Hi Tommy, Thank you very much for the response. They are addressing all my concerns.
BR, Daniel On Mon, May 16, 2016 at 4:15 PM, Tommy Pauly <[email protected]> wrote: > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
