One document matched: draft-boucadair-pcp-nat-reveal-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-pcp-nat-reveal-00"
ipr="trust200902">
<front>
<title abbrev="PCP to Reveal a Host behind NAT">Using PCP to Reveal a Host
behind NAT</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>This document describes how to use PCP to retrieve the identify of a
host behind a NAT. Two use cases are discussed and the PCP applicability
is analyzed. This document extends PCP with a new OpCode: QUERY.</t>
<t>The proposed mechanism is valid for all NAT flavors including NAT44,
NAT64 or NPTv6. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As reported in <xref target="RFC6269"></xref>, several issues are
encountered when an IP address is shared among several subscribers.
These issues are encountered in various deployment contexts: e.g.,
Carrier Grade NAT (CGN), application proxies or A+P <xref
target="RFC6346"></xref>.</t>
<t>This document extends <xref target="I-D.ietf-pcp-base">Port Control
Protocol</xref> to identify a host among those sharing the same IP
address in certain scenarios.</t>
<t>The proposed technique can be used independently or combined with the
host identifier, denoted as HOST_ID defined in <xref
target="I-D.ietf-intarea-nat-reveal-analysis"></xref>.</t>
<t>Additional scenarios requiring host identification are listed in
<xref
target="I-D.boucadair-intarea-host-identifier-scenarios"></xref>.</t>
</section>
<section anchor="notation" title="Requirements Language and Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>This note uses terminology defined in <xref
target="I-D.ietf-pcp-base"></xref>.</t>
</section>
<section title="Problem Space">
<t></t>
<section title="Policy and Charging Control Architecture">
<t><xref target="figure1"></xref> depicts a reference architecture of
a mobile network <xref target="RFC6342"></xref>.</t>
<t><figure anchor="figure1" title="Mobile Network Archtecture">
<artwork><![CDATA[ +-----+ +-----+
| AAA | | PCRF|
+-----+ +-----+
\ /
\ / /-
\ / / I
UE BS \ / / n
| /\ +-----+ /-----------\ +-----+ /-----------\ +----+ / t
+-+ /_ \---| ANG |/ Operator's \| PCEF|/ Operator's \| BR |/ e
| |---/ \ +-----+\ IP Network /+-----+\ IP Network /+----+\ r
+-+ \-----------/ \-----------/ \ n
\ e
\ t
+-----+
| AF |
+-----+ ]]></artwork>
</figure></t>
<t>The main involved functional elements are:<list style="symbols">
<t>UE (User Equipment) is a mobile node.</t>
<t>Policy and Charging Rule Function (PCRF) which is responsible
for determining which policy and charging control rules are to be
applied <xref target="TS.23203"></xref>.</t>
<t>Policy and Charging Enforcement Function (PCEF) which performs
policy enforcement (e.g., Quality of Service (QoS)) and flow-based
charging <xref target="TS.23203"></xref>.</t>
<t>Application Function (AF) is an element offering applications
that require dynamic policy and/or charging control <xref
target="TS.23203"></xref>.</t>
<t>Access Network Gateway (ANG), Base Station (BS) and Border
Router (BR) are defined in <xref target="RFC6342"></xref>.</t>
</list></t>
<t><xref target="pb1"></xref> and <xref target="pb2"></xref> explain
the encountered problems to identify individual UEs when a NAT is
involved in the data path. The use of PCP to solve those problems is
analyzed in <xref target="pcp_solution"></xref>.</t>
</section>
<section anchor="pb1" title="NAT between the PCEF and AF">
<t><xref target="figure2"> </xref> shows a scenario where a NAT
function is located between the PCEF and AF.</t>
<t><figure anchor="figure2" title="NAT between PCEF and AF">
<artwork><![CDATA[ PCP Client
+------+
| PCRF |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +-----+
| UE |------| PCEF |---| NAT |----| AF |
+----+ +------+ +-----+ +-----+
PCP
Aware ]]></artwork>
</figure></t>
<t>The main issue in this case is that PCEF, PCRF and AF all receive
information bound to the same UE but cannot correlate between the
piece of data visible for each entity. Concretely,</t>
<t><list style="symbols">
<t>PCEF is aware of the IMSI (International Mobile Subscriber
Identity) and an internal IP address assigned to the UE.</t>
<t>AF receives an external IP address and port as assigned by the
NAT function.</t>
<t>PCRF is not able to correlate between the external IP
address/port assigned by the NAT and the internal IP address and
IMSI of the UE. For instance, the offered QoS on internal IPv4
address and the (shared) external IPv4 address may need to be
correlated for accounting purposes.</t>
<t>The IP address seen by the AF is shared among multiple UEs
using NAT, the PCRF needs to be able to inspect the NAT binding to
disambiguate among the individual UEs. AF will not be able to
treat UE traffic based on policy provided by PCRF.</t>
</list></t>
<t>This scenario can be generalized as follows (<xref
target="figure3"></xref>):</t>
<t><list style="symbols">
<t>Policy Enforcement Point (PEP, <xref
target="RFC2753"></xref>)</t>
<t>Policy Decision Point (PDP, <xref target="RFC2753"></xref>)</t>
</list></t>
<t><figure anchor="figure3" title="NAT between PEP and Server">
<artwork><![CDATA[ PCP Client
+------+
| PDP |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +------+
|Host|------| PEP |---| NAT |----|Server|
+----+ +------+ +-----+ +------+
PCP
Aware ]]></artwork>
</figure></t>
</section>
<section anchor="pb2" title="NAT before PCEF">
<t><xref target="figure4"></xref> shows an alternative scenario in
which a NAT function is located before PCEF. The main issue is that
PCEF and AF are only aware of the external IP address and the external
port number assigned by the NAT function. PCEF/AF will fail to
identify each UE behind NAT since multiple UEs share the same external
IP address and thus are unable to treat incoming connections
differently.</t>
<t><figure anchor="figure4" title="NAT before PCEF">
<artwork><![CDATA[
PCP Client
+-------+
| PCRF |------+
+-------+ |
| |
+----+ +------+ +-----+ +-----+
| UE |------| NAT |---|PCEF |----| AF |
+----+ +------+ +-----+ +-----+
PCP
Aware
]]></artwork>
</figure></t>
<t>This scenario can be generalized as follows (<xref
target="figure4a"></xref>):</t>
<t><figure anchor="figure4a" title="NAT before PEP">
<artwork><![CDATA[
PCP Client
+------+
| PDP |------+
+------+ |
| |
+----+ +------+ +-----+ +------+
|Host|------| NAT |---| PEP |----|Server|
+----+ +------+ +-----+ +------+
PCP
Aware
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section anchor="pcp_solution" title="PCP Applicability">
<t>This section discusses how PCP can be used to solve the problems
described in <xref target="pb1"></xref> and <xref
target="pb2"></xref>.</t>
<section title="NAT between the PCEF and AF">
<t>A solution to solve the problem discussed in <xref
target="pb1"></xref> is to enable a PCP Server to control the NAT and
enable a PCP Client in the PCRF. The updated interaction between PCRF,
PCEF and AF is detailed below.</t>
<t><list style="symbols">
<t>The PCP server controlling the NAT is configured to accept PCP
requests with THIRD_PARTY Option from authorized PCP clients
(i.e., PCRF).</t>
<t>PCRF is configured with the IP address of the PCP Server.</t>
<t>The PCRF is aware of the following 5-tuple of each flow
{Internal IP address of UE, Internal Port, Protocol, Remote Peer
IP address, Remote Port number} learnt from PCEF. PCRF is also
aware of the following 5-tuple of each flow {External IP address,
External Port, Protocol, Remote Peer IP address, Remote Port
number} learnt from AF.</t>
<t>The PCRF generates PCP PEER request with THIRD_PARTY option
which has Internal IP Address set to the UE's Internal IP address
provided by the PCEF. <list style="symbols">
<t>The Internal Port, Protocol, Remote Peer Port, Remote Peer
IP Address fields of the PEER request are set by the PCRF
according to the 5-tuple flow information provided by
PCEF.</t>
<t>Suggested External Port and Suggested External IP Address
are set to zero.</t>
<t>Requested Lifetime field is set to a very low value (see
Section 12.3 of <xref target="I-D.ietf-pcp-base"></xref>).</t>
</list></t>
<t>Upon the receipt of the PEER response, the PCRF compares the
External IP Address and Port learnt with the 5-tuple flow
information provided by the AF to correlate external IP
address/port associated with the mapping and the internal IP
address/port of the flow. </t>
<t>PCRF notifies PCEF/AF to enforce relevant policies for the
UE.</t>
</list></t>
</section>
<section title="NAT before PCEF">
<t>A solution to solve the problem discussed in <xref
target="pb2"></xref> is to extend PCP with a new OpCode called QUERY
(see <xref target="query"></xref>). </t>
<t>The updated interaction between PCRF, PCEF and AF is detailed
below:<list style="symbols">
<t>The PCP server controlling the NAT is configured to accept
QUERY requests <xref target="query"></xref> from authorized PCP
clients such as PCRF. Query requests must not be received in the
Internet-facing interface but from an internal interface (e.g.,
dedicated management interface).</t>
<t>PCRF generates a PCP QUERY request with External IP Address,
External Port, Remote Peer IP address, Remote Peer Port and
Protocol fields for the flow learnt from PCEF or AF.</t>
<t>PCRF learns the internal IP address and internal port number in
the QUERY response. This correlation is used by the PCRF to
retrieve the UE's policy to be passed to the PCEF.</t>
</list><xref target="figure5"></xref> shows an example of the use of
QUERY OpCode. In this example, an HTTP connection is initiated by the
UA (192.0.2.1:33041) to an HTTP server (198.51.100.2:80). The NAT
assigns 198.51.100.1/23432 as external IP Address/Port. PCRF learns
Internal IP Address and Port associated with the NAT mapping using PCP
QUERY request/response.</t>
<figure align="center" anchor="figure5" title="Usage Example">
<artwork><![CDATA[ +------+ +-----+ +------+ +------+
| UE | | NAT | | PCRF | | AF |
+------+ +-----+ +------+ +------+
192.0.2.1 | 198.51.100.2
| | |
|Src IP Address:Port | |
| = 192.0.2.1:33041 | |
|Dst IP Address:Port | |
| = 198.51.100.2:80 | |
|===================>|=====================================>|
| |Src IP Address:Port=198.51.100.1:23432|
| |Dst IP Address:Port=198.51.100.2:80 |
| | |
| {PCRF learns 5-tuple |
| from AF or PCEF} |
| | | |
| | PCP QUERY Request | |
| | External IP:Port = | |
| | 198.51.100.1:23432 | |
| | Remote Peer IP:Port = | |
| | 198.51.100.2:80 | |
| | Protocol = TCP | |
| |<=======================| |
| | PCP QUERY Response | |
| | External IP:Port = | |
| | 198.51.100.1:23432 | |
| | Internal IP:Port = | |
| | 192.0.2.1:33041 | |
| | Protocol = TCP | |
| | Lifetime = 1000 sec | |
| |=======================>| |
| | | |
| Generate Policy Rules
]]></artwork>
</figure>
<t></t>
<t></t>
</section>
</section>
<section anchor="query" title="QUERY OpCode">
<t>This section defines a new PCP OpCode which can be used to query
PCP-aware NAT to retrieve the Internal IP Address and Internal Port of a
given mapping.</t>
<t>The PCP Server MUST provide a configuration option to allow
administrators to enable/disable QUERY OpCode.</t>
<section title="QUERY Request Format">
<t>The following diagram shows the format of the OpCode-specific
information in a request for the QUERY OpCode.</t>
<t><figure anchor="figure6" title="Query Opcode Request">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| QUERY Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Port | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>These fields are described below:<list style="hanging">
<t hangText="Requested Lifetime (in common header):">This field
is positioned to 0.</t>
<t hangText="Mapping Nonce:">Random value chosen by the PCP
client. See Section 12.2 of <xref
target="I-D.ietf-pcp-base"></xref></t>
<t hangText="Protocol:">Upper-layer protocol associated with this
OpCode. Values are taken from the IANA protocol registry <xref
target="proto_numbers"> </xref>. For example, this field contains
6 (TCP) if the OpCode is describing a TCP mapping. Protocol MUST
NOT be zero.</t>
<t hangText="Reserved:">24 reserved bits, MUST be set to 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="External Port:">External port allocated by NAT for
the flow. External Port MUST NOT be zero</t>
<t hangText="Remote Peer Port:">Remote peer's port for the flow.
Remote Peer Port MUST NOT be zero</t>
<t hangText="External IP address:">External IP address allocated
by NAT for the flow. External IP address MUST NOT be zero</t>
<t hangText="Remote Peer IP address:">Remote peer IP address for
the flow. Remote Peer IP address MUST NOT be zero.</t>
</list></t>
</section>
<section title="QUERY Response Format">
<t>The following diagram shows the format of OpCode-specific
information in a response packet for the QUERY OpCode:</t>
<t><figure anchor="figure7" title="Query Opcode Response">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| QUERY Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Port | Internal Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Internal IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>These fields are described below:<list style="hanging">
<t hangText="Lifetime (in common header):">On a success response,
this indicates the lifetime for this mapping, in seconds. On an
error response, this indicates that mapping does not exist.</t>
<t hangText="Mapping Nonce:">Copied from the request.</t>
<t hangText="Protocol:">Copied from the request.</t>
<t hangText="Reserved:">24 reserved bits, MUST be set to 0.</t>
<t hangText="External Port:">Copied from the request.</t>
<t hangText="External IP address:">Copied from the request.</t>
<t hangText="Internal Port:">Internal Port as assigned by the
PCP-controlled device.</t>
<t hangText="Internal IP address:">Internal IP address as assigned
by the PCP-controlled controlled device.</t>
</list></t>
</section>
<section title="Generating a QUERY Request">
<t>This section describes the operation of a PCP client when sending
requests with the QUERY OpCode.</t>
<t>PCP QUERY request is used by an authorized third party PCP client
that is only aware of the 5-tuple {External IP address and Port,
Protocol, Remote Peer IP address and Port} and needs to learn the
Internal IP address and Port associated with the NAT mapping. The
request MUST contain non-zero values of Protocol, External Port,
Remote Peer Port, External IP address and Remote Peer IP address. The
Requested Lifetime MUST be set to zero.</t>
</section>
<section title="Processing a QUERY Request">
<t>This section describes the operation of a PCP server when
processing a QUERY request.</t>
<t>For EIM/EIF port-mapping NAT, the processing of the QUERY request
is as follows:<list style="symbols">
<t>If any of the values Protocol, External Port and External IP
address are equal to zero, the request is invalid and the PCP
server MUST return a MALFORMED_REQUEST to the client.</t>
<t>If Protocol, External Port and External IP address do not match
any existing implicit dynamic mapping, then the PCP server MUST
return NONEXIST_MAP error response (also needed in <xref
target="I-D.boucadair-pcp-failure"></xref>).</t>
<t>If Protocol, External Port and External IP address match an
existing implicit dynamic mapping, then the PCP server MUST build
a QUERY response with the Internal IP address, Internal Port and
the lifetime associated with the mapping.</t>
</list></t>
<t>For EDM port-mapping NAT, the processing of the QUERY request is as
follows:</t>
<t><list style="symbols">
<t>If any of the values Protocol, External Port, Remote Peer Port,
External IP address and Remote Peer IP Address are zero, the
request is invalid and PCP server MUST return a MALFORMED_REQUEST
to the client.</t>
<t>If Protocol, External Port, Remote Peer Port, External IP
address and Remote Peer IP address do not match any existing
implicit dynamic mapping then the PCP server MUST return
NONEXIST_MAP error response (also needed in <xref
target="I-D.boucadair-pcp-failure"></xref>).</t>
<t>If Protocol, External Port, Remote Peer Port, External IP
address and Remote Peer IP address matches an existing implicit
dynamic mapping then the PCP server builds a QUERY response with
the Internal IP address, Internal Port and the lifetime associated
with the mapping.</t>
</list></t>
<t>PCP QUERY requests received on the Internet-facing interface MUST
be silently drooped. </t>
<t>In DS-Lite context <xref target="RFC6333"></xref>, the Internal IP
address returned in the QUERY response MUST be the IPv6 address of the
remote tunnel endpoint and not the internal private IPv4 address.</t>
</section>
<section title="Processing a QUERY Response">
<t>After performing common PCP response processing by the PCP Client,
the response is further matched with a previously-sent QUERY request
by comparing the QUERY Nonce, External IP Address, External Port and
Protocol. On a SUCCESS response, the PCP Client can use the Internal
IP Address and Port in the QUERY response as needed.</t>
</section>
</section>
<section title="Applicability Scope of QUERY OpCode">
<t>The PCP-Reveal solution is designed for needs within one single
administrative domain (i.e., the PCP Client and PCP Server are managed
by the same entity). Considerations related to the activation of the
PCP-Reveal solution in an inter-domain context is out of scope of this
document.</t>
</section>
<section title="IANA Considerations">
<t>Authors of this document request the following OpCode:<list
style="symbols">
<t>QUERY</t>
</list></t>
<t>The following error code is requested:<list style="symbols">
<t>NONEXIST_MAP</t>
</list></t>
<t></t>
</section>
<section title="Security Considerations">
<t>Security considerations discussed in <xref
target="I-D.ietf-pcp-base"></xref> are to be taken into account. In
particular, QUERY OpCode MUST NOT be implemented or used unless the
network on which the PCP QUERY messages are to be sent is fully trusted.
For example if Access Control Lists (ACLs) are installed on the PCP
server, and the network between the PCP client and the PCP server, so
those ACLs allow only communications from a trusted PCP client to the
PCP server. </t>
<t>QUERY OpCode may be generated by non legitimate PCP Clients; the PCP
Server MUST enforce some policies such as rate limit QUERY messages.
QUERY requests received from non legitimate PCP Clients are silently
dropped.</t>
<t>PCP authentication <xref target="I-D.ietf-pcp-authentication"></xref>
MAY be used.</t>
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<reference anchor="proto_numbers"
target="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml">
<front>
<title>Protocol Numbers</title>
<author fullname="IANA" surname="IANA">
<organization></organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="TS.23203" target="">
<front>
<title>Policy and charging control architecture</title>
<author fullname="3GPP" surname="3GPP">
<organization>UPnP Forum</organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<?rfc ?>
<?rfc include="reference.RFC.6342"
?>
<?rfc include="reference.RFC.2753"
?>
<?rfc include="reference.RFC.6269"
?>
<?rfc include='reference.RFC.6333'?>
<?rfc include="reference.RFC.6346"
?>
<?rfc include='reference.I-D.boucadair-intarea-host-identifier-scenarios'?>
<?rfc include='reference.I-D.ietf-intarea-nat-reveal-analysis'?>
<?rfc include='reference.I-D.boucadair-pcp-failure'?>
<?rfc include='reference.I-D.ietf-pcp-authentication'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:43:36 |