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

[Eric Rescorla <[e-mail]>]

AFAICT there are two separate issues:

- The use of 4500, which, as Tero says, we can just update the registry to
point to this document for.
- The use of 443, which seems more complicated

WRT 443, I would assert the following facts:

- It's not awesome that people use 443 (though understandable because of
overly-aggressive firewalls)
- People aren't going to stop using 443 (because it goes through NATs well)

Generally, I think it's more useful for documents to reflect reality, even
if we don't like that reality,
and 443 only appears in the appendix, so that seems fairly innocuous to me.
Perhaps we can
leave the 443 in the appendix with some note like:

"Note: While port 4500 is the reserved port for this protocol, some
existing implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"

What would people think about that?

Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
wiggle room
to specify ALPN here? Or maybe a longer prefix?

-Ekr


On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen <[e-mail]> wrote:

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