Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tero Kivinen <[e-mail]>]

Tommy Pauly writes:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > This draft suggests that ports that are assigned to other services can
> > simply be used. This is not okay. If a port is assigned to a certain
> > service, this service and/or the respective RFC defines how this port is
> > used. Simply changing the specified behavior by requiring a check for a
> > magic number cannot be done without updating the RFC that the port
> > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
> > the IANA registry would need to be updated.
> 
> At this point, the only portion of the document that mentions a port
> other than 500 and 4500 is the appendix. We recommend that 4500 is
> used as the port for TCP encapsulation. The IANA registry for
> 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> that document does not explain how TCP is to be used, so the
> reference should be updated to point to the document on TCP
> encapsulation. 

I already explained this in long email to the Joe and Paul, but
noticed that those emails did not go to to the IESG, so this is mostly
cut & paste of my previous email. This does not cover anything about
using any other ports, but covers the case about the IANA allocations
for TCP/4500 and UPD/4500.

----------------------------------------------------------------------
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is already
> > owned and under the control of each assigned port. It is not
> > appropriate for any new service to hijack that pattern as having a
> > different meaning UNLESS explicitly updating the service on 
> > that port.
> >
> > A simple summary of what needs to change, in 2119-language:
> >
> >    - this approach MUST NOT be described as applying to any
> >    	 assigned number unless also updating the associated RFC
> 
> So it should add an Updates: RFC-3947

Not really. It does not update RFC3947 as it does not change the
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

> It's a little weird. 3947 reserved TCP 4500, but did not specify how
> to actually use TCP at all. It seems it was mostly preventatively
> reserved.

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late. 

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

         Keyword       Decimal    Description          Reference
         -------       -------    -----------          ---------
         ipsec-nat-t   4500/tcp   IPsec NAT-Traversal  [RFCXXXX]
         ipsec-nat-t   4500/udp   IPsec NAT-Traversal  [RFC3948], [RFC7296]

(RFCXXXX being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
-- 
[e-mail]