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

[Alissa Cooper <[e-mail]>]

Hi Lionel,

> On Sep 6, 2016, at 8:31 AM, [e-mail] wrote:
> 
> Hi,
> 
> On the specific discussion on IANA, here is my summary for more details.
> When discussed in the group, two voices (Alan and myself) had two different strong positions.
> Other voices were neutral saying that both could work, without any preference. Others didn't care.
> In order not to block the process, it was concluded that IANA would be maybe more appropriate to decide if my concerns about the registry management are also an issue for them. And because IANA is part of the IESG review process, it was thought that it was good to their feedback, even if it means that we have to update the draft afterward. IETF last calls are also for that purpose I think.

I disagree. The WG needs to decide how it wants to structure the registries. It can choose something complicated that will require more work for IANA, or it can choose something simpler, but the WG should choose whatever it thinks is best. IANA is involved in the last call process to provide feedback about whether the instructions given to them are clear, not to provide an opinion about how registries should be structured. As long as the instructions are clear, IANA should be able to create registries however the IETF chooses to specify them.

Alissa

> 
> Now, in the details (text is short but illustrated with tables for clarification of the concerns).
> 
> The current position in the draft is to allocate a unique value per TLV, such as:
> 
>      Name                    Value      Meaning
>      ----                          -----      -------
>      IP-Port-Type            1         see Section 3.2.1
>      IP-Port-Limit           2         see Section 3.2.2
>      IP-Port-Ext-IPv4-Addr   3         see Section 3.2.3
>      IP-Port-Int-IPv4-Addr   4         see Section 3.2.4
>      IP-Port-Int-IPv6-Addr   5         see Section 3.2.5
>      IP-Port-Int-Port        6         see Section 3.2.6
>      IP-Port-Ext-Port        7         see Section 3.2.7
>      IP-Port-Alloc           8         see Section 3.2.8
>      IP-Port-Range-Start     9         see Section 3.2.9
>      IP-Port-Range-End      10         see Section 3.2.10
>      IP-Port-Local-Id       11         see Section 3.2.11
> 
> Which means that whatever the parent attribute, value 1 will have to be reserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these TLVs are never unused in these attributes.
> The argument given by Alan is that "a TLV called "foo" should have the same TLV-Type value (e.g. 1) across multiple parent TLVs.  There is enough space to do sparse allocation." 
> 
> However, the allocation rule for TLV is defined as follow in the RFC6929:
> 
> 10.3.6. Allocation within a TLV
> 
>   Specifications can request allocation of Attribute Type values within
>   an Attribute of data type TLV.  The encapsulating TLV can be
>   allocated in the same specification, or it can have been previously
>   allocated.
> 
>   Specifications need to request allocation within a specific Attribute
>   Type value (e.g., "TYPE.TLV.*").  Allocations are performed from the
>   smallest Unassigned value, proceeding to the largest Unassigned
>   value.
> 
> Moreover, in section 2.3.  "TLV Data Type" of the same RFC, it is said:
> 
>      As with the Extended-Type field defined above, the TLV-Type is
>      meaningful only within the context defined by "Type" fields of the
>      encapsulating Attributes.  That is, the field may be thought of as
>      defining a new type space of the form
>      "Type.Extended-Type.TLV-Type".  Where TLVs are nested, the type
>      space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.
> 
> Following these recommendations, the section 7.3 should be revised as follow, with a TLV-Type defined per parent attribute:
> 
> 7.3.  IANA Considerations on New RADIUS Sub-attributes
> 
>   This specification requests allocation of the following sub-attributes within
>   the attribute IP-Port-Limit-Info 241.TBD1:
> 
>      Identifier                      Name               
>      --------------                 -------------- 
>      241.TBD1.1                 IP-Port-Type  
>      241.TBD1.2                 IP-Port-Limit   
>      241.TBD1.3                 IP-Port-Ext-IPv4-Addr
>     241. TBD1.{4-253} 	Unassigned
>     245. TBD1.{254-255}	Reserved
> 
>   This specification requests allocation of the following sub-attributes within
>   the attribute IP-Port-Range 241.TBD2:
> 
>      Identifier                      Name                   
>      ----                                  ----                
>      241.TBD2.1                 IP-Port-Type-1   
>      241.TBD2.2                 IP-Port-Ext-IPv4-Addr-1
>      241.TBD2.3                 IP-Port-Local-Id-1  
>      241.TBD2.4                 IP-Port-Alloc   
>      241.TBD2.5                 IP-Port-Range-Start
>      241.TBD2.6                 IP-Port-Range-End  
>     241. TBD2.{7-253}	Unassigned
>     245. TBD2.{254-255}	Reserved
> 
>   This specification requests allocation of the following sub-attributes within
>   the attribute IP-Port-Forwarding-Map 241.TBD3:
> 
>      Type                             Name                   
>      ----                                ----   
>      241.TBD3.1                 IP-Port-Type-2 
>      241.TBD3.2                 IP-Port-Ext-IPv4-Addr-2
>      241.TBD3.3                 IP-Port-Local-Id-1
>      241.TBD3.4                 IP-Port-Int-IPv4-Addr 
>      241.TBD3.5                 IP-Port-Int-IPv6-Addr 
>      241.TBD3.6                 IP-Port-Int-Port 
>      241.TBD3.7                 IP-Port-Ext-Port
>     241. TBD3.{8-253}	Unassigned
>     245. TBD3.{254-255}	Reserved
> 
> Here is an "example" of what would look like after the Radius Attribute Types registry after publication of the new RFC.
> 
> 241			Extended-Attribute-1		[RFC6929]
> 241.1			Frag-Status			[RFC7499]
> 241.2			Proxy-State-Length		[RFC7499]
> 
> 241.3			IP-Port-Limit-Info		NEW RFC
> 241.3.1			IP-Port-Type-1			NEW RFC
> 241.3.2			IP-Port-Ext-IPv4-Addr-1	               NEW RFC
> 241.3.3			IP-Port-Limit			NEW RFC
> 241.3.{4-253}		Unassigned			NEW RFC
> 245.3.{254-255}	Reserved			NEW RFC
> 
> 241.4			IP-Port-Range			NEW RFC
> 241.4.1			IP-Port-Type-2			NEW RFC
> 241.4.2			IP-Port-Ext-IPv4-Addr-2 	NEW RFC
> 241.4.3			IP-Port-Local-Id-1		NEW RFC
> 241.4.4			IP-Port-Alloc			NEW RFC
> 241.4.5			IP-Port-Range-Start		NEW RFC
> 241.4.6			IP-Port-Range-End		NEW RFC
> 241.4.{7-253}		Unassigned			NEW RFC
> 245.4.{254-255}	Reserved			NEW RFC
> 
> 241.5			IP-Port-Forwarding-Map	NEW RFC
> 241.5.1			IP-Port-Type-3			NEW RFC
> 241.5.2			IPort-Ext-IPv4-Addr-3		NEW RFC
> 241.5.3			IP-Port-Local-Id-2		NEW RFC
> 241.5.4			IP-Port-Int-IPv4-Addr		NEW RFC
> 241.5.5			IP-Port-Int-IPv6-Addr		NEW RFC
> 241.5.6			IP-Port-Int-Port		               NEW RFC
> 241.5.7			IP-Port-Ext-Port		NEW RFC
> 241.5.{8-253}		Unassigned			NEW RFC
> 245.5.{254-255}	Reserved			NEW RFC
> 
> 241.{6-25}		Unassigned	
> 241.26			Extended-Vendor-Specific-1	[RFC6929]
> 241.{27-240}		Unassigned	
> 241.{241-255}		Reserved			[RFC6929]
> 
> This approach is straightforward for IANA in terms of allocation and I still don't see the real issue from a dictionary point of view.
> 
> In the other hand, here is an "example" of what would look like the registry if Alan's proposal is accepted.
> 
> 241			Extended-Attribute-1		[RFC6929]
> 241.1			Frag-Status			[RFC7499]
> 241.2			Proxy-State-Length		[RFC7499]
> 
> 241.3			IP-Port-Limit-Info		NEW RFC
> 241.3.1			IP-Port-Type			NEW RFC
> 241.3.2			IP-Port-Ext-IPv4-Addr	               NEW RFC
> 241.3.3			IP-Port-Limit			NEW RFC
> 241.3.{4-11}		Reserved			NEW RFC
> 241.3.{12-253}		Unassigned			NEW RFC
> 241.3.{254-255}	Reserved			NEW RFC
> 
> 241.4			IP-Port-Range			NEW RFC
> 241.4.1			IP-Port-Type			NEW RFC
> 241.4.2			IP-Port-Ext-IPv4-Addr	 	NEW RFC
> 241.4.3			Reserved			NEW RFC
> 241.4.4			IP-Port-Local-Id			NEW RFC
> 241.4.5			IP-Port-Alloc			NEW RFC
> 241.4.6			IP-Port-Range-Start		NEW RFC
> 241.4.7			IP-Port-Range-End		NEW RFC
> 241.4.{8-11}		Reserved			NEW RFC
> 241.4.{12-253}		Unassigned			NEW RFC
> 241.4.{254-255}	Reserved			NEW RFC
> 
> 241.5			IP-Port-Forwarding-Map	NEW RFC
> 241.5.1			IP-Port-Type			NEW RFC
> 241.5.2			IPort-Ext-IPv4-Addr		NEW RFC
> 241.5.3			Reserved			NEW RFC
> 241.5.4			IP-Port-Local-Id			NEW RFC
> 241.5.5			Reserved			NEW RFC
> 241.5.6			Reserved			NEW RFC
> 241.5.7			Reserved			NEW RFC
> 241.5.8			IP-Port-Int-IPv4-Addr		NEW RFC
> 241.5.9			IP-Port-Int-IPv6-Addr		NEW RFC
> 241.5.10		IP-Port-Int-Port		               NEW RFC
> 241.5.11		IP-Port-Ext-Port		NEW RFC
> 241.5.{12-253}		Unassigned			NEW RFC
> 241.5.{254-255}	Reserved			NEW RFC
> 
> And the values x.x.{1-11} will have to be reserved for any new attribute of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, 243.{1-240}, 244.{1-240}, 245.{1-240} and 246.{1-240}.
> It would be like defining a new registry for sub-TLVs. That is, in my opinion, in contradiction with the definition of the TLV data type given in section 7.3 of RFC6929 (see above).
> 
> I hope that this clarifies my point.
> 
> regards,
> 
> Lionel
> 
>> -----Message d'origine-----
>> De : [e-mail]
>> [mailto:[e-mail]]
>> Envoyé : mardi 16 août 2016 23:16
>> À : Alissa Cooper
>> Cc : IESG; [e-mail]; MORAND Lionel
>> IMT/OLN; [e-mail]; [e-mail]
>> Objet : Re: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11:
>> (with DISCUSS and COMMENT)
>> 
>> 
>> 
>> 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-ex
>>>>> t/
>>>>> 
>>>>> 
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>> 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
>>> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>