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

[Dean cheng <[e-mail]>]

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

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

> To: [e-mail]<mailto:[e-mail]>; Alissa Cooper

> Cc: IESG; [e-mail]<mailto:[e-mail]>; radext-

> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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

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

>

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

> > [mailto:[e-mail]]

> > Envoyé : mardi 16 août 2016 23:16

> > À : Alissa Cooper

> > Cc : IESG; [e-mail]<mailto:[e-mail]>; MORAND

> > Lionel IMT/OLN; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>

> wrote:

> > >

> > >

> > >> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty

> > <[e-mail]<mailto:[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]<mailto:[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-<https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius->

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