diff options
Diffstat (limited to 'doc/rfc/rfc7620.txt')
| -rw-r--r-- | doc/rfc/rfc7620.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7620.txt b/doc/rfc/rfc7620.txt new file mode 100644 index 0000000..b4f96d7 --- /dev/null +++ b/doc/rfc/rfc7620.txt @@ -0,0 +1,1459 @@ + + + + + + +Independent Submission M. Boucadair, Ed. +Request for Comments: 7620 B. Chatras +Category: Informational Orange +ISSN: 2070-1721 T. Reddy + Cisco Systems + B. Williams + Akamai, Inc. + B. Sarikaya + Huawei + August 2015 + + + Scenarios with Host Identification Complications + +Abstract + + This document describes a set of scenarios in which complications + when identifying which policy to apply for a host are encountered. + This problem is abstracted as "host identification". Describing + these scenarios allows commonalities between scenarios to be + identified, which is helpful during the solution design phase. + + This document does not include any solution-specific discussions. + +IESG Note + + This document describes use cases where IP addresses are overloaded + with both location and identity properties. Such semantic + overloading is seen as a contributor to a variety of issues within + the routing system [RFC4984]. Additionally, these use cases may be + seen as a way to justify solutions that are not consistent with IETF + Best Current Practices on protecting privacy [BCP160] [BCP188]. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not 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/rfc7620. + + + +Boucadair, et al. Informational [Page 1] + +RFC 7620 Host Identification: Scenarios August 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Scenario 1: Carrier-Grade NAT (CGN) . . . . . . . . . . . . . 4 + 4. Scenario 2: Address plus Port (A+P) . . . . . . . . . . . . . 5 + 5. Scenario 3: On-Premise Application Proxy Deployment . . . . . 6 + 6. Scenario 4: Distributed Proxy Deployment . . . . . . . . . . 7 + 7. Scenario 5: Overlay Network . . . . . . . . . . . . . . . . . 8 + 8. Scenario 6: Policy and Charging Control Architecture (PCC) . 10 + 9. Scenario 7: Emergency Calls . . . . . . . . . . . . . . . . . 12 + 10. Other Deployment Scenarios . . . . . . . . . . . . . . . . . 13 + 10.1. Open WLAN or Provider WLAN . . . . . . . . . . . . . . . 13 + 10.2. Cellular Networks . . . . . . . . . . . . . . . . . . . 14 + 10.3. Femtocells . . . . . . . . . . . . . . . . . . . . . . . 14 + 10.4. Traffic Detection Function (TDF) . . . . . . . . . . . . 17 + 10.5. Fixed and Mobile Network Convergence . . . . . . . . . . 18 + 11. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 14. Informative References . . . . . . . . . . . . . . . . . . . 22 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + + + + + + + + + + + + + + + +Boucadair, et al. Informational [Page 2] + +RFC 7620 Host Identification: Scenarios August 2015 + + +1. Introduction + + The goal of this document is to enumerate scenarios that encounter + the issue of uniquely identifying a host among those sharing the same + IP address. Within this document, a host can be any device directly + connected to a network operated by a network provider, a Home + Gateway, or a roaming device located behind a Home Gateway. + + An exhaustive list of encountered issues for the Carrier-Grade NAT + (CGN), Address plus Port (A+P), and application proxies scenarios are + documented in [RFC6269]. In addition to those issues, some of the + scenarios described in this document suffer from additional issues + such as: + + o Identifying which policy to enforce for a host (e.g., limit access + to the service based on some counters such as volume-based service + offerings); enforcing the policy will have an impact on all hosts + sharing the same IP address. + o Needing to correlate between the internal address:port and + external address:port to generate and therefore enforce policies. + o Querying a location server for the location of an emergency caller + based on the source IP address. + + The goal of this document is to identify scenarios the authors are + aware of and that share the same complications in identifying which + policy to apply for a host. This problem is abstracted as the host + identification problem. + + The analysis of the scenarios listed in this document indicates + several root causes for the host identification issue: + + 1. Presence of address sharing (CGN, A+P, application proxies, + etc.). + 2. Use of tunnels between two administrative domains. + 3. Combination of address sharing and presence of tunnels in the + path. + + Even if these scenarios share the same root causes, describing the + scenario allows to identify what is common between the scenarios, and + then this information would help during the solution design phase. + +2. Scope + + This document can be used as a tool to design a solution(s) that + mitigates the encountered issues. Note, [RFC6967] focuses only on + the CGN, A+P, and application proxies cases. The analysis in + [RFC6967] may not be accurate for some of the scenarios that do not + span multiple administrative domains (e.g., Section 10.1). + + + +Boucadair, et al. Informational [Page 3] + +RFC 7620 Host Identification: Scenarios August 2015 + + + This document does not target means that would lead to exposing a + host beyond what the original packet, issued from that host, would + have already exposed. Such means are not desirable nor required to + solve the issues encountered in the scenarios discussed in this + document. The focus is exclusively on means to restore the + information conveyed in the original packet issued by a given host. + These means are intended to help in identifying which policy to apply + for a given flow. These means may rely on some bits of the source IP + address and/or port number(s) used by the host to issue packets. + + To prevent side effects and misuses of such means on privacy, a + solution specification document(s) should explain, in addition to + what is already documented in [RFC6967], the following: + + o To what extent the solution can be used to nullify the effect of + using address sharing to preserve privacy (see, for example, + [EFFOpenWireless]). Note, this concern can be mitigated if the + address-sharing platform is under the responsibility of the host's + owner and the host does not leak information that would interfere + with the host's privacy protection tool. + + o To what extent the solution can be used to expose privacy + information beyond what the original packet would have already + exposed. Note, the solutions discussed in [RFC6967] do not allow + extra information to be revealed other than what is conveyed in + the original packet. + + This document covers both IPv4 and IPv6. + + This document does not include any solution-specific discussions. In + particular, the document does not elaborate whether explicit + authentication is enabled or not. + + This document does not discuss whether specific information is needed + to be leaked in packets, whether this is achieved out of band, etc. + Those considerations are out of scope. + +3. Scenario 1: Carrier-Grade NAT (CGN) + + Several flavors of stateful CGN have been defined. A non-exhaustive + list is provided below: + + 1. IPv4-to-IPv4 NAT (NAT44) [RFC6888] [STATELESS-NAT44] + + 2. DS-Lite NAT44 [RFC6333] + + 3. Network Address and Protocol Translation from IPv6 Clients to + IPv4 Servers (NAT64) [RFC6146] + + + +Boucadair, et al. Informational [Page 4] + +RFC 7620 Host Identification: Scenarios August 2015 + + + 4. IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] + + As discussed in [RFC6967], remote servers are not able to distinguish + between hosts sharing the same IP address (Figure 1). As a reminder, + remote servers rely on the source IP address for various purposes + such as access control or abuse management. The loss of the host + identification will lead to issues discussed in [RFC6269]. + + +-----------+ + | HOST_1 |----+ + +-----------+ | +--------------------+ +------------+ + | | |------| Server 1 | + +-----------+ +-----+ | | +------------+ + | HOST_2 |--| CGN |----| INTERNET | :: + +-----------+ +-----+ | | +------------+ + | | |------| Server n | + +-----------+ | +--------------------+ +------------+ + | HOST_3 |-----+ + +-----------+ + + Figure 1: CGN Reference Architecture + + Some of the above-referenced CGN scenarios will be satisfied by + eventual completion of the transition to IPv6 across the Internet + (e.g., NAT64), but this is not true of all CGN scenarios (e.g., NPTv6 + [RFC6296]) for which some of the issues discussed in [RFC6269] will + be encountered (e.g., impact on geolocation). + + Privacy-related considerations discussed in [RFC6967] apply for this + scenario. + +4. Scenario 2: Address plus Port (A+P) + + A+P [RFC6346] [RFC7596] [RFC7597] denotes a flavor of address-sharing + solutions that does not require any additional NAT function to be + enabled in the service provider's network. A+P assumes subscribers + are assigned with the same IPv4 address together with a port set. + Subscribers assigned with the same IPv4 address should be assigned + non-overlapping port sets. Devices connected to an A+P-enabled + network should be able to restrict the IPv4 source port to be within + a configured range of ports. To forward incoming packets to the + appropriate host, a dedicated entity called the Port-Range Router + (PRR) [RFC6346] is needed (Figure 2). + + Similar to the CGN case, remote servers rely on the source IP address + for various purposes such as access control or abuse management. The + loss of the host identification will lead to the issues discussed in + + + + +Boucadair, et al. Informational [Page 5] + +RFC 7620 Host Identification: Scenarios August 2015 + + + [RFC6269]. In particular, it will be impossible to identify hosts + sharing the same IP address by remote servers. + + +-----------+ + | HOST_1 |----+ + +-----------+ | +--------------------+ +------------+ + | | |------| Server 1 | + +-----------+ +-----+ | | +------------+ + | HOST_2 |--| PRR |----| INTERNET | :: + +-----------+ +-----+ | | +------------+ + | | |------| Server n | + +-----------+ | +--------------------+ +------------+ + | HOST_3 |-----+ + +-----------+ + + Figure 2: A+P Reference Architecture + + Privacy-related considerations discussed in [RFC6967] apply for this + scenario. + +5. Scenario 3: On-Premise Application Proxy Deployment + + This scenario is similar to the CGN scenario (Section 3). + + Remote servers are not able to distinguish hosts located behind the + proxy. Applying policies on the perceived external IP address as + received from the proxy will impact all hosts connected to that + proxy. + + Figure 3 illustrates a simple configuration involving a proxy. Note + several (per-application) proxies may be deployed. This scenario is + a typical deployment approach used within enterprise networks. + + +-----------+ + | HOST_1 |----+ + +-----------+ | +--------------------+ +------------+ + | | |------| Server 1 | + +-----------+ +-----+ | | +------------+ + | HOST_2 |--|Proxy|----| INTERNET | :: + +-----------+ +-----+ | | +------------+ + | | |------| Server n | + +-----------+ | +--------------------+ +------------+ + | HOST_3 |-----+ + +-----------+ + + Figure 3: Proxy Reference Architecture + + + + + +Boucadair, et al. Informational [Page 6] + +RFC 7620 Host Identification: Scenarios August 2015 + + + The administrator of the proxy may have many reasons for wanting to + proxy traffic - including caching, policy enforcement, malware + scanning, reporting on network or user behavior for compliance, or + security monitoring. + + The same administrator may also wish to selectively hide or expose + the internal host identity to servers. He/she may wish to hide the + identity to protect end-user privacy or to reduce the ability of a + rogue agent to learn the internal structure of the network. He/she + may wish to allow upstream servers to identify hosts to enforce + access policies (for example, on documents or online databases), to + enable account identification (on subscription-based services) or to + prevent spurious misidentification of high-traffic patterns as a DoS + attack. Application-specific protocols exist for enabling such + forwarding on some plaintext protocols (e.g., Forwarded headers on + HTTP [RFC7239] or time-stamp-line headers in SMTP [RFC5321]). + + Servers not receiving such notifications but wishing to perform host + or user-specific processing are obliged to use other application- + specific means of identification (e.g., cookies [RFC6265]). + + Packets/connections must be received by the proxy regardless of the + IP address family in use. The requirements of this scenario are not + satisfied by eventual completion of the transition to IPv6 across the + Internet. Complications will arise for both IPv4 and IPv6. + + Privacy-related considerations discussed in [RFC6967] apply for this + scenario. + +6. Scenario 4: Distributed Proxy Deployment + + This scenario is similar to the proxy deployment scenario (Section 5) + with the same use cases. However, in this instance part of the + functionality of the application proxy is located in a remote site. + This may be desirable to reduce infrastructure and administration + costs or because the hosts in question are mobile or roaming hosts + tied to a particular administrative zone of control but not to a + particular network. + + In some cases, a distributed proxy is required to identify a host on + whose behalf it is performing the caching, filtering, or other + desired service - for example, to know which policies to enforce. + Typically, IP addresses are used as a surrogate. However, in the + presence of CGN, this identification becomes difficult. Alternative + solutions include the use of cookies, which only work for HTTP + traffic, tunnels, or proprietary extensions to existing protocols. + + + + + +Boucadair, et al. Informational [Page 7] + +RFC 7620 Host Identification: Scenarios August 2015 + + + +-----------+ +----------+ + | HOST_1 |-------------| | + +-----------+ | | +-------+ +----------+ + | | | |----| Server 1 | + +-----------+ | | | | +----------+ + | HOST_2 |----+ | INTERNET |---| Proxy | :: + +-----------+ +-----+ | | | | +----------+ + |Proxy|----| | | |----| Server n | + +-----------+ +-----+ | | +-------+ +----------+ + | HOST_3 |----+ +----------+ + +-----------+ + + Figure 4: Distributed Proxy Reference Architecture (1) + + +-----------+ +---+ +---+ +----------+ + | HOST_1 +---------+ I | | I +--+ Server 1 | + +-----------+ | N | +---+ | N | +----------+ + | T | | P | | T | + +-----------+ +---+ | E | | r | | E | +----------+ + | HOST_2 +--+ P | | R +--+ o +--+ R +--+ Server 2 | + +-----------+ | r | | N | | x | | N | +----------+ + | o |--+ E | | y | | E | :: + +-----------+ | x | | T | +---+ | T | +----------+ + | HOST_3 +--+ y | | | | +--+ Server N | + +-----------+ +---+ +---+ +---+ +----------+ + + Figure 5: Distributed Proxy Reference Architecture (2) + + Packets/connections must be received by the proxy regardless of the + IP address family in use. The requirements of this scenario are not + satisfied by eventual completion of the transition to IPv6 across the + Internet. Complications will arise for both IPv4 and IPv6. + + If the proxy and the servers are under the responsibility of the same + administrative entity (Figure 4), no privacy concerns are raised. + Nevertheless, privacy-related considerations discussed in [RFC6967] + apply if the proxy and the servers are not managed by the same + administrative entity (Figure 5). + +7. Scenario 5: Overlay Network + + An overlay network is a network of machines distributed throughout + multiple autonomous systems within the public Internet that can be + used to improve the performance of data transport (see Figure 6). IP + packets from the sender are delivered first to one of the machines + that make up the overlay network. That machine then relays the IP + + + + + +Boucadair, et al. Informational [Page 8] + +RFC 7620 Host Identification: Scenarios August 2015 + + + packets to the receiver via one or more machines in the overlay + network, applying various performance enhancement methods. + + +------------------------------------+ + | | + | INTERNET | + | | + +-----------+ | +------------+ | + | HOST_1 |-----| OVRLY_IN_1 |-----------+ | + +-----------+ | +------------+ | | + | | | + +-----------+ | +------------+ +-----------+ | +--------+ + | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| Server | + +-----------+ | +------------+ +-----------+ | +--------+ + | | | + +-----------+ | +------------+ | | + | HOST_3 |-----| OVRLY_IN_3 |-----------+ | + +-----------+ | +------------+ | + | | + +------------------------------------+ + + Figure 6: Overlay Network Reference Architecture + + Such overlay networks are used to improve the performance of content + delivery [IEEE1344002]. Overlay networks are also used for + peer-to-peer data transport [RFC5694], and they have been suggested + for use in both improved scalability for the Internet routing + infrastructure [RFC6179] and provisioning of security services + (intrusion detection, anti-virus software, etc.) over the public + Internet [IEEE101109]. + + In order for an overlay network to intercept packets and/or + connections transparently via base Internet connectivity + infrastructure, the overlay ingress and egress hosts (OVERLAY_IN and + OVERLAY_OUT) must be reliably in path in both directions between the + connection-initiating HOST and the SERVER. When this is not the + case, packets may be routed around the overlay and sent directly to + the receiving host, presumably without invoking some of the advanced + service functions offered by the overlay. + + For public overlay networks, where the ingress and/or egress hosts + are on the public Internet, packet interception commonly uses network + address translation for the source (SNAT) or destination (DNAT) + addresses in such a way that the public IP addresses of the true + endpoint hosts involved in the data transport are invisible to each + other (see Figure 7). For example, the actual sender and receiver + may use two completely different pairs of source and destination + addresses to identify the connection on the sending and receiving + + + +Boucadair, et al. Informational [Page 9] + +RFC 7620 Host Identification: Scenarios August 2015 + + + networks in cases where both the ingress and egress hosts are on the + public Internet. + + IP hdr contains: IP hdr contains: + SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER + dst = overlay1 dst = receiver + + Figure 7: NAT Operations in an Overlay Network + + In this scenario, the remote server is not able to distinguish among + hosts using the overlay for transport. In addition, the remote + server is not able to determine the overlay ingress point being used + by the host, which can be useful for diagnosing host connectivity + issues. + + In some of the above-referenced scenarios, IP packets traverse the + overlay network fundamentally unchanged, with the overlay network + functioning much like a CGN (Section 3). In other cases, connection- + oriented data flows (e.g., TCP) are terminated by the overlay in + order to perform object caching and other such transport and + application-layer optimizations, similar to the proxy scenario + (Section 5). In both cases, address sharing is a requirement for + packet/connection interception, which means that the requirements for + this scenario are not satisfied by the eventual completion of the + transition to IPv6 across the Internet. + + More details about this scenario are provided in [OVERLAYPATH]. + + This scenario does not introduce privacy concerns since the + identification of the host is local to a single administrative domain + (i.e., Content Delivery Network (CDN) Overlay Network) or passed to a + remote server to help forwarding back the response to the appropriate + host. The host identification information is not publicly available + nor can be disclosed to other hosts connected to the Internet. + +8. Scenario 6: Policy and Charging Control Architecture (PCC) + + This issue is related to the PCC framework defined by 3GPP in + [TS23.203] when a NAT is located between the Policy and Charging + Enforcement Function (PCEF) and the Application Function (AF) as + shown in Figure 8. + + The main issue is: PCEF, the Policy and Charging Rule Function + (PCRF), and AF all receive information bound to the same User + Equipment (UE) but without being able to correlate between the piece + of data visible for each entity. Concretely, + + + + + +Boucadair, et al. Informational [Page 10] + +RFC 7620 Host Identification: Scenarios August 2015 + + + o PCEF is aware of the International Mobile Subscriber Identity + (IMSI) and an internal IP address assigned to the UE. + + o AF receives an external IP address and port as assigned by the NAT + function. + + o PCRF is not able to correlate between the external IP address/port + assigned by the NAT (received from the AF) and the internal IP + address and IMSI of the UE (received from the PCEF). + + +------+ + | PCRF |-----------------+ + +------+ | + | | + +----+ +------+ +-----+ +-----+ + | UE |------| PCEF |---| NAT |----| AF | + +----+ +------+ +-----+ +-----+ + + Figure 8: NAT Located between AF and PCEF + + This scenario can be generalized as follows (Figure 9): + + o Policy Enforcement Point (PEP) [RFC2753] + + o Policy Decision Point (PDP) [RFC2753] + + +------+ + | PDP |-----------------+ + +------+ | + | | + +----+ +------+ +-----+ +------+ + | UE |------| PEP |---| NAT |----|Server| + +----+ +------+ +-----+ +------+ + + Figure 9: NAT Located between PEP and the Server + + Note that an issue is encountered to enforce per-UE policies when the + NAT is located before the PEP function (see Figure 10): + + +------+ + | PDP |------+ + +------+ | + | | + +----+ +------+ +-----+ +------+ + | UE |------| NAT |---| PEP |----|Server| + +----+ +------+ +-----+ +------+ + + Figure 10: NAT Located before PEP + + + +Boucadair, et al. Informational [Page 11] + +RFC 7620 Host Identification: Scenarios August 2015 + + + This scenario does not introduce privacy concerns since the + identification of the host is local to a single administrative domain + and is meant to help identify which policy to select for a UE. + +9. Scenario 7: Emergency Calls + + Voice Service Providers (VSPs) operating under certain jurisdictions + are required to route emergency calls from their subscribers and have + to include information about the caller's location in signaling + messages they send towards Public Safety Answering Points (PSAPs) + [RFC6443] via an Emergency Service Routing Proxy (ESRP) [RFC6443]. + This information is used both for the determination of the correct + PSAP and to reveal the caller's location to the selected PSAP. + + In many countries, regulation bodies require that this information be + provided by the network rather than the user equipment, in which case + the VSP needs to retrieve this information (by reference or by value) + from the access network where the caller is attached. + + This requires the VSP call server receiving an emergency call request + to identify the relevant access network and to query a Location + Information Server (LIS) in this network using a suitable lookup key. + In the simplest case, the source IP address of the IP packet carrying + the call request is used both for identifying the access network + (thanks to a reverse DNS query) and as a lookup key to query the LIS. + Obviously, the user-id as known by the VSP (e.g., telephone number or + email-formatted URI) can't be used as it is not known by the access + network. + + The above mechanism is broken when there is a NAT between the user + and the VSP and/or if the emergency call is established over a VPN + tunnel (e.g., an employee remotely connected to a company Voice over + IP (VoIP) server through a tunnel wishes to make an emergency call). + In such cases, the source IP address received by the VSP call server + will identify the NAT or the address assigned to the caller equipment + by the VSP (i.e., the address inside the tunnel). This is similar to + the CGN case in (Section 3) and overlay network case (Section 7) and + applies irrespective of the IP versions used on both sides of the NAT + and/or inside and outside the tunnel. + + Therefore, the VSP needs to receive an additional piece of + information that can be used to both identify the access network + where the caller is attached and query the LIS for his/her location. + This would require the NAT or the tunnel endpoint to insert this + extra information in the call requests delivered to the VSP call + servers. For example, this extra information could be a combination + of the local IP address assigned by the access network to the + + + + +Boucadair, et al. Informational [Page 12] + +RFC 7620 Host Identification: Scenarios August 2015 + + + caller's equipment with some form of identification of this access + network. + + However, because it shall be possible to set up an emergency call + regardless of the actual call control protocol used between the user + and the VSP (e.g., SIP [RFC3261], Inter-Asterisk eXchange (IAX) + [RFC5456], tunneled over HTTP, or proprietary protocol, possibly + encrypted), this extra information has to be conveyed outside the + call request, in the header of lower-layer protocols. + + Privacy-related considerations discussed in [RFC6967] apply for this + scenario. + +10. Other Deployment Scenarios + + This section lists deployment scenarios that are variants of + scenarios described in previous sections. + +10.1. Open WLAN or Provider WLAN + + In the context of Provider WLAN, a dedicated Service Set Identifier + (SSID) can be configured and advertised by the Residential Gateway + (RG) for visiting terminals. These visiting terminals can be mobile + terminals, PCs, etc. + + Several deployment scenarios are envisaged: + + 1. Deploy a dedicated node in the service provider's network that + will be responsible for intercepting all the traffic issued from + visiting terminals (see Figure 11). This node may be co-located + with a CGN function if private IPv4 addresses are assigned to + visiting terminals. Similar to the CGN case discussed in + Section 3, remote servers may not be able to distinguish visiting + hosts sharing the same IP address (see [RFC6269]). + + 2. Unlike the previous deployment scenario, IPv4 addresses are + managed by the RG without requiring any additional NAT to be + deployed in the service provider's network for handling traffic + issued from visiting terminals. Concretely, a visiting terminal + is assigned with a private IPv4 address from the IPv4 address + pool managed by the RG. Packets issued from a visiting terminal + are translated using the public IP address assigned to the RG + (see Figure 12). This deployment scenario induces the following + identification concerns: + + + + + + + +Boucadair, et al. Informational [Page 13] + +RFC 7620 Host Identification: Scenarios August 2015 + + + * The provider is not able to distinguish the traffic belonging + to the visiting terminal from the traffic of the subscriber + owning the RG. This is needed to identify which policies are + to be enforced such as: accounting, Differentiated Services + Code Point (DSCP) remarking, black list, etc. + + * Similar to the CGN case Section 3, a misbehaving visiting + terminal is likely to have some impact on the experienced + service by the subscriber owning the RG (e.g., some of the + issues are discussed in [RFC6269]). + + +-------------+ + |Local_HOST_1 |----+ + +-------------+ | + | | + +-------------+ +-----+ | +-----------+ + |Local_HOST_2 |--| RG |-|--|Border Node| + +-------------+ +-----+ | +----NAT----+ + | | + +-------------+ | | Service Provider + |Visiting Host|-----+ + +-------------+ + + Figure 11: NAT Enforced in a Service Provider's Node + + +-------------+ + |Local_HOST_1 |----+ + +-------------+ | + | | + +-------------+ +-----+ | +-----------+ + |Local_HOST_2 |--| RG |-|--|Border Node| + +-------------+ +-NAT-+ | +-----------+ + | | + +-------------+ | | Service Provider + |Visiting Host|-----+ + +-------------+ + + Figure 12: NAT Located in the RG + + This scenario does not introduce privacy concerns since the + identification of the host is local to a single administrative domain + and is meant to help identify which policy to select for a visiting + UE. + + + + + + + + +Boucadair, et al. Informational [Page 14] + +RFC 7620 Host Identification: Scenarios August 2015 + + +10.2. Cellular Networks + + Cellular operators allocate private IPv4 addresses to mobile + terminals and deploy NAT44 function, generally co-located with + firewalls, to access public IP services. The NAT function is located + at the boundaries of the Public Land Mobile Network (PLMN). + IPv6-only strategy, consisting in allocating IPv6 prefixes only to + mobile terminals, is considered by various operators. A NAT64 + function is also considered in order to preserve IPv4 service + continuity for these customers. + + These NAT44 and NAT64 functions bring some issues that are very + similar to those mentioned in Figure 1 and Section 8. These issues + are particularly encountered if policies are to be applied on the Gi + interface. + + Note: 3GPP defines the Gi interface as the reference point between + the Gateway GPRS Support Node (GGSN) and an external Packet Domain + Network (PDN). This interface reference point is called SGi in 4G + networks (i.e., between the PDN Gateway and an external PDN). + + Because private IP addresses are assigned to the mobile terminals, + there is no correlation between the internal IP address and the + external address:port assigned by the NAT function, etc. + + Privacy-related considerations discussed in [RFC6967] apply for this + scenario. + +10.3. Femtocells + + This scenario can be seen as a combination of the scenarios described + in Sections 8 and 10.1. + + The reference architecture is shown in Figure 13. + + A Femto Access Point (FAP) is defined as a home base station used to + graft a local (femto) cell within a user's home to a mobile network. + + + + + + + + + + + + + + +Boucadair, et al. Informational [Page 15] + +RFC 7620 Host Identification: Scenarios August 2015 + + + +---------------------------+ + | +----+ +--------+ +----+ | +-----------+ +-------------------+ + | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | + | +----+ | Alone | | RG | | | | | | | | | Mobile | + | | FAP | +----+ | | | | |S | |F | Network| + | +--------+ (NAPT) | | Broadband | | |e | |A | | + +---------------------------+ | Fixed | | |G |-|P | +-----+| + | (BBF) | | |W | |G |-| Core|| + +---------------------------+ | Network | | | | |W | | Ntwk|| + | +----+ +------------+ | | | | | | | | +-----+| + | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | + | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ + | +------------+ | + +---------------------------+ + + <=====> IPsec Tunnel + CoreNtwk Core Network + FAPGW FAP Gateway + NAPT Network Address Port Translator + SeGW Security Gateway + + Figure 13: Femtocell Reference Architecture + + UE is connected to the FAP at the RG, which is routed back to the + 3GPP Evolved Packet Core (EPC). It is assumed that each UE is + assigned an IPv4 address by the mobile network. A mobile operator's + FAP leverages the IPsec Internet Key Exchange Protocol Version 2 + (IKEv2) to interconnect FAP with the SeGW over the Broadband Fixed + (BBF) network. Both the FAP and the SeGW are managed by the mobile + operator, which may be a different operator for the BBF network. + + An investigated scenario is when the mobile operator passes on its + mobile subscriber's policies to the BBF to support traffic policy + control. But most of today's broadband fixed networks are relying on + the private IPv4 addressing plan (+NAPT) to support its attached + devices, including the mobile operator's FAP. In this scenario, the + mobile network needs to: + + o determine the FAP's public IPv4 address to identify the location + of the FAP to ensure its legitimacy to operate on the license + spectrum for a given mobile operator prior to the FAP being ready + to serve its mobile devices. + + o determine the FAP's public IPv4 address together with the + translated port number of the UDP header of the encapsulated IPsec + tunnel for identifying the UE's traffic at the fixed broadband + network. + + + + +Boucadair, et al. Informational [Page 16] + +RFC 7620 Host Identification: Scenarios August 2015 + + + o determine the corresponding FAP's public IPv4 address associated + with the UE's inner IPv4 address that is assigned by the mobile + network to identify the mobile UE, which allows the PCRF to + retrieve the special UE's policy (e.g., QoS) to be passed onto the + Broadband Policy Control Function (BPCF) at the BBF network. + + SeGW would have the complete knowledge of such mapping, but the + reasons for being unable to use SeGW for this purpose are explained + in Section 2 of [IKEv2-CP-EXT]. + + This scenario involves PCRF/BPCF, but it is valid in other deployment + scenarios making use of Authentication, Authorization, and Accounting + (AAA) servers. + + The issue of correlating the internal IP address and the public IP + address is valid even if there is no NAT in the path. + + This scenario does not introduce privacy concerns since the + identification of the host is local to a single administrative domain + and is meant to help identify which policy to select for a UE. + +10.4. Traffic Detection Function (TDF) + + Operators expect that the traffic subject to the packet inspection is + routed via the Traffic Detection Function (TDF) as per the + requirement specified in [TS29.212]; otherwise, the traffic may + bypass the TDF. This assumption only holds if it is possible to + identify individual UEs behind the Basic NAT or NAPT invoked in the + RG connected to the fixed broadband network, as shown in Figure 14. + As a result, additional mechanisms are needed to enable this + requirement. + + + + + + + + + + + + + + + + + + + + +Boucadair, et al. Informational [Page 17] + +RFC 7620 Host Identification: Scenarios August 2015 + + + +--------+ + | | + +-------+ PCRF | + | | | + | +--------+ + +--------+ +--------+ +--------+ +----+----+ + | | | | | +-----+ | + | ------------------------------------------------------------------ + | | | | | | | TDF | / \ + | ****************************************************************** | + +--------+ +--------+ +--------+ +----+----+ | | + | | | +-------+ | | |Service| + | | | | | | | \ / + | | | | | | | +--------+ + | | | | | | +--------+ PDN | + | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | + | UE | | RG | | BNG +------------------+ Gateway| + +--------+ +--------+ +--------+ +--------+ + + Legend: + --------- 3GPP UE User-Plane Traffic Offloaded subject to packet + inspection + + ********* 3GPP UE User-Plane Traffic Offloaded not subject to packet + inspection + + >>>>>>>>> 3GPP UE User-Plane Traffic Home Routed + + BNG Broadband Network Gateway + + Figure 14: UE's Traffic Routed with TDF + + This scenario does not introduce privacy concerns since the + identification of the host is local to a single administrative domain + and is meant to help identify which policy to select for a UE. + +10.5. Fixed and Mobile Network Convergence + + In the Policy for Convergence of Fixed Mobile Convergence (FMC) + scenario, the fixed broadband network must partner with the mobile + network to acquire the policies for the terminals or hosts attaching + to the fixed broadband network, shown in Figure 15, so that host- + specific QoS and accounting policies can be applied. + + A UE is connected to the RG, which is routed back to the mobile + network. The mobile operator's PCRF needs to maintain the + interconnect with the BPCF in the BBF network for PCC (Section 8). + The hosts (i.e., UEs) attaching to a fixed broadband network with a + + + +Boucadair, et al. Informational [Page 18] + +RFC 7620 Host Identification: Scenarios August 2015 + + + Basic NAT or NAPT deployed should be identified. Based on the UE + identification, the BPCF can acquire the associated policy rules of + the identified UE from the PCRF in the mobile network so that it can + enforce policy rules in the fixed broadband network. Note, this + scenario assumes private IPv4 addresses are assigned in the fixed + broadband network. Requirements similar to those in Section 10.3 are + raised in this scenario. + + +------------------------------+ +-------------+ + | | | | + | +------+ | | +------+ | + | | BPCF +---+---+-+ PCRF | | + | +--+---+ | | +---+--+ | + +-------+ | | | | | | + |HOST_1 | Private IP1 +--+---+ | | +---+--+ | + +-------+ | +----+ | | | | | | | + | | RG | | | | | | | | + | |with+-------------+ BNG +--------+ PGW | | + +-------+ | | NAT| | | | | | | | + |HOST_2 | | +----+ | | | | | | | + +-------+ Private IP2 +------+ | | +------+ | + | | | | + | | | | + | Fixed | | Mobile | + | Broadband | | Network | + | Network | | | + | | | | + +------------------------------+ +-------------+ + + Figure 15: Reference Architecture for Policy for Convergence in Fixed + and Mobile Network Convergence (1) + + In an IPv6 network, similar issues exist when the IPv6 prefix is + shared between multiple UEs attaching to the RG (see Figure 16). The + case applies when RG is assigned a single prefix, the home network + prefix, e.g., using DHCPv6 Prefix Delegation [RFC3633] with the edge + router, and BNG acts as the Delegating Router (DR). RG uses the home + network prefix in the address configuration using stateful (DHCPv6) + or stateless address autoconfiguration (SLAAC) techniques. + + + + + + + + + + + + +Boucadair, et al. Informational [Page 19] + +RFC 7620 Host Identification: Scenarios August 2015 + + + +------------------------------+ +-------------+ + | | | | + | | | +------+ | + | +-------------+ PCRF | | + | | | | +---+--+ | + +-------+ | | | | | | + |HOST_1 |--+ +--+---+ | | +---+--+ | + +-------+ | +----+ | | | | | | | + | | RG | | | | | | | | + | | +------------+ BNG +---------+ PGW | | + +-------+ | | | | | | | | | | + |HOST_2 |--+ +----+ | | | | | | | + +-------+ | +------+ | | +------+ | + | | | | + | | | | + | Fixed | | Mobile | + | Broadband | | Network | + | Network | | | + | | | | + +------------------------------+ +-------------+ + + Figure 16: Reference Architecture for Policy for Convergence in Fixed + and Mobile Network Convergence (2) + + BNG acting as PCEF initiates an IP Connectivity Access Network + (IP-CAN) session with the policy server, a.k.a. Policy and Charging + Rules Function (PCRF), to receive the Quality of Service (QoS) + parameters and charging rules. BNG provides the PCRF with the IPv6 + prefix assigned to the host; in this case, it's the home network + prefix and an ID that has to be equal to the RG-specific home network + line ID. + + HOST_1 in Figure 16 creates a 128-bit IPv6 address using this prefix + and adding its interface ID. Having completed the address + configuration, the host can start communication with a remote host + over the Internet. However, no specific IP-CAN session can be + assigned to HOST_1, and consequently the QoS and accounting performed + will be based on RG subscription. + + Another host, e.g., HOST_2, attaches to the RG and also establishes + an IPv6 address using the home network prefix. The edge router, or + BNG, is not involved with this or any other such address assignments. + + This leads to the case where no specific IP-CAN session/sub-session + can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently + the QoS and accounting performed can only be based on RG subscription + and is not host specific. Therefore, IPv6 prefix sharing in the + Policy for Convergence scenario leads to similar issues as the + + + +Boucadair, et al. Informational [Page 20] + +RFC 7620 Host Identification: Scenarios August 2015 + + + address sharing as explained in the previous scenarios in this + document. + +11. Synthesis + + The following table shows whether each scenario is valid for IPv4/ + IPv6 and if it is within one single administrative domain or spans + multiple domains. The table also identifies the root cause of the + identification issues. + + The IPv6 column indicates for each scenario whether IPv6 is supported + at the client's side and/or server's side. + + +-------------------+----+-------------+------+-----------------+ + | | | IPv6 |Single| Root Cause | + | Scenario | |------+------|Domain+-------+---------+ + | |IPv4|Client|Server| |Address|Tunneling| + | | | | | |sharing| | + +-------------------+----+------+------+------+-------+---------+ + | CGN |Yes |Yes(1)| No | No | Yes | No | + | A+P |Yes | No | No | No | Yes | No | + | Application Proxy |Yes | Yes | Yes | No | Yes | No | + | Distributed Proxy |Yes | Yes | Yes |Yes/No| Yes | No | + | Overlay Networks |Yes |Yes(2)|Yes(2)| No | Yes | No | + | PCC |Yes |Yes(1)| No | Yes | Yes | No | + | Emergency Calls |Yes | Yes | Yes | No | Yes | No | + | Provider WLAN |Yes | No | No | Yes | Yes | No | + | Cellular Networks |Yes |Yes(1)| No | Yes | Yes | No | + | Femtocells |Yes | No | No | No | Yes | Yes | + | TDF |Yes | Yes | No | Yes | Yes | No | + | FMC |Yes |Yes(1)| No | No | Yes | No | + +-------------------+----+------+------+------+-------+---------+ + + Notes: + (1) For example, NAT64 + (2) This scenario is a combination of CGN and application proxies + + Table 1: Synthesis + +12. Privacy Considerations + + Privacy-related considerations that apply to means to reveal a host + identifier are discussed in [RFC6967]. This document does not + introduce additional privacy issues than those discussed in + [RFC6967]. + + None of the scenarios inventoried in this document aim at revealing a + customer identifier, account identifier, profile identifier, etc. + + + +Boucadair, et al. Informational [Page 21] + +RFC 7620 Host Identification: Scenarios August 2015 + + + Particularly, none of these scenarios are endorsing the functionality + provided by the following proprietary headers (but not limited to) + that are known to be used to leak subscription-related information: + HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID, + HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID, + HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, + HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, + HTTP_X_NETWORK_INFO, etc. + +13. Security Considerations + + This document does not define an architecture nor a protocol; as such + it does not raise any security concerns. Security considerations + that are related to the host identifier are discussed in [RFC6967]. + +14. Informative References + + [BCP160] Barnes, R., Lepinski, M., Cooper, A., Morris, J., + Tschofenig, H., and H. Schulzrinne, "An Architecture for + Location and Location Privacy in Internet Applications", + BCP 160, RFC 6280, July 2011. + + [BCP188] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, May 2014. + + [EFFOpenWireless] + EFF, "Open Wireless", 2014, <https://www.eff.org/issues/ + open-wireless>. + + [IEEE101109] + Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. + ZAaabi, "Using Cloud Computing to Implement a Security + Overlay Network", IEEE Computer Society Digital Library, + IEEE Security & Privacy, Vol. 11, Issue 1, pp. 44-53, + DOI 10.1109/MSP.2012.88, Jan-Feb 2013. + + [IEEE1344002] + Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, + "Informed content delivery across adaptive overlay + networks", IEEE/ACM Transactions on Networking, Vol. 12, + Issue 5, pp. 767-780, DOI 10.1109/TNET.2004.836103, + October 2004. + + [IKEv2-CP-EXT] + So, T., "IKEv2 Configuration Payload Extension for Private + IPv4 Support for Fixed Mobile Convergence", Work in + Progress, draft-so-ipsecme-ikev2-cpext-02, June 2012. + + + + +Boucadair, et al. Informational [Page 22] + +RFC 7620 Host Identification: Scenarios August 2015 + + + [OVERLAYPATH] + Williams, B., "Overlay Path Option for IP and TCP", Work + in Progress, draft-williams-overlaypath-ip-tcp-rfc-04, + June 2013. + + [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework + for Policy-based Admission Control", RFC 2753, + DOI 10.17487/RFC2753, January 2000, + <http://www.rfc-editor.org/info/rfc2753>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + DOI 10.17487/RFC3633, December 2003, + <http://www.rfc-editor.org/info/rfc3633>. + + [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report + from the IAB Workshop on Routing and Addressing", + RFC 4984, DOI 10.17487/RFC4984, September 2007, + <http://www.rfc-editor.org/info/rfc4984>. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <http://www.rfc-editor.org/info/rfc5321>. + + [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. + Shumard, "IAX: Inter-Asterisk eXchange Version 2", + RFC 5456, DOI 10.17487/RFC5456, February 2010, + <http://www.rfc-editor.org/info/rfc5456>. + + [RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) + Architecture: Definition, Taxonomies, Examples, and + Applicability", RFC 5694, DOI 10.17487/RFC5694, November + 2009, <http://www.rfc-editor.org/info/rfc5694>. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, <http://www.rfc-editor.org/info/rfc6146>. + + [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network + (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, + <http://www.rfc-editor.org/info/rfc6179>. + + + +Boucadair, et al. Informational [Page 23] + +RFC 7620 Host Identification: Scenarios August 2015 + + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + DOI 10.17487/RFC6265, April 2011, + <http://www.rfc-editor.org/info/rfc6265>. + + [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and + P. Roberts, "Issues with IP Address Sharing", RFC 6269, + DOI 10.17487/RFC6269, June 2011, + <http://www.rfc-editor.org/info/rfc6269>. + + [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix + Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, + <http://www.rfc-editor.org/info/rfc6296>. + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, + <http://www.rfc-editor.org/info/rfc6333>. + + [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to + the IPv4 Address Shortage", RFC 6346, + DOI 10.17487/RFC6346, August 2011, + <http://www.rfc-editor.org/info/rfc6346>. + + [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling Using Internet + Multimedia", RFC 6443, DOI 10.17487/RFC6443, December + 2011, <http://www.rfc-editor.org/info/rfc6443>. + + [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, + A., and H. Ashida, "Common Requirements for Carrier-Grade + NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, + April 2013, <http://www.rfc-editor.org/info/rfc6888>. + + [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, + "Analysis of Potential Solutions for Revealing a Host + Identifier (HOST_ID) in Shared Address Deployments", + RFC 6967, DOI 10.17487/RFC6967, June 2013, + <http://www.rfc-editor.org/info/rfc6967>. + + [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", + RFC 7239, DOI 10.17487/RFC7239, June 2014, + <http://www.rfc-editor.org/info/rfc7239>. + + [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. + Farrer, "Lightweight 4over6: An Extension to the Dual- + Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, + July 2015, <http://www.rfc-editor.org/info/rfc7596>. + + + + +Boucadair, et al. Informational [Page 24] + +RFC 7620 Host Identification: Scenarios August 2015 + + + [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., + Murakami, T., and T. Taylor, Ed., "Mapping of Address and + Port with Encapsulation (MAP-E)", RFC 7597, + DOI 10.17487/RFC7597, July 2015, + <http://www.rfc-editor.org/info/rfc7597>. + + [STATELESS-NAT44] + Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, + "Stateless IPv4 Network Address Translation", Work in + Progress, draft-tsou-stateless-nat44-02, October 2012. + + [TS23.203] 3GPP, "Policy and charging control architecture (Release + 11)", 3GPP TS23.203, September 2012. + + [TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points + (Release 11)", 3GPP TS29.212, December 2013. + +Acknowledgments + + Many thanks to F. Klamm, D. Wing, D. von Hugo, G. Li, D. Liu, and + Y. Lee for their review. + + J. Touch, S. Farrel, and S. Moonesamy provided useful comments in the + intarea mailing list. + + Figure 8 and part of the text in Section 10.3 were inspired by + [IKEv2-CP-EXT]. + +Contributors + + Many thanks to the following people for contributing text and + comments to the document: + + o David Binet + o Sophie Durel + o Li Xue + o Richard Stewart Wheeldon + + + + + + + + + + + + + + +Boucadair, et al. Informational [Page 25] + +RFC 7620 Host Identification: Scenarios August 2015 + + +Authors' Addresses + + Mohamed Boucadair (editor) + Orange + Rennes 35000 + France + + Email: mohamed.boucadair@orange.com + + + Bruno Chatras + Orange + Paris + France + + Email: bruno.chatras@orange.com + + + Tirumaleswar Reddy + Cisco Systems + Cessna Business Park, Varthur Hobli + Sarjapur Marathalli Outer Ring Road + Bangalore, Karnataka 560103 + India + + Email: tireddy@cisco.com + + + Brandon Williams + Akamai, Inc. + Cambridge MA + United States + + Email: brandon.williams@akamai.com + + + Behcet Sarikaya + Huawei + 5340 Legacy Dr. Building 3, + Plano, TX 75024 + United States + + Email: sarikaya@ieee.org + + + + + + + + +Boucadair, et al. Informational [Page 26] + |