RADIUS Extensions for IP Port Configuration and Reporting
draft-ietf-radext-ip-port-radius-ext-17

Received changes through RFC Editor sync (created alias RFC 8045, changed abstract to 'This document defines three new RADIUS attributes.  For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts.  This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc.  This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers.', changed pages to 43, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-01-25, changed IESG state to RFC Published)

[Ballot comment]
The document really improved. Thanks.

- Section 2. Terminology.
Typically, you want to have that note at the beginning:

  Note that the definitions of "internal IP address", "internal port",
  "internal realm", "external IP address", "external port", "external
  realm", and "mapping" are the same as defined in Port Control
  Protocol (PCP) [RFC6887], and the Common Requirements for Carrier-
  Grade NATs (CGNs) [RFC6888].

If I know of RFC6887 and RFC6888, I don't read the definitions.

You mentioned that you would fixed this. It seems that this paragraph disappeared. Is this intentional?

- Normative references to IANA registries, I'm not sure. I guess the RFC-editor would correct that, if it needs to be.

[Ballot comment]
Thanks for addressing most of my comments, especially the one about privacy sensitive information in IP-Port-Local-Id TLV. However, I note that the summary for the IP-Port-Local-Id TLV in section 3.1.3 still mentions the potential for it to carry a MAC address.

[Edit: The suggested changes in Alissa's current comment would help mitigate that.]

[Ballot comment]
Thanks for addressing most of my comments, especially the one about privacy sensitive information in IP-Port-Local-Id TLV. However, I note that the summary for the IP-Port-Local-Id TLV in section 3.1.3 still mentions the potential for it to carry a MAC address.

[Ballot comment]
Thanks for responding to my DISCUSS and COMMENT. I understand that this document is not the appropriate place to specify error handling related to these attributes. I do still think adding a note about the potential consequences of communicating erroneous port range and port mapping information would be a good precaution here.

In 3.2.11 the new text helps but I think there are a couple more changes necessary to make the constraints explicit:

OLD
localID

      string.  The data type of this field is string (refer to
      [I-D.ietf-radext-datatypes]).  This field contains the data that
      is a local session identifier at the customer premise, such as MAC
      address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP
      address/prefix, etc.

  IP-Port-Local-Id TLV MAY be included in the following Attributes:

NEW
localID

      string.  The data type of this field is string (refer to
      [I-D.ietf-radext-datatypes]).  This field contains the data that
      is a local session identifier at the customer premise, such as MAC
      address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP
      address/prefix, or another local session identifier.

  IP-Port-Local-Id TLV MAY be included in the following Attributes if it is necessary to identify the subscriber:

[Ballot comment]

Thanks for removing the ICMP identifier thing.

OLD COMMENTS below. I'm happy to chat about 'em
if we need to.

- write-up: Yeah, major yuks to leaving design decisions
to IANA.  While the folks there are quite capable, they
are not able to make IETF consensus decisions.  If the WG
aren't sure, ask IANA personnel (or someone) and then
verify that that outcome garners rough consensus back in
the WG or using other IETF processes. So Alissa's discuss
point#4 is entirely, completely and fully correct and
a showstopper really.

- I also agree with the issue called out in Joel's comment
about mission creep and how this overlaps with PCP. Did
the WG consider whether or not it is a good idea for the
IETF to define multiple ways in which some of these
features can be added? If so, what is the justification
for there being more than one? (Is that somewhere in the
WG list archive? If not, it ought be.) It may well be that
having a RADIUS mechanism for this is also a good plan,
but I think that ought be justified.

- 4.1.4: using port 80 as an example is very 1990's. Would
it not be better to be more up to date? That's not just a
facetious point - web cameras being left open to the
Internet are a major swamp for botnet gestation. Better to
use a more desirable example really.

- The secdir review [1] also noted a bunch of issues that
as far as I can see received no response so far, but that
do deserve a response. (Apologies if I missed a response.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html

[Ballot comment]
Thanks for addressing my discuss!

Here is some further feedback from the IE-Doctors:
The description of the requested Information Element is still a bit vague, but acceptable; one must read the document in order to understand that binding the value to and end-user is really binding to one or more (source) addresses. The reference to section 3.2.2 (which is, IMO, not any more explanatory than the description of the IE itself) is not necessary.

[Ballot discuss]
I'm late for my review here. If some points in my DISCUSS/COMMENT have been discussed already let me know.

I'll flag this as a DISCUSS to follow up on the IPFIX issues.
First of, I applause the attempt to reuse/map/combine data models (IPFIX information element and RADIUS attribute).

Now, there are a couple of issues.
The first set of issues has been sent via the IPFIX experts, copied here for tracking purposes.

    Dear Authors,

    The experts for the IPFIX IE registry have returned the following
    review:

    In general, the Information Elements in draft-ietf-radext-ip-port-
    radius-ext are so underspecified as to be unimplementable. They should
    not be added to the registry in their present form. The authors are
    advised to read RFC 7013, especially Section 4, which provides useful
    information on defining Information Elements. Specifically:

    The Information Element transportType is underspecified: (a) I presume
    this is in reference to sourceTransportPort and
    destinationTransportPort, but the description must say this if it is
    the case; (b) It's not clear at all from the description in what
    context this distinction is useful; (c) What's an ICMP identifier?

    In addition, the description of transportType appears to create a
    table which should probably be handled as a subregistry. See See
    RFC7013 section 4.7. for advice on the creation of tables without
    subregistries (in short, "don't".)

    The Information Element natTransportLimit has an inappropriate name;
    it does not describe that which it (presumably) is supposed to
    represent (see RFC 7013 section 4.1). In addition, it is
    underspecified. It is impossible to implement from the description. Is
    the field IPv4 specific, or is IPv6 supported as well? (If not, why
    not?)

    The Information Element localID has an inappropriate name; it is far
    too general (see RFC 7013 section 4.1). It uses an inappropriate
    abstract data type (addresses should never be represented as UTF-8
    strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as
    well as poorly designed. Without the ability to disambiguate the type
    of information in the field, this is not a useful Information Element.
    Without a complete enumeration of possible types (n.b. 'etc.' in the
    description), it is not a useful Information Element. Its purpose is
    unclear from its description; further, it appears to violate the
    following guidance in RFC 7013 section 4: "The Information Element
    must be unique within the registry, and its description must represent
    a substantially different meaning from that of any existing
    Information Element. An existing Information Element that can be
    reused for a given purpose should be reused."

I have some more issues I would like to discuss:
- section 3.2.5, as an example, contains a list of sourceIPv6Address. In IPFIX, we would export those as a list [RFC 6313]
Does this RADIUS document want to only reuse the semantic of individual IPFIX information element?
And also the semantic of multiple information elements [RFC 6313]?
And also the IPFIX encoding? For example, some IPFIX fields are "right justified" (sourceTransportPort), while some others are not (localID)
The document should be clear.

[Ballot comment]
-

  1.  IP-Port-Limit-Info: This attribute may be carried in RADIUS
      Access-Accept, Access-Request, Accounting-Request or CoA-Request
      packet.  The purpose of this attribute is to limit the total
      number of TCP/UDP ports and/or ICMP identifiers allocated to a
      user, associated with one or more IPv4 addresses.

I see "may be carried". Could it be carried in other packets ... was my first question.
It was not clear (until I read the rest of the document) that it's a non compulsory attribute only in
Access-Accept, Access-Request, Accounting-Request or CoA-Request packets.
Proposal:
  1.  IP-Port-Limit-Info: The purpose of this attribute is to limit the total
      number of TCP/UDP ports and/or ICMP identifiers allocated to a
      user, associated with one or more IPv4 addresses. This attribute is
      carried in RADIUS Access-Accept, Access-Request, Accounting-Request or
      CoA-Request packets. 

Same remark for the other two points below.

2.  IP-Port-Range: This attribute may be carried in RADIUS
      Accounting-Request packet.  The purpose of this attribute is to
      report by an address sharing device (e.g., a CGN) to the RADIUS
      server the range of TCP/UDP ports and/or ICMP identifiers that
      have been allocated or deallocated associated with a given IPv4
      address for a user.

  3.  IP-Port-Forwarding-Map: This attribute may be carried in RADIUS
      Access-Accept, Access-Request, Accounting-Request or CoA-Request
      packet.  The purpose of this attribute is to specify how an IPv4
      address and a TCP/ UDP port (or an ICMP identifier) is mapped to
      another IPv4 address and a TCP/UDP port (or an ICMP identifier).

-

  1.  IP-Port-Limit-Info: This attribute may be carried in RADIUS
      Access-Accept, Access-Request, Accounting-Request or CoA-Request
      packet.  The purpose of this attribute is to limit the total
      number of TCP/UDP ports and/or ICMP identifiers allocated to a
      user, associated with one or more IPv4 addresses.


Only for TCP/UDP? I believe Mirja had the same question.

- Section 2. Terminology.
Typically, you want to have that note at the beginning:

  Note that the definitions of "internal IP address", "internal port",
  "internal realm", "external IP address", "external port", "external
  realm", and "mapping" are the same as defined in Port Control
  Protocol (PCP) [RFC6887], and the Common Requirements for Carrier-
  Grade NATs (CGNs) [RFC6888].

If I know of RFC6887 and RFC6888, I don't read the definitions.

- Section 3.1.3

  This attribute is of type "TLV" as defined in the RADIUS Protocol
  Extensions [RFC6929].  It contains the following sub-attributes:

  ...

  o  either an IP-Port-Int-IPv4-Addr TLV (see Section 3.2.4) or an IP-
      Port-Local-Id TLV (see Section 3.2.11),

  o  either an IP-Port-Int-IPv6-Addr TLV (see Section 3.2.5) or an IP-
      Port-Local-Id TLV (see Section 3.2.11),

Depending on the IP-Port-Type value, it's one of the two above, not both.

- I believe the RFC 2119 keywords usage is sometimes weak (generic comment for the entire document)
Example1: section 3.1.3

  The attribute contains a 2-byte IP internal port number that is
  associated with an internal IPv4 or IPv6 address, or a locally
  significant identifier at the customer site, and a 2-byte IP external
  port number that is associated with an external IPv4 address.  The
  internal IPv4 or IPv6 address, or the local identifier must be
  included; the external IPv4 address may also be included.

Not RFC 2119 keywords. Shoud they be MUST and MAY?
And the next paragraph contains RFC 2119 keywords.

  The IP-Port-Forwarding-Map Attribute MAY appear in an Access-Accept
  packet.  It MAY also appear in an Access-Request packet to indicate a
  preferred port mapping by the device co-located with NAS.  However
  the server is not required to honor such a preference.

Example2:

  IP-Port-Ext-IPv4-Addr TLV MAY be included in the following
  Attributes:

  o  IP-Port-Limit-Info Attribute, identified as 241.TBD1.3 (see
      Section 3.1.1).

  o  IP-Port-Range Attribute, identified as 241.TBD2.3 (see
      Section 3.1.2).

  o  IP-Port-Forwarding-Mapping Attribute, identified as 241.TBD3.3
      (see Section 3.1.3).

Don't you need the RFC2119 keyword in the reverse situation, in section 3.1.1 (IP-Port-Limit-Info Attribute)? 
OLD:
  o  an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3).

NEW:
  o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Ext-IPv4-Addr (see Section 3.2.3).

This logic would not only be clearer, but would also avoid inconsistencies.
See section 3.1.3
OLD:

It contains the following sub-attributes:
  ...
  o  an IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3).


NEW:

It contains the following sub-attributes:

  ...
  o  an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3).

Example 3:

  natEvent

      Integer.  This field contains the data (unsigned8) of natEvent
      (230) defined in IPFIX, right justified, and unused bits must be
      set to zero.  It indicates the allocation or deallocation of a
      range of IP ports as follows:

MUST?

[Ballot discuss]

Sorry for not spotting this in other documents, but do we
understand the privacy characteristics of this ICMP
identifier? It may well be that the resolution of this
discuss requires some other document to exist (in which
case I'll get out of the way of this one) but I think we
ought be quite cautious in how we introduce  new functions
for identifiers that may be personally identifying, so I'd
like to chat about this a bit. Did the WG discuss the
privacy issues associated with this identifier?

[Ballot comment]

- write-up: Yeah, major yuks to leaving design decisions
to IANA.  While the folks there are quite capable, they
are not able to make IETF consensus decisions.  If the WG
aren't sure, ask IANA personnel (or someone) and then
verify that that outcome garners rough consensus back in
the WG or using other IETF processes. So Alissa's discuss
point#4 is entirely, completely and fully correct and
a showstopper really.

- I also agree with the issue called out in Joel's comment
about mission creep and how this overlaps with PCP. Did
the WG consider whether or not it is a good idea for the
IETF to define multiple ways in which some of these
features can be added? If so, what is the justification
for there being more than one? (Is that somewhere in the
WG list archive? If not, it ought be.) It may well be that
having a RADIUS mechanism for this is also a good plan,
but I think that ought be justified.

- 4.1.4: using port 80 as an example is very 1990's. Would
it not be better to be more up to date? That's not just a
facetious point - web cameras being left open to the
Internet are a major swamp for botnet gestation. Better to
use a more desirable example really.

- The secdir review [1] also noted a bunch of issues that
as far as I can see received no response so far, but that
do deserve a response. (Apologies if I missed a response.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html

[Ballot comment]
* Does the IP-Port-Limit include the count of ports already allocated through the IP-Port-Forwarding-Map or not?

* I agree with Alissa's DISCUSS points about the lack of error handling and the privacy issues and Mirja's DISCUSS point about restricting transport protocols to TCP and UDP.

[Ballot comment]
Tim Chown Tim.Chown@jisc.ac.uk provided the opdir review.

At this time, this position is not a discuss, but I would like to see a discussion or pointer to a dicussion on the role of this method vs pcp.

thanks
joel

Hi,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of the
IETF drafts. Comments that are not addressed in last call may be included in AD reviews
during the IESG review.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This draft defines three new RADIUS attributes to be used when communicating with a
RADIUS server to facilitate the configuration or reporting of IP and port ranges used
with a network appliance, typically a CGN, where there is a need to constrain
the ports available per customer where IP address sharing is in use.

The three RADIUS attributes are:
IP-Port-Limit-Info - defines the maximum number of ports available
IP-Port-Range - the specific range of port numbers available
IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device

I would consider the document to be "Ready with Issues".

I have some general comments, followed by some specific comments. Note that while I
am familiar with RADIUS (from an eduroam context) the draft is not one I was
familiar with or followed prior to this review. Thus these comments may have already
been addressed.

General comments:

There are at least two areas in which this document has "creep". One is that it is
providing an alternative method to PCP to define port forwarding mappings on a device.
So there is an open question as to whether PCP should be the method of choice for
this function, or whether we wish to create a new way to establish such mappings.

Secondly, two of the new attributes support inclusion of a new TLV, IP-Port-Local-Id,
which allows user/device-specific information to be transmitted via RADIUS, such as
MAC address or VLAN ID. While this is intended to allow differentiation of users for
accounting/identification r, in doing so it adds an additional potential privacy
concern into a new RADIUS attribute, depending on specific use cases of the TLV.
This is not discussed in the Security Considerations section, but probably should be.

I note the new attributes use a number of IPFIX information elements; has the draft
considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, which says
the "lack of a consistent way to log the data makes it difficult to write the
collector applications that would receive this data and process it to present useful
information"? This draft is introducing a new method to log such elements; is this
a concern at all?

The examples of use cases of the new attributes include both NAT44 devices and CGNs.
The document could state more clearly the address sharing scenarios, perhaps with a
simplified network element diagram for each example, showing the user/host, CPE/NAT44,
and NAT444/CGN? Some additional clarity here would be useful (see also comments below).
Also, the term "the user" is used in many places in the document where in practice
"the customer's CPE" would be more appropriate.


Specific comments:

NAT64 is mentioned as a use case at the start, but no example is given later in the
document. This might add useful value.

In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in the
TLV are 16 bit values, but 32 bits are reserved for the element. Similarly the
NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if the
document stated why these elements are being padded out to 32 bits.

In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex users
over a smaller number of shared IPv4 addresses, rather its primary design goal
is to facilitate access to legacy IPv4 content from IPv6-only networks.  The
text should be clarified.

Also in 4.1.1, do users really have service agreements that state port limits?
If they do, I doubt users are aware of them (or care...), and the issue is beyond
the scope of this document.

In 4.1.2, I think you mean "block", not "bulk"? 
And the comment on "randomization" might fit better in the Security Considerations
section if you discuss privacy there (which is presumably what you mean?)

Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram shows
only the NAT44 (presumably in the CPE) and not an ISP CGN.

The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, without
the diagram showing there may (presumably) be mappings to establish at both the
user's CPE and the ISP's CGN.

And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about a CGN
allocating more ports; is that at the NAT44, or at the CGN?

(These specific NAT44/CGN comments are examples of the general comment I made earlier.)

In Section 5, I found the format of the table with 0 and 0+ a little unintuitive.

--

Tim


_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

[Ballot comment]
* Why are the the uint8 and unit16 based types getting stuffed into 32 bit fields inside the TLVs? This feels like a complete waste. Is there any specific reason this is required?

* Does the IP-Port-Limit include the count of ports already allocated through the IP-Port-Forwarding-Map or not?

* I agree with Alissa's DISCUSS points about the lack of error handling and the privacy issues and Mirja's DISCUSS point about restricting transport protocols to TCP and UDP.

[Ballot discuss]
I fully support Alissa's discussion points and have two more to add:

1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very future-proof: there are other transport protocols that have ports or identifiers that may want to be supported in future. Also it is not clear to me from the document why this information is needed at all in the described use cases. Therefore I see two possible ways forward: Either remove the IP-Port-Type TLV or extend it to also cover other cases.

Related to this point I would like to mention that RFC6887 is not restricted to UDP/TCP and therefore the following sentence in section 2 is not correct:
"Note that the definitions of [...] "internal port", [...] "external port" [...] are the same as defined in Port Control Protocol (PCP) [RFC6887]"

2) The IE doctors have provide feedback to IANA that the Information Elements in this doc are underspecified (not confirm with rules in RFC 7013) and should therefore be not registered.  Addressing this feedback could lead to a mayor rewrite of this doc, especially in the relation to the use and definition of transportType and receptively IP-Port-Type TLV, and should therefore be done before a final IESG decision.

[Ballot comment]
Maybe it is just me, but I found that the idea that most subattributes are the same size, but right aligned to be wasteful. Is this a common design pattern for Radius?

I am agreeing with Alissa on privacy concerns.

On page 12:

      IP-Port-Int-IPv6-Addr TLV

        This TLV contains an IPv4 address that is associated with the

Typo: should be IPv6?

        internal IP port number contained in the IP-Port-Int-Port TLV.
        For IPv6 network, either this TLV or IP-Port-Local-Id TLV must
        be included as part of the IP-Port-Forwarding-Map Attribute.
        Refer to Section 3.2.5.

[Ballot comment]
I originally intended the two comments under "Major Issues" to be points for a DISCUSS position. But I see Alissa has already captured the essence of them in her DISCUSS. Therefore I will ballot NO OBJECTION for now, and will watch that discussion.

Major Issues:

The guidance for IP-Port-Local-Id TLV contemplates using persistent client identifiers, such as MAC addresses. Is that necessary? I suspect the answer will be "yes". But if that  is the case, the draft really needs a privacy considerations section to discuss the implications and tradeoffs.

- 3.1.1, paragraph 7: "However, the RADIUS server is not required to honor such a
  preference."
Please describe what it means to "not honor" such a preference? Does the server report an error? Does the transaction succeed, but report a different limit? Does the server just ignore the preference and do its own thing? (I expect this applies to any number of failure conditions.)

Minor Issues:

- Please clarify the applicability to IPv4 and IPv6. Specifically, I note that you define TLVs for "internal" IPv4 and IPv6 addresses, but only for "external" IPv4 address. I assume that to mean that this supports Nat44 and Nat64 use cases, but not anything that uses IPv6 in the "external" realm? (Whatever the answer, it would be helpful to have a paragraph or two to make that explicit.)

-2, definition of "port-based device":
Wouldn’t that more properly be called a port-mapping device? (anything using TCP or UDP would seem to be port-based)

-3.1.1, last paragraph:
This language precludes new extension packet types from using the attribute without updating this document. Is that really the intent? Would it make sense to say something like "... MUST NOT appear in any other RADIUS packet types defined at the time of this writing. If a future packet type uses the attribute, the specification of that packet type will need to define it's usage"? (Note that this issue repeats several times in the document.)

Editorial Comments and Nits:

- The use of the term "session" seems inconsistent. In some places it seems like an IPFlow or a NAT mapping, but in other places it seems like a network connection (i.e. NAS attachment.)

- 1, list item 1:
Singular/plural mismatch for "packet". Either "packet" should be "packets", or you need an article before RADIUS. (e.g. a RADIUS...packet.) Note that this error repeats many times in similar patterns throughout the document.

-1, list item 2, last sentence:
Convoluted sentence. Can it be simplified?

-1, last paragraph:
It would be helpful to mention that this draft defines IPFIX elements near the top of the section, and also in the abstract.

-2, definition of "Internal IP Address": "refers to the IP address that is used as a
      source IP address"
Used by what device?

-2, definition of "mapping":
I cannot parse the text. (Note that while the last paragraph in the section says this is taken from 6887 and 6888, neither of them seem to use this specific language.)

-4.1, second paragraph: " A CGN function in a broadband network would most likely co-located on a BNG."
There's a missing word in there somewhere. Maybe a "be" before "co-located"?

-6, last paragraph:
The paragraph doesn't parse. Should "deployed" be "deployments"?

[Ballot discuss]
(1) I find the absence of any definition of error handling behavior in this document to be a problem. I realize that the attributes specified in this document are meant to be transmitted between components that are all operated by the same administrative entity, but implementors can still make mistakes, and for those cases it seems like error handling should be defined. For example:

- What happens if the AAA server sends an IP-Port-Limit-Info attribute with a larger limit than the CGN is able to allocate to that particular user? What is the CGN supposed to do and how is that communicated back to the AAA server?

- What happens if the CGN sends an IP-Port-Range attribute that encompasses a larger range than a previously sent IP-Port-Limit-Info? What is the AAA server supposed to do?

- What happens if the AAA server sends an IP-Port-Forwarding-Map attribute to map a port that is not within the requesting host's allocated range? Is the CGN expected to change the mapping and send a CoA with a different IP-Port-Forwarding-Map, or communicate some sort of error, or something else?

There are surely other error cases. I think it's worth going through the uses of each attribute and specifying all the error handling behavior. This seems especially important since part of the motivation for these attributes is for identification and the consequences of erroneous identification could be severe for the user. Discussion of those consequences is also missing from Section 6.

(2) Section 3.1.2 says:

"For port allocation, both IP-Port-Range-Start TLV and IP-
  Port-Range-End TLV must be included; for port deallocation, the
  inclusion of these two TLVs is optional and if not included, it
  implies that all ports that are previously allocated are now
  deallocated."

How does an AAA server distinguish between port allocation and deallocation requests if a deallocation request includes a range start and range end? Is the server supposed to assume that whatever range is specified by the most recently received IP-Port-Range attribute represents the only range of allocated ports for the host? What is the meaning of sending an IP-Port-Range request with only a start value or an end value but not both (as seems to be allowable by the above)?

(3) The specification of IP-Port-Local-Id seems to allow for unnecessary exposure of potentially sensitive information. There is no explanation given for why the combination of the other identifiers included in IP-Port-Range and IP-Port-Forwarding attributes is insufficient to identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As defined, it sounds like implementations could put basically any user, device, or interface identifier in there. If this TLV is actually necessary to communicate what these attributes are trying to accomplish, the justification for it should be provided and the limitations on when this field may be used and what kind of identifiers can appear here should be stated.

(4) The shepherd write-up discusses two different approaches to defining the sub-TLV types and then says: "Both approaches were considered as valid and the WG has decided to let IANA decide what the approach is preferred when allocating the TLV-Type for the sub-TLVs defined in this document." This is not appropriate. The document needs to explicitly define how the types should be allocated and should not leave the decision to IANA. I see that IANA has already noted that Section 7.3 is ambiguous about this; the WG needs to make a choice.

(5) Section 6 seems to be missing a discussion of the consequences of communicating erroneous port range and port mapping information. Since part of the motivation for these attributes is identification of the host, this needs to be discussed.

[Ballot comment]
(1) What does it mean for an IP-Port-Range attribute to have IP-Port-Type 1 or 2? Can numbers in the whole range be used for any of the port or identifier types? Or is the range expected to be split up somehow among the multiple types? I think this needs to be explained.

(2) In 4.1.4, how does the ISP know that Joe is traveling?

[Ballot comment]
On page 12:

      IP-Port-Int-IPv6-Addr TLV

        This TLV contains an IPv4 address that is associated with the

Typo: should be IPv6?

        internal IP port number contained in the IP-Port-Int-Port TLV.
        For IPv6 network, either this TLV or IP-Port-Local-Id TLV must
        be included as part of the IP-Port-Forwarding-Map Attribute.
        Refer to Section 3.2.5.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-radext-ip-port-radius-ext-10.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the IPFIX Information Elements subregistry of the IP Flow Information Export (IPFIX) Entities registry located at:

https://www.iana.org/assignments/ipfix/

three new information elements are to be registered as follows:

ElementID: [ TBD-at-registration ]
Name: transportType
Data Type: unsigned8
Data Type Semantics:
Status: current
Description: The value indicates TCP/UDP ports and ICMP Identifiers (1), TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5).
Units:
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: natTransportLimit
Data Type: unsigned16
Data Type Semantics:
Status: current
Description: The value is the max number of IP transport ports to be assigned to an end user associated with one or more IPv4 addresses.
Units:
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: localID
Data Type: string
Data Type Semantics:
Status: current
Description: The value is an IPv4 or IPv6 address, a MAC address, a VLAN ID, etc.
Units:
Range:
References: [ RFC-to-be ]

IANA Question --> for each of these three registrations, could the authors please supply the data type semantics and the units to be registered with these values?

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Radius Attribute Types subregistry of the Radius Types registry located at:

http://www.iana.org/assignments/

three new Radius attribute types are to be registered under the 241 Extended-Attribute-1 type as follows:

Value: 241.[ TBD-at-registration ]
Description: IP-Port-Limit-Info
Reference: [ RFC-to-be ]

Value: 241.[ TBD-at-registration ]
Description: IP-Port-Range
Reference: [ RFC-to-be ]

Value: 241.[ TBD-at-registration ]
Description: IP-Port-Forwarding-Map
Reference: [ RFC-to-be ]

Third, IANA notes that the authors request:

This specification requests allocation of the following TLVs:
Name Value Meaning
---- ----- -------
IP-Port-Type 1 see Section 3.2.1
IP-Port-Limit 2 see Section 3.2.2
IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3
IP-Port-Int-IPv4-Addr 4 see Section 3.2.4
IP-Port-Int-IPv6-Addr 5 see Section 3.2.5
IP-Port-Int-Port 6 see Section 3.2.6
IP-Port-Ext-Port 7 see Section 3.2.7
IP-Port-Alloc 8 see Section 3.2.8
IP-Port-Range-Start 9 see Section 3.2.9
IP-Port-Range-End 10 see Section 3.2.10
IP-Port-Local-Id 11 see Section 3.2.11

IANA Question --> Specifically, in what registry are these new TLVs to be registered?

IANA understands that the three actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

=== 1. Summary ===

The document shepherd is Lionel Morand.
The responsible Area Director is Kathleen Moriarty.

This document defines three new RADIUS attributes.  For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.

Three new attributes (IP-Port-Limit-Info, IP-Port-Range, IP-Port-Forwarding-Map)are defined as "Extended Type" using the "TLV" data type, both defined in RFC6929). The "tlv" data type is an encapsulation layer that permits the "Value" field the attribute to contain new sub-attributes and this nesting is used to group data into logical containers.

This document provides also a mapping between RADIUS sub-TLV and IPFIX Information Element Identifiers, defining new IPFIX Information Elements when required.

=== 2. Review and Consensus ===

After detailed reviews and clean-up, this document is ready to be published.

These new attributes are useful when a RADIUS server is used to configure TCP/UDP port (or ICMP identifier) mapping behaviors in Carrier-Grade NAT or to report to the RADIUS Server the port/identifier mapping behavior applied by the CGN to a user session, as part of the accounting information sent to a RADIUS server.

The proposed RADIUS extensions are simple (definition of new TLV attributes allocated from the RADIUS "Extended Type" code space defined in RFC6929), and there was no difficulty in coming to consensus on the definition of these TLVs.

The IANA considerations section has been reviewed and is consistent with the body of the document. There is no discussion regarding the attribute type values assigned from the Short Extended Space defined in RFC6929. The attribute type value assignment by IANA should be straightforward. However, there was a discussion in the WG regarding the allocation of TLV-Type values for the sub-TLVs.

Some of the sub-TLVs are reused in the three attributes defined in this document. Therefore, two approaches were discussed after the shepherd review:

Approach#1: allocate a fixed TLV-Type for a same sub-TLV reused in multiple parent attributes.
Approach#2: allocate a TLV-Type meaningful only within the context defined by the parent attribute.

In the approach 1, using fixed values for sub-TLV used in any attribute is straightforward from a dictionary/configuration point of view, i.e. the same information is identified by the same name/value independently of the parent attribute. However it would mean defining a flat allocation space for sub-TLV, allowing only 253 values for the definition of sub-TLVs in the Extended-Type space.
In the approach 2, the guidelines given in the RFC6929 are strictly enforced, i.e. for nested TLVs, the TLV-Type is allocated in the type space defined by the parent attribute, of the form "Type.Extended-Type.TLV-Type.TLV-Type", allowing the definition of 253 TLV per extended attribute. However this implies extra-complexity to manage the same TLV with different name/id in different parent attributes.

Both approaches were considered as valid and the WG has decided to let IANA decide what the approach is preferred when allocating the TLV-Type for the sub-TLVs defined in this document. If required, the IANA section will be updated according to the final decision.

=== 3. Intellectual Property ===

Each author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

=== 4. Other Points ===

ID nits tool confirms that document meets the internet drafts checklists.

One specification put as informative reference is still in progress:
* I-D.gundavelli-v6ops-community-wifi-svcs
However, it is not essential for this specification.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-radext-ip-port-radius-ext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'RADIUS Extensions for IP Port Configuration and Reporting'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines three new RADIUS attributes.  For devices that
  implement IP port ranges, these attributes are used to communicate
  with a RADIUS server in order to configure and report TCP/UDP ports
  and ICMP identifiers, as well as mapping behavior for specific hosts.
  This mechanism can be used in various deployment scenarios such as
  Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ballot/


No IPR declarations have been submitted directly on this I-D.

=== 1. Summary ===

The document shepherd is Lionel Morand.
The responsible Area Director is Kathleen Moriarty.

This document defines three new RADIUS attributes.  For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.

Three new attributes (IP-Port-Limit-Info, IP-Port-Range, IP-Port-Forwarding-Map)are defined as "Extended Type" using the "TLV" data type, both defined in RFC6929). The "tlv" data type is an encapsulation layer that permits the "Value" field the attribute to contain new sub-attributes and this nesting is used to group data into logical containers.

This document provides also a mapping between RADIUS sub-TLV and IPFIX Information Element Identifiers, defining new IPFIX Information Elements when required.

=== 2. Review and Consensus ===

After detailed reviews and clean-up, this document is ready to be published.

These new attributes are useful when a RADIUS server is used to configure TCP/UDP port (or ICMP identifier) mapping behaviors in Carrier-Grade NAT or to report to the RADIUS Server the port/identifier mapping behavior applied by the CGN to a user session, as part of the accounting information sent to a RADIUS server.

The proposed RADIUS extensions are simple (definition of new TLV attributes allocated from the RADIUS "Extended Type" code space defined in RFC6929), and there was no difficulty in coming to consensus on the definition of these TLVs.

The IANA considerations section have been reviewed and is consistent with the body of the document. There is no discussion regarding the attribute type values assigned from the Short Extended Space defined in RFC6929. The attribute type value assignment by IANA should be straightforward. However, there was a discussion in the WG regarding the allocation of TLV-Type values for the sub-TLVs.

Some of the sub-TLVs are reused in the three attributes defined in this document. Therefore, two approaches were discussed after the shepherd review:

Approach#1: allocate a fixed TLV-Type for a same sub-TLV reused in multiple parent attributes.
Approach#2: allocate a TLV-Type meaningful only within the context defined by the parent attribute.

In the approach 1, using fixed values for sub-TLV used in any attribute is straightforward from a dictionary/configuration point of vie, i.e. the same information is identified by the same name/value independently of the parent attribute. However it would mean defining a flat allocation space for sub-TLV, allowing only 253 values for the definition of sub-TLVs in the Extended-Type space.
In the approach 2, the guidelines given in the RFC6929 are strictly enforced, i.e. for nested TLVs, the TLV-Type is allocated in the type space defined by the parent attribute, of the form "Type.Extended-Type.TLV-Type.TLV-Type", allowing the definition of 253 TLV per extended attribute. However this implies extra-complexity to manage the same TLV with different name/id in different parent attributes.

Both approaches were considered as valid and the WG has decided to let IANA decide what is the preferred approach when allocating the TLV-Type for the sub-TLVs defined in this document. If required, the IANA section will be updated according to the final decision.

=== 3. Intellectual Property ===

Each author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

=== 4. Other Points ===

ID nits tool confirms that document meets the internet drafts checklists.

One specifications put as informative reference are still in progress:
* I-D.gundavelli-v6ops-community-wifi-svcs
However, it is not essential for this specification.