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

[Eric Rescorla <[e-mail]>]

On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly <[e-mail]> wrote:

>
> On Apr 26, 2017, at 12:51 PM, Eric Rescorla <[e-mail]> wrote:
>
> 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?
>
>
> That sounds good to me. I think we may want to mention that the Stream
> Prefix is used to distinguish from any other protocols running on port
> 4500, etc, not really specifically to 443.
>

Good point.


Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
> wiggle room
> to specify ALPN here? Or maybe a longer prefix?
>
>
> The document's text regarding ALPN is in section 4:
>
> "Although some framing protocols do support negotiating inner protocols,
> the stream prefix should always be used in order for implementations to be
> as generic as possible and not rely on other framing protocols on top of
> TCP."
>
> The idea is that we don't want to use TLS as a wrapper whenever possible.
> An implementation on an IKE server may be behind a proxy or another process
> that's terminating the TLS or raw TCP, and passing the inner stream along.
> In that case, we wanted a standard way to put IKE and ESP in a stream, not
> relying on an outer protocol's details.
>

I get that, but it is a bit unfortunate to be relying on this inband
signaling.



> I'm perfectly open to using another prefix value; if you have a suggestion
> for a longer value, that would be great!
>

I think I'd probably ask MT or mnot, but my instinct would be to use some
randomly chosen string
that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just
reduces the chance of
any kind of accidental collision. I don't think it's a dealbreaker.

-Ekr




> Thanks,
> Tommy
>
>
> -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]
>>
>>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>