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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 27, 2017 at 6:00 AM, Eric Rescorla <[e-mail]> wrote:

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

Replying to myself (and in light of Benoit's comments).

The advantage of ALPN is that it would let outgoing firewall devices do
some kind
of filtering even for the TLS traffic (which of course will not be possible
if you
use non-NULL ciphers which you will have to for 1.3).

-Ekr


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