[radext] Joel Jaeggli's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT)

["Joel Jaeggli" <[e-mail]>]

Joel Jaeggli has entered the following ballot position for
draft-ietf-radext-ip-port-radius-ext-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Tim Chown [e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ops-dir