Re: [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS)

[<[e-mail]>]

Hi Mirja, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind [mailto:[e-mail]]
> Envoyé : mercredi 12 octobre 2016 15:55
> À : BOUCADAIR Mohamed IMT/OLN; The IESG
> Cc : [e-mail]; MORAND Lionel IMT/OLN;
> [e-mail]; [e-mail]
> Objet : Re: [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-
> port-radius-ext-11: (with DISCUSS)
> 
> Hi Mohamed,
> 
> thanks for these changes. Using the IANA protocol number seems to be the
> right thing to do!

[Med] Great!

> 
> One tiny additional question/comment: the term "IP port" or "IP transport
> port" seems a little weird (because ports are in the transport header and
> not
> in the IP header). Is it important to use this term to indicate that it's
> IP
> underneath or could you simply speak about "transport ports" instead?

[Med] We used "IP" on purpose to avoid that the term "port" is misunderstood as referring to a physical port. Using simply "transport port" does not help either to clarify that confusion. This is why we went for explicitly using "IP xxx" to make it clear we are dealing with port numbers that are used by protocols transported over IP.

> 
> Thanks!
> Mirja
> 
> 
> On 29.09.2016 08:44, [e-mail] wrote:
> > Dear Mirja,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : radext [mailto:[e-mail]] De la part de Mirja
> >> Kuehlewind
> >> Envoyé : mercredi 17 août 2016 16:04
> >> À : The IESG
> >> Cc : [e-mail]; MORAND Lionel
> IMT/OLN;
> >> [e-mail]; [e-mail]
> >> Objet : [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-
> port-
> >> radius-ext-11: (with DISCUSS)
> >>
> >> Mirja Kühlewind 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-ext/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> I fully support Alissa's discussion points and have two more to add:
> >>
> >> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very
> >> future-proof: there are other transport protocols that have ports or
> >> identifiers that may want to be supported in future.
> >
> > [Med] This is a fair comment. FWIW, only TCP/UDP/ICMP are covered
> initially in the draft because those are currently the only ones supported
> by widely deployed CGNs.
> >
> >  Also it is not clear
> >> to me from the document why this information is needed at all in the
> >> described use cases.
> >
> > [Med] Because ports are bound to a transport protocol (e.g., of the port
> forwarding in Section 4.1.3). In modern NATs, when an (explicit/implicit)
> mapping is created, a port is reserved only for a given transport protocol
> not for all transport protocols.
> >
> >  Therefore I see two possible ways forward: Either
> >> remove the IP-Port-Type TLV or extend it to also cover other cases.
> >
> > [Med] The new version of the draft extends the TLV to be applicable to
> other transport protocols. We are using the IANA protocol numbers
> (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
> >
> >>
> >> Related to this point I would like to mention that RFC6887 is not
> >> restricted to UDP/TCP and therefore the following sentence in section 2
> >> is not correct:
> >> "Note that the definitions of [...] "internal port", [...] "external
> >> port" [...] are the same as defined in Port Control Protocol (PCP)
> >> [RFC6887]"
> >
> > [Med] This is not an issue given that the new version of the draft is
> not restricted to TCP/UDP.
> >