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

[<[e-mail]>]

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.

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.