Skip to main content

Last Call Review of draft-ietf-radext-ip-port-radius-ext-09

Request Review of draft-ietf-radext-ip-port-radius-ext
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-09-13
Requested 2016-08-02
Authors Dean Cheng , Jouni Korhonen , Mohamed Boucadair , Senthil Sivakumar
Draft last updated 2016-08-24
Completed reviews Genart Last Call review of -09 by Ron Bonica (diff)
Genart Telechat review of -11 by Ron Bonica (diff)
Secdir Last Call review of -09 by Carl Wallace (diff)
Opsdir Last Call review of -09 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-radext-ip-port-radius-ext-09-opsdir-lc-chown-2016-08-24
Reviewed revision 09 (document currently at 17)
Result Has Issues
Completed 2016-08-24


I have reviewed this document as part of the Operational directorate's 

ongoing effort to review all IETF documents being processed by the IESG. 


 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 puposes, 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 dcoument 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 interchangably, 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.