Subject: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Apr 2017 18:42:53 -0700

Ben Campbell 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:
----------------------------------------------------------------------

I have one (hopefully easy) point that I think needs to be fixed before
progressing.

Section 6, paragraph 6 says : "... if the TCP Originator stream is
missing the stream prefix, or message frames are not parsable as IKE or
ESP messages), it MUST close the TCP connection."

IIUC, the entire point of having the stream prefix is to allow the TCP
responder to demux between this protocol, and some other protocol that
would normally run on that port. Saying it MUST close the TCP session
seems to completely remove that value. I assume people meant to allow the
respondent to delegate a stream out to some other protocol handler if the
prefix is not present?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

-2:
-- 2nd bullet (and elsewhere)
I think this needs a discussion about how those configured ports are
likely to be in the assigned range, and the likely impact. (I recognize
that tunneling over a port assigned to something else is a primary reason
for doing this. I'm not arguing against it; I just think the implications
warrant discussion.)

-- 2nd to last paragraph: "This document leaves the selection of TCP
ports up to implementations."
I suspect "configurable local policy" would make more sense. Leaving it
up to "implementations" leaves open the chance of different
implementations making non-intersecting port choices, which doesn't help
interoperability.

-3, first paragraph:
Are people confident there will never, ever be a need to demux protocols
other than IKE and ESP? If not, this approach may paint people in a
corner in the future. I ask because we made similar choices with
DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue.
See RFC7983 for a discussion. (Note that this would have been a DISCUSS
point, but I think it's reasonably likely that there really won't be
other protocols here. But I want to make sure people have thought about
it.)

-4, first paragraph: What is the expected behavior from a peers that do
not support this spec when they receive a TCP stream with the magic
number on a port for some other protocol?

-6: First paragraph: It would be helpful to mention behavior on receipt
of a stream without the magic number here. But see the DISCUSS point.

-8: "... MUST support dynamically enabling and disabling TCP
encapsulation..." seems unreasonably strong, especially since the
requirement to try UDP before TCP is only a SHOULD. Does this contemplate
situations where it might be impossible to use TCP on the after a network
change?

- Appendix A: Doesn't the use of the NULL cipher invalidate one of the
primary reasons to use TLS? (Namely to obscure the fact that this is not
HTTP, or whatever other protocol is assigned to the port?)

Editorial Comments:

- Please expand IKE and ESP on first mention in both the abstract and
body.

-3, 2nd paragraph: s/"may be able"/"is able".

-3.2, " The SPI field in the ESP header MUST NOT be a zero value."
Is this a new requirement for this draft? That is, does ESP otherwise
allow zero value SPIs? If not, please consider dropping the MUST NOT.  

-5.1: "...SHOULD always attempt negotiate IKE over UDP first"
This is stated several times in the draft, more than once with the
SHOULD. It's better to avoid redundant 2119 keywords.

-6: "... IKE Figure 1 and ESP Figure 2... ": Broken section
cross-references.

-10, title: Please expand DPD.

-12: Several previous sections pointed to section 12 for more information
about why one needed to try direct connections or UDP before TCP. But I
don't find any specifics on that in this section.

- Appendix A: Why is this an appendix? It contains normative text that
seems central to certain use cases. I was surprised to see no discussion
about using TLS in section 11, where it seemed quite relevant.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Apr 2017 22:10:52 -0400

Hi Ben & others,

I may be able to help on a few of these, but the editors (etc.),
please correct me if necessary.

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

I believe that this is because there is presumed to be no other
service operating on the listening port (assuming a VPN concentrator),
but that's not explicitly stated either.

This may go more into unexplained assumptions... the clients
authorized to connect to the server would need to know the correct
port to establish a session and would be given that information
specific to the implementation.  With this assumption, the above
should be fine... but editors/AD/WG, please correct me if I am wrong.

> number on a port for some other protocol?

Maybe listing assumptions up front in the draft would help _IF_ the
assumption is that the listening server is a VPN concentrator that
wouldn't be listening for other services.

> HTTP, or whatever other protocol is assigned to the port?)

Editors/AD correct me if I am wrong, but...
No, if TLS is used with a NULL cipher, it'll pass inspection of a
middle box validating the protocol.  This doesn't need to use the
cipher as it's negotiating the IPsec connection.

> - Please expand IKE and ESP on first mention in both the abstract and

These are on the list of well known acronyms:
https://www.rfc-editor.org/materials/abbrev.expansion.txt

-- 

Best regards,
Kathleen

---

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

> but that's not explicitly stated either.

Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
the other kinds of SSL VPNs or as the administration interface or
user interface.

> should be fine... but editors/AD/WG, please correct me if I am wrong.

I am pretty sure what is meant is "configuration" and not "implementation".

> wouldn't be listening for other services.

Support for TCP would be based on preconfiguration, so the client knows
this out-of-band. It cannot be discovered during negotiation, because
it is assumed the regular UDP ports are blocked, which is the only
reason to attempt TCP to begin with.

> cipher as it's negotiating the IPsec connection.

right, TLS happens to use encryption to get out, but it is not the
encryption of the actual IKE/IPsec protocols, which keep using their
own channel negotiations.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Apr 2017 22:38:09 -0400

Thanks for the quick response Paul, a few questions...

> the other kinds of SSL VPNs or as the administration interface or

OK, sounds like I didn't help here, so the editors should propose text
to address this gap.

> I am pretty sure what is meant is "configuration" and not "implementation".

Is that in response to me being wrong in my assumption or the draft
should say configuration (I think it's the latter, but important to
check)?

> reason to attempt TCP to begin with.

I read the draft with this assumption in mind (see above), but this
should be clarified in the document to address this question from Ben.

> own channel negotiations.

I think clarifying this further in the draft would be helpful.

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Apr 2017 22:54:18 -0500

> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <[email-masked]> wrote:
> 

I think we are on the right track here, pending proposed text.

> should say configuration (I think it's the latter, but important to

We are probably splitting hairs on the meaning of “implementation” vs “configuration”. (and maybe “deployment”). I was thinking of “implementation” as being what developers do, and “configuring/deploying” as what operators do. But I am aware that operators sometimes talk about “implementing” a system.

So my point was that I assume for purposes of interoperability that a general purpose client or server would allow the port to be changed in the field.

> should be clarified in the document to address this question from Ben.

Imagine a misconfigured client opening a connection to an web server on port 80, expecting to find a VPN service. What happens? I think that a consequence of the design approach to allow this to run over ports assigned to other protocols is that you need to consider that sort of thing.

> I think clarifying this further in the draft would be helpful.

I agree, because I’m still confused :-) 

To clarify my question: Assuming the case of TLS encapsulation to the HTTPS port across a DPI middle-box that hates that sort of thing. If TLS uses the NULL cipher, can the middlebox not tell that the protocol over TLS is not HTTP? (I will defer to the experts.)

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Apr 2017 14:06:27 +0300

If we ever want to run other protocols there, we still have 255
reserved values we can use as Non-ESP marker. The reason the
0x00000000 is selected as Non-ESP marker in the UDP encapsulation (and
here) is because first four octets of the ESP packet are SPI, and SPI
MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the
Internet Assigned Numbers Authority (IANA) for future use" in the
RFC4303.

So if we need to run something else than IKE and ESP over that tunnel
we just reserve one of the other reserved IANA numbers for it and use
it as protocol marker for this new protocol. 

> allow zero value SPIs? If not, please consider dropping the MUST NOT.  

RFC4303 reserves value zero for the "for local,
implementation-specific use and MUST NOT be sent on the wire.".

I.e., conforming ESP packet coming the to the UDP or TCP encapsulation
layer cannot have SPI of zero ever. And we are not using SPI zero, we
are using it as marker that this is not ESP packet, but this is IKE
packet.

The full text from the RFC4303 about the reserved SPI numbers is:
----------------------------------------------------------------------
2.1.  Security Parameters Index (SPI)
...
   The set of SPI values in the range 1 through 255 are reserved by the
   Internet Assigned Numbers Authority (IANA) for future use; a reserved
   SPI value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  The SPI value of zero (0)
   is reserved for local, implementation-specific use and MUST NOT be
   sent on the wire.  (For example, a key management implementation
   might use the zero SPI value to mean "No Security Association Exists"
   during the period when the IPsec implementation has requested that
   its key management entity establish a new SA, but the SA has not yet
   been established.)
-- 
[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 09:57:18 -0400

> To clarify my question: Assuming the case of TLS encapsulation to the HTTPS port across a DPI middle-box that hates that sort of thing. If TLS uses the NULL cipher, can the middlebox not tell that…

IPsec WG participants should chime in here, Yoav may know for sure
with his background, I'm sure others too.

I'd guess that a DPI would not pick it up as the protocol inspection
most likely assumes when it sees TLS, that the traffic is encrypted
and looks no further for inspection/blocking purposes.  The
middleboxes that do some protocol inspection aren't like the ones from
15-20 years ago that dug into the protocol (blocking FTP commands,
etc.).

The use of TCP 443 for this has been in place for a decade or two,
Google QUIC also uses TCP 443, and I'm sure other services do too. So
tunneling does work.

For purity, are we worried if this is TLS or HTTP/TLS (as the port
usage specifies) or does that matter?

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Apr 2017 10:03:10 -0500

> On Apr 26, 2017, at 6:06 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Ben Campbell writes:

Ah, I didn’t realize 1-255 were reserved. It might be worth a mention that if future protocols are added, their prefixes must be registered with IANA. (I note that 2 are registered already.)

Am I correct to assume the draft did not also add a prefix for ESP is due to performance reasons? Doing so would completely avoid any possible collisions between the prefix value and the SPI.

> The full text from the RFC4303 about the reserved SPI numbers is:

Got it. I propose the following:

OLD:
The SPI field in the ESP header MUST NOT be a zero value.”
NEW:
[RFC4303] forbids a value of zero in the SPI field.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Apr 2017 08:05:35 -0700

On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty <
[email-masked]> wrote:

> > We are probably splitting hairs on the meaning of “implementation” vs
> “configuration”. (and maybe “deployment”). I was thinking of
> “implementation” as being what developers do, and “configuring/deploying”
> as what operators do. But I am aware that operators sometimes talk about
> “implementing” a system.
> >
> > So my point was that I assume for purposes of interoperability that a
> general purpose client or server would allow the port to be changed in the
> field.
> >
> >>
> >>>
> > Imagine a misconfigured client opening a connection to an web server on
> port 80, expecting to find a VPN service. What happens? I think that a
> consequence of the design approach to allow this to run over ports assigned
> to other protocols is that you need to consider that sort of thing.
> >
> >>>
> > To clarify my question: Assuming the case of TLS encapsulation to the
> HTTPS port across a DPI middle-box that hates that sort of thing. If TLS
> uses the NULL cipher, can the middlebox not tell that the protocol over TLS
> is not HTTP? (I will defer to the experts.)
>

Hmm... In most cases people are tunnelling over HTTP, and due to concerns
about cross-protocol attacks, I think that's a good thing. See, for
instance  [0]

> tunneling does work.

Hmm... Not to my knowledge.  QUIC is UDP over 443 I believe that in cases
where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have
a pointer?

-Ekr

[0] http://www.adambarth.com/papers/2011/huang-chen-barth-
rescorla-jackson.pdf

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 11:13:21 -0400

On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla <[email-masked]> wrote:
>
>
> On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty
> <[email-masked]> wrote:
>>
>> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty
>> >> <[email-masked]> wrote:
>> >>
>> > “implementation” as being what developers do, and “configuring/deploying” as
>> > what operators do. But I am aware that operators sometimes talk about
>> > “implementing” a system.
>> >
> about cross-protocol attacks, I think that's a good thing. See, for instance
> [0]
>

This draft doesn't make that clear.  If that is the case, then I had
previously asked somewhere in this thread if they could just specify
that so the proper use of 443 would be in place - ending the
discussion.

> where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have

No, it was sent to me in thread by a WG participant... so discard for now.
>
> -Ekr
>
>
> [0]
> http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
>
>
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Apr 2017 08:34:04 -0700

On Wed, Apr 26, 2017 at 8:13 AM, Kathleen Moriarty <
[email-masked]> wrote:

> >> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer
> one
> >> >>> of
> >> >>>>> I suspect "configurable local policy" would make more sense.
> Leaving
> >> >>>>> it
> >> >>>>> implementations making non-intersecting port choices, which
> doesn't
> >> >>>>> help
> >> >>>>> interoperability.
> >> >>>>
> >> >>>>
> >> >>>>> -4, first paragraph: What is the expected behavior from a peers
> that
> >> >>>>> do
> >> >>>>> primary reasons to use TLS? (Namely to obscure the fact that this
> is
> >> >>>>> not
> instance

Sorry, bad writing on my part. I think they're not doing that here, so we
should at least ask if that's a problem (though the answer may well be
"no")

-Ekr

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Apr 2017 10:35:40 -0500

By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. Only the first point was part of the DISCUSS, the rest are non-binding comments. And I think the DISCUSS point is moving in the right direction, pending a text proposal.

Thanks!

Ben.

> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 26 Apr 2017 10:50:23 -0700

Hi Ben,

Thanks for the comments! Your point about the line in Section 6 not making sense is definitely a good point. How about this text (changes in bold):

If a TCP connection is being used to resume a previous IKE session,
   the TCP Responder can recognize the session using either the IKE SPI
   from an encapsulated IKE message or the ESP SPI from an encapsulated
   ESP message.  If the session had been fully established previously,
   it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
   message if MOBIKE is supported, or an INFORMATIONAL message (a
   keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
   for the existing IKE session on new an incoming connection unless that connection
   begins with the stream prefix. If either the TCP Originator or TCP Responder
   cannot parse valid IKE or ESP messages on a TCP encapsulation connection
   that was started with a valid stream prefix, it MUST close the TCP connection.]  
   If there is instead a syntax issue within an IKE
   message, an implementation MUST send the INVALID_SYNTAX notify
   payload and tear down the IKE SA as usual, rather than tearing down
   the TCP connection directly.

Thanks,
Tommy

> On Apr 26, 2017, at 8:35 AM, Ben Campbell <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Apr 2017 13:36:29 -0500

> On Apr 26, 2017, at 12:50 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Ben,
> 

That looks good to me. I will clear, with the assumption this or similar edits will make it into the draft.

Thanks!

Ben.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 26 Apr 2017 14:58:48 -0500

Hi, Ben and Tommy,

On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell <[email-masked]> wrote:

> > Thanks for the comments! Your point about the line in Section 6 not
> making sense is definitely a good point. How about this text (changes in
> bold):
> >

Does

*The TCP Responder MUST NOT accept any messages*
*   for the existing IKE session on new an incoming connection unless that
connection*
*   begins with the stream prefix. *

parse for you guys? I get stuck at "on new an incoming".

Spencer

> >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the
> thread. Only the first point was part of the DISCUSS, the rest are
> non-binding comments. And I think the DISCUSS point is moving in the right
> direction, pending a text proposal.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> one of
> Leaving it
> doesn't help
> that do
> >>>> Imagine a misconfigured client opening a connection to an web server
> on port 80, expecting to find a VPN service. What happens? I think that a
> is not

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Apr 2017 15:08:07 -0500

> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Ben and Tommy,
> 
> The TCP Responder MUST NOT accept any messages
>    begins with the stream prefix. 
> 
> parse for you guys? I get stuck at "on new an incoming”.

I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”?

---

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

> On Apr 26, 2017, at 1:08 PM, Ben Campbell <[email-masked]> wrote:
> 
>> 

Yes, I meant "on a new incoming connection". Sorry!

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 26 Apr 2017 20:27:11 -0500

On Apr 26, 2017 16:23, "Tommy Pauly" <[email-masked]> wrote:

On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

Hi, Ben and Tommy,

Hi Ben,

Thanks for the comments! Your point about the line in Section 6 not making
sense is definitely a good point. How about this text (changes in bold):

  for the existing IKE session on new an incoming connection unless that
connection
  begins with the stream prefix. If either the TCP Originator or TCP
Responder
  that was started with a valid stream prefix, it MUST close the TCP
connection.]

Thanks,
Tommy

That looks good to me. I will clear, with the assumption this or similar
edits will make it into the draft.

Does

The TCP Responder MUST NOT accept any messages
  for the existing IKE session on new an incoming connection unless that
connection
  begins with the stream prefix.

Thanks for clarifying. I thought I was experiencing telechat blindness ;-)

Spencer

Thanks,
Tommy

Spencer

Thanks!

Ben.

By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread.
Only the first point was part of the DISCUSS, the rest are non-binding
comments. And I think the DISCUSS point is moving in the right direction,
pending a text proposal.

Thanks!

Ben.

On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <
[email-masked]> wrote:

On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <
[email-masked]> wrote:

To clarify my question: Assuming the case of TLS encapsulation to the HTTPS
port across a DPI middle-box that hates that sort of thing. If TLS uses the
NULL cipher, can the middlebox not tell that the protocol over TLS is not
HTTP? (I will defer to the experts.)

--

Best regards,
Kathleen

---

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

Ben Campbell writes:
> Ah, I didn’t realize 1-255 were reserved. It might be worth a
> mention that if future protocols are added, their prefixes must be
> registered with IANA. (I note that 2 are registered already.)

I do not think it belongs to this document. This is not actually using
reserved SPIs, but I think it should be enough to see that there is a
way to extend this, but as we do not see the need for extension now,
we do not need to think how we are going to do it. There are other
ways of doing that extension also and everything depends what we
really want to do.

Trying to guess things now is not really useful.

> Am I correct to assume the draft did not also add a prefix for ESP
> is due to performance reasons? Doing so would completely avoid any
> possible collisions between the prefix value and the SPI.

Actually RFC3947/3948 original invented this method, and the reason we
do not add prefix is to save 4 or 8 octets on every single ESP packet.
The ESP header needs to be alinged to 4 or 8 octet boundary thus
minimum overhead would be 4 or 8 octets (see RFC5840 for example,
i.e., WESP adds extra header before ESP).

There is no possibility with collisions with ESP, as ESP specifies
that SPI zero is always reserved, and MUST NOT ever appear on the
wire. Thus ESP packet with SPI of zero is invalid. As IKE packets are
much less frequent than ESP packets (with ratio of million or billion
to 1), it does not matter that we add some extra overhead to them.
Also IKE payload does not need to be aligned so we can go with just 4
octets of overhead, and does not need to care about the IPv4 vs IPv6
alignment requirements.

> [RFC4303] forbids a value of zero in the SPI field.

That is good change, I would recommend that authors do that change. 
-- 
[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 27 Apr 2017 17:33:00 -0500

> On Apr 27, 2017, at 7:09 AM, Tero Kivinen <[email-masked]> wrote:
> 
>>>> Substantive Comments:
>>>> 
>>>> -3, first paragraph:

The reason I thought it might be worth mentioning it would be to help prevent people from heading down a wrong path in future extensions. I’m okay with leaving it out if people think the probability of it coming up is low.