Hi Valery, Thanks for your reply! I think these are good points that we can clarify in future versions, although we can address these once it is a working group document. Responses inline.
Best, Tommy > On May 16, 2016, at 11:53 PM, Valery Smyslov <sva...@gmail.com> wrote: > > Hi Tommy, > > sorry for late reply. I'm mostly OK with the last version of the draft. > > Few comments. It is a bit unclear how Stream Prefix is intended > to be used with TLS. Is it insterted at the beginning of the TLS data stream? The intention is that the prefix is used at the beginning of the stream even when TLS is being used (specifically, inside the encrypted TLS stream). Since the point of the prefix is to identify which specific protocol is being used, to differentiate from other TLS or VPN traffic, it is relevant to use it even when going over TLS port 443 in case the server being used also supports other VPN protocols over the same port using TLS. This is one of the points Yoav brought up. > > Then, I think some text should be added describing a situation > when the original responder having a valid (from its point of view) > TCP session receives a request from original initiator for a new > TCP session. This may happen if original initiator looses TCP > state for some reason (RST from an attacker, temporary network failure etc.). > In this case the responder will have two TCP sessions associated with > the IKE SA. Clearly, the new one should be used for further communications, > but only after it is proven to be authentic (some protected message is > received > over it). But what the responder should do with the old TCP session? > Keep it? Send FIN? Send RST? Just discard? > In general, the approach of the draft is to clearly separate the TCP state from the IKE session state. If you look at Section 6, it specifically allows for multiple TCP connections between two peers even if there is only one IKE SA between them. If one of them becomes redundant (because the other peer opened up a new TCP flow for some reason), it would make sense to close the other in a usual way. I think this can be left to the implementation, but either a FIN or RST would be appropriate rather than a discard. We can add that to future versions. > Regards, > Valery. > >> 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 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
