Hi Paul, Daniel, Thanks for the comments! Responses inline.
I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is satisfactory to resolve those issues. Thanks, Tommy > On May 6, 2016, at 4:48 PM, Paul Wouters <p...@nohats.ca> wrote: > > 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. Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks makes most sense is fine with me. > >> 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. Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do generic TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the future, so we specifically leave this port option as a configuration property. We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, due to comments from the group on inclusion of direct references to TLS in the standard. > >> 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. We can add a mention that the ESP SPI must be non-zero to match the other RFCs. > >> 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. That's correct. > >> """ >> 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? We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break in message IDs. > >> 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
