Subject: [IPsec] informal ports and transport review of [email-masked]

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 11:36:06 -0700

Hi, all,

I'm providing this feedback at the request of the ADs.

The port information is based on my experience as IANA port review team lead.

The transport information is based on my experience in TSV-ART.

Joe

----------------

Ports issues:

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

    - this approach MUST NOT be described as applying to any unassigned but
assignable, or reserved port

    - this approach MUST NOT use any existing assigned port in an example unless also
updating the associated RFC (including 4500 and 443)

	- IMO, this is a new service that therefore MUST either request a new assignment (for
TCP only) or  be limited to operating only over dynamic ports, as per RFC6335

------------------
TCP issues:

This approach has issues with its use of TCP as well, as follows:

 - TCP MSS has nothing to do with fragmentation; it is primarily
associated with IP reassembly

    - TCP over TCP discussion is insufficient; there are known
interactions that amplify the problem far beyond either one alone

---

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Apr 2017 15:04:41 -0400 (EDT)

> also updating the associated RFC

So it should add an Updates: RFC-3947

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.

> TCP only) or  be limited to operating only over dynamic ports, as per RFC6335

This issue is really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls and middle-ware 
that only let out port 443 traffic unmangled. We cannot really write
that we are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention 443 without updating the
RFC defining 443 is hard to meet. Not only because we'd have an IKE
document updating a TLS document, but also because IANA actually has
not RFC listed for the definition of port 443.

I'm already a little annoyed that the draft cannot (politically) specify
how to use port 443 with TLS to tunnel IKE and ESP over TCP. It will
lead to interoperability issues because it is not specified. Becoming
more quiet about port 443 isn't going to help anyone and will only
increase the large number of incompatible SSL-VPNs out there whose
main reason for existing is that IKE/IPsec cannot leave some networks
unless using abusing TLS over 443.

I guess that text can be fixed.

> interactions that amplify the problem far beyond either one alone

The text is already basically saying "tcp over tcp is such a disaster,
really try to move back to udp as soon as possible and really try
that often because tcp over tcp is really really bad". I don't know
why more text is needed.

Paul

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 13:03:44 -0700

Hi, Paul,

On 4/25/2017 12:04 PM, Paul Wouters 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.
>>

But also section 4 needs to be revised and the notion of the magic
string completely removed. You won't need a magic string if you use an
assigned port and you should NEVER be abusing (your words, below)
someone else's port for your purposes.

In fact, IMO, this doc should have a MUST NOT be used except with ports
specifically designated.

> to actually use TCP at all. It seems it was mostly preventatively
That was IANA policy before RFC6335, when we shifted to "only assign
protocols actually in use".

> Part of this draft is designed to break through firewalls and
> middle-ware that only let out port 443 traffic unmangled. We cannot
> really write

It's not listed, but it would probably be rfc2818 or one of the ones
that updates that.

However, I'd personally want someone involved from HTTPWG to sign off on
this.

> how to use port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the thing:

    You get to define your service.

    You do not get to define someone else's.

You would be squatting (using someone else's ports for your purposes),
pure and simple.

I'm not sorry if that annoys you or you consider that politically incorrect.

> It will
> more quiet about port 443 isn't going to help anyone

It is - it protects HTTPS for the rest of us.

> and will only

You said it - abusing. The IETF should never condone that behavior in a
new standard.

> that often because tcp over tcp is really really bad". I don't know

I agree this is less important - it's basically hurting yourself. I
think it's worth noting that the result is unpredictably worse than two
TCPs back to back, at least, though, as a warning to designers.

Joe

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Apr 2017 23:59:42 +0300

Hi, Joe

I haven’t been involved with this draft, but I don’t believe that last statement is correct:

> On 25 Apr 2017, at 23:03, Joe Touch <[email-masked]> wrote:
> 
>> 

I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any sense of the word to the HTTP working group.

While it is the default port for HTTPS, that protocol can run on any port depending on the value in origin (RFC 6454).

The draft makes it clear in section 2 that the port used is pre-configured on both IKE initiator and IKE responder. The draft does not assign or re-assign any ports.

Yes, there is a suggestion to use port 443 because it is usable in more networks than other ports. That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call of Duty, various “SSL VPN” products and many others. They’ve been doing that for over a decade. It is way too late to close the barn doors, and we don’t even have the authority to do so.

We can remove all references to specific ports and leave only text about pre-configuration. IMO this amounts to a wind and a nod, because we all know which port is going to get configured.

Yoav

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 14:15:41 -0700

First, correcting the subject line (sorry - that looks like an erroneous
paste on my part).

Also below...

On 4/25/2017 1:59 PM, Yoav Nir wrote:
>> On 25 Apr 2017, at 23:03, Joe Touch <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>>
> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs”
> in any sense of the word to the HTTP working group.

Strictly, the port is assigned based on a service definition.

On any given host, any user can define any port any way they see fit,
e.g., they can run DNS on port 110 or IMAP on port 53.

However, a new standard should never be making a change to the service
defined for a port that is already assigned to another party (they can
change a service they have been assigned).

> While it is the default port for HTTPS, that protocol can run on any
> port depending on the value in origin (RFC 6454).

Yes, any protocol can run on any port number (as per above), as long as
the endpoints agree. But that's not what you're talking about here -
you're saying that if you get "IKETCP" on a port, then you can trust
that it is your service.

That's incorrect. You don't get to define the string "IKETCP" for other
services.

> The draft makes it clear in section 2 that the port used is
> pre-configured on both IKE initiator and IKE responder. The draft does
> not assign or re-assign any ports.
Section 4 claims that the use of the magic string differentiates this
service from the default assigned service or any other service. That's
incorrect. You don't have that authority.

> Yes, there is a suggestion to use port 443 because it is usable in
> more networks than other ports.
Again, you don't have the authority to say what "IKETCP" means on port 443.

Yes, if the port is explicitly indicated, you can use whatever port you
want. But you should never imply that this system should run on ports
assigned to other services that are running in parallel - you do not
have that authority.

> That is why TCP port 443 has been used by Skype, AiCloud file sharing,
> Call of Duty, various “SSL VPN” products and many others. They’ve been
> doing that for over a decade. It is way too late to close the barn
> doors, and we don’t even have the authority to do so.

You do not have the authority to endorse or standardize this behavior
either.

It remains non-compliant squatting.

> We can remove all references to specific ports and leave only text
> about pre-configuration. IMO this amounts to a wind and a nod, because
> we all know which port is going to get configured.

You should be saying that the port is indicated explicitly (which is the
equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe
get your own separate assignment). But the entire text on the magic
number being appropriate when sharing an existing assignment is
incorrect and needs to be removed IMO.

Joe

---

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

> On Apr 25, 2017, at 2:15 PM, Joe Touch <[email-masked]> wrote:
> 
> First, correcting the subject line (sorry - that looks like an erroneous paste on my part).
> 
> Also below...
> 
>>> On 25 Apr 2017, at 23:03, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> 
> On any given host, any user can define any port any way they see fit, e.g., they can run DNS on port 110 or IMAP on port 53. 
> 
> However, a new standard should never be making a change to the service defined for a port that is already assigned to another party (they can change a service they have been assigned).
> 
> Yes, any protocol can run on any port number (as per above), as long as the endpoints agree. But that's not what you're talking about here - you're saying that if you get "IKETCP" on a port, then you can trust that it is your service.
> 
> That's incorrect. You don't get to define the string "IKETCP" for other services. 
> 
> Section 4 claims that the use of the magic string differentiates this service from the default assigned service or any other service. That's incorrect. You don't have that authority.
> 
>> Yes, there is a suggestion to use port 443 because it is usable in more networks than other ports.
> Yes, if the port is explicitly indicated, you can use whatever port you want. But you should never imply that this system should run on ports assigned to other services that are running in parallel - you do not have that authority.
> 
>> That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call of Duty, various “SSL VPN” products and many others. They’ve been doing that for over a decade. It is way too late to close the barn doors, and we don’t even have the authority to do so. 
> 
> You do not have the authority to endorse or standardize this behavior either.
> 
> You should be saying that the port is indicated explicitly (which is the equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get your own separate assignment). But the entire text on the magic number being appropriate when sharing an existing assignment is incorrect and needs to be removed IMO.

I suggest that we can:

- Clarify the text in section 2 (configuration) to say that the default port is TCP 4500, and that implementations may communicate other port options out of band as configuration. This is done for UDP as well. This is the "explicit" indication of the ports you mention above.
- Port 443 is only mentioned in the figures for the appendix. We can remove the mention of the port there.

As for the Stream Prefix of "IKETCP", I believe that we have good reasons to keep it even if we are only using the protocol on port 4500 (as would be the recommended/sanctioned) method. TCP port 4500 has been technically allocated to IPsec NAT Traversal (which TCP encapsulation is) for a long while without a specific protocol being defined. The concern that brought about the stream prefix was to let VPN endpoints that may be running older non-standard protocols to recognize TCP encapsulation in case they were already squatting on the port (4500), or have configured TCP encapsulation to run on a port they are using for their own custom VPN protocol.

How does that sound?

Thanks!
Tommy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Apr 2017 06:46:59 +0300

> On 26 Apr 2017, at 0:15, Joe Touch <[email-masked]> wrote:
> 

That I totally agree with.  The purpose of the IKETCP magic string is to demultiplex between TCP connections implementing this draft and other TCP connections using the same port for other services, regardless of whether those other services are defined in IANA or other squatters.

I think the text in section 4 already says so, but perhaps it can be clarified.

Yoav

---

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

Paul Wouters writes:
> >    - this approach MUST NOT be described as applying to any
> >    	 assigned number unless also updating the associated RFC
> 

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

> to actually use TCP at all. It seems it was mostly preventatively

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: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 10:59:07 -0700

Hi, Tommy,

On 4/25/2017 8:34 PM, Tommy Pauly wrote:
> I suggest that we can:
>
> - Clarify the text in section 2 (configuration) to say that the
> default port is TCP 4500, and that implementations may communicate
> other port options out of band as configuration. This is done for UDP
> as well. This is the "explicit" indication of the ports you mention above.
That will work.

> As for the Stream Prefix of "IKETCP", I believe that we have good
> reasons to keep it even if we are only using the protocol on port 4500
> (as would be the recommended/sanctioned) method.

That is your decision, but IMO it is important that this ONLY helps
check that you connect to a port running your service based on other
information (e.g., port 4500 or port as indicated out of band). The key
issue is that this doc should never claim that this text is intended to
help you run this service *concurrently* with any other service on the
same port. That's hijacking - because any existing service can define
that string to mean whatever it wants (regardless of whether they do
that now or not).

> TCP port 4500 has been technically allocated to IPsec NAT Traversal
> (which TCP encapsulation is) for a long while without a specific
> protocol being defined. The concern that brought about the stream
> prefix was to let VPN endpoints that may be running older non-standard
> protocols to recognize TCP encapsulation in case they were already
> squatting on the port (4500), or have configured TCP encapsulation to
> run on a port they are using for their own custom VPN protocol.
>
> How does that sound?

As a confirmation check, yes. Again, NOT to demux with legacy services.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 11:01:08 -0700

On 4/25/2017 8:46 PM, Yoav Nir wrote:
> ...
>> Yes, any protocol can run on any port number (as per above), as long
>> as the endpoints agree. But that's not what you're talking about here
>> - you're saying that if you get "IKETCP" on a port, then you can
>> trust that it is your service.
>>
> That I totally agree with.  The purpose of the IKETCP magic string is
> to demultiplex between TCP connections implementing this draft and
> other TCP connections using the same port for other services,
> regardless of whether those other services are defined in IANA or
> other squatters.

Actually, this is the opposite of what is valid.

Let me be clear - you can define that string to mean whatever you want
WITHIN YOUR SERVICE.

You CANNOT define that string as having a meaning when a port is used
for other services. You cannot change other services without updating
their specs (and without their permission).

> I think the text in section 4 already says so, but perhaps it can be

IMO, that section needs substantial revision and must not say - or imply
- what it currently says.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 11:06:34 -0700

On 4/26/2017 3:43 AM, Tero Kivinen wrote:
> Not really.
... (basically points to other more appropriate RFCs to UPDATE)

I'll leave it to you and the IESG to determine what RFC this document
should be updated to correctly change the definition of port 4500. ;-)

> the protocol over other transport protocol in the future...

Actually, that was how IANA handled assignments in the past. Currently,
if you ask for port number X on UDP, then port number X on all other
transports (TCP, DCCP, SCTP) are marked "Reserved". The current assignee
(e.g., for X on UDP, here) has first-priority on using that port on
other transports, but that assignment typically uses the same name only
where the primary difference is framing. IANA now encourages assignees
to have different names for different services on different transports,
even when sharing the same port number on different (see RFC7605).

>          Keyword       Decimal    Description          Reference
Sounds good to me (again, I'll trust this group and the IESG to pick the
best references)

Joe