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 <[email protected]
<mailto:[email protected]>>
*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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
