RE: [Ipsec] big IKE packets
"Yoav Nir" <ynir@checkpoint.com> Wed, 01 September 2004 13:51 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12939 for <ipsec-archive@lists.ietf.org>; Wed, 1 Sep 2004 09:51:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2PFF-0008Hv-UT; Wed, 01 Sep 2004 03:09:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2PAH-0007HQ-IC for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 03:04:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13279 for <ipsec@ietf.org>; Wed, 1 Sep 2004 03:04:16 -0400 (EDT)
Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2PCP-0002Mc-UI for ipsec@ietf.org; Wed, 01 Sep 2004 03:06:30 -0400
Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i81706d23874 for <ipsec@lists.tislabs.com>; Wed, 1 Sep 2004 03:00:06 -0400 (EDT)
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8171JD3007534 for <ipsec@lists.tislabs.com>; Wed, 1 Sep 2004 03:01:19 -0400 (EDT)
Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAATvaaRo; Wed, 1 Sep 04 03:01:11 -0400
Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i81742W14027; Wed, 1 Sep 2004 10:04:02 +0300 (IDT)
Message-Id: <200409010704.i81742W14027@michael.checkpoint.com>
From: Yoav Nir <ynir@checkpoint.com>
To: 'Michael Richardson' <mcr@sandelman.ottawa.on.ca>, 'Paul Hoffman / VPNC' <paul.hoffman@vpnc.org>
Subject: RE: [Ipsec] big IKE packets
Date: Wed, 01 Sep 2004 10:03:56 +0300
Organization: Check Point
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-index: AcSPuexWQI0qcq08TU2bFGcKcsNcxgAM9PSA
In-Reply-To: <27208.1093996792@marajade.sandelman.ottawa.on.ca>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.com
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Content-Transfer-Encoding: 7bit
OK. Yes, solving the cert too-big-for-MTU is important. I don't know how representative it is of others' experience, but I can tell you about my company's experience with IKEv1. In general, enterprise gateways have no problems talking to one another using large UDP packets. The routers allow this, although my experience may be tainted by working only with modern gateways. The place where cert-too-big is a problem is for the case of a home user or small office behind a broadband modem. These things do drop UDP fragments, and in many cases they prevent phase 1 from completing. I'm just not sure Suren's idea is the best way to solve this. What my company did was to allow IKE to pass over TCP (we used port 500). This has some advantages, and some disadvantages. I'll list them, as far as we've learned: Advantages: 1. Takes care of long messages and retransmissions. 2. Since an IKE message has a length field, requires virtually no change in the protocol. Disadvantages: 1. Like all TCP ports, this is a potential for DOS attacks that needs to be mitigated. 2. When the evil, fragment-dropping router is also a NAT device (nearly always) you cannot open a TCP connection from the responder back to the initiator, so you need to have a separate phase2 (or CCSA in IKEv2) exchange running with UDP after the original exchange so as to map the ports. Certs are not the only source for messages. In IKEv1 there were also large proposals. In IKEv2 there could be EAP methods, large traffic selectors, etc. Things like hash-and-URL solve one problem, but I think IKE over TCP is a better solution. Like any proposal, I guess this too falls into the too-late-for-IKEv2 category, but it still could be submitted as a private draft. -----Original Message----- From: Michael Richardson Subject: Re: [Ipsec] big IKE packets >>>>> "VPNC" == VPNC <Paul> writes: VPNC> It would be a lot easier for those of us who think "let's not VPNC> re-invent TCP in IKEv2" to know what you are talking about if VPNC> we had an Internet Draft will your full proposal for the VPNC> fragment handling. Without that, we'll just keep saying "it's VPNC> too hard, and it's not important enough" and you'll keep VPNC> saying "it really isn't, and it is important". Remember, that I'm the guy who thinks that one of the reasons that certificates shouldn't be exchanged in-band is because of problems like this :-) I do, however, hate PSK, and want it to go away, so if solving this problem makes progress, then I'm willing to help. I twigged on this after reading parts of the last month of the pki4ipsec list, and started to think about it in the shower or something. I would be happy to write a document --- but others need to say, "yes, solving the cert too-big-for-MTU is important". _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec
- [Ipsec] big IKE packets Michael Richardson
- [Ipsec] HASH and URL suren
- Re: [Ipsec] big IKE packets Paul Koning
- Re: [Ipsec] big IKE packets Michael Richardson
- Re: [Ipsec] big IKE packets Paul Koning
- Re: [Ipsec] big IKE packets Dan McDonald
- Re: [Ipsec] big IKE packets Michael Richardson
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Michael Richardson
- Re: [Ipsec] big IKE packets Paul Hoffman / VPNC
- Re: [Ipsec] big IKE packets Michael Richardson
- RE: [Ipsec] big IKE packets Yoav Nir
- RE: [Ipsec] big IKE packets Yoav Nir
- [Ipsec] big IKE packets Tero Kivinen
- Re: [Ipsec] big IKE packets Francis Dupont
- RE: [Ipsec] big IKE packets Paul Koning
- Re: [Ipsec] big IKE packets Yoav Nir
- Re: [Ipsec] big IKE packets Paul Koning
- [Ipsec] Re: [Pki4ipsec] HASH and URL Michael Richardson
- Re: [Ipsec] big IKE packets Michael Richardson
- Re: [Ipsec] big IKE packets Francis Dupont
- RE: [Ipsec] big IKE packets Yoav Nir
- Re: [Ipsec] big IKE packets Tero Kivinen
- [Ipsec] Re: [Pki4ipsec] HASH and URL Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Ipsec] HASH and URL M.Chenna kesava Reddy
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Yoav Nir
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Yoav Nir
- RE: [Pki4ipsec] Re: [Ipsec] big IKE packets Paul Koning
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- RE: [Pki4ipsec] Re: [Ipsec] big IKE packets Yoav Nir
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Tero Kivinen
- Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Nicolas Williams
- Re: [Pki4ipsec] RE: [Ipsec] big IKE packets Paul Wouters
- [Ipsec] Re: [Pki4ipsec] HASH and URL ravivsn