On Jun 14, 2012, at 10:34 PM, John Leser wrote:
> On 06/14/12 13:39, Yoav Nir wrote:
>> Hi Yaron
>>
>> Responses are inline.
>>
>> Yoav
>>
>> On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote:
>>
>>> Hi Yoav,
>>>
>>> thank you for the new draft. A few comments:
>>>
>>> - Please mention the question of IKE keepalive messages ("liveness
>>> check"). Do you expect these messages to each be on a new connection? Or
>>> to preserve one long-lived one?
>>
>> I think section 2.1 makes it clear that the TCP connections should be
>> short-lived. Specifically, I would not send liveness checks, which are very
>> short requests and responses over TCP. I would use UDP exclusively for those.
>>
>
> This section is a little unclear to me. Is the idea that the initiator
> of the exchange(s) may send up to <IKEv2 request window> requests, wait
> for the responses to arrive and then must close the connection? Or can
> the initiator perform as many exchanges as it likes over one TCP
> connection, so long as "knows" that it has requests it wants to send?
> If this connection closing requirement is designed to interact with the
> IKEv2 request window, please make it more clear.
OK, I will. It has nothing to do with the request window. The Initiator can
send as many requests as it wants as long as it has any to send. When it's idle
(like if all the necessary child SAs are ready) it should close the connection
rather than leave it idle.
>>> - The draft kind of skirts the question, and I would prefer to be clear:
>>> we are standardizing new behavior for IKEv2, not for IKEv1.
>>
>> I think it's suitable for both versions. If this gets adopted by the working
>> group, and people object to standardizing new stuff for IKEv1, I can remove
>> all mention of it.
>>
>> <hat type="vendor">
>> Our present implementation works with IKEv1, and has done so for over 10
>> years. I could submit an Informational describing how Check Point's
>> implementation does IKEv1 over TCP. But just as new ciphers would apply to
>> both versions, I think this transport can also be independent of version.
>> </hat>
>
> I'd rather settle on the best possible solution for IKEv2 without
> worrying about making sure it works for IKEv1 as well.
If that's where the group consensus is going, I am fine with making an
Informational document about IKEv1 over TCP in CP products.
>>> - In the security considerations, we should mention that (under certain
>>> assumptions), it is easier for an off-path attacker to reset a TCP
>>> connection than a UDP "connection".
>>
>> Yes, TCP presents some DoS opportunities not available for UDP. I'll look
>> for an RFC that talks about this. And if there isn't one, there d**n well
>> should be.
>>
>
> I suggest adding a MUST that a lost TCP connection or truncated packet
> from the peer should never constitute a failed exchange (which in many
> cases, closes the SA).
Agree
>>> - There are obvious advantages to negotiating this capability: you don't
>>> have clients sending SYNs that will get rejected by firewalls/endpoints.
>>> Especially in IKEv2 where the heavy stuff only happens on message #3.
>>
>> SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a
>> notification over UDP that says "I support TCP" doesn't help much, because
>> it cannot vouch for the path allowing TCP port 500. I wonder if there's an
>> actual use case for increasing the length field of payloads, so that IKE can
>> support larger payloads when working over TCP. One use for this would be to
>> send large CRLs in a CERT payload.
>>
>
> I agree with the concerns Yaron has raised here. I would much prefer
> that this be negotiated via notifications during the SA_INIT exchange.
> I see a number of benefits:
>
> 1. The TCP listening port could be explicitly exchanged (as data in the
> notification), rather than always assumed 500. This would allow
> operation in parallel with any legacy/proprietary use of that server
> port, and in general more deployment flexibility.
>
> 2. Since INIT always happens over UDP, as responder, I can immediately
> close any TCP connection that doesn't present an IKE header with an SPI
> I recognize.
I don't agree that IKE_SA_INIT should always be over UDP. The first flight of
packets from the server in TCP includes at most 2 packets. Then the server has
to wait for an ACK to continue. Same goes for the request. So beginning with
the IKE_AUTH exchange for TCP can add up to three roundtrips. This is a shame
when dealing with a peer that we know supports IKE.
> 3. It fits better with the IKEv2 design of never assuming the peer has
> capabilities beyond the base requirements without a notification/vendor
> payload indicating otherwise.
Just as clients may start IKE over UDP port 4500, they should be able to begin
IKE_SA_INIT over TCP. We can still have those notifications for clients using
UDP for IKE_SA_INIT, but it would be silly to send them over TCP.
>>> - 2.3: disallowing retransmissions implies a change on both transmitter
>>> and receiver, and I think this is unnecessary. You can change the IKE
>>> timeouts on the sender to achieve the same behavior, even if rarely an
>>> odd retransmission does slip through.
>>
>> I guess. There is a MUST in section 2.4 for keeping retransmission
>> detection, so when implementing the transmitter, you can do either. It
>> doesn't make sense to retransmit at the application level when TCP does it
>> for you.
>>
>
> Do we want to specify (maybe as a SHOULD) a fairly rapid fallback to UDP
> for retransmissions? This would help avoid protocol failures when the
> UDP path is functional but TCP is not. Messages ids should filter out
> any duplicates that get through.
Maybe as implementation advice. It doesn't affect interoperability.
>
> -John
>
>>>
>>> Thanks,
>>> Yaron
>>>
>>> On 06/14/2012 12:59 AM, Yoav Nir wrote:
>>>> Hi
>>>>
>>>> I've submitted this draft as a possible solution to the problem
>>>> discussed in the thread about fragmentation causing IKE to fail.
>>>>
>>>> Comments are welcome.
>>>>
>>>> Yoav
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> *From: *"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
>>>>> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
>>>>> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt*
>>>>> *Date: *June 13, 2012 7:13:55 PM GMT+03:00
>>>>> *To: *Yoav Nir<y...@checkpoint.com<mailto:y...@checkpoint.com>>
>>>>>
>>>>>
>>>>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt
>>>>> has been successfully submitted by Yoav Nir and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Filename:draft-nir-ipsecme-ike-tcp
>>>>> Revision:00
>>>>> Title:A TCP transport for the Internet Key Exchange
>>>>> Creation date:2012-06-13
>>>>> WG ID:Individual Submission
>>>>> Number of pages: 7
>>>>> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt
>>>>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp
>>>>> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00
>>>>>
>>>>>
>>>>> Abstract:
>>>>> This document describes using TCP for IKE messages. This facilitates
>>>>> the transport of large messages over paths where fragments are
>>>>> dropped.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>> Scanned by Check Point Total Security Gateway.
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
