Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one 
question remains.


I still don't understand why we require that each connection should 
start with an IKE message. The explanation given is "to allow the peer 
to know with which IKE session the traffic is associated." But of course 
the ESP SPI identifies the Child SA, and implicitly, the IKE SA.


Moreover, later in the same section you allow multiple IKE SAs over the 
same connection, which again doesn't work well with the reasoning above.


Best,
Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:

Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt

Please check it out, and provide feedback.


Thanks.
Samy.


*From:* Yaron Sheffer >

*Sent:* Nov 20, 2015 3:11 PM
*To:* Tommy Pauly; IPsecME WG
*Subject:* Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited
under "prior work", both because it is documented and also because I
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers
will use UDP encapsulation even when there is no NAT on the path, for
example because networks or middleboxes do not support IP protocols
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams
don't send anything) and is hard to understand. There are lots of
networks that use jumbo frames and so hardcoding the value 1500 into the
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that
are all associated with the same IKE SA. So I'm wondering why we are
insisting on all Child SAs being in the same connection, and as a result
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly
that if the connection is closed midway through a message, the recipient
must silently drop the partial message.

You may want to add to the last paragraph of the Security
Considerations: This document explicitly does not define a profile for
TLS when used in this manner, or any relation between identities at the
IPsec level and those at the TLS level ("channel binding").

Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, 
I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:

>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and 
other work that this draft is trying to standardize (3GPP 
recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP 
stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and 
re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes 
(thanks Graham Bartlett for input on this).

>
> In the meeting in Yokohama, there was general agreement that this 
was relevant work that we’d like to keep looking into. Please read the 
document, and provide any feedback you have!

>
> Thanks,
> Tommy
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec
>

___
IPsec mailing list
IPsec@ietf.org 
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Tommy,

Thanks for clarifying this point. But I still think we are making a 
protocol change for what can be solved easily at the implementation 
level. Implementations will need to tag each IKE SA with the currently 
valid TCP connection on which responses can be sent. And ESP SAs likely 
already point to their parent IKE SA. So when we have an ESP packet that 
needs to be sent back from the responder, why not look up its associated 
IKE SA and use it to find the TCP connection?


IMHO it would be better if we can stick to the simple model of a TCP 
wrapper for an unordered pile of IKE and ESP messages. This would add 
TCP with the minimal change to ESP, IKE and the relationship between them.


Thanks,
Yaron

On 12/08/2015 10:24 PM, Tommy Pauly wrote:

Hi Yaron,

The original version of the draft did not require that the new TCP 
connection begin with an IKE message, but it was added in response to 
feedback we received at our meeting in Yokohama.


The concern was that the new TCP connection would almost certainly 
have different ports from the old connection. In order for the server 
to send packets back to the client, it needs to know the correct 
mapping for both the IKE SAs and the Child SAs. If we allow an ESP 
packet to be the first packet of a new connection, it may be hard to 
implement a correct server that reacts to that and adjusts all 
associated IKE and Child SA values to use the new port. However, it 
the first packet is an IKE packet, the server can essentially treat it 
as if it were MOBIKE and reset the ports.


In the case of multiple IKE SAs over a TCP connection (which is a new 
edge case that has been brought up), perhaps it would make sense to 
say that for all IKE SAs using the connection, at least one IKE 
message must precede any ESP messages for a Child SA of the IKE SA.


Does this make sense?

Thanks,
Tommy

On Dec 8, 2015, at 2:12 AM, Yaron Sheffer > wrote:


Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one 
question remains.


I still don't understand why we require that each connection should 
start with an IKE message. The explanation given is "to allow the 
peer to know with which IKE session the traffic is associated." But 
of course the ESP SPI identifies the Child SA, and implicitly, the 
IKE SA.


Moreover, later in the same section you allow multiple IKE SAs over 
the same connection, which again doesn't work well with the reasoning 
above.


Best,
Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:

Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt

Please check it out, and provide feedback.


Thanks.
Samy.


*From:* Yaron Sheffer 
*Sent:* Nov 20, 2015 3:11 PM
*To:* Tommy Pauly; IPsecME WG
*Subject:* Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be 
cited

under "prior work", both because it is documented and also because I
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers
will use UDP encapsulation even when there is no NAT on the path, for
example because networks or middleboxes do not support IP protocols
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams
don't send anything) and is hard to understand. There are lots of
networks that use jumbo frames and so hardcoding the value 1500 into 
the

spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs 
that

are all associated with the same IKE SA. So I'm wondering why we are
insisting on all Child SAs being in the same connection, and as a 
result

requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly
that if the connection is closed midway through a message, the 
recipient

must silently drop the partial message.

You may want to add to the last paragraph of the Security
Considerations: This document explicitly does not define a profile for
TLS when used in this manner, or any relation between identities at the
IPsec level and those at the TLS level ("channel binding").

Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in 
Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:

>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and 
other work that this draft is trying to standardize (3GPP 
recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL 
VPNs).
> - Comments about maximum IKE and ESP message 

Re: [IPsec] New revision of TCP Encapsulation draft

[Tommy Pauly]

Hi Yaron,

The original version of the draft did not require that the new TCP connection 
begin with an IKE message, but it was added in response to feedback we received 
at our meeting in Yokohama.

The concern was that the new TCP connection would almost certainly have 
different ports from the old connection. In order for the server to send 
packets back to the client, it needs to know the correct mapping for both the 
IKE SAs and the Child SAs. If we allow an ESP packet to be the first packet of 
a new connection, it may be hard to implement a correct server that reacts to 
that and adjusts all associated IKE and Child SA values to use the new port. 
However, it the first packet is an IKE packet, the server can essentially treat 
it as if it were MOBIKE and reset the ports.

In the case of multiple IKE SAs over a TCP connection (which is a new edge case 
that has been brought up), perhaps it would make sense to say that for all IKE 
SAs using the connection, at least one IKE message must precede any ESP 
messages for a Child SA of the IKE SA.

Does this make sense?

Thanks,
Tommy

> On Dec 8, 2015, at 2:12 AM, Yaron Sheffer  wrote:
> 
> Hi Samy,
> 
> Thanks for the new draft. It addresses most of my comments, but one question 
> remains.
> 
> I still don't understand why we require that each connection should start 
> with an IKE message. The explanation given is "to allow the peer to know with 
> which IKE session the traffic is associated." But of course the ESP SPI 
> identifies the Child SA, and implicitly, the IKE SA.
> 
> Moreover, later in the same section you allow multiple IKE SAs over the same 
> connection, which again doesn't work well with the reasoning above.
> 
> Best,
> Yaron
> 
> On 12/08/2015 08:40 AM, Samy Touati wrote:
>> Hi Yaron and Yoav,
>> 
>> An updated draft addressing your comments has been posted.
>> 
>> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt 
>> 
>> 
>> Please check it out, and provide feedback.
>> 
>> 
>> Thanks.
>> Samy.
>> 
>> 
>> From: Yaron Sheffer < yaronf.i...@gmail.com 
>> >
>> Sent: Nov 20, 2015 3:11 PM
>> To: Tommy Pauly; IPsecME WG
>> Subject: Re: [IPsec] New revision of TCP Encapsulation draft
>> 
>> Hi Tommy,
>> 
>> I also think this is very relevant work. Here are some comments to -01:
>> 
>> I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
>> under "prior work", both because it is documented and also because I 
>> believe it is implemented by a vendor.
>> 
>> In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
>> will use UDP encapsulation even when there is no NAT on the path, for 
>> example because networks or middleboxes do not support IP protocols 
>> other than TCP and UDP."
>> 
>> "Although a stream" - this paragraph is not worded very well (streams 
>> don't send anything) and is hard to understand. There are lots of 
>> networks that use jumbo frames and so hardcoding the value 1500 into the 
>> spec may not be a good idea.
>> 
>> I can think of HA cases where several gateways are handling ESP SAs that 
>> are all associated with the same IKE SA. So I'm wondering why we are 
>> insisting on all Child SAs being in the same connection, and as a result 
>> requiring that an IKE message be the preamble to any new connection.
>> 
>> Although it might seem obvious, I think Sec. 3 should say explicitly 
>> that if the connection is closed midway through a message, the recipient 
>> must silently drop the partial message.
>> 
>> You may want to add to the last paragraph of the Security 
>> Considerations: This document explicitly does not define a profile for 
>> TLS when used in this manner, or any relation between identities at the 
>> IPsec level and those at the TLS level ("channel binding").
>> 
>> Thanks,
>> Yaron
>> 
>> On 11/20/2015 11:49 PM, Tommy Pauly wrote:
>> > Hello,
>> >
>> > Based on the feedback received at our informal meeting in Yokohama, I’ve 
>> > updated the draft for TCP Encapsulation of IKEv2 and ESP:
>> >
>> > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 
>> > 
>> >
>> > The revisions include:
>> > - More explanation in the introduction about the motivation, and other 
>> > work that this draft is trying to standardize (3GPP recommendations, 
>> > proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
>> > - Comments about maximum IKE and ESP message size within the TCP stream, 
>> > which is effective the MTU of the tunnel.
>> > - Specify that if the TCP connection is brought down and re-established, 
>> > the first message on the stream must be an IKE message.
>> > - Detailed considerations about interactions with middleboxes (thanks 
>> > Graham Bartlett for input on this).
>> >
>> > In the meeting in