[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Next steps on TCP Encapsulation for IKEv2
From: Yoav Nir <ynir.ietf () gmail ! com>
Date: 2016-04-06 19:13:51
Message-ID: A6AF5D18-7D93-489D-8D1D-39F903D21B8C () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
My opinion is colored by my implementation. Our gateway listens in on port 443, and \
has to distinguish between several kinds of connections:
- IKE-over-TCP (it's the old IKEv1 think, but still…)
- TLS handshake, and that splits further into:
- SSL-VPN
- with your draft: IKE
- HTTPS to some kind of portal served by the gateway.
So the first thing is to distinguish between TLS and non-TLS, and the question is \
"does it look like ClientHello". ClientHello looks like 16 03 00/01/02/03 00/01/02. \
In version -03 of the draft you are proposing to begin the a 4-byte length field, so \
assuming a 1000-bye Initial request, that's going to be 00 00 03 E8. This looks \
different enough. There is a proposal to make this field 2-byte, so this would start \
with 03 E8 00 00. Is this OK? Yes, but what if we happened to have an Initial \
request with size 5635? Then we get 16 03 00 00. That looks too much like \
ClientHello. Of course I can argue that a 5635-byte Initial request is ludicrously \
large, but I still think this is worth it.
For the second kind of distinguishing we'd need to tell apart whatever SSL-VPN \
protocol we support from IKE. I think the magic number would help here as well. \
HTTP/2 has this really big magic described in section 3.5, but HTTP/1 does not. So I \
think a magic will be needed there as well.
Yoav
> On 6 Apr 2016, at 11:20 AM, Tommy Pauly <tpauly@apple.com> wrote:
>
> Hi Yoav,
>
> Thanks for the feedback. While I see the advantage of adding the magic value at the \
> start of the non-TLS TCP stream, especially over port 443, this seems to require \
> the document to even more explicitly discuss TLS. If implementations do end up \
> using TLS, as I believe many will in practice, then presumably they would not \
> include this magic byte at the beginning of their stream over TLS. This means that \
> the inner protocol diverges depending on which set of protocols are being used for \
> the stream. I would prefer that these be consistent if possible.
> Thoughts?
>
> Tommy
>
> > On Apr 5, 2016, at 1:14 PM, Yoav Nir <ynir.ietf@gmail.com \
> > <mailto:ynir.ietf@gmail.com>> wrote:
> > Hi, Tommy.
> >
> > The changes look fine, although I'm still not convinced we even need the TLS. But \
> > that's for another thread.
> > We foresee that most TCP encapsulation is likely to be in on port 443. I think \
> > TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other \
> > types of traffic on the same port.
> > I propose we add a magic value at the start of a non-TLS TCP stream, something \
> > very different from (0x16, 0x03, 0x01, 0x00).
> > Yoav
> >
> >
> > > On 5 Apr 2016, at 12:27 PM, Tommy Pauly <tpauly@apple.com \
> > > <mailto:tpauly@apple.com>> wrote:
> > > Hello,
> > >
> > > At our meeting yesterday, we agreed that we want one more revision of \
> > > draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group \
> > > adoption to clear up a few concerns.
> > > Here are the changes we're planning:
> > >
> > > 1. Reconcile the length field size with 3GPP's recommendation (sent out by \
> > > Tero) to promote interoperability if any devices have already implemented \
> > > 3GPP's suggestions. This would mean changing the length field from 32 bits to \
> > > 16 bits.
> > > 2. Address the concerns around including too many direct references to use of \
> > > TLS and port 443 in the body of the standards track document. The current plan \
> > > here would be to make all direct references to TLS in the body of the document \
> > > be more generic regarding any protocols over TCP that are added to encapsulate \
> > > the IKE session, and point to an appendix that explains the caveats regarding \
> > > TLS. The main point to communicate is that TLS should not influence the framing \
> > > of IKE or ESP packets on the stream, and that the encryption and authentication \
> > > properties of TLS do not influence the IKE session at all. Valery, I believe \
> > > this should address your concerns.
> > > Please reply with your feedback if you think these changes are good ideas, and \
> > > if there are any other remaining points that should be changed before we move \
> > > ahead.
> > > After this, the plan would be to ask for working group adoption of the document \
> > > if there are no other objections, and to in parallel start an informational \
> > > document (perhaps a draft, perhaps outside of IETF) to describe the practical \
> > > strategies for using TLS to encapsulate the tunnel, and more detail on proxy \
> > > interactions.
> > > Thanks,
> > > Tommy Pauly
> > > _______________________________________________
> > > IPsec mailing list
> > > IPsec@ietf.org <mailto:IPsec@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/ipsec \
> > > <https://www.ietf.org/mailman/listinfo/ipsec>
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org <mailto:IPsec@ietf.org>
> > https://www.ietf.org/mailman/listinfo/ipsec
>
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space;" class="">My opinion is colored by my \
implementation. Our gateway listens in on port 443, and has to distinguish between \
several kinds of connections:<div class=""> - IKE-over-TCP (it's the old IKEv1 \
think, but still…)</div><div class=""> - TLS handshake, and that splits \
further into:</div><div class=""> - SSL-VPN</div><div class=""> \
- with your draft: IKE</div><div class=""> - HTTPS to some kind of \
portal served by the gateway.</div><div class=""><br class=""></div><div class="">So \
the first thing is to distinguish between TLS and non-TLS, and the question is "does \
it look like ClientHello". ClientHello looks like 16 03 00/01/02/03 \
00/01/02. </div><div class="">In version -03 of the draft you are proposing to \
begin the a 4-byte length field, so assuming a 1000-bye Initial request, that's going \
to be 00 00 03 E8. This looks different enough. There is a proposal to make this \
field 2-byte, so this would start with 03 E8 00 00. Is this OK? Yes, but \
what if we happened to have an Initial request with size 5635? Then we get 16 \
03 00 00. That looks too much like ClientHello. Of course I can argue \
that a 5635-byte Initial request is ludicrously large, but I still think this is \
worth it.</div><div class=""><br class=""></div><div class="">For the second kind of \
distinguishing we'd need to tell apart whatever SSL-VPN protocol we support from IKE. \
I think the magic number would help here as well. HTTP/2 has this really big magic \
described in section 3.5, but HTTP/1 does not. So I think a magic will be \
needed there as well.</div><div class=""><br class=""></div><div \
class="">Yoav</div><div class=""><br class=""><div><blockquote type="cite" \
class=""><div class="">On 6 Apr 2016, at 11:20 AM, Tommy Pauly <<a \
href="mailto:tpauly@apple.com" class="">tpauly@apple.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" \
content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div \
class="">Hi Yoav,</div><div class=""><br class=""></div><div class="">Thanks for the \
feedback. While I see the advantage of adding the magic value at the start of the \
non-TLS TCP stream, especially over port 443, this seems to require the document to \
even more explicitly discuss TLS. If implementations do end up using TLS, as I \
believe many will in practice, then presumably they would not include this magic byte \
at the beginning of their stream over TLS. This means that the inner protocol \
diverges depending on which set of protocols are being used for the stream. I would \
prefer that these be consistent if possible.</div><div class=""><br \
class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div \
class="">Tommy</div><br class=""><div class=""><blockquote type="cite" class=""><div \
class="">On Apr 5, 2016, at 1:14 PM, Yoav Nir <<a \
href="mailto:ynir.ietf@gmail.com" class="">ynir.ietf@gmail.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><meta \
http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div \
style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space;" class="">Hi, Tommy.<div class=""><br class=""></div><div \
class="">The changes look fine, although I'm still not convinced we even need the \
TLS. But that's for another thread.</div><div class=""><br class=""></div><div \
class="">We foresee that most TCP encapsulation is likely to be in on port 443. I \
think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other \
types of traffic on the same port.</div><div class=""><br class=""></div><div \
class="">I propose we add a magic value at the start of a non-TLS TCP stream, \
something very different from (0x16, 0x03, 0x01, 0x00).</div><div class=""><br \
class=""></div><div class="">Yoav</div><div class=""><br class=""></div><div \
class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On \
5 Apr 2016, at 12:27 PM, Tommy Pauly <<a href="mailto:tpauly@apple.com" \
class="">tpauly@apple.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" \
content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello,<div \
class=""><br class=""></div><div class="">At our meeting yesterday, we agreed that we \
want one more revision of draft-pauly-ipsecme-tcp-encaps-03 before putting it up \
for working group adoption to clear up a few concerns.</div><div class=""><br \
class=""></div><div class="">Here are the changes we're planning:</div><div \
class=""><br class=""></div><div class="">1. Reconcile the length field size with \
3GPP's recommendation (sent out by Tero) to promote interoperability if any devices \
have already implemented 3GPP's suggestions. This would mean changing the length \
field from 32 bits to 16 bits.</div><div class=""><br class=""></div><div class="">2. \
Address the concerns around including too many direct references to use of TLS and \
port 443 in the body of the standards track document. The current plan here would be \
to make all direct references to TLS in the body of the document be more generic \
regarding any protocols over TCP that are added to encapsulate the IKE session, and \
point to an appendix that explains the caveats regarding TLS. The main point to \
communicate is that TLS should not influence the framing of IKE or ESP packets on the \
stream, and that the encryption and authentication properties of TLS do not influence \
the IKE session at all. Valery, I believe this should address your \
concerns.</div><div class=""><br class=""></div><div class=""><b class="">Please \
reply</b> with your feedback if you think these changes are good ideas, and if \
there are any other remaining points that should be changed before we move \
ahead.</div><div class=""><br class=""></div><div class="">After this, the plan would \
be to ask for working group adoption of the document if there are no other \
objections, and to in parallel start an informational document (perhaps a draft, \
perhaps outside of IETF) to describe the practical strategies for using TLS to \
encapsulate the tunnel, and more detail on proxy interactions.</div><div class=""><br \
class=""></div><div class="">Thanks,</div><div class="">Tommy \
Pauly</div></div>_______________________________________________<br class="">IPsec \
mailing list<br class=""><a href="mailto:IPsec@ietf.org" \
class="">IPsec@ietf.org</a><br class=""><a \
href="https://www.ietf.org/mailman/listinfo/ipsec" \
class="">https://www.ietf.org/mailman/listinfo/ipsec</a><br \
class=""></div></blockquote></div><br \
class=""></div></div>_______________________________________________<br \
class="">IPsec mailing list<br class=""><a href="mailto:IPsec@ietf.org" \
class="">IPsec@ietf.org</a><br class=""><a \
href="https://www.ietf.org/mailman/listinfo/ipsec" \
class="">https://www.ietf.org/mailman/listinfo/ipsec</a><br \
class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br \
class=""></div></body></html>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic