draft-ietf-radext-ip-port-radius-ext-09.txt   draft-ietf-radext-ip-port-radius-ext-10.txt 
Network Working Group D. Cheng Network Working Group D. Cheng
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Korhonen Intended status: Standards Track J. Korhonen
Expires: September 18, 2016 Broadcom Corporation Expires: January 29, 2017 Broadcom Corporation
M. Boucadair M. Boucadair
Orange Orange
S. Sivakumar S. Sivakumar
Cisco Systems Cisco Systems
March 17, 2016 July 28, 2016
RADIUS Extensions for IP Port Configuration and Reporting RADIUS Extensions for IP Port Configuration and Reporting
draft-ietf-radext-ip-port-radius-ext-09 draft-ietf-radext-ip-port-radius-ext-10
Abstract Abstract
This document defines three new RADIUS attributes. For devices that This document defines three new RADIUS attributes. For devices that
implementing IP port ranges, these attributes are used to communicate implement IP port ranges, these attributes are used to communicate
with a RADIUS server in order to configure and report TCP/UDP ports with a RADIUS server in order to configure and report TCP/UDP ports
and ICMP identifiers, as well as mapping behavior for specific hosts. and ICMP identifiers, as well as mapping behavior for specific hosts.
This mechanism can be used in various deployment scenarios such as This mechanism can be used in various deployment scenarios such as
Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 18, 2016. This Internet-Draft will expire on January 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4. Applications, Use Cases and Examples . . . . . . . . . . . . 23 4. Applications, Use Cases and Examples . . . . . . . . . . . . 23
4.1. Managing CGN Port Behavior using RADIUS . . . . . . . . . 23 4.1. Managing CGN Port Behavior using RADIUS . . . . . . . . . 23
4.1.1. Configure IP Port Limit for a User . . . . . . . . . 24 4.1.1. Configure IP Port Limit for a User . . . . . . . . . 24
4.1.2. Report IP Port Allocation/Deallocation . . . . . . . 26 4.1.2. Report IP Port Allocation/Deallocation . . . . . . . 26
4.1.3. Configure Forwarding Port Mapping . . . . . . . . . . 27 4.1.3. Configure Forwarding Port Mapping . . . . . . . . . . 27
4.1.4. An Example . . . . . . . . . . . . . . . . . . . . . 29 4.1.4. An Example . . . . . . . . . . . . . . . . . . . . . 29
4.2. Report Assigned Port Set for a Visiting UE . . . . . . . 30 4.2. Report Assigned Port Set for a Visiting UE . . . . . . . 30
5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. IANA Considerations on New IPFIX Information Elements . . 32 7.1. IANA Considerations on New IPFIX Information Elements . . 33
7.2. IANA Considerations on New RADIUS Attributes . . . . . . 33 7.2. IANA Considerations on New RADIUS Attributes . . . . . . 33
7.3. IANA Considerations on New RADIUS TLVs . . . . . . . . . 33 7.3. IANA Considerations on New RADIUS TLVs . . . . . . . . . 34
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
In a broadband network, customer information is usually stored on a In a broadband network, customer information is usually stored on a
RADIUS server [RFC2865]. At the time when a user initiates an IP RADIUS server [RFC2865]. At the time when a user initiates an IP
connection request, if this request is authorized, the RADIUS server connection request, if this request is authorized, the RADIUS server
will populate the user's configuration information to the Network will populate the user's configuration information to the Network
Access Server (NAS), which is often referred to as a Broadband Access Server (NAS), which is often referred to as a Broadband
Network Gateway (BNG) in broadband access networks. The Carrier- Network Gateway (BNG) in broadband access networks. The Carrier-
skipping to change at page 5, line 19 skipping to change at page 5, line 19
o Internal Port: is a UDP or TCP port, or an ICMP identifier, which o Internal Port: is a UDP or TCP port, or an ICMP identifier, which
is allocated by a host or application behind a device supporting is allocated by a host or application behind a device supporting
port ranges for an outbound IP packet in the internal realm. port ranges for an outbound IP packet in the internal realm.
o External Port: is a UDP or TCP port, or an ICMP identifier, which o External Port: is a UDP or TCP port, or an ICMP identifier, which
is allocated by a device supporting port ranges upon receiving an is allocated by a device supporting port ranges upon receiving an
outbound IP packet in the internal realm, and is used to replace outbound IP packet in the internal realm, and is used to replace
the internal port that is allocated by a user or application. the internal port that is allocated by a user or application.
o External realm: refers to the networking segment where external IP o External realm: refers to the networking segment where external IP
addresses are used in respective of the device supporting port addresses are used as source addresses of outbound packets
ranges. forwarded by a device supporting port ranges.
o Internal realm: refers to the networking segment that is behind a o Internal realm: refers to the networking segment that is behind a
device supporting port ranges and where internal IP addresses are device supporting port ranges and where internal IP addresses are
used. used.
o Mapping: associates with a device supporting port ranges for a o Mapping: associates with a device supporting port ranges for a
relationship between an internal IP address, internal port and the relationship between an internal IP address, internal port and the
protocol, and an external IP address, external port, and the protocol, and an external IP address, external port, and the
protocol. protocol.
skipping to change at page 26, line 12 skipping to change at page 26, line 12
Figure 16: RADIUS Message Flow for changing a user's NAT44 port limit Figure 16: RADIUS Message Flow for changing a user's NAT44 port limit
4.1.2. Report IP Port Allocation/Deallocation 4.1.2. Report IP Port Allocation/Deallocation
Upon obtaining the IP port limit for a user, the CGN device needs to Upon obtaining the IP port limit for a user, the CGN device needs to
allocate a TCP/UDP port or an ICMP identifiers for the user when allocate a TCP/UDP port or an ICMP identifiers for the user when
receiving a new IP flow sent from that user. receiving a new IP flow sent from that user.
As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP
identifiers once at a time for a specific user, instead of one port/ identifiers one at a time for a specific user, instead of one port/
identifier at a time, and within each port bulk, the ports/ identifier at a time, and within each port bulk, the ports/
identifiers may be randomly distributed or in consecutive fashion. identifiers may be randomly distributed or in consecutive fashion.
When a CGN device allocates bulk of TCP/UDP ports and ICMP When a CGN device allocates bulk of TCP/UDP ports and ICMP
identifiers, the information can be easily conveyed to the RADIUS identifiers, the information can be easily conveyed to the RADIUS
server by a new RADIUS attribute called the IP-Port-Range (defined in server by a new RADIUS attribute called the IP-Port-Range (defined in
Section 3.1.2). The CGN device may allocate one or more TCP/UDP port Section 3.1.2). The CGN device may allocate one or more TCP/UDP port
ranges or ICMP identifier ranges, or generally called IP port ranges, ranges or ICMP identifier ranges, or generally called IP port ranges,
where each range contains a set of numbers representing TCP/UDP ports where each range contains a set of numbers representing TCP/UDP ports
or ICMP identifiers, and the total number of ports/identifiers must or ICMP identifiers, and the total number of ports/identifiers must
be less or equal to the associated IP port limit imposed for that be less or equal to the associated IP port limit imposed for that
skipping to change at page 32, line 22 skipping to change at page 32, line 22
0+ 0+ 0 0 0+ TBA IP-Port-Forwarding-Map 0+ 0+ 0 0 0+ TBA IP-Port-Forwarding-Map
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet. 0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet.
6. Security Considerations 6. Security Considerations
This document does not introduce any security issue other than the This document does not introduce any security issue other than the
ones already identified in RADIUS [RFC2865]. ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA
messages. Known RADIUS vulnerabilities apply to this specification.
For example, if RADIUS packets are sent in the clear, an attacker in
the communication path between the RADIUS client and server may glean
information that it will use to prevent a legitimate user to access
the service by appropriately setting the maximum number of IP ports
conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota
of a user by installing many mapping entries (IP-Port-Forwarding-Map
attribute), prevent incoming traffic to be delivered to its
legitimate destination by manipulating the mapping entries installed
by means of an IP-Port-Forwarding-Map attribute, discover the IP
address and port range assigned to a given user and which is reported
in an IP-Port-Range attribute, etc. The root cause of these attack
vectors is the communication between the RADIUS client and server.
This document targets deployed where a trusted relationship is in
place between the RADIUS client and server with communication
optionally secured by IPsec or Transport Layer Security (TLS)
[RFC6614].
7. IANA Considerations 7. IANA Considerations
This document requires new code point assignments for both IPFIX This document requires new code point assignments for both IPFIX
Information Elements and RADIUS attributes as explained in the Information Elements and RADIUS attributes as explained in the
following sub-sections. following sub-sections.
It is assumed that Extended-Type-1 "241" will be used for RADIUS It is assumed that Extended-Type-1 "241" will be used for RADIUS
attributes in Section 7.2. attributes in Section 7.2.
skipping to change at page 34, line 5 skipping to change at page 34, line 29
IP-Port-Range-Start 9 see Section 3.2.9 IP-Port-Range-Start 9 see Section 3.2.9
IP-Port-Range-End 10 see Section 3.2.10 IP-Port-Range-End 10 see Section 3.2.10
IP-Port-Local-Id 11 see Section 3.2.11 IP-Port-Local-Id 11 see Section 3.2.11
8. Acknowledgements 8. Acknowledgements
Many thanks to Dan Wing, Roberta Maglione, Daniel Derksen, David Many thanks to Dan Wing, Roberta Maglione, Daniel Derksen, David
Thaler, Alan Dekok, Lionel Morand, and Peter Deacon for their useful Thaler, Alan Dekok, Lionel Morand, and Peter Deacon for their useful
comments and suggestions. comments and suggestions.
Special thanks to Lionel Morand for the Shepherd review. Special thanks to Lionel Morand for the Shepherd review and to
Kathleen Moriarty for the AD review.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", [IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
<http://www.iana.org/assignments/ipfix/ipfix.xhtml>. <http://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 35, line 31 skipping to change at page 36, line 5
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>. <http://www.rfc-editor.org/info/rfc6269>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>. <http://www.rfc-editor.org/info/rfc6333>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
Operation of Address Translators with Per-Interface Operation of Address Translators with Per-Interface
Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
<http://www.rfc-editor.org/info/rfc6619>. <http://www.rfc-editor.org/info/rfc6619>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013, DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>. <http://www.rfc-editor.org/info/rfc6887>.
 End of changes. 13 change blocks. 
14 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/