Hi Tommy,
I reviewed the draft.
Generally, the draft is in a good shape. It is well written and contains almost
no
editorial issues. There are however some places where I'd like to see more
clarification, all of them are listed below.
My main problem with the draft is that it has an intended status Standards
Track and
at the same time its main goal, as specified in the Introduction, is to invent
some hack to cheat middleboxes that don't pass UDP. In this context
the proposal to use TLS (and port 443) looks especially ugly, however it is
probably
the most "penetrating" solution. I understand that the world is not perfect and
we must deal with it. However I think that the Standards Track documents must
try
to model more or less ideal world (to some extent) and should not standardize
hacks,
tricks and so on.
On the other hand, TCP encapsulation per se doesn't look bad, and I think it is
worth
to have standard interoperable solution to encapsulate IKE and ESP in TCP.
I would have had much less problems with this proposal it the draft was
splitted
into two documents - one Standards Track document describing TCP encapsulation
per se, and the other Informational document describing all the hacks and
tricks
to cheat the middleboxes that try not to pass anything except e.g. http and/or
https.
And I'd like all the TLS encapsulation stuff go into that draft.
1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be
preferred over using TCP
Encapsulation is present twice in the document (in Sections 1 and 2). I
think it's OK to reemphasize
this requirement, however since both of them use RFC2119 language, they
look duplicated.
I'd suggest to change one of the SHOULDs to lower case.
2. Section 3.
Although a TCP stream may be able to send very long messages,
implementations SHOULD limit message lengths to typical UDP datagram
ESP payload lengths. The maximum message length is used as the
effective MTU for connections that are being encrypted using ESP, so
the maximum message length will influence characteristics of inner
connections, such as the TCP Maximum Segment Size (MSS).
this text is not clear for me. IKE and ESP message length can be up
to 64Kbytes, so how it can be used as effective MTU (that is less than or
equal to the interface MTU, that is usually about 1500 bytes)?
How it can influence MSS, that is usually less than or equal to
path MTU to avoid IP fragmentation? Am I missing something?
3. Section 4.
Any specific IKE SA, along with its Child SAs, is either TCP
encapsulated or not. A mix of TCP and UDP encapsulation for a single
SA is not allowed. The exception to this rule is SAs that are
migrated between addresses using MOBIKE Section 7.
the last sentence is not accurate. As far as I understand, if IKE SA (along
with
its Child SAs) migrated from one address to another via MOBIKE, then
either all these SAs (IKE & its children) use TCP encapsulation
or all them use traditional encapsulation. So, it is not an exception
from the rule. Well, my reading of the rule that "the mix is not allowed"
is that by "mix" you mean situation when IKE SA uses one type
of encapsulation while some of its children use different type.
I'd suggest to clarify this text so that any ambiguity is eliminated.
4. Section 5.
A peer must discard a partially received message due to a broken
connection.
s/must/MUST ?
5. Section 9.
NAT keep-alive packets over a TCP
encapsulated IPSec connection will be sent with a length value of 1
byte, whose value is 0xFF Figure 2.
Shouldn't "Figure 2" be enclosed in brackets?
6. Section 11.
There is no subsection describing additional overhead to the size of the
ESP
and IKE messages when using TCP encapsulation.
This overhead may be important for some implementations. Consider some
application (e.g. VoIP) that sends small packets, e.g. about 50 bytes in
size.
With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = 36
bytes.
With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) = 52
bytes.
The difference may be significant for low bandwith networks or low power
consumption
devices. With TLS the situation will be worse.
7. Section 11.3
It is not clear from the text where NULL cipher should be used - in ESP
or in TLS? If it is about TLS, then does by NULL cipher you mean
TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS
(I'm not a TLS expert)? If it is about ESP NULL cipher,
then it contradicts to last para in Section 12... I think it should be
clarified.
8. The draft is silent about ESP Sequence Numbers. I think a few words could
be added that while the ESP SN are unnecessary with TCP encapsulation,
the sender still must increnet it in every sent packet.
Regards,
Valery Smyslov.
----- Original Message -----
From: Tommy Pauly
To: [email protected]
Sent: Tuesday, February 16, 2016 12:52 AM
Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft
Hello all,
I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation
draft. The changes include:
- Making the use case (as a last resort if UDP is blocked) more clear in the
introduction
- Clarify connection establishment and teardown section (allowing a resumed
connection to start with either IKE or ESP traffic, allowing multiple SAs on
one TCP connection)
- Adding more details about interactions with IKEv2 fragmentation, and TCP
MSS and QoS markings
- Clarifying the keep-alive/DPD section
- A new appendix written by a new author from Cisco giving four example
exchanges with TCP encapsulation of IKEv2.
https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03
I believe this should address many of the comments the last draft received.
Please take a look and provide your feedback! If the working group is in favor,
I’d like to see if this can be adopted by the working group.
Thanks,
Tommy
------------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
