[radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-radext-ip-port-radius-ext-11: Discuss

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/



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


----------------------------------------------------------------------
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?