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

[<[e-mail]>]

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