From mailman-bounces@ietf.org Wed Sep 1 09:51:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12915 for ; Wed, 1 Sep 2004 09:51:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2R7k-0002hI-OU for ipsec-archive@lists.ietf.org; Wed, 01 Sep 2004 05:09:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:02:23 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From ipsec-bounces@ietf.org Wed Sep 1 10:36:49 2004 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 ; 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 ; 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 ; 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 ; 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" To: "'Michael Richardson'" , "'Paul Hoffman / VPNC'" Subject: RE: [Ipsec] big IKE packets Date: Wed, 1 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 From ipsec-bounces@ietf.org Wed Sep 1 12:32:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05561 for ; Wed, 1 Sep 2004 12:32:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMa-0005mG-HL; Wed, 01 Sep 2004 11:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VFv-0004Ag-PJ for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:34:31 -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 JAA06366 for ; Wed, 1 Sep 2004 09:34:28 -0400 (EDT) From: housley@vigilsec.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2U4i-0002s6-SE for ipsec@ietf.org; Wed, 01 Sep 2004 08:18:54 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i81CCAd02276 for ; Wed, 1 Sep 2004 08:12:10 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81CDPMF026341 for ; Wed, 1 Sep 2004 08:13:25 -0400 (EDT) Message-Id: <200409011213.i81CDPMF026341@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMtaqCZ; Wed, 1 Sep 04 08:13:22 -0400 To: ipsec@lists.tislabs.com Date: Wed, 1 Sep 2004 09:16:50 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 1 X-MSMail-Priority: High X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ipsec] Server Error (ipsec@lists.tislabs.com) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id i81CCAd02276 Content-Transfer-Encoding: quoted-printable Mail Delivery Error - This mail contains unicode characters ------------- failed message ------------- dd~:U$h;*oc&=F6(*>SAI9uCb%zG7ZIo*xu=F6mVSdlpcMGi: jl1WlQKhrL3~1t->=DF0tt&d|Hju:FX9y%yY7&FXlo,)O rUq8;Gxbf'Qzbdh+ZpHD|#xiO>U>VcU=F6M;'QQm=DF(,<.g =E4=F6|i$6>w3BEXk=FCi'zUnAEE Modified message has been sent as a binary attachment. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="msg3515.pif.htm" Content-Disposition: attachment; filename="msg3515.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: msg3515.pif
Virus name: W32/Netsky.q@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Wed Sep 1 12:34:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05841 for ; Wed, 1 Sep 2004 12:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMe-0005qp-Qb; Wed, 01 Sep 2004 11:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VGX-0004Iv-Ap for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:35:09 -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 JAA06882 for ; Wed, 1 Sep 2004 09:35:05 -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 1C2Ta3-0003hb-AE for ipsec@ietf.org; Wed, 01 Sep 2004 07:47:12 -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 i81Bedd27633 for ; Wed, 1 Sep 2004 07:40:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81Bfttw020506 for ; Wed, 1 Sep 2004 07:41:55 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzvaG8N; Wed, 1 Sep 04 07:41:46 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i81BiY014616; Wed, 1 Sep 2004 14:44:34 +0300 (IDT) Message-Id: <200409011144.i81BiY014616@michael.checkpoint.com> From: "Yoav Nir" To: "'Michael Richardson'" Subject: RE: [Ipsec] big IKE packets Date: Wed, 1 Sep 2004 14:44:29 +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: AcSPuexWQI0qcq08TU2bFGcKcsNcxgAM9PSAAArIxCA= X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Oops, sorry. I meant Michael's idea. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Wednesday, September 01, 2004 10:04 AM To: 'Michael Richardson'; 'Paul Hoffman / VPNC' Cc: 'ipsec@lists.tislabs.com'; 'pki4ipsec@honor.icsalabs.com' Subject: RE: [Ipsec] big IKE packets 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. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 12:39:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06496 for ; Wed, 1 Sep 2004 12:39:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMq-000606-40; Wed, 01 Sep 2004 11:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VHq-0004hR-1c for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:36:31 -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 JAA07940 for ; Wed, 1 Sep 2004 09:36:25 -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 1C2Sbl-00045i-WD for ipsec@ietf.org; Wed, 01 Sep 2004 06:44:55 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i81AcQd18873 for ; Wed, 1 Sep 2004 06:38:26 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81Adgo4010382 for ; Wed, 1 Sep 2004 06:39:42 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKpaOqu; Wed, 1 Sep 04 06:39:38 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i81AgJMV004605 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Sep 2004 13:42:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i81AgFh4004602; Wed, 1 Sep 2004 13:42:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16693.42887.488474.795227@fireball.kivinen.iki.fi> Date: Wed, 1 Sep 2004 13:42:15 +0300 From: Tero Kivinen To: "Bob Doud" Subject: RE: [Ipsec] big IKE packets In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Dan McDonald , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Bob Doud writes: > Keep in mind that Linux implemenations send out the last ^ Old > fragment first, so you're going to see a lot of that. We're > not going to hold our breath waiting for that to be changed! No need to hold your breath anymore, I think it has been fixed at least in 2.6 already. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 12:40:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06705 for ; Wed, 1 Sep 2004 12:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMu-00065a-Hi; Wed, 01 Sep 2004 11:49:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VI1-0004nd-8h for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:36:43 -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 JAA08078 for ; Wed, 1 Sep 2004 09:36:36 -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 1C2SRy-0008Kb-Bl for ipsec@ietf.org; Wed, 01 Sep 2004 06:34:47 -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 i81ASJd17574 for ; Wed, 1 Sep 2004 06:28:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81ATYBJ008880 for ; Wed, 1 Sep 2004 06:29:34 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPOaGur; Wed, 1 Sep 04 06:29:29 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i81AVIu19463; Wed, 1 Sep 2004 13:31:18 +0300 (IDT) Message-Id: <200409011031.i81AVIu19463@michael.checkpoint.com> From: "Yoav Nir" To: Subject: RE: [Ipsec] big IKE packets Date: Wed, 1 Sep 2004 13:31:13 +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: AcSQCuzKGwEj370TTwigq8QNtCgBlgAA6lDw In-Reply-To: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, "'Michael Richardson'" , "'Paul Hoffman / VPNC'" , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Those stupid DSL routers know (sort-of) how to deal with TCP. They can live with UDP (as long as it does not need fragmentation). They usually drop ICMP, ESP and AH. I wouldn't trust them to pass SCTP. -----Original Message----- From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Wednesday, September 01, 2004 1:02 PM To: Yoav Nir Cc: 'Michael Richardson'; 'Paul Hoffman / VPNC'; ipsec@lists.tislabs.com; pki4ipsec@honor.icsalabs.com Subject: Re: [Ipsec] big IKE packets In your previous mail you wrote: 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. => if we agree to change UDP for a better protocol, IMHO SCTP is the best candidate (BTW it was designed for signaling, and IKE is a signaling protocol). Regards Francis.Dupont@enst-bretagne.fr PS: interaction of IKE over SCTP and MOBIKE should give some fun! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 12:41:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07021 for ; Wed, 1 Sep 2004 12:41:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMw-000686-My; Wed, 01 Sep 2004 11:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VIC-0004u7-Fx for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:36:54 -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 JAA08248 for ; Wed, 1 Sep 2004 09:36:49 -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 1C2SGk-0004Ho-6h for ipsec@ietf.org; Wed, 01 Sep 2004 06:23:11 -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 i81AGhd15835 for ; Wed, 1 Sep 2004 06:16:44 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81AHxbX006962 for ; Wed, 1 Sep 2004 06:17:59 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAnaqJn; Wed, 1 Sep 04 06:17:55 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i81AKVPw004347 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Sep 2004 13:20:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i81AKVLY004344; Wed, 1 Sep 2004 13:20:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16693.41583.171737.473529@fireball.kivinen.iki.fi> Date: Wed, 1 Sep 2004 13:20:31 +0300 From: Tero Kivinen To: Michael Richardson Subject: [Ipsec] big IKE packets In-Reply-To: <14803.1093977688@marajade.sandelman.ottawa.on.ca> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson writes: > I wonder if one solution to the problem of large IKE packets > (that require fragmentation) wouldn't be to define a fragmentation > header in IKE. There is also such method, it is called IP. The IP packets already offers fragmentation, why should we do it again on the IKE level? If the operating system vendor who implemented IP stack didn't know how to make the fragmentation, how can you expect him to be able to make IKE fragmentation to the IPsec stack of the OS? The only difference would be the separate acks for fragments, but I do not think this fragmentation in IKE would really help, as it just adds one more complicated option, and I think people would be leaving the implementation of it out from their products. The HTTP transfer of certificates is much better sulution for that. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 12:43:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07282 for ; Wed, 1 Sep 2004 12:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMz-0006At-IA; Wed, 01 Sep 2004 11:49:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VIV-00053J-9I for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 09:37:11 -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 JAA08449 for ; Wed, 1 Sep 2004 09:37:05 -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 1C2Rz7-0006yK-IF for ipsec@ietf.org; Wed, 01 Sep 2004 06:04:59 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i819wGd13374 for ; Wed, 1 Sep 2004 05:58:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i819xRfc004090 for ; Wed, 1 Sep 2004 05:59:27 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr(192.44.77.17) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT8aG9h; Wed, 1 Sep 04 05:59:24 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i81A1hE18139; Wed, 1 Sep 2004 12:01:43 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i81A1gSj053026; Wed, 1 Sep 2004 12:01:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Yoav Nir" Subject: Re: [Ipsec] big IKE packets In-reply-to: Your message of Wed, 01 Sep 2004 10:03:56 +0300. <200409010704.i81742W14027@michael.checkpoint.com> Date: Wed, 01 Sep 2004 12:01:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipsec@lists.tislabs.com, "'Michael Richardson'" , "'Paul Hoffman / VPNC'" , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: 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. => if we agree to change UDP for a better protocol, IMHO SCTP is the best candidate (BTW it was designed for signaling, and IKE is a signaling protocol). Regards Francis.Dupont@enst-bretagne.fr PS: interaction of IKE over SCTP and MOBIKE should give some fun! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 14:11:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17250 for ; Wed, 1 Sep 2004 14:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZH6-0005TM-5E; Wed, 01 Sep 2004 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2YKk-0000op-I4 for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 12:51:42 -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 MAA09198 for ; Wed, 1 Sep 2004 12:51:39 -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 1C2YMx-0004NK-0l for ipsec@ietf.org; Wed, 01 Sep 2004 12:54:00 -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 i81GlNd24968 for ; Wed, 1 Sep 2004 12:47:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81GmeXP004354 for ; Wed, 1 Sep 2004 12:48:40 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_paWFi; Wed, 1 Sep 04 12:48:37 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i81GpVFp031819 for ; Wed, 1 Sep 2004 12:51:31 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i81GpUsw031814; Wed, 1 Sep 2004 12:51:30 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 12:51:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16693.65040.525143.196105@gargle.gargle.HOWL> Date: Wed, 1 Sep 2004 12:51:28 -0400 From: Paul Koning To: ynir@checkpoint.com Subject: RE: [Ipsec] big IKE packets References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 01 Sep 2004 16:51:30.0754 (UTC) FILETIME=[EE3F2220:01C49043] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Yoav" == Yoav Nir writes: Yoav> Those stupid DSL routers know (sort-of) how to deal with TCP. Yoav> They can live with UDP (as long as it does not need Yoav> fragmentation). They usually drop ICMP, ESP and AH. I Yoav> wouldn't trust them to pass SCTP. To what extent should we pessimize the protocol design to work around defective network equipment? paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 16:25:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28943 for ; Wed, 1 Sep 2004 16:25:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2b9E-0002rC-79; Wed, 01 Sep 2004 15:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2b1b-0002TA-RC for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 15:44:07 -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 PAA25861 for ; Wed, 1 Sep 2004 15:44:05 -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 1C2b3p-0001lQ-NQ for ipsec@ietf.org; Wed, 01 Sep 2004 15:46:27 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i81Jdrd05623 for ; Wed, 1 Sep 2004 15:39:53 -0400 (EDT) Received: from [172.31.21.3] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i81Jhp600670; Wed, 1 Sep 2004 22:43:51 +0300 (IDT) In-Reply-To: <16693.65040.525143.196105@gargle.gargle.HOWL> References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> <16693.65040.525143.196105@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4728C348-FC4F-11D8-97AA-000393AD410A@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] big IKE packets Date: Wed, 1 Sep 2004 22:44:03 +0300 To: Paul Koning X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit To quite a large extent. If that equipment worked correctly, it would be able to work with fragments, and we could do with UDP and ESP, no need for NAT-T. As it is, TCP is supported by all equipment, and is implemented in every operating system. Who uses SCTP? On 01/09/2004, at 19:51, Paul Koning wrote: > > To what extent should we pessimize the protocol design to work around > defective network equipment? > > paul > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 18:04:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09254 for ; Wed, 1 Sep 2004 18:04:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2cbO-0006G2-Pp; Wed, 01 Sep 2004 17:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2c8A-0006KO-TN for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 16:54:59 -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 QAA00834 for ; Wed, 1 Sep 2004 16:54:55 -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 1C2cAP-0007jY-Cm for ipsec@ietf.org; Wed, 01 Sep 2004 16:57:18 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i81Kogd11465 for ; Wed, 1 Sep 2004 16:50:44 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81KptgL005649 for ; Wed, 1 Sep 2004 16:51:55 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFzaaal; Wed, 1 Sep 04 16:51:52 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i81KsjFp018039 for ; Wed, 1 Sep 2004 16:54:45 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i81Ksisw018034; Wed, 1 Sep 2004 16:54:44 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 16:54:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16694.14098.898026.4193@gargle.gargle.HOWL> Date: Wed, 1 Sep 2004 16:54:42 -0400 From: Paul Koning To: ynir@checkpoint.com Subject: Re: [Ipsec] big IKE packets References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> <16693.65040.525143.196105@gargle.gargle.HOWL> <4728C348-FC4F-11D8-97AA-000393AD410A@checkpoint.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 01 Sep 2004 20:54:44.0612 (UTC) FILETIME=[E8DD2440:01C49065] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Yoav" == Yoav Nir writes: Yoav> To quite a large extent. If that equipment worked correctly, Yoav> it would be able to work with fragments, and we could do with Yoav> UDP and ESP, no need for NAT-T. Yoav> As it is, TCP is supported by all equipment, and is implemented Yoav> in every operating system. Who uses SCTP? Not many people use SCTP. But it is an IETF standard. It has been suggested as a suitable protocol. If we decide not to use it for technical reasons, that's fine. But I don't think "we can't use good protocol X because there are crummy network equipment vendors who mess up that protocol" is a good policy. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 18:30:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12696 for ; Wed, 1 Sep 2004 18:30:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2dXX-0000sL-7r; Wed, 01 Sep 2004 18:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2dK9-0002Mi-Np for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 18:11:25 -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 SAA10544 for ; Wed, 1 Sep 2004 18:11:22 -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 1C2dMP-0006va-3t for ipsec@ietf.org; Wed, 01 Sep 2004 18:13:46 -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 i81M7Bd14365 for ; Wed, 1 Sep 2004 18:07:12 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81M8N5n014836 for ; Wed, 1 Sep 2004 18:08:23 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAL0aG8C; Wed, 1 Sep 04 18:08:21 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81MAtt05603 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 1 Sep 2004 18:11:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81MHDc02461 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 1 Sep 2004 18:17:15 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81JaAOw023940; Wed, 1 Sep 2004 15:36:10 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81JaA87023937; Wed, 1 Sep 2004 15:36:10 -0400 To: pki4ipsec@honor.icsalabs.com, ipsec@lists.tislabs.com In-Reply-To: Message from suren of "01 Sep 2004 11:54:50 PDT." <1094064890.2123.71.camel@suren> References: <1094064890.2123.71.camel@suren> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Sep 2004 15:36:10 -0400 Message-ID: <23936.1094067370@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] Re: [Pki4ipsec] HASH and URL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "suren" == suren writes: suren> Hi, As I understand, the IKE node can send Hash of public key suren> of its certificate and URL (including port number) from which suren> the peer can retrieve its certificate. I guess, it is to suren> ensure that there is no fragmentation on IKE packets as some suren> routers might not honor fragmentation. suren> I see that there would be firewall related issues in suren> this. Since, the IKE needs to make a new connection (HTTP suren> connection) to the URI given in Cert payload, any firewalls suren> in between should have a policy (ACL) to allow this HTTP suren> connection. Worse, given NAT/firewall, you can't tell the peer to "get it from http://me:1234/mycert.pem" It would be best if we had an option in the CERT REQ which told the peer to please do an HTTP POST to some URL. A responder would then be in a position to know if it can provide for this service or not. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQTYkpoqHRg3pndX9AQGLVwP/TvRnsCZ8rkQ9Q+bKv89iRtoHIGBnbIfU SyfJCc3hNDCu9UK4113TGDB1VwieGK4z8jrBL+z7CDEhJrFv4YQdCHeOlNajRC7Y q0b/igy60RpOEALfaoPN+OYJoSdTXAg92ibg8mEXV9G7CdJFNjW23XrdGlXPXrWX qCSf0mcZfOw= =w7NJ -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 18:54:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14218 for ; Wed, 1 Sep 2004 18:54:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2dXY-0000sR-0Y; Wed, 01 Sep 2004 18:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2dKE-0002Rx-6M for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 18:11:30 -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 SAA10548 for ; Wed, 1 Sep 2004 18:11:26 -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 1C2dMU-0006vf-Ny for ipsec@ietf.org; Wed, 01 Sep 2004 18:13:51 -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 i81M7Ed14374 for ; Wed, 1 Sep 2004 18:07:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81M8UJk014848 for ; Wed, 1 Sep 2004 18:08:30 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxAa4_C; Wed, 1 Sep 04 18:08:27 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81MAtr05603 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 1 Sep 2004 18:11:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81MHDo02461 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 1 Sep 2004 18:17:17 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81IWsjl022675; Wed, 1 Sep 2004 14:32:54 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81IWrQe022672; Wed, 1 Sep 2004 14:32:53 -0400 To: ipsec@lists.tislabs.com Subject: Re: [Ipsec] big IKE packets In-Reply-To: Message from "Yoav Nir" of "Wed, 01 Sep 2004 14:44:29 +0300." <200409011144.i81BiY014616@michael.checkpoint.com> References: <200409011144.i81BiY014616@michael.checkpoint.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Sep 2004 14:32:53 -0400 Message-ID: <22670.1094063573@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoav" == Yoav Nir writes: Yoav> Oops, sorry. I meant Michael's idea. So, I'm not attached to it. Running over TCP is certainly an option --- but as you indicate it means switching somehow to UDP if you need to do NAT-T. That's why I suggested a mechanism that lives entirely within IKE, and that permits IKE to verify that each fragment arrived independantly. I believe that we will see some increase in host<->host IPsec to secure long-lived TCP connections against attacks. I would hate to introduce an unprotected, long-lived TCP connection. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQTYVz4qHRg3pndX9AQGqhQP+MqOQxic0YFJjDtR7chrclD8g6GhuQ68B rK2Kt+4JGsCrdfeOnb2KacUv9jV6TFCR42NlLlU1G8wCUQFRXNeBslU9wI47n8WC 986tghICETeeaE+xJzQf0Xg2U1FqKyz6G/B1p3ll7wNt0gD/IjTi/m+24STJ86NP TqxKnEuFr6s= =anmc -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 1 19:24:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16261 for ; Wed, 1 Sep 2004 19:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2eCt-0007YD-Lb; Wed, 01 Sep 2004 19:07:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2dl8-0005dr-R0 for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 18:39: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 SAA13421 for ; Wed, 1 Sep 2004 18:39:15 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2dnQ-0000w7-8N for ipsec@ietf.org; Wed, 01 Sep 2004 18:41:40 -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 i81MZ6d15370 for ; Wed, 1 Sep 2004 18:35:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81MaMVn017740 for ; Wed, 1 Sep 2004 18:36:22 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVzayMI; Wed, 1 Sep 04 18:36:14 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81Md6d05866 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 1 Sep 2004 18:39:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i81MifY03124 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 1 Sep 2004 18:44:43 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81Mb8jY003651; Wed, 1 Sep 2004 18:37:08 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i81Mb6kT003643; Wed, 1 Sep 2004 18:37:08 -0400 To: Paul Koning Subject: Re: [Ipsec] big IKE packets In-Reply-To: Message from Paul Koning of "Wed, 01 Sep 2004 16:54:42 EDT." <16694.14098.898026.4193@gargle.gargle.HOWL> References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> <16693.65040.525143.196105@gargle.gargle.HOWL> <4728C348-FC4F-11D8-97AA-000393AD410A@checkpoint.com> <16694.14098.898026.4193@gargle.gargle.HOWL> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Sep 2004 18:37:05 -0400 Message-ID: <3641.1094078225@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ipsec@lists.tislabs.com, ynir@checkpoint.com, pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: >>>>> "Yoav" == Yoav Nir writes: Yoav> To quite a large extent. If that equipment worked correctly, Yoav> it would be able to work with fragments, and we could do with Yoav> UDP and ESP, no need for NAT-T. Yoav> As it is, TCP is supported by all equipment, and is Yoav> implemented in every operating system. Who uses SCTP? Paul> Not many people use SCTP. But it is an IETF standard. It has Paul> been suggested as a suitable protocol. If we decide not to Paul> use it for technical reasons, that's fine. But I don't think Paul> "we can't use good protocol X because there are crummy network Paul> equipment vendors who mess up that protocol" is a good policy. Should we define a standard way to do IKE over SCTP? Yes. Does it solve the problem at hand? Unfortunately not. Let me state the problem again: Statement 1: IKE (v1 and v2) can create UDP datagrams which are larger than the MTU. Statement 2: IP permits these datagrams to be fragmented by the sender, such that the receiver can assemble them. Statement 3: there exist faulty network devices which attempt to filter based upon port numbers, and fail when the datagrams are fragmented. Assumptions/Notes Statement 1 a) If the only source of large IKE packets is certificates, then there are other mechanisms for exchanging certificates. They include HTTP, LDAP, possibly HTTP POST from the "road warrior" to the gateway, etc. I.e. we don't need to solve this problem in IKE. b) There are are other reasons why IKE datagrams can be large. One reason in IKEv1 is proposals. Postulate: IKEv2 mitigates this to the point where it doesn't matter. Statement 2 a) A gateway may wish to never have to assemble fragments for port-500 to avoid fragment attacks. Statement 3 a) The broken equipment can not be replaced. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQTZPEIqHRg3pndX9AQHwhwP/bETMfs3jZY/kf/6xhs+O/xYbEBE8T6mf QxvQCFRcXnFk1jSFA5h/OMw0J6B/sBvy48/TjPJ+RyCrb7vkBlIuggRcmkbZVxeO w3z8mG8J/4AXD7v35odme0zoxNR0YjHbLw3uWw3qTpml3zOt7mxLEVglcJkaTcH3 QOeJUVL2cuQ= =Cvwg -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 01:34:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19620 for ; Thu, 2 Sep 2004 01:34:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2k9G-0008Dr-VJ; Thu, 02 Sep 2004 01:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2k2g-0005pc-0c for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 01:21:50 -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 BAA19043 for ; Thu, 2 Sep 2004 01:21:49 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2k4z-000724-Gn for ipsec@ietf.org; Thu, 02 Sep 2004 01:24:15 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i825Had08934 for ; Thu, 2 Sep 2004 01:17:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i825Iof1008251 for ; Thu, 2 Sep 2004 01:18:50 -0400 (EDT) Received: from unknown(202.125.80.82) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9xaGbq; Thu, 2 Sep 04 01:18:44 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA00959; Thu, 2 Sep 2004 11:21:23 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA00952; Thu, 2 Sep 2004 11:21:16 +0530 Message-ID: <4136ADBB.4080003@rocsys.com> Date: Thu, 02 Sep 2004 10:50:59 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Subject: Re:[Ipsec] big IKE packets X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Is the certificate only issue in fragmentation? Based on my quick read of IKEv2 specification, there are some scenarios, where the packet size can be more than the PMTU value of the path. If there are multiple networks behind gateways and with different services, the TS payload itself can become bigger. I did not in the document that, the payload size should be limited to 'N' number of Traffic Selectors. I feel that, we need to solve the problem completely, rather than fixing the problem only for certificates. Some how, I think that running IKE over TCP would be good as TCP internally takes care of adjusting its MSS based on PMTU values. Ravi ----- Original Message ----- From: "Tero Kivinen" To: "Michael Richardson" Cc: ; Sent: Wednesday, September 01, 2004 3:20 AM Subject: [Ipsec] big IKE packets > Michael Richardson writes: > > I wonder if one solution to the problem of large IKE packets > > (that require fragmentation) wouldn't be to define a fragmentation > > header in IKE. > > There is also such method, it is called IP. The IP packets already > offers fragmentation, why should we do it again on the IKE level? > > If the operating system vendor who implemented IP stack didn't know > how to make the fragmentation, how can you expect him to be able to > make IKE fragmentation to the IPsec stack of the OS? > > The only difference would be the separate acks for fragments, but I do > not think this fragmentation in IKE would really help, as it just adds > one more complicated option, and I think people would be leaving the > implementation of it out from their products. > > The HTTP transfer of certificates is much better sulution for that. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 05:09:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14422 for ; Thu, 2 Sep 2004 05:09:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2nN7-0005Sg-7D; Thu, 02 Sep 2004 04:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2n6c-00084W-9W for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 04:38:07 -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 EAA12480 for ; Thu, 2 Sep 2004 04:38:04 -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 1C2n8w-0004zu-Fs for ipsec@ietf.org; Thu, 02 Sep 2004 04:40:32 -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 i828Xld28936 for ; Thu, 2 Sep 2004 04:33:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i828Z38p011018 for ; Thu, 2 Sep 2004 04:35:03 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr(192.44.77.17) by nutshell.tislabs.com via csmap (V6.0) id srcAAAk_aaGv; Thu, 2 Sep 04 04:34:59 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i828bA824180; Thu, 2 Sep 2004 10:37:10 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i828b8Sj056831; Thu, 2 Sep 2004 10:37:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409020837.i828b8Sj056831@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Yoav Nir" Subject: Re: [Ipsec] big IKE packets In-reply-to: Your message of Wed, 01 Sep 2004 13:31:13 +0300. <200409011031.i81AVIu19463@michael.checkpoint.com> Date: Thu, 02 Sep 2004 10:37:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@lists.tislabs.com, "'Michael Richardson'" , "'Paul Hoffman / VPNC'" , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: Those stupid DSL routers know (sort-of) how to deal with TCP. They can live with UDP (as long as it does not need fragmentation). They usually drop ICMP, ESP and AH. I wouldn't trust them to pass SCTP. => if I understand you well, you argue for IKE over HTTP (:-)? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 05:29:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15834 for ; Thu, 2 Sep 2004 05:29:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2nfn-000880-LC; Thu, 02 Sep 2004 05:14:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ncf-0005lS-0X for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 05:11:13 -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 FAA14626 for ; Thu, 2 Sep 2004 05:11:11 -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 1C2nf0-0007eL-NT for ipsec@ietf.org; Thu, 02 Sep 2004 05:13:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8296vd01746 for ; Thu, 2 Sep 2004 05:06:57 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8298FOx016073 for ; Thu, 2 Sep 2004 05:08:15 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6UaGyF; Thu, 2 Sep 04 05:08:12 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i829AYY00231; Thu, 2 Sep 2004 12:10:34 +0300 (IDT) Message-Id: <200409020910.i829AYY00231@michael.checkpoint.com> From: "Yoav Nir" To: Subject: RE: [Ipsec] big IKE packets Date: Thu, 2 Sep 2004 12:10:28 +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: AcSQyCpBjn/wbZmuS7iuGg51my13UQABCL+g In-Reply-To: <200409020837.i828b8Sj056831@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, "'Michael Richardson'" , "'Paul Hoffman / VPNC'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Perish the thought. Then some smart firewall will drop your IKE because it does not look like HTTP, so it's either a worm or file-sharing. Better use HTTPS. Nobody understands SSL :-) -----Original Message----- From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Thursday, September 02, 2004 11:37 AM To: Yoav Nir Cc: ipsec@lists.tislabs.com; 'Michael Richardson'; 'Paul Hoffman / VPNC'; pki4ipsec@honor.icsalabs.com Subject: Re: [Ipsec] big IKE packets In your previous mail you wrote: Those stupid DSL routers know (sort-of) how to deal with TCP. They can live with UDP (as long as it does not need fragmentation). They usually drop ICMP, ESP and AH. I wouldn't trust them to pass SCTP. => if I understand you well, you argue for IKE over HTTP (:-)? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 08:24:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27533 for ; Thu, 2 Sep 2004 08:24:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qPA-0005yf-Ar; Thu, 02 Sep 2004 08:09:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qK1-0003L8-8T for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 08:04:09 -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 IAA25754 for ; Thu, 2 Sep 2004 08:04:08 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2qMO-000537-EP for ipsec@ietf.org; Thu, 02 Sep 2004 08:06:37 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i82Bxsd26300 for ; Thu, 2 Sep 2004 07:59:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i82C1AUm011371 for ; Thu, 2 Sep 2004 08:01:10 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAysaamw; Thu, 2 Sep 04 08:01:06 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i82C3eZt019986 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 15:03:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i82C3ZMd019983; Thu, 2 Sep 2004 15:03:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.3095.811663.265071@fireball.kivinen.iki.fi> Date: Thu, 2 Sep 2004 15:03:35 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] big IKE packets In-Reply-To: <4728C348-FC4F-11D8-97AA-000393AD410A@checkpoint.com> References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> <16693.65040.525143.196105@gargle.gargle.HOWL> <4728C348-FC4F-11D8-97AA-000393AD410A@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > To quite a large extent. If that equipment worked correctly, it would > be able to work with fragments, and we could do with UDP and ESP, no > need for NAT-T. Not really. ESP cannot never go through the NATs without the NAT's doing some guesswork, or without the IPsec to telling the NAT the SPI mapping it is using. I.e. NAT will not know which inbound SPI matches what outbound SPI, and it cannot forward packets to the correct recipient. NAT-T does this by giving the information to the NAT boxes in the form of UDP port numbers. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 08:38:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28592 for ; Thu, 2 Sep 2004 08:38:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qff-0005Ho-AX; Thu, 02 Sep 2004 08:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qQQ-0006Si-VQ for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 08:10:47 -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 IAA26420 for ; Thu, 2 Sep 2004 08:10:46 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2qSm-0005co-8p for ipsec@ietf.org; Thu, 02 Sep 2004 08:13:15 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i82C6Ud27446 for ; Thu, 2 Sep 2004 08:06:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i82C7lEf012509 for ; Thu, 2 Sep 2004 08:07:47 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1CaiBy; Thu, 2 Sep 04 08:07:44 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i82CAXv9020017 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 15:10:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i82CAWsO020014; Thu, 2 Sep 2004 15:10:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.3512.570183.498619@fireball.kivinen.iki.fi> Date: Thu, 2 Sep 2004 15:10:32 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <23936.1094067370@marajade.sandelman.ottawa.on.ca> References: <1094064890.2123.71.camel@suren> <23936.1094067370@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.com Subject: [Ipsec] Re: [Pki4ipsec] HASH and URL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson writes: > Worse, given NAT/firewall, you can't tell the peer to "get it from > http://me:1234/mycert.pem" But you can normally say "get it from my home-www server http://www.my-home.net/username/mycert.cer". For VPN style usage, that is quite right, and you quite often assume that http over port 80 will work through the firewalls/nat, especially when there is nothing special going on (meaning proxies etc can work properly with the url). > It would be best if we had an option in the CERT REQ which told the > peer to please do an HTTP POST to some URL. > A responder would then be in a position to know if it can provide for > this service or not. That would work for the one way, but would not work for the other way around. I.e. if the initiator is behind NAT, and claims that the servers certificate should be posted to url http://10.0.0.22:1234/, it would not really work... So we would need keep the normal get also, and I think we can most likely organize things so that there will be some place you can connect to get the certificate, and if not, then send it inband... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 08:40:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28875 for ; Thu, 2 Sep 2004 08:40:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qpp-0002SJ-VF; Thu, 02 Sep 2004 08:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qYU-0002ZS-4B for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 08:19:06 -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 IAA27066 for ; Thu, 2 Sep 2004 08:19:05 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2qao-0006L0-HD for ipsec@ietf.org; Thu, 02 Sep 2004 08:21:34 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i82CEld28854 for ; Thu, 2 Sep 2004 08:14:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i82CG40Q013846 for ; Thu, 2 Sep 2004 08:16:04 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe8aacB; Thu, 2 Sep 04 08:16:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i82CIq9P020059 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 15:18:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i82CIlkk020056; Thu, 2 Sep 2004 15:18:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.4007.280595.398507@fireball.kivinen.iki.fi> Date: Thu, 2 Sep 2004 15:18:47 +0300 From: Tero Kivinen To: Ravi Kumar Subject: [Pki4ipsec] Re:[Ipsec] big IKE packets In-Reply-To: <4136ADBB.4080003@rocsys.com> References: <4136ADBB.4080003@rocsys.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Michael Richardson X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit [Removed the pki4ipsec from the CC line, as I do not think this is pki4ipsec issue]. Ravi Kumar writes: > value of the path. If there are multiple networks behind > gateways and with different services, the TS payload itself > can become bigger. I did not in the document that, the > payload size should be limited to 'N' number of Traffic > Selectors. As responder is always allowed to limit the number of traffic selectors, it can limit them already. The initiator can also limit the number of traffic selectors as it likes. There is already text in the latest changes by Charlie which says this. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 10:09:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05333 for ; Thu, 2 Sep 2004 10:09:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2s72-00081D-1O; Thu, 02 Sep 2004 09:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2s1i-0004la-Ot for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 09:53:22 -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 JAA03893 for ; Thu, 2 Sep 2004 09:53:21 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2s48-0005ag-0H for ipsec@ietf.org; Thu, 02 Sep 2004 09:55:52 -0400 Received: (qmail 22344 invoked by uid 0); 2 Sep 2004 13:53:18 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.38.108) by woodstock.binhost.com with SMTP; 2 Sep 2004 13:53:18 -0000 Message-Id: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 02 Sep 2004 09:53:55 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: margaret@thingmagic.com, narten@us.ibm.com Subject: [Ipsec] Two IKEv2 issues from the IESG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Here are two issues from the IESG regarding IKEv2. I hope that these can be quickly resolved by the IPsec Working Group. Charlie has already agreed to quickly update the document to reflect the Working Group decision, once consensus is clear. MINIMUM PACKET SIZE Margaret Wasserman asked that the specification state the minimum packet that must be supported. The response to her request included several changes that reduce the livelihood of exceeding a minimum, but falls short of actually specifying a minimum. There is a fundamental problem when one side does not know the maximum size for a packet that can be sent to a peer. If the specification does not provide guidance, then an implementation must assume the worst case, which is 576 bytes for IPv4, including headers. If a larger packet is sent, it is often unclear what happens. Will it get silently discarded? If so, this is indistiguishable from other types of failure, like packet loss. Will an error indicate what the maximum packet size? Almost certainly not. Such support is not presently part of IKEv2, and the IESG is not asking for it to be added. Doing so can be very tricky; the IP stack may accept a different maximum packet size than the upper layer application. Arguably, one of the regrettable such defaults is in the DNS were one can only assume DNS packets of 512 bytes. We have been paying for that for years, and we had to invent EDNS0 to overcome this limitation. In summary, it really does make sense for IKEv2 to some thing like: implementations MUST be prepared to accept IKEv2 packets of size at least XXX, where XXX is something reasonably large. Leaving this unspecified will almost certain come back to haunt us down the road, and it is easy to fix at this point in time. I suggest the addition of the following text: "All IKEv2 implementations MUST be able to receive and process packets that are up to 1280 bytes long, and they SHOULD be able to receive and process packets that are up to 3000 bytes long." The numbers in this suggestion come from Tero. I support them. The rationale is simple. The minimum IPv6 MTU is 1280, thus every implementation that supports IPv6 must already support the MUST packet size. This does not impose any new requirements on IPv6 hosts. Further, Tero provides a bit of IKEv2-specific analysis. The typical IPv4 packet carrying an IKEv2 message will be: - 20 bytes of IPv4 header - 8 bytes of UDP header - 28 bytes of generic header - 4 + 16 + 12 bytes of encrypted payload overhead - 8 bytes of ID overhead + ID length of say 21 (kivinen-laptop.iki.fi) - 28 bytes of SHA-1 AUTH payload - 4 + 8 + 4 bytes of SA payload overhead plus 8 bytes per transform ID + 4 bytes for key length of AES, typically we have 2 transforms, one having the key length = 36 bytes - 2 * 24 bytes of traffic selectors This totals to 229 bytes, allowing 1051 bytes for a certificate, which is plenty for a certificate carrying a 1024-bit public key, even with a fair number of certificate extensions. A certificate carrying a 2048-bit public key with a modest number of certificate extensions can also be accommodated. A 3000 byte packet is enough for any normal certificate use. It accommodates two certificates, each carrying a 2048-bit public key with a modest number of certificate extensions ELLIPTIC CURVES I am raising the second issue. In 2002, the working group decided not to pursue elliptic curves. Hilarie made several presentation advocating them; her slides are in the minutes. However, the IPR concerns associate with elliptic curves lead the working group to classic Diffie-Hellman. Yet, two elliptic curve groups are still included in the document. This seems to contradict the working group decision. I am not suggesting any protocol changes. Therefore, the specification of elliptic curves in the future is still viable. In fact, I would like to see that happen in the future. However, the inclusion of elliptic curves in Appendix B at this time concerns me from a process perspective. I will gladly entertain suggestions for a follow-on document in this area once the base IKEv2 document is finished. I suggest the removal of the elliptic curve groups from Appendix B. I hope that these two issues can be quickly resolved. Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 11:31:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12728 for ; Thu, 2 Sep 2004 11:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2tND-0005lc-R7; Thu, 02 Sep 2004 11:19:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2t9F-0006P8-QF for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 11:05:13 -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 LAA10874 for ; Thu, 2 Sep 2004 11:05:12 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca ([205.150.200.161] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2tBe-0003Dy-Le for ipsec@ietf.org; Thu, 02 Sep 2004 11:07:44 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i82F4pj14493 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Thu, 2 Sep 2004 11:04:54 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i82FANI00807 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 2 Sep 2004 11:10:29 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i82F2nEg029381; Thu, 2 Sep 2004 11:02:49 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i82F2msl029378; Thu, 2 Sep 2004 11:02:48 -0400 To: Russ Housley Subject: Re: [Ipsec] Two IKEv2 issues from the IESG In-Reply-To: Message from Russ Housley of "Thu, 02 Sep 2004 09:53:55 EDT." <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Sep 2004 11:02:48 -0400 Message-ID: <29377.1094137368@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipsec@ietf.org, margaret@thingmagic.com, narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Russ" == Russ Housley writes: Russ> I suggest the addition of the following text: Russ> "All IKEv2 implementations MUST be able to receive and Russ> process packets that are up to 1280 bytes long, and they Russ> SHOULD be able to receive and process packets that are up to Russ> 3000 bytes long." (Sorry to be pedantic here, but I think it is important) I think that the word "packet" is wrong here. I think that you mean "datagram" -- seeing as a 3000 byte datagram would exceed common MTU, it must have been fragmented into multiple frames to have been received. The above (corrected) statement also implies to me that an IKEv2 and host must be prepared to re-assemble at least 3000 bytes bytes worth of fragment. Russ> I am not suggesting any protocol changes. Therefore, the Russ> specification of elliptic curves in the future is still Russ> viable. In fact, I would like to see that happen in the Russ> future. However, the inclusion of elliptic curves in Appendix Russ> B at this time concerns me from a process perspective. I will Russ> gladly entertain suggestions for a follow-on document in this Russ> area once the base IKEv2 document is finished. I think that the answer is that... "They were in IKEv1." Russ> I suggest the removal of the elliptic curve groups from Russ> Appendix B. I don't object. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQTc2FoqHRg3pndX9AQE6mAP/aJBX4Lvtlh+MDeSAosh3JlVyxid90k29 ZcFWdGCS+EQskZhmcDyCG8GlJFwx2qqFoc1WHEJKgagrkIgfl0meyWFjukbp5j+Q ZJ5EaECMQWAd0aVES1emNKTMYr+Kxgq0qU6Wu271XZI0v/4MGhoiD+5LVNLDLrpt SVw0ueSF9bg= =Xj1t -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 12:40:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16852 for ; Thu, 2 Sep 2004 12:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uNR-0006Xl-G8; Thu, 02 Sep 2004 12:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uJO-0003UC-Q0 for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 12:19:47 -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 MAA15568 for ; Thu, 2 Sep 2004 12:19:44 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2uLo-0000qR-AT for ipsec@ietf.org; Thu, 02 Sep 2004 12:22:17 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GJcHD000848; Thu, 2 Sep 2004 09:19:39 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> Date: Thu, 2 Sep 2004 09:19:39 -0700 To: Russ Housley , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Two IKEv2 issues from the IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: margaret@thingmagic.com, narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:53 AM -0400 9/2/04, Russ Housley wrote: >MINIMUM PACKET SIZE > >I suggest the addition of the following text: > > "All IKEv2 implementations MUST be able to receive and process > packets that are up to 1280 bytes long, and they SHOULD be able > to receive and process packets that are up to 3000 bytes long." Yes. It gives implementers a hard number to work with, and a reasonable suggested number so that lazy implementers don't say "all we should do is 1280". >ELLIPTIC CURVES > >I suggest the removal of the elliptic curve groups from Appendix B. Yes. They shouldn't be there if we don't intend to support them well, and at this point that support is not there. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 12:41:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17032 for ; Thu, 2 Sep 2004 12:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uNS-0006Zr-KV; Thu, 02 Sep 2004 12:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uLG-0004TQ-Ri for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 12:21:42 -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 MAA15653 for ; Thu, 2 Sep 2004 12:21:40 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2uNd-00013l-Bu for ipsec@ietf.org; Thu, 02 Sep 2004 12:24:13 -0400 Received: (qmail 6842 invoked by uid 0); 2 Sep 2004 16:21:28 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.117) by woodstock.binhost.com with SMTP; 2 Sep 2004 16:21:28 -0000 Message-Id: <6.1.1.1.2.20040902122036.055e4b58@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 02 Sep 2004 12:22:18 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Since Thomas is not a member of the IPsec WG mail list, this message will probably sit in the spam queue indefinitely. I think the WG should see it now. So, I am forwarding it. Russ >To: Russ Housley >cc: ipsec@ietf.org, margaret@thingmagic.com >Subject: Re: Two IKEv2 issues from the IESG >Date: Thu, 02 Sep 2004 10:01:00 -0400 >From: Thomas Narten > >Russ Housley writes: > > > I suggest the addition of the following text: > > > "All IKEv2 implementations MUST be able to receive and process > > packets that are up to 1280 bytes long, and they SHOULD be able > > to receive and process packets that are up to 3000 bytes long." > >I don't see how the SHOULD is useful. The problem is that a sender has >no way of knowing whether the other end supports the larger packet >size. So, for interoperability, it can't try a size that large. If it >does, it may well send packets into a black hole. This is a generic >issue that has come up in many other protocols. It would be nice to >send larger packets, but it turns out that there exist compliant >implementations that don't support them, so one can't count on such >packets being supported. > >Note, the key issue is what is the receiver mandated to be capable of >accepting? > >Or, is there a way for IKE to respond to such packets with an error >effectively saying "packet too big"? If so, then one could try a large >packet, and negotiate a smaller value. That also works. > >Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 12:56:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18161 for ; Thu, 2 Sep 2004 12:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uhd-0007ac-C0; Thu, 02 Sep 2004 12:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uYs-0002rh-IA for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 12:35:46 -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 MAA16461 for ; Thu, 2 Sep 2004 12:35:44 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2ubJ-0002EN-DF for ipsec@ietf.org; Thu, 02 Sep 2004 12:38:17 -0400 Received: (qmail 12265 invoked by uid 0); 2 Sep 2004 16:35:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.117) by woodstock.binhost.com with SMTP; 2 Sep 2004 16:35:45 -0000 Message-Id: <6.1.1.1.2.20040902123439.05543dc8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 02 Sep 2004 12:36:35 -0400 To: Michael Richardson From: Russ Housley Subject: Re: [Ipsec] Two IKEv2 issues from the IESG In-Reply-To: <29377.1094137368@marajade.sandelman.ottawa.on.ca> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> <29377.1094137368@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org, margaret@thingmagic.com, narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Michael: > Russ> I suggest the addition of the following text: > > Russ> "All IKEv2 implementations MUST be able to receive and > Russ> process packets that are up to 1280 bytes long, and they > Russ> SHOULD be able to receive and process packets that are up to > Russ> 3000 bytes long." > > (Sorry to be pedantic here, but I think it is important) > > I think that the word "packet" is wrong here. > > I think that you mean "datagram" -- seeing as a 3000 byte datagram would >exceed common MTU, it must have been fragmented into multiple frames to >have been received. > > The above (corrected) statement also implies to me that an IKEv2 and >host must be prepared to re-assemble at least 3000 bytes bytes worth of >fragment. I see your point. If we take this approach, then we need to remove the IP header and UDP header sizes from the mandatory-to-support size. Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 13:12:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19352 for ; Thu, 2 Sep 2004 13:12:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2v2Q-0001WY-KS; Thu, 02 Sep 2004 13:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2uyz-0008Aa-VA for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 13:02:48 -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 NAA18605 for ; Thu, 2 Sep 2004 13:02:43 -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 1C2v1P-0004YJ-Gy for ipsec@ietf.org; Thu, 02 Sep 2004 13:05:17 -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 i82GwUd06426 for ; Thu, 2 Sep 2004 12:58:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i82Gxl7h020956 for ; Thu, 2 Sep 2004 12:59:47 -0400 (EDT) Received: from nwkea-mail-1.sun.com(192.18.42.13) by nutshell.tislabs.com via csmap (V6.0) id srcAAAs5aW6O; Thu, 2 Sep 04 12:59:44 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i82H2b4d009581 for ; Thu, 2 Sep 2004 10:02:37 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i82H2aja023500 for ; Thu, 2 Sep 2004 11:02:37 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i82GxgQt002565; Thu, 2 Sep 2004 11:59:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i82Gxe56002564; Thu, 2 Sep 2004 11:59:40 -0500 (CDT) Date: Thu, 2 Sep 2004 11:59:40 -0500 From: Nicolas Williams To: Michael Richardson Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040902165939.GC1989@binky.central.sun.com> Mail-Followup-To: Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com, ipsec@lists.tislabs.com References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18117.1093983805@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipsec@lists.tislabs.com, Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > But, they would be vulnerable to the TCP RST attacks that we might in > fact trying to defend against in the first place. IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 ran over TCP) wouldn't affect any live SAs :) Yes, running IKEv2 over TCP adds a DoS to IKEv2, but IKE is, essentially, about bootstrapping a secure network given an insecure network, so that seems Ok to me. (And surely IKEv2 suffers from other DoS attacks anyways?) Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 13:23:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20808 for ; Thu, 2 Sep 2004 13:23:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2vEY-0007MK-A8; Thu, 02 Sep 2004 13:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2v6x-0003SB-Ar for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 13:10:59 -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 NAA19281 for ; Thu, 2 Sep 2004 13:10:56 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2v9O-00052n-BG for ipsec@ietf.org; Thu, 02 Sep 2004 13:13:30 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i82HAMFl016817 for ; Thu, 2 Sep 2004 13:10:23 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i82HAKsw016812; Thu, 2 Sep 2004 13:10:20 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 13:10:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.21498.439833.446732@gargle.gargle.HOWL> Date: Thu, 2 Sep 2004 13:10:18 -0400 From: Paul Koning To: housley@vigilsec.com Subject: Re: [Ipsec] Two IKEv2 issues from the IESG References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> <29377.1094137368@marajade.sandelman.ottawa.on.ca> <6.1.1.1.2.20040902123439.05543dc8@mail.binhost.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 02 Sep 2004 17:10:20.0286 (UTC) FILETIME=[B9E9C9E0:01C4910F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, margaret@thingmagic.com, mcr@sandelman.ottawa.on.ca, narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Russ" == Russ Housley writes: Russ> Michael: I suggest the addition of the following text: >> Russ> "All IKEv2 implementations MUST be able to receive and process Russ> packets that are up to 1280 bytes long, and they SHOULD be able Russ> to receive and process packets that are up to 3000 bytes long." >> (Sorry to be pedantic here, but I think it is important) >> >> I think that the word "packet" is wrong here. >> >> I think that you mean "datagram" -- seeing as a 3000 byte datagram >> would exceed common MTU, it must have been fragmented into >> multiple frames to have been received. >> >> The above (corrected) statement also implies to me that an IKEv2 >> and host must be prepared to re-assemble at least 3000 bytes bytes >> worth of fragment. Russ> I see your point. If we take this approach, then we need to Russ> remove the IP header and UDP header sizes from the Russ> mandatory-to-support size. If we weren't so afraid of internationalbureaucratspeak, we could just say "APDUs" which would be clear and unambiguous. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 2 14:59:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27849 for ; Thu, 2 Sep 2004 14:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2wgj-0001d8-Vj; Thu, 02 Sep 2004 14:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2was-0007Up-QH for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 14:45:58 -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 OAA27099 for ; Thu, 2 Sep 2004 14:45:57 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2wdJ-0004KK-GP for ipsec@ietf.org; Thu, 02 Sep 2004 14:48:31 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i82IjMJ11769; Thu, 2 Sep 2004 21:45:23 +0300 (IDT) Date: Thu, 02 Sep 2004 21:45:35 +0300 Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG Message-ID: <53f916e375fced1074599bff40b278eb@cbl217-132-236-200.bb.netvision.net.il> MIME-Version: 1.0 (Generated by Pantomime 1.1.0) From: Yoav Nir To: Russ Housley Organization: Check Point In-Reply-To: <6.1.1.1.2.20040902122036.055e4b58@mail.binhost.com> X-Mailer: GNUMail.app (Version 1.1.0) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ynir@checkpoint.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I don't think IKE can respond. I wouldn't have a problem with a MUST requirement to support 3000 bytes, but the fact that the peers are able to re-assemble them does not make it a good idea to send them. NAT devices, firewalls and routers on the way may drop fragmented UDP packets. I guess this ties into the other thread here about big IKE packets. On 2004-09-02 19:22:18 +0300 Russ Housley wrote: >> I don't see how the SHOULD is useful. The problem is that a sender >> has >> no way of knowing whether the other end supports the larger packet >> size. So, for interoperability, it can't try a size that large. If it >> does, it may well send packets into a black hole. This is a generic >> issue that has come up in many other protocols. It would be nice to >> send larger packets, but it turns out that there exist compliant >> implementations that don't support them, so one can't count on such >> packets being supported. >> >> Note, the key issue is what is the receiver mandated to be capable of >> accepting? >> >> Or, is there a way for IKE to respond to such packets with an error >> effectively saying "packet too big"? If so, then one could try a >> large >> packet, and negotiate a smaller value. That also works. >> >> Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 05:04:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08791 for ; Fri, 3 Sep 2004 05:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39rU-0002Z5-5k; Fri, 03 Sep 2004 04:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39S8-000420-9z for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 04:29:50 -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 EAA07212 for ; Fri, 3 Sep 2004 04:29:46 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C39Ug-0002Zn-6V for ipsec@ietf.org; Fri, 03 Sep 2004 04:32:27 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i838TaNw002630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 11:29:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i838TVP6002627; Fri, 3 Sep 2004 11:29:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.11115.789768.114922@fireball.kivinen.iki.fi> Date: Fri, 3 Sep 2004 11:29:31 +0300 From: Tero Kivinen To: Michael Richardson Subject: Re: [Ipsec] Two IKEv2 issues from the IESG In-Reply-To: <29377.1094137368@marajade.sandelman.ottawa.on.ca> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> <29377.1094137368@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley , narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson writes: > I think that you mean "datagram" -- seeing as a 3000 byte datagram would > exceed common MTU, it must have been fragmented into multiple frames to > have been received. > > The above (corrected) statement also implies to me that an IKEv2 and > host must be prepared to re-assemble at least 3000 bytes bytes worth of > fragment. Yes. That was my intention, meaning that all implementations of IKEv2 SHOULD also supoprt IP fragmentation in their end. There might be nodes between which make it impossible to use fragmentation (firewalls / NATs etc), but I think we should require that our own end is working in this case. I have seen IKEv1 implementation which implemented their own IP / UDP code which didn't include any reassembly at all. I do not want to that happen in the IKEv2. > Russ> I suggest the removal of the elliptic curve groups from > Russ> Appendix B. > > I don't object. Same here. It really does not matter if they are there or not. If they are there, then it might be easier for people to define more of them later, as the document also describes what to put in the KE payload, so if we remove the groups, do we also remove this text from draft-ietf-ipsec-ikev2-15.txt: ---------------------------------------------------------------------- The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:26:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15301 for ; Fri, 3 Sep 2004 06:26:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3B4A-0007MX-3t; Fri, 03 Sep 2004 06:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Axl-0004II-12 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:06:33 -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 GAA13547 for ; Fri, 3 Sep 2004 06:06:30 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3B0K-00014C-Jg for ipsec@ietf.org; Fri, 03 Sep 2004 06:09:13 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i83A6TNX003630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 13:06:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i83A6R9o003627; Fri, 3 Sep 2004 13:06:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.16930.850706.258383@fireball.kivinen.iki.fi> Date: Fri, 3 Sep 2004 13:06:26 +0300 From: Tero Kivinen To: Thomas Narten Subject: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: <6.1.1.1.2.20040902122036.055e4b58@mail.binhost.com> References: <6.1.1.1.2.20040902122036.055e4b58@mail.binhost.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 40 min X-Total-Time: 95 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Thomas Narten writes: >Russ Housley writes: > > "All IKEv2 implementations MUST be able to receive and process > > packets that are up to 1280 bytes long, and they SHOULD be able > > to receive and process packets that are up to 3000 bytes long." > >I don't see how the SHOULD is useful. The problem is that a sender has >no way of knowing whether the other end supports the larger packet >size. So, for interoperability, it can't try a size that large. If it >does, it may well send packets into a black hole. This is a generic >issue that has come up in many other protocols. It would be nice to >send larger packets, but it turns out that there exist compliant >implementations that don't support them, so one can't count on such >packets being supported. That would be the true if we would be talking about protocol talked between any random host in the internet and another random host in the internet. With IPsec that is not normally the case. You need to have some kind of trust relationship between the hosts to get IKEv2 working, i.e. you need common CA, or shared secrets exchange priori etc. In most of the cases you also need to agree about the policy to be used and so on. This means that agreeing in the maximum datagram size using those same out of band methods is possible. The 3000 bytes is more like to be meant as an instruction to the the implementators, use this in your implementation. If we leave it out all implementations will only support 1280 or 1500 bytes, and then there are some implementations which use 64k... If the adminstrator is going to be putting up a road-warrior VPN system for the company, and they enroll their own CA with 2048 bit keys, and 2 level hierarchy, which would mean that it does not fit to the 1280 byte packets, then can always say that we only support those implementations which supports this 3000 bytes packets. In normal case they will only support one implementation for the client end and one implementation (or same implementation) for the SGW end, so this is not really a problem. They simply need to select the implementations so that it supports that feature (and configure them so). On the other hand if you have something like garage door opener device, which only supports minimal 1280 byte packets, and you have your own 2048 bit CA in your house, you can still create smaller certificate (1024 bits or 2048 bits without too much extensions) to the door opening mechanisms so that that the door opener and opening mechanism can create IKEv2 connection using packets which are smaller than 1280 bytes (or you can simply use http transport for the certificates). As you need to configure both ends (at least generate / load the certificates for the private keys) anyways and add some kind of trust relationship there, this shouldn't be a problem. If you are really doing the random host to random host connections, then you must limit yourself to 1280 bytes, and use http transfer for certificates if the certificates doesn't fit otherwise, but as I said, that random host to random host connections are not that common use for the IPsec (at least now). The 1280 bytes is enough for basic operations in that case too, so there is no problem there. >Or, is there a way for IKE to respond to such packets with an error >effectively saying "packet too big"? If so, then one could try a large >packet, and negotiate a smaller value. That also works. Not really, but adding such would be very easy. The IKE_SA_INIT are almost always smaller than 1280 bytes: 20 + 8 + 28 + 4 + 8 + 4 + 8 * transforms + 8 + group_size + 4 + nonce_size = 84 + 8 * transforms + group size (max 1024) + nonce size (max 256) + 68 bytes of cookie. The max SA payload size with all algorithms and all key sizes is about 300 bytes. This gives the max IKE_SA_INIT packet size for 4096 bit Diffie-Hellman group 1220 bytes, which means that we can always send and receive that. Even 8192-bit Diffie-Hellman KE packet, with one crypto suite SA proposal, and 64 bytes of nonce and 64 bytes of cookie, can fit to the 1280 bytes. And as IKE_SA_INIT must be sent before the IKE_AUTH exchange (which includes the certificates) can start, we can later add notification to IKE_SA_INIT giving out the max size of packet we can receive. All current implementations will simply ignore the notification, and if implementation does not get such notification, and is not configured to allow more than 1280 bytes, it should keep the packet sizes less than 1280 bytes. So there is way to be able to configure bigger packet size if such need is later needed. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:28:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15548 for ; Fri, 3 Sep 2004 06:28:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3B5U-000808-FE; Fri, 03 Sep 2004 06:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3AzR-0004yF-Qm for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:08: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 GAA13793 for ; Fri, 3 Sep 2004 06:08:15 -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 1C3B1y-00015a-DV for ipsec@ietf.org; Fri, 03 Sep 2004 06:10:58 -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 i83A3vd27655 for ; Fri, 3 Sep 2004 06:03:57 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83A5F89015240 for ; Fri, 3 Sep 2004 06:05:15 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_zaWWD; Fri, 3 Sep 04 06:05:12 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i83A7rdp003636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 13:07:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i83A7l0J003633; Fri, 3 Sep 2004 13:07:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.17011.885015.535673@fireball.kivinen.iki.fi> Date: Fri, 3 Sep 2004 13:07:47 +0300 From: Tero Kivinen To: Nicolas Williams Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: <20040902165939.GC1989@binky.central.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Williams writes: > On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > > But, they would be vulnerable to the TCP RST attacks that we might in > > fact trying to defend against in the first place. > IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 > ran over TCP) wouldn't affect any live SAs :) Actually it would delete all the IPsec SAs negotiated with the IKEv2 SA which was terminated. So it would affect all SAs. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:32:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15920 for ; Fri, 3 Sep 2004 06:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3BEl-0002Wr-7n; Fri, 03 Sep 2004 06:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3B2J-0006U9-39 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:11:15 -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 GAA14221 for ; Fri, 3 Sep 2004 06:11:12 -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 1C3B4s-0001MO-7a for ipsec@ietf.org; Fri, 03 Sep 2004 06:13:55 -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 i83A6qd28004 for ; Fri, 3 Sep 2004 06:06:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83A871m015739 for ; Fri, 3 Sep 2004 06:08:07 -0400 (EDT) Received: from dsl084.203.95.61.touchtelindia.net(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvpa4PE; Fri, 3 Sep 04 06:08:04 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i83AAHOB024717; Fri, 3 Sep 2004 15:40:18 +0530 Message-ID: <413844E5.4070202@netd.com> Date: Fri, 03 Sep 2004 15:48:13 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suren@intotoinc.com Subject: Re: [Ipsec] HASH and URL References: <1093975729.2123.47.camel@suren> In-Reply-To: <1093975729.2123.47.camel@suren> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi surendra, As for as I think HTTP is allowed by firewall, and Ike will always sends it's ip address and port as part of URL. Thx mcreddy suren wrote: >Hi, > As I understand, the IKE node can send Hash of public key of > its certificate and URL (including port number) from which the peer > can retrieve its certificate. I guess, it is to ensure that there is > no fragmentation on IKE packets as some routers might not honor > fragmentation. > > I see that there would be firewall related issues in this. > Since, the IKE needs to make a new connection (HTTP connection) to > the URI given in Cert payload, any firewalls in between should have > a policy (ACL) to allow this HTTP connection. > > This could be a deployment problem. The administrator of firewall > need to create a ACL to allow all connections outbound. > This is one of the problem being faced by administrators on CRLDP > (CRL Distribution point) too. At least in this case, the distribution > points are smaller and in most cases deterministic and the > administrator of firewalls can create appropriate policies > statically. > > What do you think of this following proposal. > - IKE Peer which receives Certificate payload always sends its > IP address and port as part of URL. (Assumption here is that, > all services typically are allowed between IPSec Peers). > - When the IKE node receives HTTP request, it could send HTTP > Redirect to new URL, which could be outside its node. > - IKE Peer is expected to use same source IP address and Port > (May be using REUSE address option in sockets) to connect to > new HTTP Server and Port. > - Since, most of firewalls support 'address binding' feature, > it should work. > >Does this make sense? Comments? > >Thanks >Suren >www.intoto.com > > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:38:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16533 for ; Fri, 3 Sep 2004 06:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3BJu-0003ue-4v; Fri, 03 Sep 2004 06:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3B8H-0000cL-Ur for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:17:26 -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 GAA14601 for ; Fri, 3 Sep 2004 06:17:23 -0400 (EDT) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3BAq-0001oX-5C for ipsec@ietf.org; Fri, 03 Sep 2004 06:20:06 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i83AGpOB027492; Fri, 3 Sep 2004 15:46:54 +0530 Message-ID: <4138466D.5090804@netd.com> Date: Fri, 03 Sep 2004 15:54:45 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabled router X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I have some doubts regarding how the ipsec fits in to the security router in tunnel mode , please clarify. Packet comming from internet with ipsec in tunnel mode to local lan : eth0------------------eth1 Packet from ipsec Decryption will comes back to look up on inner ip header Here in tunnel mode outer ip header destination ip address will be SG address, and once it is decrypted it will give AH/ESP payload i.e inner IP packet back to Ip look up and it will look like comes with eth1 destined for local lan, and if we apply SNAT it will change the source address. I think SNAT won't for this ipsec packet. Packet comming from lan to internet in tunnel mode: eth1---------- --------eth0 Packet from ipsec Encryption will comes back to look up on Outer ip header added by ipsec Here in tunnel mode outer ip header is added as source ip address will be SG address, and once it is encrypted the packet looks like inner IP packet is as is sent by local lan host and goes back to Ip look up and it will look like comes with eth1 destined for local lan, and if we apply DNAT it will change the destination ip address.I think DNAT won't work for ipsec packets. Please clarify me how ipsec works in SNAT and DNAT cases and in SPD policy says 10.1.1.1/24 to 20.1.2.3/24 Lans configured in Tunnel mode. What will be the SA's in this case is it source ip SG1 to destination ip SG2 or it is Lan ip's only. Thanks in advance, Regards mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:38:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16649 for ; Fri, 3 Sep 2004 06:38:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3BJy-00041D-37; Fri, 03 Sep 2004 06:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3B8j-0000mN-6J for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:17:53 -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 GAA14620 for ; Fri, 3 Sep 2004 06:17:50 -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 1C3BBI-0001tN-ED for ipsec@ietf.org; Fri, 03 Sep 2004 06:20:33 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i83ADPd28925 for ; Fri, 3 Sep 2004 06:13:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83AEh4j017005 for ; Fri, 3 Sep 2004 06:14:43 -0400 (EDT) Received: from dsl084.203.95.61.touchtelindia.net(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEQaqjH; Fri, 3 Sep 04 06:14:39 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i83AGpOB027492; Fri, 3 Sep 2004 15:46:54 +0530 Message-ID: <4138466D.5090804@netd.com> Date: Fri, 03 Sep 2004 15:54:45 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabled router X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I have some doubts regarding how the ipsec fits in to the security router in tunnel mode , please clarify. Packet comming from internet with ipsec in tunnel mode to local lan : eth0------------------eth1 Packet from ipsec Decryption will comes back to look up on inner ip header Here in tunnel mode outer ip header destination ip address will be SG address, and once it is decrypted it will give AH/ESP payload i.e inner IP packet back to Ip look up and it will look like comes with eth1 destined for local lan, and if we apply SNAT it will change the source address. I think SNAT won't for this ipsec packet. Packet comming from lan to internet in tunnel mode: eth1---------- --------eth0 Packet from ipsec Encryption will comes back to look up on Outer ip header added by ipsec Here in tunnel mode outer ip header is added as source ip address will be SG address, and once it is encrypted the packet looks like inner IP packet is as is sent by local lan host and goes back to Ip look up and it will look like comes with eth1 destined for local lan, and if we apply DNAT it will change the destination ip address.I think DNAT won't work for ipsec packets. Please clarify me how ipsec works in SNAT and DNAT cases and in SPD policy says 10.1.1.1/24 to 20.1.2.3/24 Lans configured in Tunnel mode. What will be the SA's in this case is it source ip SG1 to destination ip SG2 or it is Lan ip's only. Thanks in advance, Regards mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 06:44:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17333 for ; Fri, 3 Sep 2004 06:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3BV9-0007Il-Nh; Fri, 03 Sep 2004 06:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3BKD-00046e-LY for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 06:29:46 -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 GAA15756 for ; Fri, 3 Sep 2004 06:29:43 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3BMn-00030C-Qb for ipsec@ietf.org; Fri, 03 Sep 2004 06:32:26 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i83ASepk003860 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 13:28:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i83ASdIw003857; Fri, 3 Sep 2004 13:28:39 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.18263.54510.460163@fireball.kivinen.iki.fi> Date: Fri, 3 Sep 2004 13:28:39 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: angelos@cs.columbia.edu, tytso@mit.edu, charliek@microsoft.com, housley@vigilsec.com, byfraser@cisco.com Subject: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I just noticed that we do not forbid of using encrption algorithm ENCR_NULL and integrity algorithm NONE for the IKE SA. Or at least I didn't find text about it. I think we should explicitly say that integrity algorithm cannot be NONE in IKE SA (it will completely break the authentication I think), and perhaps same thing about encryption algorithm ENCR_NULL (it will break the identity protection). So add a paragraph to section 3.3.3 saying: "For the IKE SA integrity algoritm MUST NOT be NONE, and encryption algorithm MUST NOT be ENCR_NULL." -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 09:11:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27024 for ; Fri, 3 Sep 2004 09:11: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 1C3DjX-0000ju-SY; Fri, 03 Sep 2004 09:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Dep-00084Y-Oo for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 08:59:12 -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 IAA26142 for ; Fri, 3 Sep 2004 08:59:10 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3DhQ-0005YB-H3 for ipsec@ietf.org; Fri, 03 Sep 2004 09:01:53 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i83CwKh06634; Fri, 3 Sep 2004 08:58:25 -0400 (EDT) Received: from [47.140.54.204] (artpt680.us.nortel.com [47.140.54.204]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S19V131Z; Fri, 3 Sep 2004 08:58:12 -0400 Message-ID: <41386A50.6030300@nortelnetworks.com> Date: Fri, 03 Sep 2004 08:57:52 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. References: <16696.18263.54510.460163@fireball.kivinen.iki.fi> In-Reply-To: <16696.18263.54510.460163@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, byfraser@cisco.com, charliek@microsoft.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >I just noticed that we do not forbid of using encrption algorithm >ENCR_NULL and integrity algorithm NONE for the IKE SA. Or at least I >didn't find text about it. > >I think we should explicitly say that integrity algorithm cannot be >NONE in IKE SA (it will completely break the authentication I think), >and perhaps same thing about encryption algorithm ENCR_NULL (it will >break the identity protection). > >So add a paragraph to section 3.3.3 saying: > >"For the IKE SA integrity algoritm MUST NOT be NONE, and encryption >algorithm MUST NOT be ENCR_NULL." > > This probably was a side-effect of separating algorithms out of the spec. This text should go into the security considerations, I would think. regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 11:24:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05775 for ; Fri, 3 Sep 2004 11:24:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3FmV-0001h3-DP; Fri, 03 Sep 2004 11:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Fjs-0000uI-6H for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 11:12:32 -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 LAA05043 for ; Fri, 3 Sep 2004 11:12:30 -0400 (EDT) Received: from www.native6.com ([168.103.150.210] helo=hestia.native6.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3FmT-0001nd-P3 for ipsec@ietf.org; Fri, 03 Sep 2004 11:15:15 -0400 Received: from JOHNIBMLAPTOP ([10.128.0.99]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id i83FBvJ1009422 for ; Fri, 3 Sep 2004 08:11:57 -0700 Message-Id: <200409031511.i83FBvJ1009422@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Date: Fri, 3 Sep 2004 08:12:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSNfam2Dsakoyr4SbiG3bCN7NIGKwESpyCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Subject: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The flow label in IPv6 is chosen by the source node, and must be delivered to the ultimate destination without having been changed in transit, unlike the DSCP or ECN QoS-related fields for IPv6. I suggest, since it is constant end-to-end, the field be moved to "immutable" and protected by AH. -------------- from draft-ietf-ipsec-rfc2402bis-07 ---------- 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label Hop Limit -------------- from RFC 3697 -------------- 2. IPv6 Flow Label Specification The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a source to label packets of a flow. A Flow Label of zero is used to indicate packets not part of any flow. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to identify which flow a particular packet belongs to. Packets are processed in a flow-specific manner by the nodes that have been set up with flow-specific state. The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification. The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). ------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspenceNOSPAM@native6.com www.native6.com ------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 11:30:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06239 for ; Fri, 3 Sep 2004 11:30:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3FzR-0004UT-1K; Fri, 03 Sep 2004 11:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3FuB-0002xs-Da for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 11:23:12 -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 LAA05639 for ; Fri, 3 Sep 2004 11:23:09 -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 1C3Fwm-000220-3B for ipsec@ietf.org; Fri, 03 Sep 2004 11:25:54 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i83FIpd27416 for ; Fri, 3 Sep 2004 11:18:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83FK6Rn015820 for ; Fri, 3 Sep 2004 11:20:08 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZCa4ME; Fri, 3 Sep 04 11:19:35 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i83FMQ35019833 for ; Fri, 3 Sep 2004 08:22:26 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i83FMLJl029112 for ; Fri, 3 Sep 2004 09:22:26 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i83FJQu1013936; Fri, 3 Sep 2004 10:19:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i83FJONM013935; Fri, 3 Sep 2004 10:19:24 -0500 (CDT) Date: Fri, 3 Sep 2004 10:19:24 -0500 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040903151924.GF1989@binky.central.sun.com> Mail-Followup-To: Tero Kivinen , Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com, ipsec@lists.tislabs.com References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16696.17011.885015.535673@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Fri, Sep 03, 2004 at 01:07:47PM +0300, Tero Kivinen wrote: > Nicolas Williams writes: > > On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > > > But, they would be vulnerable to the TCP RST attacks that we might in > > > fact trying to defend against in the first place. > > IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 > > ran over TCP) wouldn't affect any live SAs :) > > Actually it would delete all the IPsec SAs negotiated with the IKEv2 > SA which was terminated. So it would affect all SAs. I don't get it. IKEv2 runs over UDP, where there's no RST. So why would running it over TCP introduce this RST->SA-death scenario? What am I missing? Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 12:57:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10864 for ; Fri, 3 Sep 2004 12:57:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3HIr-0005pU-Gx; Fri, 03 Sep 2004 12:52:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3HGs-0005FZ-D8 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 12:50:42 -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 MAA10597 for ; Fri, 3 Sep 2004 12:50:39 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3HJV-0003rZ-AR for ipsec@ietf.org; Fri, 03 Sep 2004 12:53:26 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i83Go7jh005915; Fri, 3 Sep 2004 12:50:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200409031511.i83FBvJ1009422@hestia.native6.com> References: <200409031511.i83FBvJ1009422@hestia.native6.com> Date: Fri, 3 Sep 2004 12:45:18 -0400 To: "John Spence, CCSI, CCNA, CISSP" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.0 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:12 AM -0700 9/3/04, John Spence, CCSI, CCNA, CISSP wrote: >The flow label in IPv6 is chosen by the source node, and must be delivered >to the ultimate destination without having been changed in transit, unlike >the DSCP or ECN QoS-related fields for IPv6. > >I suggest, since it is constant end-to-end, the field be moved to >"immutable" and protected by AH. > John, We copied the text from 2402, and nobody had noticed the error there in almost 6 years! Good catch. We will change the 2402bis text accordingly. Thanks, Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 13:55:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01822 for ; Fri, 3 Sep 2004 13:55:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IDF-0006zA-Lg; Fri, 03 Sep 2004 13:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IBJ-0006eY-Rv for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 13:49:04 -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 NAA01269 for ; Fri, 3 Sep 2004 13:48:57 -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 1C3I9z-0004xT-OP for ipsec@ietf.org; Fri, 03 Sep 2004 13:47:41 -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 i83Hecd11809 for ; Fri, 3 Sep 2004 13:40:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83HfuWc008125 for ; Fri, 3 Sep 2004 13:41:56 -0400 (EDT) Received: from mxout3.netvision.net.il(194.90.9.24) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3baG2p; Fri, 3 Sep 04 13:41:53 -0400 Received: from [217.132.236.116] by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3H001OD7YMH1@mxout3.netvision.net.il> for ipsec@lists.tislabs.com; Fri, 03 Sep 2004 20:44:46 +0300 (IDT) Date: Fri, 03 Sep 2004 20:45:00 +0300 From: Yoav Nir Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-reply-to: <16696.17011.885015.535673@fireball.kivinen.iki.fi> To: Tero Kivinen Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , Nicolas Williams , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT No. At the end of the initial negotiation, the TCP connection is terminated and the SA remains. Further child SAs will be negotiated in new TCP connections or using UDP packets. (or SCTP if we write support for that too) The SA is not bound to any message passing mechanism. On 03/09/2004, at 13:07, Tero Kivinen wrote: > Nicolas Williams writes: >> On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: >>> But, they would be vulnerable to the TCP RST attacks that we might >>> in >>> fact trying to defend against in the first place. >> IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 >> ran over TCP) wouldn't affect any live SAs :) > > Actually it would delete all the IPsec SAs negotiated with the IKEv2 > SA which was terminated. So it would affect all SAs. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 13:58:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02057 for ; Fri, 3 Sep 2004 13:58:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IDG-0006zu-UO; Fri, 03 Sep 2004 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IBJ-0006ef-AP for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 13:49:01 -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 NAA01305 for ; Fri, 3 Sep 2004 13:48:59 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3I6L-0004nL-PG for ipsec@ietf.org; Fri, 03 Sep 2004 13:43:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 3 Sep 2004 10:40:37 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 10:40:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Date: Fri, 3 Sep 2004 10:40:51 -0700 Message-ID: Thread-Topic: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Thread-Index: AcSRtdoCdJy7AWpSRrazV6nut5l+pwAJCWqw From: "Charlie Kaufman" To: "Dondeti, Lakshminath" , "Tero Kivinen" X-OriginalArrivalTime: 03 Sep 2004 17:40:15.0762 (UTC) FILETIME=[12836F20:01C491DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, jis@mit.edu, byfraser@cisco.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I disagree. IKEv2 was specifically designed so that it would maintain most of its security properties even if its encryption algorithm were broken (or NULL). Yes, identities and traffic selectors would be exposed. But the key derivation and authentication would still be secure. It would be entirely appropriate to use ENCR_NULL in IKE if AH was being negotiated or ENCR_NULL were being negotiated in the underlying ESP. Similarly, if IKE negotiated NONE as its integrity protection algorithm, the subsequently negotiated ESP and AH SAs would still be secure (though the protocol would be exposed to some "downgrade" attacks if the endpoints were not both properly configured. So I don't believe these should be ruled out in the IKEv2 specification itself. In Jeff's algorithms document, ENCR_NULL is listed as *MAY* implement, which I believe is appropriate. NONE for integrity is not labeled. Perhaps it should be labeled MUST NOT. (I think it's OK as is, but I understand your concern). --Charlie -----Original Message----- From: Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com]=20 Sent: Friday, September 03, 2004 5:58 AM To: Tero Kivinen Cc: ipsec@ietf.org; angelos@cs.columbia.edu; tytso@mit.edu; Charlie Kaufman; housley@vigilsec.com; byfraser@cisco.com Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Tero Kivinen wrote: >I just noticed that we do not forbid of using encrption algorithm >ENCR_NULL and integrity algorithm NONE for the IKE SA. Or at least I >didn't find text about it. > >I think we should explicitly say that integrity algorithm cannot be >NONE in IKE SA (it will completely break the authentication I think), >and perhaps same thing about encryption algorithm ENCR_NULL (it will >break the identity protection). > >So add a paragraph to section 3.3.3 saying: > >"For the IKE SA integrity algoritm MUST NOT be NONE, and encryption >algorithm MUST NOT be ENCR_NULL." > =20 > This probably was a side-effect of separating algorithms out of the=20 spec. This text should go into the security considerations, I would think. regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 14:06:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02876 for ; Fri, 3 Sep 2004 14:06:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IPz-0001Sv-9f; Fri, 03 Sep 2004 14:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IIA-000832-76 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 13:56:06 -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 NAA01914 for ; Fri, 3 Sep 2004 13:56:04 -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 1C3IKl-0005HM-FD for ipsec@ietf.org; Fri, 03 Sep 2004 13:58:50 -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 i83Hpld12709 for ; Fri, 3 Sep 2004 13:51:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83Hr4Xs009569 for ; Fri, 3 Sep 2004 13:53:05 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5WaOQs; Fri, 3 Sep 04 13:52:59 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i83Htr35004029 for ; Fri, 3 Sep 2004 10:55:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i83HtpJl012196 for ; Fri, 3 Sep 2004 11:55:53 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i83Hqtiv014145; Fri, 3 Sep 2004 12:52:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i83HqtF7014144; Fri, 3 Sep 2004 12:52:55 -0500 (CDT) Date: Fri, 3 Sep 2004 12:52:54 -0500 From: Nicolas Williams To: Yoav Nir Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040903175254.GM1989@binky.central.sun.com> Mail-Followup-To: Yoav Nir , Tero Kivinen , Paul Koning , pki4ipsec@honor.icsalabs.com, Michael Richardson , ipsec@lists.tislabs.com References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , Tero Kivinen , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thank you. So, why not run IKEv2 over TCP (or SCTP)? I think the DoS attacks on unprotected TCP connections for IKEv2 are something we can probably live with as the price of bootstrapping a secure network. So, unless I'm missing something, DoS attacks TCP do not make for a sufficient rationale for rejecting IKEv2 over TCP. In the Kerberos V world we had the same middle-box/large packet traversal problem; running the KDC exchanges over TCP worked for Kerberos (a bit of encapsulation, a PDU length, had to be prefixed to the Kerberos PDUs). Is NAT-T more difficult if IKEv2 is run over TCP? Nico On Fri, Sep 03, 2004 at 08:45:00PM +0300, Yoav Nir wrote: > No. At the end of the initial negotiation, the TCP connection is > terminated and the SA remains. Further child SAs will be negotiated in > new TCP connections or using UDP packets. (or SCTP if we write support > for that too) > > The SA is not bound to any message passing mechanism. > > On 03/09/2004, at 13:07, Tero Kivinen wrote: > > >Nicolas Williams writes: > >>On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > >>> But, they would be vulnerable to the TCP RST attacks that we might > >>>in > >>>fact trying to defend against in the first place. > >>IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 > >>ran over TCP) wouldn't affect any live SAs :) > > > >Actually it would delete all the IPsec SAs negotiated with the IKEv2 > >SA which was terminated. So it would affect all SAs. > >-- > >kivinen@safenet-inc.com > > > >_______________________________________________ > >Ipsec mailing list > >Ipsec@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 14:11:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03345 for ; Fri, 3 Sep 2004 14:11:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IQ6-0001Td-7o; Fri, 03 Sep 2004 14:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IJA-0008DZ-Ty for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 13:57:08 -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 NAA01964 for ; Fri, 3 Sep 2004 13:57:07 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3ILp-0005JK-8Q for ipsec@ietf.org; Fri, 03 Sep 2004 13:59:53 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i83HvTlx008094 for ; Fri, 3 Sep 2004 10:57:29 -0700 Message-ID: <15fa01c491df$6a280a40$110fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: References: <53f916e375fced1074599bff40b278eb@cbl217-132-236-200.bb.netvision.net.il> Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG Date: Fri, 3 Sep 2004 10:56:00 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit It is good thing to explicit indicate the MUST and SHOULD length of IKE messages to avoid interoperability problems. I also would like having 3000 (or even 8K) as a MUST requirement, when certifiates are used. For PSK only implementations, 1280 seems like a good limit value. There are arguments in the community that - Some UDP/IP implementations do not support fragmentation and reassembly - Some routers/firewalls/NATs discard the fragments. - DoS attacks targeting reassembly process on the end hosts. I feel that we should not worry about first two cases and I think they are in minority and they need to be fixed and would be fixed due to market requirement. We need to see, the type of reassembly DoS attacks that are possible. In my view, most of the systems are already hardened. There is one arugment that, ID (Identification) value in IP header can be guessed by blind attacker and can corrupt the datagram by sending fake IP packet with guessed ID. But, firewalls or even hardended systems sufficiently randomize this value to protect against blind injection attacks. - Keep the UDP transport as MUST for IKE (as it is today) - IKE implementations supporting PSK MUST be able to send/ receive 1280 byte messages. - IKE implementation supporting Certificates MUST be able to send/receive 3000 byte messages. - IKE implementation supporting chain of certificates (upto 4) MUST be able to send/receive 8000 byte messages. For the cases, where above values are not sufficient can make use of alternate mechanisms such as TCP transport Or HASH/URL mechanism or others. These can be 'MAY' options. Srini Intoto Inc. www.intoto.com ----- Original Message ----- > I don't think IKE can respond. I wouldn't have a problem with a MUST > requirement to support 3000 bytes, but the fact that the peers are > able to re-assemble them does not make it a good idea to send them. > NAT devices, firewalls and routers on the way may drop fragmented UDP > packets. > > I guess this ties into the other thread here about big IKE packets. > > > On 2004-09-02 19:22:18 +0300 Russ Housley wrote: > > >> I don't see how the SHOULD is useful. The problem is that a sender > >> has > >> no way of knowing whether the other end supports the larger packet > >> size. So, for interoperability, it can't try a size that large. If it > >> does, it may well send packets into a black hole. This is a generic > >> issue that has come up in many other protocols. It would be nice to > >> send larger packets, but it turns out that there exist compliant > >> implementations that don't support them, so one can't count on such > >> packets being supported. > >> > >> Note, the key issue is what is the receiver mandated to be capable of > >> accepting? > >> > >> Or, is there a way for IKE to respond to such packets with an error > >> effectively saying "packet too big"? If so, then one could try a > >> large > >> packet, and negotiate a smaller value. That also works. > >> > >> Thomas > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 14:19:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04006 for ; Fri, 3 Sep 2004 14:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Icc-0006qf-OH; Fri, 03 Sep 2004 14:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IZL-0003id-TQ for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 14:13:51 -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 OAA03637 for ; Fri, 3 Sep 2004 14:13:50 -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 1C3Ic0-0005qe-9I for ipsec@ietf.org; Fri, 03 Sep 2004 14:16:36 -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 i83I9ad14421 for ; Fri, 3 Sep 2004 14:09:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83IAsFu012049 for ; Fri, 3 Sep 2004 14:10:54 -0400 (EDT) Received: from mxout5.netvision.net.il(194.90.9.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdMa4Hx; Fri, 3 Sep 04 14:10:52 -0400 Received: from [217.132.236.116] by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3H00MGI9AXPP@mxout5.netvision.net.il> for ipsec@lists.tislabs.com; Fri, 03 Sep 2004 21:13:45 +0300 (IDT) Date: Fri, 03 Sep 2004 21:13:59 +0300 From: Yoav Nir Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-reply-to: <20040903175254.GM1989@binky.central.sun.com> To: Nicolas Williams Message-id: <06E5F5F1-FDD5-11D8-97AA-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903175254.GM1989@binky.central.sun.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT If you are behind a NAT device, you need to have at least one packet go over UDP from the iniitator to the responder. In IKEv1 you could do this by passing phase 2 over UDP. In IKEv2 you'll need an extra exchange (empty notification, or CCSA). As I am writing this mail, I am connected to my mail server from behind a home DSL router. IKEv1 over UDP did not work, because packet #5 of Main Mode did not pass ( or maybe it was packet #6). IKE over TCP worked like a charm, but it was only done for phase 1. TCP is usually considered more dangerous than UDP because DoS attacks are generally easier to mount on TCP. (RST attack, SYN attack) I think this is the reason for the resistance to using anything other than UDP. Maybe someone can write a draft for IKEv2 over TCP (and SCTP) as optional extensions to IKEv2. Then maybe we can collect all the optional extensions people keep suggesting, and make them into a big document titled "IKEv2 Optional Extensions". On 03/09/2004, at 20:52, Nicolas Williams wrote: > Thank you. > > So, why not run IKEv2 over TCP (or SCTP)? > > I think the DoS attacks on unprotected TCP connections for IKEv2 are > something we can probably live with as the price of bootstrapping a > secure network. So, unless I'm missing something, DoS attacks TCP do > not make for a sufficient rationale for rejecting IKEv2 over TCP. > > In the Kerberos V world we had the same middle-box/large packet > traversal problem; running the KDC exchanges over TCP worked for > Kerberos (a bit of encapsulation, a PDU length, had to be prefixed to > the Kerberos PDUs). > > Is NAT-T more difficult if IKEv2 is run over TCP? > > Nico > > On Fri, Sep 03, 2004 at 08:45:00PM +0300, Yoav Nir wrote: >> No. At the end of the initial negotiation, the TCP connection is >> terminated and the SA remains. Further child SAs will be negotiated >> in >> new TCP connections or using UDP packets. (or SCTP if we write support >> for that too) >> >> The SA is not bound to any message passing mechanism. >> >> On 03/09/2004, at 13:07, Tero Kivinen wrote: >> >>> Nicolas Williams writes: >>>> On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: >>>>> But, they would be vulnerable to the TCP RST attacks that we might >>>>> in >>>>> fact trying to defend against in the first place. >>>> IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if >>>> IKEv2 >>>> ran over TCP) wouldn't affect any live SAs :) >>> >>> Actually it would delete all the IPsec SAs negotiated with the IKEv2 >>> SA which was terminated. So it would affect all SAs. >>> -- >>> kivinen@safenet-inc.com >>> >>> _______________________________________________ >>> Ipsec mailing list >>> Ipsec@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipsec >>> >> > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 14:33:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04876 for ; Fri, 3 Sep 2004 14:33:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Iq7-0000yh-OR; Fri, 03 Sep 2004 14:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IkI-0008AT-Ap for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 14:25:10 -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 OAA04305 for ; Fri, 3 Sep 2004 14:25:08 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3Imw-000665-TD for ipsec@ietf.org; Fri, 03 Sep 2004 14:27:55 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i83IORf25912; Fri, 3 Sep 2004 14:24:27 -0400 (EDT) Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S19V13SF; Fri, 3 Sep 2004 14:24:26 -0400 Message-ID: <4138B6DA.9050806@nortelnetworks.com> Date: Fri, 03 Sep 2004 14:24:26 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, jis@mit.edu, byfraser@cisco.com, housley@vigilsec.com, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Agreed that IKEv2 will provide secure key establishment with the NULL algorithms, but as you note, other security properties (e.g., no ID protection, the TS payloads are exposed, and worse can be modified - and that would be a problem if TS's are used to dynamically update SPDs as described in Section 2.9 of ikev2-15 - if AUTH_NULL were to be allowed) of the protocol do not hold. I hope this can be documented in the security considerations section of the ikev2- algorithms I-D. There is discussion there about the MUST and SHOULD algorithms, but none about the MAY algorithms (ENCR_NONE; and if possible a note about the MD5 algorithms would also be a welcome addition). Thanks. I am not sure about the implications of NULL algorithms in case of EAP (Section 2.16); there is a note in Section 5 of ikev2-15, that non-key-generating methods SHOULD use a protected tunnel, which is good. Is it ok to use ENCR_NULL with any key-generating method of EAP? regards, Lakshminath Charlie Kaufman wrote: >I disagree. > >IKEv2 was specifically designed so that it would maintain most of its >security properties even if its encryption algorithm were broken (or >NULL). Yes, identities and traffic selectors would be exposed. But the >key derivation and authentication would still be secure. It would be >entirely appropriate to use ENCR_NULL in IKE if AH was being negotiated >or ENCR_NULL were being negotiated in the underlying ESP. > >Similarly, if IKE negotiated NONE as its integrity protection algorithm, >the subsequently negotiated ESP and AH SAs would still be secure (though >the protocol would be exposed to some "downgrade" attacks if the >endpoints were not both properly configured. > >So I don't believe these should be ruled out in the IKEv2 specification >itself. > >In Jeff's algorithms document, ENCR_NULL is listed as *MAY* implement, >which I believe is appropriate. NONE for integrity is not labeled. >Perhaps it should be labeled MUST NOT. (I think it's OK as is, but I >understand your concern). > > --Charlie > >-----Original Message----- >From: Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] >Sent: Friday, September 03, 2004 5:58 AM >To: Tero Kivinen >Cc: ipsec@ietf.org; angelos@cs.columbia.edu; tytso@mit.edu; Charlie >Kaufman; housley@vigilsec.com; byfraser@cisco.com >Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or >ENCR_NULL as ENCR. > >Tero Kivinen wrote: > > > >>I just noticed that we do not forbid of using encrption algorithm >>ENCR_NULL and integrity algorithm NONE for the IKE SA. Or at least I >>didn't find text about it. >> >>I think we should explicitly say that integrity algorithm cannot be >>NONE in IKE SA (it will completely break the authentication I think), >>and perhaps same thing about encryption algorithm ENCR_NULL (it will >>break the identity protection). >> >>So add a paragraph to section 3.3.3 saying: >> >>"For the IKE SA integrity algoritm MUST NOT be NONE, and encryption >>algorithm MUST NOT be ENCR_NULL." >> >> >> >> >This probably was a side-effect of separating algorithms out of the >spec. This text should go into the security considerations, I would >think. > >regards, >Lakshminath > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 15:01:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06273 for ; Fri, 3 Sep 2004 15:01:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3JCf-0005M6-NH; Fri, 03 Sep 2004 14:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3J4N-0003n4-Q8 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 14:45:55 -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 OAA05623 for ; Fri, 3 Sep 2004 14:45:54 -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 1C3J71-0006Uz-Go for ipsec@ietf.org; Fri, 03 Sep 2004 14:48:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i83IfWd16961 for ; Fri, 3 Sep 2004 14:41:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83IgogN016135 for ; Fri, 3 Sep 2004 14:42:50 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAATraiGF; Fri, 3 Sep 04 14:42:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i83IjUZh009081 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 21:45:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i83IjSnI009078; Fri, 3 Sep 2004 21:45:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16696.48072.583442.387602@fireball.kivinen.iki.fi> Date: Fri, 3 Sep 2004 21:45:28 +0300 From: Tero Kivinen To: Nicolas Williams Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: <20040903151924.GF1989@binky.central.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903151924.GF1989@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Williams writes: > On Fri, Sep 03, 2004 at 01:07:47PM +0300, Tero Kivinen wrote: > > Nicolas Williams writes: > > > On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > > > > But, they would be vulnerable to the TCP RST attacks that we might in > > > > fact trying to defend against in the first place. > > > IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 > > > ran over TCP) wouldn't affect any live SAs :) > > > > Actually it would delete all the IPsec SAs negotiated with the IKEv2 > > SA which was terminated. So it would affect all SAs. > > I don't get it. IKEv2 runs over UDP, where there's no RST. And if the UDP connection is broken down (== no reply from the other end), the IKE SA is removed, and all the IPsec SAs created using them IKE SA are also removed. > So why would running it over TCP introduce this RST->SA-death scenario? If IKE is run over TCP, my interpreation of TCP connection breaking down, would be the same as UDP connection breaking down, i.e. the IKE SA is removed. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 15:03:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06533 for ; Fri, 3 Sep 2004 15:03:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3JD6-0005Xx-HO; Fri, 03 Sep 2004 14:54:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3J92-0004SZ-Jh for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 14:50:44 -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 OAA05794 for ; Fri, 3 Sep 2004 14:50:42 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3JBg-0006ZR-Cp for ipsec@ietf.org; Fri, 03 Sep 2004 14:53:29 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i83Ip4lx010229; Fri, 3 Sep 2004 11:51:04 -0700 Message-ID: <168101c491e6$e6748cc0$110fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: , "ipsec" , "ipsec" References: <4138466D.5090804@netd.com> Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter Date: Fri, 3 Sep 2004 11:50:36 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I guess you are asking the case where IPSec and NAT functionality exist in the same unit. Note that, NAT is not required, if the private networks behind security gateways are under same administrator control. Administrator can ensure that, unique private IP address space is given to the networks under his control. If above is not the case, then NAT is applied such that, the remote systems see the public IP addresses (routable IP addresses). For outbound packets (Clear to Secure) - NAT is done first. - Run through the IPSec Policies. - If IPSec policy indicates 'Apply', packet is encrypted and outer IP header is added. In tunnel, the outer IP header would have source IP is local gateway IP address and destintion IP would be remote gateway IP address. Internal IP header is not touched. At the remote SG, outer IP header is removed and the internal IP packet is sent out on its local network. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "M.Chenna kesava Reddy" To: "ipsec" ; "ipsec" Sent: Friday, September 03, 2004 3:24 AM Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter > Hi, > I have some doubts regarding how the ipsec fits in to the security > router in tunnel mode , > please clarify. > Packet comming from internet with ipsec in tunnel mode to local lan : > eth0------------------eth1 > Packet from ipsec Decryption will comes back to look up on inner ip header > Here in tunnel mode outer ip header destination ip address will be SG > address, and once > it is decrypted it will give AH/ESP payload i.e inner IP packet back to > Ip look up and > it will look like comes with eth1 destined for local lan, and if we > apply SNAT it will > change the source address. I think SNAT won't for this ipsec packet. > > Packet comming from lan to internet in tunnel mode: > > eth1---------- > --------eth0 > Packet from ipsec Encryption will comes back to look up on Outer ip > header added by ipsec > > Here in tunnel mode outer ip header is added as source ip address will > be SG address, and once > it is encrypted the packet looks like inner IP packet is as is sent by > local lan host and goes back to > Ip look up and it will look like comes with eth1 destined for local > lan, and if we apply DNAT it will > change the destination ip address.I think DNAT won't work for ipsec > packets. > > Please clarify me how ipsec works in SNAT and DNAT cases and in SPD > policy says 10.1.1.1/24 to > 20.1.2.3/24 Lans configured in Tunnel mode. > What will be the SA's in this case is it source ip SG1 to destination ip > SG2 or it is Lan ip's only. > > Thanks in advance, > > Regards > mcreddy > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 15:04:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06802 for ; Fri, 3 Sep 2004 15:04:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3JD8-0005Yn-Aj; Fri, 03 Sep 2004 14:54:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3J99-0004YY-T2 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 14:50:51 -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 OAA05797 for ; Fri, 3 Sep 2004 14:50:50 -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 1C3JBo-0006ZV-Oy for ipsec@ietf.org; Fri, 03 Sep 2004 14:53:37 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i83Ikad17352 for ; Fri, 3 Sep 2004 14:46:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83Ilt6b016848 for ; Fri, 3 Sep 2004 14:47:55 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net(66.80.10.146) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZLaW3G; Fri, 3 Sep 04 14:47:52 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i83Ip4lx010229; Fri, 3 Sep 2004 11:51:04 -0700 Message-ID: <168101c491e6$e6748cc0$110fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: , "ipsec" , "ipsec" References: <4138466D.5090804@netd.com> Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter Date: Fri, 3 Sep 2004 11:50:36 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I guess you are asking the case where IPSec and NAT functionality exist in the same unit. Note that, NAT is not required, if the private networks behind security gateways are under same administrator control. Administrator can ensure that, unique private IP address space is given to the networks under his control. If above is not the case, then NAT is applied such that, the remote systems see the public IP addresses (routable IP addresses). For outbound packets (Clear to Secure) - NAT is done first. - Run through the IPSec Policies. - If IPSec policy indicates 'Apply', packet is encrypted and outer IP header is added. In tunnel, the outer IP header would have source IP is local gateway IP address and destintion IP would be remote gateway IP address. Internal IP header is not touched. At the remote SG, outer IP header is removed and the internal IP packet is sent out on its local network. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "M.Chenna kesava Reddy" To: "ipsec" ; "ipsec" Sent: Friday, September 03, 2004 3:24 AM Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter > Hi, > I have some doubts regarding how the ipsec fits in to the security > router in tunnel mode , > please clarify. > Packet comming from internet with ipsec in tunnel mode to local lan : > eth0------------------eth1 > Packet from ipsec Decryption will comes back to look up on inner ip header > Here in tunnel mode outer ip header destination ip address will be SG > address, and once > it is decrypted it will give AH/ESP payload i.e inner IP packet back to > Ip look up and > it will look like comes with eth1 destined for local lan, and if we > apply SNAT it will > change the source address. I think SNAT won't for this ipsec packet. > > Packet comming from lan to internet in tunnel mode: > > eth1---------- > --------eth0 > Packet from ipsec Encryption will comes back to look up on Outer ip > header added by ipsec > > Here in tunnel mode outer ip header is added as source ip address will > be SG address, and once > it is encrypted the packet looks like inner IP packet is as is sent by > local lan host and goes back to > Ip look up and it will look like comes with eth1 destined for local > lan, and if we apply DNAT it will > change the destination ip address.I think DNAT won't work for ipsec > packets. > > Please clarify me how ipsec works in SNAT and DNAT cases and in SPD > policy says 10.1.1.1/24 to > 20.1.2.3/24 Lans configured in Tunnel mode. > What will be the SA's in this case is it source ip SG1 to destination ip > SG2 or it is Lan ip's only. > > Thanks in advance, > > Regards > mcreddy > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 15:20:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09089 for ; Fri, 3 Sep 2004 15:20:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3JVa-0001vQ-Aw; Fri, 03 Sep 2004 15:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3JR8-0007Sf-NF for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 15:09:26 -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 PAA07606 for ; Fri, 3 Sep 2004 15:09:24 -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 1C3JTn-00076M-MP for ipsec@ietf.org; Fri, 03 Sep 2004 15:12:12 -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 i83J5Bd19039 for ; Fri, 3 Sep 2004 15:05:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i83J6T5L019745 for ; Fri, 3 Sep 2004 15:06:29 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe2aaKM; Fri, 3 Sep 04 15:06:27 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i83J9L35005965 for ; Fri, 3 Sep 2004 12:09:21 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i83J9JJl013247 for ; Fri, 3 Sep 2004 13:09:21 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i83J6NDp014647; Fri, 3 Sep 2004 14:06:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i83J6MiJ014646; Fri, 3 Sep 2004 14:06:22 -0500 (CDT) Date: Fri, 3 Sep 2004 14:06:22 -0500 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040903190622.GO1989@binky.central.sun.com> Mail-Followup-To: Tero Kivinen , Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com, ipsec@lists.tislabs.com References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903151924.GF1989@binky.central.sun.com> <16696.48072.583442.387602@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16696.48072.583442.387602@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Fri, Sep 03, 2004 at 09:45:28PM +0300, Tero Kivinen wrote: > Nicolas Williams writes: > > On Fri, Sep 03, 2004 at 01:07:47PM +0300, Tero Kivinen wrote: > > > Nicolas Williams writes: > > > > On Tue, Aug 31, 2004 at 04:23:25PM -0400, Michael Richardson wrote: > > > > > But, they would be vulnerable to the TCP RST attacks that we might in > > > > > fact trying to defend against in the first place. > > > > IKEv2 is not BGP. Presumably RSTing an IKEv2 TCP connection (if IKEv2 > > > > ran over TCP) wouldn't affect any live SAs :) > > > > > > Actually it would delete all the IPsec SAs negotiated with the IKEv2 > > > SA which was terminated. So it would affect all SAs. > > > > I don't get it. IKEv2 runs over UDP, where there's no RST. > > And if the UDP connection is broken down (== no reply from the other > end), the IKE SA is removed, and all the IPsec SAs created using them > IKE SA are also removed. > > > So why would running it over TCP introduce this RST->SA-death scenario? > > If IKE is run over TCP, my interpreation of TCP connection breaking > down, would be the same as UDP connection breaking down, i.e. the IKE > SA is removed. The second paragraph of section 2.4 of the IKEv2 I-D leads me to a totally different interpretation. My interpretation is that the peer that accepted the TCP connection should wait for its peer to connect again, who, in turn should try to re-connect; if both peers can connect to the other (NAT makes this difficult), then both should try to re-connect. Plus timeouts, as per- section 2.4. Also, use of UDP for some parts of IKEv2 appears to be necessary anyways (for NAT-T), so the use of UDP for dead peer detection when TCP connections reset seems quite reasonable (I assume such datagrams would be small enough to avoid fragmentation issues). Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 3 18:58:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22368 for ; Fri, 3 Sep 2004 18:58:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Msu-0007RQ-Ev; Fri, 03 Sep 2004 18:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3MqZ-0006if-84 for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 18:47:55 -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 SAA22028 for ; Fri, 3 Sep 2004 18:47:52 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3MtF-0002yJ-7D for ipsec@ietf.org; Fri, 03 Sep 2004 18:50:42 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i83MlIL02203; Sat, 4 Sep 2004 00:47:19 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i83MlKSj064922; Sat, 4 Sep 2004 00:47:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409032247.i83MlKSj064922@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH In-reply-to: Your message of Fri, 03 Sep 2004 12:45:18 EDT. Date: Sat, 04 Sep 2004 00:47:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: >The flow label in IPv6 is chosen by the source node, and must be delivered >to the ultimate destination without having been changed in transit, unlike >the DSCP or ECN QoS-related fields for IPv6. > >I suggest, since it is constant end-to-end, the field be moved to >"immutable" and protected by AH. We copied the text from 2402, and nobody had noticed the error there in almost 6 years! Good catch. We will change the 2402bis text accordingly. => Please check with the IPv6 WG. BTW this is not an error, the flow label was specified in details only by RFC 3697 (published in Mars). BTW, there is no real need to protect the flow label (look at the RFC 3697 security considerations for attacks based on altered flow labels) and for compatibility with current IPv6/IPsec implementations I *really* prefer we keep the current situation, i.e., flow label field *not* in "immutable". Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 4 11:27:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21968 for ; Sat, 4 Sep 2004 11:27:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3cNS-0007Pb-H1; Sat, 04 Sep 2004 11:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3cMg-0007KN-D7 for ipsec@megatron.ietf.org; Sat, 04 Sep 2004 11:22:06 -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 LAA21650 for ; Sat, 4 Sep 2004 11:22:03 -0400 (EDT) Received: from web8403.mail.in.yahoo.com ([202.43.219.151]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C3cPU-000318-FX for ipsec@ietf.org; Sat, 04 Sep 2004 11:25:02 -0400 Message-ID: <20040904145451.23113.qmail@web8403.mail.in.yahoo.com> Received: from [203.128.1.251] by web8403.mail.in.yahoo.com via HTTP; Sat, 04 Sep 2004 15:54:51 BST Date: Sat, 4 Sep 2004 15:54:51 +0100 (BST) From: =?iso-8859-1?q?khan=20wadood?= To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit Subject: [Ipsec] Confusion regarding "proposal may contain multiple IPSec protocols" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit i have confusion regarding "Each proposal may contain multiple IPsec protocols (where a protocol is IKE, ESP, or AH)" in my view point it should be like "Each proposal contains a protocol(where a protocol is IKE, ESP, or AH)" because you always send IKE_SA and CHILD_SA in separate SA payloads (SAi1, SAi2), so you always send one protocol in SA proposal or proposals. for subsequent CHILD_SA, you would always send one protocol in SA proposal or proposals. if you are sending lets say ESP protocol and AH protocol in the CHILD_SA proposal or proposals, basically you are negotiating two SAs (one for ESP and one for AH) with one SA payload. Conceptually, one SA payload should represent a Security Association either for IKE or ESP or AH. otherwise my previous point of view that in first SA payload (SAi1) why dont we send proposals having protocols IKE and ESP or AH respectively. any comments would be highly appreciated. wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 04:04:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12214 for ; Mon, 6 Sep 2004 04:04:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EPx-00056s-Ko; Mon, 06 Sep 2004 04:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EOo-0004mC-LY for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 03:58:53 -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 DAA11221 for ; Mon, 6 Sep 2004 03:58:39 -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 1C4ERn-00014z-Ft for ipsec@ietf.org; Mon, 06 Sep 2004 04:01:59 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i867sFd22857 for ; Mon, 6 Sep 2004 03:54:15 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i867tasR023580 for ; Mon, 6 Sep 2004 03:55:36 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMnaicU; Mon, 6 Sep 04 03:55:32 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i867wFln015277 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 10:58:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i867w99k015274; Mon, 6 Sep 2004 10:58:09 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.6289.329407.577751@fireball.kivinen.iki.fi> Date: Mon, 6 Sep 2004 10:58:09 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Michael Richardson , Paul Koning , Nicolas Williams , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > No. At the end of the initial negotiation, the TCP connection is > terminated and the SA remains. Further child SAs will be negotiated in > new TCP connections or using UDP packets. (or SCTP if we write support > for that too) That is one way to do it, but I have to say that it is not efficient or obvious way to do it. This means that for each informational message your are sending, or when creating new child SAs, you suddenly have to do the TCP connection setup again, which doubles the number of round trips needed etc. There are multiple ways of doing the TCP transport stuff, and as we do not have the spec for it, there is no point of arguing about how the nonexiting IKE over TCP works. If we want we can start arguing about how it should be done, what are the good and bad things with each proposal. > The SA is not bound to any message passing mechanism. I would disagree with that design choice. In the IKEv2 we did try to tighten up the binding between IKEv2 SA and IPsec SA, and I would see it completely appropriate to follow the same design choice here, i.e. bind the transport mechanism connection and IKE SA together. It does take care of lots of corner cases and simplifies the things. The another approach where the IKE SA and transport mechanism connection would not be tied together would be more like IKEv1 way of do it. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 04:10:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12608 for ; Mon, 6 Sep 2004 04:10:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EWu-000682-49; Mon, 06 Sep 2004 04:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EVG-0005gI-GX for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 04:05:30 -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 EAA12259 for ; Mon, 6 Sep 2004 04:05:28 -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 1C4EYR-0001Nd-E0 for ipsec@ietf.org; Mon, 06 Sep 2004 04:08:48 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i86819d24397 for ; Mon, 6 Sep 2004 04:01:09 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8682VDB024704 for ; Mon, 6 Sep 2004 04:02:31 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAApIaanW; Mon, 6 Sep 04 04:02:27 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8685IJg015420 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 11:05:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8685HYw015417; Mon, 6 Sep 2004 11:05:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.6717.487638.23566@fireball.kivinen.iki.fi> Date: Mon, 6 Sep 2004 11:05:17 +0300 From: Tero Kivinen To: Nicolas Williams Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: <20040903175254.GM1989@binky.central.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903175254.GM1989@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Williams writes: > Is NAT-T more difficult if IKEv2 is run over TCP? Not really, but the performance of the TCP over TCP is very bad, unless the IPsec would do something like retransmit detection and filtering etc. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 04:29:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13700 for ; Mon, 6 Sep 2004 04:29:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Epj-0001yi-Au; Mon, 06 Sep 2004 04:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4EjA-0007Vq-Dc for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 04:19:52 -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 EAA13302 for ; Mon, 6 Sep 2004 04:19:50 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4EmM-0001f8-CP for ipsec@ietf.org; Mon, 06 Sep 2004 04:23:10 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i868JfWr015525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 11:19:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i868JfrL015518; Mon, 6 Sep 2004 11:19:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.7581.273977.258982@fireball.kivinen.iki.fi> Date: Mon, 6 Sep 2004 11:19:41 +0300 From: Tero Kivinen To: =?iso-8859-1?q?khan=20wadood?= Subject: [Ipsec] Confusion regarding "proposal may contain multiple IPSec protocols" In-Reply-To: <20040904145451.23113.qmail@web8403.mail.in.yahoo.com> References: <20040904145451.23113.qmail@web8403.mail.in.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit khan wadood writes: > i have confusion regarding > > "Each proposal may contain multiple IPsec protocols > (where a protocol is IKE, ESP, or AH)" > > in my view point it should be like > > "Each proposal contains a protocol(where a protocol is > IKE, ESP, or AH)" Yes, with current RFC2401bis it also could be that. For the later extensiuons, that might not be true anymore. > if you are sending lets say ESP protocol and AH > protocol in the CHILD_SA proposal or proposals, > basically you are negotiating two SAs (one for ESP and > one for AH) with one SA payload. Yes, according to RFC2401bis. So if you plan to support RFC2401bis architecture only, you do not have any need for support for multiple protocols, and you can reject all those proposals having multiple protocols (i.e. you must know how to skip them, and do not select them). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 04:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14638 for ; Mon, 6 Sep 2004 04:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4F3I-0000Gl-CR; Mon, 06 Sep 2004 04:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4F11-0008Nr-Rh for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 04:38:22 -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 EAA14211 for ; Mon, 6 Sep 2004 04:38:17 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4F4D-0001vx-CB for ipsec@ietf.org; Mon, 06 Sep 2004 04:41:38 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i868cGRd015809 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 11:38:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i868cCpw015806; Mon, 6 Sep 2004 11:38:12 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.8692.464310.679681@fireball.kivinen.iki.fi> Date: Mon, 6 Sep 2004 11:38:12 +0300 From: Tero Kivinen To: Thomas Narten Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: <200409031529.i83FTg8C003971@rotala.raleigh.ibm.com> References: <16696.16930.850706.258383@fireball.kivinen.iki.fi> <200409031529.i83FTg8C003971@rotala.raleigh.ibm.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Thomas Narten writes: > Um, aren't IKE and IPsec for communication between random hosts? True, > most deployment to date has been VPNs. But are we resigning ourselves > to that scenario forever? I hope not. I do not think we are planning only for VPNs. We should have options also for other uses too. > I agree with this, but do not agree that this implies that whoever is > in charge of setting up the trust relationships is in a position to > know (or ensure) that all the possible IKE participants will accept > adequately large payloads beyound those _required_ (in the MUST sense) > by the spec. Then they assume 1280, and that is fine also. > Note: my real concern is that SHOULD is not strong enough. If it is > not a MUST requirement that 3000 bytes (or whatever the right minimum > lower bound is) be supported, we will eventually, once there is > widespread deployment of IKE, run into a deployed base where some > implementations only support the required minimum. At that point, > implementations will (for interoperability) have to assume that the > 3000 byte SHOULD is not universally implemented, and use the real > lower bound (e.g., 1280). For those people who will implement the stuff over operating system UDP stack, adding support for 3000 byte packets will be 3-bit change in their source code (i.e. change unsigned char udp_read_buffer[1280] to unsigned char udp_read_buffer[3000] :-). This means that if we have that bigger number as SHOULD all those implementors will simply use the 3000 bytes, and forget the who thing. If we do not have any SHOULD number in the RFC, they will start thinking (bad thing you know), and they end up having random number between 1280 and 64k, with distribution where you have about 40% using 1280, and 20% using 64k, and rest of the 40% use values 1500/2048/3000/4096/8192. Effectively the SHOULD will most likely limit implementations so that almost none does more than 3000 bytes... > If the WG feels that 1280 is really an adequate number to assume in > the general case, I'm fine with that. Good. > My point is that the SHOULD recommendation is probably less useful > than might seem. I think the SHOULD do have good reasons to be there, as it will be hard number for implementors. And we can benefit from that number when we defined the extension telling that number to the other end. > If this will eventually be needed, now is the time to do it, before > there is a deployed base. It is the deployed base (which won't > implement this) that will be the problem in the future (if it becomes > a problem). The extension would be quite easy. I think we do not want to add it to the IKEv2 spec at this point, but create separate extension about this. On the other hand if you feel that we should do it now to resolve the max UDP packet size problems, then we can still do it if IESG and area directors approve the change. The text could be something like: ---------------------------------------------------------------------- ... NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- ... MAX_UDP_IKE_PACKET XXXXX This notification asserts that the sending endpoint is capable of receiving UDP packets up to given size. The data associated with a MAX_UDP_IKE_PACKET notification MUST be 4 octets long and contain the big endian representation of the max UDP IKE packet size (i.e. size without IP or UDP headers) the sender promises to be able to receive. This notification SHOULD be sent inside the IKE_SA_INIT exchange so the initiator can use the bigger packet size when sending the IKE_AUTH exchange containing certificates. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 05:13:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16155 for ; Mon, 6 Sep 2004 05:13:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4FTQ-0005CA-Kk; Mon, 06 Sep 2004 05:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4FM9-0003sB-8M for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 05:00:09 -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 FAA15453 for ; Mon, 6 Sep 2004 05:00:07 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4FPK-0002Ih-D9 for ipsec@ietf.org; Mon, 06 Sep 2004 05:03:28 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i868xMng015975 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 11:59:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i868xJqm015972; Mon, 6 Sep 2004 11:59:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.9959.69134.638189@fireball.kivinen.iki.fi> Date: Mon, 6 Sep 2004 11:59:19 +0300 From: Tero Kivinen To: "Charlie Kaufman" Subject: RE: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 20 min X-Total-Time: 21 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, jis@mit.edu, byfraser@cisco.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Charlie Kaufman writes: > IKEv2 was specifically designed so that it would maintain most of its > security properties even if its encryption algorithm were broken (or > NULL). Yes, identities and traffic selectors would be exposed. But the > key derivation and authentication would still be secure. It would be > entirely appropriate to use ENCR_NULL in IKE if AH was being negotiated > or ENCR_NULL were being negotiated in the underlying ESP. I think the security considerations section do assume we use encryption: "While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers...". > Similarly, if IKE negotiated NONE as its integrity protection algorithm, > the subsequently negotiated ESP and AH SAs would still be secure (though > the protocol would be exposed to some "downgrade" attacks if the > endpoints were not both properly configured. Hmmm... at least we need strong comments to the security considerations section. Also even when IKEv2 base SKEYSEED is protected even when there is no encryption or authentication on the IKEv2, it does not mean that all extensions done later are safe. For example you easily cause denial of service, by just sending one Delete notification to the other end killing the IKE_SA etc, or you can create new IPsec SAs at will (you do not know the key, but you can cause resource exchaustion on the other end etc). > So I don't believe these should be ruled out in the IKEv2 specification > itself. I think we should rule them out. It will be much simplier for everybody if we say that there will be encryption and authentication on the packets. I do not see any reason why we should allow such thing in the base IKEv2 spec. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 6 13:25:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19426 for ; Mon, 6 Sep 2004 13:25:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4NCA-0005Vn-Uu; Mon, 06 Sep 2004 13:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4N6n-0004sq-Vj for ipsec@megatron.ietf.org; Mon, 06 Sep 2004 13:16:50 -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 NAA18676 for ; Mon, 6 Sep 2004 13:16:44 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca ([205.150.200.161] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4NA2-0001nP-B3 for ipsec@ietf.org; Mon, 06 Sep 2004 13:20:10 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i86HGef27783 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 6 Sep 2004 13:16:41 -0400 (EDT) Received: from sandelman.ottawa.on.ca (wlan232.sandelman.ca [205.150.200.232]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i86HMsN24866 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 6 Sep 2004 13:22:55 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i86HFJHn022278; Mon, 6 Sep 2004 13:15:19 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i86HFHmn022273; Mon, 6 Sep 2004 13:15:18 -0400 To: Tero Kivinen Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: Message from Tero Kivinen of "Fri, 03 Sep 2004 13:06:26 +0300." <16696.16930.850706.258383@fireball.kivinen.iki.fi> References: <6.1.1.1.2.20040902122036.055e4b58@mail.binhost.com> <16696.16930.850706.258383@fireball.kivinen.iki.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Sep 2004 13:15:17 -0400 Message-ID: <22272.1094490917@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Thomas Narten , ipsec@ietf.org, margaret@thingmagic.com, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> With IPsec that is not normally the case. You need to have Tero> some kind of trust relationship between the hosts to get IKEv2 Tero> working, i.e. you need common CA, or shared secrets exchange Tero> priori etc. In most of the cases you also need to agree about Tero> the policy to be used and so on. Warning: VPN centric view! Multiple people do take the view that there are situations where the end points are not part of the same enterprise. Not just Opportunistic Encryption, but other views as well. Tero> If the adminstrator is going to be putting up a road-warrior Tero> VPN system for the company, and they enroll their own CA with Tero> 2048 bit keys, and 2 level hierarchy, which would mean that it Tero> does not fit to the 1280 byte packets, then can always say Tero> that we only support those implementations which supports this Tero> 3000 bytes packets. In normal case they will only support one Tero> implementation for the client end and one implementation (or Tero> same implementation) for the SGW end, so this is not really a Tero> problem. They simply need to select the implementations so Tero> that it supports that feature (and configure them so). I agree with you that this is something which can be locally provisioned for the VPN scenario. I do not think that this is something that I want customers to have to worry about. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQTybJIqHRg3pndX9AQE+fgP/e17RjH10VgxEn2bbgWEAqT4FQENcsoRB 6SkoxdHgqTHaqHT8H+eWr3gPXvAuaqOKEY0wFGnHwOzw8J2CiGvkIFooJboQBWkM ONdwPu2v+RFeKEUwlGXDREQQCHVPigd3M6WrmBjRnoWBgRN4T+vNK3vC6EYc9CQJ yt3xyWpl0ks= =mIyZ -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 00:39:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00084 for ; Tue, 7 Sep 2004 00:39:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Xi9-0005u1-Cj; Tue, 07 Sep 2004 00:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4XhX-0005mN-Qy for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 00:35:28 -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 AAA29872 for ; Tue, 7 Sep 2004 00:35:24 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Xku-00033W-C0 for ipsec@ietf.org; Tue, 07 Sep 2004 00:38:57 -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 i874V1d27592 for ; Tue, 7 Sep 2004 00:31:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i874WOUD021208 for ; Tue, 7 Sep 2004 00:32:24 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3DaWyP; Tue, 7 Sep 04 00:32:20 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i874ZF35029010 for ; Mon, 6 Sep 2004 21:35:15 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i874ZDJl003744 for ; Mon, 6 Sep 2004 22:35:15 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i874WE87017945; Mon, 6 Sep 2004 23:32:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i874WCdg017944; Mon, 6 Sep 2004 23:32:12 -0500 (CDT) Date: Mon, 6 Sep 2004 23:32:12 -0500 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040907043212.GB1989@binky.central.sun.com> Mail-Followup-To: Tero Kivinen , Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com, Michael Richardson , ipsec@lists.tislabs.com References: <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903175254.GM1989@binky.central.sun.com> <16700.6717.487638.23566@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16700.6717.487638.23566@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, Sep 06, 2004 at 11:05:17AM +0300, Tero Kivinen wrote: > Nicolas Williams writes: > > Is NAT-T more difficult if IKEv2 is run over TCP? > > Not really, but the performance of the TCP over TCP is very bad, > unless the IPsec would do something like retransmit detection and > filtering etc. We're talking about running IKEv2 over TCP, not encapsulating ESP/AH in TCP. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 00:50:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00963 for ; Tue, 7 Sep 2004 00:50:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Xrt-0007Vz-PC; Tue, 07 Sep 2004 00:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Xoe-0006p7-CJ for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 00:42:49 -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 AAA00383 for ; Tue, 7 Sep 2004 00:42:45 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Xs0-0003Bs-58 for ipsec@ietf.org; Tue, 07 Sep 2004 00:46:17 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i874cPd28714 for ; Tue, 7 Sep 2004 00:38:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i874dm77022514 for ; Tue, 7 Sep 2004 00:39:48 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAw2ai8R; Tue, 7 Sep 04 00:39:44 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i874gd35000712 for ; Mon, 6 Sep 2004 21:42:39 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i874gbJl005195 for ; Mon, 6 Sep 2004 22:42:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i874ddDi017952; Mon, 6 Sep 2004 23:39:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i874ddcT017951; Mon, 6 Sep 2004 23:39:39 -0500 (CDT) Date: Mon, 6 Sep 2004 23:39:39 -0500 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040907043938.GC1989@binky.central.sun.com> Mail-Followup-To: Tero Kivinen , Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com, Michael Richardson , ipsec@lists.tislabs.com References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <16700.6289.329407.577751@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16700.6289.329407.577751@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, Sep 06, 2004 at 10:58:09AM +0300, Tero Kivinen wrote: > Yoav Nir writes: > > No. At the end of the initial negotiation, the TCP connection is > > terminated and the SA remains. Further child SAs will be negotiated in > > new TCP connections or using UDP packets. (or SCTP if we write support > > for that too) > > That is one way to do it, but I have to say that it is not efficient > or obvious way to do it. This means that for each informational > message your are sending, or when creating new child SAs, you suddenly > have to do the TCP connection setup again, which doubles the number of > round trips needed etc. I wouldn't necessarily have IKEv2 do one TCP connection per-transaction, but I'd have IKEv2 reconnect if the TCP connection is reset of if there's timeouts, very much in the spirit of section 2.4 of the IKEv2 I-D. > There are multiple ways of doing the TCP transport stuff, and as we do > not have the spec for it, there is no point of arguing about how the > nonexiting IKE over TCP works. Section 2.4 of the IKEv2 I-D provides the guidance, I think, for how to run IKEv2 over TCP. > If we want we can start arguing about how it should be done, what are > the good and bad things with each proposal. > > > The SA is not bound to any message passing mechanism. > > I would disagree with that design choice. In the IKEv2 we did try to > tighten up the binding between IKEv2 SA and IPsec SA, and I would see > it completely appropriate to follow the same design choice here, i.e. > bind the transport mechanism connection and IKE SA together. It does > take care of lots of corner cases and simplifies the things. But this wasn't done with UDP as the IKEv2 transport... Why? Because UDP is connectionless. Since the reason for proposing IKEv2 over TCP in the first place has nothing to do with TCP being connection-oriented but everything to do with PMTUs and NAT traversal I don't see why one would then want to make this leap and desire to tie IKE_SAs and their children to indicidual TCP connections -- that just does not follow. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 01:17:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02771 for ; Tue, 7 Sep 2004 01:17:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4YGS-0003M8-6m; Tue, 07 Sep 2004 01:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4YEb-0002c1-RM; Tue, 07 Sep 2004 01:09:37 -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 BAA02307; Tue, 7 Sep 2004 01:09:36 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4YHy-0003gJ-3A; Tue, 07 Sep 2004 01:13:07 -0400 Received: from [192.168.123.143] (lsanca1-ar42-4-61-160-010.lsanca1.dsl-verizon.net [4.61.160.10]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8758QJ24254; Mon, 6 Sep 2004 22:08:26 -0700 (PDT) Message-ID: <413D4254.9090306@isi.edu> Date: Mon, 06 Sep 2004 22:08:36 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org, saag@mit.edu, ipsec@ietf.org X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ipsec] new mailing list for ANONSEC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0036366605==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0036366605== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E43994799415EF9C24CEF75" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E43994799415EF9C24CEF75 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, To follow-up on related presentations at both SAAG and TCPM, we've created a mailing list for discussions of anonymous security. Further information on the list and how to join it, as well as pointers to related resources can be found at: http://www.postel.org/anonsec The mailing list address is: anonsec@postel.org Joe --------------enig6E43994799415EF9C24CEF75 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBPUJUE5f5cImnZrsRAg/BAJ4qvLQo52bA2R6E3ZCf2GzhWHflRACfYVun Dq+ihbZD5H10xkOjRpuH7v4= =HOQx -----END PGP SIGNATURE----- --------------enig6E43994799415EF9C24CEF75-- --===============0036366605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0036366605==-- From ipsec-bounces@ietf.org Tue Sep 7 01:41:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04136 for ; Tue, 7 Sep 2004 01:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4YfB-00079E-CV; Tue, 07 Sep 2004 01:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Yew-00072Z-3c for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 01:36:50 -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 BAA03831 for ; Tue, 7 Sep 2004 01:36:48 -0400 (EDT) Received: from [202.125.80.82] (helo=brahma.roc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4YiH-000451-DG for ipsec@ietf.org; Tue, 07 Sep 2004 01:40:19 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA12772; Tue, 7 Sep 2004 11:36:57 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA12765; Tue, 7 Sep 2004 11:36:54 +0530 Message-ID: <413D48DF.3010501@rocsys.com> Date: Tue, 07 Sep 2004 11:06:31 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec@ietf.org Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I agree with Thomos. SHOULD is not strong enough. I also feel that, introducing notification message to indicate the capability of Maximum size it can receive is also not good enough. What can sender do if that happens, other than logging this? Run IKE over TCP Or use HASH & URL? Unfortunatley, both are 'MAY'. In my opinion, mandating 3000 bytes, if IKE implements certificates will solve most of deployment problems. By doing this, all implementations are forced to make the change. Regards Ravi ----- Original Message ----- From: "Tero Kivinen" To: "Thomas Narten" Cc: ; ; "Russ Housley" Sent: Monday, September 06, 2004 1:38 AM Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG > Thomas Narten writes: > > Um, aren't IKE and IPsec for communication between random hosts? True, > > most deployment to date has been VPNs. But are we resigning ourselves > > to that scenario forever? I hope not. > > I do not think we are planning only for VPNs. We should have options > also for other uses too. > > > I agree with this, but do not agree that this implies that whoever is > > in charge of setting up the trust relationships is in a position to > > know (or ensure) that all the possible IKE participants will accept > > adequately large payloads beyound those _required_ (in the MUST sense) > > by the spec. > > Then they assume 1280, and that is fine also. > > > Note: my real concern is that SHOULD is not strong enough. If it is > > not a MUST requirement that 3000 bytes (or whatever the right minimum > > lower bound is) be supported, we will eventually, once there is > > widespread deployment of IKE, run into a deployed base where some > > implementations only support the required minimum. At that point, > > implementations will (for interoperability) have to assume that the > > 3000 byte SHOULD is not universally implemented, and use the real > > lower bound (e.g., 1280). > > For those people who will implement the stuff over operating system > UDP stack, adding support for 3000 byte packets will be 3-bit change > in their source code (i.e. change unsigned char udp_read_buffer[1280] > to unsigned char udp_read_buffer[3000] :-). This means that if we have > that bigger number as SHOULD all those implementors will simply use > the 3000 bytes, and forget the who thing. If we do not have any SHOULD > number in the RFC, they will start thinking (bad thing you know), and > they end up having random number between 1280 and 64k, with > distribution where you have about 40% using 1280, and 20% using 64k, > and rest of the 40% use values 1500/2048/3000/4096/8192. > > Effectively the SHOULD will most likely limit implementations so that > almost none does more than 3000 bytes... > > > If the WG feels that 1280 is really an adequate number to assume in > > the general case, I'm fine with that. > > Good. > > > My point is that the SHOULD recommendation is probably less useful > > than might seem. > > I think the SHOULD do have good reasons to be there, as it will be > hard number for implementors. And we can benefit from that number when > we defined the extension telling that number to the other end. > > > If this will eventually be needed, now is the time to do it, before > > there is a deployed base. It is the deployed base (which won't > > implement this) that will be the problem in the future (if it becomes > > a problem). > > The extension would be quite easy. I think we do not want to add it to > the IKEv2 spec at this point, but create separate extension about > this. On the other hand if you feel that we should do it now to > resolve the max UDP packet size problems, then we can still do it if > IESG and area directors approve the change. > > The text could be something like: > ---------------------------------------------------------------------- > ... > NOTIFY MESSAGES - STATUS TYPES Value > ------------------------------ ----- > ... > MAX_UDP_IKE_PACKET XXXXX > > This notification asserts that the sending endpoint is > capable of receiving UDP packets up to given size. The > data associated with a MAX_UDP_IKE_PACKET notification > MUST be 4 octets long and contain the big endian > representation of the max UDP IKE packet size (i.e. size > without IP or UDP headers) the sender promises to be able > to receive. This notification SHOULD be sent inside the > IKE_SA_INIT exchange so the initiator can use the bigger > packet size when sending the IKE_AUTH exchange containing > certificates. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 01:44:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04598 for ; Tue, 7 Sep 2004 01:44:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Yg6-0007GK-7a; Tue, 07 Sep 2004 01:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Yf6-00077s-PN for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 01:37:00 -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 BAA03836 for ; Tue, 7 Sep 2004 01:36:59 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4YiU-00045K-9X for ipsec@ietf.org; Tue, 07 Sep 2004 01:40:30 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i875Wed06022 for ; Tue, 7 Sep 2004 01:32:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i875Y2Qi002028 for ; Tue, 7 Sep 2004 01:34:02 -0400 (EDT) Received: from unknown(202.125.80.82) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnnaq8d; Tue, 7 Sep 04 01:33:58 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA12772; Tue, 7 Sep 2004 11:36:57 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA12765; Tue, 7 Sep 2004 11:36:54 +0530 Message-ID: <413D48DF.3010501@rocsys.com> Date: Tue, 07 Sep 2004 11:06:31 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec@ietf.org Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I agree with Thomos. SHOULD is not strong enough. I also feel that, introducing notification message to indicate the capability of Maximum size it can receive is also not good enough. What can sender do if that happens, other than logging this? Run IKE over TCP Or use HASH & URL? Unfortunatley, both are 'MAY'. In my opinion, mandating 3000 bytes, if IKE implements certificates will solve most of deployment problems. By doing this, all implementations are forced to make the change. Regards Ravi ----- Original Message ----- From: "Tero Kivinen" To: "Thomas Narten" Cc: ; ; "Russ Housley" Sent: Monday, September 06, 2004 1:38 AM Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG > Thomas Narten writes: > > Um, aren't IKE and IPsec for communication between random hosts? True, > > most deployment to date has been VPNs. But are we resigning ourselves > > to that scenario forever? I hope not. > > I do not think we are planning only for VPNs. We should have options > also for other uses too. > > > I agree with this, but do not agree that this implies that whoever is > > in charge of setting up the trust relationships is in a position to > > know (or ensure) that all the possible IKE participants will accept > > adequately large payloads beyound those _required_ (in the MUST sense) > > by the spec. > > Then they assume 1280, and that is fine also. > > > Note: my real concern is that SHOULD is not strong enough. If it is > > not a MUST requirement that 3000 bytes (or whatever the right minimum > > lower bound is) be supported, we will eventually, once there is > > widespread deployment of IKE, run into a deployed base where some > > implementations only support the required minimum. At that point, > > implementations will (for interoperability) have to assume that the > > 3000 byte SHOULD is not universally implemented, and use the real > > lower bound (e.g., 1280). > > For those people who will implement the stuff over operating system > UDP stack, adding support for 3000 byte packets will be 3-bit change > in their source code (i.e. change unsigned char udp_read_buffer[1280] > to unsigned char udp_read_buffer[3000] :-). This means that if we have > that bigger number as SHOULD all those implementors will simply use > the 3000 bytes, and forget the who thing. If we do not have any SHOULD > number in the RFC, they will start thinking (bad thing you know), and > they end up having random number between 1280 and 64k, with > distribution where you have about 40% using 1280, and 20% using 64k, > and rest of the 40% use values 1500/2048/3000/4096/8192. > > Effectively the SHOULD will most likely limit implementations so that > almost none does more than 3000 bytes... > > > If the WG feels that 1280 is really an adequate number to assume in > > the general case, I'm fine with that. > > Good. > > > My point is that the SHOULD recommendation is probably less useful > > than might seem. > > I think the SHOULD do have good reasons to be there, as it will be > hard number for implementors. And we can benefit from that number when > we defined the extension telling that number to the other end. > > > If this will eventually be needed, now is the time to do it, before > > there is a deployed base. It is the deployed base (which won't > > implement this) that will be the problem in the future (if it becomes > > a problem). > > The extension would be quite easy. I think we do not want to add it to > the IKEv2 spec at this point, but create separate extension about > this. On the other hand if you feel that we should do it now to > resolve the max UDP packet size problems, then we can still do it if > IESG and area directors approve the change. > > The text could be something like: > ---------------------------------------------------------------------- > ... > NOTIFY MESSAGES - STATUS TYPES Value > ------------------------------ ----- > ... > MAX_UDP_IKE_PACKET XXXXX > > This notification asserts that the sending endpoint is > capable of receiving UDP packets up to given size. The > data associated with a MAX_UDP_IKE_PACKET notification > MUST be 4 octets long and contain the big endian > representation of the max UDP IKE packet size (i.e. size > without IP or UDP headers) the sender promises to be able > to receive. This notification SHOULD be sent inside the > IKE_SA_INIT exchange so the initiator can use the bigger > packet size when sending the IKE_AUTH exchange containing > certificates. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 03:02:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23812 for ; Tue, 7 Sep 2004 03:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ZwW-0001yg-CB; Tue, 07 Sep 2004 02:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Ztt-0001ci-9c for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 02:56:21 -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 CAA23380 for ; Tue, 7 Sep 2004 02:56:19 -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 1C4ZxG-0005Oz-Jm for ipsec@ietf.org; Tue, 07 Sep 2004 02:59:51 -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 i876pud17372 for ; Tue, 7 Sep 2004 02:51:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i876rIsn017447 for ; Tue, 7 Sep 2004 02:53:18 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe4aqTH; Tue, 7 Sep 04 02:52:35 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i876tF104997; Tue, 7 Sep 2004 09:55:15 +0300 (IDT) Message-Id: <200409070655.i876tF104997@michael.checkpoint.com> From: "Yoav Nir" To: "'Nicolas Williams'" , "'Tero Kivinen'" Subject: RE: [Pki4ipsec] Re: [Ipsec] big IKE packets Date: Tue, 7 Sep 2004 09:55:08 +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: AcSUljGE2Z24LcbUQcSZTYM+Fk4B1QAD5pTw In-Reply-To: <20040907043938.GC1989@binky.central.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, "'Michael Richardson'" , "'Paul Koning'" , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The way I see it, the reason for proposing IKE over TCP is that TCP can pass arbitrary-length messages reliably a lot better than UDP. This capability is needed for the initial exchange, but not so much for informational and child-sa exchanges. Also, it is not good behavior to keep an idle TCP connection for extended periods, because otherwise you might have a shortage of sockets. Any server, including and IKEoTCP server should close the connection if it is idle for more than several seconds. If I were writing a draft for IKEv2 over TCP, I would say that any supporting implementation: - MUST be able to do initial exchanges over TCP - MAY be able to be the initiator of non-initial exchanges over TCP - MUST be able to be the responder of non-initial exchanges over TCP - MUST be able to do non-initial exchanges based on an SA created with TCP, over UDP. - SHOULD close a TCP connection when it has no more SAs to negotiate. - SHOULD close a TCP connection if it has been idle for 60 seconds. I would also say a peer is dead only if it cannot be reached with UDP, and that once an exchange is complete, the resulting SA is valid regardless of the transport, and regardless of whether or not the connection is still valid. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Nicolas Williams Sent: Tuesday, September 07, 2004 7:40 AM To: Tero Kivinen Cc: Michael Richardson; ipsec@lists.tislabs.com; Yoav Nir; Paul Koning; pki4ipsec@honor.icsalabs.com Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets On Mon, Sep 06, 2004 at 10:58:09AM +0300, Tero Kivinen wrote: > Yoav Nir writes: > > No. At the end of the initial negotiation, the TCP connection is > > terminated and the SA remains. Further child SAs will be negotiated in > > new TCP connections or using UDP packets. (or SCTP if we write support > > for that too) > > That is one way to do it, but I have to say that it is not efficient > or obvious way to do it. This means that for each informational > message your are sending, or when creating new child SAs, you suddenly > have to do the TCP connection setup again, which doubles the number of > round trips needed etc. I wouldn't necessarily have IKEv2 do one TCP connection per-transaction, but I'd have IKEv2 reconnect if the TCP connection is reset of if there's timeouts, very much in the spirit of section 2.4 of the IKEv2 I-D. > There are multiple ways of doing the TCP transport stuff, and as we do > not have the spec for it, there is no point of arguing about how the > nonexiting IKE over TCP works. Section 2.4 of the IKEv2 I-D provides the guidance, I think, for how to run IKEv2 over TCP. > If we want we can start arguing about how it should be done, what are > the good and bad things with each proposal. > > > The SA is not bound to any message passing mechanism. > > I would disagree with that design choice. In the IKEv2 we did try to > tighten up the binding between IKEv2 SA and IPsec SA, and I would see > it completely appropriate to follow the same design choice here, i.e. > bind the transport mechanism connection and IKE SA together. It does > take care of lots of corner cases and simplifies the things. But this wasn't done with UDP as the IKEv2 transport... Why? Because UDP is connectionless. Since the reason for proposing IKEv2 over TCP in the first place has nothing to do with TCP being connection-oriented but everything to do with PMTUs and NAT traversal I don't see why one would then want to make this leap and desire to tie IKE_SAs and their children to indicidual TCP connections -- that just does not follow. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 04:46:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01279 for ; Tue, 7 Sep 2004 04:46:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bZE-00082j-LD; Tue, 07 Sep 2004 04:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bTk-0007B0-Ti for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 04:37:33 -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 EAA00497 for ; Tue, 7 Sep 2004 04:37:26 -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 1C4bX7-0007Y6-Ij for ipsec@ietf.org; Tue, 07 Sep 2004 04:41:00 -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 i878Wwd04273 for ; Tue, 7 Sep 2004 04:32:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i878YLaN009544 for ; Tue, 7 Sep 2004 04:34:21 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_LaOLs; Tue, 7 Sep 04 04:34:17 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i878ZVFB002213 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 11:35:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i878ZKcL002209; Tue, 7 Sep 2004 11:35:20 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.29384.240105.749155@fireball.kivinen.iki.fi> Date: Tue, 7 Sep 2004 11:35:20 +0300 From: Tero Kivinen To: Nicolas Williams Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: <20040907043212.GB1989@binky.central.sun.com> References: <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903175254.GM1989@binky.central.sun.com> <16700.6717.487638.23566@fireball.kivinen.iki.fi> <20040907043212.GB1989@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Williams writes: > On Mon, Sep 06, 2004 at 11:05:17AM +0300, Tero Kivinen wrote: > > Nicolas Williams writes: > > > Is NAT-T more difficult if IKEv2 is run over TCP? > > > > Not really, but the performance of the TCP over TCP is very bad, > > unless the IPsec would do something like retransmit detection and > > filtering etc. > > We're talking about running IKEv2 over TCP, not encapsulating ESP/AH in > TCP. Nope. Someone was asking if NAT-T is more difficult if IKEv2 is running over TCP. As in NAT-T the ESP uses same channel than IKE packets, it means that those packet will also run over TCP, thus TCP over TCP performance is issue here. Of course you could define new NAT-T which would use different channel for ESP and IKE, but that was not the question. ---------------------------------------------------------------------- 2.23 NAT Traversal ... The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE_SA over UDP port 4500. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 05:06:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02552 for ; Tue, 7 Sep 2004 05:06:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4brB-0002Iw-2E; Tue, 07 Sep 2004 05:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bil-000165-Ju for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 04:53:00 -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 EAA01764 for ; Tue, 7 Sep 2004 04:52:57 -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 1C4bmA-0007rK-MT for ipsec@ietf.org; Tue, 07 Sep 2004 04:56:31 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i878mbd07445 for ; Tue, 7 Sep 2004 04:48:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i878o1EQ012406 for ; Tue, 7 Sep 2004 04:50:01 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvvaGoy; Tue, 7 Sep 04 04:49:58 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i878pZl1002322 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 11:51:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i878pYCm002319; Tue, 7 Sep 2004 11:51:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.30358.461938.103837@fireball.kivinen.iki.fi> Date: Tue, 7 Sep 2004 11:51:34 +0300 From: Tero Kivinen To: Nicolas Williams Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: <20040907043938.GC1989@binky.central.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <16700.6289.329407.577751@fireball.kivinen.iki.fi> <20040907043938.GC1989@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 15 min X-Total-Time: 15 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Williams writes: > I wouldn't necessarily have IKEv2 do one TCP connection per-transaction, > but I'd have IKEv2 reconnect if the TCP connection is reset of if > there's timeouts, very much in the spirit of section 2.4 of the IKEv2 > I-D. After rereading the section 2.4 once again, I disagree about your interpretation of the section 2.4. > Section 2.4 of the IKEv2 I-D provides the guidance, I think, for how to > run IKEv2 over TCP. Nope. It does not say a single word about TCP. Trying to interpret text written in UDP context in the TCP context can give very different results. > But this wasn't done with UDP as the IKEv2 transport... Why? Because > UDP is connectionless. If my UDP socket would suddenly disappears because of the operating system is running out of the resources, I would be going to interpret it as a connection loss, and delete IKE SA (i.e. if the OS decides that it will not be forwarding any packets to that UDP port to me anymore). Of course I do not know any way in the normal socket interface where I could that information but... > Since the reason for proposing IKEv2 over TCP in the first place has > nothing to do with TCP being connection-oriented but everything to > do with PMTUs and NAT traversal I don't see why one would then want > to make this leap and desire to tie IKE_SAs and their children to > indicidual TCP connections -- that just does not follow. It is little bit hard to talk about protocol which is not defined anywhere, and which people have different idea how to design it. As I said earlier this discussion is in completely wrong level. We might start talking about the design choices of the running IKEv2 over TCP (i.e. whether to create one TCP connection and tie it to the IKE SA, or create TCP session per request reply or create TCP session once, but recreate it if it breaks etc). But I think that discussion is now quite pointless as we do not think we are going to define IKEv2 over TCP now. Anyways trying to interpret the IKEv2 text written in UDP context in TCP context is not very usefull, and especially if we start making modifications to the way the protocol works in the same time, without defining those. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 05:13:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03156 for ; Tue, 7 Sep 2004 05:13:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bwa-0003bv-0g; Tue, 07 Sep 2004 05:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4buy-00034v-G1 for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 05:05:36 -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 FAA02494 for ; Tue, 7 Sep 2004 05:05:34 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4byN-00086U-NY for ipsec@ietf.org; Tue, 07 Sep 2004 05:09:08 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8795QT3002528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 12:05:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8795LF9002525; Tue, 7 Sep 2004 12:05:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.31185.456226.175045@fireball.kivinen.iki.fi> Date: Tue, 7 Sep 2004 12:05:21 +0300 From: Tero Kivinen To: Ravi Kumar Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: <413D48DF.3010501@rocsys.com> References: <413D48DF.3010501@rocsys.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Ravi Kumar writes: > Hi, > I agree with Thomos. SHOULD is not strong enough. > I also feel that, introducing notification message to > indicate the capability of Maximum size it can receive is > also not good enough. What can sender do if that happens, > other than logging this? Run IKE over TCP Or use HASH & URL? > Unfortunatley, both are 'MAY'. TCP is not MAY, it is not defined. HASH & URL is MUST. So it can also simply leave out certificates and send HASH and URL instead, and assume that the other end will either get those certificates from there, or then the authentication will fail. Note, that 1280 bytes is enough for sending the normal end user certificate, so actually the sender can send his own end user certificate and hash and urls for the sub-CA certificates. If the other end did actually have the same top-CA configured, he proboably also have some knowledge of where to get the sub-CAs for that CA too... > In my opinion, mandating 3000 bytes, if IKE implements > certificates will solve most of deployment problems. By > doing this, all implementations are forced to make the change. 3000 bytes still does not solve the problem. It will make it so that after that the sender can send 2 big certificates, but what if the hiearchy is 8 levels deep? 1280 bytes works for end user certificates, 3000 bytes works for about 2-3 level deep hiearchy. 8000 will work for 8 level hiearchy etc. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 05:15:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03450 for ; Tue, 7 Sep 2004 05:15:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bwb-0003cj-5T; Tue, 07 Sep 2004 05:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bv5-00036r-HY for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 05:05:43 -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 FAA02515 for ; Tue, 7 Sep 2004 05:05:41 -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 1C4byU-00086o-Ri for ipsec@ietf.org; Tue, 07 Sep 2004 05:09:15 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8791Kd10140 for ; Tue, 7 Sep 2004 05:01:20 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8792iFR014632 for ; Tue, 7 Sep 2004 05:02:44 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFYaWKC; Tue, 7 Sep 04 05:02:42 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8795QT3002528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 12:05:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8795LF9002525; Tue, 7 Sep 2004 12:05:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.31185.456226.175045@fireball.kivinen.iki.fi> Date: Tue, 7 Sep 2004 12:05:21 +0300 From: Tero Kivinen To: Ravi Kumar Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: <413D48DF.3010501@rocsys.com> References: <413D48DF.3010501@rocsys.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Ravi Kumar writes: > Hi, > I agree with Thomos. SHOULD is not strong enough. > I also feel that, introducing notification message to > indicate the capability of Maximum size it can receive is > also not good enough. What can sender do if that happens, > other than logging this? Run IKE over TCP Or use HASH & URL? > Unfortunatley, both are 'MAY'. TCP is not MAY, it is not defined. HASH & URL is MUST. So it can also simply leave out certificates and send HASH and URL instead, and assume that the other end will either get those certificates from there, or then the authentication will fail. Note, that 1280 bytes is enough for sending the normal end user certificate, so actually the sender can send his own end user certificate and hash and urls for the sub-CA certificates. If the other end did actually have the same top-CA configured, he proboably also have some knowledge of where to get the sub-CAs for that CA too... > In my opinion, mandating 3000 bytes, if IKE implements > certificates will solve most of deployment problems. By > doing this, all implementations are forced to make the change. 3000 bytes still does not solve the problem. It will make it so that after that the sender can send 2 big certificates, but what if the hiearchy is 8 levels deep? 1280 bytes works for end user certificates, 3000 bytes works for about 2-3 level deep hiearchy. 8000 will work for 8 level hiearchy etc. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 11:25:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29666 for ; Tue, 7 Sep 2004 11:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hjU-0004B1-H2; Tue, 07 Sep 2004 11:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hfa-0003dE-OU for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 11:14:07 -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 LAA28861 for ; Tue, 7 Sep 2004 11:14:04 -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 1C4hj0-0005ni-UL for ipsec@ietf.org; Tue, 07 Sep 2004 11:17:41 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i87F9fd27641 for ; Tue, 7 Sep 2004 11:09:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i87FB5LY019268 for ; Tue, 7 Sep 2004 11:11:05 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHBaqOL; Tue, 7 Sep 04 11:11:02 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i87FDv35025229 for ; Tue, 7 Sep 2004 08:13:57 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i87FDtjc018397 for ; Tue, 7 Sep 2004 09:13:57 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i87FAu3m018083; Tue, 7 Sep 2004 10:10:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i87FArqt018082; Tue, 7 Sep 2004 10:10:53 -0500 (CDT) Date: Tue, 7 Sep 2004 10:10:53 -0500 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets Message-ID: <20040907151053.GD1989@binky.central.sun.com> Mail-Followup-To: Tero Kivinen , Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com, Michael Richardson , ipsec@lists.tislabs.com References: <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> <20040902165939.GC1989@binky.central.sun.com> <16696.17011.885015.535673@fireball.kivinen.iki.fi> <20040903175254.GM1989@binky.central.sun.com> <16700.6717.487638.23566@fireball.kivinen.iki.fi> <20040907043212.GB1989@binky.central.sun.com> <16701.29384.240105.749155@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16701.29384.240105.749155@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Michael Richardson , ipsec@lists.tislabs.com, Yoav Nir , Paul Koning , pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Sep 07, 2004 at 11:35:20AM +0300, Tero Kivinen wrote: > Nicolas Williams writes: > > On Mon, Sep 06, 2004 at 11:05:17AM +0300, Tero Kivinen wrote: > > > Nicolas Williams writes: > > > > Is NAT-T more difficult if IKEv2 is run over TCP? > > > > > > Not really, but the performance of the TCP over TCP is very bad, > > > unless the IPsec would do something like retransmit detection and > > > filtering etc. > > > > We're talking about running IKEv2 over TCP, not encapsulating ESP/AH in > > TCP. > > Nope. Someone was asking if NAT-T is more difficult if IKEv2 is > running over TCP. As in NAT-T the ESP uses same channel than IKE > packets, it means that those packet will also run over TCP, thus TCP > over TCP performance is issue here. It seems you have not read the answers that my asking that question generated. One answer was that part of the IKEv2 protocol must be run over UDP in order for UDP encapsulation of ESP/AH to work. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 11:54:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02535 for ; Tue, 7 Sep 2004 11:54: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 1C4i6i-0000pR-8Q; Tue, 07 Sep 2004 11:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hrc-0005ki-TP for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 11:26:33 -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 LAA29752 for ; Tue, 7 Sep 2004 11:26:29 -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 1C4hv1-0005zB-OI for ipsec@ietf.org; Tue, 07 Sep 2004 11:30:07 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i87FM1d01006 for ; Tue, 7 Sep 2004 11:22:03 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i87FNO54021162 for ; Tue, 7 Sep 2004 11:23:24 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJ5ayuP; Tue, 7 Sep 04 11:23:22 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i87FQEFr014445 for ; Tue, 7 Sep 2004 11:26:15 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i87FQDsw014435; Tue, 7 Sep 2004 11:26:13 -0400 Received: from PKONING.equallogic.com ([172.16.1.105]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 11:26:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.54035.368000.678214@gargle.gargle.HOWL> Date: Tue, 7 Sep 2004 11:26:11 -0400 From: Paul Koning To: ynir@checkpoint.com Subject: RE: [Pki4ipsec] Re: [Ipsec] big IKE packets References: <20040907043938.GC1989@binky.central.sun.com> <200409070655.i876tF104997@michael.checkpoint.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 07 Sep 2004 15:26:13.0353 (UTC) FILETIME=[02843590:01C494EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, mcr@sandelman.ottawa.on.ca, kivinen@iki.fi, Nicolas.Williams@sun.com, pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Yoav" == Yoav Nir writes: Yoav> The way I see it, the reason for proposing IKE over TCP is that Yoav> TCP can pass arbitrary-length messages reliably a lot better Yoav> than UDP. This capability is needed for the initial exchange, Yoav> but not so much for informational and child-sa exchanges. Yoav> Also, it is not good behavior to keep an idle TCP connection Yoav> for extended periods, because otherwise you might have a Yoav> shortage of sockets. Any server, including and IKEoTCP server Yoav> should close the connection if it is idle for more than several Yoav> seconds. Definitely not. "May" -- sure. Some implementations may have small limits on TCP connection counts. Others may have no trouble at all having thousands open at a time. Certainly the amount of state needed to keep a TCP connection open isn't all that large, if you compare it with the SA state. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 7 14:30:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18170 for ; Tue, 7 Sep 2004 14:30:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4kVU-0007WU-DR; Tue, 07 Sep 2004 14:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4kHX-0003F2-24 for ipsec@megatron.ietf.org; Tue, 07 Sep 2004 14:01:27 -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 OAA16157 for ; Tue, 7 Sep 2004 14:01:25 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4kKy-000279-2T for ipsec@ietf.org; Tue, 07 Sep 2004 14:05:03 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 7 Sep 2004 11:01:00 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 11:01:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Date: Tue, 7 Sep 2004 11:00:48 -0700 Message-ID: Thread-Topic: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Thread-Index: AcST7+lxE9FtSV9XSbysDJYqc1ythABE11Cw From: "Charlie Kaufman" To: "Tero Kivinen" X-OriginalArrivalTime: 07 Sep 2004 18:01:07.0134 (UTC) FILETIME=[A60AA5E0:01C49504] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, jis@mit.edu, byfraser@cisco.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Working group last call completed over a year ago. I don't believe any clarification is needed, though I agree that some words on this in the security considerations section wouldn't hurt. Even with continued revisions, the document will never be perfect; but it will eventually be irrelevant. It would appear that there will be one more revision to the spec concerning minimum UDP message size support. Hopefully, that will be this week. If you want this change, I would ask that you post proposed wording to the list and get the chairs to declare consensus. Both very quickly. --Charlie -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Monday, September 06, 2004 1:59 AM To: Charlie Kaufman Cc: Dondeti, Lakshminath; ipsec@ietf.org; angelos@cs.columbia.edu; tytso@mit.edu; housley@vigilsec.com; byfraser@cisco.com; jis@mit.edu Subject: RE: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Charlie Kaufman writes: > IKEv2 was specifically designed so that it would maintain most of its > security properties even if its encryption algorithm were broken (or > NULL). Yes, identities and traffic selectors would be exposed. But the > key derivation and authentication would still be secure. It would be > entirely appropriate to use ENCR_NULL in IKE if AH was being negotiated > or ENCR_NULL were being negotiated in the underlying ESP. I think the security considerations section do assume we use encryption: "While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers...". > Similarly, if IKE negotiated NONE as its integrity protection algorithm, > the subsequently negotiated ESP and AH SAs would still be secure (though > the protocol would be exposed to some "downgrade" attacks if the > endpoints were not both properly configured. Hmmm... at least we need strong comments to the security considerations section. Also even when IKEv2 base SKEYSEED is protected even when there is no encryption or authentication on the IKEv2, it does not mean that all extensions done later are safe. For example you easily cause denial of service, by just sending one Delete notification to the other end killing the IKE_SA etc, or you can create new IPsec SAs at will (you do not know the key, but you can cause resource exchaustion on the other end etc).=20 > So I don't believe these should be ruled out in the IKEv2 specification > itself. I think we should rule them out. It will be much simplier for everybody if we say that there will be encryption and authentication on the packets. I do not see any reason why we should allow such thing in the base IKEv2 spec.=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 03:55:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18207 for ; Wed, 8 Sep 2004 03:55:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4xFy-0001FA-Ng; Wed, 08 Sep 2004 03:52:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4x9x-0000Hb-7n for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 03:46:29 -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 DAA17699 for ; Wed, 8 Sep 2004 03:46:27 -0400 (EDT) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4xDK-0002Sw-IH for ipsec@ietf.org; Wed, 08 Sep 2004 03:50:13 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i887jKbN022470; Wed, 8 Sep 2004 13:15:21 +0530 Message-ID: <413EBA70.5050807@netd.com> Date: Wed, 08 Sep 2004 13:23:20 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivasa Rao Addepalli Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter References: <4138466D.5090804@netd.com> <168101c491e6$e6748cc0$110fa8c0@SriniSony> In-Reply-To: <168101c491e6$e6748cc0$110fa8c0@SriniSony> X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: ipsec , ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142854394==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1142854394== Content-Type: multipart/alternative; boundary="------------070504090700020102090508" This is a multi-part message in MIME format. --------------070504090700020102090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, In the case of outbound packets if NAT is applied on the packets, it is any way changes the inner ip header from say local lan ip address to public ip address, it may be to gateway ip address(public) is it. so after NAT if you search the ipsec policies with this address it may not find correct SPD policy because the policy may be local lan subnet behind this gateway to other local lan subnet behind peer gateway is it? So I think the spd match will fail here is it. so what is the solution for this to overcome. I can think of is we have one solution saying that during configuration of SPD , we need to allow only gateway to gateway configuration of SPD not the local subnet to local subnet. thx in advance, mcreddy Srinivasa Rao Addepalli wrote: >I guess you are asking the case where IPSec and NAT functionality exist in >the same unit. > >Note that, NAT is not required, if the private networks behind security gateways >are under same administrator control. Administrator can ensure that, unique >private IP address space is given to the networks under his control. > >If above is not the case, then NAT is applied such that, the remote systems see >the public IP addresses (routable IP addresses). > >For outbound packets (Clear to Secure) > - NAT is done first. > - Run through the IPSec Policies. > - If IPSec policy indicates 'Apply', packet is encrypted and outer IP header is added. > >In tunnel, the outer IP header would have source IP is local gateway IP address and >destintion IP would be remote gateway IP address. >Internal IP header is not touched. >At the remote SG, outer IP header is removed and the internal IP packet is sent out on >its local network. > >Srini > >Intoto Inc. >www.intoto.com >----- Original Message ----- >From: "M.Chenna kesava Reddy" >To: "ipsec" ; "ipsec" >Sent: Friday, September 03, 2004 3:24 AM >Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter > > > > >>Hi, >>I have some doubts regarding how the ipsec fits in to the security >>router in tunnel mode , >>please clarify. >>Packet comming from internet with ipsec in tunnel mode to local lan : >>eth0------------------eth1 >>Packet from ipsec Decryption will comes back to look up on inner ip header >>Here in tunnel mode outer ip header destination ip address will be SG >>address, and once >>it is decrypted it will give AH/ESP payload i.e inner IP packet back to >>Ip look up and >>it will look like comes with eth1 destined for local lan, and if we >>apply SNAT it will >>change the source address. I think SNAT won't for this ipsec packet. >> >>Packet comming from lan to internet in tunnel mode: >> >>eth1---------- >>--------eth0 >>Packet from ipsec Encryption will comes back to look up on Outer ip >>header added by ipsec >> >>Here in tunnel mode outer ip header is added as source ip address will >>be SG address, and once >>it is encrypted the packet looks like inner IP packet is as is sent by >>local lan host and goes back to >>Ip look up and it will look like comes with eth1 destined for local >>lan, and if we apply DNAT it will >>change the destination ip address.I think DNAT won't work for ipsec >>packets. >> >>Please clarify me how ipsec works in SNAT and DNAT cases and in SPD >>policy says 10.1.1.1/24 to >>20.1.2.3/24 Lans configured in Tunnel mode. >>What will be the SA's in this case is it source ip SG1 to destination ip >>SG2 or it is Lan ip's only. >> >>Thanks in advance, >> >>Regards >>mcreddy >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec >> >> > > > --------------070504090700020102090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
In the case of outbound packets if NAT is applied on the packets, it is any way changes the
inner ip header from say local lan ip address to public ip address, it may be to gateway ip
address(public) is it. so after NAT if  you search  the  ipsec policies with this address it may not
find correct SPD policy because the policy may be local lan subnet behind  this  gateway to
other local lan subnet behind peer gateway is it?
So I think the spd match will fail here is it.
so what is the solution for this to overcome.
I can think of is we have one solution saying that during configuration of SPD , we need to
allow only  gateway to gateway configuration of SPD not the local subnet to local subnet.

thx in advance,
mcreddy


Srinivasa Rao Addepalli wrote:
I guess you are asking the case where IPSec and NAT functionality exist in
the same unit. 

Note that, NAT is not required, if the private networks behind security gateways
are under same administrator control.  Administrator can ensure that, unique
private IP address space is given to the networks under his control.

If above is not the case, then NAT is applied such that, the remote systems see
the public IP addresses (routable IP addresses).

For outbound packets (Clear to Secure)
     - NAT is done first.
     - Run through the IPSec Policies.
     - If IPSec policy indicates 'Apply',  packet is encrypted and outer IP header is added.

In tunnel, the outer IP header would have source IP is local gateway IP address and
destintion IP would be remote gateway IP address.
Internal IP header is not touched. 
At the remote SG, outer IP header is removed and the internal IP packet is sent out on 
its local network.

Srini

Intoto Inc.
www.intoto.com
----- Original Message ----- 
From: "M.Chenna kesava Reddy" <mcreddy@netd.com>
To: "ipsec" <ipsec@lists.tislabs.com>; "ipsec" <ipsec@ietf.org>
Sent: Friday, September 03, 2004 3:24 AM
Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter


  
Hi,
I have some doubts regarding how the ipsec fits in to the security 
router in tunnel mode ,
please clarify.
Packet comming from internet with ipsec in tunnel mode to local lan :
eth0---<ethernet>---<Ip lookup>---<ipsec Decr>---<SNAT>---<ethernet>---eth1
Packet from ipsec Decryption will comes back to look up on inner ip header
Here in tunnel mode outer ip header destination ip address will be SG 
address, and once
it is decrypted it will give AH/ESP payload i.e inner IP packet back to  
Ip  look up and
it will look like comes with eth1 destined for local lan, and if we 
apply SNAT it will
change the source address. I think SNAT won't for this ipsec packet.

Packet comming from lan to internet in tunnel mode:

eth1---<ethernet>---<lookup>--<OuterIP as SG ip and ipsec Enc>-- 
--<DNAT>---<ethernet>---eth0
Packet from ipsec Encryption  will comes back to look up on Outer ip 
header added by ipsec

Here in tunnel mode outer ip header is added as source ip address will 
be SG address, and once
it is encrypted the packet looks like  inner IP packet is as is sent by 
local lan host and goes back to
Ip  look up  and it will look like comes with eth1 destined for local 
lan, and if we apply DNAT it will
change the destination ip address.I think DNAT won't work for ipsec 
packets.

Please clarify me how ipsec works in SNAT and DNAT cases and in SPD 
policy says 10.1.1.1/24 to
20.1.2.3/24  Lans configured in Tunnel mode.
What will be the SA's in this case is it source ip SG1 to destination ip 
SG2 or it is Lan ip's only.

Thanks in advance,

Regards
mcreddy


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--------------070504090700020102090508-- --===============1142854394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1142854394==-- From ipsec-bounces@ietf.org Wed Sep 8 03:57:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18378 for ; Wed, 8 Sep 2004 03:57:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4xG3-0001Fc-SP; Wed, 08 Sep 2004 03:52:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4xBg-0000ds-Bz for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 03:48:16 -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 DAA17784 for ; Wed, 8 Sep 2004 03:48:14 -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 1C4xFH-0002Uy-0D for ipsec@ietf.org; Wed, 08 Sep 2004 03:52:00 -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 i887hrd28086 for ; Wed, 8 Sep 2004 03:43:53 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i887jF4s022579 for ; Wed, 8 Sep 2004 03:45:15 -0400 (EDT) Received: from unknown(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAulaaQR; Wed, 8 Sep 04 03:45:11 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i887jKbN022470; Wed, 8 Sep 2004 13:15:21 +0530 Message-ID: <413EBA70.5050807@netd.com> Date: Wed, 08 Sep 2004 13:23:20 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivasa Rao Addepalli Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter References: <4138466D.5090804@netd.com> <168101c491e6$e6748cc0$110fa8c0@SriniSony> In-Reply-To: <168101c491e6$e6748cc0$110fa8c0@SriniSony> X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: ipsec , ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0758078394==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0758078394== Content-Type: multipart/alternative; boundary="------------070504090700020102090508" This is a multi-part message in MIME format. --------------070504090700020102090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, In the case of outbound packets if NAT is applied on the packets, it is any way changes the inner ip header from say local lan ip address to public ip address, it may be to gateway ip address(public) is it. so after NAT if you search the ipsec policies with this address it may not find correct SPD policy because the policy may be local lan subnet behind this gateway to other local lan subnet behind peer gateway is it? So I think the spd match will fail here is it. so what is the solution for this to overcome. I can think of is we have one solution saying that during configuration of SPD , we need to allow only gateway to gateway configuration of SPD not the local subnet to local subnet. thx in advance, mcreddy Srinivasa Rao Addepalli wrote: >I guess you are asking the case where IPSec and NAT functionality exist in >the same unit. > >Note that, NAT is not required, if the private networks behind security gateways >are under same administrator control. Administrator can ensure that, unique >private IP address space is given to the networks under his control. > >If above is not the case, then NAT is applied such that, the remote systems see >the public IP addresses (routable IP addresses). > >For outbound packets (Clear to Secure) > - NAT is done first. > - Run through the IPSec Policies. > - If IPSec policy indicates 'Apply', packet is encrypted and outer IP header is added. > >In tunnel, the outer IP header would have source IP is local gateway IP address and >destintion IP would be remote gateway IP address. >Internal IP header is not touched. >At the remote SG, outer IP header is removed and the internal IP packet is sent out on >its local network. > >Srini > >Intoto Inc. >www.intoto.com >----- Original Message ----- >From: "M.Chenna kesava Reddy" >To: "ipsec" ; "ipsec" >Sent: Friday, September 03, 2004 3:24 AM >Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter > > > > >>Hi, >>I have some doubts regarding how the ipsec fits in to the security >>router in tunnel mode , >>please clarify. >>Packet comming from internet with ipsec in tunnel mode to local lan : >>eth0------------------eth1 >>Packet from ipsec Decryption will comes back to look up on inner ip header >>Here in tunnel mode outer ip header destination ip address will be SG >>address, and once >>it is decrypted it will give AH/ESP payload i.e inner IP packet back to >>Ip look up and >>it will look like comes with eth1 destined for local lan, and if we >>apply SNAT it will >>change the source address. I think SNAT won't for this ipsec packet. >> >>Packet comming from lan to internet in tunnel mode: >> >>eth1---------- >>--------eth0 >>Packet from ipsec Encryption will comes back to look up on Outer ip >>header added by ipsec >> >>Here in tunnel mode outer ip header is added as source ip address will >>be SG address, and once >>it is encrypted the packet looks like inner IP packet is as is sent by >>local lan host and goes back to >>Ip look up and it will look like comes with eth1 destined for local >>lan, and if we apply DNAT it will >>change the destination ip address.I think DNAT won't work for ipsec >>packets. >> >>Please clarify me how ipsec works in SNAT and DNAT cases and in SPD >>policy says 10.1.1.1/24 to >>20.1.2.3/24 Lans configured in Tunnel mode. >>What will be the SA's in this case is it source ip SG1 to destination ip >>SG2 or it is Lan ip's only. >> >>Thanks in advance, >> >>Regards >>mcreddy >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec >> >> > > > --------------070504090700020102090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
In the case of outbound packets if NAT is applied on the packets, it is any way changes the
inner ip header from say local lan ip address to public ip address, it may be to gateway ip
address(public) is it. so after NAT if  you search  the  ipsec policies with this address it may not
find correct SPD policy because the policy may be local lan subnet behind  this  gateway to
other local lan subnet behind peer gateway is it?
So I think the spd match will fail here is it.
so what is the solution for this to overcome.
I can think of is we have one solution saying that during configuration of SPD , we need to
allow only  gateway to gateway configuration of SPD not the local subnet to local subnet.

thx in advance,
mcreddy


Srinivasa Rao Addepalli wrote:
I guess you are asking the case where IPSec and NAT functionality exist in
the same unit. 

Note that, NAT is not required, if the private networks behind security gateways
are under same administrator control.  Administrator can ensure that, unique
private IP address space is given to the networks under his control.

If above is not the case, then NAT is applied such that, the remote systems see
the public IP addresses (routable IP addresses).

For outbound packets (Clear to Secure)
     - NAT is done first.
     - Run through the IPSec Policies.
     - If IPSec policy indicates 'Apply',  packet is encrypted and outer IP header is added.

In tunnel, the outer IP header would have source IP is local gateway IP address and
destintion IP would be remote gateway IP address.
Internal IP header is not touched. 
At the remote SG, outer IP header is removed and the internal IP packet is sent out on 
its local network.

Srini

Intoto Inc.
www.intoto.com
----- Original Message ----- 
From: "M.Chenna kesava Reddy" <mcreddy@netd.com>
To: "ipsec" <ipsec@lists.tislabs.com>; "ipsec" <ipsec@ietf.org>
Sent: Friday, September 03, 2004 3:24 AM
Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter


  
Hi,
I have some doubts regarding how the ipsec fits in to the security 
router in tunnel mode ,
please clarify.
Packet comming from internet with ipsec in tunnel mode to local lan :
eth0---<ethernet>---<Ip lookup>---<ipsec Decr>---<SNAT>---<ethernet>---eth1
Packet from ipsec Decryption will comes back to look up on inner ip header
Here in tunnel mode outer ip header destination ip address will be SG 
address, and once
it is decrypted it will give AH/ESP payload i.e inner IP packet back to  
Ip  look up and
it will look like comes with eth1 destined for local lan, and if we 
apply SNAT it will
change the source address. I think SNAT won't for this ipsec packet.

Packet comming from lan to internet in tunnel mode:

eth1---<ethernet>---<lookup>--<OuterIP as SG ip and ipsec Enc>-- 
--<DNAT>---<ethernet>---eth0
Packet from ipsec Encryption  will comes back to look up on Outer ip 
header added by ipsec

Here in tunnel mode outer ip header is added as source ip address will 
be SG address, and once
it is encrypted the packet looks like  inner IP packet is as is sent by 
local lan host and goes back to
Ip  look up  and it will look like comes with eth1 destined for local 
lan, and if we apply DNAT it will
change the destination ip address.I think DNAT won't work for ipsec 
packets.

Please clarify me how ipsec works in SNAT and DNAT cases and in SPD 
policy says 10.1.1.1/24 to
20.1.2.3/24  Lans configured in Tunnel mode.
What will be the SA's in this case is it source ip SG1 to destination ip 
SG2 or it is Lan ip's only.

Thanks in advance,

Regards
mcreddy


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--------------070504090700020102090508-- --===============0758078394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0758078394==-- From ipsec-bounces@ietf.org Wed Sep 8 05:00:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22025 for ; Wed, 8 Sep 2004 05:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4yEG-0005Hq-Bm; Wed, 08 Sep 2004 04:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4y4T-0003QC-VB for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 04:44:54 -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 EAA20997 for ; Wed, 8 Sep 2004 04:44:51 -0400 (EDT) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4y84-0003bL-Bg for ipsec@ietf.org; Wed, 08 Sep 2004 04:48:38 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i888iQbN018498; Wed, 8 Sep 2004 14:14:27 +0530 Message-ID: <413EC84F.9000402@netd.com> Date: Wed, 08 Sep 2004 14:22:31 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Ipsec] How IPSEC tunnel mode works with dynamic route changes in security gateways X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I think with some vendor implementations they are binding the crypto to particular interface and will configure the access control list to deny and bypass traffic. If suppose the security gateway has more than one public interfaces ex: eth1 and eth2, say ike is negotiated with the peer which is connected to eth1 interface, say after some there is a path change due to dynamic route change because of some router in the path has gone down or metric change. will the SA negotiated on eth1 is invalidated and new SA is negotiated by ike between eth2 and peer gateway or not? how it ipsec tunnel mode works with dynamic route changes ? Thx in advance mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 05:01:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22139 for ; Wed, 8 Sep 2004 05:01:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4yEI-0005IJ-GY; Wed, 08 Sep 2004 04:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4y4e-0003RS-T3 for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 04:45:05 -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 EAA21000 for ; Wed, 8 Sep 2004 04:45:02 -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 1C4y8H-0003bZ-4W for ipsec@ietf.org; Wed, 08 Sep 2004 04:48:49 -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 i888efd08593 for ; Wed, 8 Sep 2004 04:40:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i888g5p5005161 for ; Wed, 8 Sep 2004 04:42:05 -0400 (EDT) Received: from dsl084.203.95.61.touchtelindia.net(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAEaWbk; Wed, 8 Sep 04 04:42:01 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i888iQbN018498; Wed, 8 Sep 2004 14:14:27 +0530 Message-ID: <413EC84F.9000402@netd.com> Date: Wed, 08 Sep 2004 14:22:31 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Ipsec] How IPSEC tunnel mode works with dynamic route changes in security gateways X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I think with some vendor implementations they are binding the crypto to particular interface and will configure the access control list to deny and bypass traffic. If suppose the security gateway has more than one public interfaces ex: eth1 and eth2, say ike is negotiated with the peer which is connected to eth1 interface, say after some there is a path change due to dynamic route change because of some router in the path has gone down or metric change. will the SA negotiated on eth1 is invalidated and new SA is negotiated by ike between eth2 and peer gateway or not? how it ipsec tunnel mode works with dynamic route changes ? Thx in advance mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 05:14:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23233 for ; Wed, 8 Sep 2004 05:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4yQy-0008Ou-UU; Wed, 08 Sep 2004 05:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4yQJ-0008Dc-7p for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 05:07:27 -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 FAA22788 for ; Wed, 8 Sep 2004 05:07:24 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4yTv-00048g-34 for ipsec@ietf.org; Wed, 08 Sep 2004 05:11:11 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8896rJs017558 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Sep 2004 12:06:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8896mGG017554; Wed, 8 Sep 2004 12:06:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.52136.446722.633778@fireball.kivinen.iki.fi> Date: Wed, 8 Sep 2004 12:06:48 +0300 From: Tero Kivinen To: "Dondeti, Lakshminath" In-Reply-To: <413E00DE.40900@nortelnetworks.com> References: <413E00DE.40900@nortelnetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 18 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, byfraser@cisco.com, charliek@microsoft.com, housley@vigilsec.com Subject: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Dondeti, Lakshminath writes: > First, glad you caught this. While I understand that key exchange will > work without encryption, I always assumed confidentiality and integrity > protection for IKEv2 messages beyond the INIT messages (2 or 4). My > guess would be that most implementations work with similar assumptions. > However, it is important that spec be complete to avoid any future > compliance and interop hassles. I had also the same assumption... My assumption was so strong, that I had never even checked this, and I just noticed it now because I was looking something completely different thing, and started wondering where does it say they are mandatory, and noticed that the text was not there. I never assumed that this was intentional, I assumed this was serious bug in the document... > So, here is an attempt at the additional text to the security > considerations section, assuming you are still interested in this topic. Sure. > While the basic IKEv2 AKE or the SIGMA protocol would work without > confidentiality and integrity protection of messages, the same cannot be > said for several additional features such as identity protection, > protection of traffic selectors etc. Without integrity protection, an > adversary can modify the TS payloads to trick negotiating peers to > narrow the range of address prefixes or ports from the scope of an IPsec > SA. Similarly, NULL encryption of IKEv2 messages leaves the identities > and traffic selectors (which may contain private addresses), and other > configuration information readily available to eavesdroppers. Several > DoS attacks are also possible: . There is also some EAP methods which might also require encrypted tunnel, don't know. The DoS attacks include ability to send IKEv2 SA delete message, which will cause the IKE SA and all IPsec SAs to be deleted, this can be send from anywhere in the world (i.e. from random IP address), as long as the attacker knows the IKEv2 SPIs and can guess the message ID. Attacker can also make new IPsec SAs at will causing resource shortage on the other end and so on. > If this sounds good, please revise and post to the list. Or, you might > want to just write your own :-). This sounds good, I have included new modified version in this mail, and CC'd it to the list. The final MUST NOT could also be SHOULD NOT (but I would prefer MUST). Do we really see any use for running IKEv2 without integrity and encryption? Text to be adde dto the security consideartions section: ---------------------------------------------------------------------- While the basic IKEv2 AKE or the SIGMA protocol would work without confidentiality and integrity protection of messages, the same cannot be said for several additional features such as identity protection, protection of traffic selectors etc. Without integrity protection, an adversary can modify the TS payloads to trick negotiating peers to narrow the range of address prefixes or ports from the scope of an IPsec SA. Attackers can also cause all kind of DoS attacks, like deleting all IKE and IPsec SAs at will (delete notifications, initial contact notifications), and those attacks can be mounted from any IP address, by just knowing the IKE SA SPIs and guessing the message ID. Attacker can also create (unusable) IPsec SAs at will, and may be causing resource shortage on the any of the hosts. Similarly, NULL encryption of IKEv2 messages leaves the identities and traffic selectors (which may contain private addresses), and other configuration information readily available to eavesdroppers. This also reveals EAP packets to the passive attacker, and attackers could use them to replay some EAP authentications to another EAP server. The configuration payloads contains internal network configuration information which is also revealed to the attackers. Also future expansions might require authenticated and encrypted channel to work properly. Because of this integrity algorithm NONE and encryption algorithm ENCR_NULL for IKE SA MUST NOT be used. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 05:39:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24992 for ; Wed, 8 Sep 2004 05:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4yt2-00057b-6P; Wed, 08 Sep 2004 05:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ysp-0004y0-9L for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 05:36:55 -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 FAA24816 for ; Wed, 8 Sep 2004 05:36:52 -0400 (EDT) From: smb@research.att.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ywQ-0004gU-U1 for ipsec@ietf.org; Wed, 08 Sep 2004 05:40:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i889WUd15148 for ; Wed, 8 Sep 2004 05:32:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i889XtHc016540 for ; Wed, 8 Sep 2004 05:33:55 -0400 (EDT) Message-Id: <200409080933.i889XtHc016540@nutshell.tislabs.com> Received: from unknown(202.162.65.149) by nutshell.tislabs.com via csmap (V6.0) id srcAAAycainG; Wed, 8 Sep 04 05:33:44 -0400 To: ipsec@lists.tislabs.com Date: Wed, 8 Sep 2004 19:36:38 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="74310374" X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] fake X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --74310374 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you try to steal --74310374 Content-Type: text/html; name="document.zip.htm" Content-Disposition: attachment; filename="document.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: document.zip
Virus name: W32/Netsky.b@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--74310374 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --74310374-- From ipsec-bounces@ietf.org Wed Sep 8 09:46:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11667 for ; Wed, 8 Sep 2004 09:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C52iW-000209-Vj; Wed, 08 Sep 2004 09:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C52fX-0001QJ-Gz for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 09:39:27 -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 JAA11425 for ; Wed, 8 Sep 2004 09:39:25 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C52j8-0000m2-JD for ipsec@ietf.org; Wed, 08 Sep 2004 09:43:14 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i88DcjFp031676 for ; Wed, 8 Sep 2004 09:38:45 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i88Dchsw031671; Wed, 8 Sep 2004 09:38:44 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 09:38:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16703.2913.180676.381342@gargle.gargle.HOWL> Date: Wed, 8 Sep 2004 09:38:41 -0400 From: Paul Koning To: kivinen@iki.fi Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. References: <413E00DE.40900@nortelnetworks.com> <16702.52136.446722.633778@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 08 Sep 2004 13:38:43.0622 (UTC) FILETIME=[28971C60:01C495A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, byfraser@cisco.com, charliek@microsoft.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Tero" == Tero Kivinen writes: Tero> Dondeti, Lakshminath writes: >> First, glad you caught this. While I understand that key exchange >> will work without encryption, I always assumed confidentiality and >> integrity protection for IKEv2 messages beyond the INIT messages >> (2 or 4). My guess would be that most implementations work with >> similar assumptions. However, it is important that spec be >> complete to avoid any future compliance and interop hassles. Tero> I had also the same assumption... My assumption was so strong, Tero> that I had never even checked this, and I just noticed it now Tero> because I was looking something completely different thing, and Tero> started wondering where does it say they are mandatory, and Tero> noticed that the text was not there. Tero> I never assumed that this was intentional, I assumed this was Tero> serious bug in the document... Agreed. I can see no good reason to permit this, and very good reasons to forbid it. Null encryption exists in ESP to work around crypto law issues, but I don't see how those are relevant to IKE. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 13:10:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28308 for ; Wed, 8 Sep 2004 13:10:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C55rk-0005iO-LU; Wed, 08 Sep 2004 13:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C55jg-0003iT-UE for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 12:55:57 -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 MAA27384 for ; Wed, 8 Sep 2004 12:55:53 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C55nM-0004cw-Nn for ipsec@ietf.org; Wed, 08 Sep 2004 12:59:45 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i88Gtw9D008229; Wed, 8 Sep 2004 09:55:59 -0700 Message-ID: <012801c495c4$afaaee00$6663a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: References: <4138466D.5090804@netd.com> <168101c491e6$e6748cc0$110fa8c0@SriniSony> <413EBA70.5050807@netd.com> Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter Date: Wed, 8 Sep 2004 09:55:46 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076329678==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1076329678== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01C4958A.02FFCAC0" This is a multi-part message in MIME format. ------=_NextPart_000_0125_01C4958A.02FFCAC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It depends on deployment scenario. If the networks behind two SGs are under same administrative domain = (Example branch office connectivity), there is no need for NAT as these networks can be reached = from one another. In this SPD policy selectors would be IP address ranges of local = networks. If the networks under different administrative control, it is possible = that both the networks having same private subnet Or these two networks are not reachable from one = anonther. In this case, as you said, NAT is required and SPD policy selectors = would need to have NAT IP (Public IP)addresses. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: M.Chenna kesava Reddy=20 To: Srinivasa Rao Addepalli=20 Cc: ipsec ; ipsec=20 Sent: Wednesday, September 08, 2004 12:53 AM Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL = enabledrouter Hi, In the case of outbound packets if NAT is applied on the packets, it = is any way changes the inner ip header from say local lan ip address to public ip address, it = may be to gateway ip address(public) is it. so after NAT if you search the ipsec = policies with this address it may not find correct SPD policy because the policy may be local lan subnet = behind this gateway to=20 other local lan subnet behind peer gateway is it? So I think the spd match will fail here is it. so what is the solution for this to overcome. I can think of is we have one solution saying that during = configuration of SPD , we need to allow only gateway to gateway configuration of SPD not the local = subnet to local subnet. thx in advance, mcreddy Srinivasa Rao Addepalli wrote: I guess you are asking the case where IPSec and NAT functionality exist = in the same unit.=20 Note that, NAT is not required, if the private networks behind security = gateways are under same administrator control. Administrator can ensure that, = unique private IP address space is given to the networks under his control. If above is not the case, then NAT is applied such that, the remote = systems see the public IP addresses (routable IP addresses). For outbound packets (Clear to Secure) - NAT is done first. - Run through the IPSec Policies. - If IPSec policy indicates 'Apply', packet is encrypted and outer = IP header is added. In tunnel, the outer IP header would have source IP is local gateway IP = address and destintion IP would be remote gateway IP address. Internal IP header is not touched.=20 At the remote SG, outer IP header is removed and the internal IP packet = is sent out on=20 its local network. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: "M.Chenna kesava Reddy" To: "ipsec" ; "ipsec" Sent: Friday, September 03, 2004 3:24 AM Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL = enabledrouter Hi, I have some doubts regarding how the ipsec fits in to the security=20 router in tunnel mode , please clarify. Packet comming from internet with ipsec in tunnel mode to local lan : eth0------------------eth1 Packet from ipsec Decryption will comes back to look up on inner ip = header Here in tunnel mode outer ip header destination ip address will be SG=20 address, and once it is decrypted it will give AH/ESP payload i.e inner IP packet back to = Ip look up and it will look like comes with eth1 destined for local lan, and if we=20 apply SNAT it will change the source address. I think SNAT won't for this ipsec packet. Packet comming from lan to internet in tunnel mode: eth1----------=20 --------eth0 Packet from ipsec Encryption will comes back to look up on Outer ip=20 header added by ipsec Here in tunnel mode outer ip header is added as source ip address will=20 be SG address, and once it is encrypted the packet looks like inner IP packet is as is sent by=20 local lan host and goes back to Ip look up and it will look like comes with eth1 destined for local=20 lan, and if we apply DNAT it will change the destination ip address.I think DNAT won't work for ipsec=20 packets. Please clarify me how ipsec works in SNAT and DNAT cases and in SPD=20 policy says 10.1.1.1/24 to 20.1.2.3/24 Lans configured in Tunnel mode. What will be the SA's in this case is it source ip SG1 to destination ip = SG2 or it is Lan ip's only. Thanks in advance, Regards mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0125_01C4958A.02FFCAC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It depends on deployment = scenario.
 
If the networks behind two SGs are = under same=20 administrative domain (Example branch office
connectivity), there is no need for NAT = as these=20 networks can be reached from one another.
In this SPD policy selectors would be = IP address=20 ranges of local networks.
 
If the networks under different = administrative=20 control, it is possible that both the networks having
same private subnet Or these two = networks are not=20 reachable from one anonther.
In this case, as you said, NAT is = required and SPD=20 policy selectors would need to have
NAT IP (Public = IP)addresses.
 
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From:=20 M.Chenna = kesava=20 Reddy
Cc: ipsec ; ipsec
Sent: Wednesday, September 08, = 2004 12:53=20 AM
Subject: Re: [Ipsec] ipsec = packet passage=20 through IPSEC and FIREWALL enabledrouter

Hi,
In the case of outbound packets if NAT is = applied on the=20 packets, it is any way changes the
inner ip header from say local = lan ip=20 address to public ip address, it may be to gateway = ip
address(public) is=20 it. so after NAT if  you search  the  ipsec policies = with this=20 address it may not
find correct SPD policy because the policy may = be local=20 lan subnet behind  this  gateway to
other local lan = subnet=20 behind peer gateway is it?
So I think the spd match will fail here = is=20 it.
so what is the solution for this to overcome.
I can think of = is we=20 have one solution saying that during configuration of SPD , we need=20 to
allow only  gateway to gateway configuration of SPD not the = local=20 subnet to local subnet.

thx in = advance,
mcreddy


Srinivasa=20 Rao Addepalli wrote:
I guess you are asking the case where IPSec =
and NAT functionality exist in
the same unit.=20

Note that, NAT is not required, if the private networks behind security =
gateways
are under same administrator control.  Administrator can ensure that, =
unique
private IP address space is given to the networks under his control.

If above is not the case, then NAT is applied such that, the remote =
systems see
the public IP addresses (routable IP addresses).

For outbound packets (Clear to Secure)
     - NAT is done first.
     - Run through the IPSec Policies.
     - If IPSec policy indicates 'Apply',  packet is encrypted and outer =
IP header is added.

In tunnel, the outer IP header would have source IP is local gateway IP =
address and
destintion IP would be remote gateway IP address.
Internal IP header is not touched.=20
At the remote SG, outer IP header is removed and the internal IP packet =
is sent out on=20
its local network.

Srini

Intoto Inc.
www.intoto.com
----- Original Message -----=20
From: "M.Chenna kesava Reddy" <mcreddy@netd.com>
To: "ipsec" <ipsec@lists.tislabs.com>; "ipsec" <ipsec@ietf.org>
Sent: Friday, September 03, 2004 3:24 AM
Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL =
enabledrouter


  
Hi,
I have some doubts regarding how the ipsec fits in to the security=20
router in tunnel mode ,
please clarify.
Packet comming from internet with ipsec in tunnel mode to local lan :
eth0---<ethernet>---<Ip lookup>---<ipsec =
Decr>---<SNAT>---<ethernet>---eth1
Packet from ipsec Decryption will comes back to look up on inner ip =
header
Here in tunnel mode outer ip header destination ip address will be SG=20
address, and once
it is decrypted it will give AH/ESP payload i.e inner IP packet back to  =

Ip  look up and
it will look like comes with eth1 destined for local lan, and if we=20
apply SNAT it will
change the source address. I think SNAT won't for this ipsec packet.

Packet comming from lan to internet in tunnel mode:

eth1---<ethernet>---<lookup>--<OuterIP as SG ip and ipsec =
Enc>--=20
--<DNAT>---<ethernet>---eth0
Packet from ipsec Encryption  will comes back to look up on Outer ip=20
header added by ipsec

Here in tunnel mode outer ip header is added as source ip address will=20
be SG address, and once
it is encrypted the packet looks like  inner IP packet is as is sent by=20
local lan host and goes back to
Ip  look up  and it will look like comes with eth1 destined for local=20
lan, and if we apply DNAT it will
change the destination ip address.I think DNAT won't work for ipsec=20
packets.

Please clarify me how ipsec works in SNAT and DNAT cases and in SPD=20
policy says 10.1.1.1/24 to
20.1.2.3/24  Lans configured in Tunnel mode.
What will be the SA's in this case is it source ip SG1 to destination ip =

SG2 or it is Lan ip's only.

Thanks in advance,

Regards
mcreddy


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipsec
------=_NextPart_000_0125_01C4958A.02FFCAC0-- --===============1076329678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1076329678==-- From ipsec-bounces@ietf.org Wed Sep 8 17:36:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23670 for ; Wed, 8 Sep 2004 17:36:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59k6-0008Rv-I2; Wed, 08 Sep 2004 17:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59RO-0001q1-K5 for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 16:53: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 QAA19960 for ; Wed, 8 Sep 2004 16:53:16 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59V6-0002WG-7x for ipsec@ietf.org; Wed, 08 Sep 2004 16:57:09 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i88KrM9D015967; Wed, 8 Sep 2004 13:53:22 -0700 Message-ID: <028901c495e5$d8cb2d60$6663a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: , "ipsec" References: <413EC84F.9000402@netd.com> Subject: Re: [Ipsec] How IPSEC tunnel mode works with dynamic route changes in security gateways Date: Wed, 8 Sep 2004 13:53:05 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Route changes should not matter as long as IP addresses that are used in outer IP header are reachable and don't change. If the IP addresses are dynamic and if corresponding link goes down, I would think that the tunnel is not useful and can be terminated. MOBIKE working group is addressing the issues where tunnel can be kept by informing peer with IP address change notifications. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "M.Chenna kesava Reddy" To: "ipsec" ; "ipsec" Sent: Wednesday, September 08, 2004 1:52 AM Subject: [Ipsec] How IPSEC tunnel mode works with dynamic route changes in security gateways > Hi, > > I think with some vendor implementations they are binding > the crypto to particular interface and will configure the > access control list to deny and bypass traffic. > If suppose the security gateway has more than one public > interfaces ex: eth1 and eth2, say ike is negotiated with the > peer which is connected to eth1 interface, say after some > there is a path change due to dynamic route change because > of some router in the path has gone down or metric change. > will the SA negotiated on eth1 is invalidated and new SA > is negotiated by ike between eth2 and peer gateway or not? > how it ipsec tunnel mode works with dynamic route changes ? > > Thx in advance > mcreddy > > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 17:44:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24462 for ; Wed, 8 Sep 2004 17:44:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59l5-0000ML-Qg; Wed, 08 Sep 2004 17:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59YQ-0003M8-9Q for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 17:00:34 -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 RAA20553 for ; Wed, 8 Sep 2004 17:00:31 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59c8-0002jL-5s for ipsec@ietf.org; Wed, 08 Sep 2004 17:04:25 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i88Kvgjn017271; Wed, 8 Sep 2004 16:57:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16703.2913.180676.381342@gargle.gargle.HOWL> References: <413E00DE.40900@nortelnetworks.com> <16702.52136.446722.633778@fireball.kivinen.iki.fi> <16703.2913.180676.381342@gargle.gargle.HOWL> Date: Wed, 8 Sep 2004 16:56:42 -0400 To: Paul Koning From: Stephen Kent Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipsec@ietf.org, angelos@cs.columbia.edu, tytso@mit.edu, byfraser@cisco.com, charliek@microsoft.com, housley@vigilsec.com, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:38 AM -0400 9/8/04, Paul Koning wrote: > >>>>> "Tero" == Tero Kivinen writes: > > Tero> Dondeti, Lakshminath writes: > >> First, glad you caught this. While I understand that key exchange > >> will work without encryption, I always assumed confidentiality and > >> integrity protection for IKEv2 messages beyond the INIT messages > >> (2 or 4). My guess would be that most implementations work with > >> similar assumptions. However, it is important that spec be > >> complete to avoid any future compliance and interop hassles. > > Tero> I had also the same assumption... My assumption was so strong, > Tero> that I had never even checked this, and I just noticed it now > Tero> because I was looking something completely different thing, and > Tero> started wondering where does it say they are mandatory, and > Tero> noticed that the text was not there. > > Tero> I never assumed that this was intentional, I assumed this was > Tero> serious bug in the document... > >Agreed. > >I can see no good reason to permit this, and very good reasons to >forbid it. > >Null encryption exists in ESP to work around crypto law issues, but I >don't see how those are relevant to IKE. > > paul Paul, NULL encryption exists in ESP not to work around export control issues (we have AH for that) but to allow efficient, integrity-only processing where is it needed and where confidentiality is not required (and might cause technical problems, add undesirable overhead, etc.) Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 8 20:19:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04766 for ; Wed, 8 Sep 2004 20:19:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Cbd-0002WC-Bv; Wed, 08 Sep 2004 20:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5CZ9-0001th-1B for ipsec@megatron.ietf.org; Wed, 08 Sep 2004 20:13:31 -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 UAA04503 for ; Wed, 8 Sep 2004 20:13:29 -0400 (EDT) From: scott@hyperthought.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Ccs-0006Lk-3U for ipsec@ietf.org; Wed, 08 Sep 2004 20:17:23 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i89095d20911 for ; Wed, 8 Sep 2004 20:09:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i890AVtW026525 for ; Wed, 8 Sep 2004 20:10:31 -0400 (EDT) Message-Id: <200409090010.i890AVtW026525@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtWaaYZ; Wed, 8 Sep 04 20:10:27 -0400 To: ipsec@lists.tislabs.com Date: Wed, 8 Sep 2004 21:13:58 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 1 X-MSMail-Priority: High X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ipsec] Delivered Message (ipsec@lists.tislabs.com) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id i89095d20911 Content-Transfer-Encoding: quoted-printable Mail Delivery Failure - This mail couldn't be shown. ------------- failed message ------------- g9(Z3#<=F6%F+=E4n!#A+'_4c9iQqsvA%!<8hiRnN=DFFM~o !I)=FC1p=F6CMiTaAxpdUMF0GG!vUM;l4nC(G-!qDy3~vrXYe->qc (3sVq56z=DF9rDcqG8=DF6C9Gqh8kc*&,=DFTfi2L9-Tj1Rf~Vt hIaIAN2I0QeJ5T2(,Lm?!Q6CuJ>=DFLdy3;I(Y Translated message has been attached. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="message28607.zip.htm" Content-Disposition: attachment; filename="message28607.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: message28607.zip
Virus name: W32/Netsky.q@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Thu Sep 9 01:43:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05435 for ; Thu, 9 Sep 2004 01:43:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HdZ-00029o-NU; Thu, 09 Sep 2004 01:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HTr-0000Ot-0L for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 01:28:23 -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 BAA04576 for ; Thu, 9 Sep 2004 01:28:22 -0400 (EDT) Received: from [202.125.80.82] (helo=brahma.roc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5HXZ-0002iy-R7 for ipsec@ietf.org; Thu, 09 Sep 2004 01:32:18 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA19485; Thu, 9 Sep 2004 11:28:35 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA19478; Thu, 9 Sep 2004 11:28:34 +0530 Message-ID: <413FE9E8.4000401@rocsys.com> Date: Thu, 09 Sep 2004 10:58:08 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG References: <413D48DF.3010501@rocsys.com> <16701.31185.456226.175045@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yes. I went through IKEv2 document version 15. It did indicate HASH & URL is MUST. I feel, this is very strong statement. I feel mandating 3000 byte for one level certificate hierarchy and 8K for multiple certificate hierarchy would be better and simple. Regards, -Ravi Tero Kivinen wrote: >Ravi Kumar writes: > > >> Hi, >> I agree with Thomos. SHOULD is not strong enough. >> I also feel that, introducing notification message to >>indicate the capability of Maximum size it can receive is >>also not good enough. What can sender do if that happens, >>other than logging this? Run IKE over TCP Or use HASH & URL? >> Unfortunatley, both are 'MAY'. >> >> > >TCP is not MAY, it is not defined. > >HASH & URL is MUST. So it can also simply leave out certificates and >send HASH and URL instead, and assume that the other end will either >get those certificates from there, or then the authentication will >fail. Note, that 1280 bytes is enough for sending the normal end user >certificate, so actually the sender can send his own end user >certificate and hash and urls for the sub-CA certificates. If the >other end did actually have the same top-CA configured, he proboably >also have some knowledge of where to get the sub-CAs for that CA >too... > > > >> In my opinion, mandating 3000 bytes, if IKE implements >>certificates will solve most of deployment problems. By >>doing this, all implementations are forced to make the change. >> >> > >3000 bytes still does not solve the problem. It will make it so that >after that the sender can send 2 big certificates, but what if the >hiearchy is 8 levels deep? 1280 bytes works for end user certificates, >3000 bytes works for about 2-3 level deep hiearchy. 8000 will work for >8 level hiearchy etc. > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 9 06:05:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03124 for ; Thu, 9 Sep 2004 06:05:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Liq-0004Jw-FJ; Thu, 09 Sep 2004 06:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Lei-0003J5-8V for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 05:55:52 -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 FAA02612 for ; Thu, 9 Sep 2004 05:55:49 -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 1C5LiX-0006hI-3i for ipsec@ietf.org; Thu, 09 Sep 2004 05:59:50 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i899pOd21948 for ; Thu, 9 Sep 2004 05:51:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i899qpRj000784 for ; Thu, 9 Sep 2004 05:52:51 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com(195.101.245.16) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZNaGwb; Thu, 9 Sep 04 05:52:25 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 11:55:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Sep 2004 11:55:15 +0200 Message-ID: <2CAE5634D52E194BA393187E0568E1AC09A1B1@ftrdmel1.rd.francetelecom.fr> Thread-Index: AcSWUxsiSEUckgi7RweEEkGnfzzMqg== From: "LARREUR Elodie RD-CORE-LAN" To: X-OriginalArrivalTime: 09 Sep 2004 09:55:16.0423 (UTC) FILETIME=[1BB0A570:01C49653] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487831948==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1487831948== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49653.1B668721" This is a multi-part message in MIME format. ------_=_NextPart_001_01C49653.1B668721 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable unsuscribe ------_=_NextPart_001_01C49653.1B668721 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
unsuscribe
------_=_NextPart_001_01C49653.1B668721-- --===============1487831948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1487831948==-- From ipsec-bounces@ietf.org Thu Sep 9 11:41:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27490 for ; Thu, 9 Sep 2004 11:41:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Qu7-0007sF-DG; Thu, 09 Sep 2004 11:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5QqU-0006to-As for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 11:28:22 -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 LAA26765 for ; Thu, 9 Sep 2004 11:28:19 -0400 (EDT) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5QuL-0004Dq-23 for ipsec@ietf.org; Thu, 09 Sep 2004 11:32:22 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i89FRkbN015714; Thu, 9 Sep 2004 20:57:47 +0530 Message-ID: <4140785C.30309@netd.com> Date: Thu, 09 Sep 2004 21:05:56 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivasa Rao Addepalli Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter References: <4138466D.5090804@netd.com> <168101c491e6$e6748cc0$110fa8c0@SriniSony> <413EBA70.5050807@netd.com> <012801c495c4$afaaee00$6663a8c0@SriniSony> In-Reply-To: <012801c495c4$afaaee00$6663a8c0@SriniSony> X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 1.0 (+) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384103837==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0384103837== Content-Type: multipart/alternative; boundary="------------030106070603070304000703" This is a multi-part message in MIME format. --------------030106070603070304000703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, In the case of networks under different administrative control, NAT is applied and SPD policy selectors are NAT(public IP) addresses, so In this case can I select tunnel mode ?? If tunnel mode is selected then Inner ip ( NATed IP ) is same as outer ip address is it. please clarify Thx in advance mcreddy Srinivasa Rao Addepalli wrote: > It depends on deployment scenario. > > If the networks behind two SGs are under same administrative domain > (Example branch office > connectivity), there is no need for NAT as these networks can be > reached from one another. > In this SPD policy selectors would be IP address ranges of local networks. > > If the networks under different administrative control, it is possible > that both the networks having > same private subnet Or these two networks are not reachable from one > anonther. > In this case, as you said, NAT is required and SPD policy selectors > would need to have > NAT IP (Public IP)addresses. > > Srini > Intoto Inc. > www.intoto.com > > ----- Original Message ----- > From: M.Chenna kesava Reddy > To: Srinivasa Rao Addepalli > Cc: ipsec ; ipsec > > Sent: Wednesday, September 08, 2004 12:53 AM > Subject: Re: [Ipsec] ipsec packet passage through IPSEC and > FIREWALL enabledrouter > > Hi, > In the case of outbound packets if NAT is applied on the packets, > it is any way changes the > inner ip header from say local lan ip address to public ip > address, it may be to gateway ip > address(public) is it. so after NAT if you search the ipsec > policies with this address it may not > find correct SPD policy because the policy may be local lan subnet > behind this gateway to > other local lan subnet behind peer gateway is it? > So I think the spd match will fail here is it. > so what is the solution for this to overcome. > I can think of is we have one solution saying that during > configuration of SPD , we need to > allow only gateway to gateway configuration of SPD not the local > subnet to local subnet. > > thx in advance, > mcreddy > > > Srinivasa Rao Addepalli wrote: > >>I guess you are asking the case where IPSec and NAT functionality exist in >>the same unit. >> >>Note that, NAT is not required, if the private networks behind security gateways >>are under same administrator control. Administrator can ensure that, unique >>private IP address space is given to the networks under his control. >> >>If above is not the case, then NAT is applied such that, the remote systems see >>the public IP addresses (routable IP addresses). >> >>For outbound packets (Clear to Secure) >> - NAT is done first. >> - Run through the IPSec Policies. >> - If IPSec policy indicates 'Apply', packet is encrypted and outer IP header is added. >> >>In tunnel, the outer IP header would have source IP is local gateway IP address and >>destintion IP would be remote gateway IP address. >>Internal IP header is not touched. >>At the remote SG, outer IP header is removed and the internal IP packet is sent out on >>its local network. >> >>Srini >> >>Intoto Inc. >>www.intoto.com >>----- Original Message ----- >>From: "M.Chenna kesava Reddy" >>To: "ipsec" ; "ipsec" >>Sent: Friday, September 03, 2004 3:24 AM >>Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter >> >> >> >> >>>Hi, >>>I have some doubts regarding how the ipsec fits in to the security >>>router in tunnel mode , >>>please clarify. >>>Packet comming from internet with ipsec in tunnel mode to local lan : >>>eth0------------------eth1 >>>Packet from ipsec Decryption will comes back to look up on inner ip header >>>Here in tunnel mode outer ip header destination ip address will be SG >>>address, and once >>>it is decrypted it will give AH/ESP payload i.e inner IP packet back to >>>Ip look up and >>>it will look like comes with eth1 destined for local lan, and if we >>>apply SNAT it will >>>change the source address. I think SNAT won't for this ipsec packet. >>> >>>Packet comming from lan to internet in tunnel mode: >>> >>>eth1---------- >>>--------eth0 >>>Packet from ipsec Encryption will comes back to look up on Outer ip >>>header added by ipsec >>> >>>Here in tunnel mode outer ip header is added as source ip address will >>>be SG address, and once >>>it is encrypted the packet looks like inner IP packet is as is sent by >>>local lan host and goes back to >>>Ip look up and it will look like comes with eth1 destined for local >>>lan, and if we apply DNAT it will >>>change the destination ip address.I think DNAT won't work for ipsec >>>packets. >>> >>>Please clarify me how ipsec works in SNAT and DNAT cases and in SPD >>>policy says 10.1.1.1/24 to >>>20.1.2.3/24 Lans configured in Tunnel mode. >>>What will be the SA's in this case is it source ip SG1 to destination ip >>>SG2 or it is Lan ip's only. >>> >>>Thanks in advance, >>> >>>Regards >>>mcreddy >>> >>> >>>_______________________________________________ >>>Ipsec mailing list >>>Ipsec@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ipsec >>> >>> >> >> >> --------------030106070603070304000703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
In the case of networks under different administrative control, NAT is applied and
SPD policy selectors are NAT(public IP) addresses, so In this case can I select tunnel
mode ??
If tunnel mode is selected then Inner ip ( NATed IP ) is same as outer ip address is it.

please clarify
Thx in advance
mcreddy



Srinivasa Rao Addepalli wrote:
It depends on deployment scenario.
 
If the networks behind two SGs are under same administrative domain (Example branch office
connectivity), there is no need for NAT as these networks can be reached from one another.
In this SPD policy selectors would be IP address ranges of local networks.
 
If the networks under different administrative control, it is possible that both the networks having
same private subnet Or these two networks are not reachable from one anonther.
In this case, as you said, NAT is required and SPD policy selectors would need to have
NAT IP (Public IP)addresses.
 
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
Cc: ipsec ; ipsec
Sent: Wednesday, September 08, 2004 12:53 AM
Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter

Hi,
In the case of outbound packets if NAT is applied on the packets, it is any way changes the
inner ip header from say local lan ip address to public ip address, it may be to gateway ip
address(public) is it. so after NAT if  you search  the  ipsec policies with this address it may not
find correct SPD policy because the policy may be local lan subnet behind  this  gateway to
other local lan subnet behind peer gateway is it?
So I think the spd match will fail here is it.
so what is the solution for this to overcome.
I can think of is we have one solution saying that during configuration of SPD , we need to
allow only  gateway to gateway configuration of SPD not the local subnet to local subnet.

thx in advance,
mcreddy


Srinivasa Rao Addepalli wrote:
I guess you are asking the case where IPSec and NAT functionality exist in
the same unit. 

Note that, NAT is not required, if the private networks behind security gateways
are under same administrator control.  Administrator can ensure that, unique
private IP address space is given to the networks under his control.

If above is not the case, then NAT is applied such that, the remote systems see
the public IP addresses (routable IP addresses).

For outbound packets (Clear to Secure)
     - NAT is done first.
     - Run through the IPSec Policies.
     - If IPSec policy indicates 'Apply',  packet is encrypted and outer IP header is added.

In tunnel, the outer IP header would have source IP is local gateway IP address and
destintion IP would be remote gateway IP address.
Internal IP header is not touched. 
At the remote SG, outer IP header is removed and the internal IP packet is sent out on 
its local network.

Srini

Intoto Inc.
www.intoto.com
----- Original Message ----- 
From: "M.Chenna kesava Reddy" <mcreddy@netd.com>
To: "ipsec" <ipsec@lists.tislabs.com>; "ipsec" <ipsec@ietf.org>
Sent: Friday, September 03, 2004 3:24 AM
Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL enabledrouter


  
Hi,
I have some doubts regarding how the ipsec fits in to the security 
router in tunnel mode ,
please clarify.
Packet comming from internet with ipsec in tunnel mode to local lan :
eth0---<ethernet>---<Ip lookup>---<ipsec Decr>---<SNAT>---<ethernet>---eth1
Packet from ipsec Decryption will comes back to look up on inner ip header
Here in tunnel mode outer ip header destination ip address will be SG 
address, and once
it is decrypted it will give AH/ESP payload i.e inner IP packet back to  
Ip  look up and
it will look like comes with eth1 destined for local lan, and if we 
apply SNAT it will
change the source address. I think SNAT won't for this ipsec packet.

Packet comming from lan to internet in tunnel mode:

eth1---<ethernet>---<lookup>--<OuterIP as SG ip and ipsec Enc>-- 
--<DNAT>---<ethernet>---eth0
Packet from ipsec Encryption  will comes back to look up on Outer ip 
header added by ipsec

Here in tunnel mode outer ip header is added as source ip address will 
be SG address, and once
it is encrypted the packet looks like  inner IP packet is as is sent by 
local lan host and goes back to
Ip  look up  and it will look like comes with eth1 destined for local 
lan, and if we apply DNAT it will
change the destination ip address.I think DNAT won't work for ipsec 
packets.

Please clarify me how ipsec works in SNAT and DNAT cases and in SPD 
policy says 10.1.1.1/24 to
20.1.2.3/24  Lans configured in Tunnel mode.
What will be the SA's in this case is it source ip SG1 to destination ip 
SG2 or it is Lan ip's only.

Thanks in advance,

Regards
mcreddy


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--------------030106070603070304000703-- --===============0384103837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0384103837==-- From ipsec-bounces@ietf.org Thu Sep 9 12:46:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02756 for ; Thu, 9 Sep 2004 12:46:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5RjL-0005oe-07; Thu, 09 Sep 2004 12:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Rco-0003nG-Jy for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 12:18:19 -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 MAA00934 for ; Thu, 9 Sep 2004 12:18:15 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Rgh-0005If-4K for ipsec@ietf.org; Thu, 09 Sep 2004 12:22:20 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i89GIR9D015380; Thu, 9 Sep 2004 09:18:27 -0700 Message-ID: <00bf01c49688$983782f0$0301010a@SriniSony> From: "Srinivasa Rao Addepalli" To: References: <4138466D.5090804@netd.com><168101c491e6$e6748cc0$110fa8c0@SriniSony><413EBA70.5050807@netd.com><012801c495c4$afaaee00$6663a8c0@SriniSony> <4140785C.30309@netd.com> Subject: Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALLenabledrouter Date: Thu, 9 Sep 2004 09:18:08 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0854911934==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0854911934== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01C4964D.EBBE9340" This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C4964D.EBBE9340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes. You can select tunnel mode. You are right that source IP in both = inner and outer IP header would be same, if same IP address is used as NAT IP and as = well as local=20 security gateway IP address. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: M.Chenna kesava Reddy=20 To: Srinivasa Rao Addepalli=20 Cc: ipsec=20 Sent: Thursday, September 09, 2004 8:35 AM Subject: Re: [Ipsec] ipsec packet passage through IPSEC and = FIREWALLenabledrouter Hi, In the case of networks under different administrative control, NAT is = applied and=20 SPD policy selectors are NAT(public IP) addresses, so In this case can = I select tunnel mode ?? If tunnel mode is selected then Inner ip ( NATed IP ) is same as outer = ip address is it. please clarify Thx in advance mcreddy Srinivasa Rao Addepalli wrote: It depends on deployment scenario. If the networks behind two SGs are under same administrative domain = (Example branch office connectivity), there is no need for NAT as these networks can be = reached from one another. In this SPD policy selectors would be IP address ranges of local = networks. If the networks under different administrative control, it is = possible that both the networks having same private subnet Or these two networks are not reachable from one = anonther. In this case, as you said, NAT is required and SPD policy selectors = would need to have NAT IP (Public IP)addresses. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: M.Chenna kesava Reddy=20 To: Srinivasa Rao Addepalli=20 Cc: ipsec ; ipsec=20 Sent: Wednesday, September 08, 2004 12:53 AM Subject: Re: [Ipsec] ipsec packet passage through IPSEC and = FIREWALL enabledrouter Hi, In the case of outbound packets if NAT is applied on the packets, = it is any way changes the inner ip header from say local lan ip address to public ip = address, it may be to gateway ip address(public) is it. so after NAT if you search the ipsec = policies with this address it may not find correct SPD policy because the policy may be local lan subnet = behind this gateway to=20 other local lan subnet behind peer gateway is it? So I think the spd match will fail here is it. so what is the solution for this to overcome. I can think of is we have one solution saying that during = configuration of SPD , we need to allow only gateway to gateway configuration of SPD not the local = subnet to local subnet. thx in advance, mcreddy Srinivasa Rao Addepalli wrote: I guess you are asking the case where IPSec and NAT functionality exist = in the same unit.=20 Note that, NAT is not required, if the private networks behind security = gateways are under same administrator control. Administrator can ensure that, = unique private IP address space is given to the networks under his control. If above is not the case, then NAT is applied such that, the remote = systems see the public IP addresses (routable IP addresses). For outbound packets (Clear to Secure) - NAT is done first. - Run through the IPSec Policies. - If IPSec policy indicates 'Apply', packet is encrypted and outer = IP header is added. In tunnel, the outer IP header would have source IP is local gateway IP = address and destintion IP would be remote gateway IP address. Internal IP header is not touched.=20 At the remote SG, outer IP header is removed and the internal IP packet = is sent out on=20 its local network. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: "M.Chenna kesava Reddy" To: "ipsec" ; "ipsec" Sent: Friday, September 03, 2004 3:24 AM Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL = enabledrouter Hi, I have some doubts regarding how the ipsec fits in to the security=20 router in tunnel mode , please clarify. Packet comming from internet with ipsec in tunnel mode to local lan : eth0------------------eth1 Packet from ipsec Decryption will comes back to look up on inner ip = header Here in tunnel mode outer ip header destination ip address will be SG=20 address, and once it is decrypted it will give AH/ESP payload i.e inner IP packet back to = Ip look up and it will look like comes with eth1 destined for local lan, and if we=20 apply SNAT it will change the source address. I think SNAT won't for this ipsec packet. Packet comming from lan to internet in tunnel mode: eth1----------=20 --------eth0 Packet from ipsec Encryption will comes back to look up on Outer ip=20 header added by ipsec Here in tunnel mode outer ip header is added as source ip address will=20 be SG address, and once it is encrypted the packet looks like inner IP packet is as is sent by=20 local lan host and goes back to Ip look up and it will look like comes with eth1 destined for local=20 lan, and if we apply DNAT it will change the destination ip address.I think DNAT won't work for ipsec=20 packets. Please clarify me how ipsec works in SNAT and DNAT cases and in SPD=20 policy says 10.1.1.1/24 to 20.1.2.3/24 Lans configured in Tunnel mode. What will be the SA's in this case is it source ip SG1 to destination ip = SG2 or it is Lan ip's only. Thanks in advance, Regards mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_00BC_01C4964D.EBBE9340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes. You can select tunnel mode. You = are right that=20 source IP in both inner and outer
IP header would be same, if same IP = address is used=20 as NAT IP and as well as local
security gateway IP = address.
 
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From:=20 M.Chenna = kesava=20 Reddy
Cc: ipsec
Sent: Thursday, September 09, = 2004 8:35=20 AM
Subject: Re: [Ipsec] ipsec = packet passage=20 through IPSEC and FIREWALLenabledrouter

Hi,
In the case of networks under different = administrative=20 control, NAT is applied and
SPD policy selectors are NAT(public = IP)=20 addresses, so In this case can I select tunnel
mode ??
If tunnel = mode is=20 selected then Inner ip ( NATed IP ) is same as outer ip address is=20 it.

please clarify
Thx in=20 advance
mcreddy



Srinivasa Rao Addepalli wrote:
It depends on deployment = scenario.
 
If the networks behind two SGs are = under same=20 administrative domain (Example branch office
connectivity), there is no need for = NAT as=20 these networks can be reached from one another.
In this SPD policy selectors would = be IP=20 address ranges of local networks.
 
If the networks under different = administrative=20 control, it is possible that both the networks having
same private subnet Or these two = networks are=20 not reachable from one anonther.
In this case, as you said, NAT is = required and=20 SPD policy selectors would need to have
NAT IP (Public = IP)addresses.
 
Srini
Intoto Inc.
www.intoto.com
-----=20 Original Message ----- From:=20 M.Chenna kesava=20 Reddy To:=20 Srinivasa Rao=20 Addepalli Cc:=20 ipsec ; ipsec Sent:=20 Wednesday, September 08, 2004 12:53 AM Subject:=20 Re: [Ipsec] ipsec packet passage through IPSEC and FIREWALL=20 enabledrouter

Hi,
In the case of outbound packets if NAT is = applied on=20 the packets, it is any way changes the
inner ip header from say = local=20 lan ip address to public ip address, it may be to gateway=20 ip
address(public) is it. so after NAT if  you = search =20 the  ipsec policies with this address it may not
find = correct SPD=20 policy because the policy may be local lan subnet behind  = this =20 gateway to
other local lan subnet behind peer gateway is = it?
So I=20 think the spd match will fail here is it.
so what is the = solution for=20 this to overcome.
I can think of is we have one solution saying = that=20 during configuration of SPD , we need to
allow only  = gateway to=20 gateway configuration of SPD not the local subnet to local=20 subnet.

thx in advance,
mcreddy


Srinivasa Rao = Addepalli wrote:
I guess you are asking the case where IPSec =
and NAT functionality exist in
the same unit.=20

Note that, NAT is not required, if the private networks behind security =
gateways
are under same administrator control.  Administrator can ensure that, =
unique
private IP address space is given to the networks under his control.

If above is not the case, then NAT is applied such that, the remote =
systems see
the public IP addresses (routable IP addresses).

For outbound packets (Clear to Secure)
     - NAT is done first.
     - Run through the IPSec Policies.
     - If IPSec policy indicates 'Apply',  packet is encrypted and outer =
IP header is added.

In tunnel, the outer IP header would have source IP is local gateway IP =
address and
destintion IP would be remote gateway IP address.
Internal IP header is not touched.=20
At the remote SG, outer IP header is removed and the internal IP packet =
is sent out on=20
its local network.

Srini

Intoto Inc.
www.intoto.com
----- Original Message -----=20
From: "M.Chenna kesava Reddy" <mcreddy@netd.com>
To: "ipsec" <ipsec@lists.tislabs.com>; "ipsec" <ipsec@ietf.org>
Sent: Friday, September 03, 2004 3:24 AM
Subject: [Ipsec] ipsec packet passage through IPSEC and FIREWALL =
enabledrouter


  
Hi,
I have some doubts regarding how the ipsec fits in to the security=20
router in tunnel mode ,
please clarify.
Packet comming from internet with ipsec in tunnel mode to local lan :
eth0---<ethernet>---<Ip lookup>---<ipsec =
Decr>---<SNAT>---<ethernet>---eth1
Packet from ipsec Decryption will comes back to look up on inner ip =
header
Here in tunnel mode outer ip header destination ip address will be SG=20
address, and once
it is decrypted it will give AH/ESP payload i.e inner IP packet back to  =

Ip  look up and
it will look like comes with eth1 destined for local lan, and if we=20
apply SNAT it will
change the source address. I think SNAT won't for this ipsec packet.

Packet comming from lan to internet in tunnel mode:

eth1---<ethernet>---<lookup>--<OuterIP as SG ip and ipsec =
Enc>--=20
--<DNAT>---<ethernet>---eth0
Packet from ipsec Encryption  will comes back to look up on Outer ip=20
header added by ipsec

Here in tunnel mode outer ip header is added as source ip address will=20
be SG address, and once
it is encrypted the packet looks like  inner IP packet is as is sent by=20
local lan host and goes back to
Ip  look up  and it will look like comes with eth1 destined for local=20
lan, and if we apply DNAT it will
change the destination ip address.I think DNAT won't work for ipsec=20
packets.

Please clarify me how ipsec works in SNAT and DNAT cases and in SPD=20
policy says 10.1.1.1/24 to
20.1.2.3/24  Lans configured in Tunnel mode.
What will be the SA's in this case is it source ip SG1 to destination ip =

SG2 or it is Lan ip's only.

Thanks in advance,

Regards
mcreddy


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/ipsec

_______________________________________________
Ipsec = mailing=20 = list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_00BC_01C4964D.EBBE9340-- --===============0854911934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0854911934==-- From ipsec-bounces@ietf.org Thu Sep 9 15:08:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13098 for ; Thu, 9 Sep 2004 15:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UAV-0004wI-L5; Thu, 09 Sep 2004 15:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5U8m-0002LF-GA for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 14:59:28 -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 OAA12234 for ; Thu, 9 Sep 2004 14:59:26 -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 1C5UCf-0008OM-Ir for ipsec@ietf.org; Thu, 09 Sep 2004 15:03:31 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i89It1d25360 for ; Thu, 9 Sep 2004 14:55:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i89IuSLw008923 for ; Thu, 9 Sep 2004 14:56:28 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5yaWzr; Thu, 9 Sep 04 14:56:25 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i89Ix7jf007295; Thu, 9 Sep 2004 14:59:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200409032247.i83MlKSj064922@givry.rennes.enst-bretagne.fr> References: <200409032247.i83MlKSj064922@givry.rennes.enst-bretagne.fr> Date: Thu, 9 Sep 2004 14:58:36 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.0 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Francis, I looked at RFC 3697. It does state that AH does not protect flow labels, which is consistent with the old AH spec (RFC 2402). So, if we were to change this in the new AH spec, there would be a conflict. Also, the security analysis in 3697 argues that since there is no protection of the flow spec value, intermediate systems cannot rely on it and an end IPsec implementation cannot rely on it in transport mode. I agree that it is unlikely that we would be able to manage key distribution for intermediate systems to be able to check the AH ICV, which supports your argument that it is not worth including it in the ICV computation. However, if we choose to maintain backward compatibility with 2402, we need to clarify in 2402bis that this is the reason for not including the value in the ICV computation, as opposed to the current, erroneous rationale. Is the WG comfortable with the status quo, i.e., NOT including the flow label in the ICV, despite the fact that it is immutable? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 9 20:19:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19143 for ; Thu, 9 Sep 2004 20:19:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Z3M-0006yy-MH; Thu, 09 Sep 2004 20:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Yzc-0006FO-FN for ipsec@megatron.ietf.org; Thu, 09 Sep 2004 20:10:20 -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 UAA18708 for ; Thu, 9 Sep 2004 20:10:18 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Z3Z-0000kx-Nt for ipsec@ietf.org; Thu, 09 Sep 2004 20:14:26 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8A05md13703 for ; Thu, 9 Sep 2004 20:05:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8A07Hsd015984 for ; Thu, 9 Sep 2004 20:07:17 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net(66.80.10.146) by nutshell.tislabs.com via csmap (V6.0) id srcAAATwaanF; Thu, 9 Sep 04 20:07:14 -0400 Received: from vamshi.intotoinc.com ([10.1.5.47]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i8A0AN9E030033 for ; Thu, 9 Sep 2004 17:10:23 -0700 Message-Id: <5.2.0.9.0.20040909165609.02a98c88@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Sep 2004 17:05:32 -0700 To: ipsec@lists.tislabs.com From: vamsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ipsec] IKEv2 and EAP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Some questions when EAP and IKEv2 are used together. EAP model allows Authenticator to be different from Authentication Server. Typically RADIUS Server acts as Authentication server. IKEv2 responder acts as Authenticator. IKEv2 initiator is called peer in EAP. My assumption, when I was going through 2.16 of IKEv2 document is that, IKE_AUTH exchange type is used for transferring the EAP payload in IKE. I also would assume that 'Response bit' of IKE header is also honored. Fortunately, the number of EAP messages, in no retransmission case, are always odd. With first EAP message going as part of response from Authenticator, IKE request/response AUTH exchange works for rest of EAP messages. EAP, itself does retransmissions. Since, IKEv2 provides some sort of reliability (with retransmissions), it can be safely assumed that between IKE peers, messages are not lost. But, messages can be lost during communicating with RADIUS or within the Authenticator. In that case, EAP retransmits the packet. If this happens, the number of EAP messages between IKE peers may not be odd. In that case how does Request/Response exchange work? Am I on right track so far? If so, I can think of two options. 1. Don't interpret the 'Response' bit. Always set it as 'Request" and no response should be expected by the sender. In this case, IKE is only acting as transport to send EAP packets between EAP client and EAP Server. 2. Have some logic, where IKE at the Authenticator interprets the EAP header and if it is duplicate EAP message (which was sent before), then don't send the EAP packet. This may require buffering the EAP response so that, it can respond to EAP request in case of duplicate request. Comments? Thanks Vamsi www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 01:29:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09319 for ; Fri, 10 Sep 2004 01:29:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5dwC-0000jK-JS; Fri, 10 Sep 2004 01:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5dvX-0000bv-6Z for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 01:26:27 -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 BAA09123 for ; Fri, 10 Sep 2004 01:26:25 -0400 (EDT) Received: from [202.125.80.82] (helo=brahma.roc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5dzV-0006Cn-LR for ipsec@ietf.org; Fri, 10 Sep 2004 01:30:35 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA22470 for ipsec@ietf.org; Fri, 10 Sep 2004 11:26:39 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA22463 for ; Fri, 10 Sep 2004 11:26:37 +0530 Message-ID: <41413AF2.6010103@rocsys.com> Date: Fri, 10 Sep 2004 10:56:10 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Configuration Payload clarification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Section 3.15 (Configuration Payload) indicates that CFG_REQUEST/CFG-REPLY may optionally be added to any IKE request. Section 2.19 indicates that IRAC MUST request the IRAS controlled address in IKE-AUTH exchange. Does it mean that CFG-REQUEST/CFG-REPLY used to get the internal IP address on remote network, MUST be sent in IKE-AUTH exchange? If these payloads are with IP address attributes sent in any exchange (including informational), then can it be considered as ERROR by the receiving implementation? Thanks Ravi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 01:36:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09838 for ; Fri, 10 Sep 2004 01:36:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5e28-0001Xd-HN; Fri, 10 Sep 2004 01:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5dxr-0000rJ-VQ for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 01:28:51 -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 BAA09234 for ; Fri, 10 Sep 2004 01:28:50 -0400 (EDT) Received: from [202.125.80.82] (helo=brahma.roc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5e1p-0006F8-DC for ipsec@ietf.org; Fri, 10 Sep 2004 01:33:00 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id LAA22486 for ipsec@ietf.org; Fri, 10 Sep 2004 11:29:09 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id LAA22479 for ; Fri, 10 Sep 2004 11:29:07 +0530 Message-ID: <41413B88.5060106@rocsys.com> Date: Fri, 10 Sep 2004 10:58:40 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ipsec] INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Typically, there can be multiple subnetworks behind Edge device (IRAS). I expect that, IRAC would need to know these subnetworks so that it can redirect (by adding appropriate routes) the traffic through the tunnel for these networks. IRAS can inform these networks via INTERNAL_IPx_SUBNET attributes. Isn't the purpose of these attributes? If so, why is this attribute not treated as 'Multi-Valued'? Thanks, -Ravi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 04:30:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03505 for ; Fri, 10 Sep 2004 04:30:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5glQ-0005sQ-Dp; Fri, 10 Sep 2004 04:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5ggy-0005Kw-MI for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 04:23:37 -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 EAA02929 for ; Fri, 10 Sep 2004 04:23:34 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gkz-0000ct-BG for ipsec@ietf.org; Fri, 10 Sep 2004 04:27:46 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8A8J9d29045 for ; Fri, 10 Sep 2004 04:19:10 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8A8Kaaw008549 for ; Fri, 10 Sep 2004 04:20:36 -0400 (EDT) Received: from p2.piuha.net(131.160.192.2) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQ1aiRq; Fri, 10 Sep 04 04:20:34 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 23A5E89873; Fri, 10 Sep 2004 11:23:28 +0300 (EEST) Message-ID: <4141644A.60901@kolumbus.fi> Date: Fri, 10 Sep 2004 11:22:34 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vamsi Subject: Re: [Ipsec] IKEv2 and EAP References: <5.2.0.9.0.20040909165609.02a98c88@10.1.5.10> In-Reply-To: <5.2.0.9.0.20040909165609.02a98c88@10.1.5.10> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit vamsi wrote: > EAP model allows Authenticator to be different from Authentication > Server. > Typically RADIUS Server acts as Authentication server. > IKEv2 responder acts as Authenticator. IKEv2 initiator is called > peer in > EAP. Yes. > My assumption, when I was going through 2.16 of IKEv2 document is that, > IKE_AUTH exchange type is used for transferring the EAP payload in IKE. > I also would assume that 'Response bit' of IKE header is also honored. > Fortunately, the number of EAP messages, in no retransmission case, are > always odd. With first EAP message going as part of response from > Authenticator, IKE request/response AUTH exchange works for rest of EAP > messages. Yes. > EAP, itself does retransmissions. Since, IKEv2 provides some sort of > reliability (with retransmissions), it can be safely assumed that > between IKE peers, > messages are not lost. That's right. To put it in other words, EAP gives a message for IKEv2 and IKEv2 will either deliver this message, or fail and the whole connection attempt is abandoned. > But, messages can be lost during communicating with > RADIUS or within the Authenticator. In that case, EAP retransmits > the packet. I don't think this is right. AAA protocols have their own retransmission. If the IKEv2 box does not get an answer from a RADIUS server, it will retry the Access-Request. Similarly, if Diameter is used then the underlying TCP/SCTP protocols handle reliability. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 11:46:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07862 for ; Fri, 10 Sep 2004 11:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5nQV-0003Rk-Sz; Fri, 10 Sep 2004 11:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5n7r-0000G4-GN for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 11:15:48 -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 LAA05418 for ; Fri, 10 Sep 2004 11:15:44 -0400 (EDT) Received: from transport.mindtree.com ([202.56.255.241] helo=mtv01exog01.mindtree.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5nBv-0000EH-HS for ipsec@ietf.org; Fri, 10 Sep 2004 11:20:01 -0400 Received: from mtv01ex04.mindtree.com ([172.20.32.41]) by mtv01exog01.mindtree.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Sep 2004 20:44:32 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Date: Fri, 10 Sep 2004 20:44:32 +0530 Message-ID: <5959EA4638D8734599AB75EAAFBB6FEF3CCD6F@mtv01ex04.mindtree.com> Thread-Topic: "Non-initial" vs. "Initial" Fragments Definition thread-index: AcSXSN/U19IFIpCfSumNa6umIFKSMA== From: "Vishwanath Edavayyanamath" To: X-OriginalArrivalTime: 10 Sep 2004 15:14:32.0829 (UTC) FILETIME=[E035FAD0:01C49748] X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [Ipsec] "Non-initial" vs. "Initial" Fragments Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598149135==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0598149135== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49748.DFC78912" This is a multi-part message in MIME format. ------_=_NextPart_001_01C49748.DFC78912 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, In the draft-ietf-ipsec-rfc2401bis-02.txt page 18 it is stated that, =20 And the phrase "initial" fragment is used to mean a fragment that contains all the = selector values needed for access control. However, it should be noted = that for IPv6, which fragment contains the Next Layer Protocol and ports (or ICMP message type/code or Mobility Header type) will depend on the kind and number of extension headers present. The "initial" fragment might not be the first fragment. ^^^^^^^^^^^^^^^^^^^^^^^ =20 In which case this will apply? while there is a minimum packet size = defined (576 fragmented or not) and the headers in context (next layer protocol, ports, etc) pretty much fit in the minimum packet size defined (again = 576 fragmented or otherwise). =20 So, I feel the statement is redundant and can be removed. =20 =20 Regards Vishwa DISCLAIMER: This message (including attachment if any) is confidential and may be = privileged. Before opening attachments please check them for viruses and = defects. MindTree Consulting Private Limited (MindTree) will not be = responsible for any viruses or defects or any forwarded attachments = emanating either from within MindTree or outside. If you have received = this message by mistake please notify the sender by return e-mail and = delete this message from your system. Any unauthorized use or = dissemination of this message in whole or in part is strictly = prohibited. Please note that e-mails are susceptible to change and = MindTree shall not be liable for any improper, untimely or incomplete = transmission. ------_=_NextPart_001_01C49748.DFC78912 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
   =20 In the draft-ietf-ipsec-rfc2401bis-02.txt page 18 it is = stated=20 that,
 
And = the phrase=20 "initial"
       fragment is used to = mean a=20 fragment that contains all the = selector
      =20 values needed for access control. However, it should be noted=20 that
       for IPv6, which fragment = contains=20 the Next Layer Protocol and
       = ports (or=20 ICMP message type/code or Mobility Header type)=20 will
       depend on the kind and = number of=20 extension headers present.
       The = "initial"=20 fragment might not be the first=20 fragment.
          =             &= nbsp;           &n= bsp;        =20 ^^^^^^^^^^^^^^^^^^^^^^^
 
In=20 which case this will apply? while there is a minimum packet size defined = (576=20 fragmented or not) and the headers in context (next layer protocol, = ports, etc)=20 pretty much fit in the minimum packet size defined (again 576 fragmented = or=20 otherwise).
 
So, I=20 feel the statement is redundant and can be = removed.
 
 
Regards
Vishwa

DISCLAIMER:
T= his message (including attachment if any) is confidential and may be = privileged. Before opening attachments please check them for viruses and = defects. MindTree Consulting Private Limited (MindTree) will not be = responsible for any viruses or defects or any forwarded attachments = emanating either from within MindTree or outside. If you have received = this message by mistake please notify the sender by return e-mail and = delete this message from your system. Any unauthorized use or = dissemination of this message in whole or in part is strictly = prohibited. Please note that e-mails are susceptible to change and = MindTree shall not be liable for any improper, untimely or incomplete = transmission. ------_=_NextPart_001_01C49748.DFC78912-- --===============0598149135== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0598149135==-- From ipsec-bounces@ietf.org Fri Sep 10 12:34:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11411 for ; Fri, 10 Sep 2004 12:34:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5nq2-0001gR-Ti; Fri, 10 Sep 2004 12:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5nW8-0004mS-4N for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 11:40:52 -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 LAA07299 for ; Fri, 10 Sep 2004 11:40:48 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5nZx-0000jH-Ov for ipsec@ietf.org; Fri, 10 Sep 2004 11:45:06 -0400 Received: from thunklet ([127.0.0.1] helo=thunk.org) by thunker.thunk.org with esmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1C5nV4-0007uN-00; Fri, 10 Sep 2004 11:39:46 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1C5nSS-0001yo-82; Fri, 10 Sep 2004 11:37:04 -0400 Date: Fri, 10 Sep 2004 11:37:04 -0400 From: "Theodore Ts'o" To: Russ Housley Subject: Re: [Ipsec] Two IKEv2 issues from the IESG Message-ID: <20040910153704.GA7565@thunk.org> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> User-Agent: Mutt/1.5.6+20040818i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipsec@ietf.org, margaret@thingmagic.com, narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, Sep 02, 2004 at 09:53:55AM -0400, Russ Housley wrote: > Here are two issues from the IESG regarding IKEv2. I hope that these can > be quickly resolved by the IPsec Working Group. Charlie has already agreed > to quickly update the document to reflect the Working Group decision, once > consensus is clear. > ELLIPTIC CURVES > > I am raising the second issue. In 2002, the working group decided not to > pursue elliptic curves. Hilarie made several presentation advocating them; > her slides are in the minutes. However, the IPR concerns associate with > elliptic curves lead the working group to classic Diffie-Hellman. Yet, two > elliptic curve groups are still included in the document. This seems to > contradict the working group decision. No one has objected to this change. So Charlie, please remove elliptic curve groups from Appendix B. > MINIMUM PACKET SIZE Please add the following text: > "All IKEv2 implementations MUST be able to receive and process > packets that are up to 1280 bytes long, and they SHOULD be able > to receive and process packets that are up to 3000 bytes long." There have been a few people who have suggested that they would prefer a simple 3000 byte MUST requirement instead. However, these people seem to have been in the minority, and given that 1280 bytes is enough for a 1024 bit certificate, and 2048 with modest certificate extensions, it seems that 1280 byte requirement is sufficient for many applications. In addition, it is likely that most implementations will implemement SHOULD requirements. Do any of those people advocating the 3000 byte MUST object strenously to the above text requiring a 1280 MUST, and a 3000 byte SHOULD? - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 13:34:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15980 for ; Fri, 10 Sep 2004 13:34:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5pCx-00057F-EY; Fri, 10 Sep 2004 13:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5otH-0000iz-5H for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 13:08:51 -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 NAA14254 for ; Fri, 10 Sep 2004 13:08:47 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5oxM-0002lo-Nk for ipsec@ietf.org; Fri, 10 Sep 2004 13:13:06 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8AH969E026299; Fri, 10 Sep 2004 10:09:06 -0700 Message-ID: <089d01c49758$d1523b40$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Ravi Kumar" , References: <41413AF2.6010103@rocsys.com> Subject: Re: [Ipsec] Configuration Payload clarification Date: Fri, 10 Sep 2004 10:08:39 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ravi Kumar" To: Sent: Thursday, September 09, 2004 10:26 PM Subject: [Ipsec] Configuration Payload clarification > Hi, > Section 3.15 (Configuration Payload) indicates that > CFG_REQUEST/CFG-REPLY may optionally be added to any IKE > request. > > Section 2.19 indicates that IRAC MUST request the > IRAS controlled address in IKE-AUTH exchange. > > Does it mean that CFG-REQUEST/CFG-REPLY used to get > the internal IP address on remote network, MUST be sent in > IKE-AUTH exchange? If these payloads are with IP address > attributes sent in any exchange (including informational), > then can it be considered as ERROR by the receiving > implementation? That is my understanding too. Requesting internal address MUST happen in AUTH exchange. As I understand, only reqeusting application version happens in informational exchange. In future, some more attributes might be defined which can go in Informational exchange. As on today, I believe 'application version' is the only attribute (as part of CP) can go in Informational exchange. > > Thanks > Ravi > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 13:41:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16400 for ; Fri, 10 Sep 2004 13:41:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5pEo-0005ie-Vw; Fri, 10 Sep 2004 13:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5p2C-0002r2-W1 for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 13:18:05 -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 NAA14933 for ; Fri, 10 Sep 2004 13:18:01 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5p6I-0002zF-SP for ipsec@ietf.org; Fri, 10 Sep 2004 13:22:20 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8AHHrdH014721; Fri, 10 Sep 2004 22:47:53 +0530 Message-Id: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 Sep 2004 23:02:11 +0530 To: ipsec@ietf.org From: Uma Shankar Ch Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pasi.eronen@nokia.com Subject: [Ipsec] Extended Authentication IKEv1 - IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0056474363==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0056474363== Content-Type: multipart/alternative; boundary="=====================_1444823==_.ALT" --=====================_1444823==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Can IKEv1 be used with any mutual authentication method using Xauth? Am not aware of it. In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the Client by the server. But, in IKEv1 it happens after establishing trusted authentication channel with whatever way authentication is configured ( by pre-shared key or public key certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating method? In this context, in summary, I have the following questions 1. What is the rationale of changing the way extended authentication starts from v1 to v2? Of course, there would be definitely certain advantages with this change, but am not able to understand what are those. (i) Is that, the repercussion of this change is the text in Security Considerations section (Section 5) of the draft? "Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates." 2. I could not find any text relating to the change of the way extended authentication happen in IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt". 3. The last minor point. (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the new one being RFC 3748? (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..." it should have been "Extensible Authentication..." Can any body clarify on this? -Uma www.intoto.com --=====================_1444823==_.ALT Content-Type: text/html; charset="us-ascii"

Can IKEv1 be used with any mutual authentication  method using Xauth?
Am not aware of it.

In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the
Client by the server. But, in IKEv1 it happens after establishing trusted authentication
channel with whatever way authentication is configured ( by pre-shared key or public key
certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating
method?

In this context, in summary, I have the following questions

1. What is the rationale of changing the way extended authentication starts from v1 to v2?

Of course, there would be definitely certain advantages with this change, but am not able to
 understand what are those.

 (i) Is that, the repercussion of this change is the text in Security Considerations section
(Section 5) of the draft?

"Use of EAP authentication changes the probing possibilities somewhat.
 When EAP authentication is used, the responder proves its identity
 before the initiator does, so an initiator that knew the name of a
 valid initiator could probe the responder for both its name and
 certificates."

2.  I could not find any text relating to the change of the way extended authentication happen in  IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt".

3. The last minor point.

 (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the
new one being  RFC 3748?
 (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..."
it should have been "Extensible Authentication..."

Can any body clarify on this?

-Uma

www.intoto.com



--=====================_1444823==_.ALT-- --===============0056474363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0056474363==-- From ipsec-bounces@ietf.org Fri Sep 10 14:05:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17765 for ; Fri, 10 Sep 2004 14:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5pcC-0002kT-79; Fri, 10 Sep 2004 13:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5pKO-0006vd-3s for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 13:36:52 -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 NAA16158 for ; Fri, 10 Sep 2004 13:36:50 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5pOU-0003KU-N5 for ipsec@ietf.org; Fri, 10 Sep 2004 13:41:07 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8AHb89D027204; Fri, 10 Sep 2004 10:37:08 -0700 Message-ID: <08cd01c4975c$bbfe3100$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Ravi Kumar" , References: <41413B88.5060106@rocsys.com> Subject: Re: [Ipsec] INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2 Date: Fri, 10 Sep 2004 10:36:41 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ravi Kumar" To: Sent: Thursday, September 09, 2004 10:28 PM Subject: [Ipsec] INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2 > Typically, there can be multiple subnetworks behind Edge > device (IRAS). I expect that, IRAC would need to know these > subnetworks so that it can redirect (by adding appropriate > routes) the traffic through the tunnel for these networks. > > IRAS can inform these networks via INTERNAL_IPx_SUBNET > attributes. Isn't the purpose of these attributes? If so, > why is this attribute not treated as 'Multi-Valued'? This is not explicitely mentioned in the document. But this is what I think is intended. Since, in IKEv2, multiple Traffic Selectors are possible within one TS payload, Traffic Selectors are used to represent the internal networks. Suppose, if there are three internal networks ie 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24, then following TS payloads are sent to the Initiator as part of response to AUTH exchange request (Assume that, 192.168.1.10 address is given to Initiator) TSi = (0,0-65536, 192.168.1.0-192.168.1.10) TSr= ( (0, 0-65536, 192.168.1.0-192.168.1.255) (0, 0-65536, 192.168.2.0-192.168.2.255) (0, 0-65536, 192.168.3.0-192.168.3.255) > > Thanks, > -Ravi > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 14:34:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19452 for ; Fri, 10 Sep 2004 14:34:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5q0G-0007hu-Ud; Fri, 10 Sep 2004 14:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5pil-0003vv-CM for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 14:02:03 -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 OAA17567 for ; Fri, 10 Sep 2004 14:02:01 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5pmq-0003rW-L0 for ipsec@ietf.org; Fri, 10 Sep 2004 14:06:18 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8AI1rBq019749 for ; Fri, 10 Sep 2004 23:31:53 +0530 Message-Id: <5.1.0.14.0.20040910234044.02a9eb10@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 Sep 2004 23:46:11 +0530 To: ipsec@ietf.org From: Uma Shankar Ch Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ipsec] EAP_ONLY_AUTHENTICATION -- IDr payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0048989267==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0048989267== Content-Type: multipart/alternative; boundary="=====================_4085156==_.ALT" --=====================_4085156==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Can any body answer this. As, In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the Client by the server.(Of course it is protected) The IKE responder node should send IDr in response to the third message according to "draft-eronen-ipsec-ikev2-eap-auth-01.txt" ? HDR, SK { IDi, [IDr,] EAP_ONLY_AUTHENTICATION, SAi2, TSi, TSr} --> <-- HDR, SK { IDr, EAP(Request) } It could have been postponed up till the last message where SAr2, TSi, TSr are sent by responder. My point is why responder should expose his identity before authenticating the client in this scenario? Regards, Uma www.intoto.com --=====================_4085156==_.ALT Content-Type: text/html; charset="us-ascii"
Can any body answer this.

As, In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the
Client by the server.(Of course it is protected)
The IKE responder node should send IDr in response to the third message according to
 "draft-eronen-ipsec-ikev2-eap-auth-01.txt" ?

HDR, SK { IDi, [IDr,] EAP_ONLY_AUTHENTICATION,
                   SAi2, TSi, TSr}  -->

                             <--   HDR, SK { IDr, EAP(Request) }

It could have been postponed up till the last message where SAr2, TSi, TSr  are sent by responder. My point is why responder should expose his identity before authenticating the client in this scenario?

Regards,
Uma
www.intoto.com

--=====================_4085156==_.ALT-- --===============0048989267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0048989267==-- From ipsec-bounces@ietf.org Fri Sep 10 14:59:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21596 for ; Fri, 10 Sep 2004 14:59:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5qPV-0005o0-Uq; Fri, 10 Sep 2004 14:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5qEL-0002ZX-0i for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 14:34:41 -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 OAA19516 for ; Fri, 10 Sep 2004 14:34:38 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5qIQ-0004UR-Ne for ipsec@ietf.org; Fri, 10 Sep 2004 14:38:56 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 777988987C; Fri, 10 Sep 2004 21:34:29 +0300 (EEST) Message-ID: <4141F381.4090902@kolumbus.fi> Date: Fri, 10 Sep 2004 21:33:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Uma Shankar Ch Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 References: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> In-Reply-To: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, pasi.eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Uma, I don't have an answer to your primary question, but: > 2. I could not find any text relating to the change of the way extended > authentication happen in IKEv1 and the proposed standard in IKEv2 in > *"Appendix A: Summary of changes from IKEv1"* of > *"draft-ietf-ipsec-ikev2-15.txt"*. Yes. I would suggest adding the following text to Appendix A: "(NN) To support authentication through the Extensible Authentication Protocol (EAP) [ref]." > 3. The last minor point. > > (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which > is obsolete and the > new one being RFC 3748? Yes, which is a problem that people have complained about :-) http://www.vpnc.org/ietf-ipsec/mail-archive/msg00474.html Please refer to RFC 3748. (It strikes me that there's probably other things that have not been adopted in the IKEv2 draft. For instance, the above message complained about a typo s/NAC/NAK, which is still wrong in -15...) > (ii) In the text wherever applicable, the draft is mentioning > "*Extended Authentication *..." > it should have been "*Extensible Authentication*..." Right. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 19:02:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18001 for ; Fri, 10 Sep 2004 19:02:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5uJT-00046q-Fm; Fri, 10 Sep 2004 18:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5uHg-0003il-Me for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 18:54:25 -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 SAA17599 for ; Fri, 10 Sep 2004 18:54:21 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5uLp-00049H-BC for ipsec@ietf.org; Fri, 10 Sep 2004 18:58:42 -0400 Received: from [10.1.5.96] ([10.1.5.96]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i8AMsV9D004722; Fri, 10 Sep 2004 15:54:32 -0700 Subject: Re: [Ipsec] Two IKEv2 issues from the IESG From: suren To: "Theodore Ts'o" In-Reply-To: <20040910153704.GA7565@thunk.org> References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> <20040910153704.GA7565@thunk.org> Content-Type: text/plain Organization: Intoto, Inc. Message-Id: <1094856244.2093.3.camel@suren> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 Sep 2004 15:44:04 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley , narten@us.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suren@intotoinc.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Since, IKE over TCP is not defined, I go with making 3K bytes MUST for IKE over UDP. Suren Intoto Inc. On Fri, 2004-09-10 at 08:37, Theodore Ts'o wrote: > On Thu, Sep 02, 2004 at 09:53:55AM -0400, Russ Housley wrote: > > Here are two issues from the IESG regarding IKEv2. I hope that these can > > be quickly resolved by the IPsec Working Group. Charlie has already agreed > > to quickly update the document to reflect the Working Group decision, once > > consensus is clear. > > > ELLIPTIC CURVES > > > > I am raising the second issue. In 2002, the working group decided not to > > pursue elliptic curves. Hilarie made several presentation advocating them; > > her slides are in the minutes. However, the IPR concerns associate with > > elliptic curves lead the working group to classic Diffie-Hellman. Yet, two > > elliptic curve groups are still included in the document. This seems to > > contradict the working group decision. > > No one has objected to this change. So Charlie, please remove > elliptic curve groups from Appendix B. > > > MINIMUM PACKET SIZE > > Please add the following text: > > > "All IKEv2 implementations MUST be able to receive and process > > packets that are up to 1280 bytes long, and they SHOULD be able > > to receive and process packets that are up to 3000 bytes long." > > There have been a few people who have suggested that they would prefer > a simple 3000 byte MUST requirement instead. However, these people > seem to have been in the minority, and given that 1280 bytes is enough > for a 1024 bit certificate, and 2048 with modest certificate > extensions, it seems that 1280 byte requirement is sufficient for many > applications. In addition, it is likely that most implementations > will implemement SHOULD requirements. > > Do any of those people advocating the 3000 byte MUST object strenously > to the above text requiring a 1280 MUST, and a 3000 byte SHOULD? > > - Ted > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 19:49:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20762 for ; Fri, 10 Sep 2004 19:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5v7D-00088j-OC; Fri, 10 Sep 2004 19:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5v2E-0006It-Kc for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 19:42:30 -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 TAA20255 for ; Fri, 10 Sep 2004 19:42:28 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5v6N-0004tQ-NJ for ipsec@ietf.org; Fri, 10 Sep 2004 19:46:49 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8ANftS29004; Sat, 11 Sep 2004 01:41:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8ANfuSj098711; Sat, 11 Sep 2004 01:41:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409102341.i8ANfuSj098711@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Vishwanath Edavayyanamath" Subject: Re: [Ipsec] "Non-initial" vs. "Initial" Fragments Definition In-reply-to: Your message of Fri, 10 Sep 2004 20:44:32 +0530. <5959EA4638D8734599AB75EAAFBB6FEF3CCD6F@mtv01ex04.mindtree.com> Date: Sat, 11 Sep 2004 01:41:56 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: In the draft-ietf-ipsec-rfc2401bis-02.txt page 18 it is stated that, And the phrase "initial" fragment is used to mean a fragment that contains all the selector values needed for access control. However, it should be noted that for IPv6, which fragment contains the Next Layer Protocol and ports (or ICMP message type/code or Mobility Header type) will depend on the kind and number of extension headers present. The "initial" fragment might not be the first fragment. ^^^^^^^^^^^^^^^^^^^^^^^ In which case this will apply? => when there is a large destination option header after the fragmentation header and the end of the first fragment falls in it. while there is a minimum packet size defined (576 fragmented or not) and the headers in context (next layer protocol, ports, etc) pretty much fit in the minimum packet size defined (again 576 fragmented or otherwise). => I can't parse your argument. The minimum fragment payload size is 8 octets, and 576 is the minimal garanted size for reassembly of IPv4 packets (minimal MTU is 68, in IPv6 the values are 1500 and 1280). So, I feel the statement is redundant and can be removed. => redundant? You can believe it is false (so I've given an example). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 10 19:59:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21504 for ; Fri, 10 Sep 2004 19:59:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5v7H-0008A4-Rl; Fri, 10 Sep 2004 19:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5v4W-00076J-CY for ipsec@megatron.ietf.org; Fri, 10 Sep 2004 19:44:52 -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 TAA20347 for ; Fri, 10 Sep 2004 19:44:50 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5v8f-0004w0-GG for ipsec@ietf.org; Fri, 10 Sep 2004 19:49:10 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8ANj99D006149 for ; Fri, 10 Sep 2004 16:45:09 -0700 Message-ID: <006f01c49790$242adc50$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: Date: Fri, 10 Sep 2004 16:44:40 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Ipsec] IKEv2 and Initial Contact X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit As I understand, SAi2, SAr2 and TSi, TSr are MUST payloads in AUTH exchange. When the system restarts, the implementation are expected to send INITIAL_CONTACT notification to others so that the remote peers would reset any state information, remote peer has with this node. Since this message needs to be cryptographically protected, IKE SA needs to be negotiated with the peer. Note that, here the IKE SA is not initiated due to the data packet. In this case, what should be the values of SA and TS payloads. I guess, we can send send any values (may be all supported ones) in SAs so that atleast one of the combination would be accepted by peer. What are the appropriate values for Traffic Selectors? Options, I can think of are: 1. Make SA and TS optional in AUTH exchange. Is there any particular reason for not making them optional. 2. Define some predefined value for SA and TS to indicate to the peer that they are not to be interpreted, so that peer does not fail the exchange. What do other think about this? Did I overlook any text in the draft? Thanks Srini Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 01:07:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08059 for ; Sat, 11 Sep 2004 01:07:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C603u-0005Jp-TI; Sat, 11 Sep 2004 01:04:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5zzg-0003hC-Tu for ipsec@megatron.ietf.org; Sat, 11 Sep 2004 01:00:13 -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 BAA07088 for ; Sat, 11 Sep 2004 01:00:12 -0400 (EDT) Received: from mxout3.netvision.net.il ([194.90.9.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C603t-0001Et-CA for ipsec@ietf.org; Sat, 11 Sep 2004 01:04:34 -0400 Received: from [217.132.153.66] by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3V00JQZ1VF3N@mxout3.netvision.net.il> for ipsec@ietf.org; Sat, 11 Sep 2004 07:59:39 +0300 (IDT) Date: Sat, 11 Sep 2004 07:59:53 +0300 From: Yoav Nir Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 In-reply-to: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> To: Uma Shankar Ch Message-id: <6B49F3FA-03AF-11D9-818D-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) References: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> X-Spam-Score: 1.2 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711968188==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0711968188== Content-type: multipart/alternative; boundary="Boundary_(ID_3N+8HuN9pwpJMTWevEgCSA)" --Boundary_(ID_3N+8HuN9pwpJMTWevEgCSA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable AFAIK the rationale is that EAP is not used between two IPSec gateways,=20= but with a client connecting to a gateway (or "access concentrator"). =20= There are two reasons why the gateway should identify first. 1. The gateway authenticates with a certificate or shared secret. The=20= EAP methods may be less secure, so a fake gateway can either do a MITM=20= attack and connect to the real gateway, or even worse, get the=20 credentials and be able to connect to the real gateway later. If you=20 look at an EAP method such as GTC (gateway asks "Password?", client=20 answers "12345"), you don't want your client to do GTC with a gateway=20 that hasn't authenticated yet. The certificates (and PSK) are assumed=20= to be more secure, and an authentication should not give the attacker=20 enough information to impersonate a gateway. 2. The gateway is assumed to be known. Its identity (as opposed to its=20= PSK or private key) are usually not secret. On 10/09/2004, at 20:32, Uma Shankar Ch wrote: > > > Can IKEv1 be used with any mutual authentication=A0 method using = Xauth? > Am not aware of it. > > In IKEv2 extended authentication happen as part of AUTH exchange=20 > before authenticating the > Client by the server. But, in IKEv1 it happens after establishing=20 > trusted authentication > channel with whatever way authentication is configured ( by=20 > pre-shared key or public key > certificates) by the administrator. Is it because with IKEv1, we=20 > can't use mutual authenticating > method? > > In this context, in summary, I have the following questions > > 1. What is the rationale of changing the way extended authentication=20= > starts from v1 to v2? > > Of course, there would be definitely certain advantages with this=20 > change, but am not able to > =A0understand what are those. > > =A0(i) Is that, the repercussion of this change is the text in = Security=20 > Considerations section > (Section 5) of the draft? > > "Use of EAP authentication changes the probing possibilities = somewhat. > =A0When EAP authentication is used, the responder proves its identity > =A0before the initiator does, so an initiator that knew the name of a > =A0valid initiator could probe the responder for both its name and > =A0certificates." > > 2.=A0 I could not find any text relating to the change of the way=20 > extended authentication happen in=A0 IKEv1 and the proposed standard = in=20 > IKEv2 in "Appendix A: Summary of changes from IKEv1" of=20 > "draft-ietf-ipsec-ikev2-15.txt". > > 3. The last minor point. > > =A0(i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284=20= > which is obsolete and the > new one being=A0 RFC 3748? > =A0(ii) In the text wherever applicable, the draft is mentioning=20 > "Extended Authentication ..." > it should have been "Extensible Authentication..." > > Can any body clarify on this? > > -Uma > > www.intoto.com > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_3N+8HuN9pwpJMTWevEgCSA) Content-type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AFAIK the rationale is that EAP is not used between two IPSec gateways, but with a client connecting to a gateway (or "access concentrator"). There are two reasons why the gateway should identify first. 1. The gateway authenticates with a certificate or shared secret. The EAP methods may be less secure, so a fake gateway can either do a MITM attack and connect to the real gateway, or even worse, get the credentials and be able to connect to the real gateway later. If you look at an EAP method such as GTC (gateway asks "Password?", client answers "12345"), you don't want your client to do GTC with a gateway that hasn't authenticated yet. The certificates (and PSK) are assumed to be more secure, and an authentication should not give the attacker enough information to impersonate a gateway. 2. The gateway is assumed to be known. Its identity (as opposed to its PSK or private key) are usually not secret. On 10/09/2004, at 20:32, Uma Shankar Ch wrote: Can IKEv1 be used with any mutual authentication=A0 method using Xauth?=20= Am not aware of it. In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the=20 Client by the server. But, in IKEv1 it happens after establishing trusted authentication channel with whatever way authentication is configured ( by pre-shared key or public key=20 certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating method? In this context, in summary, I have the following questions=20 1. What is the rationale of changing the way extended authentication starts from v1 to v2? Of course, there would be definitely certain advantages with this change, but am not able to =A0understand what are those. =A0(i) Is that, the repercussion of this change is the text in Security Considerations section=20 (Section 5) of the draft? "Use of EAP authentication changes the probing possibilities somewhat. =A0When EAP authentication is used, the responder proves its identity =A0before the initiator does, so an initiator that knew the name of a =A0valid initiator could probe the responder for both its name and =A0certificates." 2.=A0 I could not find any text relating to the change of the way extended authentication happen in=A0 IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt". 3. The last minor point. =A0(i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the=20 new one being=A0 RFC 3748? =A0(ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..."=20 it should have been "Extensible Authentication..." Can any body clarify on this? -Uma 0000,0000,EEEEwww.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_3N+8HuN9pwpJMTWevEgCSA)-- --===============0711968188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0711968188==-- From ipsec-bounces@ietf.org Sat Sep 11 16:33:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07986 for ; Sat, 11 Sep 2004 16:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EUp-00056q-40; Sat, 11 Sep 2004 16:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Gym-0002N6-P3 for ipsec@megatron.ietf.org; Sun, 29 Aug 2004 00:07:44 -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 AAA29043 for ; Sun, 29 Aug 2004 00:07:42 -0400 (EDT) Received: from www.native6.com ([168.103.150.210] helo=hestia.native6.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1H0G-0007Ms-V6 for ipsec@ietf.org; Sun, 29 Aug 2004 00:09:17 -0400 Received: from JOHNIBMLAPTOP (c-24-16-70-119.client.comcast.net [24.16.70.119]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id i7T47CJ1013728 for ; Sat, 28 Aug 2004 21:07:12 -0700 Message-Id: <200408290407.i7T47CJ1013728@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Date: Sat, 28 Aug 2004 21:07:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSNfam2Dsakoyr4SbiG3bCN7NIGKw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 11 Sep 2004 16:29:17 -0400 Subject: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The flow label in IPv6 is chosen by the source node, and must be delivered to the ultimate destination without having been changed in transit, unlike the DSCP or ECN QoS-related fields for IPv6. I suggest, since it is constant end-to-end, the field be moved to "immutable" and protected by AH. -------------- from draft-ietf-ipsec-rfc2402bis-07 ---------- 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label Hop Limit -------------- from RFC 3697 -------------- 2. IPv6 Flow Label Specification The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a source to label packets of a flow. A Flow Label of zero is used to indicate packets not part of any flow. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to identify which flow a particular packet belongs to. Packets are processed in a flow-specific manner by the nodes that have been set up with flow-specific state. The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification. The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). ------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspenceNOSPAM@native6.com www.native6.com ------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:36:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08277 for ; Sat, 11 Sep 2004 16:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EWJ-0005Lb-WD; Sat, 11 Sep 2004 16:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2s9C-0001At-Bb for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 10:01:06 -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 KAA04322 for ; Thu, 2 Sep 2004 10:01:04 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2sBa-0006HF-Er for ipsec@ietf.org; Thu, 02 Sep 2004 10:03:35 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82E0XKK398880; Thu, 2 Sep 2004 10:00:33 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i82E1fNw056248; Thu, 2 Sep 2004 10:01:42 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i82E11AK025833; Thu, 2 Sep 2004 10:01:01 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i82E100H025827; Thu, 2 Sep 2004 10:01:00 -0400 Message-Id: <200409021401.i82E100H025827@rotala.raleigh.ibm.com> To: Russ Housley In-Reply-To: Message from housley@vigilsec.com of "Thu, 02 Sep 2004 09:53:55 EDT." <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> Date: Thu, 02 Sep 2004 10:01:00 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Sat, 11 Sep 2004 16:30:50 -0400 Cc: ipsec@ietf.org, margaret@thingmagic.com Subject: [Ipsec] Re: Two IKEv2 issues from the IESG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Russ Housley writes: > I suggest the addition of the following text: > "All IKEv2 implementations MUST be able to receive and process > packets that are up to 1280 bytes long, and they SHOULD be able > to receive and process packets that are up to 3000 bytes long." I don't see how the SHOULD is useful. The problem is that a sender has no way of knowing whether the other end supports the larger packet size. So, for interoperability, it can't try a size that large. If it does, it may well send packets into a black hole. This is a generic issue that has come up in many other protocols. It would be nice to send larger packets, but it turns out that there exist compliant implementations that don't support them, so one can't count on such packets being supported. Note, the key issue is what is the receiver mandated to be capable of accepting? Or, is there a way for IKE to respond to such packets with an error effectively saying "packet too big"? If so, then one could try a large packet, and negotiate a smaller value. That also works. Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:38:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08460 for ; Sat, 11 Sep 2004 16:38:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EWK-0005Lh-Oz; Sat, 11 Sep 2004 16:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2tF5-0000mN-Cq for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 11:11:15 -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 LAA11167 for ; Thu, 2 Sep 2004 11:11:13 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2tHS-0003gy-BG for ipsec@ietf.org; Thu, 02 Sep 2004 11:13:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82FAQKK520002; Thu, 2 Sep 2004 11:10:26 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i82FBdND138030; Thu, 2 Sep 2004 11:11:39 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i82FAvAK026712; Thu, 2 Sep 2004 11:10:58 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i82FAqDu026707; Thu, 2 Sep 2004 11:10:57 -0400 Message-Id: <200409021510.i82FAqDu026707@rotala.raleigh.ibm.com> To: Michael Richardson Subject: Re: [Ipsec] Two IKEv2 issues from the IESG In-Reply-To: Message from mcr@sandelman.ottawa.on.ca of "Thu, 02 Sep 2004 11:02:48 EDT." <29377.1094137368@marajade.sandelman.ottawa.on.ca> Date: Thu, 02 Sep 2004 11:10:52 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Sat, 11 Sep 2004 16:30:50 -0400 Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Russ> "All IKEv2 implementations MUST be able to receive and > Russ> process packets that are up to 1280 bytes long, and they > Russ> SHOULD be able to receive and process packets that are up to > Russ> 3000 bytes long." > (Sorry to be pedantic here, but I think it is important) This is an important point. > I think that the word "packet" is wrong here. > I think that you mean "datagram" -- seeing as a 3000 byte datagram would > exceed common MTU, it must have been fragmented into multiple frames to > have been received. Actually, even "datagram" is ambiguous. I think you want something more like: ... be able to receive and process IKE payloads that are up to 3000 bytes long. (or is "IKE Payload" defined as something else ... what I'm after is essentially "the user data part of the UDP datagram") I.e., what you want is clarity that IKE is able to send 3000 bytes of user data, independent of the underlying IP headers, and know that it will be accepted/processed by the receiver. Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:42:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08760 for ; Sat, 11 Sep 2004 16:42:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EWL-0005Ln-HO; Sat, 11 Sep 2004 16:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3G0i-0004oW-5v for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 11:29:56 -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 LAA06193 for ; Fri, 3 Sep 2004 11:29:53 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3G3J-0002DB-Ih for ipsec@ietf.org; Fri, 03 Sep 2004 11:32:39 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i83FTCnZ426036; Fri, 3 Sep 2004 11:29:12 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i83FTB7B405558; Fri, 3 Sep 2004 09:29:11 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i83FThAK003975; Fri, 3 Sep 2004 11:29:43 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i83FTg8C003971; Fri, 3 Sep 2004 11:29:43 -0400 Message-Id: <200409031529.i83FTg8C003971@rotala.raleigh.ibm.com> To: Tero Kivinen Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG In-Reply-To: Message from kivinen@iki.fi of "Fri, 03 Sep 2004 13:06:26 +0300." <16696.16930.850706.258383@fireball.kivinen.iki.fi> Date: Fri, 03 Sep 2004 11:29:42 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Sat, 11 Sep 2004 16:30:50 -0400 Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > That would be the true if we would be talking about protocol talked > between any random host in the internet and another random host in the > internet. Um, aren't IKE and IPsec for communication between random hosts? True, most deployment to date has been VPNs. But are we resigning ourselves to that scenario forever? I hope not. > With IPsec that is not normally the case. You need to have some kind > of trust relationship between the hosts to get IKEv2 working, i.e. you > need common CA, or shared secrets exchange priori etc. In most of the > cases you also need to agree about the policy to be used and so on. I agree with this, but do not agree that this implies that whoever is in charge of setting up the trust relationships is in a position to know (or ensure) that all the possible IKE participants will accept adequately large payloads beyound those _required_ (in the MUST sense) by the spec. > This means that agreeing in the maximum datagram size using those same > out of band methods is possible. The 3000 bytes is more like to be > meant as an instruction to the the implementators, use this in your > implementation. If we leave it out all implementations will only > support 1280 or 1500 bytes, and then there are some implementations > which use 64k... Note: my real concern is that SHOULD is not strong enough. If it is not a MUST requirement that 3000 bytes (or whatever the right minimum lower bound is) be supported, we will eventually, once there is widespread deployment of IKE, run into a deployed base where some implementations only support the required minimum. At that point, implementations will (for interoperability) have to assume that the 3000 byte SHOULD is not universally implemented, and use the real lower bound (e.g., 1280). > If you are really doing the random host to random host connections, > then you must limit yourself to 1280 bytes, and use http transfer for > certificates if the certificates doesn't fit otherwise, but as I said, > that random host to random host connections are not that common use > for the IPsec (at least now). The 1280 bytes is enough for basic > operations in that case too, so there is no problem there. If the WG feels that 1280 is really an adequate number to assume in the general case, I'm fine with that. My point is that the SHOULD recommendation is probably less useful than might seem. > >Or, is there a way for IKE to respond to such packets with an error > >effectively saying "packet too big"? If so, then one could try a large > >packet, and negotiate a smaller value. That also works. > Not really, but adding such would be very easy. The IKE_SA_INIT are > almost always smaller than 1280 bytes: If this will eventually be needed, now is the time to do it, before there is a deployed base. It is the deployed base (which won't implement this) that will be the problem in the future (if it becomes a problem). Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:43:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08908 for ; Sat, 11 Sep 2004 16:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EWX-0005Mh-BP; Sat, 11 Sep 2004 16:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZtW-0004oh-Az for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 14:31:44 -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 OAA19257 for ; Wed, 1 Sep 2004 14:31:38 -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 1C2Zvj-0004Ql-Rl for ipsec@ietf.org; Wed, 01 Sep 2004 14:34:01 -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 i81IRSd00181 for ; Wed, 1 Sep 2004 14:27:28 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i81IShNh015416 for ; Wed, 1 Sep 2004 14:28:43 -0400 (EDT) Received: from mail.xtdnet.nl(193.110.157.5) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1gaigE; Wed, 1 Sep 04 14:28:41 -0400 Received: from mail.xtdnet.nl (mail.xtdnet.nl [193.110.157.5]) by expansionpack.xtdnet.nl (8.12.8/8.11.6) with ESMTP id i81IUOfm013642 (using TLSv1/SSLv3 with cipher DHE-DSS-AES256-SHA (256 bits) verified NO); Wed, 1 Sep 2004 20:30:25 +0200 Date: Wed, 1 Sep 2004 20:30:24 +0200 (MET DST) From: Paul Wouters X-X-Sender: paul@expansionpack.xtdnet.nl To: Paul Koning Subject: Re: [Pki4ipsec] RE: [Ipsec] big IKE packets In-Reply-To: <16693.65040.525143.196105@gargle.gargle.HOWL> Message-ID: References: <200409011001.i81A1gSj053026@givry.rennes.enst-bretagne.fr> <200409011031.i81AVIu19463@michael.checkpoint.com> <16693.65040.525143.196105@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Sat, 11 Sep 2004 16:31:04 -0400 Cc: ipsec@lists.tislabs.com, ynir@checkpoint.com, pki4ipsec@honor.icsalabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, 1 Sep 2004, Paul Koning wrote: > To what extent should we pessimize the protocol design to work around > defective network equipment? I have seen a strong increase in support questions that involve MTU problems since Microsoft added IPsec and ESPinUDP encapsulation in their products. We are seeing an ever increasing deployment based on X.509 certificates, I don't think it is wise to ignore the problem; especially in a design phase where these problems are known and possibly addressed. There are a lot of cheap, broken, networks out there. And it is not getting prettier with the next generation wireless/gms/umts/gprs. (And it won't be ipv6 either ;) If we can't even get it to work now, it surely won't work in the future. Paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:44:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09133 for ; Sat, 11 Sep 2004 16:44:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EXE-0005i8-Aw; Sat, 11 Sep 2004 16:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2gbC-0005lB-RP for ipsec@megatron.ietf.org; Wed, 01 Sep 2004 21:41:16 -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 VAA23785 for ; Wed, 1 Sep 2004 21:41:11 -0400 (EDT) From: ravivsn@www.rocsys.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2gdI-0006QB-03 for ipsec@ietf.org; Wed, 01 Sep 2004 21:43:37 -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 i821afd25547 for ; Wed, 1 Sep 2004 21:36:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i821bttc008213 for ; Wed, 1 Sep 2004 21:37:55 -0400 (EDT) Received: from unknown(202.125.80.81) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnmay_p; Wed, 1 Sep 04 21:37:49 -0400 Received: from rocsys.com (localhost [127.0.0.1] (may be forged)) by rocsys.com (8.12.10/8.12.10) with ESMTP id i82241LK012932; Thu, 2 Sep 2004 07:34:02 +0530 Received: (from apache@localhost) by rocsys.com (8.12.10/8.12.10/Submit) id i8223via012931; Thu, 2 Sep 2004 07:33:57 +0530 X-Authentication-Warning: rocsys.com: apache set sender to ravivsn@www.rocsys.com using -f Received: from 202.63.115.3 (SquirrelMail authenticated user ravivsn) by rocsys.com with HTTP; Thu, 2 Sep 2004 07:33:56 +0530 (IST) Message-ID: <1232.202.63.115.3.1094090636.squirrel@rocsys.com> Date: Thu, 2 Sep 2004 07:33:56 +0530 (IST) To: In-Reply-To: <1094064890.2123.71.camel@suren> References: <1094064890.2123.71.camel@suren> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 11 Sep 2004 16:31:47 -0400 Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.com, ravivsn@rocsys.com Subject: [Ipsec] Re: [Pki4ipsec] HASH and URL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Note: please reply to ravivsn@rocsys.com It is not good to assume that all firewalls/NATs are of Cone type. They could be symmetric type too. Alternate method I can think of : Node A Node B <-------------Cert Request Certificate----------> As part of certificate, it can indicate that, the Node B needs to make a connection on fixed port (assigned number from IANA) running HTTP Server. Node B makes the connection to Node A to get the certificate. If Node A has the certificate, it returns the certificate. Otherwise, it itself can make a connection to certificate store, get the certificate and send it on the connection Node B made with it. Since Node A can listen on well known fixed port, Firewall administrators at Node B can allow only that service. Regards, -Ravi ROCSYS Technologies Ltd http://www.rocsys.com > Hi, > As I understand, the IKE node can send Hash of public key of > its certificate and URL (including port number) from which the peer > can retrieve its certificate. I guess, it is to ensure that there is > no fragmentation on IKE packets as some routers might not honor > fragmentation. > > I see that there would be firewall related issues in this. > Since, the IKE needs to make a new connection (HTTP connection) to > the URI given in Cert payload, any firewalls in between should have > a policy (ACL) to allow this HTTP connection. > > This could be a deployment problem. The administrator of firewall > need to create a ACL to allow all connections outbound. > This is one of the problem being faced by administrators on CRLDP > (CRL Distribution point) too. At least in this case, the distribution > points are smaller and in most cases deterministic and the > administrator of firewalls can create appropriate policies > statically. > > What do you think of this following proposal. > - IKE Peer which receives Certificate payload always sends its > IP address and port as part of URL. (Assumption here is that, all > services typically are allowed between IPSec Peers). > - When the IKE node receives HTTP request, it could send HTTP > Redirect to new URL, which could be outside its node. > - IKE Peer is expected to use same source IP address and Port > (May be using REUSE address option in sockets) to connect to new > HTTP Server and Port. > - Since, most of firewalls support 'address binding' feature, > it should work. > > Does this make sense? Comments? > > Thanks > Suren > www.intoto.com > > _______________________________________________ > pki4ipsec mailing list > pki4ipsec@honor.icsalabs.com > http://honor.icsalabs.com/mailman/listinfo/pki4ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 11 16:46:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09399 for ; Sat, 11 Sep 2004 16:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EgG-0008QE-NJ; Sat, 11 Sep 2004 16:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2u5E-0004Bh-0L for ipsec@megatron.ietf.org; Thu, 02 Sep 2004 12:05:08 -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 MAA14839 for ; Thu, 2 Sep 2004 12:05:05 -0400 (EDT) Received: from mail64.messagelabs.com ([216.82.255.51]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2u7c-00085l-SX for ipsec@ietf.org; Thu, 02 Sep 2004 12:07:38 -0400 X-VirusChecked: Checked X-Env-Sender: wgrayson@calleci.com X-Msg-Ref: server-8.tower-64.messagelabs.com!1094141069!10382558 X-StarScan-Version: 5.2.10; banners=-,-,- X-Originating-IP: [206.165.61.20] Received: (qmail 21528 invoked from network); 2 Sep 2004 16:04:33 -0000 Received: from unknown (HELO 415mail.calleci.com) (206.165.61.20) by server-8.tower-64.messagelabs.com with SMTP; 2 Sep 2004 16:04:33 -0000 Received: by 415mail.calleci.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Sep 2004 11:57:52 -0400 Message-ID: <30EB828C264FD6119C5300B0D06876DB0A37D792@415mail.calleci.com> From: William Grayson To: "'ipsec@ietf.org'" Date: Thu, 2 Sep 2004 11:57:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Sat, 11 Sep 2004 16:41:04 -0400 Subject: [Ipsec] Re: Monitoring IPSEC/VPN Tunnel traffic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear IPSEC. Are there any software on the market that can monitor IPSEC/VPN Tunnel traffic? William Grayson Senior Network Engineer 415 Hamburg Turnpike Wayne, NJ 07470 Office: (973) 796-5606 "I really believe that we don't have to make a trade-off between security and privacy. I think technology gives us the ability to have both" _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 12 09:44:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14731 for ; Sun, 12 Sep 2004 09:44:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6UZY-0002Rs-31; Sun, 12 Sep 2004 09:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6UYx-0002M3-0D for ipsec@megatron.ietf.org; Sun, 12 Sep 2004 09:38:39 -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 JAA14520 for ; Sun, 12 Sep 2004 09:38:37 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6UdO-0000zb-Ia for ipsec@ietf.org; Sun, 12 Sep 2004 09:43:18 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8CDcPWk004235; Sun, 12 Sep 2004 19:08:25 +0530 Message-Id: <5.1.0.14.0.20040912183853.02aac7f0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 12 Sep 2004 19:22:48 +0530 To: Yoav Nir From: Uma Shankar Ch Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 In-Reply-To: <6B49F3FA-03AF-11D9-818D-000393AD410A@netvision.net.il> References: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1016608069==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1016608069== Content-Type: multipart/alternative; boundary="=====================_77096367==_.ALT" --=====================_77096367==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I Thank You for your response. Still... At 07:59 AM 9/11/04 +0300, Yoav Nir wrote: >AFAIK the rationale is that EAP is not used between two IPSec gateways, >but with a client connecting to a gateway (or "access >concentrator"). There are two reasons why the gateway should identify first. > >1. The gateway authenticates with a certificate or shared secret. The EAP >methods may be less secure, so a fake gateway can either do a MITM attack >and connect to the real gateway, or even worse, get the credentials and be >able to connect to the real gateway later. If you look at an EAP method >such as GTC (gateway asks "Password?", client answers "12345"), you don't >want your client to do GTC with a gateway that hasn't authenticated yet. Uma: Absolutely, client has to do EAP with an authenticated gateway. I completely agree with it and that is the reason 4th message from the responder does give cert payload ad AUTH to prove it's authenticity. <-- HDR, SK {IDr, [CERT,] AUTH,EAP } But a genuine Gateway should also know it's talking to a real client before starting EAP. My whole question is what is the advantage in dropping the AUTH payload to start EAP. We can always indicate responder to start EAP with a Notify similar to "EAP_ONLY_AUTHENTICATION"? 1. As said by you, even I think this is important, if EAP method is less secure. So, here It's Important to have a authenticated channel before hand for both client and the responder gateway, as is done in V1. 2. If EAP method is more secure, in the sense that which uses mutual authenticating method and generates MSK can also make use of the potential offered by IKEv2. With this most of the DoS attacks that could happen because of unprotected initial messages of Mutual authenticating methods, as the underlying layer gave them a secured and authenticated channel can be avoided. Otherwise even these methods, though those are working with IKEv2 are still susceptible as they don't have authenticated channel. Am not understanding what is the advantage we are getting by dropping the AUTH payload in third message? The only thing I can see is, it's reducing computational burden on the responder gateway. Is it the real Advantage? >The certificates (and PSK) are assumed to be more secure, and an >authentication should not give the attacker enough information to >impersonate a gateway. > >2. The gateway is assumed to be known. Its identity (as opposed to its >PSK or private key) are usually not secret. Uma: This answered my second mail question partially -- "why responder should expose his identity before authenticating the client". Then it seems --- why the security consideration section, should still contain this statement. Is it because just to alert???????? "Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates." -Uma www.intoto.com >On 10/09/2004, at 20:32, Uma Shankar Ch wrote: > > > >>Can IKEv1 be used with any mutual authentication method using Xauth? >>Am not aware of it. >> >>In IKEv2 extended authentication happen as part of AUTH exchange before >>authenticating the >>Client by the server. But, in IKEv1 it happens after establishing trusted >>authentication >>channel with whatever way authentication is configured ( by pre-shared >>key or public key >>certificates) by the administrator. Is it because with IKEv1, we can't >>use mutual authenticating >>method? >> >>In this context, in summary, I have the following questions >> >>1. What is the rationale of changing the way extended authentication >>starts from v1 to v2? >> >>Of course, there would be definitely certain advantages with this change, >>but am not able to >> understand what are those. >> >> (i) Is that, the repercussion of this change is the text in Security >> Considerations section >>(Section 5) of the draft? >> >>"Use of EAP authentication changes the probing possibilities somewhat. >> When EAP authentication is used, the responder proves its identity >> before the initiator does, so an initiator that knew the name of a >> valid initiator could probe the responder for both its name and >> certificates." >> >>2. I could not find any text relating to the change of the way extended >>authentication happen in IKEv1 and the proposed standard in IKEv2 in >>"Appendix A: Summary of changes from IKEv1" of >>"draft-ietf-ipsec-ikev2-15.txt". >> >>3. The last minor point. >> >> (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which >> is obsolete and the >>new one being RFC 3748? >> (ii) In the text wherever applicable, the draft is mentioning "Extended >> Authentication ..." >>it should have been "Extensible Authentication..." >> >>Can any body clarify on this? >> >>-Uma >> >>www.intoto.com >> >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec >> > --=====================_77096367==_.ALT Content-Type: text/html; charset="us-ascii" I Thank You for your response.
Still...

At 07:59 AM 9/11/04 +0300, Yoav Nir wrote:

AFAIK the rationale is that EAP is not used between two IPSec gateways, but with a client connecting to a gateway (or "access concentrator").  There are two reasons why the gateway should identify first.

1. The gateway authenticates with a certificate or shared secret.  The EAP methods may be less secure, so a fake gateway can either do a MITM attack and connect to the real gateway, or even worse, get the credentials and be able to connect to the real gateway later.  If you look at an EAP method such as GTC (gateway asks "Password?", client answers "12345"), you don't want your client to do GTC with a gateway that hasn't authenticated yet. 

Uma:

Absolutely, client has to do EAP with an authenticated gateway. I completely agree with it and that is the reason 4th message from the responder does give cert payload ad AUTH to prove it's authenticity.
                     <--    HDR, SK {IDr, [CERT,] AUTH,EAP }


But a genuine  Gateway should also know it's talking to a real client before starting EAP.
My whole question is what is the advantage in dropping the AUTH payload to start EAP. We can always indicate responder to start EAP with a Notify similar to "EAP_ONLY_AUTHENTICATION"?

1. As said by you, even I think this is important, if EAP method is less secure. So, here It's Important to have a authenticated channel before hand  for both client  and the responder gateway, as is done in V1.

2. If EAP method is more secure, in the sense that which uses mutual authenticating method and generates MSK can also make use of the potential offered by IKEv2. With this most of the DoS attacks that could happen  because of unprotected initial messages of Mutual authenticating methods, as the underlying layer gave them a secured and authenticated channel can be avoided.
Otherwise even these methods, though those are working with IKEv2 are still susceptible as they don't have authenticated channel.

Am not understanding what is the advantage we are getting by dropping the AUTH payload in third message?

The only thing I can see is, it's reducing  computational burden on the responder gateway. Is it the real Advantage?

The certificates (and PSK) are assumed to be more secure, and an authentication should not give the attacker enough information to impersonate a gateway.

2. The gateway is assumed to be known.  Its identity (as opposed to its PSK or private key) are usually not secret.

Uma:
This answered my second mail question partially -- "why responder should expose his identity before authenticating the client".

Then it seems --- why the security consideration section,  should still contain this statement. Is it because just to alert????????

"Use of EAP authentication changes the probing possibilities somewhat.
 When EAP authentication is used, the responder proves its identity
 before the initiator does, so an initiator that knew the name of a
 valid initiator could probe the responder for both its name and
 certificates."


-Uma

www.intoto.com








On 10/09/2004, at 20:32, Uma Shankar Ch wrote:



Can IKEv1 be used with any mutual authentication  method using Xauth?
Am not aware of it.

In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the
Client by the server. But, in IKEv1 it happens after establishing trusted authentication
channel with whatever way authentication is configured ( by pre-shared key or public key
certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating
method?

In this context, in summary, I have the following questions

1. What is the rationale of changing the way extended authentication starts from v1 to v2?

Of course, there would be definitely certain advantages with this change, but am not able to
 understand what are those.

 (i) Is that, the repercussion of this change is the text in Security Considerations section
(Section 5) of the draft?

"Use of EAP authentication changes the probing possibilities somewhat.
 When EAP authentication is used, the responder proves its identity
 before the initiator does, so an initiator that knew the name of a
 valid initiator could probe the responder for both its name and
 certificates."

2.  I could not find any text relating to the change of the way extended authentication happen in  IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt".

3. The last minor point.

 (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the
new one being  RFC 3748?
 (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..."
it should have been "Extensible Authentication..."

Can any body clarify on this?

-Uma

www.intoto.com



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
</blockquote></x-html>
--=====================_77096367==_.ALT-- --===============1016608069== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1016608069==-- From ipsec-bounces@ietf.org Mon Sep 13 00:40:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07605 for ; Mon, 13 Sep 2004 00:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ia4-0005fv-9j; Mon, 13 Sep 2004 00:36:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6iXb-0005QJ-Sy for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 00:34:12 -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 AAA07243 for ; Mon, 13 Sep 2004 00:34:08 -0400 (EDT) Received: from [202.125.80.82] (helo=brahma.roc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6icC-0006h7-WA for ipsec@ietf.org; Mon, 13 Sep 2004 00:38:59 -0400 Received: (from root@localhost) by brahma.roc.com (8.9.3/8.8.7) id KAA29011 for ipsec@ietf.org; Mon, 13 Sep 2004 10:34:25 +0530 Received: from rocsys.com (kishore [172.16.15.28]) by brahma.roc.com (8.9.3/8.8.7) with ESMTP id KAA29004 for ; Mon, 13 Sep 2004 10:34:23 +0530 Message-ID: <41452330.6020100@rocsys.com> Date: Mon, 13 Sep 2004 10:03:52 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Subject: Re: [Ipsec] Two IKEv2 issues from the IESG X-Priority: 3) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Spam-Score: 0.8 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ravi Kumar List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit My preference is : Implementation MUST support sending/receiving 3000 bytes messages, in case of certificates. Implementation SHOULD support HASH & URL for certificate retrieval. -Ravi ----- Original Message ----- From: "Theodore Ts'o" To: "Russ Housley" Cc: ; ; Sent: Friday, September 10, 2004 8:37 AM Subject: Re: [Ipsec] Two IKEv2 issues from the IESG > On Thu, Sep 02, 2004 at 09:53:55AM -0400, Russ Housley wrote: >> Here are two issues from the IESG regarding IKEv2. I hope that these can >> be quickly resolved by the IPsec Working Group. Charlie has already agreed >> to quickly update the document to reflect the Working Group decision, once >> consensus is clear. > >> ELLIPTIC CURVES >> >> I am raising the second issue. In 2002, the working group decided not to >> pursue elliptic curves. Hilarie made several presentation advocating them; >> her slides are in the minutes. However, the IPR concerns associate with >> elliptic curves lead the working group to classic Diffie-Hellman. Yet, two >> elliptic curve groups are still included in the document. This seems to >> contradict the working group decision. > > No one has objected to this change. So Charlie, please remove > elliptic curve groups from Appendix B. > >> MINIMUM PACKET SIZE > > Please add the following text: > >> "All IKEv2 implementations MUST be able to receive and process >> packets that are up to 1280 bytes long, and they SHOULD be able >> to receive and process packets that are up to 3000 bytes long." > > There have been a few people who have suggested that they would prefer > a simple 3000 byte MUST requirement instead. However, these people > seem to have been in the minority, and given that 1280 bytes is enough > for a 1024 bit certificate, and 2048 with modest certificate > extensions, it seems that 1280 byte requirement is sufficient for many > applications. In addition, it is likely that most implementations > will implemement SHOULD requirements. > > Do any of those people advocating the 3000 byte MUST object strenously > to the above text requiring a 1280 MUST, and a 3000 byte SHOULD? > > - Ted > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 00:54:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08544 for ; Mon, 13 Sep 2004 00:54:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6imO-0007jg-BU; Mon, 13 Sep 2004 00:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ijr-000771-92 for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 00:46:51 -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 AAA08039 for ; Mon, 13 Sep 2004 00:46:48 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6ioU-0006v8-Ad for ipsec@ietf.org; Mon, 13 Sep 2004 00:51:38 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8D4kGB2527548 for ; Mon, 13 Sep 2004 00:46:16 -0400 Received: from d27mc101.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8D4lTWb072956 for ; Mon, 13 Sep 2004 00:47:30 -0400 From: Dennis Frett To: ipsec@ietf.org Message-ID: Date: Sun, 12 Sep 2004 23:46:13 -0500 X-MIMETrack: Serialize by Router on D27mc101/27/M/IBM(Release 6.5.2|June 01, 2004) at 09/12/2004 11:46:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ipsec] Dennis Frett/Rochester/IBM is out of the office. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I will be out of the office starting 09/12/2004 and will not return until 09/27/2004. I will respond to your message when I return. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 02:46:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29791 for ; Mon, 13 Sep 2004 02:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6kSm-0005CI-Oq; Mon, 13 Sep 2004 02:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6kRF-00051n-JJ for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 02:35:45 -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 CAA29208 for ; Mon, 13 Sep 2004 02:35:43 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6kVs-0000Mj-6z for ipsec@ietf.org; Mon, 13 Sep 2004 02:40:33 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i8D6Ywe05964; Mon, 13 Sep 2004 09:34:58 +0300 (IDT) Message-Id: <200409130634.i8D6Ywe05964@michael.checkpoint.com> From: "Yoav Nir" To: "'Ravi Kumar'" , Subject: RE: [Ipsec] Two IKEv2 issues from the IESG Date: Mon, 13 Sep 2004 09:34:51 +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: AcSZTAvv1iJopYfgQRmSmABQDkUjZQAD3IpA In-Reply-To: <41452330.6020100@rocsys.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Agree. (I usually avoid "me too" responses, but since Ted is looking for people who object to reducing the "MUST" requirement to 1280, I'm making an exception) -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Ravi Kumar Sent: Monday, September 13, 2004 7:34 AM To: ipsec@ietf.org Subject: Re: [Ipsec] Two IKEv2 issues from the IESG My preference is : Implementation MUST support sending/receiving 3000 bytes messages, in case of certificates. Implementation SHOULD support HASH & URL for certificate retrieval. -Ravi ----- Original Message ----- From: "Theodore Ts'o" To: "Russ Housley" Cc: ; ; Sent: Friday, September 10, 2004 8:37 AM Subject: Re: [Ipsec] Two IKEv2 issues from the IESG > On Thu, Sep 02, 2004 at 09:53:55AM -0400, Russ Housley wrote: >> Here are two issues from the IESG regarding IKEv2. I hope that these can >> be quickly resolved by the IPsec Working Group. Charlie has already agreed >> to quickly update the document to reflect the Working Group decision, once >> consensus is clear. > >> ELLIPTIC CURVES >> >> I am raising the second issue. In 2002, the working group decided not to >> pursue elliptic curves. Hilarie made several presentation advocating them; >> her slides are in the minutes. However, the IPR concerns associate with >> elliptic curves lead the working group to classic Diffie-Hellman. Yet, two >> elliptic curve groups are still included in the document. This seems to >> contradict the working group decision. > > No one has objected to this change. So Charlie, please remove > elliptic curve groups from Appendix B. > >> MINIMUM PACKET SIZE > > Please add the following text: > >> "All IKEv2 implementations MUST be able to receive and process >> packets that are up to 1280 bytes long, and they SHOULD be able >> to receive and process packets that are up to 3000 bytes long." > > There have been a few people who have suggested that they would prefer > a simple 3000 byte MUST requirement instead. However, these people > seem to have been in the minority, and given that 1280 bytes is enough > for a 1024 bit certificate, and 2048 with modest certificate > extensions, it seems that 1280 byte requirement is sufficient for many > applications. In addition, it is likely that most implementations > will implemement SHOULD requirements. > > Do any of those people advocating the 3000 byte MUST object strenously > to the above text requiring a 1280 MUST, and a 3000 byte SHOULD? > > - Ted > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 04:44:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06616 for ; Mon, 13 Sep 2004 04:44:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6mNu-0001Tz-Kv; Mon, 13 Sep 2004 04:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6mMu-0001N7-3x for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 04:39:24 -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 EAA06312 for ; Mon, 13 Sep 2004 04:39:21 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6mRX-0002S4-MD for ipsec@ietf.org; Mon, 13 Sep 2004 04:44:12 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i8D8dK5S024414; Mon, 13 Sep 2004 10:39:20 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i8D8dKW1003120; Mon, 13 Sep 2004 10:39:20 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Sep 2004 10:39:20 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046866D4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Uma Shankar Ch'" , ipsec@ietf.org Date: Mon, 13 Sep 2004 10:38:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: pasi.eronen@nokia.com Subject: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi uma, the work done in the ipsra working group had a different focus: add secure legacy authentication without changing ike. as a result see for example pic. the work on ikev2 and the discovered man-in-the-middle attack problems caused people to think in a different direction. ciao hannes ________________________________ From: Uma Shankar Ch [mailto:umas@intotoinc.com] Sent: Friday, September 10, 2004 7:32 PM To: ipsec@ietf.org Cc: pasi.eronen@nokia.com; Tschofenig Hannes Subject: Extended Authentication IKEv1 - IKEv2 Can IKEv1 be used with any mutual authentication method using Xauth? Am not aware of it. In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the Client by the server. But, in IKEv1 it happens after establishing trusted authentication channel with whatever way authentication is configured ( by pre-shared key or public key certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating method? In this context, in summary, I have the following questions 1. What is the rationale of changing the way extended authentication starts from v1 to v2? Of course, there would be definitely certain advantages with this change, but am not able to understand what are those. (i) Is that, the repercussion of this change is the text in Security Considerations section (Section 5) of the draft? "Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates." 2. I could not find any text relating to the change of the way extended authentication happen in IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt". 3. The last minor point. (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the new one being RFC 3748? (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..." it should have been "Extensible Authentication..." Can any body clarify on this? -Uma www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 04:46:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06746 for ; Mon, 13 Sep 2004 04:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6mP7-0001ZC-2c; Mon, 13 Sep 2004 04:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6mNR-0001P2-AB for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 04:39:57 -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 EAA06338 for ; Mon, 13 Sep 2004 04:39:53 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6mS3-0002Sx-CU for ipsec@ietf.org; Mon, 13 Sep 2004 04:44:44 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i8D8dqlO007851; Mon, 13 Sep 2004 10:39:52 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i8D8dqW1003485; Mon, 13 Sep 2004 10:39:52 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Sep 2004 10:39:52 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046866D5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Uma Shankar Ch'" , ipsec@ietf.org Subject: RE: [Ipsec] EAP_ONLY_AUTHENTICATION -- IDr payload Date: Mon, 13 Sep 2004 10:39:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi uma, let me make sure that i understood your question. you are asking why user identity confidentiality of the initiator is not provided when using eap in ikev2? if so, then please take a look at the discussions with regard to this issue more than one year go: http://www.sandelman.ottawa.on.ca/ipsec/2003/06/msg00021.html as a short summary: a few people argued that user identity confidentiality is not important compared to the additional roundtrip caused by the identity request / identity response. you mention draft-eronen-ipsec-ikev2-eap-auth-01.txt in this context. this draft has a different goal (independent from the above discussion). ciao hannes ________________________________ From: Uma Shankar Ch [mailto:umas@intotoinc.com] Sent: Friday, September 10, 2004 8:16 PM To: ipsec@ietf.org Subject: [Ipsec] EAP_ONLY_AUTHENTICATION -- IDr payload Can any body answer this. As, In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the Client by the server.(Of course it is protected) The IKE responder node should send IDr in response to the third message according to "draft-eronen-ipsec-ikev2-eap-auth-01.txt" ? HDR, SK { IDi, [IDr,] EAP_ONLY_AUTHENTICATION, SAi2, TSi, TSr} --> <-- HDR, SK { IDr, EAP(Request) } It could have been postponed up till the last message where SAr2, TSi, TSr are sent by responder. My point is why responder should expose his identity before authenticating the client in this scenario? Regards, Uma www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 12:37:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14959 for ; Mon, 13 Sep 2004 12:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6tfJ-0004Zl-Pc; Mon, 13 Sep 2004 12:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6tTm-0001W3-OI for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 12:15:00 -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 MAA13490 for ; Mon, 13 Sep 2004 12:14:55 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6tYS-0003gW-NU for ipsec@ietf.org; Mon, 13 Sep 2004 12:19:52 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8DGFS9F028380; Mon, 13 Sep 2004 09:15:28 -0700 Message-ID: <009701c499ac$c72175e0$0301010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Yoav Nir" , "Uma Shankar Ch" References: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10><5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> <5.1.0.14.0.20040912183853.02aac7f0@172.16.1.10> Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 Date: Sun, 12 Sep 2004 12:31:48 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0014396442==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0014396442== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0292_01C498C4.78D69FC0" This is a multi-part message in MIME format. ------=_NextPart_000_0292_01C498C4.78D69FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Uma, Unlike in IKEv1, in IKEv2, there is only one level of = authentication. That means, in IKEv2, the nodes need to authenticate the peers with one type of authentication. That is = major advantage I see here (with respect to configuration). In IKEv1, there are two authentication stages to = take advantage of AAA infrastrucutre. One is at the IKE level and another at AAA level. Clients are = configured with preshared/Certificate and X-AUTH credentials.=20 This was un-necessary and complex configuration. One might say that, = it provides good security. In reality, it is not. Remote access clients normally asked to share same preshared key = (for a given SGW) and AAA authentication is actually used to authenticate the clients. Any time, key is known to = multiple people, the security associated with it will be always under suspect. So, it is not really giving = any advantage. In regards to DoS attack, Clients also need to do same level = computation to move onto next stage ie EAP stage. But certainly, it is a problem, in case of DDOS attack ie multiple = clients under coordination can swamp the security gateway. This is generic problem, not only associated with = IKE, but with whole of Internet and applications. Note that IKE provide Cookie Notify mechanism to = ensure that Client does the DH computation before Server does. In my view, when a security gateway is used as remote access server, = its identity is in general has to be made known. In IKE, at least I see protection where SG Identity is = given, only upon checking the client Identity. I believe that we can live with this limitation. Srini Intoto Inc. www.intoto.com ----- Original Message -----=20 From: Uma Shankar Ch=20 To: Yoav Nir=20 Cc: ipsec@ietf.org=20 Sent: Sunday, September 12, 2004 6:52 AM Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 I Thank You for your response. Still... At 07:59 AM 9/11/04 +0300, Yoav Nir wrote: AFAIK the rationale is that EAP is not used between two IPSec = gateways, but with a client connecting to a gateway (or "access = concentrator"). There are two reasons why the gateway should identify = first.=20 1. The gateway authenticates with a certificate or shared secret. = The EAP methods may be less secure, so a fake gateway can either do a = MITM attack and connect to the real gateway, or even worse, get the = credentials and be able to connect to the real gateway later. If you = look at an EAP method such as GTC (gateway asks "Password?", client = answers "12345"), you don't want your client to do GTC with a gateway = that hasn't authenticated yet. =20 Uma:=20 Absolutely, client has to do EAP with an authenticated gateway. I = completely agree with it and that is the reason 4th message from the = responder does give cert payload ad AUTH to prove it's authenticity. <-- HDR, SK {IDr, [CERT,] AUTH,EAP } But a genuine Gateway should also know it's talking to a real client = before starting EAP. My whole question is what is the advantage in dropping the AUTH = payload to start EAP. We can always indicate responder to start EAP with = a Notify similar to "EAP_ONLY_AUTHENTICATION"? 1. As said by you, even I think this is important, if EAP method is = less secure. So, here It's Important to have a authenticated channel = before hand for both client and the responder gateway, as is done in = V1. 2. If EAP method is more secure, in the sense that which uses mutual = authenticating method and generates MSK can also make use of the = potential offered by IKEv2. With this most of the DoS attacks that could = happen because of unprotected initial messages of Mutual authenticating = methods, as the underlying layer gave them a secured and authenticated = channel can be avoided. Otherwise even these methods, though those are working with IKEv2 are = still susceptible as they don't have authenticated channel. Am not understanding what is the advantage we are getting by dropping = the AUTH payload in third message? The only thing I can see is, it's reducing computational burden on = the responder gateway. Is it the real Advantage? The certificates (and PSK) are assumed to be more secure, and an = authentication should not give the attacker enough information to = impersonate a gateway.=20 2. The gateway is assumed to be known. Its identity (as opposed to = its PSK or private key) are usually not secret.=20 Uma:=20 This answered my second mail question partially -- "why responder = should expose his identity before authenticating the client". Then it seems --- why the security consideration section, should = still contain this statement. Is it because just to alert???????? "Use of EAP authentication changes the probing possibilities somewhat. = When EAP authentication is used, the responder proves its identity=20 before the initiator does, so an initiator that knew the name of a=20 valid initiator could probe the responder for both its name and=20 certificates." -Uma www.intoto.com On 10/09/2004, at 20:32, Uma Shankar Ch wrote:=20 Can IKEv1 be used with any mutual authentication method using = Xauth?=20 Am not aware of it.=20 In IKEv2 extended authentication happen as part of AUTH exchange = before authenticating the=20 Client by the server. But, in IKEv1 it happens after establishing = trusted authentication=20 channel with whatever way authentication is configured ( by = pre-shared key or public key=20 certificates) by the administrator. Is it because with IKEv1, we = can't use mutual authenticating=20 method?=20 In this context, in summary, I have the following questions=20 1. What is the rationale of changing the way extended = authentication starts from v1 to v2?=20 Of course, there would be definitely certain advantages with this = change, but am not able to=20 understand what are those.=20 (i) Is that, the repercussion of this change is the text in = Security Considerations section=20 (Section 5) of the draft?=20 "Use of EAP authentication changes the probing possibilities = somewhat.=20 When EAP authentication is used, the responder proves its = identity=20 before the initiator does, so an initiator that knew the name of = a=20 valid initiator could probe the responder for both its name and=20 certificates."=20 2. I could not find any text relating to the change of the way = extended authentication happen in IKEv1 and the proposed standard in = IKEv2 in "Appendix A: Summary of changes from IKEv1" of = "draft-ietf-ipsec-ikev2-15.txt".=20 3. The last minor point.=20 (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 = which is obsolete and the=20 new one being RFC 3748?=20 (ii) In the text wherever applicable, the draft is mentioning = "Extended Authentication ..."=20 it should have been "Extensible Authentication..."=20 Can any body clarify on this?=20 -Uma=20 www.intoto.com=20 _______________________________________________=20 Ipsec mailing list=20 Ipsec@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ipsec=20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0292_01C498C4.78D69FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Uma,
    Unlike in = IKEv1, in IKEv2,=20 there is only one level of authentication. That means, in IKEv2, the = nodes need=20 to
     authenticate = the peers=20 with one type of authentication. That is major advantage I see here = (with=20 respect to
    configuration). In=20 IKEv1, there are two = authentication=20 stages to take advantage of AAA infrastrucutre.
    One is at the IKE = level=20 and  another at AAA = level.     Clients are configured = with=20 preshared/Certificate and X-AUTH credentials.
    This = was un-necessary and complex configuration. One might = say that, it=20 provides good security. In reality, it is not.
    Remote access = clients normally=20 asked to share same preshared key (for a given SGW) and AAA = authentication=20 is
    actually used to = authenticate=20 the clients. Any time, key is known to multiple people,  the = security=20 associated
    with it will be = always under=20 suspect. So, it is not really giving any advantage.
 
    In regards to DoS=20 attack, Clients also need to do same level computation to move = onto=20 next stage ie EAP stage.
    But certainly, it is = a problem,=20 in case of DDOS attack ie multiple clients under coordination can swamp=20 the
    security gateway. = This is=20 generic problem, not only associated with IKE, but with whole of = Internet=20 and
    applications.  = Note that=20 IKE provide Cookie Notify mechanism to ensure that Client does the=20 DH computation before
    Server = does.
 
    In my view, when a = security=20 gateway is used as remote access server, its identity is in general has = to=20 be
    made known. In IKE, = at least I=20 see protection where SG Identity is given, only upon checking the=20 client
    Identity. I believe = that we can=20 live with this limitation.
 
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From:=20 Uma = Shankar=20 Ch
Sent: Sunday, September 12, = 2004 6:52=20 AM
Subject: Re: [Ipsec] Extended=20 Authentication IKEv1 - IKEv2

I Thank You for your response.
Still...

At = 07:59 AM=20 9/11/04 +0300, Yoav Nir wrote:
AFAIK the rationale = is that EAP=20 is not used between two IPSec gateways, but with a client connecting = to a=20 gateway (or "access concentrator").  There are two reasons why = the=20 gateway should identify first.

1. The gateway authenticates = with a=20 certificate or shared secret.  The EAP methods may be less = secure, so a=20 fake gateway can either do a MITM attack and connect to the real = gateway, or=20 even worse, get the credentials and be able to connect to the real = gateway=20 later.  If you look at an EAP method such as GTC (gateway asks=20 "Password?", client answers "12345"), you don't want your client to = do GTC=20 with a gateway that hasn't authenticated yet. =20

Uma:

Absolutely, client has to do = EAP with=20 an authenticated gateway. I completely agree with it and that is = the=20 reason 4th message from the responder does give cert payload ad AUTH = to prove=20 it's authenticity.
          &nbs= p;         =20 <--    HDR, SK {IDr, [CERT,] AUTH,EAP=20 }


But a genuine  Gateway should also know it's = talking=20 to a real client before starting EAP.
My whole question is what is = the=20 advantage in dropping the AUTH payload to start EAP. We can always = indicate=20 responder to start EAP with a Notify similar to=20 "EAP_ONLY_AUTHENTICATION"?

1. As said by you, even I = think this=20 is important, if EAP method is less secure. So, here It's = Important=20 to have a authenticated channel before hand  for both = client =20 and the responder gateway, as is done in V1.

2. If EAP method = is more=20 secure, in the sense that which uses mutual authenticating method and=20 generates MSK can also make use of the potential offered by IKEv2. = With this=20 most of the DoS attacks that could happen  because of unprotected = initial=20 messages of Mutual authenticating methods, as the underlying layer = gave them a=20 secured and authenticated channel can be avoided.
Otherwise even = these=20 methods, though those are working with IKEv2 are still susceptible as = they=20 don't have authenticated channel.

Am not understanding what is = the=20 advantage we are getting by dropping the AUTH payload in third=20 message?

The only thing I can see is, it's reducing  = computational=20 burden on the responder gateway. Is it the real Advantage?

The certificates (and = PSK) are=20 assumed to be more secure, and an authentication should not give the = attacker enough information to impersonate a gateway.

2. The = gateway=20 is assumed to be known.  Its identity (as opposed to its PSK or = private=20 key) are usually not secret.

Uma:
This = answered my=20 second mail question partially -- "why responder should expose his = identity=20 before authenticating the client".

Then it seems --- why = the=20 security consideration section,  should still contain this = statement. Is=20 it because just to alert????????

"Use of EAP authentication = changes the=20 probing possibilities somewhat.
 When EAP authentication is = used, the=20 responder proves its identity
 before the initiator does, so = an=20 initiator that knew the name of a
 valid initiator could = probe the=20 responder for both its name and=20
 certificates."


-Uma

www.intoto.com








=
On 10/09/2004, at = 20:32, Uma=20 Shankar Ch wrote:



Can IKEv1 be used = with any=20 mutual authentication  method using Xauth?
Am not aware = of it.=20

In IKEv2 extended authentication happen as part of AUTH = exchange=20 before authenticating the
Client by the server. But, in IKEv1 = it=20 happens after establishing trusted authentication
channel with = whatever way authentication is configured ( by pre-shared key or = public=20 key
certificates) by the administrator. Is it because with = IKEv1, we=20 can't use mutual authenticating
method?

In this = context, in=20 summary, I have the following questions

1. What is the = rationale=20 of changing the way extended authentication starts from v1 to v2?=20

Of course, there would be definitely certain advantages = with this=20 change, but am not able to
 understand what are those.=20

 (i) Is that, the repercussion of this change is the = text in=20 Security Considerations section
(Section 5) of the draft? =

"Use=20 of EAP authentication changes the probing possibilities somewhat.=20
 When EAP authentication is used, the responder proves = its=20 identity
 before the initiator does, so an initiator that = knew=20 the name of a
 valid initiator could probe the responder = for both=20 its name and
 certificates."

2.  I could not = find=20 any text relating to the change of the way extended authentication = happen=20 in  IKEv1 and the proposed standard in IKEv2 in "Appendix = A:=20 Summary of changes from IKEv1" of=20 "draft-ietf-ipsec-ikev2-15.txt".

3. The last minor = point.=20

 (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers = [EAP] as RFC=20 2284 which is obsolete and the
new one being  RFC 3748?=20
 (ii) In the text wherever applicable, the draft is = mentioning=20 "Extended Authentication ..."
it should have been=20 "Extensible Authentication..."

Can any body clarify = on=20 this?

-Uma

www.intoto.com=20



_______________________________________________ =
Ipsec=20 mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec=20
</blockquote></x-html>

_______________________________________________
Ipsec = mailing=20 = list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0292_01C498C4.78D69FC0-- --===============0014396442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0014396442==-- From ipsec-bounces@ietf.org Mon Sep 13 13:21:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17963 for ; Mon, 13 Sep 2004 13:21:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6uHq-0003va-HV; Mon, 13 Sep 2004 13:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6uFP-00038m-1P for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 13:04:11 -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 NAA16807 for ; Mon, 13 Sep 2004 13:04:07 -0400 (EDT) From: tytso@mit.edu Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6uK5-0004hd-7v for ipsec@ietf.org; Mon, 13 Sep 2004 13:09:04 -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 i8DGxXd21248 for ; Mon, 13 Sep 2004 12:59:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8DH1556018500 for ; Mon, 13 Sep 2004 13:01:05 -0400 (EDT) Message-Id: <200409131701.i8DH1556018500@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAiaaGcK; Mon, 13 Sep 04 13:00:53 -0400 To: ipsec@lists.tislabs.com Date: Mon, 13 Sep 2004 14:04:26 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 1 X-MSMail-Priority: High X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ipsec] Deliver Mail (ipsec@lists.tislabs.com) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id i8DGxXd21248 Content-Transfer-Encoding: quoted-printable Delivery Failure - Invalid mail specification=20 ------------- failed message ------------- Qa(-!*BDhQ3IH%Rj=FC:FT.4BDY65=FC=DFIEo_BTJ2R=F6s.pXN6n GG4=F6eNwo=DFouA7wN(071)Wl+coRcNT5Zw$AbOGaEF Vbs'zRZ(FYJb3m&wKmSkx|)GB)j&?QZCd;Ca~!VMTIQ%EQ a=E47TUGD|OZ)E=DFx)3D=DF=DF('rl Partial message is available and has been sent as a binary attachment. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="msg4308.pif.htm" Content-Disposition: attachment; filename="msg4308.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: msg4308.pif
Virus name: W32/Netsky.q@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Mon Sep 13 13:45:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20065 for ; Mon, 13 Sep 2004 13:45:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6un0-0000am-MI; Mon, 13 Sep 2004 13:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ucH-0007Kh-Oe for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 13:27:51 -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 NAA18432 for ; Mon, 13 Sep 2004 13:27:48 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6ugz-0005Bz-RE for ipsec@ietf.org; Mon, 13 Sep 2004 13:32:43 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8DHRcHB030311; Mon, 13 Sep 2004 22:57:38 +0530 Message-Id: <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 Sep 2004 23:12:08 +0530 To: Tschofenig Hannes , ipsec@ietf.org From: Uma Shankar Ch In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F046866D4@mchp905a.mch.sbs. de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: pasi.eronen@nokia.com Subject: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Hannes, If you can permit me I want to clarify my queries with you personally. Thanks for the reply. -Uma At 10:38 AM 9/13/04 +0200, Tschofenig Hannes wrote: >hi uma, > >the work done in the ipsra working group had a different focus: add secure >legacy authentication without changing ike. as a result see for example pic. Uma: Okay. >the work on ikev2 and the discovered man-in-the-middle attack problems >caused people to think in a different direction. Uma: It's unfortunate that even IKEv2 come in the category of PEAP, TTLS or PIC where only unilateral authentication is happening, i.e, server is authenticating to client. This caused the MITM attacks on all tunneled protocols which EAP methods. And IKEv2 got added to the list, of course with the cryptographic binding between inner EAP protocol and outer protocol avoided the MITM attack on all these including IKEv2. The only exception is PANA over TLS --- POTLS. Where mutual authentication happens for outer protocol before EAP where client is authenticated to EAP server. But, IKEv2 can inherently capable of avoiding the MITM attack, if client can authenticate to IKE responder. And apart from that it could have avoided so many DoS attacks. My worry is DoS attacks on EAP-SIM with IKEv2 ------------------------------------------------------------------------- With this EAP-SIM didn't get the advantage of working with IKEv2, even though IKEv2 capable of giving the advantage. My worry is in EAP-SIM in the initial rounds with a simple Failure notify attacker can close the connection causing DoS, just because client is not authenticated to server before the start of EAP. EAP-SIM guys pushed this problem on PEAP or IKEv2 but unfortunately both didn't solve the problem. IKEv2 could have solved it. Can you answer this. And one more thing is, I strongly feel with out the "draft-eronen-ipsec-ikev2-eap-auth-01.txt" section 2.16 in IKEv2 doesn't give any advantage. As 2.16 mandating unilateral authentication and AUTH payload in the 4th message MUST be verified by client which would be a problem in real deployment scenarios where the client has to be configured with pre shared key or public key certificate. (If client is a handset device). Regards, Uma >ciao >hannes > >________________________________ > > From: Uma Shankar Ch [mailto:umas@intotoinc.com] > Sent: Friday, September 10, 2004 7:32 PM > To: ipsec@ietf.org > Cc: pasi.eronen@nokia.com; Tschofenig Hannes > Subject: Extended Authentication IKEv1 - IKEv2 > > > > > Can IKEv1 be used with any mutual authentication method using >Xauth? > Am not aware of it. > > In IKEv2 extended authentication happen as part of AUTH exchange >before authenticating the > Client by the server. But, in IKEv1 it happens after establishing >trusted authentication > channel with whatever way authentication is configured ( by >pre-shared key or public key > certificates) by the administrator. Is it because with IKEv1, we >can't use mutual authenticating > method? > > In this context, in summary, I have the following questions > > 1. What is the rationale of changing the way extended authentication >starts from v1 to v2? > > Of course, there would be definitely certain advantages with this >change, but am not able to > understand what are those. > > (i) Is that, the repercussion of this change is the text in >Security Considerations section > (Section 5) of the draft? > > "Use of EAP authentication changes the probing possibilities >somewhat. > When EAP authentication is used, the responder proves its identity > before the initiator does, so an initiator that knew the name of a > valid initiator could probe the responder for both its name and > certificates." > > 2. I could not find any text relating to the change of the way >extended authentication happen in IKEv1 and the proposed standard in IKEv2 >in "Appendix A: Summary of changes from IKEv1" of >"draft-ietf-ipsec-ikev2-15.txt". > > 3. The last minor point. > > (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 >which is obsolete and the > new one being RFC 3748? > (ii) In the text wherever applicable, the draft is mentioning >"Extended Authentication ..." > it should have been "Extensible Authentication..." > > Can any body clarify on this? > > -Uma > > www.intoto.com > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 13:57:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21032 for ; Mon, 13 Sep 2004 13:57:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6us7-0001W7-Vj; Mon, 13 Sep 2004 13:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6umq-0000Vd-Rj for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 13:38:46 -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 NAA19542 for ; Mon, 13 Sep 2004 13:38:43 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6urX-0005Ry-1j for ipsec@ietf.org; Mon, 13 Sep 2004 13:43:39 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8DHcSxU031674; Mon, 13 Sep 2004 23:08:28 +0530 Message-Id: <5.1.0.14.0.20040913231827.02abf990@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 Sep 2004 23:22:57 +0530 To: "Srinivasa Rao Addepalli" , "Yoav Nir" From: Uma Shankar Ch Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 In-Reply-To: <009701c499ac$c72175e0$0301010a@SriniSony> References: <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> <5.1.0.14.0.20040910224931.02aaecb0@172.16.1.10> <5.1.0.14.0.20040912183853.02aac7f0@172.16.1.10> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1812173303==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1812173303== Content-Type: multipart/alternative; boundary="=====================_5712224==_.ALT" --=====================_5712224==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Srini, I accept we might have to live with some DDoS attacks. Thanks for the detailed clarification we are getting the definite advantage in terms of configuration. This would play very important role when it comes to wireless/mobile deployment scenarios. Regards, Uma At 12:31 PM 9/12/04 -0700, Srinivasa Rao Addepalli wrote: >Hi Uma, > Unlike in IKEv1, in IKEv2, there is only one level of authentication. > That means, in IKEv2, the nodes need to > authenticate the peers with one type of authentication. That is > major advantage I see here (with respect to > configuration). In IKEv1, there are two authentication stages to take > advantage of AAA infrastrucutre. > One is at the IKE level and another at AAA level. Clients are > configured with preshared/Certificate and X-AUTH credentials. > This was un-necessary and complex configuration. One might say that, > it provides good security. In reality, it is not. > Remote access clients normally asked to share same preshared key (for > a given SGW) and AAA authentication is > actually used to authenticate the clients. Any time, key is known to > multiple people, the security associated > with it will be always under suspect. So, it is not really giving any > advantage. > > In regards to DoS attack, Clients also need to do same level > computation to move onto next stage ie EAP stage. > But certainly, it is a problem, in case of DDOS attack ie multiple > clients under coordination can swamp the > security gateway. This is generic problem, not only associated with > IKE, but with whole of Internet and > applications. Note that IKE provide Cookie Notify mechanism to > ensure that Client does the DH computation before > Server does. > > In my view, when a security gateway is used as remote access server, > its identity is in general has to be > made known. In IKE, at least I see protection where SG Identity is > given, only upon checking the client > Identity. I believe that we can live with this limitation. > >Srini >Intoto Inc. >www.intoto.com >----- Original Message ----- >From: Uma Shankar Ch >To: Yoav Nir >Cc: ipsec@ietf.org >Sent: Sunday, September 12, 2004 6:52 AM >Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2 > >I Thank You for your response. >Still... > >At 07:59 AM 9/11/04 +0300, Yoav Nir wrote: >>AFAIK the rationale is that EAP is not used between two IPSec gateways, >>but with a client connecting to a gateway (or "access >>concentrator"). There are two reasons why the gateway should identify first. >> >>1. The gateway authenticates with a certificate or shared secret. The >>EAP methods may be less secure, so a fake gateway can either do a MITM >>attack and connect to the real gateway, or even worse, get the >>credentials and be able to connect to the real gateway later. If you >>look at an EAP method such as GTC (gateway asks "Password?", client >>answers "12345"), you don't want your client to do GTC with a gateway >>that hasn't authenticated yet. >Uma: > >Absolutely, client has to do EAP with an authenticated gateway. I >completely agree with it and that is the reason 4th message from the >responder does give cert payload ad AUTH to prove it's authenticity. > <-- HDR, SK {IDr, [CERT,] AUTH,EAP } > > > >But a genuine Gateway should also know it's talking to a real client >before starting EAP. >My whole question is what is the advantage in dropping the AUTH payload to >start EAP. We can always indicate responder to start EAP with a Notify >similar to "EAP_ONLY_AUTHENTICATION"? > >1. As said by you, even I think this is important, if EAP method is less >secure. So, here It's Important to have a authenticated channel before >hand for both client and the responder gateway, as is done in V1. > >2. If EAP method is more secure, in the sense that which uses mutual >authenticating method and generates MSK can also make use of the potential >offered by IKEv2. With this most of the DoS attacks that could >happen because of unprotected initial messages of Mutual authenticating >methods, as the underlying layer gave them a secured and authenticated >channel can be avoided. >Otherwise even these methods, though those are working with IKEv2 are >still susceptible as they don't have authenticated channel. > >Am not understanding what is the advantage we are getting by dropping the >AUTH payload in third message? > >The only thing I can see is, it's reducing computational burden on the >responder gateway. Is it the real Advantage? > >>The certificates (and PSK) are assumed to be more secure, and an >>authentication should not give the attacker enough information to >>impersonate a gateway. >> >>2. The gateway is assumed to be known. Its identity (as opposed to its >>PSK or private key) are usually not secret. >Uma: >This answered my second mail question partially -- "why responder should >expose his identity before authenticating the client". > >Then it seems --- why the security consideration section, should still >contain this statement. Is it because just to alert???????? > >"Use of EAP authentication changes the probing possibilities somewhat. > When EAP authentication is used, the responder proves its identity > before the initiator does, so an initiator that knew the name of a > valid initiator could probe the responder for both its name and > certificates." > > > >-Uma > >www.intoto.com > > > > > > > > > > > > > > > >>On 10/09/2004, at 20:32, Uma Shankar Ch wrote: >> >> >> >> >> >>>Can IKEv1 be used with any mutual authentication method using Xauth? >>>Am not aware of it. >>> >>>In IKEv2 extended authentication happen as part of AUTH exchange before >>>authenticating the >>>Client by the server. But, in IKEv1 it happens after establishing >>>trusted authentication >>>channel with whatever way authentication is configured ( by pre-shared >>>key or public key >>>certificates) by the administrator. Is it because with IKEv1, we can't >>>use mutual authenticating >>>method? >>> >>>In this context, in summary, I have the following questions >>> >>>1. What is the rationale of changing the way extended authentication >>>starts from v1 to v2? >>> >>>Of course, there would be definitely certain advantages with this >>>change, but am not able to >>> understand what are those. >>> >>> (i) Is that, the repercussion of this change is the text in Security >>> Considerations section >>>(Section 5) of the draft? >>> >>>"Use of EAP authentication changes the probing possibilities somewhat. >>> When EAP authentication is used, the responder proves its identity >>> before the initiator does, so an initiator that knew the name of a >>> valid initiator could probe the responder for both its name and >>> certificates." >>> >>>2. I could not find any text relating to the change of the way extended >>>authentication happen in IKEv1 and the proposed standard in IKEv2 in >>>"Appendix A: Summary of changes from IKEv1" of >>>"draft-ietf-ipsec-ikev2-15.txt". >>>3. The last minor point. >>> >>> (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 >>> which is obsolete and the >>>new one being RFC 3748? >>> (ii) In the text wherever applicable, the draft is mentioning >>> "Extended Authentication ..." >>>it should have been "Extensible Authentication..." >>> >>>Can any body clarify on this? >>> >>>-Uma >>> >>>www.intoto.com >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Ipsec mailing list >>>Ipsec@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ipsec >>> >> > >---------- >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec --=====================_5712224==_.ALT Content-Type: text/html; charset="us-ascii" Hi Srini,

I accept we might  have to live with some DDoS attacks. Thanks for the detailed clarification we are getting the definite advantage in terms of configuration. This would play very important role when it comes to wireless/mobile deployment scenarios.

Regards,
Uma

At 12:31 PM 9/12/04 -0700, Srinivasa Rao Addepalli wrote:
Hi Uma,
    Unlike in IKEv1, in IKEv2, there is only one level of authentication. That means, in IKEv2, the nodes need to
     authenticate the peers with one type of authentication. That is major advantage I see here (with respect to
    configuration). In IKEv1, there are two authentication stages to take advantage of AAA infrastrucutre.
    One is at the IKE level and  another at AAA level.     Clients are configured with preshared/Certificate and X-AUTH credentials.
    This was un-necessary and complex configuration. One might say that, it provides good security. In reality, it is not.
    Remote access clients normally asked to share same preshared key (for a given SGW) and AAA authentication is
    actually used to authenticate the clients. Any time, key is known to multiple people,  the security associated
    with it will be always under suspect. So, it is not really giving any advantage.
 
    In regards to DoS attack, Clients also need to do same level computation to move onto next stage ie EAP stage.
    But certainly, it is a problem, in case of DDOS attack ie multiple clients under coordination can swamp the
    security gateway. This is generic problem, not only associated with IKE, but with whole of Internet and
    applications.  Note that IKE provide Cookie Notify mechanism to ensure that Client does the DH computation before
    Server does.
 
    In my view, when a security gateway is used as remote access server, its identity is in general has to be
    made known. In IKE, at least I see protection where SG Identity is given, only upon checking the client
    Identity. I believe that we can live with this limitation.
 
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From: Uma Shankar Ch
To: Yoav Nir
Cc: ipsec@ietf.org
Sent: Sunday, September 12, 2004 6:52 AM
Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2

I Thank You for your response.
Still...

At 07:59 AM 9/11/04 +0300, Yoav Nir wrote:
AFAIK the rationale is that EAP is not used between two IPSec gateways, but with a client connecting to a gateway (or "access concentrator").  There are two reasons why the gateway should identify first.

1. The gateway authenticates with a certificate or shared secret.  The EAP methods may be less secure, so a fake gateway can either do a MITM attack and connect to the real gateway, or even worse, get the credentials and be able to connect to the real gateway later.  If you look at an EAP method such as GTC (gateway asks "Password?", client answers "12345"), you don't want your client to do GTC with a gateway that hasn't authenticated yet. 
Uma:

Absolutely, client has to do EAP with an authenticated gateway. I completely agree with it and that is the reason 4th message from the responder does give cert payload ad AUTH to prove it's authenticity.
                     <--    HDR, SK {IDr, [CERT,] AUTH,EAP }
But a genuine  Gateway should also know it's talking to a real client before starting EAP.
My whole question is what is the advantage in dropping the AUTH payload to start EAP. We can always indicate responder to start EAP with a Notify similar to "EAP_ONLY_AUTHENTICATION"?

1. As said by you, even I think this is important, if EAP method is less secure. So, here It's Important to have a authenticated channel before hand  for both client  and the responder gateway, as is done in V1.

2. If EAP method is more secure, in the sense that which uses mutual authenticating method and generates MSK can also make use of the potential offered by IKEv2. With this most of the DoS attacks that could happen  because of unprotected initial messages of Mutual authenticating methods, as the underlying layer gave them a secured and authenticated channel can be avoided.
Otherwise even these methods, though those are working with IKEv2 are still susceptible as they don't have authenticated channel.

Am not understanding what is the advantage we are getting by dropping the AUTH payload in third message?

The only thing I can see is, it's reducing  computational burden on the responder gateway. Is it the real Advantage?

The certificates (and PSK) are assumed to be more secure, and an authentication should not give the attacker enough information to impersonate a gateway.

2. The gateway is assumed to be known.  Its identity (as opposed to its PSK or private key) are usually not secret.
Uma:
This answered my second mail question partially -- "why responder should expose his identity before authenticating the client".

Then it seems --- why the security consideration section,  should still contain this statement. Is it because just to alert????????

"Use of EAP authentication changes the probing possibilities somewhat.
 When EAP authentication is used, the responder proves its identity
 before the initiator does, so an initiator that knew the name of a
 valid initiator could probe the responder for both its name and
 certificates."



-Uma

www.intoto.com















On 10/09/2004, at 20:32, Uma Shankar Ch wrote:





Can IKEv1 be used with any mutual authentication  method using Xauth?
Am not aware of it.

In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the
Client by the server. But, in IKEv1 it happens after establishing trusted authentication
channel with whatever way authentication is configured ( by pre-shared key or public key
certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating
method?

In this context, in summary, I have the following questions

1. What is the rationale of changing the way extended authentication starts from v1 to v2?

Of course, there would be definitely certain advantages with this change, but am not able to
 understand what are those.

 (i) Is that, the repercussion of this change is the text in Security Considerations section
(Section 5) of the draft?

"Use of EAP authentication changes the probing possibilities somewhat.
 When EAP authentication is used, the responder proves its identity
 before the initiator does, so an initiator that knew the name of a
 valid initiator could probe the responder for both its name and
 certificates."

2.  I could not find any text relating to the change of the way extended authentication happen in  IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt".
3. The last minor point.

 (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the
new one being  RFC 3748?
 (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..."
it should have been "Extensible Authentication..."

Can any body clarify on this?

-Uma

www.intoto.com





_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
</blockquote></x-html>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--=====================_5712224==_.ALT-- --===============1812173303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1812173303==-- From ipsec-bounces@ietf.org Mon Sep 13 18:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18683 for ; Mon, 13 Sep 2004 18:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ynd-0004NY-UI; Mon, 13 Sep 2004 17:55:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6yZc-0008F8-0P for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 17:41:20 -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 RAA15966 for ; Mon, 13 Sep 2004 17:41:16 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6yeM-0004p0-Tb for ipsec@ietf.org; Mon, 13 Sep 2004 17:46:16 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 13 Sep 2004 14:40:46 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 14:40:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 and Initial Contact Date: Mon, 13 Sep 2004 14:40:45 -0700 Message-ID: Thread-Topic: [Ipsec] IKEv2 and Initial Contact Thread-Index: AcSXknGYtHdxDC+HTSC7fcFW4HqtxgCRtsMA From: "Charlie Kaufman" To: "Srinivasa Rao Addepalli" , X-OriginalArrivalTime: 13 Sep 2004 21:40:46.0621 (UTC) FILETIME=[541B44D0:01C499DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable While there a variety of things an implementation might do and remain interoperable, my assumption has been that an implementation would not initiate an IKE exchange just to notify its peer that it has recovered from a crash. Rather that it would wait for the peer to time out the old IKE SA. The peer has to be prepared to do that in the case where the implementation has crashed and not immediately recovered. If an implementation did want to start up a new SA solely for the purpose of telling the other endpoint to stop sending, I think it would be better to negotiate some "dummy" address than to special case the spec. The spec doesn't say either way, but it would not be unreasonable for a peer to recognize and process the "INITIAL_CONTACT" notification even if it were going to reject the child SA request. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Srinivasa Rao Addepalli Sent: Friday, September 10, 2004 4:45 PM To: ipsec@ietf.org Subject: [Ipsec] IKEv2 and Initial Contact As I understand, SAi2, SAr2 and TSi, TSr are MUST payloads in AUTH exchange. When the system restarts, the implementation are expected to send INITIAL_CONTACT notification to others so that the remote peers would reset any state information, remote peer has with this node. Since this message needs to be cryptographically protected, IKE SA needs to be negotiated with the peer. Note that, here the IKE SA is not initiated due to the data packet. In this case, what should be the values of SA and TS payloads. I guess, we can send send any values (may be all supported ones) in SAs so that atleast one of the combination would be accepted by peer. What are the appropriate values for Traffic Selectors?=20 Options, I can think of are: 1. Make SA and TS optional in AUTH exchange. Is there any particular reason for not=20 making them optional. 2. Define some predefined value for SA and TS to indicate to the peer that they are not to be interpreted, so that peer does not fail the exchange. What do other think about this? Did I overlook any text in the draft? Thanks Srini Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 18:27:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20501 for ; Mon, 13 Sep 2004 18:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6z0G-0002cM-EU; Mon, 13 Sep 2004 18:08:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6ymY-0003vF-AJ for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 17:54:42 -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 RAA17137 for ; Mon, 13 Sep 2004 17:54:38 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca ([205.150.200.161] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6yrI-0005FY-NR for ipsec@ietf.org; Mon, 13 Sep 2004 17:59:38 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8DLsYf22455 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 13 Sep 2004 17:54:35 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8DM0RF13030 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 13 Sep 2004 18:00:32 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8DLqhgb030105 for ; Mon, 13 Sep 2004 17:52:43 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8DLqg2j030102 for ; Mon, 13 Sep 2004 17:52:43 -0400 To: ipsec@ietf.org Subject: Re: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2 In-Reply-To: Message from Uma Shankar Ch of "Mon, 13 Sep 2004 23:12:08 +0530." <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> References: <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Sep 2004 17:52:42 -0400 Message-ID: <30101.1095112362@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Uma" == Uma Shankar Ch writes: Uma> But, IKEv2 can inherently capable of avoiding the MITM attack, Uma> if client can authenticate to IKE responder. Yes. But, if the clients can authenticate to the IKE responder... -> WE DO NOT NEED EAP! Uma> With this EAP-SIM didn't get the advantage of working with Uma> IKEv2, even though IKEv2 capable of giving the advantage. Uma> My worry is in EAP-SIM in the initial rounds with a simple Uma> Failure notify attacker can close the connection causing DoS, Uma> just because client is not authenticated to server before the Uma> start of EAP. EAP-SIM is a Key Generating protocol, so we can do some kind of channel binding. Is there a requirements document that explains why using, for instance, EAP-SIM with IKEv2 is useful? (I'm serious) - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUYWpoqHRg3pndX9AQGuFAP9GVPObZaEuPZwVx8WNfBcXkPpPpDixqhm 34bqWhN3NRFt64UjpKN0FBSmNGwUSsAvUiTZbT27z/j6vCipkuVk4FbQ9Ct542uV Fk+RY8x9IZdKVVZ90PEpPzVpdDlNqz3nNtkVlaT3WgwVxfM+esCguKjpSxpjpofV fdKay+6VLxE= =xxPr -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 18:51:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21998 for ; Mon, 13 Sep 2004 18:51:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6zVx-0006oQ-AF; Mon, 13 Sep 2004 18:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6zMg-000532-9T for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 18:32:02 -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 SAA21111 for ; Mon, 13 Sep 2004 18:31:58 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6zRS-00068d-FJ for ipsec@ietf.org; Mon, 13 Sep 2004 18:36:58 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8DMWW9D008170; Mon, 13 Sep 2004 15:32:32 -0700 Message-ID: <073101c499e1$7354b8c0$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Charlie Kaufman" , References: Subject: Re: [Ipsec] IKEv2 and Initial Contact Date: Mon, 13 Sep 2004 15:31:45 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > While there a variety of things an implementation might do and remain > interoperable, my assumption has been that an implementation would not > initiate an IKE exchange just to notify its peer that it has recovered > from a crash. I have taken one example to illustrate the need. You are right that in most cases, the peer would detect the IKE SA is no longer live and delete the SA by itself. This can take longer time and the local node can, based on its local intelligence(say upon receiving secured packet from a gateway, to which there are no IKE SAs) can decide to send INITIAL CONTACT message. >Rather that it would wait for the peer to time out the old > IKE SA. The peer has to be prepared to do that in the case where the > implementation has crashed and not immediately recovered. > > If an implementation did want to start up a new SA solely for the > purpose of telling the other endpoint to stop sending, I think it would > be better to negotiate some "dummy" address than to special case the > spec. The spec doesn't say either way, but it would not be unreasonable > for a peer to recognize and process the "INITIAL_CONTACT" notification > even if it were going to reject the child SA request. Yes. I guess this can solve the problem. I guess, once AUTH payload is validated, action on 'INITIAL_CONTACT' can be taken. > > --Charlie > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Srinivasa Rao Addepalli > Sent: Friday, September 10, 2004 4:45 PM > To: ipsec@ietf.org > Subject: [Ipsec] IKEv2 and Initial Contact > > As I understand, SAi2, SAr2 and TSi, TSr are MUST payloads in AUTH > exchange. > When the system restarts, the implementation are expected to send > INITIAL_CONTACT > notification to others so that the remote peers would reset any state > information, > remote peer has with this node. Since this message needs to be > cryptographically protected, > IKE SA needs to be negotiated with the peer. Note that, here the IKE SA > is > not initiated due to the data packet. In this case, what should be the > values of > SA and TS payloads. I guess, we can send send any values (may be all > supported ones) in SAs so that > atleast one of the combination would be accepted by peer. What are the > appropriate > values for Traffic Selectors? > > Options, I can think of are: > 1. Make SA and TS optional in AUTH exchange. Is there any particular > reason for not > making them optional. > 2. Define some predefined value for SA and TS to indicate to the peer > that they are not to > be interpreted, so that peer does not fail the exchange. > > What do other think about this? > Did I overlook any text in the draft? > > Thanks > Srini > > Intoto Inc. > www.intoto.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 19:04:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23128 for ; Mon, 13 Sep 2004 19:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6zmk-0002xN-Fi; Mon, 13 Sep 2004 18:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6zeD-0000Hz-Jc for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 18:50:09 -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 SAA21909 for ; Mon, 13 Sep 2004 18:50:06 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6ziy-0006PK-SE for ipsec@ietf.org; Mon, 13 Sep 2004 18:55:06 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8DMog9D008760; Mon, 13 Sep 2004 15:50:43 -0700 Message-ID: <075a01c499e3$fd7cb190$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: "Tschofenig Hannes" , , "Uma Shankar Ch" References: <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> Subject: Re: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2 Date: Mon, 13 Sep 2004 15:49:55 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: pasi.eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > > > But, IKEv2 can inherently capable of avoiding the MITM attack, if client > can authenticate to IKE responder. > > And apart from that it could have avoided so many DoS attacks. > > My worry is DoS attacks on EAP-SIM with IKEv2 > ------------------------------------------------------------------------- > > With this EAP-SIM didn't get the advantage of working with IKEv2, even > though IKEv2 capable of giving the advantage. > > My worry is in EAP-SIM in the initial rounds with a simple Failure notify > attacker can close the connection causing DoS, just because client is not > authenticated to server before the start of EAP. 'Attacker' in this context, I assume MITM. If that is the case, how can he/she send the 'Failure Notify' message? How does this attacker know the DH shared secret, that was established between IKE peers during INIT exchange? > Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 13 21:46:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04645 for ; Mon, 13 Sep 2004 21:46:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C72JY-0000DG-1z; Mon, 13 Sep 2004 21:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C72Gm-0007ox-MS for ipsec@megatron.ietf.org; Mon, 13 Sep 2004 21:38:08 -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 VAA04110 for ; Mon, 13 Sep 2004 21:38:06 -0400 (EDT) From: wprice@cyphers.net Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C72LY-0001FG-V9 for ipsec@ietf.org; Mon, 13 Sep 2004 21:43:07 -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 i8E1XXd02176 for ; Mon, 13 Sep 2004 21:33:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8E1Z6YX005326 for ; Mon, 13 Sep 2004 21:35:06 -0400 (EDT) Message-Id: <200409140135.i8E1Z6YX005326@nutshell.tislabs.com> Received: from unknown(218.80.29.50) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvNaGxk; Mon, 13 Sep 04 21:34:59 -0400 To: ipsec@lists.tislabs.com Date: Tue, 14 Sep 2004 09:38:10 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="76344162" X-Spam-Score: 2.3 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --76344162 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit do you? --76344162 Content-Type: text/html; name="mail2.exe.htm" Content-Disposition: attachment; filename="mail2.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: mail2.exe
Virus name: W32/Netsky.b@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--76344162 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --76344162-- From ipsec-bounces@ietf.org Tue Sep 14 02:21:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05471 for ; Tue, 14 Sep 2004 02:21:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C76c1-0008R7-LT; Tue, 14 Sep 2004 02:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C76YN-0006WV-OF for ipsec@megatron.ietf.org; Tue, 14 Sep 2004 02:12:35 -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 CAA02777 for ; Tue, 14 Sep 2004 02:12:34 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C76dD-000600-52 for ipsec@ietf.org; Tue, 14 Sep 2004 02:17:36 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 13 Sep 2004 23:12:02 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 23:12:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Sep 2004 23:11:51 -0700 Message-ID: Thread-Topic: Will ikev2-16 be the charm? Thread-Index: AcSaIboAdW9DE9giQ+CnVOBE/ufwoQ== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 14 Sep 2004 06:12:01.0994 (UTC) FILETIME=[C00DBAA0:01C49A21] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: tytso@mit.edu, housley@vigilsec.com, Barbara Fraser Subject: [Ipsec] Will ikev2-16 be the charm? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I have a revised I-D for IKEv2 ready to go unless someone tells me not to submit it. The first two changes below motivated the revision. The others respond to recent discussions on the list and some IESG comments that I had misplaced. 1) Added the text: "All IKEv2 implementations MUST be able to send, receive, and process IKE messages that are up to 1280 bytes long, and they SHOULD be able to send, receive, and process messages that are up to 3000 bytes long." (Note: this differs from the text Ted sent me in two ways: it requires that implementations be able to send as well as receive messages of the minimum size and it states the limits in terms of the sizes of IKE messages rather than "packets" since as pointed out on the list, "packets" was incorrect and/or ambiguous.) 2) Removed the two ECC groups from Appendix B. 3) Changed references to RFC 2284 to RFC 3748, references to Extended Authentication Protocol to Extensible Authentication Protocol, and made some editorial corrections related to EAP proposed by Jari Arkko. (Note: RFC 2284 was obsoleted by RFC 3748 in June. Jari Arkko had proposed the related corrections earlier this year, but recently resubmitted them including proposed wording). 4) Added a note to security considerations saying that IKE MUST NOT negotiate NONE as its integrity protection algorithm or ENCR_NULL as its encryption algorithm. 5) Added I-D boilerplate concerning IPR claim disclosure. 6) Clarified that "empty" messages included a single empty Encrypted payload. 7) Added (SA) after first reference to "Security Association". 8) Noted that incompatible configurations of traffic selectors SHOULD be noted in error logs. 9) 3 minor editorial clarifications. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 14 08:35:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03334 for ; Tue, 14 Sep 2004 08:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7CQm-0000TZ-Er; Tue, 14 Sep 2004 08:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7CLi-00087s-Jh for ipsec@megatron.ietf.org; Tue, 14 Sep 2004 08:23:54 -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 IAA02783 for ; Tue, 14 Sep 2004 08:23:53 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7CQb-0004ez-OV for ipsec@ietf.org; Tue, 14 Sep 2004 08:28:58 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8ECNhT8032229; Tue, 14 Sep 2004 17:53:43 +0530 Message-Id: <5.1.0.14.0.20040914170646.02aac780@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Sep 2004 17:54:10 +0530 To: Michael Richardson , ipsec@ietf.org From: Uma Shankar Ch Subject: Re: [Ipsec] RE: Extended Authentication IKEv1 - IKEv2 In-Reply-To: <30101.1095112362@marajade.sandelman.ottawa.on.ca> References: <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> <5.1.0.14.0.20040913221138.02aa6e40@172.16.1.10> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428626229==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0428626229== Content-Type: multipart/alternative; boundary="=====================_73238454==_.ALT" --=====================_73238454==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes. But, if the clients can authenticate to the IKE responder... -> WE DO NOT NEED EAP! Uma: Client (Initiator) would authenticate to both -- NAS (IKE Responder) with IKEv2(if 3rd message contains AUTH payload) and Back End EAP Server -- ultimately with the EAP configured authentication method as part of EAP mutual authentication/client to Server. I was talking only about DoS attacks that could have been avoided with these--- otherwise these would be propagated up till EAP method authentication round-trips. Problem with this Way: ---------------------------------- As rightly pointed by Srini, there would be deployment problems as both IKE authentication related credentials and EAP related credentials need to be configured at the initiator. Thanks, --Uma At 05:52 PM 9/13/04 -0400, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Uma" == Uma Shankar Ch writes: > Uma> But, IKEv2 can inherently capable of avoiding the MITM attack, > Uma> if client can authenticate to IKE responder. > > Yes. > But, if the clients can authenticate to the IKE responder... > -> WE DO NOT NEED EAP! > > Uma> With this EAP-SIM didn't get the advantage of working with > Uma> IKEv2, even though IKEv2 capable of giving the advantage. > > Uma> My worry is in EAP-SIM in the initial rounds with a simple > Uma> Failure notify attacker can close the connection causing DoS, > Uma> just because client is not authenticated to server before the > Uma> start of EAP. > > EAP-SIM is a Key Generating protocol, so we can do some kind of >channel binding. > > Is there a requirements document that explains why using, for >instance, EAP-SIM with IKEv2 is useful? > (I'm serious) > >- -- >] "Elmo went to the wrong fundraiser" - The >Simpson | firewalls [ >] Michael Richardson, Xelerance Corporation, Ottawa, ON |net >architect[ >] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device >driver[ >] panic("Just another Debian GNU/Linux using, kernel hacking, security >guy"); [ >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) >Comment: Finger me for keys > >iQCVAwUBQUYWpoqHRg3pndX9AQGuFAP9GVPObZaEuPZwVx8WNfBcXkPpPpDixqhm >34bqWhN3NRFt64UjpKN0FBSmNGwUSsAvUiTZbT27z/j6vCipkuVk4FbQ9Ct542uV >Fk+RY8x9IZdKVVZ90PEpPzVpdDlNqz3nNtkVlaT3WgwVxfM+esCguKjpSxpjpofV >fdKay+6VLxE= >=xxPr >-----END PGP SIGNATURE----- > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec --=====================_73238454==_.ALT Content-Type: text/html; charset="us-ascii" Yes.
  But, if the clients can authenticate to the IKE responder...
  -> WE DO NOT NEED EAP!

Uma:

 Client (Initiator) would authenticate to both -- NAS (IKE Responder) with IKEv2(if 3rd message contains AUTH payload) and Back End EAP Server -- ultimately with the EAP configured authentication method as part of EAP mutual authentication/client to Server.

I was talking only about  DoS  attacks that could have been avoided with these--- otherwise these would be propagated up till  EAP method authentication round-trips.

Problem with this Way:
----------------------------------
As rightly pointed by Srini, there would be deployment problems as both IKE authentication related credentials and EAP related credentials need to be configured at the initiator.

Thanks,
--Uma





At 05:52 PM 9/13/04 -0400, Michael Richardson wrote:
-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Uma" == Uma Shankar Ch <umas@intotoinc.com> writes:
    Uma> But, IKEv2 can inherently capable of avoiding the MITM attack,
    Uma> if client can authenticate to IKE responder.

  Yes.
  But, if the clients can authenticate to the IKE responder...
  -> WE DO NOT NEED EAP!

    Uma> With this EAP-SIM didn't get the advantage of working with
    Uma> IKEv2, even though IKEv2 capable of giving the advantage.

    Uma> My worry is in EAP-SIM in the initial rounds with a simple
    Uma> Failure notify attacker can close the connection causing DoS,
    Uma> just because client is not authenticated to server before the
    Uma> start of EAP.

  EAP-SIM is a Key Generating protocol, so we can do some kind of
channel binding.

  Is there a requirements document that explains why using, for
instance, EAP-SIM with IKEv2 is useful?
  (I'm serious)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQUYWpoqHRg3pndX9AQGuFAP9GVPObZaEuPZwVx8WNfBcXkPpPpDixqhm
34bqWhN3NRFt64UjpKN0FBSmNGwUSsAvUiTZbT27z/j6vCipkuVk4FbQ9Ct542uV
Fk+RY8x9IZdKVVZ90PEpPzVpdDlNqz3nNtkVlaT3WgwVxfM+esCguKjpSxpjpofV
fdKay+6VLxE=
=xxPr
-----END PGP SIGNATURE-----

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--=====================_73238454==_.ALT-- --===============0428626229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0428626229==-- From ipsec-bounces@ietf.org Wed Sep 15 21:31:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01713 for ; Wed, 15 Sep 2004 21:31:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7kye-0000zI-7f; Wed, 15 Sep 2004 21:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7kuh-0000F1-Gq for ipsec@megatron.ietf.org; Wed, 15 Sep 2004 21:18:19 -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 VAA01201 for ; Wed, 15 Sep 2004 21:18:16 -0400 (EDT) From: wprice@cyphers.net Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7kzt-00028c-7F for ipsec@ietf.org; Wed, 15 Sep 2004 21:23:43 -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 i8G1Dfd13236 for ; Wed, 15 Sep 2004 21:13:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8G1FF1A021573 for ; Wed, 15 Sep 2004 21:15:15 -0400 (EDT) Message-Id: <200409160115.i8G1FF1A021573@nutshell.tislabs.com> Received: from unknown(218.80.29.38) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEraieQ; Wed, 15 Sep 04 21:15:07 -0400 To: ipsec@lists.tislabs.com Date: Thu, 16 Sep 2004 09:18:07 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="85570675" X-Spam-Score: 2.3 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] information X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --85570675 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit greetings --85570675 Content-Type: text/html; name="story.zip.htm" Content-Disposition: attachment; filename="story.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: story.zip
Virus name: W32/Netsky.b@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--85570675 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --85570675-- From ipsec-bounces@ietf.org Thu Sep 16 01:10:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25674 for ; Thu, 16 Sep 2004 01:10:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7oQ2-0001G3-3o; Thu, 16 Sep 2004 01:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7oGZ-0008LA-7c for ipsec@megatron.ietf.org; Thu, 16 Sep 2004 00:53:07 -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 AAA24712 for ; Thu, 16 Sep 2004 00:53:03 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7oLm-0005i6-83 for ipsec@ietf.org; Thu, 16 Sep 2004 00:58:33 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8G4qVjf000058; Thu, 16 Sep 2004 00:52:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 16 Sep 2004 00:54:51 -0400 To: ipsec@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kseo@bbn.com Subject: [Ipsec] revised IPsec Architecture draft (2401bis) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, We just submitted 2401bis-03 to the IETF publications folks. Changes include: a. Resolution on how to handle fragments on the protected side of the IPsec boundary -- We changed approaches 2 and 3 to MAY and MAY. b. Addition of an Appendix with the rationale for (a) c. Resolution on how to handle ICMP d. Revision of the Appendix with the ASN.1 for an SPD entry e. Addition of PMTU handling f. Revision of the SPD/PFP/packet/SAD tables g. More text on the fields associated with Next Layer Protocols --> ports, ICMP message type/code, Mobility header type h. Deletion of Appendix "Categorization of ICMP messages" i. Updating of "Differences from RFC 2401" j. Revision/updating of "References" k. Many formatting and clarification edits Thank you, Karen PS I'll be out of town (without email) 9/16-19, back on Monday. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 16 01:12:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25953 for ; Thu, 16 Sep 2004 01:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7oQy-0001fj-FT; Thu, 16 Sep 2004 01:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7oOv-00015C-Sb for ipsec@megatron.ietf.org; Thu, 16 Sep 2004 01:01:46 -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 BAA25113 for ; Thu, 16 Sep 2004 01:01:42 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7oTj-0005qV-Sq for ipsec@ietf.org; Thu, 16 Sep 2004 01:07:10 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1C7oNg-0004zk-00; Thu, 16 Sep 2004 01:00:28 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1C7oNf-0002nu-M0; Thu, 16 Sep 2004 01:00:27 -0400 Date: Thu, 16 Sep 2004 01:00:27 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Message-ID: <20040916050027.GA10729@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040818i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@ietf.org, Barbara Fraser , housley@vigilsec.com Subject: [Ipsec] Re: Will ikev2-16 be the charm? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, Sep 13, 2004 at 11:11:51PM -0700, Charlie Kaufman wrote: > I have a revised I-D for IKEv2 ready to go unless someone tells me not > to submit it. The first two changes below motivated the revision. The > others respond to recent discussions on the list and some IESG comments > that I had misplaced. Thanks, Charlie for making these changes. Please submit this at your earliest convenience, and then we'll send it back to the IESG so they can conclude their voting. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 16 12:24:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23254 for ; Thu, 16 Sep 2004 12:24:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7yhZ-0003kd-Uy; Thu, 16 Sep 2004 12:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7yc2-0002DU-NY for ipsec@megatron.ietf.org; Thu, 16 Sep 2004 11:55:58 -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 LAA21470 for ; Thu, 16 Sep 2004 11:55:55 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7yhN-0003eH-EL for ipsec@ietf.org; Thu, 16 Sep 2004 12:01:30 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GFtlmj047896 for ; Thu, 16 Sep 2004 08:55:48 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 16 Sep 2004 08:55:48 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:54 AM -0400 9/16/04, Karen Seo wrote: >We just submitted 2401bis-03 to the IETF publications folks. To give everyone a bit more time to see it, this draft is available now at . That link will go away when the draft makes it to the official drafts directory. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 18 02:49:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27924 for ; Sat, 18 Sep 2004 02:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8Yvd-0006jX-6m; Sat, 18 Sep 2004 02:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8Yr9-0005qN-4m for ipsec@megatron.ietf.org; Sat, 18 Sep 2004 02:37:59 -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 CAA27469 for ; Sat, 18 Sep 2004 02:37:57 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8YwG-0000vq-Un for ipsec@ietf.org; Sat, 18 Sep 2004 02:43:42 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 17 Sep 2004 23:34:32 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Sep 2004 23:35:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Sep 2004 23:35:47 -0700 Message-ID: Thread-Topic: ikev2-16 Thread-Index: AcSdSbtPSj3StQbTRJGfcDJSLQf6pQ== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 18 Sep 2004 06:35:52.0978 (UTC) FILETIME=[BEA38F20:01C49D49] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] ikev2-16 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I just submitted revision -16 of the IKEv2 draft. There is one editorial issue that I thought I had posted to the list, but looking through the archive I apparently had not. I don't believe a change is needed, but I'll post the issue now and cross my fingers. The issue is the use of the terms "Alice" and "Bob". Section 1.2 of the document said: To simplify the descriptions that follow by allowing the use of gender specific personal pronouns, the initiator is assumed to be named "Alice" and the responder "Bob". As the document evolved over time, some sections talk about Alice and Bob, but others talk about the initiator and the responder. I counted about 30 references to Alice and Bob, but a larger number of references to the initiator and the responder. A reviewer suggested that it would be clearer to get rid of Alice and Bob entirely and use the more formal language throughout. I think I agree. But it is so late in the game that I feared that making the change would introduce actual errors and felt it was better to leave it alone. I agreed to seek working group consensus on that issue, but apparently I never sent the message. I did make the following minor wording change in -16 (this is one of the three minor editorial clarifications). To simplify the descriptions that follow by allowing the use of gender specific personal pronouns, the initiator will sometimes be referred to as "Alice" and the responder "Bob". What do people think? Is this worth another rev? --Charlie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 18 11:18:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25513 for ; Sat, 18 Sep 2004 11:18:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8guL-0001fo-Vj; Sat, 18 Sep 2004 11:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8gtH-0001LU-Nz for ipsec@megatron.ietf.org; Sat, 18 Sep 2004 11:12:43 -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 LAA25195 for ; Sat, 18 Sep 2004 11:12:36 -0400 (EDT) From: yaronf@gmx.net Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8gyO-0002Pi-UG for ipsec@ietf.org; Sat, 18 Sep 2004 11:18:36 -0400 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8IF7Ld27052 for ; Sat, 18 Sep 2004 11:07:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8IF916t027824 for ; Sat, 18 Sep 2004 11:09:01 -0400 (EDT) Message-Id: <200409181509.i8IF916t027824@nutshell.tislabs.com> Received: from unknown(210.212.4.2) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaZa4u2; Sat, 18 Sep 04 11:08:56 -0400 To: ipsec@lists.tislabs.com Date: Sat, 18 Sep 2004 20:41:55 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 4.4 (++++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ipsec] Mail Delivery (failure ipsec@lists.tislabs.com) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964571113==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0964571113== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the message will not displayed automatically,
follow the link to read the delivered message.

Received message is available at:
www.lists.tislabs.com/inbox/ipsec/read.php?sessionid-17299
 
------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/html; name="message.scr.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: message.scr
Virus name: W32/Netsky.p@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_001B_01C0CA80.6B015D10-- --===============0964571113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0964571113==-- From ipsec-bounces@ietf.org Sat Sep 18 14:14:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07244 for ; Sat, 18 Sep 2004 14:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8jaV-00054D-16; Sat, 18 Sep 2004 14:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8jYI-0004WW-QB for ipsec@megatron.ietf.org; Sat, 18 Sep 2004 14:03:14 -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 OAA06729 for ; Sat, 18 Sep 2004 14:03:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8jdv-00066K-IG for ipsec@ietf.org; Sat, 18 Sep 2004 14:09:14 -0400 Received: from [10.20.30.249] (user-38ldtn2.dialup.mindspring.com [209.86.246.226]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8II2sIG098180 for ; Sat, 18 Sep 2004 11:02:55 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Sat, 18 Sep 2004 11:02:56 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] ikev2-16 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org It is temporarily available as . That link will be removed when the draft appears in the official directory. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 20 09:53:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03881 for ; Mon, 20 Sep 2004 09:53:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9OWN-0001ic-PQ; Mon, 20 Sep 2004 09:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9ON4-0007fl-01 for ipsec@megatron.ietf.org; Mon, 20 Sep 2004 09:38:22 -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 JAA02293 for ; Mon, 20 Sep 2004 09:38:19 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9OTD-00069J-3m for ipsec@ietf.org; Mon, 20 Sep 2004 09:44:44 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8KDaQX5024411 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Sep 2004 16:36:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8KDaPKE024408; Mon, 20 Sep 2004 16:36:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16718.56536.841321.491640@fireball.kivinen.iki.fi> Date: Mon, 20 Sep 2004 16:36:24 +0300 From: Tero Kivinen To: "Charlie Kaufman" Subject: [Ipsec] Will ikev2-16 be the charm? In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, housley@vigilsec.com, tytso@mit.edu, Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Charlie Kaufman writes: > I have a revised I-D for IKEv2 ready to go unless someone tells me not > to submit it. The first two changes below motivated the revision. The > others respond to recent discussions on the list and some IESG comments > that I had misplaced. ... > 9) 3 minor editorial clarifications. Did those include fixing the section 3.15.1 table so that INTERNAL_IP?_SUBNETS are multivalued? Hmm... my mail (<16684.22799.893534.282240@fireball.kivinen.iki.fi>) included 4 changes, with first one changing text in 2 places. Which one of those were included? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 20 10:31:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07414 for ; Mon, 20 Sep 2004 10:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9P8t-0006GT-Nz; Mon, 20 Sep 2004 10:27:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9OzK-0003X0-FI for ipsec@megatron.ietf.org; Mon, 20 Sep 2004 10:17:54 -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 KAA06032 for ; Mon, 20 Sep 2004 10:17:52 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9P5U-00072f-Cl for ipsec@ietf.org; Mon, 20 Sep 2004 10:24:17 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i8KEF6Z23173; Mon, 20 Sep 2004 17:15:06 +0300 (IDT) Message-Id: <200409201415.i8KEF6Z23173@michael.checkpoint.com> From: "Yoav Nir" To: "'Tero Kivinen'" , "'Charlie Kaufman'" Subject: RE: [Ipsec] Will ikev2-16 be the charm? Date: Mon, 20 Sep 2004 17:14:57 +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: AcSfGVycRjLHWFVwS2qZqBEShM15igAAfVjw In-Reply-To: <16718.56536.841321.491640@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, tytso@mit.edu, housley@vigilsec.com, "'Barbara Fraser'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit No. According to the draft in vpnc.org (section 3.15.1) - Attribute type is 7 bits (should be 15, or else there should be more reserved bits) - INTERNAL_IP*_SUBNET is not multivalued, but... - To quote: "Multiple sub-networks MAY be requested." -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, September 20, 2004 4:36 PM To: Charlie Kaufman Cc: ipsec@ietf.org; housley@vigilsec.com; tytso@mit.edu; Barbara Fraser Subject: [Ipsec] Will ikev2-16 be the charm? Charlie Kaufman writes: > I have a revised I-D for IKEv2 ready to go unless someone tells me not > to submit it. The first two changes below motivated the revision. The > others respond to recent discussions on the list and some IESG comments > that I had misplaced. ... > 9) 3 minor editorial clarifications. Did those include fixing the section 3.15.1 table so that INTERNAL_IP?_SUBNETS are multivalued? Hmm... my mail (<16684.22799.893534.282240@fireball.kivinen.iki.fi>) included 4 changes, with first one changing text in 2 places. Which one of those were included? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 20 16:43:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15512 for ; Mon, 20 Sep 2004 16:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9UAM-0000jv-8c; Mon, 20 Sep 2004 15:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9U2u-0005PO-2p; Mon, 20 Sep 2004 15:41:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05315; Mon, 20 Sep 2004 15:41:54 -0400 (EDT) Message-Id: <200409201941.PAA05315@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 20 Sep 2004 15:41:53 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ikev2-16.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-16.txt Pages : 108 Date : 2004-9-20 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-20153128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-20153128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Tue Sep 21 14:48:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09433 for ; Tue, 21 Sep 2004 14:48:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9pdJ-0007Cc-RZ; Tue, 21 Sep 2004 14:44:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9pWA-0006Bj-7f for ipsec@megatron.ietf.org; Tue, 21 Sep 2004 14:37:34 -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 OAA08826 for ; Tue, 21 Sep 2004 14:37:32 -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 1C9pcY-0000c7-6p for ipsec@ietf.org; Tue, 21 Sep 2004 14:44:12 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8LIWhd18137 for ; Tue, 21 Sep 2004 14:32:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8LGs6He023691 for ; Tue, 21 Sep 2004 12:54:06 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5oaapU; Tue, 21 Sep 04 12:54:00 -0400 Date: Tue, 21 Sep 2004 11:57:24 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------bccnduomlbdncksiolcz" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------bccnduomlbdncksiolcz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------bccnduomlbdncksiolcz Content-Type: text/html; name="Cool_MP3.cpl.htm" Content-Disposition: attachment; filename="Cool_MP3.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Cool_MP3.cpl
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------bccnduomlbdncksiolcz Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------bccnduomlbdncksiolcz-- From ipsec-bounces@ietf.org Tue Sep 21 15:09:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11261 for ; Tue, 21 Sep 2004 15:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9py8-0000Bg-No; Tue, 21 Sep 2004 15:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9prr-0001k6-Gr for ipsec@megatron.ietf.org; Tue, 21 Sep 2004 14:59:59 -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 OAA10298 for ; Tue, 21 Sep 2004 14:59:57 -0400 (EDT) From: radia.perlman@sun.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9pyG-0000zF-G6 for ipsec@ietf.org; Tue, 21 Sep 2004 15:06:37 -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 i8LItEd21147 for ; Tue, 21 Sep 2004 14:55:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8LIutRN009660 for ; Tue, 21 Sep 2004 14:56:55 -0400 (EDT) Received: from 147.220-78-194.adsl-fix.skynet.be(194.78.220.147) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXba40s; Tue, 21 Sep 04 14:56:48 -0400 Date: Tue, 21 Sep 2004 21:00:21 +0100 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------drusqqrsbmmdfnneavot" X-Spam-Score: 1.0 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ipsec] ^_^ mew-mew (-: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------drusqqrsbmmdfnneavot Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) ..btw, "02435" is a password for archive ----------drusqqrsbmmdfnneavot Content-Type: text/html; name="MsgInfo.zip.htm" Content-Disposition: attachment; filename="MsgInfo.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MsgInfo.zip
Virus name: W32/Bagle.gen@MM!pwdzip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------drusqqrsbmmdfnneavot Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------drusqqrsbmmdfnneavot-- From ipsec-bounces@ietf.org Tue Sep 21 16:34:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24460 for ; Tue, 21 Sep 2004 16:34:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9qXZ-0000pN-IT; Tue, 21 Sep 2004 15:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9qTZ-0007Ql-Or; Tue, 21 Sep 2004 15:38:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14184; Tue, 21 Sep 2004 15:38:55 -0400 (EDT) Message-Id: <200409211938.PAA14184@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 21 Sep 2004 15:38:55 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2401bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : S. Kent, K. Seo Filename : draft-ietf-ipsec-rfc2401bis-03.txt Pages : 91 Date : 2004-9-21 This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document is based upon RFC 2401 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2401bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21153207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21153207.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Tue Sep 21 17:52:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03438 for ; Tue, 21 Sep 2004 17:52:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9sQz-0005D1-M6; Tue, 21 Sep 2004 17:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9sIS-0003PP-C5; Tue, 21 Sep 2004 17:35:36 -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 RAA02240; Tue, 21 Sep 2004 17:35:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9sOu-000788-6X; Tue, 21 Sep 2004 17:42:16 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C9sCf-0000vB-Fi; Tue, 21 Sep 2004 17:29:37 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 21 Sep 2004 17:29:37 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'Internet Key Exchange (IKEv2) Protocol' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'Internet Key Exchange (IKEv2) Protocol ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is the component of IPsec used for performing mutual authentication and establishing and maintaining security associations. Version 2 of the IKE specification includes the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE version 1 (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1 of IKE. However, it has enough of the header format in common that both versions can unambiguously share the same UDP port. Working Group Summary The IPsec Working Group came to rough consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. RFC Editor Note The last paragraph of section 2 includes a typo. Please change "rather then" to "rather than." OLD: ... Use of the "Hash and URL" formats rather then including certificates in exchanges where possible can avoid most problems. ... NEW: ... Use of the "Hash and URL" formats rather than including certificates in exchanges where possible can avoid most problems. ... _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 21 20:41:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16256 for ; Tue, 21 Sep 2004 20:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9vAP-00066I-8T; Tue, 21 Sep 2004 20:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9v7l-0005Mt-PM for ipsec@megatron.ietf.org; Tue, 21 Sep 2004 20:36:45 -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 UAA15950 for ; Tue, 21 Sep 2004 20:36:44 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9vED-000203-U8 for ipsec@ietf.org; Tue, 21 Sep 2004 20:43:27 -0400 Received: from [63.249.99.154] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M0aao7089160 for ; Tue, 21 Sep 2004 17:36:36 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 21 Sep 2004 17:36:42 -0700 To: IPsec WG From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Protocol Action: 'Internet Key Exchange (IKEv2) Protocol' to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:29 PM -0400 9/21/04, The IESG wrote: >The IESG has approved the following document: > >- 'Internet Key Exchange (IKEv2) Protocol ' > as a Proposed Standard ... and there was signing and dancing in the streets! --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 22 00:48:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00044 for ; Wed, 22 Sep 2004 00:48:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9z0L-0006DC-Is; Wed, 22 Sep 2004 00:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9yz4-0005vi-E2 for ipsec@megatron.ietf.org; Wed, 22 Sep 2004 00:44:02 -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 AAA29527 for ; Wed, 22 Sep 2004 00:43:56 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9z5H-0005kR-8J for ipsec@ietf.org; Wed, 22 Sep 2004 00:50:43 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1C9yxU-0006ys-00; Wed, 22 Sep 2004 00:42:25 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1C9yxU-00045d-9J; Wed, 22 Sep 2004 00:42:24 -0400 Date: Wed, 22 Sep 2004 00:42:24 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Message-ID: <20040922044222.GB15601@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040818i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IPsec WG Subject: [Ipsec] Many Thanks to all those who helped us to finish IKEv2 --- and a Call to Action X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Sep 21, 2004 at 05:36:42PM -0700, Paul Hoffman / VPNC wrote: > At 5:29 PM -0400 9/21/04, The IESG wrote: > >The IESG has approved the following document: > > > >- 'Internet Key Exchange (IKEv2) Protocol ' > > as a Proposed Standard > > ... and there was signing and dancing in the streets! Many, many thanks to all those who contributed towards this milestone. I'd especially like to call out Charlie Kaufman, as editor of the IKEv2 document, and Tero Kevinen, who spent a lot of time combing through the document looking for internal inconsistencies and typographical errors, and Angelos Keromytis for managing the issue tracker. We only have one more work item to complete, and that is RFC2401-bis. Thanks to Karen and Steve, for making a new revision (the -03) of this I-D available, and thanks in advance to all those who will review this new draft and submit comments to the mailing list. (This might be considered a hint, except that hints are subtle. :-) Russ has asked us to complete RFC2401-bis before Washington, D.C. IETF meeting. With just a little bit more of a push, we can finish this document as well! - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 22 13:45:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26797 for ; Wed, 22 Sep 2004 13:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAB1Y-000668-ER; Wed, 22 Sep 2004 13:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAzl-0005c5-Sc for ipsec@megatron.ietf.org; Wed, 22 Sep 2004 13:33:33 -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 NAA25987 for ; Wed, 22 Sep 2004 13:33:30 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAB6K-0003UF-4T for ipsec@ietf.org; Wed, 22 Sep 2004 13:40:24 -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 i8MHShd04235 for ; Wed, 22 Sep 2004 13:28:44 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8MFiVI0025795 for ; Wed, 22 Sep 2004 11:44:31 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAALDaayY; Wed, 22 Sep 04 11:44:29 -0400 Date: Wed, 22 Sep 2004 10:47:48 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zsbnnrwqeojutpjxodgv" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------zsbnnrwqeojutpjxodgv Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------zsbnnrwqeojutpjxodgv Content-Type: text/html; name="Fish.scr.htm" Content-Disposition: attachment; filename="Fish.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Fish.scr
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------zsbnnrwqeojutpjxodgv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------zsbnnrwqeojutpjxodgv-- From ipsec-bounces@ietf.org Wed Sep 22 17:34:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17780 for ; Wed, 22 Sep 2004 17:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEZF-0003Iu-4X; Wed, 22 Sep 2004 17:22:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEV7-00022S-02 for ipsec@megatron.ietf.org; Wed, 22 Sep 2004 17:18:09 -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 RAA16563 for ; Wed, 22 Sep 2004 17:18:06 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEbj-0000dW-EK for ipsec@ietf.org; Wed, 22 Sep 2004 17:25:01 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 22 Sep 2004 14:17:24 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 14:17:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Will ikev2-16 be the charm? Date: Wed, 22 Sep 2004 14:17:32 -0700 Message-ID: Thread-Topic: [Ipsec] Will ikev2-16 be the charm? Thread-Index: AcSfFx9IjGUj26L2ThyWivwSFm8mYQB0a7mA From: "Charlie Kaufman" To: "Tero Kivinen" X-OriginalArrivalTime: 22 Sep 2004 21:17:52.0414 (UTC) FILETIME=[9EBBABE0:01C4A0E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, housley@vigilsec.com, tytso@mit.edu, Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable No, I somehow lost track of your fixes. I'm going to be doing one more draft for this and to get rid of Alice and Bob. Did I miss anything else? --Charlie -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Monday, September 20, 2004 6:36 AM To: Charlie Kaufman Cc: ipsec@ietf.org; tytso@mit.edu; housley@vigilsec.com; Barbara Fraser Subject: [Ipsec] Will ikev2-16 be the charm? Charlie Kaufman writes: > I have a revised I-D for IKEv2 ready to go unless someone tells me not > to submit it. The first two changes below motivated the revision. The > others respond to recent discussions on the list and some IESG comments > that I had misplaced. ... > 9) 3 minor editorial clarifications. Did those include fixing the section 3.15.1 table so that INTERNAL_IP?_SUBNETS are multivalued? Hmm... my mail (<16684.22799.893534.282240@fireball.kivinen.iki.fi>) included 4 changes, with first one changing text in 2 places. Which one of those were included? --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 00:37:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25326 for ; Thu, 23 Sep 2004 00:37:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CALHX-0003Ky-CW; Thu, 23 Sep 2004 00:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CALFB-00033A-UI for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 00:30:09 -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 AAA24931 for ; Thu, 23 Sep 2004 00:30:06 -0400 (EDT) Received: from mxout4.netvision.net.il ([194.90.9.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CALLr-0007N1-EA for ipsec@ietf.org; Thu, 23 Sep 2004 00:37:06 -0400 Received: from [217.132.135.116] by mxout4.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4H00G2O8HBEA@mxout4.netvision.net.il> for ipsec@ietf.org; Thu, 23 Sep 2004 06:29:35 +0200 (IST) Date: Thu, 23 Sep 2004 06:29:33 +0200 From: Yoav Nir Subject: Re: [Ipsec] Will ikev2-16 be the charm? In-reply-to: To: Charlie Kaufman Message-id: <2B4CFCB2-0D19-11D9-992E-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 1.2 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT In section 3.15.1, the Attribute Type is said to be 7 bits, although the diagram shows that it is 15 bits. On 23/09/2004, at 00:17, Charlie Kaufman wrote: > No, I somehow lost track of your fixes. I'm going to be doing one more > draft for this and to get rid of Alice and Bob. > > Did I miss anything else? > > --Charlie > > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, September 20, 2004 6:36 AM > To: Charlie Kaufman > Cc: ipsec@ietf.org; tytso@mit.edu; housley@vigilsec.com; Barbara Fraser > Subject: [Ipsec] Will ikev2-16 be the charm? > > Charlie Kaufman writes: >> I have a revised I-D for IKEv2 ready to go unless someone tells me not >> to submit it. The first two changes below motivated the revision. The >> others respond to recent discussions on the list and some IESG > comments >> that I had misplaced. > ... >> 9) 3 minor editorial clarifications. > > Did those include fixing the section 3.15.1 table so that > INTERNAL_IP?_SUBNETS are multivalued? > > Hmm... my mail (<16684.22799.893534.282240@fireball.kivinen.iki.fi>) > included 4 changes, with first one changing text in 2 places. Which > one of those were included? > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 11:51:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24802 for ; Thu, 23 Sep 2004 11:51:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVmW-0002ZE-1A; Thu, 23 Sep 2004 11:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVT0-0007iT-3S for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 11:25:06 -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 LAA22698 for ; Thu, 23 Sep 2004 11:25:03 -0400 (EDT) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVZn-0001z6-39 for ipsec@ietf.org; Thu, 23 Sep 2004 11:32:08 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i8NFOrVn013810; Thu, 23 Sep 2004 20:54:59 +0530 Message-ID: <4152EC97.8080501@netd.com> Date: Thu, 23 Sep 2004 21:02:39 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ipsec] Where will I get ipsec mailing list archive(mbox) to import to my netscape mail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I want to download the ipsec mail archive, is any one know any link to download it to my mail box. thx in advance mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 12:35:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28367 for ; Thu, 23 Sep 2004 12:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWGC-0001Iz-Kd; Thu, 23 Sep 2004 12:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAW4f-0006fm-Kb for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 12:04:01 -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 MAA25800 for ; Thu, 23 Sep 2004 12:03:58 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWBT-0002r7-67 for ipsec@ietf.org; Thu, 23 Sep 2004 12:11:04 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8NG11jf025824; Thu, 23 Sep 2004 12:01:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <20040922044222.GB15601@thunk.org> References: <20040922044222.GB15601@thunk.org> Date: Thu, 23 Sep 2004 12:03:41 -0400 To: "Theodore Ts'o" , Barbara Fraser From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IPsec WG , kseo@bbn.com, Russ Housley Subject: [Ipsec] 2401bis -- Last Call?? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted, Barb, Thank you for the kind words and patience. Given that IKEv2 has been approved as a Proposed Standard but is waiting on 2401bis, and that we've put in what were hopefully the remaining major changes, do you want to initiate Last Call for 2401bis? Karen >On Tue, Sep 21, 2004 at 05:36:42PM -0700, Paul Hoffman / VPNC wrote: >> At 5:29 PM -0400 9/21/04, The IESG wrote: >> >The IESG has approved the following document: >> > >> >- 'Internet Key Exchange (IKEv2) Protocol ' >> > as a Proposed Standard >> >> ... and there was signing and dancing in the streets! > >Many, many thanks to all those who contributed towards this milestone. >I'd especially like to call out Charlie Kaufman, as editor of the >IKEv2 document, and Tero Kevinen, who spent a lot of time combing >through the document looking for internal inconsistencies and >typographical errors, and Angelos Keromytis for managing the issue >tracker. > >We only have one more work item to complete, and that is RFC2401-bis. >Thanks to Karen and Steve, for making a new revision (the -03) of this >I-D available, and thanks in advance to all those who will review this >new draft and submit comments to the mailing list. (This might be >considered a hint, except that hints are subtle. :-) > >Russ has asked us to complete RFC2401-bis before Washington, D.C. IETF >meeting. With just a little bit more of a push, we can finish this >document as well! > > - Ted > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 12:42:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29823 for ; Thu, 23 Sep 2004 12:42:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWPU-00048k-Sv; Thu, 23 Sep 2004 12:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAW8o-0007Ub-KP for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 12:08: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 MAA26164 for ; Thu, 23 Sep 2004 12:08:15 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAWFZ-0002xi-Q9 for ipsec@ietf.org; Thu, 23 Sep 2004 12:15:21 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i8NG7fFl007334 for ; Thu, 23 Sep 2004 12:07:41 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i8NG7fsw007329; Thu, 23 Sep 2004 12:07:41 -0400 Received: from PKONING.equallogic.com ([172.16.1.105]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 12:07:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16722.62667.300000.37945@gargle.gargle.HOWL> Date: Thu, 23 Sep 2004 12:07:39 -0400 From: Paul Koning To: mcreddy@netd.com Subject: Re: [Ipsec] Where will I get ipsec mailing list archive(mbox) to import to my netscape mail References: <4152EC97.8080501@netd.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 23 Sep 2004 16:07:41.0177 (UTC) FILETIME=[73FC0690:01C4A187] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "M" == M Chenna kesava Reddy writes: M> Hi, I want to download the ipsec mail archive, is any one know any M> link to download it to my mail box. thx in advance mcreddy Try ftp://ftp.ietf.org/ietf-mail-archive/. For some reason the HTML "archives" that the IETF maintains are handled by a useless program that doesn't provide search or random access. Other organizations do better (GNU for example). The FTP server isn't documented anywhere, but it does give you a way to get to the raw mbox files. You may have to download a lot of individual files, since things are typically split up by month. (In some working group archives, some of it is split up into individual messages, hundreds of them.) "wget" is your friend for cases like that. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 13:00:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01251 for ; Thu, 23 Sep 2004 13:00:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWp9-0002P6-Pv; Thu, 23 Sep 2004 12:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWeM-0008Gn-8Z for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 12:40:54 -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 MAA29531 for ; Thu, 23 Sep 2004 12:40:51 -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 1CAWl0-00040j-Qh for ipsec@ietf.org; Thu, 23 Sep 2004 12:47:57 -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 i8NGZud08970 for ; Thu, 23 Sep 2004 12:35:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8NG4mst017459 for ; Thu, 23 Sep 2004 12:04:48 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxja4fI; Thu, 23 Sep 04 12:04:45 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i8NG7fFn007334 for ; Thu, 23 Sep 2004 12:07:43 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i8NG7fsw007329; Thu, 23 Sep 2004 12:07:41 -0400 Received: from PKONING.equallogic.com ([172.16.1.105]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 12:07:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16722.62667.300000.37945@gargle.gargle.HOWL> Date: Thu, 23 Sep 2004 12:07:39 -0400 From: Paul Koning To: mcreddy@netd.com Subject: Re: [Ipsec] Where will I get ipsec mailing list archive(mbox) to import to my netscape mail References: <4152EC97.8080501@netd.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 23 Sep 2004 16:07:41.0177 (UTC) FILETIME=[73FC0690:01C4A187] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "M" == M Chenna kesava Reddy writes: M> Hi, I want to download the ipsec mail archive, is any one know any M> link to download it to my mail box. thx in advance mcreddy Try ftp://ftp.ietf.org/ietf-mail-archive/. For some reason the HTML "archives" that the IETF maintains are handled by a useless program that doesn't provide search or random access. Other organizations do better (GNU for example). The FTP server isn't documented anywhere, but it does give you a way to get to the raw mbox files. You may have to download a lot of individual files, since things are typically split up by month. (In some working group archives, some of it is split up into individual messages, hundreds of them.) "wget" is your friend for cases like that. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 13:45:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04094 for ; Thu, 23 Sep 2004 13:45:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXZQ-0002tQ-MA; Thu, 23 Sep 2004 13:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXQS-0001UP-Mj for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 13:30:36 -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 NAA03250 for ; Thu, 23 Sep 2004 13:30:33 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXXH-0005Bn-RW for ipsec@ietf.org; Thu, 23 Sep 2004 13:37:40 -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 i8NHPnd10854 for ; Thu, 23 Sep 2004 13:25:49 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8NGnDwl023698 for ; Thu, 23 Sep 2004 12:49:13 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZWaGrU; Thu, 23 Sep 04 12:49:10 -0400 Date: Thu, 23 Sep 2004 11:52:32 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------qcjstjwyjfdukuapjlum" X-Spam-Score: 2.7 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------qcjstjwyjfdukuapjlum Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


:)

----------qcjstjwyjfdukuapjlum Content-Type: image/bmp; name="jvbnjzspor.bmp" Content-Disposition: attachment; filename="jvbnjzspor.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk32BwAAAAAAADYAAAAoAAAAPgAAABAAAAABABAAAAAAAMAHAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr12v/f/9//3//fyArICvXa/9//3//f/9/ ICsgK9dr/3//f7NfICsgK49T/3//f/9/12uPUyArICuzX/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/j1MgK9dr/3//f/9/ /3+PUyAr12v/f/9//3//f49TICvXa/9//38gKyAr12sgK49T/3//f49TICvXa7NfICuzX/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICsgKyArICsgK49T/3//f/9/s18gK7Nf/38gKyArICsgKyArICuPU/9//3//f/9/j1MgK9dr /3//f/9//3/XayArICv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3+PUyAr12uzXyArj1P/f/9//3//f7NfICuPU/9/j1MgK9drs18gK49T /3//f9drj1MgK49TICuPU/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/12sgKyAr12sgK49T/3//f/9//3/XayAr j1P/f9drICsgK9drICuPU/9//3+PUyAr12uzXyArICv/f/9//3//f7NfICuzX/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/12sgK7Nf ICsgK/9//3//f/9//38gKyAr/3//f9drICuzXyArICv/f/9/ICsgK/9/12sgKyAr/3//f/9/ j1MgK49T12v/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/s18gKyArICvXa/9//3/Xa/9/ICsgK9dr/3//f7NfICsgKyAr12v/fyAr ICv/f/9/ICsgK/9//3//f/9/s18gK49T/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/j1MgKyArs1//f/9/ICsgKyArICvXa/9/ /3//f49TICsgK7Nf/3+PUyAr12v/fyArICv/f/9//3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f9drICsgK7Nf /3//f9drs18gKyArs1//f/9//3/XayArICuzX/9/12sgK7Nf12sgK49T/3//f49TICvXayAr j1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f7NfICuPU/9//3//f/9//3+PU49T/3//f/9//3+zXyArj1P/f/9/s18gKyAr j1P/f/9//3/Xa49TICsgK9dr/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fw== ----------qcjstjwyjfdukuapjlum Content-Type: text/html; name="Garry.zip.htm" Content-Disposition: attachment; filename="Garry.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Garry.zip
Virus name: W32/Bagle@MM!pwdzip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------qcjstjwyjfdukuapjlum Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------qcjstjwyjfdukuapjlum-- From ipsec-bounces@ietf.org Thu Sep 23 14:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06122 for ; Thu, 23 Sep 2004 14:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXr4-0005wU-Tx; Thu, 23 Sep 2004 13:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXmF-000557-Il for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 13:53:07 -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 NAA04778 for ; Thu, 23 Sep 2004 13:53:05 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXt4-0005fE-Rk for ipsec@ietf.org; Thu, 23 Sep 2004 14:00:11 -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 i8NHmKd15654 for ; Thu, 23 Sep 2004 13:48:20 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8NFME7q012156 for ; Thu, 23 Sep 2004 11:22:14 -0400 (EDT) Received: from dsl084.203.95.61.touchtelindia.net(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXuaGUx; Thu, 23 Sep 04 11:22:10 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i8NFOrVn013810; Thu, 23 Sep 2004 20:54:59 +0530 Message-ID: <4152EC97.8080501@netd.com> Date: Thu, 23 Sep 2004 21:02:39 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ipsec] Where will I get ipsec mailing list archive(mbox) to import to my netscape mail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I want to download the ipsec mail archive, is any one know any link to download it to my mail box. thx in advance mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 14:49:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09538 for ; Thu, 23 Sep 2004 14:49:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYVD-0008Hl-Ig; Thu, 23 Sep 2004 14:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYIc-0005Bc-N7; Thu, 23 Sep 2004 14:26:34 -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 OAA07763; Thu, 23 Sep 2004 14:26:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYPS-0006P7-Lz; Thu, 23 Sep 2004 14:33:38 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CAYGw-0004eB-Qx; Thu, 23 Sep 2004 14:24:50 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 23 Sep 2004 14:24:50 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'Cryptographic Algorithms for use in the Internet Key Exchange Version 2' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following documents: - 'Cryptographic Algorithms for use in the Internet Key Exchange Version 2 ' as a Proposed Standard - 'Cryptographic Suites for IPsec ' as a Proposed Standard These documents are products of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary The IPSec series of protocols makes use of various cryptographic algorithms to provide security services. The Internet Key Exchange (both IKEv1 and IKEv2) provide a mechanism to negotiate which algorithms should be used for a particular association. However to ensure interoperability between disparate implementations, this document specifies a set of mandatory to implement algorithms, thereby ensuring that there will be at least one algorithm that all implementations will have available. This document also specifies algorithms that should be implemented because they made be promoted to mandatory at some future time. Working Group Summary The IPsec Working Group came to rough consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. RFC Editor Note Please change "MUST" to "MUST-" in the last paragraph of section 4.1.1 to make it consistent with section 4.1.3. OLD For confidentiality, implementations MUST implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be implemented. NEW For confidentiality, implementations MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be implemented. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 16:29:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20360 for ; Thu, 23 Sep 2004 16:29:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAa6M-0001jo-RO; Thu, 23 Sep 2004 16:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZwH-0004QB-J1 for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 16:11:37 -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 QAA17874 for ; Thu, 23 Sep 2004 16:11:35 -0400 (EDT) Received: from mxout2.netvision.net.il ([194.90.9.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAa37-0000Vz-Az for ipsec@ietf.org; Thu, 23 Sep 2004 16:18:43 -0400 Received: from [217.132.152.212] by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4I00IPDG2F26@mxout2.netvision.net.il> for ipsec@ietf.org; Thu, 23 Sep 2004 22:11:04 +0200 (IST) Date: Thu, 23 Sep 2004 22:11:03 +0200 From: Yoav Nir Subject: Re: [Ipsec] Where will I get ipsec mailing list archive(mbox) to import to my netscape mail In-reply-to: <4152EC97.8080501@netd.com> To: mcreddy@netd.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4152EC97.8080501@netd.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT Try here: http://www.vpnc.org/ietf-ipsec/ On 23/09/2004, at 18:32, M.Chenna kesava Reddy wrote: > Hi, > I want to download the ipsec mail archive, is any one know any link to > download it to my mail box. > thx in advance > mcreddy > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 23 22:32:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14240 for ; Thu, 23 Sep 2004 22:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfqE-0006nU-DL; Thu, 23 Sep 2004 22:29:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAflU-0006I1-6d for ipsec@megatron.ietf.org; Thu, 23 Sep 2004 22:24:52 -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 WAA13902 for ; Thu, 23 Sep 2004 22:24:49 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfsM-0007XP-VD for ipsec@ietf.org; Thu, 23 Sep 2004 22:32:00 -0400 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8O2OcdL021841 for ; Fri, 24 Sep 2004 07:54:38 +0530 Message-Id: <5.1.0.14.0.20040924074124.024f69e0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Sep 2004 07:56:01 +0530 To: ipsec@ietf.org From: Jyothi In-Reply-To: <2B4CFCB2-0D19-11D9-992E-000393AD410A@netvision.net.il> References: Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.8 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Ipsec] Traffic selectors selection using IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113411818==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0113411818== Content-Type: multipart/alternative; boundary="=====================_2068494844==_.ALT" --=====================_2068494844==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, I have some issues in selection of traffic selectors in IKEv2. Initially, SG1 and SG2 have the same SPD configuration. After that SG2 administrator modified the SPD policy but SG1 SPD policy is not modified. H1 -------SG1 ---- Internet ------ SG2-----H2 SG1 SPD policy: Protocol: ALL Src 1: 1.1.1.10 - 1.1.1.200 Src 2: 2.2.2.20 - 2.2.2.40 Dst 1: 10.10.10.10 - 10.10.10.20 Dst 2: 20.20.20.20 - 20.20.20.200 SG2 SPD policy: Protocol: ALL Src 1: 20.20.20.50 - 20.20.20.100 Src 2: 10.10.10.5 - 10.10.10.15 Dst 1: 1.1.1.10 - 1.1.1.30 Dst 2: 2.2.2.10 - 2.2.2.30 H1 IP address is : 1.1.1.15 H2 IP address is : 20.20.20.65 Traffic initiated from H1 to H2 (UDP traffic with port 6666 to destination port 6767) There are three cases: 1) No PFP is set SG1 started negotiating IKEv2 with following traffic selectors: TS Src1: 1.1.1.15 protocol UDP port 6666 (pkt selectors may be sent or may not be (renewal case)). Src2: 1.1.1.10 - 1.1.1.200 Src3: 2.2.2.20 - 2.2.2.40 TS Dst1: 20.20.20.65 protocol UDP port 6767 Dst2: 10.10.10.10 - 10.10.10.20 Dst3: 20.20.20.20 - 20.20.20.200 What SG2 should select?? Because it has some matching selectors?? Can SG2 select the following selectors and send it to SG1: a) TS Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the received selectors and SPD policy has the same set) Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the received selectors adn SPD policy has a set more than that subset) TS Dst1: 20.20.20.50 - 20.20.20.200 (is a subset of the received selectors and SPD policy has the same set) Dst2: 10.10.10.10 - 10.10.10.15(is a subset of the received selectors and SPD policy has the same set) protocol is ALL If IPSEC SA are created with the above set, there will be overhead. Searching is happening twice. Can I store multiple sets of selectors in SA?? I think I am missing some thing. Please correct me. OR b) Can I just select the packet selectors and protocol ALL (since the SPD policy has protocol ALL configuration). 2) PFP is selected for protocol and IP addresses in SG1, but not in SG2. Then in this case what SG1 should propose?? Is it pkt selectors and SPD selectors with a particular protocol?? 3) PFP is not selected in SG1, but in SG2. In this case what selectors SG2 should select?? If SG2 selects the matching subset, same SA will be used even if PFP is selected. Thanks Jyothi --=====================_2068494844==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,

I have some issues in selection of traffic selectors in IKEv2.

Initially, SG1 and SG2 have the same SPD configuration.
 After that SG2 administrator modified the SPD policy but SG1 SPD policy is not modified.


          H1 -------SG1 ---- Internet ------ SG2-----H2

SG1 SPD policy:
     Protocol: ALL

     Src 1:  1.1.1.10 - 1.1.1.200
     Src 2:  2.2.2.20 - 2.2.2.40

     Dst 1:  10.10.10.10 - 10.10.10.20
     Dst 2:  20.20.20.20 - 20.20.20.200

SG2 SPD policy:
     Protocol: ALL

     Src 1:  20.20.20.50 - 20.20.20.100
     Src 2:  10.10.10.5 - 10.10.10.15

     Dst 1:  1.1.1.10 - 1.1.1.30
     Dst 2:  2.2.2.10 - 2.2.2.30

H1 IP address is : 1.1.1.15   H2 IP address is : 20.20.20.65


Traffic initiated from H1 to H2 (UDP traffic with port 6666 to destination port 6767)
There are three cases:
1) No PFP is set

    SG1 started negotiating IKEv2 with following traffic selectors:

        TS Src1:  1.1.1.15 protocol UDP port 6666 (pkt selectors may be sent or may not be (renewal case)).
           Src2:  1.1.1.10 - 1.1.1.200
           Src3:  2.2.2.20 - 2.2.2.40

        TS Dst1:  20.20.20.65 protocol UDP port 6767
           Dst2:  10.10.10.10 - 10.10.10.20
           Dst3:  20.20.20.20 - 20.20.20.200

    What SG2 should select?? Because it has some matching selectors??

Can SG2 select the following selectors and send it to SG1:

a)
        TS Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the received selectors
                                       and SPD policy has the same set)
           Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the received selectors
                                      adn SPD policy has a set more than that subset)

        TS Dst1: 20.20.20.50 - 20.20.20.200 (is a subset of the received selectors
                                               and SPD policy has the same set)
           Dst2: 10.10.10.10 - 10.10.10.15(is a subset of the received selectors
                                               and SPD policy has the same set)
   protocol is ALL

If IPSEC SA are created with the above set, there will be overhead.
Searching is happening twice.
Can I store multiple sets of selectors in SA??

I think I am missing some thing. Please correct me.

                        OR
b) Can I just select the packet selectors and protocol ALL (since the SPD policy has
         protocol ALL configuration).


2) PFP is selected for protocol and IP addresses in SG1, but not in SG2.

Then in this case what SG1 should propose??

Is it pkt selectors and SPD selectors with a particular protocol??


3) PFP is not selected in SG1, but in SG2.

In this case what selectors SG2 should select??

If SG2 selects the matching subset, same SA will be used even if PFP is selected.

Thanks
Jyothi --=====================_2068494844==_.ALT-- --===============0113411818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0113411818==-- From ipsec-bounces@ietf.org Fri Sep 24 04:24:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19329 for ; Fri, 24 Sep 2004 04:24:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAlLm-0004w2-J4; Fri, 24 Sep 2004 04:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAlHF-0004GZ-R1 for ipsec@megatron.ietf.org; Fri, 24 Sep 2004 04:18:04 -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 EAA18872 for ; Fri, 24 Sep 2004 04:18:00 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAlOC-0004hh-C6 for ipsec@ietf.org; Fri, 24 Sep 2004 04:25:13 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i8O8HvjZ017607 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Sep 2004 11:17:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i8O8HuHv017604; Fri, 24 Sep 2004 11:17:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16723.55348.673843.98064@fireball.kivinen.iki.fi> Date: Fri, 24 Sep 2004 11:17:56 +0300 From: Tero Kivinen To: Jyothi Subject: [Ipsec] Traffic selectors selection using IKEv2 In-Reply-To: <5.1.0.14.0.20040924074124.024f69e0@172.16.1.10> References: <5.1.0.14.0.20040924074124.024f69e0@172.16.1.10> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Jyothi writes: > SG1 SPD policy: > Protocol: ALL > Src 1: 1.1.1.10 - 1.1.1.200 > Src 2: 2.2.2.20 - 2.2.2.40 > Dst 1: 10.10.10.10 - 10.10.10.20 > Dst 2: 20.20.20.20 - 20.20.20.200 > > SG2 SPD policy: > Protocol: ALL > Src 1: 20.20.20.50 - 20.20.20.100 > Src 2: 10.10.10.5 - 10.10.10.15 > Dst 1: 1.1.1.10 - 1.1.1.30 > Dst 2: 2.2.2.10 - 2.2.2.30 > > H1 IP address is : 1.1.1.15 H2 IP address is : 20.20.20.65 > > 1) No PFP is set > SG1 started negotiating IKEv2 with following traffic selectors: > TS Src1: 1.1.1.15 protocol UDP port 6666 (pkt selectors may be > Src2: 1.1.1.10 - 1.1.1.200 > Src3: 2.2.2.20 - 2.2.2.40 > TS Dst1: 20.20.20.65 protocol UDP port 6767 > Dst2: 10.10.10.10 - 10.10.10.20 > Dst3: 20.20.20.20 - 20.20.20.200 > a) > TS Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the received selectors > Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the received selectors > TS Dst1: 20.20.20.50 - 20.20.20.200 (is a subset of the received > Dst2: 10.10.10.10 - 10.10.10.15(is a subset of the received > protocol is ALL Yes, it can select that. > If IPSEC SA are created with the above set, there will be overhead. > Searching is happening twice. > Can I store multiple sets of selectors in SA?? Yes. > b) Can I just select the packet selectors and protocol ALL (since the SPD > policy has > protocol ALL configuration). Yes protocol can be ALL if you like, as initiator offered it, and responder allows that in the policy. > 2) PFP is selected for protocol and IP addresses in SG1, but not in SG2. > Then in this case what SG1 should propose?? SG1 will then propose TS Src1: 1.1.1.15 protocol UDP Dst1: 20.20.20.65 protocol UDP And the responder must return that same TS, as there is nothing it can limit the TS. > 3) PFP is not selected in SG1, but in SG2. > In this case what selectors SG2 should select?? SG1 will offer same thing as in 1), and the SG2 will select the same thing that SG1 selected in the 2), i.e. the first TS entry, which is the one matching the packet. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 24 12:42:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24067 for ; Fri, 24 Sep 2004 12:42:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsr5-0007ly-NA; Fri, 24 Sep 2004 12:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAshW-0005DP-RF for ipsec@megatron.ietf.org; Fri, 24 Sep 2004 12:13:38 -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 MAA21109 for ; Fri, 24 Sep 2004 12:13:35 -0400 (EDT) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsoX-0004dO-KH for ipsec@ietf.org; Fri, 24 Sep 2004 12:20:54 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i8OGD4DV008671 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 24 Sep 2004 11:13:06 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i8OGC1WF008264; Fri, 24 Sep 2004 16:12:01 GMT Message-Id: <200409241612.i8OGC1WF008264@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Fri, 24 Sep 2004 16:12:01 +0000 From: "William Dixon" To: "'Tero Kivinen'" , "'Jyothi'" Subject: RE: [Ipsec] Traffic selectors selection using IKEv2 Date: Fri, 24 Sep 2004 09:10:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16723.55348.673843.98064@fireball.kivinen.iki.fi> X-Lux-Comment: LuxSci remailer message ID code - 1096042321-5086582.29768632 X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit This is just the tip of the iceberg. We need a place to document selector negotiation in order to achieve reliable interop. A BCP draft seems reasonable, unless we are worried about people not implementing some parts of the negotiation and we want to mandate it as MUST for interop. Thoughts Tero ? > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Tero Kivinen > Sent: Friday, September 24, 2004 1:18 AM > To: Jyothi > Cc: ipsec@ietf.org > Subject: [Ipsec] Traffic selectors selection using IKEv2 > > Jyothi writes: > > SG1 SPD policy: > > Protocol: ALL > > Src 1: 1.1.1.10 - 1.1.1.200 > > Src 2: 2.2.2.20 - 2.2.2.40 > > Dst 1: 10.10.10.10 - 10.10.10.20 > > Dst 2: 20.20.20.20 - 20.20.20.200 > > > > SG2 SPD policy: > > Protocol: ALL > > Src 1: 20.20.20.50 - 20.20.20.100 > > Src 2: 10.10.10.5 - 10.10.10.15 > > Dst 1: 1.1.1.10 - 1.1.1.30 > > Dst 2: 2.2.2.10 - 2.2.2.30 > > > > H1 IP address is : 1.1.1.15 H2 IP address is : 20.20.20.65 > > > > 1) No PFP is set > > SG1 started negotiating IKEv2 with following traffic selectors: > > TS Src1: 1.1.1.15 protocol UDP port 6666 (pkt > selectors may be > > Src2: 1.1.1.10 - 1.1.1.200 > > Src3: 2.2.2.20 - 2.2.2.40 > > TS Dst1: 20.20.20.65 protocol UDP port 6767 > > Dst2: 10.10.10.10 - 10.10.10.20 > > Dst3: 20.20.20.20 - 20.20.20.200 > > a) > > TS Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the > received selectors > > Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the > received selectors > > TS Dst1: 20.20.20.50 - 20.20.20.200 (is a subset > of the received > > Dst2: 10.10.10.10 - 10.10.10.15(is a subset of > the received > > protocol is ALL > > Yes, it can select that. > > > If IPSEC SA are created with the above set, there will be overhead. > > Searching is happening twice. > > Can I store multiple sets of selectors in SA?? > > Yes. > > > b) Can I just select the packet selectors and protocol ALL > (since the > > SPD policy has > > protocol ALL configuration). > > Yes protocol can be ALL if you like, as initiator offered it, > and responder allows that in the policy. > > > 2) PFP is selected for protocol and IP addresses in SG1, > but not in SG2. > > Then in this case what SG1 should propose?? > > SG1 will then propose > > TS Src1: 1.1.1.15 protocol UDP > Dst1: 20.20.20.65 protocol UDP > > And the responder must return that same TS, as there is > nothing it can limit the TS. > > > 3) PFP is not selected in SG1, but in SG2. > > In this case what selectors SG2 should select?? > > SG1 will offer same thing as in 1), and the SG2 will select > the same thing that SG1 selected in the 2), i.e. the first TS > entry, which is the one matching the packet. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 25 22:30:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00795 for ; Sat, 25 Sep 2004 22:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBOhk-0006vG-CM; Sat, 25 Sep 2004 22:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9hlE-0003Mw-2J for ipsec@megatron.ietf.org; Tue, 21 Sep 2004 06:20:36 -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 GAA00653 for ; Tue, 21 Sep 2004 06:20:33 -0400 (EDT) Received: from web8508.mail.in.yahoo.com ([202.43.219.170]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9hrZ-0007ph-0K for ipsec@ietf.org; Tue, 21 Sep 2004 06:27:10 -0400 Message-ID: <20040921102000.14521.qmail@web8508.mail.in.yahoo.com> Received: from [203.200.200.162] by web8508.mail.in.yahoo.com via HTTP; Tue, 21 Sep 2004 11:20:00 BST Date: Tue, 21 Sep 2004 11:20:00 +0100 (BST) From: rajavel samy To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 25 Sep 2004 22:23:59 -0400 Subject: [Ipsec] Create_child_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi, I like to get clarified regarding the first child SA creation and CREATE_CHILD_SA. 1. Is it possible to create bidirectional SAs (example tunneling all inbound and outbound traffice between initiator and responder)within the phase I of IKEv2 procedure. 2. Also is it possible to create bidirectional SAs with a single exchange of CREATE_CHILD_SA messages. Thanks Rajvel. ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 25 22:32:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00941 for ; Sat, 25 Sep 2004 22:32:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBOhl-0006vM-4P; Sat, 25 Sep 2004 22:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAxiz-0004uw-V6 for ipsec@megatron.ietf.org; Fri, 24 Sep 2004 17:35:29 -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 RAA22813 for ; Fri, 24 Sep 2004 17:35:27 -0400 (EDT) From: Madhvi.Verma@utstar.com Received: from ns3.utstar.com ([216.37.120.25] helo=rm-mail1.utstar.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxq4-0005Tv-GR for ipsec@ietf.org; Fri, 24 Sep 2004 17:42:48 -0400 Received: from gypsum.mw.3com.com (gypsum.utstar.com [216.37.120.52] (may be forged)) by rm-mail1.utstar.com (8.12.11/8.12.11) with ESMTP id i8OLWdxr001020 for ; Fri, 24 Sep 2004 16:32:40 -0500 (CDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i8OLYot5008051 for ; Fri, 24 Sep 2004 16:34:50 -0500 (CDT) To: ipsec@ietf.org Date: Fri, 24 Sep 2004 16:34:49 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 09/24/2004 04:34:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Sat, 25 Sep 2004 22:23:59 -0400 Subject: [Ipsec] IKE query X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, Section 9 of RFC 2409 (IKE), provides implementation hints . I have a query related to the following excerpt from the same section: An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. My question is : can those multiple SAs be used simultaneously to achieve load balancing , or do they have to be used one after the other. Thank you, Madhvi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 25 23:12:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02675 for ; Sat, 25 Sep 2004 23:12:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBPOM-0004ZW-OJ; Sat, 25 Sep 2004 23:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBPGR-0003fY-LZ for ipsec@megatron.ietf.org; Sat, 25 Sep 2004 22:59:51 -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 WAA01856 for ; Sat, 25 Sep 2004 22:59:48 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBPNl-0005q1-Vh for ipsec@ietf.org; Sat, 25 Sep 2004 23:07:26 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 25 Sep 2004 19:59:56 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Sep 2004 19:59:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Create_child_SA Date: Sat, 25 Sep 2004 19:59:15 -0700 Message-ID: Thread-Topic: [Ipsec] Create_child_SA Thread-Index: AcSjcOGU6185wdU3TsufaBbyBEW1hwAApl0A From: "Charlie Kaufman" To: "rajavel samy" , X-OriginalArrivalTime: 26 Sep 2004 02:59:19.0473 (UTC) FILETIME=[D1360A10:01C4A374] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable The terminology is a little confusing, but IKEv2 does what you want. ESP and AH SAs are never bidirectional. IKE SAs are always bidirectional. Because in the 99.9999% case, people want data to flow in both directions, IKEv2 always creates ESP and AH SAs in pairs - one in each direction and both have the same traffic selectors. It also requires that they be deleted together. So phase I of IKEv2 always negotiates three SAs - a bidirectional IKE SA and a pair of SAs for data. (Note: IKEv2 also no longer uses the phase I / phase II terminology, but I know what you mean). In practice, this is also how IKEv1 is always used, but the protocol allows the flexibility to do otherwise. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of rajavel samy Sent: Tuesday, September 21, 2004 3:20 AM To: ipsec@ietf.org Subject: [Ipsec] Create_child_SA Hi, I like to get clarified regarding the first child SA creation and CREATE_CHILD_SA.=20 1. Is it possible to create bidirectional SAs (example tunneling all inbound and outbound traffice between initiator and responder)within the phase I of IKEv2 procedure. 2. Also is it possible to create bidirectional SAs with a single exchange of CREATE_CHILD_SA messages. Thanks=20 Rajvel. ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 26 01:05:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06338 for ; Sun, 26 Sep 2004 01:05:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBRAv-0006me-DJ; Sun, 26 Sep 2004 01:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBR7F-0006Ey-WB for ipsec@megatron.ietf.org; Sun, 26 Sep 2004 00:58:30 -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 AAA06180 for ; Sun, 26 Sep 2004 00:58:26 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBREa-0007SA-IO for ipsec@ietf.org; Sun, 26 Sep 2004 01:06:05 -0400 Received: by mproxy.gmail.com with SMTP id 78so8270861rnl for ; Sat, 25 Sep 2004 21:58:28 -0700 (PDT) Received: by 10.38.79.43 with SMTP id c43mr577367rnb; Sat, 25 Sep 2004 21:58:28 -0700 (PDT) Received: by 10.38.164.13 with HTTP; Sat, 25 Sep 2004 21:58:28 -0700 (PDT) Message-ID: Date: Sun, 26 Sep 2004 12:58:28 +0800 From: "Luo, Guojie" To: ipsec@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Subject: [Ipsec] need to get familiar with IPsec quickly X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Luo, Guojie" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit can anybody show me one article best describe IPsec, and one article best describe the implement framework? thanks~~ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 26 04:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29235 for ; Sun, 26 Sep 2004 04:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBUJQ-0001hb-9p; Sun, 26 Sep 2004 04:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBUEK-0008Ft-Iu for ipsec@megatron.ietf.org; Sun, 26 Sep 2004 04:18:01 -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 EAA28947 for ; Sun, 26 Sep 2004 04:17:58 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBULe-00060x-5l for ipsec@ietf.org; Sun, 26 Sep 2004 04:25:37 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8Q8HKN21720; Sun, 26 Sep 2004 10:17:20 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8Q8HHSj076268; Sun, 26 Sep 2004 10:17:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409260817.i8Q8HHSj076268@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Madhvi.Verma@utstar.com Subject: Re: [Ipsec] IKE query In-reply-to: Your message of Fri, 24 Sep 2004 16:34:49 CDT. Date: Sun, 26 Sep 2004 10:17:17 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: My question is : can those multiple SAs be used simultaneously to achieve load balancing , or do they have to be used one after the other. => I believe this is as you'd like but please note the load will be balanced only with some kind of handware support (parallel crypto accelerators). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 26 22:21:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13645 for ; Sun, 26 Sep 2004 22:21:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBl26-0003CM-4q; Sun, 26 Sep 2004 22:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBkzh-00030F-2G for ipsec@megatron.ietf.org; Sun, 26 Sep 2004 22:12:01 -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 WAA13435 for ; Sun, 26 Sep 2004 22:11:59 -0400 (EDT) From: ekr@rtfm.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBl7D-0003pj-Ql for ipsec@ietf.org; Sun, 26 Sep 2004 22:19:48 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8R273d09645 for ; Sun, 26 Sep 2004 22:07:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8R28sEe005410 for ; Sun, 26 Sep 2004 22:08:54 -0400 (EDT) Message-Id: <200409270208.i8R28sEe005410@nutshell.tislabs.com> Received: from unknown(221.10.5.194) by nutshell.tislabs.com via csmap (V6.0) id srcAAAGOaODk; Sun, 26 Sep 04 22:08:39 -0400 To: ipsec@lists.tislabs.com Date: Mon, 27 Sep 2004 10:22:43 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_0204C8D6.C940AC67" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 4.1 (++++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0013_0204C8D6.C940AC67 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0013_0204C8D6.C940AC67 Content-Type: text/html; name="body.zip.htm" Content-Disposition: attachment; filename="body.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: body.zip
Virus name: W32/Lovgate.x@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0013_0204C8D6.C940AC67 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0013_0204C8D6.C940AC67-- From ipsec-bounces@ietf.org Mon Sep 27 01:21:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20363 for ; Mon, 27 Sep 2004 01:21:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBnuT-00054d-Ib; Mon, 27 Sep 2004 01:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBnpW-0004rs-B1 for ipsec@megatron.ietf.org; Mon, 27 Sep 2004 01:13:42 -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 BAA20116 for ; Mon, 27 Sep 2004 01:13:41 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.192] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBnx3-0006PH-VL for Ipsec@ietf.org; Mon, 27 Sep 2004 01:21:31 -0400 Received: by mproxy.gmail.com with SMTP id 79so3149211rnk for ; Sun, 26 Sep 2004 22:13:39 -0700 (PDT) Received: by 10.38.163.10 with SMTP id l10mr396716rne; Sun, 26 Sep 2004 22:13:39 -0700 (PDT) Received: by 10.38.164.13 with HTTP; Sun, 26 Sep 2004 22:13:39 -0700 (PDT) Message-ID: Date: Mon, 27 Sep 2004 13:13:39 +0800 From: "Luo, Guojie" To: Thomas Gal , Ipsec@ietf.org Subject: Re: [Ipsec] need to get familiar with IPsec quickly In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02596E02@svr-exc.domain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02596E02@svr-exc.domain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Luo, Guojie" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Is the spec called RFC 2406? On Sun, 26 Sep 2004 14:31:56 -0700, Thomas Gal wrote: > I would say read the whole spec 3 times. > > -T > > > -----Original Message----- > > From: Luo, Guojie [mailto:luoguojie@gmail.com] > > Sent: Saturday, September 25, 2004 9:58 PM > > To: ipsec@ietf.org > > Subject: [Ipsec] need to get familiar with IPsec quickly > > > > can anybody show me one article best describe IPsec, and one > > article best describe the implement framework? thanks~~ > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 27 03:43:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09434 for ; Mon, 27 Sep 2004 03:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBq6r-0005Z5-89; Mon, 27 Sep 2004 03:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBq4p-0005Tj-Lz for ipsec@megatron.ietf.org; Mon, 27 Sep 2004 03:37:39 -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 DAA09245 for ; Mon, 27 Sep 2004 03:37:37 -0400 (EDT) Message-Id: <200409270737.DAA09245@ietf.org> Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBqCO-0008C2-IY for Ipsec@ietf.org; Mon, 27 Sep 2004 03:45:29 -0400 Received: (qmail 16729 invoked by uid 65534); 27 Sep 2004 07:37:02 -0000 Received: from 52.141.77.83.cust.bluewin.ch (EHLO VAIO) (83.77.141.52) by mail.gmx.net (mp010) with SMTP; 27 Sep 2004 09:37:02 +0200 X-Authenticated: #2483435 From: "Christian Scheurer" To: "Luo, Guojie" Subject: Re: [Ipsec] need to get familiar with IPsec quickly X-mailer: Foxmail 4.2 [eg] Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 27 Sep 2004 9:36:43 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 8bit Cc: "Ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CS-AntiSpam@gmx.net List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Hello, you may check this if you are interested in a simple IPsec implementation for embedded systems: http://lists.gnu.org/archive/html/lwip-users/2004-06/msg00098.html http://www.embeddedipsec.org Read the documentation there to see how we got started with IPsec. Greetings, Christian >Sender name: Luo, Guojie >Sender address: luoguojie@gmail.com >Message subject: [Ipsec] need to get familiar with IPsec quickly >Message time: 2004-09-26, 12:58:00 > >can anybody show me one article best describe IPsec, and one article >best describe the implement framework? thanks~~ > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec ===================================================================== http://www.ChristianScheurer.ch ===================================================================== _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 27 10:24:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02644 for ; Mon, 27 Sep 2004 10:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwKx-0002dd-Pd; Mon, 27 Sep 2004 10:18:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwGE-0001TK-2U for ipsec@megatron.ietf.org; Mon, 27 Sep 2004 10:13:50 -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 KAA01357 for ; Mon, 27 Sep 2004 10:13:47 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwNr-0006jI-9J for ipsec@ietf.org; Mon, 27 Sep 2004 10:21:43 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8REDCjh021382; Mon, 27 Sep 2004 10:13:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 27 Sep 2004 09:45:45 -0400 To: Madhvi.Verma@utstar.com From: Stephen Kent Subject: Re: [Ipsec] IKE query Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:34 PM -0500 9/24/04, Madhvi.Verma@utstar.com wrote: >Hello, > >Section 9 of RFC 2409 (IKE), provides implementation hints . I have >a query related >to the following excerpt from the same section: > > An implementation may wish to negotiate a range of SAs when > performing Quick Mode. By doing this they can speed up the "re- > keying". Quick Mode defines how KEYMAT is defined for a range of SAs. > When one peer feels it is time to change SAs they simply use the next > one within the stated range. A range of SAs can be established by > negotiating multiple SAs (identical attributes, different SPIs) with > one Quick Mode. > > My question is : can those multiple SAs be used simultaneously to achieve >load balancing , or do they have to be used one after the other. > >Thank you, >Madhvi In the new version of 2401 we make explicit provision for multiple SAs that might be used for various QoS purposes. It is not clear that implementations conforming to the original 2401 spec will always be able to do this. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 27 18:38:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16780 for ; Mon, 27 Sep 2004 18:38:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC43F-0002A7-Dt; Mon, 27 Sep 2004 18:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC3wg-0001Um-O4; Mon, 27 Sep 2004 18:26:10 -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 SAA16271; Mon, 27 Sep 2004 18:26:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC44O-0002DW-O8; Mon, 27 Sep 2004 18:34:08 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CC3tB-00015z-Q2; Mon, 27 Sep 2004 18:22:33 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 27 Sep 2004 18:22:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipsec@ietf.org Subject: [Ipsec] Last Call: 'The Use of Galois/Counter Mode (GCM) in IPsec ESP' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from the document authors to consider the following document: - 'The Use of Galois/Counter Mode (GCM) in IPsec ESP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 05:30:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08512 for ; Tue, 28 Sep 2004 05:30:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCEBv-0001G2-Fa; Tue, 28 Sep 2004 05:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCEA0-0000wZ-Rc for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 05:20:36 -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 FAA08008 for ; Tue, 28 Sep 2004 05:20:34 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCEHn-0005EN-UB for ipsec@ietf.org; Tue, 28 Sep 2004 05:28:40 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1CCE9v-00055l-00 for ; Tue, 28 Sep 2004 11:20:31 +0200 Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72voelker) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) for id 1CCE9u-0000m0-00; Tue, 28 Sep 2004 11:20:30 +0200 From: =?iso-8859-1?Q?Lars_V=F6lker?= To: Date: Tue, 28 Sep 2004 11:20:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSlOsh/iFs7zYcuRCaA775R/SlcZg== Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] 2401bis-v03 fig. 3 incorrect/unintuitive? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi! I think figure 3 on page 50 of 2401bis-v03 is not correct or at least = seems unintuitive to me.=20 On the right hand side, the IPsec protected traffic is PROTECTed again? Shouldn't this be UNPROTECT or so? In the opposite case (fig. 2 p. 43) = the inverse action is called PROTECT too, which is really a protection. Lars --=20 Lars V=F6lker Institute of Telematics, University of Karlsruhe Zirkel 2, 76128 Karlsruhe Phone: +49 721 - 608 6397 Fax: +49 721 - 38 80 97 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 15:17:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15362 for ; Tue, 28 Sep 2004 15:17:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCNKw-0001Nq-9b; Tue, 28 Sep 2004 15:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCN7J-0007sK-Di for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 14:54:25 -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 OAA12364 for ; Tue, 28 Sep 2004 14:54:23 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCNFC-0007dC-9I for ipsec@ietf.org; Tue, 28 Sep 2004 15:02:34 -0400 Received: from [128.33.244.241] (col-dhcp33-244-241.bbn.com [128.33.244.241]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8SIrqjf004847; Tue, 28 Sep 2004 14:53:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 28 Sep 2004 14:53:14 -0400 To: Lars =?iso-8859-1?Q?V=F6lker?= From: Stephen Kent Subject: Re: [Ipsec] 2401bis-v03 fig. 3 incorrect/unintuitive? Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 11:20 AM +0200 9/28/04, Lars V=F6lker wrote: >Hi! > >I think figure 3 on page 50 of 2401bis-v03 is not correct or at least seems >unintuitive to me. > >On the right hand side, the IPsec protected traffic is PROTECTed again? >Shouldn't this be UNPROTECT or so? In the opposite case (fig. 2 p. 43) the >inverse action is called PROTECT too, which is really a protection. > >Lars > Lars, We can change the box in both figures to say=20 "APPLY" vs. "PROTECT" to try to minimize=20 confusion. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 17:08:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24413 for ; Tue, 28 Sep 2004 17:08:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPAZ-0000mb-TI; Tue, 28 Sep 2004 17:05:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCOsH-00066H-JA for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 16:47:01 -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 QAA23649 for ; Tue, 28 Sep 2004 16:46:58 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCP07-0002ea-4r for ipsec@ietf.org; Tue, 28 Sep 2004 16:55:11 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8SKkNjf012137; Tue, 28 Sep 2004 16:46:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 28 Sep 2004 16:49:18 -0400 To: ipsec@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: kseo@bbn.com Subject: [Ipsec] resend --> IPsec -- new AH and ESP drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, [First version of this email is being held for list moderator due to being too long. I accidentally included a bit of non-ASCII text... Apologies if you receive both that one and this one.] We have just submitted new versions of the AH and ESP drafts that incorporate the following changes, most of which have been discussed on the list or are typo/clarification fixes. Hopefully, all are acceptable to the working group. Thank you, Karen 1. AH and ESP -- As discussed Navin Kuma and Sheila Frankel (on the IPsec mailing list)... The AH RFC, in section 3.3.3.2.2, exempts MD5 and SHA-1 from the implicit packet padding requirements, since they have their own padding conventions. AES-XCBC-MAC was not defined when the AH RFC was written. Thus, implicit padding will be performed per the AH RFC, "If the IP packet length (including AH and the 32 high order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm. However, the AES-XCBC-MAC RFC, in section 4.2, states "with regard to 'implicit packet padding' as defined in [AH], no implicit padding is required." We therefore propose to remove the exemption for MD5 and SHA-1 and refer folks to the documents that define the specific integrity algorithms for guidance on how to use the algorithms with AH and ESP, with regard to padding. Thus, AH section 3.3.3.2.2, paragraph 2, will change From: For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions and thus no implicit packet padding is required. To: For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero. ESP section 3.3.2.1, last paragraph, will change From: For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the Sequence Number, if ESN is selected.) The padding octets MUST have a value of zero. The block size (and hence the length of the padding) is specified by the integrity algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte block size because of their internal padding conventions. To: For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the Sequence Number, if ESN is selected.) The block size (and hence the length of the padding) is specified by the integrity algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this question, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero. 2. AH -- As discussed with Francis Dupont, John Spence, and Jari Arkko (on the IPsec mailing list)... The flow label in IPv6 is chosen by the source node, and must be delivered to the ultimate destination without having been changed in transit. So in theory the flow label is "immutable." However, the flow label was specified in detail only by RFC 3697 (published in March 2004). And there is no real need to protect the flow label (see the RFC 3697 security considerations for attacks based on altered flow labels). Therefore, for compatibility with current IPv6/IPsec implementations, it was agreed to keep the current situation, i.e., flow label field *not* in "immutable" and to add a comment explaining this to AH (see (*) comment below). 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label (*) Hop Limit (*) The flow label described in AH v1 was mutable, and in RFC 2460 [DH98] was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AH v2. 3. AH and ESP -- As discussed with Andrea Colegrove in private communication... ESP does not contain a version number, therefore if there are concerns about backward compatibility, they need to be managed by a signaling mechanism between the two IPsec peers. We do not require that ESPv2 and ESPv3 interoperate. So it might be a good idea to point out this situation. This would seem to apply to AH as well. Therefore, we propose to add something along the lines of the following text: AH Section 2.0, at the end, before Section 2.1 ESP Section 2.0, at the end, before Section 2.1 "AH [ESP] does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of AH [ESP], e.g., IKE or an out-of-band configuration mechanism." 4. AH and ESP -- Francis Dupont brought up the following concern on the IPsec list (9/10/03)... We propose to add the sentence "Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6." as shown in the paragraphs below: AH 3.1.2 Tunnel Mode In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ESP 3.1.2 Tunnel Mode Processing In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. 5. ESP typo 3.4.4.2 Combined Confidentiality and Integrity Algorithms If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows: 1. Decryps and integrity check the ESP Payload Data, "Decryps" should be "Decrypt" and "check" should be "checks" 6. AH & ESP -- Under IKEv2, ESN is the default. The ESN addendum to the ISAKMP DOI doesn't need to be changed. But to minimize the chance of confusion, a sentence should be added to AH and ESP as shown below: 2.5.1 Extended (64-bit) Sequence Number To support high-speed IPsec implementations, a new option for sequence numbers SHOULD be offered, as an extension to the current, 32-bit sequence number field. Use of an Extended Sequence Number (ESN) MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit Sequence Numbers are explicitly negotiated. : 2.2.1 Extended (64-bit) Sequence Number (added last sentence) To support high-speed IPsec implementations, extended sequence numbers SHOULD be implemented, as an extension to the current, 32-bit sequence number field. Use of an Extended Sequence Number (ESN) MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit Sequence Numbers are explicitly negotiated. 7. ESP -- Reviewed and approved by working group. We put the following text back into Section 2.4. (The ESPv2 padding text (Section 2.4) is otherwise unchanged.): "If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)" 8. AH and ESP -- Reviewed and approved by working group. We replaced the current text re: multicast lookup in o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 with the following text: "If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this demultiplexing algorithm. In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions. Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows: 1. Search the SAD for a match on {SPI, destination address, source address}. If a SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available TCAM features. The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier. As part of this change, the references were updated with: [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security Architecture", RFC 3740, March 2004. 9. ESP typo 3.3.2.1 Separate Confidentiality and Integrity Algorithms 4. Compute the ICV over the ESP packet minus the ICV field. Thus the ICV computation encompasses the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. (Note that the last 4 fields will be in ciphertext form, since encryption is performed first.) If the ESN option is enabled for the SA, it the high-order 32 bits of the Sequence Number are appended after the Next Header field for purposes of this computation, but are not transmitted. The last sentence "If the ESN option is enabled for the SA, it the high-order 32...." has an extra "it" that should be removed. 10. We also updated the boilerplate and Notes sections per the ID-Checklist. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 18:29:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29863 for ; Tue, 28 Sep 2004 18:29:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQQ2-0007un-CD; Tue, 28 Sep 2004 18:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQ8V-000720-9T for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 18:07:51 -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 SAA27169 for ; Tue, 28 Sep 2004 18:07:47 -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 1CCQGP-0003wA-4W for ipsec@ietf.org; Tue, 28 Sep 2004 18:16:01 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8SM2sd09061 for ; Tue, 28 Sep 2004 18:02:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8SM4lbZ004823 for ; Tue, 28 Sep 2004 18:04:47 -0400 (EDT) Received: from cpe-69-133-196-17.cinci.rr.com(69.133.196.17) by nutshell.tislabs.com via csmap (V6.0) id srcAAAsoaOxj; Tue, 28 Sep 04 18:04:32 -0400 Date: Tue, 28 Sep 2004 18:10:35 -0500 To: ipsec@lists.tislabs.com From: lizie@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------kjzirkwheevuvotcezrp" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Ipsec] Hey! X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------kjzirkwheevuvotcezrp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Ipsec,


It's time to find a friend!

For details see the attach.

Kind regards, Lizie
----------kjzirkwheevuvotcezrp Content-Type: image/jpeg; name="myphoto4.jpeg" Content-Disposition: attachment; filename="myphoto4.jpeg" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAAQABAAD/4QDmRXhpZgAASUkqAAgAAAAFABIBAwABAAAAAQAAADEB AgAcAAAASgAAADIBAgAUAAAAZgAAABMCAwABAAAAAQAAAGmHBAABAAAAegAAAAAAAABBQ0Qg U3lzdGVtcyBEaWdpdGFsIEltYWdpbmcAMjAwNDowNDoyMyAwNTowNzowNQAFAACQBwAEAAAA MDIxMJCSAgADAAAAMzgAAAKgBAABAAAAdQAAAAOgBAABAAAAlgAAAAWgBAABAAAAvAAAAAAA AAACAAEAAgAEAAAAUjk4AAIABwAEAAAAMDEwMAAAAAAAAAAA/8AAEQgAlgB1AwEiAAIRAQMR Af/bAIQACAUGBwYFCAcGBwkICAkMFA0MCwsMGBESDhQdGR4eHBkcGyAkLicgIisiGxwoNigr LzEzNDMfJjg8ODI8LjIzMQEMDQ0SDxIjExMjSjEqMUpKSkpKSkpKSkpKSkpKSkpKSkpKSkpK SkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpK/8QAlgAAAQQDAQAAAAAAAAAAAAAABwIEBQYA AwgBEAABAwIEAgYGBwUGBwAAAAABAgMRAAQFEiExBkEHEyJRYXEyQoGRobEUFSM0UsHwM1Ny 0eEIYnOSk7IWJCU1NlSiAQADAQEBAAAAAAAAAAAAAAACAwQBAAURAAICAgIBBAMAAAAAAAAA AAABAhEDIRIxQQQTUWEUIjL/2gAMAwEAAhEDEQA/ADMFTrOp769J1rEdmNdhXsakkaiuFCkE dYBzrCdvnSU6KBpSt4rUcJJj+Qr0nxioviXGrbAcLdvrteRttJJMSdByHOg/xJ0vYvdAs4Oh GGhY1cUA44kfIEVzklo1RbDRiGKWOHIz312wwkDdxwJ+dV666R+GGkq/6va9nQwvn3Cua8Rx VV++t7Eru4vbkySt1UgnwHKo+6WnrC0FhSEmApucp8RNZbD4IP1702cPtXZabD7qE6dYhPZ+ OtTGH9LPC15AOJJYVoIdQRNczKZt0OKQt1QUBopELTtO9arlpdsspWomDvXWdxR2jZX9tetJ dtHkPIWJCm1AinNcmcBcdYjwtfoyurdslGXGZmB3jxrp7h3HLTHsKavrRxKkOpzQDOlGn4Yu UaN+OkfVL86SAN/EVWGiQlZAMKgz3VZMfJ+rlJHrKA8uf5VVbtZbtNFZSD6U/ruoZdmIYODO 652kgZjE6Unqv76PfTN3Vc667UilDKC0CIMVhIzV4AYI3rz1p76YAKTosGKxZjU7AVmWNa0Y hcJt7VbqtEIBUrXYDxrTgP8ATnjhcxa2whpxcJSlbjaRpqZMn2ChLdwlTga+0USesUNgfOpj izG1XuO4jib6Ap15RS2AdEJ2HtqQ4N4QusfcZdxUluyBJDCNMwHefhrSZSUf2ZTGL6RRnkJb TKcqjz138qUiwuG7cXT9utDK5CSU7kV0A3wjhqWS1a2TDaolJS2JSRBGtPLjBLdxpIurZoqJ haVJAEHkBSvyfoZ7X2c0LKAYRm8iKRnSCc4KtCE9r0TVv6QeGRguLJTbpIZf1QDy7xVVes1J Cld1UxkpKxMotMbFR3BI9tFToK4pfsr9zB3Vyw79o3p6CtJ8wefsNCuNTtUlwviH1Xj9ldkk IQ4AuDuk6Ee40T6Bo60xO7620aQRGZYmPKq1jSx1KUjUFXtNO3bpdxhNtcEDOTBy+sQN/Koz ESpYZz6ZtT4TQN2LSGKhsCoDuEzSco/EPjW9QR1igtQSdOU1kM/vU/5f6UAQUohIiZmvFCFU sDSTXuSTI27qaCJIjbuqj9LON/VfDamkEF27V1SdJkc6vCok+VBDp2vVqxNhmTDIB8O+hm9B QVsoGCWLeIcQsW9wAtIUVLE6GNAPfRywewbtmEJbRAG0dxoJcKXK7PH3rr6I9dIt0AL6lIUQ CZJo24DjNli+HJfsyvLPorEEHxFR5k7LcfROYczLiVZZ7j404xttJbzQM4gDxqq3fEuM2ZH0 eyt7dpBI666WTA7wlOpPhTi24usrhBavMWbXcK1CVNdWPZrNYq40c7uyjdLVt9IvsJtkoG7i p2kwNPh8aE2IOrS6q3KQJJ15iKLXSHc2719ZqU4hWTdafRGp+G1UTjDBS27b4kgJCH1EKA7w N/bvTcUqpAzVop0QrXnSNUrMVtVqTGtI2c13qtE7R0pwxcOO8O4WsA/bM9aByAIA386Riel0 ASFEeEU06MrtN1wVhCgZUy0tpZHLKuPlFPr/AEumxv4ROs0vwB5G7iEqeXliBG/lXnUjw9x/ nT20UE5y6kkqOg10Fb+tb/dq+NYZYQvVGvOvUq3jeedYAeyK9QIB5686YYIUARJrnXpovM3G zjKlZkJA7Pd310WZIk8q5k6aXBb8euLjMB6Xjp/WgltoZj8lWwM3K8bBaLpbUpCn0IUU9YnM NCRRc4NY6nic3LaHkNXK1FLJVCUN6mCNZ5AGeVD3o0/5nGrsJKQVIGUfKjLwphUXl1dyFFr7 IBRiI9L51Nmk+XEqxxXGx9xZYN31s8UW5W4ICEk5RHlUDccOt8SPsXGKWbNuq3aDSEtEhMA6 HL4SauAfSsqbfQFGDkWkz5zT3DsPaSkPKid6VG26QTpLZTeIeE273Avo+XIEphKolXgfh7jQ Z4jXimD2jmD4ghC2UKll1PIDlHt8xXR2PXIaaypUNNBNc+9I9wq+vrkpILVikJUSdAtRMDzj Wjx6lxMk7jZQ51nXXQ16R2Eq9la0yo/LSnjSQ5auIy6jUH21cyULHQTfIVhWI2azq04HEgnk ofzFXTElKbuQoCSY18qEfRDiycL4jDFwYavR1BPco6j4iKMmIsJD6ToAU+00LAfZrQz9ihZW oFYkwYrOq/vr99bn1oQhtJMQmtPXN/i+FYCEpPpCawSEx30pAhJNJTqEz30ZwhYO351zp/aH w5bPEwuo7LraVD5H5V0VcPMsIK33EtITJKlKgVz/ANP/ABXhmLPWdhhjiX/o2YuPJMgk+qDz FA+0MgDjhzGFYHcMPoGVwOSs8yggaD50bcNxS3dxFTr767br2g42CvIh4jSfGBpXPT7/AFwT MDKIoidGd+cXDWH3T0O2iSltRGYlB5Qe40nPjtcijFLfEOCcSwFlk3CX7YKIggLBjwFPLS+S /ZlbGdKQYhYhST3VHYLhLFrbBNxlU2BpnSBNReMYE7YLWrDeJLzDUOyrqFJQ8gHwzageFTdj dGrjO+OH4Yu5uiO0rK0zm7T6jskfrzoKcXXLFthjdikpcu3lm4ulpGgWfVHeBtNTnGGPWFlf FScQu8XxFoZRcvrBS0DvkSNE+yh3d3Krm4U86Soq2BJJPmapw4/IvJOlQm3ErB1it+T7BxSd knnvWuzkuEH0j8fCtqYCFmT2lQJPKqGINiLhTDrNw2crqClxJnSRR/t8R+scNtbpKtXm0qPO ARO9c9ZZsmV5RHaTI8D/AFox9HDwuuC7HQhSCpomRrCv686yQMi2hR61yFaSPVJ5UrMrv/8A g1i+ysgwDvqqK8kd6f8AUNCLCdBIMUlsaCdKVISBJ1rB4mmHFX48w1y+wlwi56tKQTBXlSa5 l4tFoy+tq2JVlMSRueddQ8crUrALlpvqgooMF0AhI7/CuW8abtmrhWVRcUTEjmNKQ65lOP8A grnUqLa17AGPM91O+H8WucFxRm+slBLjZ9YSkjuI7qkMVtDY26PpCcjxOfqf3cgRJ7/DlUWp IU2VqHaMqkd805NSQDVMuOO9KOL37ls9aINmu3UVZQvOkmI2I+dQWPcYY1j5BxG8UoDQIR2R 7qa4Hg9xjl81Y2Ylxe5OyRzJo18M9FuEWVs2bi2F08fSddGaT4DYCkSePF42NXOfkA1vb3Fz nLTTroSJORJNeqsbtLCbhVu4llforynKfbXTzfCFowkpZYSyOWUZagLzgt2xuFOYaW0sO6u2 ziZbJ/ED6p+HOh/K+jfZXyc+JWoKgA6HXvrZeLLjhUNM4lQAiDzo1OcDYe2tVx9GS267qvKZ A/Koq74KtAFHqkKzc41GlavUR+DfZfyCdLqgz1ZMJmfbFErofx5st/Uj0JdS8XmQfWkDMPPS arPEfDa8LJWkFxidRzHjUFYXDlhfs3do4UusLC0HxFPUlNaESi1pnR7rhzmUg+BG1I6z+4j3 UxwrEPrHDLa7ZUoJeQFwk7Typ1nc/E57xQiqCqo67zS/WI3EUg8uWtbEggGRRowp3H3C1/j7 CWrK4DYnWSdPdv8AlVKPQ+MIZ+nJeTe3qO0lKx2QY3g768tqM4CsvxNeLaSoELEjY0Dxp2xi yNKjjbi9q5OJuJuCl1xuQerByjxnnUCx6QG8CuoOkXo7axa0WcOabZKR2W0JCQtU6Se4TXPN 9w7dWPETmEuAqWHAypSRpmNdF0qYx/ttBO6D+H0N2RvnUDrLk6TuEjajZY2qVIHKqxwZhacP wy3Yb0CUAAbVbmlhGmxFRKXKTkx0lSpCLi1yJJ8POajLtnNyHdrUu47prrz8KZuAKMmDXTS8 HRvyV28slFCoGoG/68agrhogq7O29XC8QMh0FV3EWk5wQOetKY1MpnEtkh+1XKQUqTBB0j9f nQZu2jb3S2xu2qNdJo84w3LBMEATy/XdQU4jaLWJuEg9rcEc6q9M9tC8y1YWeDgocKYbmBgt SD4Empao/h+3cs+HsNtlQpTdukGTETrHxp9K/wAKf839KfZIwyhOm0zW1IgnTekgDLrvSjI5 0xAGEQnvryMx3EzXqjOkxWAD4zWnGKE8v60MuPMLsRxVYIZaSbp8quX3I1gDKkT7TROI76F9 2/8AWfH2IPpOZu3KbdMH8I1+JNI9Q6gOwK5FuwpqGkjkBoafupncTEGtGHBKUDlTzcVJFaHt 7GjgJitDi8oidacPLyjWNNRUPeXiEvJQFCVHQDnQydBJWbXTIy89/Kou7azAmZG0VJpMNg7k 95pnejMggZd9KWEir4olOQ7GJ1oMcZNBGIBYCVIEqKdp8PhRpxZxxLZaKjknNlO099B3ik9c +/GuQQI1jWqcH9GZNxoteCY/iGLYW1cs21oU6oKSVEpI0g09+mYr/wCpae5VCzBuJMRwa2Ux ZLbShS8xC2wdYHOn3/HeOfvGP9IVU8cr0TKUa2dlEzGgrNDuYodXHE9zZhtt65vEFUZnFwQA fGKlzi99ZtJubZSr1opBUy6qT5hXI/ClL1Cfg14Gi3mTShsKaYXiFvidkm6tlGD6ST6SD+E9 1O0mR4VSmntCGq0xhj2JN4Xhrly4QCBCQe+Py3oc8JNqWtVw4CVPOFxU+J1qR4/xY3N+cPaU MiD1R132Us+IiE+c0rh9rIyknWdp3qP1MrpFOBabLPaGQNY0p4NE+ym9okZdomtlw4EpPfS1 pBvbI3F7tNu0tauQ/Xxplh9jM3FymX185JyDuFa3lC9xNKd22O2rxVy/XlUy032dJ0pfbD6Q xuCUp08qj7lz1fSPMc6krxBJ2HeKiLoZEkmNTPnQPs1FX4rfSxbOLKvRG2ndQjulZ/pJWSIC ST7aIvHDxU2W0AErhPlrQ6vRFneK8AJ9hqrCjJlUdUgn7NJTvJJmda1yfD3UpLZWJG228V71 KvD/ADV6BCdLNW1pfS8tLhcKYEq0jxqXwV5TD5tVHOlmJnmCAaisI/ZDy/lUhh//AHW58kf7 BXjx7PQl0WM2BYcF7hrpYegEpI7DgPqqH571M4dei6ti5kKFAdoTI9lM0/dR/AmswH7m77at g6nS6JJ7jYKsNuHMVX9MdJlS3JkzqVkqP67qvGGNBtpOU6ACqFwp9xT/AIrn+40QbD9kP4RU c3cipJKNIm7fsNgA6VHYzddTbLXB0FSLX7MVC8Q/cXf4aJ9ALsRhSFBhDrqgpTnaVp+uVTKC erOg0qKw/wC5M/wCpVHoK9lZDs2Q1u9id4HOq7ibkIO48qsV36K/4R+dVnFvRV7fzrJdmxB3 xOpS7qCeZ31g1TcXAawS4cj01wPcKuPEf3w+Z/Kqdj3/AI6r/FPyFUYvB2TopkxzrMx7zWGv KvIj/9k= ----------kjzirkwheevuvotcezrp Content-Type: text/html; name="MoreInfo.vbs.htm" Content-Disposition: attachment; filename="MoreInfo.vbs.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MoreInfo.vbs
Virus name: W32/Bagle@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------kjzirkwheevuvotcezrp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------kjzirkwheevuvotcezrp-- From ipsec-bounces@ietf.org Tue Sep 28 19:47:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05501 for ; Tue, 28 Sep 2004 19:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRPg-0004fG-L4; Tue, 28 Sep 2004 19:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCR1a-0006sw-P7 for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 19:04:46 -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 TAA01584 for ; Tue, 28 Sep 2004 19:04:43 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCR9V-0005EY-BB for ipsec@ietf.org; Tue, 28 Sep 2004 19:12:58 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8SN3xF15298; Wed, 29 Sep 2004 01:03:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8SN40Sj087638; Wed, 29 Sep 2004 01:04:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409282304.i8SN40Sj087638@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Karen Seo , Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) In-reply-to: Your message of Thu, 16 Sep 2004 00:54:51 EDT. Date: Wed, 29 Sep 2004 01:04:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I've read the last version (draft-ietf-ipsec-rfc2401bis-03.txt) and I have some questions/comments: - nowhere it is explained how from a SPD one can find the other endpoint to use in tunnel mode: * in 3.2 this is not in the parameters which can be specified through the SPD management paradigm * in 4.4.1 some parameters needed to effect the protection are not listed (examples finish by "etc.") * in 4.4.1.2 this is not in processing info * in 4.4.2.1 this is in the data items in the SAD * 4.4.3 (PAD) is clearly about peers but does not give the answer * 4.5.3 is better but does not provide a general solution: "an IPsec-supporting host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use." what I am looking for is the specified way to bind an SPD entry to a peer address. * in appendix C this is not in the ASN.1 definition of an SPD entry Note this can become important for a correct operation of a MOBIKE protocol (these addresses could be updated so we should know where they are), so I'd like to get it fixed. - the second major issue is with the inbound processing (5.2, pages 50*). There is no lookup in the SPD similar to RFC 5.2.1 step 3 so no check similar to step 4: 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. If we assume the SPD is decorrelated we can get rid of the note. RFC2401bis SPD entries specify only one protection so the check should not be done at the end but each time (i.e., in the SAD check with SA "chaining" managed by loopback forwarding as shown in appendix E). My concern is the SAD check is not equivalent because of the SAD is not ordered and SAD selectors reflect SPD selectors at the time the SA is created, not the actual SPD situation. I give in the PS two examples of the issue. - in 4.1 matching on the SPI only works well when the SPI is given by one and only one node. Of course this can't be the case for multicast so we've got the destination+SPI or source+destination+SPI stuff. But 2nd paragraph associates the anycast case to the unicast one when the receiver in the anycast case is just a member of the group, and we can *not* assume to get the same member everytime. IMHO we have to deal with the anycast case as with the multicast case. (note that as an IPv6 man I understand "anycast" as "IPv6 anycast" :-) - in 4.1 lookup description (1, 2 and 3) the "ESP" seems superfluous. Some lines before, the draft states the protocol field is not used for multicast SA lookups without any explaination... - the initial fragment definition in 4.4 and use in 7 are not sound: "And the phrase "initial" fragment is used to mean a fragment that contains all the selector values needed for access control." "Also, for IPv6, even an initial fragment might NOT contain the Next Layer Protocol or Ports (or ICMP message type/code, or Mobility Header type) depending on the kind and number of extension headers present." with the definition there can be no initial fragment so the second statement doesn't make sense. - in 5.1 3b a "may" follows a "MAY"? - in 5.1.2.2 the flow label stuff is wrong: the flow label may be configured or automatically generated, *not* copied from the inner header. IMHO it is safe to assume than an SA is a flow. Of course the issue is worse in appendix C... - in 13 the draft states: o 2401bis clarifies that for all traffic that crosses the IPsec boundary, including IPsec management traffic, the SPD or associated caches must be consulted. This should be true, cf my first concern! - in references, Mobip is RFC 3775. Thanks Francis.Dupont@enst-bretagne.fr PS: first example: we'd like to protect any traffic between A and B with AH (SPD rule 1 local=A remote=B NLP=ANY Action=PROTECT(AH)) but for TCP we'd like confidentiality (SPD rule 2 local=A remote=B NLP=TCP Action=PROTECT(ESP)) If B sends to A a TCP packet protected by AH: - the SAD check will accept it (it matches the SA created by rule 1) - a SPD check will dropped it (incorrect protection). second example: To avoid the first example case, the SPD can be decorrelated before SAD selectors are filled. But this is not enough if the SPD is modified, for instance if the rule 2 is inserted in the SPD after the rule 1. Note I don't argue the SAD selectors should be modified, 4.4.2 is correct ("the entry for an inbound SA in the SAD MUST contain the value or values negotiated at the time the SA was created.") The real problem is the SAD check is not enough and must be followed by a SPD check. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 20:43:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09843 for ; Tue, 28 Sep 2004 20:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSPD-00089u-Pq; Tue, 28 Sep 2004 20:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS5v-0002uq-6a for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 20:13:19 -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 UAA07841 for ; Tue, 28 Sep 2004 20:13:17 -0400 (EDT) From: ghuang@cisco.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSDn-0007Pb-Sh for ipsec@ietf.org; Tue, 28 Sep 2004 20:21:31 -0400 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8T08Id06803 for ; Tue, 28 Sep 2004 20:08:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8T0ABdQ025746 for ; Tue, 28 Sep 2004 20:10:11 -0400 (EDT) Message-Id: <200409290010.i8T0ABdQ025746@nutshell.tislabs.com> Received: from unknown(221.10.5.194) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVaaOkY; Tue, 28 Sep 04 20:09:56 -0400 To: ipsec@lists.tislabs.com Date: Wed, 29 Sep 2004 08:24:13 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_FD578395.7E7F5606" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_FD578395.7E7F5606 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit It's the long-awaited film version of the Broadway hit. The message sent as a binary attachment. ------=_NextPart_000_0009_FD578395.7E7F5606 Content-Type: text/html; name="doc.pif.htm" Content-Disposition: attachment; filename="doc.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: doc.pif
Virus name: W32/Lovgate.x@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0009_FD578395.7E7F5606 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0009_FD578395.7E7F5606-- From ipsec-bounces@ietf.org Tue Sep 28 21:10:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11069 for ; Tue, 28 Sep 2004 21:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSdA-0003Ls-HH; Tue, 28 Sep 2004 20:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBQNq-0005PQ-Sc for ipsec@megatron.ietf.org; Sun, 26 Sep 2004 00:11:35 -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 AAA04378 for ; Sun, 26 Sep 2004 00:11:31 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBQVA-0006pZ-UT for ipsec@ietf.org; Sun, 26 Sep 2004 00:19:10 -0400 Received: by mproxy.gmail.com with SMTP id 78so205718rnk for ; Sat, 25 Sep 2004 21:11:32 -0700 (PDT) Received: by 10.38.15.36 with SMTP id 36mr550500rno; Sat, 25 Sep 2004 21:11:32 -0700 (PDT) Received: by 10.38.164.13 with HTTP; Sat, 25 Sep 2004 21:11:32 -0700 (PDT) Message-ID: Date: Sun, 26 Sep 2004 12:11:32 +0800 From: "Luo, Guojie" To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Sep 2004 20:47:38 -0400 Subject: [Ipsec] need to get familiar with IPsec quickly X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Luo, Guojie" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit can anybody show me one article best describe IPsec, and one article best describe the implement framework? thanks~~ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 21:10:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11133 for ; Tue, 28 Sep 2004 21:10:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSdB-0003Ly-EE; Tue, 28 Sep 2004 20:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCLy4-0002AA-N5; Tue, 28 Sep 2004 13:40:48 -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 NAA07134; Tue, 28 Sep 2004 13:40:47 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCM5m-0005y6-VN; Tue, 28 Sep 2004 13:48:57 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 28 Sep 2004 13:40:07 -0400 id 003C8291.4159A1F7.00006226 From: "Scott Hollenbeck" To: iesg@ietf.org Date: Tue, 28 Sep 2004 13:40:00 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F93C@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 28 Sep 2004 20:47:38 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] RE: Last Call: 'The Use of Galois/Counter Mode (GCM) in IPsec ESP' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable (I'm not subscribed to the IPsec list, so this might get held up for moderation.) Section 8.3 says: "For IKE Phase 2 negotiations, IANA has assigned as the ESP Transform Identifier for AES-GCM with an eight-byte explicit IV." Seeing the I would expect something in the IANA Considerations = section to describe what IANA has to do to make this assignment. There is = nothing requested of IANA, though: "12. IANA Considerations Currently, no ESP transform numbers have been assigned for use with the AES-GCM transform." Some text should be added here to explicitly describe the IANA action = needed to fill in the in section 8.3. -Scott- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 21:20:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11795 for ; Tue, 28 Sep 2004 21:20:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCT3C-0001Of-9G; Tue, 28 Sep 2004 21:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSlC-00057z-Me for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 20:55:58 -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 UAA10583 for ; Tue, 28 Sep 2004 20:55:54 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSsr-0008FO-Jb for ipsec@ietf.org; Tue, 28 Sep 2004 21:04:08 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CCSj1-0007rx-00; Tue, 28 Sep 2004 20:53:43 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1CCSj0-00008A-Oj; Tue, 28 Sep 2004 20:53:42 -0400 Date: Tue, 28 Sep 2004 20:53:42 -0400 From: "Theodore Ts'o" To: Karen Seo Subject: Re: [Ipsec] resend --> IPsec -- new AH and ESP drafts Message-ID: <20040929005342.GA435@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Sep 28, 2004 at 04:49:18PM -0400, Karen Seo wrote: > Folks, > > [First version of this email is being held for list moderator due to > being too long. I accidentally included a bit of non-ASCII text... > Apologies if you receive both that one and this one.] I've found the mail in the moderation queue and suppressed it since Karen has resent it w/o the non-ASCII text. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 22:18:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14483 for ; Tue, 28 Sep 2004 22:18:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCTzM-00074Z-8I; Tue, 28 Sep 2004 22:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCTvg-0005xF-Oy for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 22:10:52 -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 WAA14047 for ; Tue, 28 Sep 2004 22:10:50 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCU3N-00013B-Ij for ipsec@ietf.org; Tue, 28 Sep 2004 22:19:05 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CCTut-00089Q-00; Tue, 28 Sep 2004 22:10:03 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1CCTut-0000As-4K; Tue, 28 Sep 2004 22:10:03 -0400 Date: Tue, 28 Sep 2004 22:10:03 -0400 From: "Theodore Ts'o" To: ipsec@ietf.org Message-ID: <20040929021003.GC435@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Many thanks to Stephen Kent and Karen Seo for submitting the updated version of the rfc2401bis-03.txt. At this point, we believe that this document has addressed all pending issues that have been listed in the Issue Tracker. So therefore, it is appropriate that we start a one week working group, starting today and terminating on Tuesday, October 2nd. To all working group members, we would greatly appreciate it if you would take this opportunity to review the document and make comments to the mailing list at your earliest convenience. Many thanks. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 22:43:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16486 for ; Tue, 28 Sep 2004 22:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCU5o-0000bw-QN; Tue, 28 Sep 2004 22:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCU0p-0007EW-3h for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 22:16:11 -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 WAA14314 for ; Tue, 28 Sep 2004 22:16:08 -0400 (EDT) Received: from [69.25.196.29] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCU8X-00017v-0h for ipsec@ietf.org; Tue, 28 Sep 2004 22:24:24 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CCTzM-0008AZ-00; Tue, 28 Sep 2004 22:14:40 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1CCTzM-0000B6-4D; Tue, 28 Sep 2004 22:14:40 -0400 Date: Tue, 28 Sep 2004 22:14:40 -0400 From: "Theodore Ts'o" To: Karen Seo Message-ID: <20040929021440.GD435@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipsec@ietf.org Subject: [Ipsec] Minor typographical errors in draft-ietf-ipsec-rfc2401bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org While going through the rfc2401bis-03 draft, I found the following minor typo's. - Ted Page 12, Section 4.1: Extra curly brace: 1. Search the SAD for a match on the combination of SPI, destination address, and source address}. If an SAD entry matches, then process the inbound ESP packet with that If you're removing the curly brace syntax and replacing it with explantory text, then you should probably also make the change from {SPI} to SPI here: 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol otherwise. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. -------------------------------- Page 13: Extra hyphen in "-support"? Therefore a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to -support QoS appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender -------------------------------- Section 4.4, Page 18: Missing period at the end of this paragraph: depend on the kind and number of extension headers present. The "initial" fragment might not be the first fragment, in this context _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 28 23:43:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21803 for ; Tue, 28 Sep 2004 23:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCVH4-0007Y9-IH; Tue, 28 Sep 2004 23:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCVCS-0006Tp-6P for ipsec@megatron.ietf.org; Tue, 28 Sep 2004 23:32:16 -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 XAA21320 for ; Tue, 28 Sep 2004 23:32:13 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCVKF-0002pR-2L for ipsec@ietf.org; Tue, 28 Sep 2004 23:40:29 -0400 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8T3Vtwu009930 for ; Wed, 29 Sep 2004 09:01:56 +0530 Message-Id: <5.1.0.14.0.20040928084643.02dcee40@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 Sep 2004 09:05:19 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ipsec] query regarding deletion of IKEv2 session X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I have query regarding the deletion of IKE SA in following case: Responder received AUTH response consisting of AUTH, SA2,TS,etc payloads. Responder verified the AUTH and it is successful. If the responder does not have matching SPD policy either non-matching selectors or non-matching proposals. Responder sends the corresponding informational exchange. In this case, do we delete the IKEv2 SA?? I think we should not delete IKE SA. Because AUTH verification is succeeded. When the administrator changes the SPD policy, then we can start CHILD_SA exchange to negotiate IPSEC proposals. But, CHILD_SA exchange is optional. In case if we delete IKE SA, does the responder sends the delete payload for IKE SA?? Because AUTH exchange is not complete but AUTH verification is succeeded. Thanks in advance Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 29 13:29:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21143 for ; Wed, 29 Sep 2004 13:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CChsd-0000fz-Et; Wed, 29 Sep 2004 13:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CChbS-000557-Ke for ipsec@megatron.ietf.org; Wed, 29 Sep 2004 12:46:54 -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 MAA18403 for ; Wed, 29 Sep 2004 12:46:51 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CChjM-0002IX-TM for ipsec@ietf.org; Wed, 29 Sep 2004 12:55:15 -0400 Received: from SriniSony (dhcp-111.intoto.com [10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8TGmu9D009353; Wed, 29 Sep 2004 09:48:56 -0700 Message-ID: <041f01c4a643$e5c10b70$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: , "Jyothi" References: <5.1.0.14.0.20040928084643.02dcee40@172.16.1.10> Subject: Re: [Ipsec] query regarding deletion of IKEv2 session Date: Wed, 29 Sep 2004 09:46:42 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > Hi all, > > I have query regarding the deletion of IKE SA in following case: > > Responder received AUTH response consisting of AUTH, SA2,TS,etc payloads. > > Responder verified the AUTH and it is successful. > > If the responder does not have matching SPD policy either non-matching > selectors or non-matching proposals. Responder sends the corresponding > informational exchange. > > In this case, do we delete the IKEv2 SA?? SRINI> I would think so. If the responder is not returning response to AUTH exchage, initiator would anyway will not complete the transaction and it fails. > I think we should not delete IKE SA. Because AUTH verification is succeeded. SRINI> But, note that the responder is not returning its authentication credentials. So there is no need for keeping the IKE SA on responder side. > > When the administrator changes the SPD policy, then we can start CHILD_SA > exchange to negotiate IPSEC proposals. > > But, CHILD_SA exchange is optional. SRINI> That is true. IKEs with minimal capabilities does not have to support Child SA. > > In case if we delete IKE SA, does the responder sends the delete payload > for IKE SA?? Because AUTH exchange is not complete but AUTH verification is > succeeded. SRINI> It is not needed. IKE SA would not have been matured on Initiator side and initiator would delete it, if there is no successful AUTH exchange response is received. > > Thanks in advance > Jyothi > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 29 17:29:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18166 for ; Wed, 29 Sep 2004 17:29:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkTV-0004eP-P7; Wed, 29 Sep 2004 15:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkO2-0001bw-FZ for ipsec@megatron.ietf.org; Wed, 29 Sep 2004 15:45:14 -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 PAA03111 for ; Wed, 29 Sep 2004 15:45:12 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCkW8-00064M-EM for ipsec@ietf.org; Wed, 29 Sep 2004 15:53:36 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TJisSZ057096; Wed, 29 Sep 2004 12:44:54 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 29 Sep 2004 12:44:55 -0700 To: Karen Seo , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] resend --> IPsec -- new AH and ESP drafts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org These drafts got stuck in the Internet Drafts queue. They are temporarily available as and . Those links will be removed with the drafts are officially posted. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 29 19:24:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01074 for ; Wed, 29 Sep 2004 19:24:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnJU-0000w1-6s; Wed, 29 Sep 2004 18:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCmtS-0000UY-0t for ipsec@megatron.ietf.org; Wed, 29 Sep 2004 18:25:50 -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 SAA25521 for ; Wed, 29 Sep 2004 18:25:46 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCn1O-0004Te-NH for ipsec@ietf.org; Wed, 29 Sep 2004 18:34:13 -0400 Received: from SriniSony (dhcp-111.intoto.com [10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i8TMRq9D021196; Wed, 29 Sep 2004 15:27:52 -0700 Message-ID: <03a201c4a673$3db37f00$6f05010a@SriniSony> From: "Srinivasa Rao Addepalli" To: , "Jyothi" References: <5.1.0.14.0.20040924074124.024f69e0@172.16.1.10> Subject: Re: [Ipsec] Traffic selectors selection using IKEv2 Date: Wed, 29 Sep 2004 15:25:35 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1631232035==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1631232035== Content-Type: multipart/alternative; boundary="----=_NextPart_000_039D_01C4A638.911B6E90" This is a multi-part message in MIME format. ------=_NextPart_000_039D_01C4A638.911B6E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some issues in selection of traffic selectors in IKEv2. Initially, SG1 and SG2 have the same SPD configuration. After that SG2 administrator modified the SPD policy but SG1 SPD = policy is not modified. H1 -------SG1 ---- Internet ------ SG2-----H2 SG1 SPD policy: Protocol: ALL Src 1: 1.1.1.10 - 1.1.1.200 Src 2: 2.2.2.20 - 2.2.2.40 Dst 1: 10.10.10.10 - 10.10.10.20 Dst 2: 20.20.20.20 - 20.20.20.200 SG2 SPD policy: Protocol: ALL Src 1: 20.20.20.50 - 20.20.20.100 Src 2: 10.10.10.5 - 10.10.10.15 Dst 1: 1.1.1.10 - 1.1.1.30 Dst 2: 2.2.2.10 - 2.2.2.30 H1 IP address is : 1.1.1.15 H2 IP address is : 20.20.20.65 Traffic initiated from H1 to H2 (UDP traffic with port 6666 to = destination port 6767) There are three cases:=20 1) No PFP is set=20 SG1 started negotiating IKEv2 with following traffic selectors: TS Src1: 1.1.1.15 protocol UDP port 6666 (pkt selectors may = be sent or may not be (renewal case)). Src2: 1.1.1.10 - 1.1.1.200 Src3: 2.2.2.20 - 2.2.2.40 TS Dst1: 20.20.20.65 protocol UDP port 6767 Dst2: 10.10.10.10 - 10.10.10.20 Dst3: 20.20.20.20 - 20.20.20.200 What SG2 should select?? Because it has some matching selectors?? Can SG2 select the following selectors and send it to SG1: a) TS Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the received = selectors and SPD policy has the same = set) Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the received = selectors adn SPD policy has a set more = than that subset) TS Dst1: 20.20.20.50 - 20.20.20.200 (is a subset of the = received selectors and SPD policy has the = same set) Dst2: 10.10.10.10 - 10.10.10.15(is a subset of the received = selectors and SPD policy has the = same set) protocol is ALL SRINI> Yes. This seems to be correct. If IPSEC SA are created with the above set, there will be overhead. Searching is happening twice.=20 Can I store multiple sets of selectors in SA?? SRINI> Since, you are sending all possible selectors in the response, only one SA is needed and all selected selectors point to the same SA. I think I am missing some thing. Please correct me. OR b) Can I just select the packet selectors and protocol ALL (since the = SPD policy has protocol ALL configuration). SRINI> This scheme would create too many SAs and I would not recommend = this. 2) PFP is selected for protocol and IP addresses in SG1, but not in = SG2. Then in this case what SG1 should propose?? Is it pkt selectors and SPD selectors with a particular protocol?? SRINI> If SG1 is initiator, it would send specific protocol and = specific IP addresses. Responder will select the same thing.=20 3) PFP is not selected in SG1, but in SG2. In this case what selectors SG2 should select?? If SG2 selects the matching subset, same SA will be used even if PFP = is selected. SRINI> SG1 as initiator would send all selector ranges including the = packet selectors. SG2 would select the packet selectors as its response. If packet selectors are not sent = (typically happens during start up or in case of persistent tunnel configurations), then this negotiation = would fail.=20 Thanks Jyothi=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec Intoto Inc. www.intoto.com ------=_NextPart_000_039D_01C4A638.911B6E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Hi all,

I have some = issues in=20 selection of traffic selectors in IKEv2.

Initially, SG1 and SG2 = have=20 the same SPD configuration.
 After that SG2 administrator = modified the=20 SPD policy but SG1 SPD policy is not=20 = modified.


        &nbs= p; H1=20 -------SG1 ---- Internet ------ SG2-----H2

SG1 SPD=20 policy:
     Protocol:=20 ALL

     Src 1:  1.1.1.10 -=20 1.1.1.200
     Src 2:  2.2.2.20 -=20 2.2.2.40

     Dst 1:  10.10.10.10 -=20 10.10.10.20
     Dst 2:  20.20.20.20 -=20 20.20.20.200

SG2 SPD policy:
     = Protocol:=20 ALL

     Src 1:  20.20.20.50 -=20 20.20.20.100
     Src 2:  10.10.10.5 -=20 10.10.10.15

     Dst 1:  1.1.1.10 -=20 1.1.1.30
     Dst 2:  2.2.2.10 -=20 2.2.2.30

H1 IP address is : 1.1.1.15   H2 IP address = is :=20 20.20.20.65


Traffic initiated from H1 to H2 (UDP traffic = with port=20 6666 to destination port 6767)
There are three cases:
1) No PFP = is set=20

    SG1 started negotiating IKEv2 with = following=20 traffic=20 = selectors:

        = TS=20 Src1:  1.1.1.15 protocol UDP port 6666 (pkt selectors may be sent = or may=20 not be (renewal=20 = case)).
          =20 Src2:  1.1.1.10 -=20 = 1.1.1.200
          = =20 Src3:  2.2.2.20 -=20 = 2.2.2.40

        TS=20 Dst1:  20.20.20.65 protocol UDP port=20 = 6767
        &n= bsp; =20 Dst2:  10.10.10.10 -=20 = 10.10.10.20
          =20 Dst3:  20.20.20.20 - 20.20.20.200

    What = SG2=20 should select?? Because it has some matching selectors??

Can = SG2 select=20 the following selectors and send it to=20 = SG1:

a)
        = TS=20 Src1: 1.1.1.10 - 1.1.1.30 (is a subset of the received=20 = selectors
                =          &nbs= p;          &nb= sp; =20 and SPD policy has the same=20 = set)
        &n= bsp; =20 Src2: 2.2.2.20 - 2.2.2.30 (is a subset of the received=20 = selectors
                =          &nbs= p;          &nb= sp;=20 adn SPD policy has a set more than that=20 = subset)

        TS=20 Dst1: 20.20.20.50 - 20.20.20.200 (is a subset of the received=20 = selectors
                =          &nbs= p;         &n= bsp;           = and SPD policy has the same=20 = set)
        &n= bsp; =20 Dst2: 10.10.10.10 - 10.10.10.15(is a subset of the received=20 = selectors
                =          &nbs= p;         &n= bsp;           = and SPD policy has the same set)
   protocol is=20 ALL
SRINI> Yes.=20 This seems to be correct.

If IPSEC SA are created with the above set, there will be=20 overhead.
Searching is happening twice.
Can I store multiple = sets of=20 selectors in SA??
 
SRINI> Since, you are sending all possible selectors = in the=20 response,
only one SA is needed and all selected selectors point to = the=20 same SA.


I think I am missing some thing. Please correct=20 = me.

                &n= bsp;       OR
b)=20 Can I just select the packet selectors and protocol ALL (since the SPD = policy=20 has
         = protocol ALL configuration).
 
SRINI> This=20 scheme would create too many SAs and I would not recommend=20 this.


2) PFP is selected for protocol and = IP=20 addresses in SG1, but not in SG2.

Then in this case what SG1 = should=20 propose??

Is it pkt selectors and SPD selectors with a = particular=20 protocol??
 
SRINI> = If=20 SG1 is initiator, it would send specific protocol and specific IP = addresses.
Responder will select the same thing.=20


3) PFP is not selected in SG1, but in=20 SG2.

In this case what selectors SG2 should select??

If = SG2=20 selects the matching subset, same SA will be used even if PFP is=20 selected.
 
SRINI> SG1 as initiator would send = all=20 selector ranges including the packet selectors. SG2 would=20 select
the packet selectors as its response. = If packet=20 selectors are not sent (typically happens during start=20 up
or in case of persistent tunnel = configurations),=20 then this negotiation would fail.=20

Thanks
Jyothi

_______________________________________________
Ipsec mailing=20 list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec
 
Intoto Inc.
www.intoto.com

------=_NextPart_000_039D_01C4A638.911B6E90-- --===============1631232035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1631232035==-- From ipsec-bounces@ietf.org Wed Sep 29 19:48:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03264 for ; Wed, 29 Sep 2004 19:48:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnrt-00034I-18; Wed, 29 Sep 2004 19:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnNj-0001Ja-FO for ipsec@megatron.ietf.org; Wed, 29 Sep 2004 18:57:07 -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 SAA28294 for ; Wed, 29 Sep 2004 18:57:04 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCnVh-0005Fr-6W for ipsec@ietf.org; Wed, 29 Sep 2004 19:05:31 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TMumKx085262 for ; Wed, 29 Sep 2004 15:56:49 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 29 Sep 2004 15:56:50 -0700 To: IPsec WG From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. We have talked for over five years about getting rid of 56-bit DES in IKEv1. So, I have (belatedly) written a draft on doing this at the same time as updating the other algorithm MUSTs and SHOULDs. This is a personal draft, not a WG item, but it can be discussed on this list before I turn it into the IESG as a personal submission. Comments are appreciated. --Paul Hoffman >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Wed, 29 Sep 2004 15:29:16 -0400 >Subject: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Algorithms for Internet Key Exchange >version 1 (IKEv1) > Author(s) : P. Hoffman > Filename : draft-hoffman-ikev1-algorithms-00.txt > Pages : 4 > Date : 2004-9-29 > >The required and suggested algorithms in the original IKEv1 >specification does not reflect the current reality of IPsec market. >It requires allowing weak security and suggests algorithms that are >thinly implemented. This document updates the original specification >and is intended for all IKEv1 implementations deployed today. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-ikev1-algorithms-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body >of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hoffman-ikev1-algorithms-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hoffman-ikev1-algorithms-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 30 12:33:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06733 for ; Thu, 30 Sep 2004 12:33:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3VX-0008T3-V9; Thu, 30 Sep 2004 12:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3GP-0002wk-TL for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 11:54:38 -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 LAA02972 for ; Thu, 30 Sep 2004 11:54:34 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD3OW-00035C-RF for ipsec@ietf.org; Thu, 30 Sep 2004 12:03:11 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1CD3GC-0000tN-00; Thu, 30 Sep 2004 17:54:24 +0200 Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72voelker) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1CD3GB-00078k-00; Thu, 30 Sep 2004 17:54:23 +0200 From: =?iso-8859-1?Q?Lars_V=F6lker?= To: "'Stephen Kent'" Subject: RE: [Ipsec] 2401bis-v03 fig. 3 incorrect/unintuitive? Date: Thu, 30 Sep 2004 17:54:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcSljJLLSr/ZrJFpTfKIQOxWfoavUQBd9Q1Q Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi! > We can change the box in both figures to say > "APPLY" vs. "PROTECT" to try to minimize > confusion. I think PROCESS and PROCESS might be a good idea too, since this is the verb the draft uses anyway in 5.2 3a (p. 51). The main confusion is that in both cases PROTECT was used and I got the feeling that the decapsulation of ESP is not really the same as protecting it (=encapsulation). When also considering IPcomp as possible protocol, protection seems to be an even worse choice. I feel PROCESS and PROCESS would be good, or we could use ENCAPSULATE and DECAPSULATE, even that with AH transport mode this option does not completely fit. Lars _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 30 15:12:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20820 for ; Thu, 30 Sep 2004 15:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD6As-0008Tu-I7; Thu, 30 Sep 2004 15:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD5qy-0000Zk-NV for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 14:40:33 -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 OAA17446 for ; Thu, 30 Sep 2004 14:40:30 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD5zH-0007ZJ-2i for ipsec@ietf.org; Thu, 30 Sep 2004 14:49:07 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8UIdkjf025359; Thu, 30 Sep 2004 14:39:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200409282304.i8SN40Sj087638@givry.rennes.enst-bretagne.fr> References: <200409282304.i8SN40Sj087638@givry.rennes.enst-bretagne.fr> Date: Thu, 30 Sep 2004 14:39:05 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Francis, Tunnel SA destination address: This was not present in 2401bis either, but we should deal with it now. We can add it to the SPD definition text and the ASN.1 in the appendix, and will make sure it is in the appropriate subsections of 4.4. I don't see it being in the PAD. 4.5.3 says you have to make this info available, but does not say how, because we have no standard mechanism. I think the best we can do is to augment the SPD definition to include the data and note that there is no standard means to do this. checking inbound traffic (5.2): You provided an example at the end of your message to clarify the concern re checking only the SAD entry vs. checking the SPD. However, I do not understand your example. You specified the first entry in the SPD applying to ALL traffic, and thus a linear search of the SPD would match that rule first, overriding the second entry, which was TCP-specific and called for use of ESP. The entries would have to be reversed if the second entry would ever be applied. If the entries were reversed in order, then the TCP-specific rule would catch all TCP traffic, and all other traffic would have AH applied. When the SPD is decorrelated, that process would split the AH SPD entry, to avoid overlap with the ESP SPD entry. (Using the new selector range value, the AH entry could be expressed as two new entries, specifying the protocol number ranges below and above TCP.) As a result, the SAD entry established for carriage of AH-protected traffic would not overlap with the TCP-specific SAD entry for which ESP must be applied. So, if a peer sent TCP traffic via the AH SA, it would NOT match the selectors in the SAD, since that SAD entry would have a gap where TCP would be. inbound SA selection (4.1): We can move the allusion to anycast to the discussion of multicast if other agree. We took text supplied by another WG member to more precisely describe this aspect of processing and this is the first time it has appeared in a draft. The references to ESP in the processing steps here are superfluous and will be removed. the protocol field is not used in SA selection for multicast SAs because support for such SAs is new, and we retained the option of using the protocol field as an option only for backward compatibility for unicast SAs. initial, non-initial, and first fragments: The definition in 4.4 is correct, noting that in some cases in IPv6, the initial fragment might not be the first fragment. The text in 7 will be changed to match that in 4.4, specifically we will change "Also, for IPv6, even an initial fragment might NOT contain the Next Layer Protocol or Ports ..." to say "Also, for IPv6, the first fragment might NOT contain the Next Layer Protocol or Ports ..." 5.1 3b: We will fix the lowercase "may" in this section. 5.1.2.2: other than for covert channel concerns, why would one never copy a flow label from the inner header? 13: the SAD is a form of SPD cache, for inbound traffic carried via an SA. do you think we need to clarify this in the discussion of the SAD in 4.4.2? we will update the reference to the Mobile IP RFC _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 30 17:04:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02623 for ; Thu, 30 Sep 2004 17:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7Xh-0000xY-Tk; Thu, 30 Sep 2004 16:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7Gx-0007ng-TE for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 16:11:28 -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 QAA26108 for ; Thu, 30 Sep 2004 16:11:25 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD7PG-0001XS-4h for ipsec@ietf.org; Thu, 30 Sep 2004 16:20:03 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8UKAls07275; Thu, 30 Sep 2004 22:10:47 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8UKAlSj098613; Thu, 30 Sep 2004 22:10:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409302010.i8UKAlSj098613@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) In-reply-to: Your message of Thu, 30 Sep 2004 14:39:05 EDT. Date: Thu, 30 Sep 2004 22:10:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: Tunnel SA destination address: This was not present in 2401bis either, but we should deal with it now. We can add it to the SPD definition text and the ASN.1 in the appendix, and will make sure it is in the appropriate subsections of 4.4. I don't see it being in the PAD. 4.5.3 says you have to make this info available, but does not say how, because we have no standard mechanism. I think the best we can do is to augment the SPD definition to include the data and note that there is no standard means to do this. => I agree but we should do something for the Tunnel SA source address too: - to be coherent with the situation on the peer where source and destination address roles are swapped - because if in many cases the source address can be inferred from the destination address this is not always the case. So I proposed an optional field when no value means infer from the destination. checking inbound traffic (5.2): You provided an example at the end of your message to clarify the concern re checking only the SAD entry vs. checking the SPD. However, I do not understand your example. You => I forgot to specify the order of the rule: the most specific must be first. specified the first entry in the SPD applying to ALL traffic, and thus a linear search of the SPD would match that rule first, overriding the second entry, which was TCP-specific and called for use of ESP. The entries would have to be reversed if the second entry would ever be applied. If the entries were reversed in order, then => please assume the reversed order. the TCP-specific rule would catch all TCP traffic, and all other traffic would have AH applied. When the SPD is decorrelated, that => when? This is not clear that the SPD is decorrelated... I am afraid the decorrelation goal is to focused on caching so I missed in 5: Note: It is assumed that one starts with a correlated SPD... process would split the AH SPD entry, to avoid overlap with the ESP SPD entry. (Using the new selector range value, the AH entry could be expressed as two new entries, specifying the protocol number ranges below and above TCP.) As a result, the SAD entry established for carriage of AH-protected traffic would not overlap with the TCP-specific SAD entry for which ESP must be applied. So, if a peer sent TCP traffic via the AH SA, it would NOT match the selectors in the SAD, since that SAD entry would have a gap where TCP would be. => so the SAD check works for the first example but not (yet) for the second where the rule 2 is added* after the creation of the SAD entry for the rule 1 (*: after in time, before in order). ... other little points... => fine 5.1.2.2: other than for covert channel concerns, why would one never copy a flow label from the inner header? => in order to break the unicity rule on flow labels? IMHO the flow label MUST NOT be copied. 13: the SAD is a form of SPD cache, for inbound traffic carried via an SA. do you think we need to clarify this in the discussion of the SAD in 4.4.2? => yes because there is a good way to not reproduce pages of explainations about how to manage SAD selectors for instance about changes implied by add/update/delete in the SPD. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 30 17:31:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04533 for ; Thu, 30 Sep 2004 17:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD8Br-0003J0-LS; Thu, 30 Sep 2004 17:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7mw-0000Df-LK for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 16:44:30 -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 QAA29675 for ; Thu, 30 Sep 2004 16:44:27 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD7vG-0002ke-8q for ipsec@ietf.org; Thu, 30 Sep 2004 16:53:06 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8UKhUjj002527; Thu, 30 Sep 2004 16:43:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200409302010.i8UKAlSj098613@givry.rennes.enst-bretagne.fr> References: <200409302010.i8UKAlSj098613@givry.rennes.enst-bretagne.fr> Date: Thu, 30 Sep 2004 16:42:37 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0181329431==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0181329431== Content-Type: multipart/alternative; boundary="============_-1115545521==_ma============" --============_-1115545521==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:10 PM +0200 9/30/04, Francis Dupont wrote: > In your previous mail you wrote: > > Tunnel SA destination address: This was not present in 2401bis > either, but we should deal with it now. We can add it to the SPD > definition text and the ASN.1 in the appendix, and will make sure it > is in the appropriate subsections of 4.4. I don't see it being in > the PAD. 4.5.3 says you have to make this info available, but does > not say how, because we have no standard mechanism. I think the best > we can do is to augment the SPD definition to include the data and > note that there is no standard means to do this. > >=> I agree but we should do something for the Tunnel SA source address too: > - to be coherent with the situation on the peer where source and > destination address roles are swapped > - because if in many cases the source address can be inferred from the > destination address this is not always the case. >So I proposed an optional field when no value means infer from the >destination. the source address, for the sender, is trivial if you have just one interface, and if you are not mobile. if you have multiple interfaces, you do need to specify the right one to use as the source address, statically. if you are mobile, you need to have something outside of IPsec updating the value, which says that there would not be any useful SPD entry to specify in advance. so, yes, we will add text to accommodate both source and destination addresses for tunnel headers. >=> when? This is not clear that the SPD is decorrelated... I am afraid >the decorrelation goal is to focused on caching so I missed in 5: we do not explain how to perform decorrelation in detail the text, but rather refer to Appendix B. A fundamental requirement for any algorithm of this sort is that it breaks overlapping entries into non-overlapping entries. I think the text inn 4.4.1 says that reasonably well. >=> so the SAD check works for the first example but not (yet) for the >second where the rule 2 is added* after the creation of the SAD entry >for the rule 1 (*: after in time, before in order). section 4.4.1 concludes with a brief section: Handling Changes to the SPD while the System is Running If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation MAY choose to check the impact of an SPD change on extant SAs and to provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc. i think this addressed your concern. > 5.1.2.2: other than for covert channel concerns, why would one never > copy a flow label from the inner header? > >=> in order to break the unicity rule on flow labels? IMHO the flow >label MUST NOT be copied. what is the "unicity rule?" Steve --============_-1115545521==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] revised IPsec Architecture draft (2401bis)
At 10:10 PM +0200 9/30/04, Francis Dupont wrote:
 In your previous mail you wrote:

   Tunnel SA destination address: This was not present in 2401bis
   either, but we should  deal with it now.  We can add it to the SPD
   definition text and the ASN.1 in the appendix, and will make sure it
   is in the appropriate subsections of 4.4.  I don't see it being in
   the PAD.  4.5.3 says you have to make this info available, but does
   not say how, because we have no standard mechanism.  I think the best
   we can do is to augment the SPD definition to include the data and
   note that there is no standard means to do this.
  
=> I agree but we should do something for the Tunnel SA source address too:
 - to be coherent with the situation on the peer where source and
   destination address roles are swapped
 - because if in many cases the source address can be inferred from the
   destination address this is not always the case.
So I proposed an optional field when no value means infer from the
destination.

the source address, for the sender, is trivial if you have just one interface, and if you are  not mobile. if you have multiple interfaces, you do need to specify the right one to use as the source address, statically. if you are mobile, you need to have something outside of IPsec updating the value, which says that there would not be any useful SPD entry to specify in advance. so, yes, we will add text to accommodate both source and destination addresses for tunnel headers.

        <SNIP>

=> when? This is not clear that the SPD is decorrelated... I am afraid
the decorrelation goal is to focused on caching so I missed in 5:

we do not explain how to perform decorrelation in detail the text, but rather refer to Appendix B. A fundamental requirement for any algorithm of this sort is that it breaks overlapping entries into non-overlapping entries. I think the text inn 4.4.1 says that reasonably well.

=> so the SAD check works for the first example but not (yet) for the
second where the rule 2 is added* after the creation of the SAD entry
for the rule 1 (*: after in time, before in order).

section 4.4.1 concludes with a brief section:

        Handling Changes to the SPD while the System is Running

        If a change is made to the SPD while the system is running, a check
     SHOULD be made of the effect of this change on extant SAs. An
   implementation MAY choose to check the impact of an SPD change on
       extant SAs and to provide a user/administrator with a mechanism for
     configuring what actions to take, e.g., delete an affected SA, allow
        an affected SA to continue unchanged, etc.
i think this addressed your concern.

    5.1.2.2: other than for covert channel concerns, why would one never
   copy a flow label from the inner header?
  
=> in order to break the unicity rule on flow labels? IMHO the flow
label MUST NOT be copied.



what is the "unicity rule?"

Steve
--============_-1115545521==_ma============-- --===============0181329431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0181329431==-- From ipsec-bounces@ietf.org Thu Sep 30 17:33:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04807 for ; Thu, 30 Sep 2004 17:33:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD8Qx-0007NX-4M; Thu, 30 Sep 2004 17:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7si-0004QF-Tv for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 16:50:28 -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 QAA00399 for ; Thu, 30 Sep 2004 16:50:26 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD812-000311-CQ for ipsec@ietf.org; Thu, 30 Sep 2004 16:59:05 -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 i8UKjTd28879 for ; Thu, 30 Sep 2004 16:45:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8UKlNZf020352 for ; Thu, 30 Sep 2004 16:47:23 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe8aaVN; Thu, 30 Sep 04 16:47:20 -0400 Date: Thu, 30 Sep 2004 15:50:47 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jvtgzmllveqbxlqcxfpg" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------jvtgzmllveqbxlqcxfpg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------jvtgzmllveqbxlqcxfpg Content-Type: text/html; name="Dog.cpl.htm" Content-Disposition: attachment; filename="Dog.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Dog.cpl
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------jvtgzmllveqbxlqcxfpg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------jvtgzmllveqbxlqcxfpg-- From ipsec-bounces@ietf.org Thu Sep 30 19:55:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15363 for ; Thu, 30 Sep 2004 19:55:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDAec-0003w5-17; Thu, 30 Sep 2004 19:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDAOn-0000Iw-HM for ipsec@megatron.ietf.org; Thu, 30 Sep 2004 19:31:45 -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 TAA13723 for ; Thu, 30 Sep 2004 19:31:41 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDAX6-0006x0-8P for ipsec@ietf.org; Thu, 30 Sep 2004 19:40:23 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8UNV5Y03823; Fri, 1 Oct 2004 01:31:05 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8UNV5Sj099207; Fri, 1 Oct 2004 01:31:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) In-reply-to: Your message of Thu, 30 Sep 2004 16:42:37 EDT. Date: Fri, 01 Oct 2004 01:31:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: the source address, for the sender, is trivial if you have just one interface, and if you are not mobile. if you have multiple interfaces, you do need to specify the right one to use as the source address, statically. if you are mobile, you need to have something outside of IPsec updating the value, => an IPsec/mobile integrate code needs to know the place of the value to be enabled to update it: I raised the issue exactly for this reason... which says that there would not be any useful SPD entry to specify in advance. so, yes, we will add text to accommodate both source and destination addresses for tunnel headers. => so this issue is closed. >=> when? This is not clear that the SPD is decorrelated... I am afraid >the decorrelation goal is to focused on caching so I missed in 5: we do not explain how to perform decorrelation in detail the text, but rather refer to Appendix B. A fundamental requirement for any algorithm of this sort is that it breaks overlapping entries into non-overlapping entries. I think the text inn 4.4.1 says that reasonably well. => I have no problem with the decorrelation idea (I began with pattern matching and term rewriting systems where the problem is hard, BTW IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm). But I still believe a statement explaining the SPD is considered as being decorrelated after the end of 4.4.1 should be fine. >=> so the SAD check works for the first example but not (yet) for the >second where the rule 2 is added* after the creation of the SAD entry >for the rule 1 (*: after in time, before in order). section 4.4.1 concludes with a brief section: Handling Changes to the SPD while the System is Running If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation MAY choose to check the impact of an SPD change on extant SAs and to provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc. i think this addressed your concern. => yes but this conflicts with the end of 4.4.2: For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST contain the value or values negotiated at the time the SA was created. For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1, "Selectors." (note I like the idea of explaining that the SAD selectors are in fact the inbound SPD cache!) > 5.1.2.2: other than for covert channel concerns, why would one never > copy a flow label from the inner header? > >=> in order to break the unicity rule on flow labels? IMHO the flow >label MUST NOT be copied. what is the "unicity rule?" => RFC 3697 section 3 (flow labeling requirements): A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. Obviously RFC 3697 requires the source node has the control of label assignment and bans SGs from copying flow labels from inner headers. Thanks Francis.Dupont@enst-bretagne.fr PS: about flow labels IMHO it is enough to refer to RFC 3697. The only issue is the RFC 3697 doesn't really define flows: A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection. I believe we can say: - a SA can form a flow (default case) - multiple instances of SAs with the same parameters can form a flow (at least two reasons: keep the same flow label across rekeying, allow explicit specification of flow label values) so we get: - zero flow label - explicit specification (which includes previous case) - automatic assignment by the IPv6 according to its own flow establishment method (i.e., don't care at the IPsec level :-) This can be encoded by an optional value on 20 bits. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec