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

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.

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:

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.]

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.

I agree with Alissa's questions.

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

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.

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

* 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.