[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt

2012-06-13 Thread Yoav Nir
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.orgmailto:internet-dra...@ietf.org 
internet-dra...@ietf.orgmailto: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.commailto: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


Re: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt

2012-06-13 Thread Yaron Sheffer

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?
- The draft kind of skirts the question, and I would prefer to be clear: 
we are standardizing new behavior for IKEv2, not for IKEv1.
- 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.
- 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.
- 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.


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec