Subject: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 31 Aug 2016 03:45:59 -0700

Mirja Kühlewind has entered the following ballot position for
charter-ietf-ipsecme-10-00: Block

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

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Similar to Spencer's commet I have problems understanding what the
following really means:

"To make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel. The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection."

Based on Tero's mail I understand how the stack looks like but that's not
clear from the text because there is not really anything like a TCP
tunnel. So the big question is, based on the stack indicated by Tero, do
you have two full TCP connections running with two congestion control
loops and retransmission mechanisms on two different endpoints? That's
nothing I would recommend. 

I fully understand the need for a fallback mechanism to TCP but depending
on what you actually aim for I'm not sure if this is the right wg for it;
therefore my block for now. I hope we can resolve that quickly!

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 31 Aug 2016 14:57:40 +0300

> nothing I would recommend. 

Short answer: Yes. There will be TCP inside TCP. 

> therefore my block for now. I hope we can resolve that quickly!

This method is already inside the 3GPP TS 24.302 (3rd Generation
Partnership Project; Technical Specification Group Core Networks and
Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP
access networks; Stage 3, section F.3) [1].

This caused some problems to some IPsec vendors, as they need to
implement it to support EPC, but the 3gpp specification did not
consider or specify all needed things for the protocol, thus vendors
needed to agree something that could really be used in interoperable
way, and they also thought it would be better to do this work on the
IETF, than in the 3GPP.

IPsecME WG was considered right group to work on this, as this is
mostly defining how this extension interacts with the IKE extensions
etc (mobike, ike fragmentation, nat detection etc) [2]. The base 3GPP
version did already specify how to put that ESP traffic inside the
TCP, i.e. had TCP inside TCP already.

What do you think would be better working group for this?

[1] http://www.3gpp.org/DynaReport/24302.htm
[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
-- 
[email-masked]

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 14:02:12 +0200

Hi Tero,

thanks for the reply. Very helpful background info. Maybe even put more information in the charter text.

When you say "the 3gpp specification did not consider or specify all needed things for the protocol“, can you be more specific here?

I’m not saying that this is the wrong working group but it really depends on what you want to do. If you already have a clear view about what needs to be further specified and what the solution is, this might be the right group. If there is an unknown number of open questions to be answers, it might not.

Mirja

> Am 31.08.2016 um 13:57 schrieb Tero Kivinen <[email-masked]>:
> 
> Mirja Kuehlewind writes:

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 31 Aug 2016 15:21:32 +0300

> more information in the charter text. 

I think it belongs to the actual draft, not to the charter, perhaps we
should put the draft-ietf-ipsecme-tcp-encaps in the charter, as
a working draft. 

> When you say "the 3gpp specification did not consider or specify all
> needed things for the protocol“, can you be more specific here?

3GPP just said that we make TCP tunnel, put 16-bit length header in
front telling the length of the IKE or ESP packet coming after that,
and then we put either ESP packet directly, or 4-bytes of zeros
(Non-ESP marker we use in UDP encapsulation) and IKE packet.

There is also keepalive timer sending packets over TCP to keep it
alive (again similar what we have in UDP).

They did not define how it interacts with MOBIKE, and changing of the
IP-addresses, or and so on. There are also other newer extensiosns
like IKEv2 message fragmentation and those were not considered in the
3gpp specification. To get better answer what was missing, it would be
better to ask from the implementors who are implementing these things,
my reading was just as an IANA expert, as they needed some IKE notify
and configuration payload numbers.

> I’m not saying that this is the wrong working group but it really
> depends on what you want to do. If you already have a clear view
> about what needs to be further specified and what the solution is,
> this might be the right group. If there is an unknown number of open
> questions to be answers, it might not. 

I think the current draft mostly already answers to the questions, and
I do not think there are that many open issues with it.

-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 31 Aug 2016 08:53:56 -0400 (EDT)

> Short answer: Yes. There will be TCP inside TCP.

Well, no. This is adding confusion. There will be an IPsec tunnel inside
TCP, and the IPsec tunnel could be used to transport TCP or anything
else. The ipsecme working group is not adding a TCP over TCP method.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Aug 2016 16:17:36 +0300

> On 31 Aug 2016, at 3:21 PM, Tero Kivinen <[email-masked]> wrote:
> 

One more bit of information: some vendors have had a non-standardized version of this or something similar for years. My employer has had it since 2003, except that the header is a bit different. The pretty ubiquitous SSL VPNs do pretty much the same except that they encrypt IP packets plus headers into TLS records rather than ESP packets before streaming them over TCP.

Perhaps “TCP tunnel” is a misleading term because the TCP does not tunnel. That is part of the function of ESP. Perhaps we should be saying “TCP streaming of ESP and IKE packets”

Yoav

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 15:41:46 +0200

Hi all,

thanks for providing the reference to the draft. That was very helpful and confirmed my initial assumption that you don’t want to ‚change‘ TCP. So this work seems to be fine in this group, however, the wording in the charter is very misleading. What's about the following?

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE packets need to be
encapsulated in ESP over TCP. Therefore the group will define a mechanism to
use IKE and IPsec over TCP. Further the group will provide guidance 
how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used.“

I also removed some redundancy and added a point that guidance is needed to detect blocking. We could still at the current draft as a starting point…

Mirja

> Am 31.08.2016 um 15:17 schrieb Yoav Nir <[email-masked]>:
> 
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 31 Aug 2016 07:10:18 -0700

Thanks everyone for chiming in. I want to highlight that the point of the draft is to nail down the IKE-specific concerns of encapsulating the tunnel in streams. As mentioned by Tero, this includes how to specify the boundaries of messages within the stream; and how to interact with MOBIKE, redirection, fragmentation, and so on.

The protocol really could be summarized as "how to encapsulate IKE and IPSec in any stream-like protocol", and it specifically mentions that this applies beyond direct TCP streams. If we want to have work in other groups to change how the outer TCP works, that's great. Any work that would be done in that area could benefit such tunnels without requiring changes to the IPSec aspect.

The practice of putting tunnels over TCP when absolutely necessitated by the restrictions of a network is common practice. If we do not specify this here, devices will still do it, just without a standard. As Yoav mentioned, this is common practice across essentially every non-IKE VPN tunnel protocol, and leads to a splintering of protocols to do the same thing. Please do read the draft (current version https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02); it specifically calls out why TCP-in-TCP (which can happen in this scenario) is problematic, and so it specifies several times that this is only to be used as a fallback from UDP.

We've done fairly extensive testing around the implications of this protocol, and made sure we were satisfied with the results before we proposed the draft. 

Thanks,
Tommy

> On Aug 31, 2016, at 6:17 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 31 Aug 2016 17:11:30 +0300

Mirja Kuehlewind (IETF) writes:
> thanks for providing the reference to the draft. That was very
> helpful and confirmed my initial assumption that you don’t want to
> ‚change‘ TCP. So this work seems to be fine in this group, however,
> the wording in the charter is very misleading. What's about the
> following?

Yes, we do NOT want to make any changes to the TCP, not the TCP
outside or the TCP inside (or UDP, ICMP whatever inside, the inside
traffic can of course be something else than TCP, but usually there
will be TCP also). 

> encapsulated in ESP over TCP. Therefore the group will define a
> mechanism to use IKE and IPsec over TCP. Further the group will
> provide guidance how to detect when IKE cannot be negotiated over
> UDP and TCP as a fallback should be used.“

That is bit misleading, as IKE packets are not encpasulated in the
ESP, instead both IKE and ESP packets are encapsulated in (very
simple) encapsulation protocol that is running over TCP. I.e., the very
simple encapsulation protocol consists just the 2-octet length
prefixing the packet, and nothing else.

So more accurate text would be:

There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE and ESP packets need to be
transmitted over TCP. Therefore the group will define a mechanism to
use IKE and IPsec over TCP. Further the group will provide guidance
how to detect when IKE cannot be negotiated over UDP and TCP as a
fallback should be used.

> I also removed some redundancy and added a point that guidance is
> needed to detect blocking. We could still at the current draft as a
> starting point... 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 31 Aug 2016 10:16:59 -0400 (EDT)

> how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used.“

"IKE packets need to be encapsulated in ESP over TCP" is not correct.

Both IKE and ESP are "independently" encapsulated over TCP. First the
IKE negotiation happens, normally over UDP port 500 or when NAT is
involves over UDP port 4500. We are now introducing a method to
encapsulate this over TCP. Once the IKE session is up, we have
negotiated an ESP method, which we will _also_ need to encapsulate
over the same TCP stream. As with ESP over UDP, we place markers in
the stream to distinguish IKE from ESP packets within the TCP stream.

Paul

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 16:24:13 +0200

Hi all,

> Am 31.08.2016 um 16:11 schrieb Tero Kivinen <[email-masked]>:
> 

This text is fine. Sorry I was missing a previous comment.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 16:28:01 +0200

Hi Tommy,

thanks for the info. I understand the need for using TCP and also the need for standardization here. It was just not clear to me what exactly need to be done because I didn’t have the reference to the draft.

You as you said below what you need is guidance on "how to encapsulate IKE and IPSec in a stream-like protocol“. Maybe that the wording we could also use in the charter to clarify what the wg will do…?

Mirja

> Am 31.08.2016 um 16:10 schrieb Tommy Pauly <[email-masked]>:
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 31 Aug 2016 07:30:42 -0700

> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi all,
> 

"IKE packets need to be encapsulated in ESP over TCP" is not correct, since IKE does not run over ESP. IKE and ESP packets run alongside one another in the stream, as they do when using UDP encapsulation.

How about:

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, both IKE packets and tunneled ESP
packets need to be encapsulated in TCP. Therefore the group will define 
a mechanism to use IKE and IPsec over TCP, and define the scenarios
in which it is appropriate to use this method."

The draft covers the applicability of TCP encapsulation, but I strongly believe that specific algorithm for fallback is out of scope. This will be highly context-dependent, and we will have different algorithms for different devices and scenarios. I have planned on writing an informational draft as a follow-on to describe the methods we use, but that should be independent of the protocol to define the IKE/ESP messages in a stream, which is a much more general protocol.

Thanks,
Tommy

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 31 Aug 2016 21:53:26 -0400

Tommy,

> in which it is appropriate to use this method."

Are you okay with Tero's proposed wording since Mirja has agreed to
it.  The suggested wording is:

Sorry for my delayed response to make sure this was addressed, I was
off today and driving for a good portion of the day.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 31 Aug 2016 20:13:57 -0700

Hi Kathleen,

> On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Tommy,
> 
> On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>> 

The final sentence seems like it's missing a word after "guidance":

"Further the group will provide guidance
how to detect when IKE cannot be negotiated over UDP and TCP as a
fallback should be used."

How about:

"The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback".

From a content perspective, I am fine with this as long as the primary draft leaves the algorithm as a fairly open-ended suggestion. I think it is appropriate to say that the IKE_SA_INIT should be sent over UDP several times, after which point a fallback to TCP is appropriate if so configured on the device (and that this fallback may be sooner if there is historical reason to believe it is necessary). Any more specifics about timing and how to measure expected response times, etc, would be out of scope. Does that work?

Thanks,
Tommy