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

[[e-mail]]

Sent from my iPhone

> On Aug 16, 2016, at 4:54 PM, Alissa Cooper <[e-mail]> wrote:
> 
> 
>> 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.
> 
Agreed, thanks.

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