On Fri, 6 May 2016, Daniel Migault wrote:
s/IPSec/IPsec
If Tommy could also fix that auto-correct for my iphone, that would be great too :)
"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...
This has happened in this group a few times now in different documents. People want to say IKEv2 to exclude IKE, but we should really say IKE so these documents don't look weird when/if we get IKEv3.
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.
We should not define a port unless it is 443, which we kind of cannot.
I think that we shoudl specify that ESP SPI MUST be non zero to avoid the confusion between ESP SPI and Non-ESP marker.
First I thought this was not needed, because RFC-3948 would define that, but it does look confusing because it is mentioned in the section titled "UDP-Encapsulated ESP Header format": https://tools.ietf.org/html/rfc3948#section-2.1 So the draft should probably include something simiar to that section.
An IANA allocated port could could be such indicaton. In that case, would we need this prefix ?
We all know SSL VPNs exist because some networks block (4)500 on purpose.
""" 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. """
Note: what it you suddenly notice you can go back to UDP. Wouldn't you have a mix while you migrate all the TCP-ESP to UDP-ESP?
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.
It might be best to avoid making any statement on this. For example libreswan introduced a force-encaps= option to work around Amazon not routing ESP packets. If you mention anything for IKE vs ESP you might add limitations that might cause problems later on. While I think we should have SHOULD language on trying to move TCP sessions to UDP, I wouldn't go as far to forbid certain combinations.
In fact a network may have different firewall rules for IKEv2 and ESP """ 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.
well, on UDP it is obvious the port can change and you can just update the port on the receiver based on the last received udp port. with tcp clearly you know when it is being shut down. I'm not sure if the receiver should keep such an orphaned IKE SA while waiting for another TCP session to come in though. It might make sense of there is a DOS attack using spoofed RST packets, but the attacker can't be stopped anyway. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
