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

[Kathleen Moriarty <[e-mail]>]

Alissa,

Thanks for your detailed review, this is helpful.  Hopefully we will
be able to resolve this with the editors and shepherd before Thursday.
I have one question in line that may help with the resolution for at
least #1 & #6.

On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper <[e-mail]> wrote:
> 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.

As an alternative, I usually approach this type of problem as defining
what is acceptable and making everything else less acceptable.  White
lists are much easier to maintain and eliminate the possibility of
missing something.  If you and the WG agree, could we go forward with
that approach instead of defining all possible problems, just limiting
what is acceptable and making everything else an error?  This approach
applies to a few of your other discuss points as well, namely #2, #5,
and to some degree #3.

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

Thank you, and yes, the WG needs to make a decision.

Kathleen

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



-- 

Best regards,
Kathleen