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

From: <[email-masked]>
Date: Tue, 6 Sep 2016 09:03:29 +0000

Hi Alissa,

thank you for your review and sorry for this "late" feedback.

Here is my feedback as shepherd of the document. This needs to be completed by draft authors and the AD.

Regards,

Lionel

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

My understanding is that, when defining authorization type attributes that are use over RADIUS, it is not deemed required to define the specific use of these attributes nor the error handling.
As for other AAA documents, this draft is not specifying a specific procedure or a new protocol application. It is just about defining attributes that can be used in the use case described in this document but also in any other solution that would see advantage to reuse these attributes. The main point of this document is to ensure that the definitions of these attributes are correct (type, length, value), unambiguous and describe in which messages they can appear.
The exact behavior of the client/server using these attributes is often left out of this kind of document. It is up to the specification describing the implementation the clients and/or servers using these attributes to define this error handling.

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

If I'm correct, the answer is below:

3.2.8.  IP-Port-Alloc TLV

   The format of IP-Port-Alloc TLV is shown in Figure 11.  This
   attribute carries IPFIX Information Element 230, "natEvent", which is
   a flag to indicate an action of NAT operation (refer to [IPFIX]).

   When the value of natEvent is "1" (Create event), it means to
   allocate a range of transport ports; when the value is "2", it means
   to deallocate a range of transports ports.  For the purpose of this
   TLV, no other value is used.

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

My understanding was that the IP-Port-Local-Id is required when it is not possible to rely on  an internal IPv4 or IPv6 address to identify an ongoing session.
but authors can clarify the use of this attribute and address the privacy concerns.

by the way, if not already spotted:

      IP-Port-Int-IPv6-Addr TLV

         This TLV contains an IPv4 address that is associated with the

s/ This TLV contains an IPv4 address/ This TLV contains an IPv6 address

On the 4), I will answer in a separate email.

Lionel

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : mardi 16 août 2016 23:16
> À : Alissa Cooper
> Cc : IESG; [email-masked]; MORAND Lionel
> IMT/OLN; [email-masked]; [email-masked]
> 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 <[email-masked]> wrote:
> >
> >
> >> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty
> <[email-masked]> 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 <[email-masked]>
> 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.

---

From: <[email-masked]>
Date: Tue, 6 Sep 2016 12:31:19 +0000

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 6 Sep 2016 09:15:59 -0400

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

  In this draft, yes.  Where the same sub-TLVs are used in multiple different parent TLVs.

  It's not a hard & fast recommendation.  It's just one of the little things that would be nice, if it can be done.

> Following these recommendations, the section 7.3 should be revised as follow, with a TLV-Type defined per parent attribute:

  That needs to be done, as IANA requires very specific instructions.

  My $0.02 is that I'd like to see:

IP-Port-Type-Parent-A have the same "TLV-Type" value as IP-Port-Type-Parent-B.

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

  That's not what I'm saying.

> 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 would be in for of a new registry for sub-TLVs, but only where those sub-TLVs are re-used a lot.

  As an example, let's say we had firewall rules defined in RADIUS TLVs.  Each firewall rule can specify a src/dst IP/port, for 4 different fields.  The firewall rules have an "input" set, for packets destined locally, and an "output" set, for packets destined remotely.

  Let's say we have the following definitions for "input" attributes.  I'll omit numbers for clarity, but assume that order matters:

INPUT
	SRC-IP-Input
	DST-IP-Input
	SRC-Port-Input
	DST-Port-Input

  We need to define something similar for the output rules.  We could do this:

OUTPUT
	SRC-IP-Output
	DST-IP-Output
	SRC-Port-Output
	DST-Port-Output

  Which is nice.  The sub-TLVs have the same order.

  Or, if numbering doesn't matter, we could do:

OUTPUT
	SRC-Port-Output
	DST-Port-Output
	SRC-IP-Output
	DST-IP-Output

  Or:

OUTPUT
	SRC-Port-Output
	SRC-IP-Output
	DST-IP-Output
	DST-Port-Output

  I think that either of these last two options is objectively worse than the first one.

  Note that I'm not suggesting that *all* attributes have these 4 sub-TLVs defined.  Just the attributes which define firewall rules.

  In this case, there are multiple parent attributes which define essentially the same sub-TLVs.  It would be nice to be able to re-use these these sub-TLVs, without having multiple different definitions for them.

  I hope that clarifies things.

  Alan DeKok.

---

From: <[email-masked]>
Date: Tue, 6 Sep 2016 15:03:44 +0000

Hi Alan,

" In this case, there are multiple parent attributes which define essentially the same sub-TLVs.  It would be nice to be able to re-use these these sub-TLVs, without having multiple different definitions for them."

How do you know that a newly defined sub-TLV will/may be reused or not in other (future) parent attributes?

In the document describing the new attribute, you may have a clear idea about the use in multiple parent attributes for one sub-TLV (Foo) and you may consider that another sub-TLV (Bar) will be used only once. But tomorrow, for another purpose, the sub-TLV Bar appears to be really useful and it is decided to use it in multiple (new) attributes.

How will you ensure that the same value can be reused for Bar if not reserved?

Regards,

Lionel

Le 6 sept. 2016 15:16, Alan DeKok <[email-masked]> a écrit :

INPUT
        SRC-IP-Input
        DST-IP-Input
        SRC-Port-Input
        DST-Port-Input

OUTPUT
        SRC-IP-Output
        DST-IP-Output
        SRC-Port-Output
        DST-Port-Output

OUTPUT
        SRC-Port-Output
        DST-Port-Output
        SRC-IP-Output
        DST-IP-Output

  Or:

OUTPUT
        SRC-Port-Output
        SRC-IP-Output
        DST-IP-Output
        DST-Port-Output

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 6 Sep 2016 11:11:13 -0400

> How do you know that a newly defined sub-TLV will/may be reused or not in other (future) parent attributes? 

  You know that the sub-TLVs are re-used in the current spec.  Future attributes are largely a future problem.

> How will you ensure that the same value can be reused for Bar if not reserved? 

  Which is why I agreed with the idea to create a registry for the sub-TLVs.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Sep 2016 15:22:26 +0000 (UTC)

Lionel wrote:

> My understanding is that, when defining authorization type attributes that
> are use over RADIUS, it is not deemed required to define the specific use of
> these attributes nor the error handling.

Yes and no.  While attributes can be re-used in multiple applications and use cases, the *semantics* of the authorization needs to be unambiguous.  Remember, RADIUS doesn't have the notion of applications, so the meaning of attributes needs to be idempotent, if good interoperability to to be achieved.

> As for other AAA documents, this draft is not specifying a specific procedure
> or a new protocol application. It is just about defining attributes that can
> be used in the use case described in this document but also in any other
> solution that would see advantage to reuse these attributes. 

Yes, but see above.

> The main point of this document is to ensure that the definitions of these
> attributes are correct (type, length, value), unambiguous and describe in
> which messages they can appear.

The definition of RADIUS attributes also includes their semantics, not just their syntax.

> The exact behavior of the client/server using these attributes is often left
> out of this kind of document. It is up to the specification describing the
> implementation the clients and/or servers using these attributes to define
> this error handling.

I disagree.  Leaving out semantics and client/server behavior is not traditional for RADIUS and is likely to lead to poor interoperability.

Regards,

Dave Nelson

---

From: Dean cheng <[email-masked]>
Date: Mon, 12 Sep 2016 02:55:33 +0000

Thanks for all the review and comments, but also

feedback from Lionel, Kathleen, Alan, etc. Here

is my response to some of the comments:

1) Regarding "IP-Port-Type TLV" and "transportType"

    Comment: Should include all/other port type, or

    just drop this. "transportType" unimplementable.

    Proposal: Keep this TLV, but let it be an optional

    TLV. When included, the Value portion contains

    just one port-type that is defined in Port Number<http://www.iana.org/assignments/service-names-port-numhttp:/www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtmlbers/service-names-port-numbers.xhtml>.

    Again we'll use 4-byte data type for this 16-bit

    value.

    When not included, it is a "don’t care" or applied

    to all port types.

    Doing this way would also lead us to drop the

    "transportType" proposed to be a new IE.

2) Comment: Lack of Error handling.

    Proposal: The comment basically says that if the

    Access-Accept contains something that is

    different than that in Access-Request, we need

    to handle the error. I think this should be a

    general issue within Radius protocol. RFC2865

    does not say what NAS needs to do anything if the

    Server sends an Access-Accept message that contains

    wrong/inconsistent contents respective to that

    in Access-Request.

    We could just add a statement to say the NAS

    needs to verify the content in the Access-Access

    and if the content is different/not-expected than

    that in Access-Request, should drop the message

    with no action.

    Similarly, we need to say the same to CoA-Request

    and CoA-Response handshaking.

3) Comment: Privacy concerns. This is basically

   related to the inclusion of "IP-Port-Local-Id TLV".

   "localID" as a new IPFIX IE is unimplementable.

   Proposal-1: Remove this TLV and the proposed IE.

   We're still discussing the implication among authors.

   If we've got the consensus, both comments would be

   resolved.

   Proposal-2: Keep this TLV but refine "localID" as

   a proposed new IE. For the security/privacy concern,

   note that:

     a) This TLV is optional in "IP-Port-Range Attribute", as

     said so in the draft, it needs not to be included if

     security is a concern.

     b) This TLV is an alternative to "IP-Port-Int-IPv4-Addr

     TLV" or "IP-Port-Int-IPv6-Addr TLV" to be included in

     "IP-Port-Forwarding-Map Attribute" as clearly said so

     in the draft, and so if the security is a concern, then

     don’t use it.

4) Comment: Feedback from IE experts.

    a) for "transportType", it is no longer

    an issue (see 1 above). We just drop this.

    b) for "natTransportLimit".

    We do need this IE. Let's change the name

    to transportLimit so that it does not limit

    to be used for NAT only; also, in the text

    (Section 7.1, the second bullet), say that

    this IE is used for both IPv4 and IPv6 case.

    c) for "localID", it is no longer an issue

    if we drop "IP-Port-Local-Id TLV", but otherwise

    would need to refine the definition (see 3 above).

Cheers,

Dean

> -----Original Message-----

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

> Sent: Tuesday, September 06, 2016 2:03 AM

> To: [email-masked]<mailto:[email-masked]>; Alissa Cooper

> Cc: IESG; [email-masked]<mailto:[email-masked]>; radext-

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> Subject: RE: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-

> radius-ext-11: (with DISCUSS and COMMENT)

> Here is my feedback as shepherd of the document. This needs to be

> completed by draft authors and the AD.

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

> My understanding is that, when defining authorization type attributes

> that are use over RADIUS, it is not deemed required to define the

> specific use of these attributes nor the error handling.

> As for other AAA documents, this draft is not specifying a specific

> procedure or a new protocol application. It is just about defining

> attributes that can be used in the use case described in this document

> but also in any other solution that would see advantage to reuse these

> attributes. The main point of this document is to ensure that the

> definitions of these attributes are correct (type, length, value),

> unambiguous and describe in which messages they can appear.

> The exact behavior of the client/server using these attributes is often

> left out of this kind of document. It is up to the specification

> describing the implementation the clients and/or servers using these

> attributes to define this error handling.

>    attribute carries IPFIX Information Element 230, "natEvent", which

> is

> > >>> unnecessary exposure of potentially sensitive information. There

> > >>> is no explanation given for why the combination of the other

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

> My understanding was that the IP-Port-Local-Id is required when it is

> not possible to rely on  an internal IPv4 or IPv6 address to identify

> an ongoing session.

> but authors can clarify the use of this attribute and address the

> privacy concerns.

> > De : [email-masked]<mailto:[email-masked]>

> > Cc : IESG; [email-masked]<mailto:[email-masked]>; MORAND

> > Lionel IMT/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Objet : Re:

> > Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11:

> > > On Aug 16, 2016, at 4:54 PM, Alissa Cooper <[email-masked]<mailto:[email-masked]>>

> > <[email-masked]<mailto:[email-masked]>> wrote:

> > >> 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 <[email-masked]<mailto:[email-masked]>>

> > >>> all email addresses included in the To and CC lines. (Feel free

> to

> > >>> The document, along with other ballot positions, can be found

> here:

> > >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-<https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius->

> radius-<https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius->

> > >>> ex

> > >>> -----------------------------------------------------------------

> -

> > >>> -----------------------------------------------------------------

> -

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

> > >>> that particular user? What is the CGN supposed to do and how is

> > >>> that communicated back to the AAA server?

> > >>> encompasses a larger range than a previously sent IP-Port-Limit-

> Info?

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

> > >>> erroneous identification could be severe for the user. Discussion

> > >>> of those consequences is also missing from Section 6.

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

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

> > >> applies to a few of your other discuss points as well, namely #2,

> > >> #5, and to some degree #3.

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

> > >>> unnecessary exposure of potentially sensitive information. There

> > >>> is no explanation given for why the combination of the other

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

> > >>> considered as valid and the WG has decided to let IANA decide

> what

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

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

> > >>> -----------------------------------------------------------------

> -

> > >>> -----------------------------------------------------------------

> -

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

> _______________________________________________________________________

> __________________________________________________

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 12 Sep 2016 13:39:18 -0400

Hi Lionel,

> On Sep 6, 2016, at 5:03 AM, [email-masked] wrote:
> 
> Hi Alissa,
> 

Are there plans to specify the client-server interaction in a standardized way? I can see why the sort of error-handling I described might not fit in this document, but I don’t know how we end up with interoperable clients and servers if there isn’t a standardized understanding of the error handling.

>   TLV, no other value is used.

Got it, apologies for missing this.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 12 Sep 2016 13:49:37 -0400

Hi Lionel,

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

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

---

From: <[email-masked]>
Date: Tue, 13 Sep 2016 13:23:59 +0000

Hi Alan,

If such a registry is defined by the WG and managed by the IANA, to ensure that a newly-defined sub-TLV can be reused in any parent TLV, we are limiting de-facto the number of possible sub-TLV values to 253 values (254-255 being anyway reserved for future use)?
Moreover, an update of the allocation policy given in the RFC6929 sect. 10.3.6 would be required.

In comparison, according to the RFC6929, it is possible to define up to 253 sub-TLV *per* TLV attributes at the first level. It means that it is theoretically possible to define approximatively  up to +/- 380.000 distinct sub-TLV at the first level.
I think that limiting to 253 values just to enable to use the same sub-TLV in multiple parent attribute is too restrictive. 

If one solution has to choose, I would go with the most flexible one.

regards,

Lionel

> De : Alan DeKok [mailto:[email-masked]]
> Envoyé : mardi 6 septembre 2016 17:11
> À : MORAND Lionel IMT/OLN
> Cc : [email-masked]; Alissa Cooper; draft-ietf-radext-ip-port-
> [email-masked]; [email-masked]; IESG; [email-masked]
> Objet : Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-
> ext-11: (with DISCUSS and COMMENT)
> 
> > " In this case, there are multiple parent attributes which define essentially the
> same sub-TLVs.  It would be nice to be able to re-use these these sub-TLVs,
> without having multiple different definitions for them."
> >
> > In the document describing the new attribute, you may have a clear idea about
> the use in multiple parent attributes for one sub-TLV (Foo) and you may consider
> that another sub-TLV (Bar) will be used only once. But tomorrow, for another
> purpose, the sub-TLV Bar appears to be really useful and it is decided to use it in
> multiple (new) attributes.
> >

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Sep 2016 09:39:37 -0400

> On Sep 13, 2016, at 9:23 AM, <[email-masked]> <[email-masked]> wrote:
> If such a registry is defined by the WG and managed by the IANA, to ensure that a newly-defined sub-TLV can be reused in any parent TLV,

  No.  Those sub-TLVs can only be re-used in *appropriate* parent TLVs.  The parents need to specify that they are using the common registry.  All other TLV parents are free to specify whatever sub-TLVs they want.

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 15 Sep 2016 16:41:57 +0000

Hi Dave,

Please see below.

Regards,

Lionel

> De : David B. Nelson [mailto:[email-masked]]
> Envoyé : mardi 6 septembre 2016 17:22
> Cc : kathleen moriarty ietf; Alissa Cooper; draft-ietf-radext-ip-port-radius-
> [email-masked]; [email-masked]; IESG; [email-masked]
> Yes and no.  While attributes can be re-used in multiple applications and use
> cases, the *semantics* of the authorization needs to be unambiguous.
> Remember, RADIUS doesn't have the notion of applications, so the meaning of
> attributes needs to be idempotent, if good interoperability to to be achieved.

[LM] I agree. Especially on the semantic issue.

> > but also in any other solution that would see advantage to reuse these

[LM] ok.

> 
> > The main point of this document is to ensure that the definitions of
> > these attributes are correct (type, length, value), unambiguous and
> > describe in which messages they can appear.
> 
> > The exact behavior of the client/server using these attributes is
> > often left out of this kind of document. It is up to the specification
> I disagree.  Leaving out semantics and client/server behavior is not traditional
> for RADIUS and is likely to lead to poor interoperability.

[LM] I think that there is what it could be and what it is. As I said, I agree with your comment on the format and the semantic of the attributes. But on client/server behavior and error handling, you can check for instance with RFC7268 and RFC6911 (other standards track RFCs defining RADIUS attributes) that these aspects are not always addressed. It depends on who is the real "client" of the specification. In the present case, the attributes are only used for configuration or reporting, not strictly related to the authorization process.   
Now, if authors want to address these points in the draft, I will be fine. But I'm not convinced it is required to be published as RFC.