Hi,
I have read the draft. TCP encapsulation is a topic that matters, and I
would like different vendors to implement a standard version of this. I
think the draft is in good shape to be adopted and discussed as a WG
document. I am volunteering to continue reviewing the draft and contribute
to the text once adopted.
Please find here my comments. None of them are controversial and they
should not prevent the adoption of the draft.
BR,
Daniel
abstract:
s/IPSec/IPsec
"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."
This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...
We have to chose IKE or IKEv2. If IKE is chosen, then may specify that
IKE means IKEv2. I have seen IKEV@ in appendix A
section 2:
"""
The configuration defined on each peer should include the following
parameters:
o One or more TCP ports on which the responder will listen for
incoming connections. Note that the initiator may initiate TCP
connections to the responder from any local port.
This document leaves the selection of TCP ports up to
implementations. It's suggested to use TCP port 4500, which is
allocated for IPSec NAT Traversal.
"""
I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.
"""
Optionally, an extra framing protocol to use on top of TCP to
further encapsulate the stream of IKEv2 and IPSec packets. See
Appendix A for a detailed discussion.
"""
If I am correct the extra framing is TLS. If so I think it woudl be
clearer to mention extra framing such as TLS.
section 3.2
I think that we shoudl specify that ESP SPI MUST be non zero to avoid
the confusion between ESP SPI and Non-ESP marker.
section 4:
My understanding is that the stream prefix is needed if because tcp
does not have a mechanism that indicates the content of the streams.
An IANA allocated port could could be such indicaton. In that case,
would we need this prefix ?
section 5:
"""
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.
"""
If I understand this correctly it means:
- a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
encapsulation.
- b) an IKEv2 connection OR an ESP session cannot use TCP
encapsulation or UDP or no encapsulation.
I propose to have something similar to this:
When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
encapsulated with TCP.
In fact a network may have different firewall rules for IKEv2 and ESP
traffic. IKEv2 is an application identified with specific ports
whereas ESP packets do not have ports.If the IKEv2 traffic and ESP
were not using the same encapsulation method (non encapsulation, UDP
encapsulation or TCP encapsulation), then IKEv2 would not be able to
proceed to reachability tests of the ESP path, as IKEv2 and ESP would
use different paths. In addition, IKEv2 would be expected to negotiate
the ESP encapsulation between the peers.
With UDP and TCP encapsulation, IKEv2 and ESP packet use the same port
and transport protocol, which means that IKEv2 proceeds to the
connectivity tests and set the tunnel. In the case non-encapsulated
IKEv2 are not blocked, but that ESP packets are blocked, it is the
responsibility of the IKEv2 client to DELETE the IKE_SA on both peers
and than renegotiate the IKEv2 exchange using UDP and then TCP
encapsulation.
If IKEv2 peers are using TCP encapsulation, and both peer support UDP
encapsulation as well as MOBIKE, then it can switch from TCP to UDP
encapsulation for both IKEv2 and ESP traffic by using MOBIKE. The peer
can advertise their respective support with MOBIKE_SUPPORTED and
NAT_DETECTION_*_IP Notify Payloads. When one of the IKEv2 peer
decides to switch from TCP to UDP encapsulation, all IKEv2 and ESP
traffic is switched from TCP to UDP. Note that the other way around is
not possible as IKEv2 does not advertise its support for TCP encapsulation.
[note that using NAT_DETECTION_*_IP as an UDP_ENCAPSULATION_SUPPORTED only
works when not encapsulated with UDP/TCP]
section 6:
Because of this text, I think it would be good to have a TCP
encapsulation and TCP decapsulation sections that describes TCP and
IPsec interactions.
"""
The original initiator (that is, the endpoint that initiated the TCP
connection and sent the first IKE_SA_INIT message) is responsible for
reestablishing the TCP connection if it is torn down for any
unexpected reason. Since new TCP connections may use different ports
due to NAT mappings or local port allocations changing, the responder
MUST allow packets for existing SAs to be received from new source
ports.
"""
Section 7:
This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may
currently seen as a UDP_ENCAPSULATION_SUPPORTED notify payload to. This
won't be the case anymore with IKEv2. Maybe we should provide more text on
this.
On Wed, Apr 27, 2016 at 2:38 PM, Tommy Pauly <[email protected]> wrote:
> Hello,
>
> Based on our discussions at IETF 95 and on the list, I’ve posted a new
> revision of the TCP Encapsulation draft (
> draft-pauly-ipsecme-tcp-encaps-04):
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-04
>
> The highlights of the new version are:
> - Moved all references to TLS to an appendix, so it is not part of the
> standard directly (Valery, I think this should address your concerns)
> - Changed the length field to 16 bits to match 3GPP implementations
> (thanks to Tero for this suggestion)
> - Added a magic value to put once at the beginning of any TCP stream to
> indicate that it is being used for IKEv2, to allow differentiation from
> other streams if we re-use well-known ports (thanks to Yoav for this
> suggestions)
>
> I believe this addresses all of the concerns brought up previously, so I’d
> like to see if we could get adoption from the working group to move this
> draft forward. Please reply with your thoughts on this!
>
> Thanks,
> Tommy Pauly
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
