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

[Alissa Cooper <[e-mail]>]

> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> 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?  

I think it’s fine to say “the only correct behavior is X” but you still need to say what implementations are expected to do when not-X happens. And X will have different values for the different usages of each of these attributes.

Alissa

> 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