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