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

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 May 2017 12:17:40 +0300

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

[Note, that I am just talking as individual here, these IANA actions
do not relate the IKEv2 registries where I am IANA Expert]

I proposed to change both the UDP and TCP references for the port
4500, as even if the RFC3947 did do the IANA actions, it does not
describe the protocol used on the port. RFC3948 and 7296 does.

So from my previous email I would suggest following text:

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

    This document updates both TCP and UDP references of the port 4500
    to match the current protocols used on those ports:

    Keyword       Decimal    Description          Reference
    -------       -------    -----------          ---------
    ipsec-nat-t   4500/tcp   IPsec NAT-Traversal  [RFC-this-rfc]
    ipsec-nat-t   4500/udp   IPsec NAT-Traversal  [RFC3948], [RFC7296]

-- 
[email-masked]

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 2 May 2017 12:01:32 +0200

Hi all,

so first updating is a request to IANA, so you have to remove the first sentence. Then the update of the UPD port should probably be done in a separate document that potentially also obsoletes 3947 if that was missed with 7296.

Mirja

> Am 02.05.2017 um 11:17 schrieb Tero Kivinen <[email-masked]>:
> 
> Tommy Pauly writes:

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 May 2017 15:24:50 +0300

Mirja Kuehlewind (IETF) writes:
> so first updating is a request to IANA, so you have to remove the
> first sentence.

Agreed, forgot to remove that. 

> Then the update of the UPD port should probably be done in a
> separate document that potentially also obsoletes 3947 if that was
> missed with 7296.

No point of doing that. Publishing 1 page document doing IANA updates
is just stupid and does not help anybody. If it cannot be done here,
we can leave it as it is now, and I talk to IANA and change this thing
separately. As this is clearly a error in the IANA registry, they have
fixed this kind of mistakes before without any need for documents
especially when registry is not RFC required or similar. They do like
to get document requests just for keeping track of changes, and thats
why I think it would be better to combine the changes in this
document, as we are going to change the TCP/4500 anyways, and fixing
the UDP/4500 references at the same time would be easy.

And yes, RFC7296 did forget to obsolete RFC3947, but this is not the
document do that, and thats why I did not suggest this to do anything
like that. I suggested just fixing the reference from the RFC3947 to
RFC3948, as RFC3948 actually describes the protocol used over the port
4500. RFC3947 does not specify the protocol for port UDP/4500, it just
refers to the RFC3948 for protocol details. Adding RFC7296 would be
good, as it provides latest information about the IKE interactions for
the RFC3948 (i.e., 7296 still uses 3948 defined protocol, but replaces
the non port 4500 related details which were in the 3947). This is
just to make sure the people reading the RFC3948 also gets pointer to
the IKE parts of the protocol (as RFC4306/5996/7296 forgot to obsolete
3947). 
-- 
[email-masked]

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 2 May 2017 15:27:23 +0200

Hi Tero,

my thinking was that the main problem is that 3947 was not obsoleted and I’m assuming we need a document to fix that. In this case that document could/should also fix the IANA entry for the UDP port. However, I’m actually not sure what the right processing would be to fix this forgotten obsolete… maybe other ADs know better…?

Otherwise if you don’t want to do this, I don’t think it’s a good idea to merge kind of unrelated fixes into this spec. We can also fix that by using the IESG approval process (see RFC5226). I think that’s the better option!

Mirja

> Am 02.05.2017 um 14:24 schrieb Tero Kivinen <[email-masked]>:
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 May 2017 12:12:35 +0300

Mirja Kuehlewind (IETF) writes:
> my thinking was that the main problem is that 3947 was not obsoleted
> and I’m assuming we need a document to fix that.

This is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.

Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
already obsoleted, so effectively RFC3947 is already obsoleted, as
there is no way to implement 3947 without implementing obsoleted
protocol...

This issue is not not important enough to require RFC now.

> In this case that document could/should also fix the IANA entry for
> the UDP port. However, I’m actually not sure what the right
> processing would be to fix this forgotten obsolete… maybe other ADs
> know better…?

For now I would just leave it as it is, but fix the references in the
IANA registry so that document will not be referenced, especially as
the original IANA reference was not to the correct RFC in the first
place. 

> Otherwise if you don’t want to do this, I don’t think it’s a good
> idea to merge kind of unrelated fixes into this spec. We can also
> fix that by using the IESG approval process (see RFC5226). I think
> that’s the better option!

That is true, but as this document already modifies the TCP/4500
reference, fixing the UDP/4500 reference at the same time is not
completely unrelated fix. 

Obsoleting RFC3947 would be unrelated fix. 
-- 
[email-masked]

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 3 May 2017 12:54:41 +0200

I didn't propose to obsolete RFC3947 in this document. I guess you can also 
file an error for this if you don't want to take any further actions. 
However, for updating the IANA registry, I would say the right action is to 
do this simply by IESG approval for UDP then.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 3 May 2017 08:11:37 -0500

On May 3, 2017 05:54, "Mirja Kühlewind" <[email-masked]> wrote:

Fwiw, that would work for me.

Spencer

Mirja

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 14:13:53 -0700

It seems like most of the issues are resolved here, except for that of
muxing
IKE and non-IKE protocols on the same port (especially 443). My
understanding
is that (although we may not like it) it's nevertheless a common practice,
and
yet we can't levy the requirement that no other protocol start with
IKETCP<whatever>,
so it seems like what we need is a warning note and potentially a request
to reserve
this string for some set of common protocols (HTTP,...?).

Mirja, would that work for you?

-Ekr

On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> I didn't propose to obsolete RFC3947 in this document. I guess you can
> also file an error for this if you don't want to take any further actions.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 8 May 2017 14:49:36 +0200

Does the proposed text changes from Tommy still refer to 443 anywhere (lost track a bit but I guess the appendix still does right)?

Again I think we should talk about using 443 if that’s what’s done in reality. However my understanding is that real-life implementation use TCP/TLS which I think could be discussed in the body rather than the appendix.

And I would like to see a recommendation that HTTPS and TCPIKE should not be multiplexed the same time on the same port. My understanding from Tero’s feedback was that this is usually not done today and probably not necessary in future.

Mirja

> Am 05.05.2017 um 23:13 schrieb Eric Rescorla <[email-masked]>:
> 
> It seems like most of the issues are resolved here, except for that of muxing
> IKE and non-IKE protocols on the same port (especially 443). My understanding
> is that (although we may not like it) it's nevertheless a common practice, and
> yet we can't levy the requirement that no other protocol start with IKETCP<whatever>,
> so it seems like what we need is a warning note and potentially a request to reserve
> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 
> I didn't propose to obsolete RFC3947 in this document. I guess you can also file an error for this if you don't want to take any further actions. However, for updating the IANA registry, I would say the right action is to do this simply by IESG approval for UDP then.
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 12 May 2017 15:25:09 -0700

> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 

The current state will not refer to 443 in the body, but specify TCP 4500, with the option to have both peers mutually agree on another port to use if necessary. The working group had felt that bringing TLS over 443 directly into the body would be inappropriate for the standard. We mention in the discussion of previous solutions that there are "SSL VPNs", which covers the current reality of how the problem is solved.

> And I would like to see a recommendation that HTTPS and TCPIKE should not be multiplexed the same time on the same port. My understanding from Tero’s feedback was that this is usually not done toda…

Yes, I think it makes sense to add to the text around the configuration that it is recommended to not run any other service on the same port as TCP Encapsulated IPsec.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 31 May 2017 11:37:27 -0700

Hello,

I've posted a new version of the draft that incorporates the changes discussed in this thread. Please review!

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10>

Thanks,
Tommy

> On May 12, 2017, at 3:25 PM, Tommy Pauly <[email-masked]> wrote:
> 
> 
>