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?
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?
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
