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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 25 Apr 2017 05:48:12 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: 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-ipsecme-tcp-encaps/

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

Further, as also mentioned in the tsv-art review (Thanks Wes!), this
draft does not sufficiently handle the case of TCP in TCP encapsulation.
Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

This document is clear and well-written.  It can easily be implemented
based on the description.

There are a few additional issues that should be considered with
advice to implementers in Section 12 on performance considerations:
1) Invisibility of packet loss - Inner protocols that require packet
losses as a signal of congestion (e.g. TCP) will have a challenge due
to not being able to see any packet losses since the outer TCP will
repair them (unless sending into a full outer TCP socket buffer shows
up back to the inner TCP as a packet loss?).
2) Nesting of ECN -  Inner TCP connections will not be able to use
effectively ECN on the portion of the path covered by the outer TCP
connection.
3) Impact of congestion response on aggregate - The general "TCP in
TCP" problem is mentioned, and is mostly appropriate for a single
flow.  If an aggregate of flows is sharing the same outer TCP
connection, there may be additional concerns about how the congestion
response behavior impacts an aggregate of flows, since it may cause a
shared delay spike even to low-rate flows rather than distributing
losses proportional to per-flow throughput.
4) Additional potential for bufferbloat - Since TCP does not bound
latency, some applications in the IPsec-protected aggregate could
drive latency of the shared connection up and impact the aggregate of
flows that may include real-time applications.  The socket buffer for
the outer TCP connection might need to be limited in size to ensure
some bounds?

Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

In the security considerations section, there are several RFCs on
mechanisms to increase robustness to RST attacks and SYN floods that
could be mentioned if it's worthwhile.

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 25 Apr 2017 20:28:09 -0700

> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind <[email-masked]> wrote:
> 

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.

We can soften the references in the appendix to the fact that other ports may, in fact, be used. As for the configuration, it should state 4500 as the default, but allow peers to configure something else out-of-band if they want to modify behavior (which is standard even in UDP implementations of IKE).

> up back to the inner TCP as a packet loss?).

Yes, this is definitely true. We try to capture that with the line: "This will make loss-
   recovery of the inner TCP traffic less reactive and more prone to
   spurious retransmission timeouts."

However, this can certainly be expanded upon.

> effectively ECN on the portion of the path covered by the outer TCP

Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings between inner/outer packets. Since TCP encapsulation places the inner IP packets in a stream, there isn't a direct mapping.

An implementation could try to roughly map, but it may be best to suggest that the ECN markings for inner and outer packets be left separate. What is your opinion?

> losses proportional to per-flow throughput.

Indeed. We can add further comments to that effect.

> the outer TCP connection might need to be limited in size to ensure

We can add a comment to suggest that the buffering should be limited on the outer connection if possible.

> implementations make wrong assumptions or fail to consider them.

I do think all of these concerns go back to the overall recommendation of "use direct ESP or UDP Encapsulation whenever possible". Anything to help back up that point is great!

Thanks,
Tommy
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Apr 2017 13:46:42 +0300

Tommy Pauly writes:
> 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...
-- 
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Apr 2017 12:51:01 -0700

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

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 26 Apr 2017 14:29:12 -0700

> On Apr 26, 2017, at 12:51 PM, Eric Rescorla <[email-masked]> wrote:
> 
> - The use of 4500, which, as Tero says, we can just update the registry to point to this document for.
> - It's not awesome that people use 443 (though understandable because of overly-aggressive firewalls)
> 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
> "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

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.

> 
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be wiggle room

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'm perfectly open to using another prefix value; if you have a suggestion for a longer value, that would be great!

Thanks,
Tommy

> 
> -Ekr
> 
> 
> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen <[email-masked] <mailto:[email-masked]>> wrote:
> Tommy Pauly writes:
> [email-masked] <mailto:[email-masked]>
> 
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 10:32:37 +0200

Hi Tommy,

please see below, only on the first point for now.

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

So at least section 11 talks about port 80 as well. It doesn't explicitly 
recommend to use it, but because it's discussed there I would say that this 
is implicitly the intention:

"A network device that monitors up to the application layer will
    commonly expect to see HTTP traffic within a TCP socket running over
    port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE),
    this could be dropped by the security device."

Further it's clear that the whole intention on the existence of section 4 is 
that you want to (mis)use ports that have been assigned for other services 
and are for that reason potentially not blocked.

The (processing) problem here is that even if the bit pattern in section 4 is 
currently not used and unlikely to ever be used by the protocol that is 
officially assigned to the port, there is nothing that excludes a future 
protocol spec to use these bits (and there is also nothing that makes 
designer of these protocols aware that these bits are already in use by a 
different protocol on the same port). So the minimum you basically would need 
to do is to update all RFCs for protocols on ports that you may want to use 
(and probably also the IANA registry for these ports to add a refernce to 
this document) and say that it is not possible to use this bit patter for the 
protocol itself and all future version of it. Of course you probably would 
need to involve those working groups that maintain these protocols and I also 
not sure how happy those groups would be about such an update.

I personally think that that is not a nice solution and if you e.g. want to 
use port 80 for IKE, you would need to define an IKE variant over HTTP/TCP. 
That doesn't sound great and I'm not sure if that a solution anybody would 
like to implement.

I do see the problem you have and I understand why you selected the solution 
you have but that does contradict quite a bit the idea of the port registry 
and I don't think it's a safe and future prove solution. Even if people use 
this approach, I'm concern to publish it in an Standards Track RFC, but I 
guess that's a discussion the IESG would need to have.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 27 Apr 2017 07:33:49 -0500

Not my discuss, but since I'm also supposed to worry about ports :-)

On Thu, Apr 27, 2017 at 3:32 AM, Mirja Kühlewind <[email-masked]>
wrote:

>> 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 understand Mirja's point, and I understand why the draft doesn't tie the
protocol to one assigned port.

>
> Further it's clear that the whole intention on the existence of section 4
> is that you want to (mis)use ports that have been assigned for other
> services and are for that reason potentially not blocked.
>
> The (processing) problem here is that even if the bit pattern in section 4
> is currently not used and unlikely to ever be used by the protocol that is
> different protocol on the same port). So the minimum you basically would
> need to do is to update all RFCs for protocols on ports that you may want
> to use (and probably also the IANA registry for these ports to add a
> refernce to this document) and say that it is not possible to use this bit
> patter for the protocol itself and all future version of it. Of course you
> probably would need to involve those working groups that maintain these
> protocols and I also not sure how happy those groups would be about such an
> update.
>

What I'm thinking, is that this isn't a problem we can solve, draft by
draft.

Assuming that https://datatracker.ietf.org/doc/rfc3986/referencedby/ is a
reasonable proxy, the datatracker returns 775 documents that reference the
RFC that defines the URI scheme, which includes
https://tools.ietf.org/html/rfc3986#section-3.2.3, allowing the application
to specify a port which (of course) could be assigned to another protocol
in
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
.

That's a worst-case scenario, of course (some RFCs weren't deployed, some
are probably obsoleted by other RFCs, etc.), but I'm betting the number of
protocols with the same issue as HTTP(S) has here is somewhere in the
hundreds.

>
> I personally think that that is not a nice solution and if you e.g. want
> to use port 80 for IKE, you would need to define an IKE variant over
> HTTP/TCP. That doesn't sound great and I'm not sure if that a solution
> anybody would like to implement.
>
> I do see the problem you have and I understand why you selected the
> solution you have but that does contradict quite a bit the idea of the port
> registry and I don't think it's a safe and future prove solution. Even if
> people use this approach, I'm concern to publish it in an Standards Track
> RFC, but I guess that's a discussion the IESG would need to have.

So, yes, I agree with this, and suggest that we start that discussion on
next week's informal telechat.

But, to try to make progress on this Discuss ...

The reason optional ports in URIs work, is that someone handed you a URI
with that port number who has some reason to believe that the port number
is OK to use with the host included in the URI.

Is that a reasonable assumption about the way IPsec and IKE over TCP will
be deployed? That no Initiator would assume that another host is an IKE
Responder, without being configured to use that host?

Curiously,

Spencer

> Mirja
>
>
>
>> We can soften the references in the appendix to the fact that other ports
>> may, in fact, be used. As for the configuration, it should state 4500 as
>> the default, but allow peers to configure something else out-of-band if
>> they want to modify behavior (which is standard even in UDP implementations
>> of IKE).
>>
>>
>> Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings
>> between inner/outer packets. Since TCP encapsulation places the inner IP
>> packets in a stream, there isn't a direct mapping.
>>
>> An implementation could try to roughly map, but it may be best to suggest
>> that the ECN markings for inner and outer packets be left separate. What is
>> your opinion?
>>
>> I do think all of these concerns go back to the overall recommendation of
>> "use direct ESP or UDP Encapsulation whenever possible". Anything to help
>> back up that point is great!
>>
>> Thanks,
>> Tommy
>>
>>>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Apr 2017 15:46:40 +0300

> - The use of 443, which seems more complicated

Yes. 

> - People aren't going to stop using 443 (because it goes through NATs well)

Especially as this has already been specified by the 3gpp TS.24.302
[1], [2].

One of the reasons we are doing this is that 3GPP defined how to run
IPsec over TCP, and they decided to use port 443 and TLS framing for
that (or HTTP proxy supporting HTTPCONNECT).

I.e., they specified firewall traversal that will make TCP connection
to port 443 of the ePDG address, and do normal TLS handshake over
that, and then run TCP stream over that which will have IKEv2 and ESP
frames similar what is defined here.

When IPsec WG decided this is something that should be standardized
for general use, we took that but we did not want to limit it to port
443 and TLS framing only, so we decided that we would define it mostly
on port TCP/4500 without TLS.

The original draft had text about the TLS in main body, but as it was
moved to Appendix during the working group process.

So regardless what we do here 3GPP will be running IPsec over TLS over
TCP port 443 (i.e., IPsec, not HTTP inside the TLS).

To be aligned with them we did for example change the length field
before the messages to be 16-bit instead of original 32-bits. On the
other hand we did add IKETCP stream prefix there, as that allows us to
detect this is IETF version of the IPsec over TCP, not some
proprietary or 3gpp method done before (just in case there are other
differences we did not spot). 

[1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1073
[2] http://www.3gpp.org/ftp//Specs/archive/24_series/24.302/24302-e30.zip

> 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

This was the reason why WG originally wanted to move it to Appendix,
and not remove it completely. 

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

I think that text would be fine for me at least (but I am not author
of this draft). 

> 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 stream prefix is done also on the port 4500 or any other
configured port, and those will not use TLS. Only the port 443 (or
other configured ports defined to use TLS) will use TLS. Also the TLS
wrapper before the IPsec / IKE might be completely sepearate module,
and transferring things from there to IPsec module might be hard.

The stream prefix is also inside the TLS wrapping (see B.1. example),
i.e., it is the first bytes that come from the stream coming out from
the TLS after the TLS handshake is finished. So for the IPsec module,
it does not need to know whether there was TLS warpping around the TCP
stream or not, it will get stream of octets starting with "IKETCP",
and then followed by IKE or ESP packets.

Also, note, that responder might use the fact that when new connection
comes in and it starts with "IKETCP" as indication that there is no
TLS wrapping around the frames, and give them directly to IPsec
module. If there is something else, then it might try to do TLS
handshake and if that successed, then check if inside the TLS there is
"IKETCP" stream prefix and if so, then give that data to the IPsec
module. This is something they could do on any port they are
configured to listen, not only port 4500 or 443. Or it could be they
are configured so that port 4500 is always without TLS framing, port
443 is always with TLS framing, and other configured ports have
automatic TLS detection and processing enabled....
-- 
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 05:51:39 -0700

> RFC, but I guess that's a discussion the IESG would need to have.

Mirja,

I agree that this kind of port squatting is regrettable, but I also don't
think it really
helps to not publish RFCs that document widely used protocols because we
are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the following

We could do something similar for port 80.

Would that work?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 06:00:17 -0700

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

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

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 06:01:43 -0700

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

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 15:42:48 +0200

Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one now to 
partly also reply to others).

See below.

On 27.04.2017 14:51, Eric Rescorla wrote:
>
>
> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     solution you have but that does contradict quite a bit the idea of the
>     port registry and I don't think it's a safe and future prove solution.
>     Even if people use this approach, I'm concern to publish it in an
>     Standards Track RFC, but I guess that's a discussion the IESG would need
>     to have.
>
>
> Mirja,
>

This already is good but I think it's not enough. As Tero noted the working 
group thought that they rather specify a generic scheme which I find 
problematic. Currently the drafts says:

"This document leaves the selection of TCP ports up to
    implementations.  It is suggested to use TCP port 4500, which is
    allocated for IPsec NAT Traversal."

Which sounds to me like an invitation to squat on any open port regardless 
what the port is supposed to be used for (hoping that the magic number would 
avoid any collision). I don't think that a good thing to right in an RFC.

Now given the text you propose above, I actually assume that the text I just 
cited will be removed but the whole document is written with this assumption 
and therefore there are a couple more places where wording probably needs to 
change.

I do understand well the problem and that 443 is used in practice. However, 
to match reality I would rather like to see a document that specifies the 
approach of encapsulating in TLS/TCP on port 443 that is used today and pure 
TCP encapsulation for use with port 4500 only. Again i think that's where 
your proposed text is heading to but I think it needs more changes; in this 
case it would also make sense to add the TLS part back in the main document 
for 443 only.

Further, I have one more question: The document is written in a way that 
allows the implementation of multiple services on the used port. Is that 
actually done in reality? If we could restrict the use of this encapsulation 
with servers that only are IKE servers (at least for the used port), you 
would actually not need the magic number anymore. I guess you can still have 
the magic number if you really want it because that makes it easier to 
distinguish valid IKE/IPSec traffic from other random traffic that might be 
send to this port but the other service running on this port (on other 
servers) does not need to know about the magic number because it is supposed 
to never see any IKe/IPSec TCP-encapsulated traffic.

Does that make sense?

Mirja

>
> -Ekr
>
>
>
>
>     Mirja
>
>
>
>         We can soften the references in the appendix to the fact that other
>         ports may, in fact, be used. As for the configuration, it should
>         state 4500 as the default, but allow peers to configure something
>         else out-of-band if they want to modify behavior (which is standard
>         even in UDP implementations of IKE).
>
>
>         Generally, IPsec tunnels will apply RFC 6040 for translating ECN
>         markings between inner/outer packets. Since TCP encapsulation places
>         the inner IP packets in a stream, there isn't a direct mapping.
>
>         An implementation could try to roughly map, but it may be best to
>         suggest that the ECN markings for inner and outer packets be left
>         separate. What is your opinion?
>
>         I do think all of these concerns go back to the overall
>         recommendation of "use direct ESP or UDP Encapsulation whenever
>         possible". Anything to help back up that point is great!
>
>         Thanks,
>         Tommy
>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/ipsec>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipsec>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 06:50:10 -0700

On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <[email-masked]>
wrote:

> One more side comment on the magic number: actually the magic number makes
> it easy for network operator to identify IKE/IPSec traffic on any port and
> block all packets that below to a flow that started with this pattern in
> the first payload packet. So if you really think you need a magic number,
> you should probably always encrypt it.
>
>
My impression was that the point of this was not to evade future operators
who are trying to block IKE, but merely to deal with the problem of
over-aggressive
middleboxes which currently block IKE, mostly accidentally. Certainly
that's how
we think of things over in WebRTC land.

-Ekr

> On 27.04.2017 15:42, Mirja Kühlewind wrote:
>
>> Hi Ekr, hi all,
>>
>>> existing
>>> implementations
>>>         Yes, this is definitely true. We try to capture that with the
>>> line:
>>>         "This will make loss-
>>>         We can add a comment to suggest that the buffering should be
>>> limited
>>>         on the outer connection if possible.
>>>
>>>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Apr 2017 16:50:57 +0300

Spencer Dawkins at IETF writes:
> The reason optional ports in URIs work, is that someone handed you a URI with
> that port number who has some reason to believe that the port number is OK to
> use with the host included in the URI.
> 
> Is that a reasonable assumption about the way IPsec and IKE over TCP will be
> deployed? That no Initiator would assume that another host is an IKE

I have been using following matrix to understand the IETF security
protocols:

+---------------------+-----------------------+------------------+
| 		      |	"Kernel" mode	      |	Application mode |
+---------------------+-----------------------+------------------+
| Pre-configuration   | IPsec                 | Secure Shell     |
| required            |                       |                  |
+---------------------+-----------------------+------------------+
| No per host         | HIP                   | SSL/TLS          |
| pre configuration   | /                     |                  |
| needed /            | TCPINC                |                  |
| opportunistic       |                       |                  |
+---------------------+-----------------------+------------------+

Kernel mode means it is implemented inside the operating system kernel
or libraries, and Application mode means it is part of the application
level implementation.

Pre-configuration required means that both ends needs to be
pre-configured to accept the connection. I.e., there is no point of
trying to use ssh to connect host kivinen.iki.fi unless you have
account and some method of authentication token for that host. Same
with IPsec, you cannot assume that other end talks IPsec and allows
you to connect unless you have pre-configured both ends to support it.

Even when using opportunistic IPsec this is mostly same, there is no
point of even trying to use opportunistic IPsec to www.google.com, and
assume it would work. It might be that at some day we are there, and
we have opportunistic IPsec installed in every single host, but we are
not there now, and main use of IPsec is with pre-configuration.

With HIP and TCPINC you always assume that you simply connect the
other end and you do not need per host configuration. The connection
either works or not, and if not you fall back to TCP (TCPINC), or just
fail (with HIP adding configuration might help).

With TLS you can just assume that other end allows you to connect if
it supports TLS at all, and this is because everybody is
"pre-configured" with same trusted anchor list, but there is no need
for per-host configuration.

So short answer to your question is: IPsec do require
pre-configuration, so if configuration says that IP address x.y.z.0
talks IPsec over TCP on port 1234, then you do that. If there is no
configuration then you usually just fail, as you do not know what
authentication credentials you are supposed to use.
-- 
[email-masked]

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 15:46:17 +0200

One more side comment on the magic number: actually the magic number makes it 
easy for network operator to identify IKE/IPSec traffic on any port and block 
all packets that below to a flow that started with this pattern in the first 
payload packet. So if you really think you need a magic number, you should 
probably always encrypt it.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 27 Apr 2017 08:56:52 -0500

Tero,

Top-posting, because I'm only saying "thank you, that's very helpful".

Spencer

On Thu, Apr 27, 2017 at 8:50 AM, Tero Kivinen <[email-masked]> wrote:

> with

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 16:03:04 +0200

Yes, just saying...

On 27.04.2017 15:50, Eric Rescorla wrote:
>
>
> On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <[email-masked]
>     One more side comment on the magic number: actually the magic number
>     makes it easy for network operator to identify IKE/IPSec traffic on any
>     port and block all packets that below to a flow that started with this
>     pattern in the first payload packet. So if you really think you need a
>     magic number, you should probably always encrypt it.
>
>
> middleboxes which currently block IKE, mostly accidentally. Certainly that's how
>     On 27.04.2017 15 <tel:27.04.2017%2015>:42, Mirja Kühlewind wrote:
>
>         Hi Ekr, hi all,
>
>         On 27.04.2017 14 <tel:27.04.2017%2014>:51, Eric Rescorla wrote:
>
>
>
>             On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             "Note: While port 4500 is the reserved port for this protocol,
>             some existing
>             implementations
>                         This document is clear and well-written.  It can
>             easily be
>                         implemented
>                     Yes, this is definitely true. We try to capture that with
>             the line:
>                     "This will make loss-
>                     We can add a comment to suggest that the buffering should
>             be limited
>             <mailto:[email-masked] <mailto:[email-masked]>>
>                         <https://www.ietf.org/mailman/listinfo/ipsec
>             <https://www.ietf.org/mailman/listinfo/ipsec>>
>
>
>
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>                 <https://www.ietf.org/mailman/listinfo/ipsec
>             <https://www.ietf.org/mailman/listinfo/ipsec>>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 07:10:04 -0700

On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <[email-masked]>
wrote:

> Hi Ekr, hi all,
>
> (not sure anymore which email best to reply to but I'm using this one now
> to partly also reply to others).
>
> See below.
>
> This already is good but I think it's not enough. As Tero noted the
> working group thought that they rather specify a generic scheme which I
> find problematic. Currently the drafts says:
>
> what the port is supposed to be used for (hoping that the magic number
> would avoid any collision). I don't think that a good thing to right in an
> RFC.
>

Hmm... Maybe I don't understand your overall theory here. It seems like
having
reserved ports for protocols but letting people run them on any port they
want
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.7.1

"  If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address. If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server. If the port
   subcomponent is empty or not given, TCP port 80 (the reserved port
   for WWW services) is the default."

-Ekr

> Now given the text you propose above, I actually assume that the text I
> just cited will be removed but the whole document is written with this
> assumption and therefore there are a couple more places where wording
> probably needs to change.
>
> I do understand well the problem and that 443 is used in practice.
> However, to match reality I would rather like to see a document that
> specifies the approach of encapsulating in TLS/TCP on port 443 that is used
> today and pure TCP encapsulation for use with port 4500 only. Again i think
> that's where your proposed text is heading to but I think it needs more
> changes; in this case it would also make sense to add the TLS part back in
> the main document for 443 only.
>
> actually done in reality? If we could restrict the use of this
> encapsulation with servers that only are IKE servers (at least for the used
> port), you would actually not need the magic number anymore. I guess you
> can still have the magic number if you really want it because that makes it
> easier to distinguish valid IKE/IPSec traffic from other random traffic
> that might be send to this port but the other service running on this port
> (on other servers) does not need to know about the magic number because it
> is supposed to never see any IKe/IPSec TCP-encapsulated traffic.
>
> Does that make sense?
>
> Mirja
>
>
>
>
>> -Ekr
>>
>>
>>
>>
>>     Mirja
>>
>>
>>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Apr 2017 17:12:10 +0300

> avoid any collision). I don't think that a good thing to right in an RFC.

Note, that configurations can only use ports which are defined to be
used by the responder. I.e., if the responder is configured to listen
port 4500 and port 443 (with TLS wrapping), there is no point of
initiator to try port 80, as it will not work.

I.e., in practice this will end up the operators picking suitable
number of port numbers they will configure their system to respond to,
and most likely they will try to use services which are not in use
normally by the responder. I.e., if the responder is running
web-server, it cannot very easily also use the port 80 (or 443) for
the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some
other random ports which might go through the filters which are
already blocking all UDP traffic, and at least port 4500 for TCP.

So this is same thing we have now in web. I am quite often running web
servers on random ports just because some places have had filters
blocking some ports. For example one of my friends company network
blocked connection to port 8080, but did not block connections to port
2020, so my web server was running (also) on that port...

So unless you are saying "TCP/UDP ports on all protocols MUST NOT be
configurable, and only port numbers reserved for those services are
allowed" there is nothing we can really do.

(and even if you say that, nothing is going to change, as people are
so used to getting past stupid firewalls). 

> case it would also make sense to add the TLS part back in the main document 

This is what the document tries to say. I.e., for some ports (like
443), there might be some other framings (like TLS) in place, and for
other ports there might not be. As IPsec will require
pre-configuration this information which ports are used, and what
framing protocol is used comes from the configuration. 

> actually done in reality?

Yes and no. There are some old IKEv1 based proprietary TCP
encapsulation methods, and I think some of those might actually use
port 500 and perhaps also port 4500. So vendor implementing those,
might want to do multiplexing based on whether there is the stream
prefix in front or not to see whether the old proprietary method is
used, or the one defined in document is used.

Another issue might be that the SGW terminating the TCP 443
connection, might also support some proprietary TLS VPN implementation
and differntiating from that is also something I can see that vendors
might want to do.

So I do not know if anybody is really do it now, but I can see reasons
why people might want to multiplex the proprietary things they are now
running on those ports 500/4500/443 with the standard we are defining
here.

> If we could restrict the use of this encapsulation 

If it is operationally possible, and there is no old proprietary
protocols to be supported, I would assume most implementations would
not want to bother with the multiplexing different protocols on one
port.

I.e., new implementations and new setups will most likely then move
for example the adminstative interface over https to separate
IP-address, just to make sure that it is easier to implement and
operate.
-- 
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 07:27:11 -0700

On Thu, Apr 27, 2017 at 7:21 AM, Mirja Kühlewind <[email-masked]>
wrote:

> See below.
>
> On 27.04.2017 16:10, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <[email-masked]
>>         <mailto:[email-masked]>
>>             solution you have but that does contradict quite a bit the
>> idea
>>         of the
>> some
>>     Which sounds to me like an invitation to squat on any open port
>>     regardless what the port is supposed to be used for (hoping that the
>>     magic number would avoid any collision). I don't think that a good
>> thing
>>     to right in an RFC.
>>
>>
> This doesn't say you can/should use any port you want (it says you can use
> another port than 80) but you should till avoid to use any other port that
> runs a different TCP service.
>

Well, that may be part of your background assumptions, but the document
doesn't say that. It just tells you how to use a different port and is
silent on
what port you should use.

-Ekr

>>     specifies the approach of encapsulating in TLS/TCP on port 443 that is
>>     used today and pure TCP encapsulation for use with port 4500 only.
>> Again
>>     i think that's where your proposed text is heading to but I think it
>>     needs more changes; in this case it would also make sense to add the
>> TLS
>>     part back in the main document for 443 only.
>>
>>     encapsulation with servers that only are IKE servers (at least for the
>>     used port), you would actually not need the magic number anymore. I
>> guess
>>     you can still have the magic number if you really want it because that
>>     makes it easier to distinguish valid IKE/IPSec traffic from other
>> random
>>     traffic that might be send to this port but the other service running
>> on
>>     this port (on other servers) does not need to know about the magic
>> number
>>     because it is supposed to never see any IKe/IPSec TCP-encapsulated
>> traffic.
>>
>>     Does that make sense?
>>
>>     Mirja
>>
>>
>>
>>
>>         -Ekr
>>
>>
>>
>>
>>             Mirja
>>
>>
>>
>>                 We can soften the references in the appendix to the fact
>> that
>>         other
>>                     Further, as also mentioned in the tsv-art review
>> (Thanks
>>         Wes!), this
>>                     draft does not sufficiently handle the case of TCP in
>> TCP
>>                     encapsulation.
>>                     losses as a signal of congestion (e.g. TCP) will have
>> a
>>         challenge due
>>                     repair them (unless sending into a full outer TCP
>> socket
>>         buffer shows
>> the
>>                    recovery of the inner TCP traffic less reactive and
>> more
>>         prone to
>>                     effectively ECN on the portion of the path covered by
>> the
>>         outer TCP
>>                     connection.
>>
>>
>>                 markings between inner/outer packets. Since TCP
>> encapsulation
>>         places
>>                     TCP" problem is mentioned, and is mostly appropriate
>> for
>>         a single
>>                     response behavior impacts an aggregate of flows,
>> since it
>>         may cause a
>>                     4) Additional potential for bufferbloat - Since TCP
>> does
>>         not bound
>>                     drive latency of the shared connection up and impact
>> the
>>         aggregate of
>>                     the outer TCP connection might need to be limited in
>> size
>>         to ensure
>>                     some bounds?
>>
>>
>> be
>>                     In the security considerations section, there are
>> several
>>         RFCs on
>>                     mechanisms to increase robustness to RST attacks and
>> SYN
>>         floods that

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 16:21:29 +0200

See below.

On 27.04.2017 16:10, Eric Rescorla wrote:
>     magic number would avoid any collision). I don't think that a good thing
>     to right in an RFC.
>
>
> Hmm... Maybe I don't understand your overall theory here. It seems like having
> reserved ports for protocols but letting people run them on any port they want

Mirja

>     used today and pure TCP encapsulation for use with port 4500 only. Again
>     needs more changes; in this case it would also make sense to add the TLS
>     used port), you would actually not need the magic number anymore. I guess
>     makes it easier to distinguish valid IKE/IPSec traffic from other random
>     traffic that might be send to this port but the other service running on
>     this port (on other servers) does not need to know about the magic number
>     because it is supposed to never see any IKe/IPSec TCP-encapsulated traffic.
>
>     Does that make sense?
>
>     Mirja
>
>
>
>
>         -Ekr
>
>
>
>
>             Mirja
>
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 16:32:39 +0200

See below

On 27.04.2017 16:27, Eric Rescorla wrote:
>         <https://tools.ietf.org/html/rfc7230#section-2.7.1>
>
>     This doesn't say you can/should use any port you want (it says you can
>     use another port than 80) but you should till avoid to use any other port
>     that runs a different TCP service.
>
>
> doesn't say that. It just tells you how to use a different port and is silent on

That's what we have the registry for. The difference is, it's okay to use a 
random port (instead of one specific reserved one) but this draft explicitly 
is intended to use other reserved ports.

Mirja

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 27 Apr 2017 07:59:07 -0700

> On Apr 27, 2017, at 6:46 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> One more side comment on the magic number: actually the magic number makes it easy for network operator to identify IKE/IPSec traffic on any port and block all packets that below to a flow that started with this pattern in the first payload packet. So if you really think you need a magic number, you should probably always encrypt it.

The working group determined that the point of the protocol is not to evade any possibility for middleboxes to block the traffic, but instead to allow connectivity through middle boxes that are essentially 'accidentally' blocking IKE/ESP. If an operator wants to block this traffic explicitly, that is fine. However, it is very common that networks on public access points will block everything by default based on what they consider to be 'web' traffic; they do not inspect more deeply.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 27 Apr 2017 08:07:07 -0700

> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> See below
> 
> That's what we have the registry for. The difference is, it's okay to use a random port (instead of one specific reserved one) but this draft explicitly is intended to use other reserved ports.

The only recommended port in the draft is 4500, which is what is reserved in the registry. The use of any other port is by configuration only. As Tero and others have explained, all IKE connections are made to pre-known pre-configured hosts. All the IKE implementations I am aware of allow the useable IKE ports to be customized.

I'm fine removing any mention of other specific ports, even in the appendix. However, the fact that configurations can choose what ports to use is something that needs to be left open. The point of the port registry is to allow devices to expect what service will be offered on a given port when they connect. If two peers mutually decide to share their own configuration, they can do that.

Thanks,
Tommy

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 27 Apr 2017 11:20:21 -0400

Hi Mirja,

I think I can help with one of your questions.  inline

> actually done in reality?

Well, Warren pointed out somewhere in a thread that you might have an
admin interface operating through the use of port 443.  From my
experience, if this happens, there is a different connection method
(virtual server  - address/port) that allows for this to happen.

I hope that is helpful.

Kathleen

-- 

Best regards,
Kathleen

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Apr 2017 17:39:29 +0200

Hi Tommy,

I think we agree. Removing the port examples is one thing but there is also 
wording that suggest using well-known ports which could be phrased more 
carefully. We discussed this today on the telechat and ekr will have another 
look at this.

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 28 Apr 2017 13:41:34 +0200

Hi Tero,

a few quick replies but we also discussed this yesterday at the telechat and 
agreed on a way forward.

> initiator to try port 80, as it will not work.

I understood this. My point breaks down to a) the case where you would use 
two services at the same time on the same port (see below) and b) some 
language changes that do favor to use 4500 where possible and not explicitly 
advise to use other assigned specific ports in the line of what Ekr already 
proposed.

> already blocking all UDP traffic, and at least port 4500 for TCP.

Actually this is another good point. If you have multiple open ports, you can 
give more advise which one to try when and in which order, e.g. always try 
4500 first (first UDP then TCP which the draft I believe already says), then 
others.

> used, or the one defined in document is used.

There is a difference of distinguishing other/old version of IKE or trying to 
distinguish IKE from other protocols. The point is for IKE you can define the 
magic number as reserved but you probably don't really want to reserve the 
same bits for all other protocols than you may run in parallel on the port. 
As long as you don't 'officially' make this reservation by updating the 
respective specs of other protocols, you can never be sure that there will 
not be a conflict in future version of these protocols.

> running on those ports 500/4500/443 with the standard we are defining

That's fine as long as the multiplexing is between version of IKE only.

> not want to bother with the multiplexing different protocols on one

Then let's just not support this case and let's specify in the draft that you 
cannot run another service on the used port.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 28 Apr 2017 10:05:58 -0700

Hello all,

Here's some proposed text for:

- Clarifying the configuration model around ports
- Clarifying the role of the stream prefix
- Expanding the TCP performance considerations. 

Changes are in bold.

Thanks,
Tommy

-------

2.  Configuration

   One of the main reasons to use TCP encapsulation is that UDP traffic
   may be entirely blocked on a network.  Because of this, support for
   TCP encapsulation is not specifically negotiated in the IKE exchange.
   Instead, support for TCP encapsulation must be pre-configured on both
   the TCP Originator and the TCP Responder.

   Implementations MUST support TCP encapsulation on TCP port 4500, 
   which is reserved for IPsec NAT Traversal. 

   Beyond a flag indicating support for TCP encapsulation, the configuration
   defined on each peer can include the following optional parameters:

   o  Alternate TCP ports on which the specific TCP Responder listens for
      incoming connections.  Note that the TCP Originator may initiate
      TCP connections to the TCP Responder from any local port. 

  ...

4.  TCP-Encapsulated Stream Prefix

   Each stream of bytes used for IKE and IPsec encapsulation MUST begin
   with a fixed sequence of six bytes as a magic value, containing the
   characters "IKETCP" as ASCII values.  This value is intended to identify
   and validate that the TCP connection is being used for TCP encapsulation
   as defined in this document, to avoid conflicts with the prevalence of previous
   non-standard protocols that used TCP port 4500. This value is only sent once, 
   by the TCP Originator only, at the beginning of any stream of IKE and ESP messages.

...

12.  Performance Considerations

   Several aspects of TCP encapsulation for IKE and IPsec packets may
   negatively impact the performance of connections within a tunnel-mode
   IPsec SA.  Implementations should be aware of these and take these
   into consideration when determining when to use TCP encapsulation.
   Due to these performance impacts, implementations SHOULD favor using 
   direct ESP or UDP encapsulation over TCP encapsulation whenever
   possible.

12.1.  TCP-in-TCP

   If the outer connection between IKE peers is over TCP, inner TCP
   connections may suffer effects from using TCP within TCP.  Running
   TCP within TCP is discouraged, since the TCP algorithms
   generally assume that they are running over an unreliable datagram
   layer.

   If the outer (tunnel) TCP connection experiences packet loss, this loss
   will be hidden from any inner TCP connections, since the outer connection
   will retransmit to account for the losses. This means that loss on an outer 
   connection will be interpreted only as delay by inner connections. Since
   the outer TCP connection will deliver the inner messages in order, any messages
   after a lost packet may have to wait until the loss is recovered. This increases
   the burstiness of inner traffic, since a large number of inner packets will be delivered
   across the tunnel at once. This effect is especially of concern when there is a high 
   level of loss on the outer connection.

   TCP-in-TCP can also lead to increased buffering, or bufferbloat. This can occur when the
   window size of the outer TCP connection is reduced, and becomes smaller than the window
   sizes of the inner TCP connections. This can lead to packets backing up in the outer TCP
   connection's send buffers. In order to limit this effect, the outer TCP connection should have
   limits on its send buffer size, and on the rate at which it reduces its window size.

   The inner TCP's round-trip-time estimation will also be affected by the burstiness of the outer 
   TCP connection.  This will make loss-recovery of the inner TCP traffic less reactive and more
   prone to spurious retransmission timeouts.

   Note that any negative effects will be shared between all flows going through the outer TCP
   connection. This is of particular concern for any latency-sensitive or real-time applications 
   using the tunnel. If such traffic is using a TCP encapsulated IPsec connection, it is recommended
   that the number of inner connections sharing the tunnel be limited as much as possible.

...

12.5.  Tunnelling ECN in TCP

   Since there is not a one-to-one mapping between outer IP packets and inner ESP/IP messages
   when using TCP encapsulation, the markings for Explicit Congestion Notification (ECN) cannot
   be simply mapped. However, any ECN markings on inner messages should be preserved through
   the tunnel.

   Implementations SHOULD follow the ECN compatibility mode as described in RFC 6040. The
   outer TCP connection SHOULD mark its packets as not ECN-capable, but SHOULD NOT clear
   any ECN markings on inner packets.

...

14.  IANA Considerations

   This memo includes no request to IANA.

   TCP port 4500 is already allocated to IPsec for NAT Traversal.  This port SHOULD
   be used for TCP encapsulated IKE and ESP as described in this document.

> On Apr 28, 2017, at 4:41 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Tero,
> 
> a few quick replies but we also discussed this yesterday at the telechat and agreed on a way forward.
> 
> I understood this. My point breaks down to a) the case where you would use two services at the same time on the same port (see below) and b) some language changes that do favor to use 4500 where possible and not explicitly advise to use other assigned specific ports in the line of what Ekr already proposed.
> 
>> 
> Actually this is another good point. If you have multiple open ports, you can give more advise which one to try when and in which order, e.g. always try 4500 first (first UDP then TCP which the draft I believe already says), then others.
> 
>> 
> There is a difference of distinguishing other/old version of IKE or trying to distinguish IKE from other protocols. The point is for IKE you can define the magic number as reserved but you probably don't really want to reserve the same bits for all other protocols than you may run in parallel on the port. As long as you don't 'officially' make this reservation by updating the respective specs of other protocols, you can never be sure that there will not be a conflict in future version of these protocols.
> 
>> 
> Then let's just not support this case and let's specify in the draft that you cannot run another service on the used port.
> 
>> 
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 28 Apr 2017 18:41:42 -0500

This is still Mirja's Discuss (which I supported), so I'll let her respond
to most of Tommy's proposed text changes, but on the last one ...

On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly <[email-masked]> wrote:

>  *  TCP port 4500 is already allocated to IPsec for NAT Traversal.  This
> port SHOULD*
> *   be used for TCP encapsulated IKE and ESP as described in this
> document.*
>

With no IANA actions, the entry in
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500
for 4500/tcp will still point to http://www.iana.org/go/rfc3947 as the
reference.

Should that change when this draft is published?

Thanks,

Spencer, who may be confused, but wanted to ask before the draft is approved

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 28 Apr 2017 17:09:42 -0700

I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA Considerations text?

Thanks,
Tommy

> On Apr 28, 2017, at 4:41 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> This is still Mirja's Discuss (which I supported), so I'll let her respond to most of Tommy's proposed text changes, but on the last one ...
> 
> On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 14.  IANA Considerations
> 
> With no IANA actions, the entry in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500 <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500> for 4500/tcp will still point to http://www.iana.org/go/rfc3947 <http://www.iana.org/go/rfc3947> as the reference. 
>