summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6967.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6967.txt')
-rw-r--r--doc/rfc/rfc6967.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6967.txt b/doc/rfc/rfc6967.txt
new file mode 100644
index 0000000..973a416
--- /dev/null
+++ b/doc/rfc/rfc6967.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Boucadair
+Request for Comments: 6967 France Telecom
+Category: Informational J. Touch
+ISSN: 2070-1721 USC/ISI
+ P. Levis
+ France Telecom
+ R. Penno
+ Cisco
+ June 2013
+
+
+ Analysis of Potential Solutions for Revealing a
+ Host Identifier (HOST_ID) in Shared Address Deployments
+
+Abstract
+
+ This document is a collection of potential solutions for revealing a
+ host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN)
+ or application proxies are involved in the path. This host
+ identifier could be used by a remote server to sort packets according
+ to the sending host. The host identifier must be unique to each host
+ under the same shared IP address.
+
+ This document analyzes a set of potential solutions for revealing a
+ host identifier and does not recommend a particular solution,
+ although it does highlight the hazards of some approaches.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6967.
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 1]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 2]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. On HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 8
+ 4.1. Use the Identification Field of the IPv4 Header (IP-ID) . 8
+ 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 9
+ 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9
+ 4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.3. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9
+ 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9
+ 4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.4. Inject Application Protocol Message Headers . . . . . . . 11
+ 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11
+ 4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . 13
+ 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 13
+ 4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.6. Assign Port Sets . . . . . . . . . . . . . . . . . . . . 14
+ 4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 14
+ 4.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . 14
+ 4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 14
+ 4.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.8. Use of a Notification Channel (e.g., ICMP) . . . . . . . 15
+ 4.8.1. Description . . . . . . . . . . . . . . . . . . . . . 15
+ 4.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.9. Use Out-of-Band Mechanisms (e.g., Ident) . . . . . . . . 16
+ 4.9.1. Description . . . . . . . . . . . . . . . . . . . . . 16
+ 4.9.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 17
+ 5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 18
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 3]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+1. Introduction
+
+ As reported in [RFC6269], 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 Address plus Port (A+P) [RFC6346].
+ Examples of such issues are: implicit identification (Section 13.2 of
+ [RFC6269]), spam (Section 13.3 of [RFC6269]), blacklisting a
+ misbehaving host (Section 13.1 of [RFC6269]), or redirecting users
+ with infected machines to a dedicated portal (Section 5.1 of
+ [RFC6269]).
+
+ In particular, some servers use the source IPv4 address as an
+ identifier to treat some incoming connections differently. Due to
+ the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that
+ address will be shared. In particular, when a server receives
+ packets from the same source address, because this address is shared,
+ the server does not know which host is the sending host [RFC6269].
+ The sole use of the IPv4 address is not sufficient to uniquely
+ distinguish a host. As a mitigation, it is tempting to investigate
+ ways that would disclose information to be used by the remote server
+ as a means of uniquely disambiguating packets sent from hosts using
+ the same IPv4 address.
+
+ The risk of not mitigating these issues include: OPEX (Operational
+ Expenditure) increase for IP connectivity service providers (costs
+ induced by calls to a hotline), revenue loss for content providers
+ (loss of users' audience), and customers' dissatisfaction (low
+ quality of experience, service segregation, etc.).
+
+ The purpose of this document is to analyze a set of alternative
+ channels to convey a host identifier and to assess to what extent the
+ alternatives solve the problem described in Section 2. The
+ evaluation is intended to be comprehensive, regardless of the
+ maturity or validity of any currently known or proposed solution.
+ The alternatives analyzed in the document are listed below:
+
+ o Use the Identification field of the IP header (denoted as IP-ID,
+ Section 4.1).
+ o Define a new IP option (Section 4.2).
+ o Define a new TCP option (Section 4.3).
+ o Inject application headers (Section 4.4).
+ o Enable Proxy Protocol (Section 4.5).
+ o Assign port sets (Section 4.6).
+ o Activate HIP (Host Identity Protocol) (Section 4.7).
+ o Use a notification channel (Section 4.8).
+ o Use an out-of-band mechanism (Section 4.9).
+
+
+
+
+Boucadair, et al. Informational [Page 4]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ A synthesis is provided in Section 5, while the detailed analysis is
+ elaborated in Section 4.
+
+ Section 3 discusses privacy issues common to all proposed solutions.
+ It is out of scope of this document to elaborate on privacy issues
+ specific to each solution.
+
+ This document does not include any recommendations because the
+ working group felt that it was too premature to include one.
+
+2. On HOST_ID
+
+ Policies that rely on source IP addresses and that are enforced by
+ some servers will be applied to all hosts sharing the same IP
+ address. For example, blacklisting the IP address of a spammer host
+ will result in all other hosts that share that address having their
+ access to the requested service restricted. [RFC6269] describes the
+ issues in detail. Therefore, due to address sharing, servers need
+ extra information beyond the source IP address to differentiate the
+ sending host. We call this information the HOST_ID.
+
+ The HOST_ID identifies a host under a shared IP address. Privacy-
+ related considerations are discussed in Section 3.
+
+ Within this document, a host can be any computer located behind a
+ Home Gateway or directly connected to an address-sharing function
+ located in the network provider's domain (typically this would be the
+ Home Gateway itself).
+
+ Because the HOST_ID is used by a remote server to sort out the
+ packets by sending host, the HOST_ID must be unique to each host
+ under the same shared IP address, where possible. In the case where
+ only the Home Gateway is revealed to the operator side of the
+ translation function, the HOST_ID need only be unique to the Home
+ Gateway. The HOST_ID does not need to be globally unique. Of
+ course, the combination of the (public) IP source address and the
+ identifier (i.e., HOST_ID) ends up being unique.
+
+ If the HOST_ID is conveyed at the IP level, all packets will have to
+ bear the identifier. If it is conveyed at a higher connection-
+ oriented level, the identifier is only needed once in the session
+ establishment phase (for instance, a TCP three-way handshake), then
+ all packets received in this session will be attributed to the
+ HOST_ID designated during the session opening.
+
+ Within this document, we assume the operator-side address-sharing
+ function injects the HOST_ID. Another deployment option to avoid
+ potential performance degradation is to let the host or Home Gateway
+
+
+
+Boucadair, et al. Informational [Page 5]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ inject its HOST_ID, but the address-sharing function will check its
+ content (just like an IP anti-spoofing function). For some
+ proposals, the HOST_ID is retrieved using an out-of-band mechanism or
+ signaled in a dedicated notification channel.
+
+ For A+P [RFC6346] and its variants, port set announcements may be
+ needed as discussed in Section 4.6.
+
+ Security considerations are common to all analyzed solutions (see
+ Section 6). Privacy-related aspects are discussed in Section 3.
+
+ The HOST_ID can be ambiguous for hosts with multiple interfaces or
+ multiple addresses assigned to a single interface. HOST_IDs that are
+ the same may be used to imply or infer the same end system, but
+ HOST_IDs that are different should not be used to imply or infer
+ whether the end systems are the same or different.
+
+3. HOST_ID and Privacy
+
+ IP address sharing is motivated by a number of different factors.
+ For years, many network operators have conserved public IPv4
+ addresses by making use of Customer Premises Equipment (CPE) that
+ assigns a single public IPv4 address to all hosts within the
+ customer's local area network and uses NAT [RFC3022] to translate
+ between locally unique private IPv4 addresses and the CPE's public
+ address. With the exhaustion of IPv4 address space, address sharing
+ between customers on a much larger scale is likely to become much
+ more prevalent. While many individual users are unaware of and
+ uninvolved in decisions about whether their unique IPv4 addresses get
+ revealed when they send data via IP, some users realize privacy
+ benefits associated with IP address sharing, and some may even take
+ steps to ensure that NAT functionality sits between them and the
+ public Internet. IP address sharing makes the actions of all users
+ behind the NAT function unattributable to any single host, creating
+ room for abuse but also providing some identity protection for
+ non-abusive users who wish to transmit data with reduced risk of
+ being uniquely identified.
+
+ The proposals considered in this document help differentiate between
+ hosts that share a public IP address. The extent of that
+ differentiation depends on what information is included in the
+ HOST_ID.
+
+ The volatility of the HOST_ID information is similar to that of the
+ internal IP address: a distinct HOST_ID may be used by the address-
+ sharing function when the host reboots or gets a new internal IP
+ address. As with persistent IP addresses, persistent HOST_IDs
+ facilitate user tracking over time.
+
+
+
+Boucadair, et al. Informational [Page 6]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ As a general matter, the HOST_ID proposals do not seek to make hosts
+ any more identifiable than they would be if they were using a public,
+ non-shared IP address. However, depending on the solution proposal,
+ the addition of HOST_ID information may allow a device to be
+ fingerprinted more easily than it otherwise would be. To prevent
+ this, the following design considerations are to be taken into
+ account:
+
+ o It is recommended that HOST_IDs be limited to providing local
+ uniqueness rather than global uniqueness.
+
+ o The address-sharing function should not use permanent HOST_ID
+ values.
+
+ Should multiple solutions be combined (e.g., TCP option and Forwarded
+ header) that include different pieces of information in the HOST_ID,
+ fingerprinting may become even easier. To prevent this, an address-
+ sharing function that is able to inject HOST_IDs in several layers
+ should reveal the same subsets of information at each layer. For
+ example, if one layer references the lower 16 bits of an IPv4
+ address, the other layer should reference these 16 bits too.
+
+ A HOST_ID can be spoofed, as this is also the case for spoofing an IP
+ address. Furthermore, users of network-based anonymity services
+ (like Tor [TOR]) may be capable of stripping HOST_ID information
+ before it reaches its destination.
+
+ In order to control the information revealed to external parties, an
+ address-sharing function should be able to strip, rewrite, and add
+ HOST_ID fields.
+
+ An address-sharing function may be configured to enforce different
+ end-user preferences with regards to HOST_ID injection. For example,
+ HOST_ID injection can be disabled for some users. This feature is
+ policy based and deployment specific.
+
+ HOST_ID specification document(s) should explain the privacy impact
+ of the solutions they specify, including the extent of HOST_ID
+ uniqueness and persistence, assumptions made about the lifetime of
+ the HOST_ID, whether and how the HOST_ID can be obfuscated or
+ recycled, whether location information can be exposed, and the impact
+ of the use of the HOST_ID on device or implementation fingerprinting.
+ [IAB-PRIVACY] provides further guidance.
+
+ For more discussion about privacy, refer to [RFC6462].
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 7]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+4. Detailed Solutions Analysis
+
+4.1. Use the Identification Field of the IPv4 Header (IP-ID)
+
+4.1.1. Description
+
+ The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be
+ used to insert information that uniquely distinguishes a host among
+ those sharing the same IPv4 address. Use of the IP-ID as a channel
+ to convey the HOST_ID is a theoretical construct (i.e., it is an
+ undocumented proposal).
+
+ An address-sharing function can rewrite the IP-ID field to insert a
+ value that is unique to the host (16 bits are sufficient to uniquely
+ disambiguate hosts sharing the same IP address). The address-sharing
+ function injecting the HOST_ID must follow the rules defined in
+ [RFC6864]; in particular, the same HOST_ID is not reassigned to
+ another host sharing the same IP address during a given time
+ interval.
+
+ A variant of this approach relies upon the format of certain packets,
+ such as TCP SYN, where the IP-ID can be modified to contain a 16-bit
+ HOST_ID.
+
+ Address-sharing devices using this solution would be required to
+ indicate that they do so, possibly using a special DNS record.
+
+4.1.2. Analysis
+
+ This usage is not consistent with the fragment reassembly use of the
+ Identification field [RFC0791] or the updated handling rules for the
+ Identification field [RFC6864].
+
+ Complications may arise if the packet is fragmented before reaching
+ the device that is injecting the HOST_ID. To appropriately handle
+ those packet fragments, the address-sharing function will need to
+ maintain a lot of state.
+
+ Another complication to be encountered is where translation is
+ balanced among several NATs; setting the appropriate HOST_ID by a
+ given NAT would alter the coordination between those NATs. Of
+ course, one can argue that this coordinated NAT scenario is not a
+ typical deployment scenario; regardless, using the IP-ID as a channel
+ to convey a HOST_ID is ill-advised.
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 8]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+4.2. Define an IP Option
+
+4.2.1. Description
+
+ An alternate way to convey the HOST_ID is to define an IP option
+ [RFC0791]. A HOST_ID IP option can be inserted by the address-
+ sharing function to uniquely distinguish a host among those sharing
+ the same IP address. An example of such an option is documented in
+ [REVEAL-IP]. This IP option allows the conveyance of an IPv4
+ address, an IPv6 prefix, a Generic Routing Encapsulation (GRE) key,
+ an IPv6 Flow Label, etc.
+
+ An IP option may also be used as described in Section 4.6 of
+ [RFC3022].
+
+4.2.2. Analysis
+
+ This proposal can apply to any transport protocol. However, it is
+ widely known that routers and other middleboxes filter IP options
+ (e.g., drop IP packets with unknown IP options, strip unknown IP
+ options, etc.).
+
+ Injecting the HOST_ID IP option introduces some implementation
+ complexity in the following cases:
+
+ o The packet is at or close to the MTU size.
+
+ o The options space is exhausted.
+
+ Previous studies demonstrated that "IP Options are not an option"
+ (refer to [Not_An_Option] and [Options]).
+
+ In conclusion, using an IP option to convey a HOST_ID is not viable.
+
+4.3. Define a TCP Option
+
+4.3.1. Description
+
+ The HOST_ID may be conveyed in a dedicated TCP option. An example is
+ specified in [REVEAL-TCP]. This option encloses the TCP client's
+ identifier (e.g., the lower 16 bits of its IPv4 address, its VLAN ID,
+ VRF ID, or subscriber ID). The address-sharing device inserts this
+ TCP option into the TCP SYN packet.
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 9]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+4.3.2. Analysis
+
+ Using a new TCP option to convey the HOST_ID does not require any
+ modification to the applications, but it is applicable only for
+ TCP-based applications. Applications relying on other transport
+ protocols are therefore left unsolved.
+
+ [REVEAL-TCP] discusses the interference with other TCP options.
+
+ The risk of session failure due to handling a new TCP option is low
+ as measured in [Options]. [REVEAL-TCP-EXP] provides a detailed
+ implementation and experimentation report of a HOST_ID TCP option.
+ This document provides an in-depth investigation of the impact of
+ implementing HOST_ID on the host, the address-sharing function, and
+ the enforcement of policies at the server side. It also reports a
+ failure ratio of 0.103% among the top 100,000 websites.
+
+ Some downsides have been identified with defining a TCP option to
+ reveal a host identity:
+
+ o Conveying an IP address in a TCP option may be seen as a violation
+ of OSI layers, but since IP addresses are already used for the
+ checksum computation, this is not seen as a blocking point.
+ Moreover, the updated version of [REVEAL-TCP] no longer allows
+ conveyance of a full IP address because the HOST_ID is encoded in
+ 16 bits.
+
+ o TCP option space is limited and might be consumed by the TCP
+ client. [REVEAL-TCP-EXP] discusses two approaches to sending the
+ HOST_ID: sending the HOST_ID in the TCP SYN (which consumes more
+ bytes in the TCP header of the TCP SYN) and sending the HOST_ID in
+ a TCP ACK (which consumes only two bytes in the TCP SYN).
+
+ o Content providers may find it more desirable to receive the
+ HOST_ID in the TCP SYN, as that more closely preserves the HOST_ID
+ received in the source IP address as per current practices.
+ Moreover, sending the HOST_ID in the TCP SYN does not interfere
+ with [FASTOPEN]. In the ACK mode, if the server is configured to
+ deliver different data based on HOST_ID, then it would have to
+ wait for the ACK before transmitting data.
+
+ o HOST_ID mechanisms need to be aware of end-to-end (E2E) issues and
+ avoid interfering with them. One example of such interference
+ would be injecting or removing TCP options of transited packets;
+ another such interference involves terminating and re-originating
+ TCP connections not belonging to the transit device. The HOST_ID
+ TCP option handled by the source node avoids this issue.
+
+
+
+
+Boucadair, et al. Informational [Page 10]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ o Injecting the HOST_ID TCP option introduces some implementation
+ complexity if the options space is exhausted. Specification
+ document(s) should specify the behavior of the address-sharing
+ function in detail in such a case.
+
+ o It is more complicated to implement sending the HOST_ID in a TCP
+ ACK, as it can introduce MTU issues if the ACK packet also
+ contains TCP data or if a TCP segment is lost. Note that MTU
+ complications can be experienced if user data is included in a SYN
+ packet (e.g., [FASTOPEN]).
+
+ o When there are several NATs in the path, the original HOST_ID may
+ be lost. The loss of the original HOST_ID may not be a problem,
+ as the target usage is between proxies or between a CGN and
+ server. Only the information leaked in the last communication leg
+ (i.e., between the last address-sharing function and the server)
+ is likely to be useful.
+
+ o Interference with usages such as a Forwarded HTTP header (see
+ Section 4.4) should be elaborated to specify the behavior of
+ servers when both options are used; in particular, specify which
+ information to use: the content of the TCP option or what is
+ conveyed in the application headers.
+
+ o When load balancers or proxies are in the path, this option does
+ not allow the preservation of the original source IP address and
+ source port. Preserving such information is required for logging
+ purposes (e.g., [RFC6302]). [REVEAL-TCP-EXP] defines a TCP option
+ that allows various combinations of source information (e.g.,
+ source port, source port and source IP address, source IPv6
+ prefix, etc.) to be revealed.
+
+ More discussion about issues raised when extending TCP can be found
+ at [ExtendTCP].
+
+4.4. Inject Application Protocol Message Headers
+
+4.4.1. Description
+
+ Another option is to not require any change within the transport or
+ the IP levels but to convey the required information that will be
+ used to disambiguate hosts at the application payload. The format of
+ the conveyed information and the related semantics depend on its
+ application (e.g., HTTP, SIP, SMTP, etc.).
+
+ Related mechanisms could be developed for other application-layer
+ protocols, but the discussion in this document is limited to HTTP and
+ similar protocols.
+
+
+
+Boucadair, et al. Informational [Page 11]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ For HTTP, the Forwarded header [HTTP-FRWD] can be used to display the
+ original IP address when an address-sharing device is involved.
+ Service providers operating address-sharing devices can enable the
+ feature of injecting the Forwarded header, which will enclose the
+ original IPv4 address or the IPv6 prefix part (see the example shown
+ in Figure 1). The address-sharing device has to strip all included
+ Forwarded headers before injecting its own. Servers may rely on the
+ contents of this field to enforce some policies such as blacklisting
+ misbehaving users.
+
+ Note that [HTTP-FRWD] standardizes the Forwarded header field, to
+ replace the de facto (and not standard) X-Forwarded-For (XFF) header.
+
+ Forwarded: for=192.0.2.1,for=[2001:db8::1]
+ Forwarded: proto=https;by=192.0.2.15
+
+ Figure 1: Example of Forwarded-For
+
+4.4.2. Analysis
+
+ Not all applications impacted by address sharing can support the
+ ability to disclose the original IP address. Only a subset of
+ protocols (e.g., HTTP) can rely on this solution.
+
+ For the HTTP case, to prevent users from injecting invalid HOST_IDs,
+ an initiative has been launched by Wikimedia to maintain a list of
+ trusted ISPs (Internet Service Providers) using XFF (see the list
+ available at [Trusted_ISPs]). If an address-sharing device is on the
+ list of trusted XFF ISPs, users editing Wikimedia located behind the
+ address-sharing device will appear to be editing from their
+ "original" IP address and not from the NATed IP address. If an
+ offending activity is detected, individual hosts can be blacklisted
+ instead of blacklisting all hosts sharing the same IP address.
+
+ XFF header injection is a common practice of load balancers. When a
+ load balancer is in the path, the original content of any included
+ XFF header should not be stripped. Otherwise, the information about
+ the "origin" IP address will be lost.
+
+ When several address-sharing devices are crossed, the Forwarded
+ header can convey the list of IP addresses (e.g., Figure 1). The
+ origin HOST_ID can be exposed to the target server.
+
+ Injecting the Forwarded header also introduces some implementation
+ complexity if the HTTP message is at or close to the MTU size.
+
+ It has been reported that some HTTP proxy implementations may
+ encounter parsing issues when injecting an XFF header.
+
+
+
+Boucadair, et al. Informational [Page 12]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ Injecting the Forwarded header for all HTTPS traffic is infeasible.
+ This may be problematic given the current HTTPS usage trends.
+
+4.5. PROXY Protocol
+
+4.5.1. Description
+
+ The solution, referred to as the Proxy Protocol [Proxy], does not
+ require any application-specific knowledge. The proposed solution
+ (Proxy Protocol Version 1) would insert identification data directly
+ into the application-data stream prior to the actual protocol data
+ being sent, regardless of the protocol. Every application protocol
+ would begin with a textual string of "PROXY", followed by some
+ textual identification data, and with a CRLF; only then would the
+ application data be inserted. Figure 2 shows an example of a line of
+ data used for this purpose, in this case, for a TCP-over-IPv4
+ connection received from 192.0.2.1:56324 and destined to
+ 192.0.2.15:443.
+
+ PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n
+
+ Figure 2: Example of PROXY Connection Report
+
+ Upon receipt of a message conveying this line, the server removes the
+ line from the incoming stream. The line is parsed to retrieve the
+ transported protocol. The content of this line is recorded in logs
+ and used to enforce policies.
+
+ Proxy Protocol Version 2 is designed to accommodate IPv4/IPv6 and
+ also non-TCP protocols (see [Proxy] for more details).
+
+4.5.2. Analysis
+
+ This solution can be deployed in a controlled environment, but it
+ cannot be deployed to all access services available in the Internet.
+ If the remote server does not support the Proxy Protocol, the session
+ will fail. Other complications will arise due to the presence of
+ firewalls, for instance.
+
+ As a consequence, this solution is infeasible and cannot be
+ recommended.
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 13]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+4.6. Assign Port Sets
+
+4.6.1. Description
+
+ This solution does not require any action from the address-sharing
+ function to disclose a host identifier. Instead of assuming that all
+ transport ports are associated with one single host, each host under
+ the same external IP address is assigned a restricted port set.
+ These port sets are then advertised to remote servers using offline
+ means. This announcement is not required for the delivery of
+ internal services (i.e., offered by the service provider deploying
+ the address-sharing function) relying on implicit identification.
+
+ Port sets assigned to hosts may be static or dynamic.
+
+ Port set announcements to remote servers are not required to reveal
+ the identity of individual hosts; they are used to advertise the
+ enforced policy to generate non-overlapping port sets (e.g., the
+ transport space associated with an IP address is fragmented to
+ contiguous blocks of 2048 port numbers).
+
+ Examples of such an approach are documented in [RFC6346] and
+ [DETERMCGN].
+
+4.6.2. Analysis
+
+ The solution does not require defining new fields or options; it is
+ policy based.
+
+ The solution may contradict the port randomization [RFC6056] as
+ identified in [RFC6269]. A mitigation would be to avoid assigning
+ static port sets to individual hosts.
+
+ The method is convenient for the delivery of services offered by the
+ service provider that is also offering the Internet access service.
+
+4.7. Host Identity Protocol (HIP)
+
+4.7.1. Description
+
+ [RFC5201] specifies an architecture that introduces a new namespace
+ to convey identity information.
+
+4.7.2. Analysis
+
+ This solution requires both the client and the server to support HIP
+ [RFC5201]. Additional architectural considerations are to be taken
+ into account, such as the key exchanges.
+
+
+
+Boucadair, et al. Informational [Page 14]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ An alternative deployment model that does not require the client to
+ be HIP-enabled is having the address-sharing function behave as a
+ UDP/TCP-HIP relay. This model is also not viable as it assumes all
+ servers are HIP-enabled.
+
+ This solution is a theoretical construct (i.e., the proposal is not
+ documented).
+
+4.8. Use of a Notification Channel (e.g., ICMP)
+
+4.8.1. Description
+
+ Another alternative is to convey the HOST_ID using a separate
+ notification channel than the one the packets issued to invoke the
+ service.
+
+ This solution relies on a mechanism where the address-sharing
+ function encapsulates the necessary host-identifying information into
+ an ICMP Echo Request packet that it sends in parallel with the
+ initial session creation (e.g., SYN). The information included in
+ the ICMP Request Data portion describes the five-tuples as seen on
+ both sides of the address-sharing function. An implementation
+ example is defined in [REVEAL-ICMP].
+
+4.8.2. Analysis
+
+ o This ICMP proposal is valid for any transport protocol that uses a
+ port number. The address-sharing function may be configured with
+ the transport protocols that will trigger issuing those ICMP
+ messages.
+
+ o A hint should be provided to the ultimate server (or intermediate
+ nodes) that the ICMP Echo Request conveys a HOST_ID. This may be
+ implemented using magic numbers (a magic number is a self-selected
+ codepoint whose primary value is its unlikely collision with
+ values selected by others).
+
+ o Even if ICMP packets are blocked in the communication path, the
+ user connection does not have to be impacted.
+
+ o Implementations requiring a session establishment to be delayed
+ until receipt of the companion ICMP Echo Request may lead to some
+ user-experience degradation.
+
+ o Because of the presence of load balancers in the path, the
+ ultimate server receiving the SYN packet may not be the one that
+ receives the ICMP message conveying the HOST_ID.
+
+
+
+
+Boucadair, et al. Informational [Page 15]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ o Because of the presence of load balancers in the path, the port
+ number assigned by address sharing may be lost. Therefore, the
+ mapping information conveyed in the ICMP may not be sufficient to
+ associate a SYN packet with a received ICMP.
+
+ o The proposal is not compatible with the presence of cascaded NAT.
+ The main reason is that each NAT in the path will generate an ICMP
+ message to reveal the internal host identifier. Because these
+ messages will be translated by the downstream address-sharing
+ devices, the remote server will receive multiple ICMP messages and
+ will need to decide which host identifier to use.
+
+ o The ICMP proposal will add traffic overhead for both the server
+ and the address-sharing device.
+
+ o The ICMP proposal is similar to other mechanisms (e.g., IPFIX
+ [IPFIX-NAT] and Syslog [SYSLOG-NAT]) for reporting dynamic
+ mappings to a mediation platform (mainly for legal traceability
+ purposes). Performance degradation is likely to be experienced by
+ address-sharing functions because ICMP messages are sent for each
+ new instantiated mapping (even if the mapping exists).
+
+ o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID
+ should be interpreted by intermediate devices that embed Policy
+ Enforcement Points (PEP) [RFC2753] responsible for granting access
+ to some services. These PEPs need to inspect all received packets
+ in order to find the companion (traffic) messages to be correlated
+ with ICMP messages conveying HOST_IDs. This induces more
+ complexity to these intermediate devices.
+
+4.9. Use Out-of-Band Mechanisms (e.g., Ident)
+
+4.9.1. Description
+
+ Another alternative is to retrieve the HOST_ID using a dedicated
+ query channel.
+
+ An implementation example may rely on the Identification Protocol
+ (Ident) [RFC1413]. This solution assumes that the address-sharing
+ function implements the server part of IDENT, while remote servers
+ implement the client part of the protocol. IDENT needs to be updated
+ to be able to return a host identifier instead of the user-id as
+ defined in [RFC1413]. The IDENT response syntax uses the same USERID
+ field described in [RFC1413], but rather than returning a username, a
+ host identifier (e.g., a 16-bit value) is returned. For any new
+ incoming connection, the server contacts the IDENT server to retrieve
+ the associated identifier. During that phase, the connection may be
+ delayed.
+
+
+
+Boucadair, et al. Informational [Page 16]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+4.9.2. Analysis
+
+ o IDENT is specific to TCP. Alternative out-of-band mechanisms may
+ be designed to cover other transport protocols such as UDP.
+
+ o This solution requires the address-sharing function to embed an
+ IDENT server.
+
+ o A hint should be provided to the ultimate server (or intermediate
+ nodes) that the address-sharing function implements the IDENT
+ protocol, for example, publishing this capability using DNS (other
+ solutions can be envisaged).
+
+ o An out-of-band mechanism may require some administrative setup
+ (e.g., contract agreement) between the entity managing the
+ address-sharing function and the entity managing the remote
+ server. Such a deployment is not feasible in the Internet at
+ large because establishing and maintaining agreements between ISPs
+ and all service actors is burdensome and not scalable.
+
+ o Implementations requiring delay of the establishment of a session
+ until receipt of the companion IDENT response may lead to some
+ user-experience degradation.
+
+ o The IDENT proposal will add traffic overhead for both the server
+ and the address-sharing device.
+
+ o Performance degradation is likely to be experienced by address-
+ sharing functions embedding the IDENT server. This is further
+ exacerbated if the address-sharing function has to handle an IDENT
+ query for each new instantiated mapping (even if the mapping
+ exists).
+
+ o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID
+ should be interpreted by intermediate devices that embed Policy
+ Enforcement Points (PEP) [RFC2753] responsible for granting access
+ to some services. These PEPs need to inspect all received packets
+ in order to generate the companion IDENT queries. This may induce
+ more complexity to these intermediate devices.
+
+ o IDENT queries may be generated by illegitimate TCP servers. This
+ would require the address-sharing function to enforce some
+ policies (e.g., rate-limit queries, filter based on the source IP
+ address, etc.).
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 17]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+5. Solutions Analysis: Synthesis
+
+ Table 1 summarizes the approaches analyzed in this document.
+
+ +-----+------+------+------+-----+-----+-----+-----+-----+
+ |IP-ID| IP | TCP |HTTP |PROXY|Port | HIP |ICMP |IDENT|
+ | |Option|Option|Header| | Set | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ UDP | Yes | Yes | No | No | No | Yes | | Yes | No |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | Yes |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
+ Traffic | | | | | | | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ Success | High| Low | High | High | Low | 100%|Low |High |High |
+ Ratio | | | | | | | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ Possible | Low | High | Low | Med | High| No | N/A | High|High |
+ Perf | to | | to | to | | | | | |
+ Impact | Med | | Med | High | | | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | Yes |
+ Modif | | | | | | | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | Yes |
+ Today | | | | | | | | | |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+ Notes | (1) | (8) | (8) | (2) | (8) | (1) | (4) | (6) | (1) |
+ | (7) | | | | | (3) | (7) | (8) | (6) |
+ | | | | | | | | | (8) |
+ ----------+-----+------+------+------+-----+-----+-----+-----+-----+
+
+ Table 1: Summary of Analyzed Solutions
+
+ o "Encrypted Traffic" refers to TLS. The use of IPsec and its
+ complications traversing NATs are discussed in Section 2.2 of
+ [RFC6889]. Similar to what is suggested in Section 13.5 of
+ [RFC6269], HOST_ID specification document(s) should analyze the
+ compatibility of each IPsec mode in detail.
+
+ o "Success ratio" indicates the ratio of successful communications
+ with remote servers when the HOST_ID is injected using a proposed
+ solution. More details are provided below to explain how the
+ success ratio is computed for each proposed solution.
+
+
+
+
+Boucadair, et al. Informational [Page 18]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ o "Possible Perf Impact" indicates the level of expected performance
+ degradation. The indicated degradation is an estimate based on
+ the need for processing at the IP layer.
+
+ o "OS TCP/IP Modif" indicates whether a modification of the OS
+ TCP/IP stack is required at the server side.
+
+ o "Deployable today" indicates if the solution can be generalized
+ without any constraint on current architectures and practices.
+
+ Notes:
+ (1) Requires mechanism to advertise that NAT is participating in
+ this scheme (e.g., DNS PTR record).
+ (2) This solution is widely deployed (e.g., HTTP severs, load
+ balancers, etc.).
+ (3) When the port set is not advertised, the solution is less
+ efficient for third-party services.
+ (4) Requires that the client and the server to be HIP-compliant and
+ that HIP infrastructure be deployed. If the client and the
+ server are HIP-enabled, the address-sharing function does not
+ need to insert an identifier. If the client is not HIP-enabled,
+ designing the device that performs address sharing to act as a
+ UDP/TCP-HIP relay is not viable.
+ (6) The solution is inefficient in some scenarios (see Section 5).
+ (7) The solution is a theoretical construct (i.e., the solution is
+ not documented).
+ (8) The solution is a documented proposal.
+
+ Provided success ratio figures for TCP and IP options are based on
+ the results documented in [Options] and [REVEAL-TCP-EXP].
+
+ The provided success ratio for the IP-ID is theoretical; it assumes
+ the address-sharing function follows the rules (see [RFC6864])to
+ rewrite the IP Identification field.
+
+ Since PROXY and HIP are not widely deployed, the success ratio for
+ establishing communication with remote servers using these protocols
+ is low.
+
+ The success ratio for the ICMP-based solution is implementation
+ specific, but it is likely to be close to 100%. The success ratio
+ depends on how efficiently the solution is implemented on the server
+ side. A remote server that does not support the ICMP-based solution
+ will ignore received companion ICMP messages. An upgraded server
+ will need to delay the acceptance of a session until it receives the
+ companion ICMP message.
+
+
+
+
+
+Boucadair, et al. Informational [Page 19]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ The success ratio for the IDENT solution is implementation specific
+ but it is likely to be close to 100%. The success ratio depends on
+ how efficient the solution is implemented on the server side. A
+ remote server that does not support IDENT will accept a session
+ establishment request following its normal operation. An upgraded
+ server will need to delay the acceptance of a session until it
+ receives a response to the IDENT request it will send to the host.
+
+ The provided success ratio for the Port Set and HTTP header solutions
+ is 100% because no additional Layer 3 or Layer 4 field is needed to
+ convey HOST_ID for these solutions.
+
+6. Security Considerations
+
+ If the server trusts the content of the HOST_ID field, a third-party
+ user can be impacted by a misbehaving user revealing a "faked"
+ HOST_ID (e.g., original IP address). This same security concern
+ applies for the injection of an IP option, TCP option, and
+ application-related content (e.g., the Forwarded HTTP header) by the
+ address-sharing device.
+
+ The HOST_ID may be used to leak information about the internal
+ structure of a network behind an address-sharing function. If this
+ behavior is undesired for the network administrator, the address-
+ sharing function can be configured to strip any existing HOST_ID in
+ received packets from internal hosts.
+
+ HOST_ID specification documents should elaborate further on threats
+ inherent to each individual solution used to convey the HOST_ID
+ (e.g., use of the IP-ID field to count hosts behind a NAT [Count]).
+
+ For more discussion of privacy issues related to the HOST_ID, see
+ Section 3.
+
+7. Acknowledgments
+
+ Many thanks to D. Wing, C. Jacquenet, J. Halpern, B. Haberman, and
+ P. Yee for their review, comments, and inputs.
+
+ Thanks also to P McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M.
+ Blanchet, D. Wing, and A. Yourtchenko for the discussions in Prague.
+
+ Some of the issues related to defining a new TCP option have been
+ raised by L. Eggert.
+
+ The privacy text was provided by A. Cooper.
+
+
+
+
+
+Boucadair, et al. Informational [Page 20]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+ Address Translator (Traditional NAT)", RFC 3022, January
+ 2001.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056, January
+ 2011.
+
+8.2. Informative References
+
+ [Count] Belloven, S., "A Technique for Counting NATted Hosts",
+ <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
+
+ [DETERMCGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
+ and O. Vautrin, "Deterministic Address Mapping to Reduce
+ Logging in Carrier Grade NAT Deployments", Work in
+ Progress, January 2013.
+
+ [ExtendTCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
+ Handley, M. and H. Tokuda,, "Is It Still Possible to
+ Extend TCP?", November 2011,
+ <http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.
+
+ [FASTOPEN] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+ Fast Open", Work in Progress, February 2013.
+
+ [HTTP-FRWD] Petersson, A. and M. Nilsson, "Forwarded HTTP
+ Extension", Work in Progress, October 2012.
+
+ [IAB-PRIVACY]
+ Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+ Morris, J., Hansen, M., and R. Smith, "Privacy
+ Considerations for Internet Protocols", Work in
+ Progress, July 2012.
+
+ [IPFIX-NAT] Sivakumar, S. and R. Penno, "IPFIX Information Elements
+ for Logging NAT Events", Work in Progress, March 2013.
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 21]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ [Not_An_Option]
+ R. Fonseca, G. Porter, R. Katz, S. Shenker, and I.
+ Stoica,, "IP Options Are Not An Option", 2005,
+ <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/
+ EECS-2005-24.html>.
+
+ [Options] Medina, A, Allman, M. and S. Floyd, "Measuring
+ Interactions Between Transport Protocols and
+ Middleboxes", 2005,
+ <http://conferences.sigcomm.org/imc/2004/papers/
+ p336-medina.pdf>.
+
+ [Proxy] Tarreau, W., "The PROXY protocol", November 2010,
+ <http://haproxy.1wt.eu/download/1.5/doc/
+ proxy-protocol.txt>.
+
+ [REVEAL-ICMP]
+ Yourtchenko, A., "Revealing Hosts Sharing An IP Address
+ Using ICMP Echo Request", Work in Progress, March 2012.
+
+ [REVEAL-IP] Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header
+ Option For User Identification In CGN Scenario", Work in
+ Progress, March 2011.
+
+ [REVEAL-PCP] Boucadair, M., Reddy, T., Patil, P., and D. Wing, "Using
+ PCP to Reveal a Host behind NAT", Work in Progress,
+ November 2012.
+
+ [REVEAL-TCP-EXP]
+ Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP
+ Options: Implementation & Preliminary Test Results",
+ Work in Progress, July 2012.
+
+ [REVEAL-TCP] Yourtchenko, A. and D. Wing, "Revealing Hosts Sharing An
+ IP Address Using TCP Option", Work in Progress, December
+ 2011.
+
+ [RFC1413] St. Johns, M., "Identification Protocol", RFC 1413,
+ February 1993.
+
+ [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
+ Framework for Policy-based Admission Control", RFC 2753,
+ January 2000.
+
+ [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T.
+ Henderson, "Host Identity Protocol", RFC 5201, April
+ 2008.
+
+
+
+
+Boucadair, et al. Informational [Page 22]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from
+ IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
+
+ [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+ Roberts, "Issues with IP Address Sharing", RFC 6269,
+ June 2011.
+
+ [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
+ "Logging Recommendations for Internet-Facing Servers",
+ BCP 162, RFC 6302, June 2011.
+
+ [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
+ IPv4 Address Shortage", RFC 6346, August 2011.
+
+ [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
+ RFC 6462, January 2012.
+
+ [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
+ RFC 6864, February 2013.
+
+ [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
+ "Analysis of Stateful 64 Translation", RFC 6889, April
+ 2013.
+
+ [SYSLOG-NAT] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
+ Format for NAT Logging", Work in Progress, May 2013.
+
+ [TOR] Dingledine, R., Mathewson, N., and P. Syverson, "Tor:
+ The secondgeneration onion router", In Proceedings of
+ the 13th USENIX Security Symposium, August 2004.
+
+ [Trusted_ISPs]
+ Wikimedia, "Trusted XFF List", May 2013,
+ <http://meta.wikimedia.org/w/
+ index.php?title=XFF_project&oldid=5507690>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 23]
+
+RFC 6967 Revealing HOST_ID June 2013
+
+
+Authors' Addresses
+
+ Mohamed Boucadair
+ France Telecom
+ Rennes 35000
+ France
+
+ EMail: mohamed.boucadair@orange.com
+
+
+ Joe Touch
+ USC/ISI
+ 4676 Admiralty Way
+ Marina del Rey, CA 90292-6695
+ United States
+
+ Phone: +1 (310) 448-9151
+ EMail: touch@isi.edu
+
+
+ Pierre Levis
+ France Telecom
+ Caen 14000
+ France
+
+ EMail: pierre.levis@orange.com
+
+
+ Reinaldo Penno
+ Cisco
+ United States
+
+ EMail: repenno@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Informational [Page 24]
+