From ipsec-bounces@ietf.org Wed Dec 1 04:32: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 EAA07370 for ; Wed, 1 Dec 2004 04:32:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQiK-0003Wp-Hj; Wed, 01 Dec 2004 04:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQaY-0001SX-Cb for ipsec@megatron.ietf.org; Wed, 01 Dec 2004 04:15:56 -0500 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 EAA05153 for ; Wed, 1 Dec 2004 04:15:53 -0500 (EST) 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 1CZQfm-0003Cr-Rs for ipsec@ietf.org; Wed, 01 Dec 2004 04:21:22 -0500 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 iB199Hd10084 for ; Wed, 1 Dec 2004 04:09:17 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iB19CVjw002682 for ; Wed, 1 Dec 2004 04:12:31 -0500 (EST) Received: from web51504.mail.yahoo.com(206.190.38.196) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoTaOof; Wed, 1 Dec 04 04:12:28 -0500 Received: (qmail 90510 invoked by uid 60001); 1 Dec 2004 09:15:43 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=niHwWwHajeTCnJkjWd7xPB2QFqUle3cALgWLGIOdWZhd3yXBYPHQvpEQhfG2zarDjJqDnju1tFFNbVAYWYH2ImRIXNZ98o/cjZtDD/AxONigVGroM8/gzp0z3F+hIT8f9HwV7NAFbLHyAo1m113MOdeI0C2wXyN9XAYhbcM3Hpg= ; Message-ID: <20041201091543.90508.qmail@web51504.mail.yahoo.com> Received: from [221.15.137.64] by web51504.mail.yahoo.com via HTTP; Wed, 01 Dec 2004 01:15:43 PST Date: Wed, 1 Dec 2004 01:15:43 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Issue on Phase 2 handler 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="===============0122041523==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0122041523== Content-Type: multipart/alternative; boundary="0-912792643-1101892543=:84423" --0-912792643-1101892543=:84423 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iB199Hd10084 Content-Transfer-Encoding: quoted-printable Hi, When we've unpacked the ipsec-tools-0.2.5.tar.gz, In ipsec-tools-0.2.5= /src/racoon/handler.h, we can see something like the following: =20 /* Phase 2 handler */ /* allocated per a SA or SA bundles of a pair of peer's IP addresses. */ /* * initiator responder * 0 (---) (---) * 1 start start (1st msg received) * 2 acquire msg get 1st valid msg received * 3 getspi request sent getspi request sent * 4 getspi done getspi done * 5 1st msg sent 1st msg sent * 6 1st valid msg received 2nd valid msg received * 7 (commit bit) (commit bit) * 8 SAs added SAs added * 9 SAs established SAs established * 10 SAs expired SAs expired */ =20 Then,=20 1), Since the initiator only send one message (step 5), why should the = responder receive two messages (step 2 and step 6)? 2), We know that before initiator begins its negotiation with responder= , it will send an SADB_GETSPI message from a user process to the kernel f= or an SPI. When it get the SPI, it can begins its negotiation.=20 But here, Why should the responder also send an SADB_GETSPI (step 3 and= step 4)? Is it still send the message to its kernel? Why don't it use th= e SPI from the initiator? If the responder get its own SPI, then there wi= ll be two different SPI between the initiator and responder, which one wi= ll they finally use? =20 Thank you. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Meet the all-new My Yahoo! =96 Try it today!=20 --0-912792643-1101892543=:84423 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iB199Hd10084 Content-Transfer-Encoding: quoted-printable
Hi,
   When we've unpacked the ipsec-tools-0.2.5.tar.gz, = In ipsec-tools-0.2.5/src/racoon/handler.h, we can see something like the = following:
 
/* Phase 2 handler */
/* allocated per a SA or SA bundles of a pa= ir of peer's IP addresses. */
/*
 *    &nb= sp; initiator          =      responder
 *  0   (---)&n= bsp;           &nb= sp;      (---)
&nbssp;*  1   s= tart           &nb= sp;       start (1st msg received)
 = ;*  2   acquire msg get      = ;   1st valid msg received
 *  3   getsp= i request sent     getspi request sent
 *&nbs= p; 4   getspi done       &nb= sp;     getspi done
 *  5   1s= t msg sent            1= st msg sent
 *  6   1st valid msg received  2= nd valid msg received
 *  7   (commit bit) &n= bsp;          (commit bit) *  8   SAs added     &nbs= p;         SAs added
 *&n= bsp; 9   SAs established      &nb= sp;  SAs established
 * 10   SAs expired &nbs= p;           SAs expire= d
 */
 
  Then,
  1), Since the initiator only send one messag= e (step 5), why should the responder receive two messages (step 2 and ste= p 6)?
  2), We know that before initiator begins its negotiation = with responder, it will send an SADB_GETSPI message from a user process t= o the kernel for an SPI. When it get the SPI, it can begins its negotiati= on.
  But here, Why should the responder also send an SADB_GETSP= I (step 3 and step 4)? Is it still send the message to its kernel? Why do= n't it use the SPI from the initiator? If the responder get its own SPI, = then there will be two different SPI between the initiator and responder,= which one will they finally use?
 
  Thank you.


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Meet the all-new My Yahoo! =96 Try it= today!=20 --0-912792643-1101892543=:84423-- --===============0122041523== 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 --===============0122041523==-- From mailman-bounces@ietf.org Wed Dec 1 06:50: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 GAA18189 for ; Wed, 1 Dec 2004 06:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZS7Q-0000kh-QO for ipsec-archive@lists.ietf.org; Wed, 01 Dec 2004 05:53:56 -0500 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 Dec 2004 05:32:59 -0500 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 Dec 1 12:41: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 MAA02602 for ; Wed, 1 Dec 2004 12:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXde-0003xA-2E; Wed, 01 Dec 2004 11:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZWUL-0001i3-FK for ipsec@megatron.ietf.org; Wed, 01 Dec 2004 10:33:58 -0500 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 KAA12265 for ; Wed, 1 Dec 2004 10:33:52 -0500 (EST) 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 1CZWZf-0002V4-96 for ipsec@ietf.org; Wed, 01 Dec 2004 10:39:25 -0500 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 iB1FRAd25327 for ; Wed, 1 Dec 2004 10:27:10 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iB1FUOUX006137 for ; Wed, 1 Dec 2004 10:30:24 -0500 (EST) Received: from nwkea-mail-1.sun.com(192.18.42.13) by nutshell.tislabs.com via csmap (V6.0) id srcAAAScai_l; Wed, 1 Dec 04 10:30:21 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iB1FXV6O001419; Wed, 1 Dec 2004 07:33:32 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iB1FXV8p029964; Wed, 1 Dec 2004 10:33:31 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iB1FXV0Q015144; Wed, 1 Dec 2004 10:33:31 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iB1FXRJS015143; Wed, 1 Dec 2004 10:33:27 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] Issue on Phase 2 handler From: Bill Sommerfeld To: Park Lee In-Reply-To: <20041201091543.90508.qmail@web51504.mail.yahoo.com> References: <20041201091543.90508.qmail@web51504.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101915206.14792.2.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 01 Dec 2004 10:33:27 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.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 On Wed, 2004-12-01 at 04:15, Park Lee wrote: > But here, Why should the responder also send an SADB_GETSPI (step 3 > and step 4)? Is it still send the message to its kernel? Why don't it > use the SPI from the initiator? If the responder get its own SPI, then > there will be two different SPI between the initiator and responder, > which one will they finally use? AH/ESP SA's are unidirectional, but IKE establishes them in pairs. AH/ESP SPI's are chosen by the receiver. With PF_KEY, you thus need to do a getspi on each end to pick the SPI used for traffic to that node. the getspi invoked by the initiator is used for responder->initiator traffic. the getspi invoked by the responder is used for initiator->responder traffic. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 1 14:38: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 OAA16266 for ; Wed, 1 Dec 2004 14:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZZXO-00083E-At; Wed, 01 Dec 2004 13:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYyd-0000kT-EV for ipsec@megatron.ietf.org; Wed, 01 Dec 2004 13:13:20 -0500 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 NAA05410 for ; Wed, 1 Dec 2004 13:13:17 -0500 (EST) Received: from web61310.mail.yahoo.com ([216.155.196.153]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZZ3x-0007CL-Cb for ipsec@ietf.org; Wed, 01 Dec 2004 13:18:52 -0500 Received: (qmail 99836 invoked by uid 60001); 1 Dec 2004 18:12:45 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DWFCBkHR4T7gSMobTx+fcyNc9frhxgdncb5f+AOvT0XsKzX0cVRdO+tPPy5RcGYrW6M9y2qvfL6zLeknLc+XA6SKKppB/1CkovY+XIq6IXnyCoOz5fnyeNUJWdS7OhJd77el56tvNR7Nib3sIsSiS/Ulg4Ius3S5uhDZH5dREQU= ; Message-ID: <20041201181245.99834.qmail@web61310.mail.yahoo.com> Received: from [80.217.162.241] by web61310.mail.yahoo.com via HTTP; Wed, 01 Dec 2004 10:12:45 PST Date: Wed, 1 Dec 2004 10:12:45 -0800 (PST) From: krishna G To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ipsec] Tunnel persistance with a MobileNode 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="===============1215376520==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1215376520== Content-Type: multipart/alternative; boundary="0-2145617557-1101924765=:98807" --0-2145617557-1101924765=:98807 Content-Type: text/plain; charset=us-ascii Outbound packet processing: I have a few questions on this First, How is it implemented in the practical world RFC 2401 says ------------------------------------------------------------------------------------- 5.1 Outbound IP Traffic Processing 5.1.1 Selecting and Using an SA or SA Bundle Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST: 1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD. 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. 3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt. _________________________________________________________ Selector fields: 4.4.2 Selectors The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. Note also that both Source and Destination addresses should either be IPv4 or IPv6. - Destination IP Address (IPv4 or IPv6): Source IP Address(es) (IPv4 or IPv6): Name: Data sensitivity level: (IPSO/CIPSO labels) Transport Layer Protocol: Source and Destination (e.g., TCP/UDP) Ports ------------------------------------------------------------------------------------- Now in the practical world what are the typical selectors used for establishing the SA's in a VPN Gateway scenario (VPN GW sitting in between the communicating nodes, typical corporate intranet access scenario). Is the use of one security association per pair of nodes, i.e Source, Destination IP addresses typical? I was just thinking if it is possible to maintain a SA with a node (Mobile Node) that changes it's IP address frequently (we won't like to establish a new SA during every change in IP address) and moreover i would like to have a unique SA with each MN If i ought to maintain SA then the selectors should be so chosen that they are unique to each MN at the same time not depending on its IP address. If i choose source address, source, destinatin ports, it would work as long as all the MN's have a unique port number for themselves at any point of time, but considering the fact that MN's might most often be behind NAT, this doesn't seem practical. Is there any easy solution for this? Suppose we succeeded to send the packet to the MN, the inbound processing at the MN looks for SA based on the triple, Destination IP address, protocol, SPI. The packet will not be processed. Is updating the SAD whenever a new binding request is send to the Home Agent (not when binding update is sent by HA, since this itself would be in IPsec tunnel) a solution. Since this updation is needed only at the client side, it should be easy to implement if the updation is done by the MobileIP client software (ofcourse, it should be possible for this to access and update the SAD which might be implemented by a different vendor's solution). I believe such updation is not against the IETF standard. Also i would be happy to know the usage of 'Name' field in the selectors? How does the a tunnel end point recognise the 'name' of a sender by looking at the packet Does that use other identities such as layer2 identity to determine this. But this works at layer3, so no information would be conveyed by layer2. (Even layer2 identity usage won't work for using X.509 in the name field, then how can this field be used?) Ofcourse, upcoming standards like IKE2 would provide a solution to the problem of mobile VPN connection. Regards, Krishna --------------------------------- Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. --0-2145617557-1101924765=:98807 Content-Type: text/html; charset=us-ascii
Outbound packet processing:
I have a few questions on this
First, How is it implemented in the practical world
RFC 2401 says
-------------------------------------------------------------------------------------
5.1 Outbound IP Traffic Processing
5.1.1 Selecting and Using an SA or SA Bundle
Since a packet's selectors might
   match multiple policies or multiple extant SAs and since the SPD is
   ordered, but the SAD is not, IPsec MUST:
           1. Match the packet's selector fields against the outbound
              policies in the SPD to locate the first appropriate
              policy, which will point to zero or more SA bundles in the
              SAD.
           2. Match the packet's selector fields against those in the SA
              bundles found in (1) to locate the first SA bundle that
              matches.  If no SAs were found or none match, create an
              appropriate SA bundle and link the SPD entry to the SAD
              entry.  If no key management entity is found, drop the
              packet.
           3. Use the SA bundle found/created in (2) to do the required
              IPsec processing, e.g., authenticate and encrypt.
_________________________________________________________
Selector fields:
4.4.2  Selectors
The following selector parameters
   MUST be supported for SA management to facilitate control of SA
   granularity.  Note that in the case of receipt of a packet with an
   ESP header, e.g., at an encapsulating security gateway or BITW
   implementation, the transport layer protocol, source/destination
   ports, and Name (if present) may be "OPAQUE", i.e., inaccessible
   because of encryption or fragmentation.  Note also that both Source
   and Destination addresses should either be IPv4 or IPv6.
      - Destination IP Address (IPv4 or IPv6):
 Source IP Address(es) (IPv4 or IPv6):
 Name:
 Data sensitivity level: (IPSO/CIPSO labels)
 Transport Layer Protocol:
 Source and Destination (e.g., TCP/UDP) Ports
-------------------------------------------------------------------------------------
Now in the practical world what are the typical selectors used for establishing the SA's in a VPN Gateway scenario (VPN GW sitting in between the communicating nodes, typical corporate intranet access scenario).
Is the use of one security association per pair of nodes, i.e Source, Destination IP addresses typical?
I was just thinking if it is possible to maintain a SA with a node (Mobile Node) that changes it's IP address frequently (we won't like to establish a new SA during every change in IP address) and moreover i would like to have a unique SA with each MN
If i ought to maintain SA then the selectors should be so chosen that they are unique to each MN at the same time not depending on its IP address.
If i choose source address, source, destinatin ports, it would work as long as all the MN's have a unique port number for themselves at any point of time, but considering the fact that MN's might most often be behind NAT, this doesn't seem practical.
Is there any easy solution for this?
Suppose we succeeded to send the packet to the MN, the inbound processing at the MN looks for SA based on the triple, Destination IP address, protocol, SPI. The packet will not be processed. Is updating the SAD whenever a new binding request is send to the Home Agent (not when binding update is sent by HA, since this itself would be in IPsec tunnel) a solution. Since this updation is needed only at the client side, it should be easy to implement if the updation is done by the MobileIP client software (ofcourse, it should be possible for this to access and update the SAD which might be implemented by a different vendor's solution). I believe such updation is not against the IETF standard.
Also i would be happy to know the usage of 'Name' field in the selectors?
How does the a tunnel end point recognise the 'name' of a sender by looking at the packet Does that use other identities such as layer2 identity to determine this. But this works at layer3, so no information would be conveyed by layer2. (Even layer2 identity usage won't work for using X.509 in the name field, then how can this field be used?)

Ofcourse, upcoming standards like IKE2 would provide a solution to the problem of mobile VPN connection.
 

       Regards,
       Krishna

Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses. --0-2145617557-1101924765=:98807-- --===============1215376520== 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 --===============1215376520==-- From ipsec-bounces@ietf.org Sat Dec 4 11:06: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 LAA08493 for ; Sat, 4 Dec 2004 11:06:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CacMY-0006J9-VA; Sat, 04 Dec 2004 11:02:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CacLZ-00062k-Ns for ipsec@megatron.ietf.org; Sat, 04 Dec 2004 11:01:21 -0500 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 LAA08353 for ; Sat, 4 Dec 2004 11:01:18 -0500 (EST) Received: from [217.219.18.2] (helo=cc.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CacRW-0003OV-EO for ipsec@ietf.org; Sat, 04 Dec 2004 11:07:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id E8B532C803E for ; Sat, 4 Dec 2004 19:28:34 +0330 (IRT) Received: from cc.iut.ac.ir ([127.0.0.1]) by localhost (cc.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32734-05 for ; Sat, 4 Dec 2004 19:28:34 +0330 (IRT) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id 3C3B62C803D for ; Sat, 4 Dec 2004 19:28:34 +0330 (IRT) From: "mahdavi" To: ipsec@ietf.org Date: Sat, 4 Dec 2004 19:28:34 +0330 Message-Id: <20041204155253.M77942@ec.iut.ac.ir> X-Mailer: Open WebMail X-OriginatingIP: 193.251.135.123 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: by amavisd-new at cc.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ipsec] 3 modes of defining tunnels in SPD. 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 Dear Experts. I have asked this question before but got no answer. So I ask it again because we can not decide which is correct. the question is as follows. I am working on a high speed secure router and there is something that I cant Understand what to do with it. and that is these mysterious sentences. (I call these as Case A and Case B ) " a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wild card for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a).,......" Imagine a router that is IPSec aware (SG1). HOST HOST C to K=========|1| SG1 |2|=======================SG2 --- M to X | / \ / | / \ / \-------------/ \------------------------/ SG1 has two interfaces 1 and 2 . outbound policy for interface 2 of SG1 says : -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with SG2. USE CASE B -------------------------------------------------------- This means to use one SA for all traffic traversing from (C - K) TO ( M - X ). Right? What about this policy? -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with SG2. USE CASE A -------------------------------------------------------- What that means? Does it mean to make separate SA's for any source-destination pair ? For example one for a packet traversing from C to M and one another for a packet giong from D to N and one another for a packet going from C to N ??? If so what is benefit of this ??? __________________________________________________________ __________________________________________________________ Question 2: Before, I thought that Case A Is not usable in this situation and this situation should be used with case b. Was Right ? __________________________________________________________ __________________________________________________________ Question 3: Can we have such a policy like below for inbound traffic for interface 1 of SG1? For inbound traffic for interface 1 of SG1 : (this is just one policy record) -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with ITSELF (SOURCE OF Packet). -------------------------------------------------------- In above policy because we wanted to have one policy for many tunnels (in this case 9 tunnels each for each host C - K ) and ITSELF means having a tunnel with source of packet host. Firstly, having such a policy is logical??? Secondly, does it mean Case A??? ____________________________________________________________ Best of regards Mahdavi. -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 5 01:35: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 BAA22869 for ; Sun, 5 Dec 2004 01:35:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CapYg-0002Jr-0I; Sun, 05 Dec 2004 01:07:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CapAY-0003yI-PJ for ipsec@megatron.ietf.org; Sun, 05 Dec 2004 00:42:51 -0500 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 AAA19580 for ; Sun, 5 Dec 2004 00:42:46 -0500 (EST) Received: from pike.sandelman.ca ([205.150.200.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CapGd-00011f-JQ for ipsec@ietf.org; Sun, 05 Dec 2004 00:49:08 -0500 Received: from sandelman.ottawa.on.ca (road.marajade.sandelman.ca [205.150.200.163]) by pike.sandelman.ca (Postfix) with ESMTP id 8BBDE5E377 for ; Sun, 5 Dec 2004 00:42:43 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A5048BDAE for ; Sat, 4 Dec 2004 22:42:38 -0700 (MST) From: "Michael Richardson" To: ipsec@ietf.org X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Date: Sat, 04 Dec 2004 22:42:38 -0700 Message-ID: <31751.1102225358@marajade.sandelman.ottawa.on.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [Ipsec] Initial Contact messages 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----- This is an extended summary of a discussion at the ICSA IPsec Consortia meetings of December 2, 2004. The discussion started concerning the IPSec 2.0 criteria. In it, it was said that ICSA was going to test that a responder properly dealt with Initial Contact messages by deleting old SAs with that "identity". IKEv2-17 says: INITIAL_CONTACT 16384 This notification asserts that this IKE_SA is the only IKE_SA currently active between the authenticated identities. It MAY be sent when an IKE_SA is established after a crash, and the recipient MAY use this information to delete any other IKE_SAs it has to the same *AUTHENTICATED IDENTITY* without waiting for a timeout. This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time). (some upcase is mine) The last sentence in this is pretty much where the conversation lay. It is difficult for an entity to know if the credentials may be replicated. So, to some extent, we assume that it will be difficult in practice to configure the client correctly here. A number of people suggested that in fact they would always be ignoring the IC messages. (Thus the conflict with the ICSA Criteria requirements) A lot of the discussion dealt with what an *AUTHENTICATED IDENTITY* is. Particularly in the context of XAUTH users with group-psk. To understand the reasons, we discussed a number of scenarios. We had a number of scenarios that we identified. In all cases, we were interested only in how the responding system should behave. Below, Ix is the PARENT SA Identity. ID_i. Note that we consider the 4-tuple of SA/DA, SP/DP because we assume that there may be NATs in between. 1) a multiuser system H1, creates two parent SAs because it needs to authenticate as two different identities. +-------+ +-------+ |H1 I1|<--------------------------->| I3 H2| | I2| | | +-------+ +-------+ We believe that H1 *MAY* send IC on each connection. For this reason it may be that H2 must look at identity *ONLY* when deciding which old SAs to flush. 4-tuple is not unique. 2) a single user system H1, connecting to a gateway H2, shutting down/suspending, and returning on another IP: .--------. | I1 H1 |<------------\ .-------. | | \ | | '--------' ------------->| | - ---- time ---- | H2 | .--------. /-------------->| | | I1 H1 |<-----------/ | | | | '-------' '--------' In this case, the 4-tuple is unique, but in addition, the ID being the same is works to find the appropriate SAs. 3) two single user systems, using XAUTH, having "Group PSK" I1. Different user names. .--------. | I1 H1 |<------------\ .-------. | user1 | \ | | '--------' ------------->| | | H2 | .--------. /-------------->| | | I1 H2 |<-----------/ | | | user2 | '-------' '--------' In this case, if H2 combines the 4-tuple with the Ix, then H2 can find SAs before XAUTH is done. Alternatively, H2 can wait until the XAUTH has been done before it processes the initial contact. 4) two single user systems, using XAUTH, having "Group PSK" I1. The same user names. This is, for instance, the situation where a single person wants their laptop and their PDA to be online. .--------. | I1 H1 |<------------\ .-------. | user1 | \ | | '--------' ------------->| | | H2 | .--------. /-------------->| | | I1 H2 |<-----------/ | | | user1 | '-------' '--------' H2 can determine uniqueness here by combining 4-tuple, ID and username. Arguably, in this situation IC should not be sent if the IDs are known to be combined. {In addition, situation (1) could be combined with any of the other situations} ===== conclusions ===== There are as many as 6 items that may be used to index into the SA table to do IC processing. There was concern that it may not be possible to build an index that provides better than linear search given the differences. There was extension discussion that liveness checks (dead peer detection) will in most cases clean up all stale SAs. There was discussion about whether it would in fact clean up in all situations. {Most of these issues are not unique to IKEv2. However, XAUTH usage has not generally been useable across vendors in IKEv1. ICSA IPSec 2.0 does not test XAUTH in IKEv2 (or IKEv1). } The suggestion was a heuristic that said that IC processing should be done by looking up 4-tuple only. If only 2 Parent SAs were found (i.e. the current one, and 1 old one), then the old one should be purged (with all of its children). This permits efficient cleanup for site-to-site VPN configurations where the end points do not move. It was noted that this is not the situation where one worries about resource exhaustion --- site-to-site VPNs tend not to have to scale to the same degree that RoadWarrior ones do. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQbKfyYqHRg3pndX9AQGtzAP8C+IoHSsy2v0hrUs4YG1UzJ0XbM/gTVCN eGhiBQn8TRz2jd0e+25F5880+ZupaxhLgOfiURonTw1/dO+22w8J1XEJtyggRwIY kMyJquAsiVFKWoHH+L8F9E1GsdQWd5LjO3P0PuBhhzFRtNn0CSqvsDHj6D3goKzp iMGA4wXBqFk= =jv7L -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 5 12:44: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 MAA24639 for ; Sun, 5 Dec 2004 12:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb0D2-0002dg-Ck; Sun, 05 Dec 2004 12:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb067-0001P6-Da for ipsec@megatron.ietf.org; Sun, 05 Dec 2004 12:22:59 -0500 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 MAA23279 for ; Sun, 5 Dec 2004 12:22:56 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb0C9-0003T5-1I for ipsec@ietf.org; Sun, 05 Dec 2004 12:29:23 -0500 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 iB5HMVPV055215; Sun, 5 Dec 2004 09:22:37 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <31751.1102225358@marajade.sandelman.ottawa.on.ca> References: <31751.1102225358@marajade.sandelman.ottawa.on.ca> Date: Sun, 5 Dec 2004 09:22:12 -0800 To: "Michael Richardson" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Initial Contact messages Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 10:42 PM -0700 12/4/04, Michael Richardson wrote: >There was extension discussion that liveness checks (dead peer >detection) will in most cases clean up all stale SAs. There was >discussion about whether it would in fact clean up in all situations. Whether or not it does is irrelevant to the user unless there is a resource-exhaustion issue. If there is such an issue, the implementation probably will have other serious problems that cannot be found consistently. >{Most of these issues are not unique to IKEv2. However, XAUTH usage has > not generally been useable across vendors in IKEv1. The issues are relevant regardless of using XAUTH: the are the same for the EAP methods in IKEv2. >The suggestion was a heuristic that said that IC processing should be >done by looking up 4-tuple only. If only 2 Parent SAs were found (i.e. the >current one, and 1 old one), then the old one should be purged (with all >of its children). That is certainly the reasonable interpretation of the spec, and fairly easy to implement. >This permits efficient cleanup for site-to-site VPN configurations where >the end points do not move. Yes, and it also permits efficient cleanup for remote-access users who only come in over one transport at a time. > It was noted that this is not the situation >where one worries about resource exhaustion --- site-to-site VPNs tend >not to have to scale to the same degree that RoadWarrior ones do. Some remote-access VPN systems have an setting that allows the administrator to say "anyone in this group of users can only be logged in once at a time". If a user with the exact same credentials (including whatever came in after XAUTH) completes SA setup, the first SA is torn down. This should work fine even for pre-shared non-secrets as long as XAUTH or some other credentialling mechanism produces unique results for each user. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 01:44: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 BAA20033 for ; Mon, 6 Dec 2004 01:44:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCVc-0001EO-0I; Mon, 06 Dec 2004 01:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCQp-0000bT-RR for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 01:33:12 -0500 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 BAA19310 for ; Mon, 6 Dec 2004 01:33:10 -0500 (EST) 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 1CbCX8-00025s-3S for ipsec@ietf.org; Mon, 06 Dec 2004 01:39:43 -0500 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 iB66X5c7011801 for ; Mon, 6 Dec 2004 12:03:05 +0530 Message-Id: <5.1.0.14.0.20041206114053.02631580@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 Dec 2004 12:06:43 +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: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] CHILD SA keys 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, I would like to know more details on order of extraction of CHILD SA keys from the key material(KEYMAT) in case ESPwith AUTH and AH . Is my understanding is right? : Initiator side: KEYMAT = { outbound ESP encryption key | outbound ESP auth key | outbound AH key | inbound ESP encryption key | inbound ESP auth key | inbound AH key} Responder side: KEYMAT = { inbound ESP encryption key | inbound ESP auth key | inbound AH key outbound ESP encryption key | outbound ESP auth key | outbound AH key | } Thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 02:14: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 CAA05724 for ; Mon, 6 Dec 2004 02:14:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCtM-0005KF-8T; Mon, 06 Dec 2004 02:02:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbChu-0003AE-G1 for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 01:50:50 -0500 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 BAA20474 for ; Mon, 6 Dec 2004 01:50:49 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbCoC-0002Ox-UA for ipsec@ietf.org; Mon, 06 Dec 2004 01:57:21 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I8A00L0SGBSJ2@mailout1.samsung.com> for ipsec@ietf.org; Mon, 06 Dec 2004 15:50:16 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I8A002W8GBIFT@mailout1.samsung.com> for ipsec@ietf.org; Mon, 06 Dec 2004 15:50:07 +0900 (KST) Received: from MOHANLAL ([107.108.71.61]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I8A00JUBGBFS2@mmp2.samsung.com> for ipsec@ietf.org; Mon, 06 Dec 2004 15:50:06 +0900 (KST) Date: Mon, 06 Dec 2004 12:17:04 +0530 From: mohanlal jangir To: ipsec@ietf.org Message-id: <011301c4db5f$67a15960$3d476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Subject: [Ipsec] IPSec use with Diameter 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 Here is one paragraph from RFC 3588 (Diameter Base Protocol): "Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with Diameter must also be trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate policy, TLS SHOULD be used to protect Diameter connections between administrative domains. IPSec is most appropriate for intra-domain usage when pre-shared keys are used as a security mechanism." Can someone explain more about this? Regards Mohanlal _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 02:18: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 CAA06217 for ; Mon, 6 Dec 2004 02:18:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCtQ-0005Mp-Qi; Mon, 06 Dec 2004 02:02:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCiH-0003Ce-6h for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 01:51:13 -0500 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 BAA20480 for ; Mon, 6 Dec 2004 01:51:12 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbCoa-0002Q2-Ci for ipsec@ietf.org; Mon, 06 Dec 2004 01:57:44 -0500 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 iB66oejf000865; Mon, 6 Dec 2004 01:50:41 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 6 Dec 2004 01:53:23 -0500 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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: kseo@bbn.com Subject: [Ipsec] IPsec -- AH draft 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, Based on the November exchange on the IPsec list re: AH and ICV and padding (see emails on subject "Query for IPv6 ICV" starting 11/4/04), we have submitted a new AH draft. This has been modified as shown below to clarify that in addition to the existing requirement to pad the ICV such that the whole AH length is an integral multiple of 4 (IPv4) or 8 (IPv6), unnecessary padding is prohibited. We did not modify any paragraphs involving *implicit* padding on the assumption that the relevant algorithm document should specify the padding requirements appropriately. 2.6 Integrity Check Value (ICV) This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits (IPv4 or IPv6) in length. The details of ICV processing are described in Section 3.3.3 "Integrity Check Value Calculation" and Section 3.4.4 "Integrity Check Value Verification." This field may include explicit padding, if required to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding . Details of how to compute the required padding ^^^^ insert text --> and MUST insert only enough padding to satisfy IPv4/v6 alignment requirements. length are provided below in Section 3.3.3.2 "Padding". The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 3.3.3.2.1 ICV Padding As mentioned in section 2.6, the ICV field may include explicit padding if required to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field to enable the receiver to perform the ICV calculation. ^^^^ add text: Inclusion of padding in excess of the minimnal amount required to satisfy IPv4/v6 alignment requirements is prohibited. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 02: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 CAA07629 for ; Mon, 6 Dec 2004 02:33:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbDBR-0003TX-0o; Mon, 06 Dec 2004 02:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbCvn-0006er-Vb for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 02:05:12 -0500 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 CAA26657 for ; Mon, 6 Dec 2004 02:05:10 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbD26-0002ed-Nv for ipsec@ietf.org; Mon, 06 Dec 2004 02:11:43 -0500 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 iB674djf001128; Mon, 6 Dec 2004 02:04:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 6 Dec 2004 02:07:23 -0500 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: e3ebaaff3b3539efaf29ef65eea2aded Cc: kseo@bbn.com Subject: [Ipsec] IPsec 2401bis -- new draft 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 Apologies if this is a duplicate -- the first try is currently stuck in the IPsec mailer queue because it was "too big". I'm not sure why -- I may have inadvertently included color/underlining. Folks, We just submitted a new draft of 2401bis to the IETF publication folks... In addition to fixes to typos/etc, this revision includes the changes listed below. Although Steve and I discussed most of these changes, he has again maintained plausible deniability by being on vacation when I completed the final edits :-). Please note: 1. On November 12th, Steve Kent requested a poll of the working group to confirm which option we should put into 2401bis for handling of BYPASS'd fragments. However, there wasn't any subsequent poll/consensus as to whether to make the change below that Mark Duffy proposed for Section 7.4 BYPASS/DISCARD traffic, sentence 2, so I didn't change the text. From: An implementation MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. To: An implementation MUST NOT forward fragmented BYPASS traffic without performing stateful fragment checking. 2. All changes below after the 2 rows of ==== were made based on feedback from Russ Housley during the current working group last call. Hence they didn't show up on the list Thank you, Karen =========================================================================== Section 5.1 "Outbound IP Traffic Processing (protected-to-unprotected)" -- restored the following NOTE after step 4. I also inserted some new text saying that "(This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.)" Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. (This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.) The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for more details.) =========================================================================== Appendix B.1 -- clarified text by changing the 2nd sentence: From: In appendix B.1: "The resulting entries that are decorrelated with the decorrelated set of entries are then added to that decorrelated set." To: The nodes of the tree are the selectors that may overlap between the policies. At each node, the algorithm creates a branch for each of the values of the selector. It also creates one branch for the complement of the union of all selector values. Policies are then formed by traversing the tree from the root to each leaf. The policies at the leaves are compared to the set of already decorrelated policy rules. Each policy at a leaf is either completely overridden by a policy in the already decorrelated set and is discarded or is decorrelated with all the policies in the decorrelated set and is added to it. =========================================================================== Section 4.4.1 "The Security Policy Database (SPD)", subsection on "How To Derive the Values for an SAD entry" -- Changed: From: For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. For outbound traffic, there are SPD-S cache entries and SPD-O cache entries. For inbound traffic, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Figure 3 in Section 5.2). To: For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. For outbound traffic, there are SPD-S cache entries and SPD-O cache entries. For inbound traffic not protected by IPsec, there are SPD-I ^^^^^^^^^^^^^^^^^^^^^^ cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Figure 3 in Section 5.2). =========================================================================== Section 7.4 BYPASS/DISCARD traffic and Section D.4 BYPASS/DROP Traffic (last paragraph) -- corrected TCP port 25 (Telnet) to be TCP port 23 (Telnet). =========================================================================== Section 5. "IP Traffic Processing" -- Clarified that the mapping of one cached SPD entry to one SA is not a consequence of decorrelation. Added the following sentences at the end of the paragraph 1: "For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors." Changed paragraph 2, sentence 3 from: But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached and each cached entry will map to exactly one SA, or indicate that matching traffic should be bypassed or discarded, appropriately. To: But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately. =========================================================================== We made the following changes to clarify how the looping of traffic protected by nested SAs is handled if there are multiple SPD-I's Section 5.1 "Outbound IP Traffic Processing (protected-to-unprotected)", step 4 -- Added the following sentences at the end of step 4 (The packet is passed to....): If necessary, i.e., if there is more than one SPD-I, the traffic being looped back MAY be tagged as coming from this internal interface. This would allow the use of a different SPD-I for "real" external traffic vs looped traffic, if needed. Appendix E - "Example of Supporting Nested SAs via SPD and Forwarding Table Entries", paragraph 1 -- Added the following sentence at the end of this paragraph: For simplicity, this example assumes just one SPD-I. =========================================================================== Section 8.2.1 "Propagation of PMTU" -- Modified last sentence to clarify when to send a PMTU ICMP message: From: When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be discarded and an appropriate ICMP PMTU message sent. To: When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be handled as follows: Case 1: Original (cleartext) packet is IPv4 and has the DF bit set. The implementation SHOULD discard the packet and send a PMTU ICMP message. Case 2: Original (cleartext) packet is IPv4 and has the DF bit clear. The implementation SHOULD fragment (before orafter encryption per its configuration) and then forward the fragments. It SHOULD NOT send a PMTU ICMP message. Case 3: Original (cleartext) packet is IPv6. The implementation SHOULD discard the packet and send a PMTU ICMP message. =========================================================================== Section D.3. The Problem of Non-Initial Fragments, -- Since Section 7.2 allows separate SAs to be used for non-initial fragments, we modified the text that said the WG had "rejected" this option: 2nd paragraph, last sentence From: However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA, precisely the solution that the WG rejected. To: However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA. 3rd paragraph, 1st sentence From: In the course of rejecting the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. To: In the course of discussing the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. Section D.6 "Other Suggested Solutions", paragraph 4: From: The Working Group rejected the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the RFC 2401 model via use of OPAQUE port fields, but never clearly articulated in the RFC 2401. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. To: The Working Group rejected an earlier version of the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the RFC 2401 model via use of OPAQUE port fields, but never clearly articulated in the RFC 2401. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. =========================================================================== Section 13 "Differences from RFC 2401" -- Added the following bullet o With respect to IP addresses and ports, the terms "Local" and "Remote" are used for policy rules (replacing source and destination). "Local" refers to the entity being protected by an IPsec implementation, i.e., the "source" address/port of outbound packets or the "destination" address/port of inbound packets. "Remote" refers to a peer entity or peer entities. The terms "source" and "destination" are still used for packet header fields. =========================================================================== Section 5.1 "Outbound IP Traffic Processing (protected to unprotected)" -- Added back the following note after Step 4 NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for more details.) =========================================================================== =========================================================================== All the following changes were suggested by Russ Housley... =========================================================================== =========================================================================== In addition to fixing typos that he caught, we made various edits including but not limited to: 1. Spelled out acronyms -- NAT, ECN, DSCP, TCAM.... 2. Used SA instead of Security Association after initial definition 3. Put in requests to RFC Editor to replace ?? with RFC numbers for the various IDs that are about to become RFCs and which are in the Reference section. 4. Changed all "Note" or "NOTE" to be consistently just one style --> "Note:" 5. Tried to change SPD-I, SPD-O, SPD-S and SPD-ID to use non-breaking hyphens, but I ran into a Microsoft Word glitch with this. So I may have missed some. 6. Replaced "system"/"systems" with "implementation"/"implementations in a number of places 7. Replaced "drop"/"DROP" with "discard"/"DISCARD" for consistency. 8. Replaced "2401bis" with phrases like "this document". =========================================================================== Section 2.1, "Goals/Objectives/Requirements/Problem Description", paragraph 5 -- Changed: From: A set of default cryptographic algorithms for use with AH and ESP is specified in [Eas03] to facilitate interoperability in the global Internet. The use of these cryptographic algorithms.... To: To facilitate interoperability in the global Internet, a set of default cryptographic algorithms for use with AH and ESP is specified in [Eas03] and a set of mandatory-to-implement algorithms for IKEv2 is specified in [Sch03]. [Eas03] and [Sch03] will be periodically updated to keep pace with computational and cryptologic advances. By specifying these algorithms in documents that are separate from the AH, ESP, and IKEv2 specifications, these algorithms can be updated or replaced without affecting the standardization progress of the rest of the IPsec document suite. The use of these cryptographic algorithms... =========================================================================== Section 3.2 "How IPsec Works", paragraph 1, bullet 2 -- changed From: o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers the same set of services, and also offers confidentiality. Use of ESP in a confidentiality-only mode is discouraged. To: o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers the same set of services, and also offers confidentiality. Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED. =========================================================================== Section 4.2 "Security Association Functionality" (changed in the rev to SA Functionality), paragraph 2 -- changed From: For example, both AH and ESP offer integrity and authentication services, but the coverage differs for each protocol and differs for transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 extension header must be protected en-route between sender and receiver, AH can provide this service, except for the mutable (non-predictable) parts of the IP or extension headers..... To: For example, both AH and ESP offer integrity and authentication services, but the coverage differs for each protocol and differs for transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 extension header must be protected en-route between sender and receiver, AH can provide this service, except for IP or extension headers that may change in a fashion not predictable by the sender.... =========================================================================== Section 4.4.1.2 "Structure of an SPD entry", 1st sentence -- Changed to indicate that the ASN.1 in Appendix C is an example, not normative. From: This section contains a prose description of an SPD entry. Also, an ASN.1 definition of an SPD entry is provided in Appendix C. To: This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry. =========================================================================== Section 4.4.1.2 "Structure of an SPD entry", 2nd paragraph, 1st sentence -- Changed: From: This text describes the SPD in a fashion that maps directly into IKE payloads. One should not create SPD entries that cannot be mapped into something that IKE can negotiate. To: This text describes the SPD in a fashion that maps directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. =========================================================================== Section 4.4.1.2 "Structure of an SPD entry", paragraph 3, bullet 1 -- Changed From: o Name -- a list of IDs. This quasi-selector is optional. To: o Name -- a list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name". =========================================================================== Section 4.5 SA and Key Management, first sentence -- Changed as follows From: IPsec mandates support for both manual and automated SA and cryptographic key management. To: All IPsec implementations MUST support both manual and automated SA and cryptographic key management. =========================================================================== Section 8.2.2 "PMTU Aging", paragraph 1 -- Changed as follows: From: In all IPsec implementations the PMTU associated with an SA MUST be "aged" and some mechanism is required to update the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it should be, To: In all IPsec implementations the PMTU associated with an SA MUST be "aged" and some mechanism is required to update the PMTU in a timely manner, especially for discovering if the PMTU is smaller than required by current network conditions. =========================================================================== Section 13. "Differences from RFC 2401" -- Changed as follows: From: o Support for AH in both IPv4 and IPv6 is now a MAY. To: o Support for AH in both IPv4 and IPv6 is no longer required. Deleted redundant bullet: o Text and an ASN.1 desription have been added to clarify the structure of an SPD entry and its alignment with what can be negotiated in IKEv2. =========================================================================== Appendix C -- ASN.1 for an SPD Entry -- made about a dozen corrections and changes. It should compile. Let me know if you want the details. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 09:25: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 JAA16734 for ; Mon, 6 Dec 2004 09:25:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbJlf-0006Tj-JR; Mon, 06 Dec 2004 09:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbJgC-000374-Nj for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 09:17:33 -0500 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 JAA16334 for ; Mon, 6 Dec 2004 09:17:30 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbJmZ-000630-Hu for ipsec@ietf.org; Mon, 06 Dec 2004 09:24:07 -0500 Received: from hyperthought.com (c-24-6-205-175.client.comcast.net[24.6.205.175]) by comcast.net (sccrmhc11) with SMTP id <2004120614164701100gqjsbe>; Mon, 6 Dec 2004 14:16:48 +0000 Message-ID: <41B4690B.9050509@hyperthought.com> Date: Mon, 06 Dec 2004 06:13:31 -0800 From: "Scott G. Kelly" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mohanlal jangir Subject: Re: [Ipsec] IPSec use with Diameter References: <011301c4db5f$67a15960$3d476c6b@sisodomain.com> In-Reply-To: <011301c4db5f$67a15960$3d476c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 mohanlal jangir wrote: > Here is one paragraph from RFC 3588 (Diameter Base Protocol): > > "Note that IPsec is considerably less flexible than TLS when it comes to > configuring root CAs. Since use of Port identifiers is prohibited within IKE > Phase 1, within IPsec it is not possible to uniquely configure trusted root > CAs for each application individually; the same policy must be used for all > applications. This implies, for example, that a root CA trusted for use with > Diameter must also be trusted to protect SNMP. These restrictions can be > awkward at best. > Since TLS supports application-level granularity in certificate policy, TLS > SHOULD be used to protect Diameter connections between administrative > domains. IPSec is most appropriate for intra-domain usage when pre-shared > keys are used as a security mechanism." > > Can someone explain more about this? It's wrong. Granted, the original IPsec RFC's were not very clear on how you configure something like this, but what is discussed above is an implementation problem probably resulting from a design decision to only permit one IKE SA between a given endpoint pair. It has always been possible to use granular per-port policies, and if a particular implementation does not support this, it's not because of a restriction in the IPsec standard. Scott _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 6 16:35: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 QAA27073 for ; Mon, 6 Dec 2004 16:35:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbQTk-00040T-MU; Mon, 06 Dec 2004 16:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbQSY-0003Xc-8j for ipsec@megatron.ietf.org; Mon, 06 Dec 2004 16:31:54 -0500 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 QAA26839 for ; Mon, 6 Dec 2004 16:31:51 -0500 (EST) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbQYv-00089W-2l for ipsec@ietf.org; Mon, 06 Dec 2004 16:38:32 -0500 Received: by mx2.trusecure.com (Postfix, from userid 1006) id 0416CC933E; Mon, 6 Dec 2004 16:31:08 -0500 (EST) Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.trusecure.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id E7C3EC91DB; Mon, 6 Dec 2004 16:31:07 -0500 (EST) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.trusecure.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id iB6LV7DW010666; Mon, 6 Dec 2004 16:31:07 -0500 (EST) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 16:31:09 -0500 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: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis Date: Mon, 6 Dec 2004 16:31:05 -0500 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F5A7AE8E@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis Thread-Index: AcTCyakYvsF9srTZTiqY+dCGKi7RbAZCxF8gAAGDRaA= From: "Zimmerman, Mark" To: "Michael Richardson" X-OriginalArrivalTime: 06 Dec 2004 21:31:09.0191 (UTC) FILETIME=[E6A17170:01C4DBDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Michael, Per your and Tero's (and other developers) suggestion I've=20 extended the timetable for the IKEv2 Interoperability Workshop (bakeoff) being held in Santa Clara an extra day. So the facilities, infrastructure and security will be available until Friday February 25th 2005 5:00PM URL for details: www.icsalabs.com/html/communities/ipsec/bakeoff/registration.html Regards, -----BEGIN PGP SIGNED MESSAGE----- Hi, as many of you know Connectathon occurs in late february 2005. ICSA is having a bakeoff very close by, a couple of days earlier. (Maybe they will actually combine forces, I don't know). While it seems that we can depend upon Connectathon 2006 occuring,=20 I think that IKEv2 implementors may need another event near the end of the summer, early fall. One thought is that maybe ETSI would organize something the week after the Paris IETF. I'm personally not crazy about that for various personal reasons, and I think that August IETFs are a bad idea anyway. (Maybe all of france will be on vacation then too...) I just wanted to plant the idea of having some kind of event in late September, early October 2005.=20 As a final idea, having it around the November 2005 IETF is okay, but probably too long between events. - -- ] "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 iQCVAwUBQYpS7oqHRg3pndX9AQG0xQP/cHnvO4FMXooNqC0X67yfOf4lwDMMIQ/5 tHi0F3Zoaa7PeesI5dPEeuiIT1MM4+Vxx8/huIO8fKn2PfFHEnEv/L28GED6bUvw WP9gbuIQ0fLJYPlRJNaKt0lmrtJJToKcVl6vSIQsaRFh9zV0139SvBt3pW1rCs5m a5OZatQMMPQ=3D =3Dtrp2 -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 7 05:26: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 FAA09602 for ; Tue, 7 Dec 2004 05:26:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbcKu-0006DD-5h; Tue, 07 Dec 2004 05:12:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbcFP-0005JL-3G for ipsec@megatron.ietf.org; Tue, 07 Dec 2004 05:07:07 -0500 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 FAA08339 for ; Tue, 7 Dec 2004 05:07:04 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbcLv-0006xU-HO for ipsec@ietf.org; Tue, 07 Dec 2004 05:13:53 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iB7A6tG0003094 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Dec 2004 12:07:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iB7A6q4Q003090; Tue, 7 Dec 2004 12:06:52 +0200 (EET) 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: <16821.32955.543884.461839@fireball.kivinen.iki.fi> Date: Tue, 7 Dec 2004 12:06:51 +0200 From: Tero Kivinen To: "Michael Richardson" Subject: [Ipsec] Initial Contact messages In-Reply-To: <31751.1102225358@marajade.sandelman.ottawa.on.ca> References: <31751.1102225358@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 58 min X-Total-Time: 68 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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 Michael Richardson writes: > INITIAL_CONTACT 16384 > > This notification asserts that this IKE_SA is the only > IKE_SA currently active between the authenticated > identities. It MAY be sent when an IKE_SA is established > after a crash, and the recipient MAY use this information to > delete any other IKE_SAs it has to the same *AUTHENTICATED > IDENTITY* without waiting for a timeout. This notification > MUST NOT be sent by an entity that may be replicated (e.g., > a roaming user's credentials where the user is allowed to > connect to the corporate firewall from two remote systems at > the same time). > It is difficult for an entity to know if the credentials may be replicated. > So, to some extent, we assume that it will be difficult in practice to > configure the client correctly here. Unless the configuration says this might be replicated, the implmentation should send initial contact notifications. If it is not known whether this is replicated or not, then it is not replicated (i.e. local end should know all cases where your local ID is replicated). There is NOTHING in the text which says that you are should be ignoring those notifications ever. Even if you are replicated node or something, if someone sends you INITIAL_CONTACT notification you should process is normally (provided you support INITIAL_CONTACT notifications at all, the whole notify processing is optional). If someone ignores INITIAL_CONTACT notifications, I would report it as a bug in the implementation. The text above talks about when you MUST NOT SEND the notification. Remember this when implementing the code. It does NOT talk about receiving case in the last sentence. Most of the replicated cases, are not really replicated cases, and they can be avoided, simply by adding another identity for the user. I.e if he wants to use multiple connections at same time, like pda, laptop and home machine, he needs one identity for his laptop, one identity for his pda and one identity for his home machine. In this case there will not be replicated identities, thus initial contact should be sent. Also if he is using smartcard or securid card or any other physical token, that token can only be used in one connection, thus in that case it is not replicated either. I.e. if he removes the smartcard from his pda and inserts it to the laptop, the connections to the pda should be disconnected when the laptop connects. > A lot of the discussion dealt with what an *AUTHENTICATED IDENTITY* is. > Particularly in the context of XAUTH users with group-psk. There is no XAUTH with IKEv2. There is no group-psk in the IKEv2. There SHOULD NOT be any group-psk in the IKEv1 case either, but as there are, then there better be different identity for each user (i.e. the psk is same, but the identity inside the negotiation should be different for each user). > Below, Ix is the PARENT SA Identity. ID_i. > Note that we consider the 4-tuple of SA/DA, SP/DP because we assume that > there may be NATs in between. > > 1) a multiuser system H1, creates two parent SAs because it needs to > authenticate as two different identities. > > +-------+ +-------+ > |H1 I1|<--------------------------->| I3 H2| > | I2| | | > +-------+ +-------+ > > We believe that H1 *MAY* send IC on each connection. > For this reason it may be that H2 must look at identity *ONLY* when > deciding which old SAs to flush. 4-tuple is not unique. Yes. This is correct, only use ID to find SAs. > 2) a single user system H1, connecting to a gateway H2, shutting > down/suspending, and returning on another IP: > > > .--------. > | I1 H1 |<------------\ .-------. > | | \ | | > '--------' ------------->| | > - ---- time ---- | H2 | > .--------. /-------------->| | > | I1 H1 |<-----------/ | | > | | '-------' > '--------' > > In this case, the 4-tuple is unique, but in addition, the ID being the > same is works to find the appropriate SAs. Again H2 should use only the ID to find the SAs. > 3) two single user systems, using XAUTH, having "Group PSK" I1. > Different user names. > > .--------. > | I1 H1 |<------------\ .-------. > | user1 | \ | | > '--------' ------------->| | > | H2 | > .--------. /-------------->| | > | I1 H2 |<-----------/ | | > | user2 | '-------' > '--------' > > In this case, if H2 combines the 4-tuple with the Ix, then H2 can find > SAs before XAUTH is done. Alternatively, H2 can wait until the XAUTH has > been done before it processes the initial contact. The ID used inside the IKEv1 main mode exchange should be different, and that is the only thing that should be used to identify the user in the H2. Note, there is no reason why the ID in the IKEv1 main mode should be same if the PSK happens to be same for both users. The reason we have the PSK same for all users in the IKEv1 main mode, is because the IKEv1 encrypts the ID with the PSK, thus you do not know the ID before, and you need to select proper PSK before knowing the ID. After we have selected the PSK and can decrypt the ID, we can use that to select which SAs to delete. And, yes, any member of the group having the group PSK can delete all SAs for any other users, but he can do quite a lot more also, like claim to be H2 and authenticate itself to the H1 as a H2, and listen all traffic between. This is simply the property of the group PSK. So if you are using the group PSK, all the members in the group DO have identical security properties, and everybody in the group can listen all others traffic and modify it at will. You better trust each of the members in the group... Doing XAUTH after group PSK does not change a situation at all, as it does not any way tie the authentication to the IKE SA, thus attacker can simply forward the XAUTH forward (or at least it used to be that when I last time checked the protocol, and cannot check it now as there is no draft about it). > 4) two single user systems, using XAUTH, having "Group PSK" I1. > The same user names. This is, for instance, the situation where > a single person wants their laptop and their PDA to be online. > > .--------. > | I1 H1 |<------------\ .-------. > | user1 | \ | | > '--------' ------------->| | > | H2 | > .--------. /-------------->| | > | I1 H2 |<-----------/ | | > | user1 | '-------' > '--------' > > H2 can determine uniqueness here by combining 4-tuple, ID and username. > Arguably, in this situation IC should not be sent if the IDs are known > to be combined. The user should have two identities one for the laptop and one for the pda in this case, i.e. something like kivinen+laptop@safenet-inc.com and kivinen+pda@safenet-inc.com. There is no reason why he should have same ID in those cases. So H2 can again use only the ID to distinguish the SAs to remove. > {In addition, situation (1) could be combined with any of the other > situations} Does not change a thing there. The only case where you want to share the IDs and authentication information is some kind of high availibity systems where you have shared IPsec SAs state between two nodes, but you do not have shared IKE SA state (i.e. you need to recreate IKE SAs after the one node goes down, but you can still continue using the old IPsec SAs (they might be on the actual ethernet card and the IKE is run on two different blade cards on the system, and the master card of those just crashed)). In all of the above cases some people will not want to switch to use separate IDs even when there is no reason why not, so that is also another reason why they might to configure their own end (i.e. the initiator) so that it does not send initial contact notifications. > There are as many as 6 items that may be used to index into the SA table > to do IC processing. There was concern that it may not be possible to > build an index that provides better than linear search given the > differences. Nope. The only thing needed is the ID, and nothing else. If you use anything else you break NAT-T, and address agility of the IKEv2. > There was extension discussion that liveness checks (dead peer > detection) will in most cases clean up all stale SAs. There was > discussion about whether it would in fact clean up in all situations. In IKEv2, yes, the dead peer detection will eventually clean up the state, but that means there will be traffic going to the black hole for couple of minutes, which is not really very nice. Initial contact will take care of the recover in seconds instead of minutes. Note, that IKEv2 dead peer detection will remove SAs if and only if there is no reply back from the other node after multiple retransmissions, and after the time out. It says that about at least a dozen retries over at least several minutes before giving up (section 2.4 in draft-ietf-ipsec-ikev2-17.txt). > {Most of these issues are not unique to IKEv2. However, XAUTH usage has > not generally been useable across vendors in IKEv1. ICSA IPSec 2.0 does > not test XAUTH in IKEv2 (or IKEv1). } IKEv2 do not have XAUTH, so that is only for IKEv1. Also there is no reason to use group PSK in the IKEv2 at all, so all points suggesting that are non issues for IKEv2. > The suggestion was a heuristic that said that IC processing should be > done by looking up 4-tuple only. If only 2 Parent SAs were found (i.e. the > current one, and 1 old one), then the old one should be purged (with all > of its children). No. In the initiator side you first check whether you have SAs with the node you are connecting to. If you do not have any IKE SAs for the ID you are connecting to, and your local ID is not marked as replicated, you send INITIAL_CONTACT notification. On the responder side you do the same thing, i.e. when you receive ID you check whether you have IKE SAs with the other end, and if not, and the your local ID is not configured to be replicated you send the INITIAL_CONTACT notification. Whenever you receive INITIAL_CONTACT notification you process that normally, i.e. you simply search for the IKE SA matching the ID pair of the new IKE SA, and remove those. There is no point of checking anything else, and if the other end claims that his ID is not replicated (by sending INITIAL_CONTACT) and that he does not have any SAs with you, you can simply trust him and delete the SAs. The local end sending out the INITIAL_CONTACT should be the one who knows whether his local ID is replicated or not. It is completely possible that the initiator do not send INITIAL_CONTACT notifications because he knows there is replicated node for him, but the responder do send it as he knows he is the only node, and there is no SAs with the ID connecting. If the initiator then had SAs with the responder ID before, he can clear them out, as responder do not have them anymore. The other way around is not normally very useful, as if the initiator sends INITIAL_CONTACT notification, it really does not matter whether responder sends INITIAL_CONTACT notification to the initiator or not, as the initiator does not have any SAs with responder (initiator just claimed so by sending INITIAL_CONTACT notification). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 8 16:58: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 QAA10632 for ; Wed, 8 Dec 2004 16:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9ZU-00007c-Ff; Wed, 08 Dec 2004 16:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9DC-0007gp-37; Wed, 08 Dec 2004 16:19:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04353; Wed, 8 Dec 2004 16:18:59 -0500 (EST) Message-Id: <200412082118.QAA04353@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Dec 2004 16:18:59 -0500 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2402bis-10.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 : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-10.txt Pages : 34 Date : 2004-12-8 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-10.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-rfc2402bis-10.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-rfc2402bis-10.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-12-8164802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-8164802.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 Wed Dec 8 17:04: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 RAA11750 for ; Wed, 8 Dec 2004 17:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9is-0006ps-JG; Wed, 08 Dec 2004 16:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9DP-0007ty-KA; Wed, 08 Dec 2004 16:19:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04360; Wed, 8 Dec 2004 16:19:13 -0500 (EST) Message-Id: <200412082119.QAA04360@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Dec 2004 16:19:13 -0500 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2401bis-05.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-05.txt Pages : 92 Date : 2004-12-8 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 obsoletes RFC 2401 (November 1998). Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: Please remove this line prior to publication as an RFC.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.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-05.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-05.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-12-8164808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-8164808.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 Wed Dec 8 17:52: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 RAA19035 for ; Wed, 8 Dec 2004 17:52:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcAJG-0003IL-Tr; Wed, 08 Dec 2004 17:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9ud-0000Tz-Ih; Wed, 08 Dec 2004 17:03:55 -0500 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 RAA11637; Wed, 8 Dec 2004 17:03:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcA1U-0001mQ-8N; Wed, 08 Dec 2004 17:11:00 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cc9iJ-0006J6-Qz; Wed, 08 Dec 2004 16:51:11 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Dec 2004 16:51:11 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipsec@ietf.org Subject: [Ipsec] Last Call: 'Security Architecture for the Internet Protocol' 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 IP Security Protocol WG to consider the following document: - 'Security Architecture for the Internet Protocol ' 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-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 10 00:23: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 AAA25465 for ; Fri, 10 Dec 2004 00:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcdBq-0005eE-PT; Fri, 10 Dec 2004 00:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccd8y-0003wM-Ju for ipsec@megatron.ietf.org; Fri, 10 Dec 2004 00:16:40 -0500 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 AAA25142 for ; Fri, 10 Dec 2004 00:16:38 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcdG6-0003w0-CA for ipsec@ietf.org; Fri, 10 Dec 2004 00:24:02 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Thu, 09 Dec 2004 22:16:09 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Date: Thu, 09 Dec 2004 22:15:52 -0700 From: "Umasankar Mukkara" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Ipsec] IPSEC MIB 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: 7bit Which is the suggested standard for ipsec monitoring. I guess the draft draft-ietf-ipsec-monitor-mib-06.txt is expired/dead. Is there any effort going on in this direction. Can you please point to the draft MIBs that many vendors are using for ipsec monitoring? Thanks, Uma. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 13 21:49: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 VAA21419 for ; Mon, 13 Dec 2004 21:49:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2gG-0003QQ-LZ; Mon, 13 Dec 2004 21:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2cK-0002ud-DW for ipsec@megatron.ietf.org; Mon, 13 Dec 2004 21:40:48 -0500 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 VAA20919 for ; Mon, 13 Dec 2004 21:40:46 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce2kG-0001l9-8C for ipsec@ietf.org; Mon, 13 Dec 2004 21:49:00 -0500 Received: from [10.84.131.44] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBE2e2jr022515; Mon, 13 Dec 2004 21:40:14 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <011301c4db5f$67a15960$3d476c6b@sisodomain.com> References: <011301c4db5f$67a15960$3d476c6b@sisodomain.com> Date: Mon, 13 Dec 2004 21:38:38 -0500 To: mohanlal jangir From: Stephen Kent Subject: Re: [Ipsec] IPSec use with Diameter 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 12:17 PM +0530 12/6/04, mohanlal jangir wrote: >Here is one paragraph from RFC 3588 (Diameter Base Protocol): > >"Note that IPsec is considerably less flexible than TLS when it comes to >configuring root CAs. Since use of Port identifiers is prohibited within IKE >Phase 1, within IPsec it is not possible to uniquely configure trusted root >CAs for each application individually; the same policy must be used for all >applications. This implies, for example, that a root CA trusted for use with >Diameter must also be trusted to protect SNMP. These restrictions can be >awkward at best. >Since TLS supports application-level granularity in certificate policy, TLS >SHOULD be used to protect Diameter connections between administrative >domains. IPSec is most appropriate for intra-domain usage when pre-shared >keys are used as a security mechanism." > >Can someone explain more about this? > >Regards >Mohanlal > I think there is some confusion here, on several fronts: - TLS says nothing about cert management; TLS provides facilities for transporting certs. HTTPS is the relevant standard re cert management in this context, and I don't think it says anything about configuring root CAs ("trust anchors" in PKIX terminology) on a per-application basis. - RFC 2401, like TLS, says nothing about cert management in the way described above. 2401bis added the notion of the PAD, and I have recently provided text on PAD details to the PKI4IPSEC WG. That text provides means for restricting the scope of a trust anchor, and that could be used to constrain the set of SPD entries that are used with a given TA, which might be used to provide per-application TA bindings. I am appalled by the text cited above. It's just wrong, including the misspelling of "IPsec!" Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 13 21:52: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 VAA21834 for ; Mon, 13 Dec 2004 21:52:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2gH-0003Qo-HI; Mon, 13 Dec 2004 21:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2cZ-0002uj-B4 for ipsec@megatron.ietf.org; Mon, 13 Dec 2004 21:41:03 -0500 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 VAA20948 for ; Mon, 13 Dec 2004 21:41:01 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce2kV-0001lH-10 for ipsec@ietf.org; Mon, 13 Dec 2004 21:49:15 -0500 Received: from [10.84.131.44] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBE2e2k5022515; Mon, 13 Dec 2004 21:40:22 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041204155253.M77942@ec.iut.ac.ir> References: <20041204155253.M77942@ec.iut.ac.ir> Date: Mon, 13 Dec 2004 21:38:38 -0500 To: "mahdavi" From: Stephen Kent Subject: Re: [Ipsec] 3 modes of defining tunnels in SPD. 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: 2086112c730e13d5955355df27e3074b 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 7:28 PM +0330 12/4/04, mahdavi wrote: >Hi Dear Experts. >I have asked this question before but got no answer. So I ask it again because >we can not decide which is correct. > >the question is as follows. > >I am working on a high speed secure router and there is >something that I cant Understand what to do with it. > >and that is these mysterious sentences. (I call these >as Case A and Case B ) I would have responded to the first version of your message if it were better worded, included specific references to 2401 sections that you find confusing, rather than requiring me to find the references, etc. > >" a. use the value in the packet itself -- This will limit use > of the SA to those packets which have this packet's value > for the selector even if the selector for the policy entry > has a range of allowed values or a wild card for this > selector. > b. use the value associated with the policy entry -- If this > were to be just a single value, then there would be no > difference between (b) and (a).,......" this text is from section 4.4.1, bottom of page 15. it is describing two ways that an SPD entry can be configured, the former is what we refer to in 2401bis as "populate from packet." > >Imagine a router that is IPSec aware (SG1). the correct spelling is IPsec, NOT IPSec, according to 2401, 2402, ... >HOST HOST >C to K=========|1| SG1 |2|=======================SG2 --- M to X > | / \ / > | / \ / > \-------------/ \------------------------/ > >SG1 has two interfaces 1 and 2 . > >outbound policy for interface 2 of SG1 says : > >-------------------------------------------------------- >For any packet from host (C to k) going to host (M to X) >make a tunnel with SG2. USE CASE B >-------------------------------------------------------- I have no idea what the symbols used here mean, i.e., "C to K" and "M to X." >This means to use one SA for all traffic traversing from (C - K) TO ( M - X ). >Right? I assume you are trying to say that you want to support a policy that maps all traffic between ANY host behind SG1 to ANY host behind SG2 to ONE SA. Yes, that is a valid policy that can be expressed in the SPD. > >What about this policy? > >-------------------------------------------------------- >For any packet from host (C to k) going to host (M to X) >make a tunnel with SG2. USE CASE A >-------------------------------------------------------- as above, this use of symbols is mysterious, at best. > >What that means? Does it mean to make separate SA's for any source-destination >pair ? >For example one for a packet traversing from C to M and one another for a >packet giong from D to N and one another for a packet going from C to N ??? > >If so what is benefit of this ??? one may also configure the SPD so that each pair of hosts, one behind each SG, will get a different SA for its traffic. OR, one can have a different SA for ALL traffic from one host behind SG1 to ALL hosts behind SG2. There are also options for other granularities of SAs. >__________________________________________________________ >__________________________________________________________ >Question 2: > >Before, I thought that Case A Is not usable in this situation and >this situation should be used with case b. Was Right ? I can't parse this sentence. >__________________________________________________________ >__________________________________________________________ >Question 3: > >Can we have such a policy like below for inbound traffic for >interface 1 of SG1? ibid. >For inbound traffic for interface 1 of SG1 : (this is just one policy record) > >-------------------------------------------------------- >For any packet from host (C to k) going to host (M to X) >make a tunnel with ITSELF (SOURCE OF Packet). >-------------------------------------------------------- ibid. >In above policy because we wanted to have one policy for many tunnels >(in this case 9 tunnels each for each host C - K ) and ITSELF means having a >tunnel with source of packet host. ibid. >Firstly, having such a policy is logical??? >Secondly, does it mean Case A??? ibid. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 13 22:42: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 WAA24879 for ; Mon, 13 Dec 2004 22:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce3Pc-0000Sr-L2; Mon, 13 Dec 2004 22:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce3Ow-0000Gk-AE for ipsec@megatron.ietf.org; Mon, 13 Dec 2004 22:31:02 -0500 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 WAA24161 for ; Mon, 13 Dec 2004 22:31:00 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce3Ws-0002on-6p for ipsec@ietf.org; Mon, 13 Dec 2004 22:39:14 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id iBE3UUJr072979 for ; Tue, 14 Dec 2004 12:30:30 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Received: from jp.yokogawa.com (fumi.local.ini.jp [10.21.254.6]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id iBE3UUEn052382 for ; Tue, 14 Dec 2004 12:30:30 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Message-ID: <41BE6080.1070504@jp.yokogawa.com> Date: Tue, 14 Dec 2004 12:39:44 +0900 From: Nobumichi Ozoe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Ipsec] [Reminder] 6th TAHI IPv6 Interoperability Test Event - 24 - 28 January 2005, Chiba, Japan 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 Dear All, This is a reminder that TAHI Projcet is organizing its 6th TAHI IPv6 Interoperability Test Event. The event will be held from 24th - 28th January 2005 at the Makuhari messe of Chiba Japan. Registration is avairable at: http://www.tahi.org/inop/6thinterop.html Deadline to register is 31 December 2004. !!! Early registration discount is untill 17 December 2004 !!! This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO Basic Support(MR), IKEv1, SNMP, MIB, SIP(terminal test), IPv6 Core Protocol, IPsec, MLDv1, Default Address Selection, Default Router Preference, RIPng, NAT-PT, 6to4 o Interoperability test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO Basic Support, SIP, IPv6 Core Protocol, IPsec, IKEv1/v2, Prefix Delegation, MLDv2 For more details, please visit our web site. * TAHI Project Home Page http://www.tahi.org/ * 6th TAHI IPv6 Interoperability Test Event Announce Page http://www.tahi.org/inop/6thinterop.html #I'm sorry if you have already received this mail. Regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 14 11:24: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 LAA16939 for ; Tue, 14 Dec 2004 11:24:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFQS-0007vy-7o; Tue, 14 Dec 2004 11:21:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFJx-0005JI-S4 for ipsec@megatron.ietf.org; Tue, 14 Dec 2004 11:14:41 -0500 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 LAA16174 for ; Tue, 14 Dec 2004 11:14:37 -0500 (EST) Received: from [217.219.18.2] (helo=cc.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFRx-0005j9-3F for ipsec@ietf.org; Tue, 14 Dec 2004 11:22:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id AED6F2C804E; Tue, 14 Dec 2004 19:40:41 +0330 (IRT) Received: from cc.iut.ac.ir ([127.0.0.1]) by localhost (cc.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11130-01; Tue, 14 Dec 2004 19:40:41 +0330 (IRT) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id 56FDF2C8041; Tue, 14 Dec 2004 19:40:27 +0330 (IRT) From: "mahdavi" To: Stephen Kent Subject: Re: [Ipsec] 3 modes of defining tunnels in SPD. Date: Tue, 14 Dec 2004 19:40:27 +0330 Message-Id: <20041214160932.M35185@ec.iut.ac.ir> In-Reply-To: References: <20041204155253.M77942@ec.iut.ac.ir> X-Mailer: Open WebMail X-OriginatingIP: 193.251.135.126 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: by amavisd-new at cc.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Hi Steve. Thank you for your kind reply and I should appologize for my weak english. I have reworded my queation as follows: Consider the following network: (C - K)-----SG---Internet----(M - X) SG is an IPsec aware gateway. (C-k) and (M-X) are ranges of hosts or gateways. Consider the following policy in SG: _______________________________________________________ For all incomming traffic from (C-K) going to (M-X) make tunnel between SG and the destination of packets. _______________________________________________________ Is it a correct policy according to "case a" (from section 4.4.1, bottom of page 15 from RFC 2401)? If so, does it means that seperate tunnels between SG and each node in range (M-X) should be stablished? Best regards Mahdavi. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 15 13: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 NAA25608 for ; Wed, 15 Dec 2004 13:30:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cedbs-00065v-Qz; Wed, 15 Dec 2004 13:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CedNa-0001to-1B for ipsec@megatron.ietf.org; Wed, 15 Dec 2004 12:56:02 -0500 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 MAA22661 for ; Wed, 15 Dec 2004 12:55:58 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CedVp-0004f8-B0 for ipsec@ietf.org; Wed, 15 Dec 2004 13:04:34 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBFHtxdt012638 for ; Wed, 15 Dec 2004 10:55:59 -0700 (MST) 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 iBFHtwJf004378 for ; Wed, 15 Dec 2004 10:55:58 -0700 (MST) 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 iBFHt2Zt172568 for ; Wed, 15 Dec 2004 11:55:02 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iBFHt2uv172567 for ipsec@ietf.org; Wed, 15 Dec 2004 11:55:02 -0600 (CST) Resent-Message-Id: <200412151755.iBFHt2uv172567@binky.central.sun.com> Date: Wed, 15 Dec 2004 06:04:28 -0600 From: Nicolas Williams To: ietf@ietf.org Message-ID: <20041215120428.GS135801@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Resent-From: Nicolas.Williams@sun.com Resent-Date: Wed, 15 Dec 2004 11:55:02 -0600 Resent-To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] "connection latching" -- comments on rfc2401bis (draft-ietf-ipsec-rfc2401bis-04.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 "Connection latching" is a simple concept: connections, for connection- oriented protocols, such as TCP or SCTP, that are run over IPsec should be 'bound' to the same quality of protection parameters and initiator and responder IDs for their duration. IOW, the SPD should be modified dynamically as a TCP (or SCTP) connection is attempted/connected/torn down so that during its lifetime the connection's IP packets are protected only with comparable SAs. The more I think about it, the more I think that "connection latching" a) seems very much related to the "populate from packet" feature of 2401bis, b) should be an integral part of the IPsec architecture, c) is absolutely necessary in situations where applications drive policy (e.g., through IPsec APIs), particularly where GSS-API and other channel binding to IPsec is to be used. BTW, and for full disclosure, there exist implementations of this concept, in Solaris 9 and 10, for example. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 16 17:19: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 RAA19276 for ; Thu, 16 Dec 2004 17:19:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf3tV-0006ZF-P1; Thu, 16 Dec 2004 17:14:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf3m4-0004th-T2 for ipsec@megatron.ietf.org; Thu, 16 Dec 2004 17:07:05 -0500 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 RAA17863 for ; Thu, 16 Dec 2004 17:07:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf3ua-000301-I2 for ipsec@ietf.org; Thu, 16 Dec 2004 17:15:53 -0500 Received: from [192.168.1.84] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBGM6Djf000702; Thu, 16 Dec 2004 17:06:15 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041214160932.M35185@ec.iut.ac.ir> References: <20041204155253.M77942@ec.iut.ac.ir> <20041214160932.M35185@ec.iut.ac.ir> Date: Thu, 16 Dec 2004 14:13:17 -0500 To: "mahdavi" From: Stephen Kent Subject: Re: [Ipsec] 3 modes of defining tunnels in SPD. 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 7:40 PM +0330 12/14/04, mahdavi wrote: >Hi Steve. >Thank you for your kind reply and I should appologize for my weak english. > >I have reworded my queation as follows: > >Consider the following network: > >(C - K)-----SG---Internet----(M - X) > >SG is an IPsec aware gateway. (C-k) and (M-X) are ranges of hosts >or gateways. > >Consider the following policy in SG: > >_______________________________________________________ >For all incomming traffic from (C-K) going to (M-X) make tunnel >between SG and the destination of packets. >_______________________________________________________ > >Is it a correct policy according to "case a" (from section 4.4.1, bottom of >page 15 from RFC 2401)? A compliant IPsec implementation will let you create an SPD entry that matches the "case a" example, what we now call "populate from packet" in 2401bis. so, yes, this a valid policy. (I would not use the term "correct" here since whether the policy is correct or not is a function of what you want to accomplish.) >If so, does it means that seperate tunnels between SG and each node in range >(M-X) should be stablished? If you populate the SAD entries based on BOTH the source and destination addresses, then you will get a distinct SA for each pair of communicating hosts in the C-K and M-X ranges. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 21 00:53: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 AAA19131 for ; Tue, 21 Dec 2004 00:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgctK-0003qJ-GZ; Tue, 21 Dec 2004 00:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgcsD-0003eF-Gi for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 00:47:54 -0500 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 AAA18877 for ; Tue, 21 Dec 2004 00:47:50 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cgd1c-00017Z-Bs for ipsec@ietf.org; Tue, 21 Dec 2004 00:57:36 -0500 Received: from brahma.intotoind.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2004122021464525143 for ; Mon, 20 Dec 2004 21:46:45 -0800 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 iBL5kxmK028927 for ; Tue, 21 Dec 2004 11:17:00 +0530 Message-Id: <5.1.0.14.0.20041221100442.00a7a2f0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 Dec 2004 11:15:33 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Ipsec] Rekeying IKE 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: , Content-Type: multipart/mixed; boundary="===============1499199410==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1499199410== Content-Type: multipart/alternative; boundary="=====================_258840829==_.ALT" --=====================_258840829==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, I have some doubts regarding the Rekeying of IKE SA. SG1==============SG2. Initially SG1 initiated IKE Exchange and IKE SA and CHILD SAs are established. If the SG2 (responder of IKE SA ) initiated the CREATE_CHILD_SA exchange to establish new IKE SA keys, how do we know who will be the initiator for the new IKE SA (SG1 or SG2) ?? If it is SG1, that means we will be negotiating the responder nonce, KEr and responder SPI in CREATE_CHILD_SA request. So, in Key material calculation, what SPI and what nonce should be used as initiator SPI and initiator nonce?? Please clarify my doubt. Thanks in advance, Jyothi --=====================_258840829==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,


I have some doubts regarding the Rekeying of IKE SA.

SG1==============SG2.

Initially SG1 initiated IKE Exchange and IKE SA and CHILD SAs are established.

If the SG2 (responder of IKE SA ) initiated the CREATE_CHILD_SA exchange to establish new IKE SA keys, how do we know who will be the initiator for the new IKE SA (SG1 or SG2) ??

If it is SG1,
   that means we will be negotiating  the responder nonce, KEr and responder SPI  in CREATE_CHILD_SA request.

So, in Key material calculation, what SPI and what nonce should be used as initiator SPI and initiator nonce??

Please clarify my doubt.
 

Thanks in advance,
Jyothi
--=====================_258840829==_.ALT-- --===============1499199410== 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 --===============1499199410==-- From ipsec-bounces@ietf.org Tue Dec 21 01:01: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 BAA19725 for ; Tue, 21 Dec 2004 01:01:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgd46-0005su-R1; Tue, 21 Dec 2004 01:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgd0Y-0005CQ-1U for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 00:56:30 -0500 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 AAA19326 for ; Tue, 21 Dec 2004 00:56:26 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cgd9x-0001Kx-7q for ipsec@ietf.org; Tue, 21 Dec 2004 01:06:13 -0500 Received: from brahma.intotoind.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2004122021553925156 for ; Mon, 20 Dec 2004 21:55:39 -0800 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 iBL5trIc030441 for ; Tue, 21 Dec 2004 11:25:54 +0530 Message-Id: <5.1.0.14.0.20041215192611.03d08300@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 Dec 2004 11:24:27 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.8 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Ipsec] extraction of CHILD SA keys from the key material 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="===============1843524788==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1843524788== Content-Type: multipart/alternative; boundary="=====================_259375009==_.ALT" --=====================_259375009==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >Hi, > >I would like to know the order of extraction of CHILD SA keys from the >key material(KEYMAT) in case ESPwith AUTH and AH . As per section 2.17 draft-ietf-ipsec-ikev2-17, ( If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet.) I would like whether the following order is right or not. >Initiator side: > > KEYMAT = { outbound AH key | outbound ESP encryption key | > outbound ESP auth key | > inbound AH key | inbound ESP encryption key | > inbound ESP auth key } > >Responder side: > > KEYMAT = { |inbound AH key | inbound ESP encryption key | inbound > ESP auth key | > outbound AH key | outbound ESP encryption key | outbound > ESP auth key > } Awaiting your valuable responses. >Thanks in advance, >Jyothi --=====================_259375009==_.ALT Content-Type: text/html; charset="us-ascii"
Hi,

I would like to know  the order of extraction of CHILD SA keys from the key material(KEYMAT) in case ESPwith AUTH and AH .

As per section 2.17 draft-ietf-ipsec-ikev2-17,

(      If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.)

I would like whether the following order is right or not.

Initiator side:
        
        KEYMAT = { outbound AH key | outbound ESP encryption key | outbound ESP auth key |

                        inbound AH key | inbound ESP encryption key | inbound ESP auth key }

Responder side:

        KEYMAT = { |inbound AH key | inbound ESP encryption key | inbound ESP auth key |
                outbound AH key | outbound ESP encryption key | outbound ESP auth key
                              }


Awaiting your valuable responses.


Thanks in advance,
Jyothi
--=====================_259375009==_.ALT-- --===============1843524788== 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 --===============1843524788==-- From ipsec-bounces@ietf.org Tue Dec 21 01:30: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 BAA21930 for ; Tue, 21 Dec 2004 01:30:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgdVN-0004CP-W9; Tue, 21 Dec 2004 01:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgdTv-000334-Ha for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 01:26:51 -0500 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 BAA21673 for ; Tue, 21 Dec 2004 01:26:50 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgddK-00025W-3T for ipsec@ietf.org; Tue, 21 Dec 2004 01:36:35 -0500 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 20 Dec 2004 22:26:19 -0800 X-BrightmailFiltered: true X-Ironport-AV: i="3.88,77,1102320000"; d="scan'208"; a="76266378:sNHT25484520" Received: from gluon.jnpr.net ([172.24.15.23]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 22:26:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] extraction of CHILD SA keys from the key material Date: Mon, 20 Dec 2004 22:26:18 -0800 Message-ID: Thread-Topic: [Ipsec] extraction of CHILD SA keys from the key material Thread-Index: AcTnIn/YJIGPE8aZR92qY8vxrR9KzwAAwMDg From: "Shekhar Kshirsagar" To: "Jyothi" , X-OriginalArrivalTime: 21 Dec 2004 06:26:18.0905 (UTC) FILETIME=[FB4B7890:01C4E725] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 It seems correct as per the rules on page 32/33: "Keying material MUST be taken from the expanded KEYMAT in the following order: All keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction. If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet. If a single protocol has both encryption and authentication keys, the encryption key is taken from the first octets of KEYMAT and the authentication key is taken from the next octets." Shekhar ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Jyothi Sent: Monday, December 20, 2004 9:54 PM To: ipsec@ietf.org Subject: [Ipsec] extraction of CHILD SA keys from the key material Hi, I would like to know=A0 the order of extraction of CHILD SA keys from = the key material(KEYMAT) in case ESPwith AUTH and AH . As per section 2.17 draft-ietf-ipsec-ikev2-17, (=A0=A0=A0=A0=A0 If multiple IPsec protocols are negotiated, keying = material is =A0=A0=A0=A0=A0 taken in the order in which the protocol headers will = appear in =A0=A0=A0=A0=A0 the encapsulated packet.) I would like whether the following order is right or not. Initiator side: =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0KEYMAT =3D { outbound AH key | outbound ESP = encryption key | outbound ESP auth key |=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0i= nbound AH key | inbound ESP encryption key | inbound ESP auth key } Responder side: =A0=A0=A0=A0=A0=A0=A0=A0KEYMAT =3D { |inbound AH key | inbound ESP = encryption key | inbound ESP auth key | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0outbound AH key | = outbound ESP encryption key | outbound ESP auth key =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 } Awaiting your valuable responses. Thanks in advance, Jyothi=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 21 02:25: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 CAA10620 for ; Tue, 21 Dec 2004 02:25:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeMY-0004FS-96; Tue, 21 Dec 2004 02:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeI7-0002Eg-QV for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 02:18:43 -0500 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 CAA09742 for ; Tue, 21 Dec 2004 02:18:41 -0500 (EST) Received: from [202.125.80.81] (helo=rocsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgeRL-0003Ke-FK for ipsec@ietf.org; Tue, 21 Dec 2004 02:28:27 -0500 Received: from rocsys.com (localhost [127.0.0.1] (may be forged)) by rocsys.com (8.12.10/8.12.10) with ESMTP id iBE7Gg7Y019344; Tue, 21 Dec 2004 13:20:45 +0530 X-MessageWall-Score: 0 (rocsys.com) Received: from [202.125.80.82] by rocsys.com (MessageWall 1.0.8) with SMTP; 21 Dec 2004 07:50:44 -0000 Message-ID: <41C7D2DA.2030503@rocsys.com> Date: Tue, 21 Dec 2004 13:08:02 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi Subject: Re: [Ipsec] Rekeying IKE SA References: <5.1.0.14.0.20041221100442.00a7a2f0@172.16.1.10> In-Reply-To: <5.1.0.14.0.20041221100442.00a7a2f0@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: 4adaf050708fb13be3316a9eee889caa 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, In your example, SG2 should be considered as Initiator. SPIi and SPIr need to be taken from Proposal of SA. Regards Ravi Jyothi wrote: > Hi all, > > > I have some doubts regarding the Rekeying of IKE SA. > > SG1==============SG2. > > Initially SG1 initiated IKE Exchange and IKE SA and CHILD SAs are > established. > > If the SG2 (responder of IKE SA ) initiated the CREATE_CHILD_SA exchange > to establish new IKE SA keys,* how do we know who will be the initiator > for the new IKE SA (SG1 or SG2) ?? > > *If it is SG1, > that means we will be negotiating the responder nonce, KEr and > responder SPI in CREATE_CHILD_SA request. > > So, in Key material calculation, what SPI and what nonce should be used > as initiator SPI and initiator nonce?? > > Please clarify my doubt. > > > Thanks in advance, > Jyothi > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Dec 21 02:39: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 CAA12095 for ; Tue, 21 Dec 2004 02:39:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeZu-0008Ff-UJ; Tue, 21 Dec 2004 02:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeTb-0007AK-8B for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 02:30:35 -0500 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 CAA11302 for ; Tue, 21 Dec 2004 02:30:33 -0500 (EST) Received: from [202.125.80.81] (helo=rocsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cged0-0003cD-9a for ipsec@ietf.org; Tue, 21 Dec 2004 02:40:19 -0500 Received: from rocsys.com (localhost [127.0.0.1] (may be forged)) by rocsys.com (8.12.10/8.12.10) with ESMTP id iBE7Gg7j019344; Tue, 21 Dec 2004 13:32:52 +0530 X-MessageWall-Score: 0 (rocsys.com) Received: from [202.125.80.82] by rocsys.com (MessageWall 1.0.8) with SMTP; 21 Dec 2004 08:02:52 -0000 Message-ID: <41C7D5B1.1060500@rocsys.com> Date: Tue, 21 Dec 2004 13:20:09 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi Subject: Re: [Ipsec] extraction of CHILD SA keys from the key material References: <5.1.0.14.0.20041215192611.03d08300@172.16.1.10> In-Reply-To: <5.1.0.14.0.20041215192611.03d08300@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: 3e15cc4fdc61d7bce84032741d11c8e5 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 Since, AH header appears first before ESP header in encapsulated packets, your understanding and representation are correct. Regards, -Ravi Jyothi wrote: > >> Hi, >> >> I would like to know the order of extraction of CHILD SA keys from >> the key material(KEYMAT) in case ESPwith AUTH and AH . > > > As per section 2.17 draft-ietf-ipsec-ikev2-17, > > ( If multiple IPsec protocols are negotiated, keying material is > taken in the order in which the protocol headers will appear in > the encapsulated packet.) > > I would like whether the following order is right or not. > >> Initiator side: >> >> KEYMAT = { outbound AH key | outbound ESP encryption key | >> outbound ESP auth key | > > >> inbound AH key | inbound ESP encryption key | >> inbound ESP auth key } >> >> Responder side: >> >> KEYMAT = { |inbound AH key | inbound ESP encryption key | >> inbound ESP auth key | >> outbound AH key | outbound ESP encryption key | >> outbound ESP auth key >> } > > > > Awaiting your valuable responses. > > >> Thanks in advance, >> Jyothi > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Dec 21 03:56: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 DAA16867 for ; Tue, 21 Dec 2004 03:56:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgfkn-0005Lb-UG; Tue, 21 Dec 2004 03:52:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgfiW-00052q-Un for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 03:50:05 -0500 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 DAA16517 for ; Tue, 21 Dec 2004 03:50:02 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgfrw-0005ZT-TW for ipsec@ietf.org; Tue, 21 Dec 2004 03:59:49 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id iBL8nU623415 for ; Tue, 21 Dec 2004 10:49:30 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39DE1E2D-532D-11D9-AD95-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: [Ipsec] Question about Hash-and-URL Date: Tue, 21 Dec 2004 10:49:29 +0200 To: " " X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 two questions regarding Hash-and-URL. I've read the IKEv2 draft and the PKI4Ipsec draft. 1. Where is this HTTP server that holds the certificates supposed to be? 2. How does the IKE peer know the URL? Is the answer to these questions outside the scope of both working groups? Is the webserver supposed to be on the IPsec peer? That won't be possible for the client-to-gateway scenario. Is the webserver supposed to be on the CA? A special-purpose web server connected to the CA? Is there some extension for X509 that allows the URL to be part of the certificate? Thanks. Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 21 12:35: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 MAA02605 for ; Tue, 21 Dec 2004 12:35:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgnhy-00063F-CE; Tue, 21 Dec 2004 12:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgnOR-0000Uc-BV for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 12:01:51 -0500 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 MAA29093 for ; Tue, 21 Dec 2004 12:01:48 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgnXw-0000Qi-6O for ipsec@ietf.org; Tue, 21 Dec 2004 12:11:40 -0500 Received: from [165.227.249.219] (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 iBLH1SfG009306; Tue, 21 Dec 2004 09:01:34 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <39DE1E2D-532D-11D9-AD95-000A95834BAA@checkpoint.com> References: <39DE1E2D-532D-11D9-AD95-000A95834BAA@checkpoint.com> Date: Tue, 21 Dec 2004 09:01:37 -0800 To: Yoav Nir , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Question about Hash-and-URL Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 10:49 AM +0200 12/21/04, Yoav Nir wrote: >I have two questions regarding Hash-and-URL. I've read the IKEv2 >draft and the PKI4Ipsec draft. > >1. Where is this HTTP server that holds the certificates supposed to be? Anywhere. This is a local decision for the gateway operator. >2. How does the IKE peer know the URL? In many cases, they will be hand-typed in. In others, the IPsec gateway itself will host the HTTP server that has the certs, so they can be automatically generated. >Is the answer to these questions outside the scope of both working groups? Yes. >Is the webserver supposed to be on the IPsec peer? That won't be >possible for the client-to-gateway scenario. Yes, and yes. It is likely that a gateway can use hash-and-URL, and a client use the normal cert. >Is the webserver supposed to be on the CA? Probably not. > A special-purpose web server connected to the CA? Probably. > Is there some extension for X509 that allows the URL to be part of >the certificate? That has not yet been specified. We want to see if anyone even uses this before trying to change PKIX. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 21 14: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 OAA08636 for ; Tue, 21 Dec 2004 14:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgpEw-0002Cl-4h; Tue, 21 Dec 2004 14:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgp7v-0000pZ-IU for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 13:52:55 -0500 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 NAA07736 for ; Tue, 21 Dec 2004 13:52:54 -0500 (EST) Received: from web51506.mail.yahoo.com ([206.190.38.198]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CgpHQ-0003rx-JL for ipsec@ietf.org; Tue, 21 Dec 2004 14:02:46 -0500 Received: (qmail 79474 invoked by uid 60001); 21 Dec 2004 18:52:23 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=S4I/KulsxjcS9i4JQ2EhcPCqWtUiCFEXZZ+ZfIg4dX6o5ZPVxo6ipB910GUt498KkNnDm2K39Dh/YRArWOQ+ccCRkakks8iDmaOQbpO0HFFRD2jU0g+ZpbNnS9K8JeKHx+EEeWtnS4JZI+IrGyrTI1BLEpJGoHWmr5N+tEpeXv4= ; Message-ID: <20041221185223.79472.qmail@web51506.mail.yahoo.com> Received: from [221.15.137.117] by web51506.mail.yahoo.com via HTTP; Tue, 21 Dec 2004 10:52:22 PST Date: Tue, 21 Dec 2004 10:52:22 -0800 (PST) From: Park Lee To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ipsec] Issue on input process of Linux native 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 Hi, We know that the output process of Linux native IPsec fully uses the XFRM architecture. The order of primal functions are xfrm_lookup(), xfrm_tmpl_resolve(), xfrm_bundle_create() and dst_output(). The input process for IPsec is more simple than output. The order of primal functions (in IPv4) are xfrm4_rcv(), xfrm4_rcv_encap(), xfrm4_parse_spi(), xfrm4_policy_check(). But, Why should the input process also go throught xfrm_lookup(), xfrm_tmpl_resolve(), xfrm_bundle_create()? What's the purpose of this? Thank you. ===== Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 21 23:39: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 XAA17265 for ; Tue, 21 Dec 2004 23:39:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgy9k-0002YH-Ro; Tue, 21 Dec 2004 23:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgy55-0000kM-BH for ipsec@megatron.ietf.org; Tue, 21 Dec 2004 23:26:35 -0500 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 XAA16468 for ; Tue, 21 Dec 2004 23:26:32 -0500 (EST) Received: from [202.125.80.81] (helo=rocsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgyEV-0008EY-1M for ipsec@ietf.org; Tue, 21 Dec 2004 23:36:31 -0500 Received: from rocsys.com (localhost [127.0.0.1] (may be forged)) by rocsys.com (8.12.10/8.12.10) with ESMTP id iBE7GgDg019344; Wed, 22 Dec 2004 10:28:38 +0530 X-MessageWall-Score: 0 (rocsys.com) Received: from [202.125.80.82] by rocsys.com (MessageWall 1.0.8) with SMTP; 22 Dec 2004 04:58:38 -0000 Message-ID: <41C8FC05.2050008@rocsys.com> Date: Wed, 22 Dec 2004 10:15:57 +0530 From: Ravi Kumar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Subject: Re: [Ipsec] Question about Hash-and-URL References: <39DE1E2D-532D-11D9-AD95-000A95834BAA@checkpoint.com> In-Reply-To: <39DE1E2D-532D-11D9-AD95-000A95834BAA@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: " " 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 HTTP Server could be anywhere. It can be either on CA server, IKE peer or any where. IKE peer should provide the complete URL. I would expect that the URL is one configuration parameter in the IKE peer. Regards Ravi Yoav Nir wrote: > Hi all > > I have two questions regarding Hash-and-URL. I've read the IKEv2 draft > and the PKI4Ipsec draft. > > 1. Where is this HTTP server that holds the certificates supposed to be? > 2. How does the IKE peer know the URL? > > Is the answer to these questions outside the scope of both working groups? > > Is the webserver supposed to be on the IPsec peer? That won't be > possible for the client-to-gateway scenario. > > Is the webserver supposed to be on the CA? A special-purpose web server > connected to the CA? Is there some extension for X509 that allows the > URL to be part of the certificate? > > Thanks. > > Yoav > > > _______________________________________________ > 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 Dec 22 07: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 HAA15518 for ; Wed, 22 Dec 2004 07:05:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch5BI-0007wu-2k; Wed, 22 Dec 2004 07:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch4xo-0003ut-GT for ipsec@megatron.ietf.org; Wed, 22 Dec 2004 06:47:32 -0500 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 GAA13915 for ; Wed, 22 Dec 2004 06:47:29 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch57S-0002eJ-Sq for ipsec@ietf.org; Wed, 22 Dec 2004 06:57:32 -0500 Received: by wproxy.gmail.com with SMTP id 57so42768wri for ; Wed, 22 Dec 2004 03:47:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kZ9dFmgFt0F/s3tehBsoyqQ0jKke7v0wgl9j6AKG4fSrJGWOQq290DuhmLtEp7iGoh5kUAAqo44mkOU680/g+dPHJ3+pDG/76s3oCHrk8Zyzg+pjOpUbu4p9HP+yEvVEFJt3Oj4o63B7HJkCUnww4LruQk+SpmxVAC6uyvEuCEE= Received: by 10.54.41.65 with SMTP id o65mr244148wro; Wed, 22 Dec 2004 03:47:00 -0800 (PST) Received: by 10.54.40.44 with HTTP; Wed, 22 Dec 2004 03:47:00 -0800 (PST) Message-ID: <41ae448404122203477e71bb83@mail.gmail.com> Date: Wed, 22 Dec 2004 17:17:00 +0530 From: Kausty To: Park Lee Subject: Re: [Ipsec] Issue on input process of Linux native IPsec In-Reply-To: <20041221185223.79472.qmail@web51506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041221185223.79472.qmail@web51506.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kausty 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 On Tue, 21 Dec 2004 10:52:22 -0800 (PST), Park Lee wrote: > Hi, > We know that the output process of Linux native > IPsec fully uses the XFRM architecture. The order of > primal functions are xfrm_lookup(), > xfrm_tmpl_resolve(), xfrm_bundle_create() and > dst_output(). > The input process for IPsec is more simple than > output. The order of primal functions (in IPv4) are > xfrm4_rcv(), xfrm4_rcv_encap(), xfrm4_parse_spi(), > xfrm4_policy_check(). > But, Why should the input process also go throught > xfrm_lookup(), xfrm_tmpl_resolve(), > xfrm_bundle_create()? What's the purpose of this? i havent gone through the code flow as u mentioned but this is my general idea. these are generic lookup functions irrespective of ipv6/v4. the purpose is to ensure that all the SA's are applied hence a bundle needs to be created everytime a packet is recieved. If no bundle is created then a seperate search needs to be done for ESP/AH/Transport/Tunnel is this what u were looking for ?? > > Thank you. > > ===== > Best Regards, > Park Lee > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > regards kausty _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 22 07:07: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 HAA15673 for ; Wed, 22 Dec 2004 07:07:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch5DT-0000XS-Df; Wed, 22 Dec 2004 07:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch58M-0007QM-1n for ipsec@megatron.ietf.org; Wed, 22 Dec 2004 06:58:26 -0500 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 GAA14802 for ; Wed, 22 Dec 2004 06:58:22 -0500 (EST) Received: from smtp.wineasy.se ([195.42.198.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch5I0-00033Q-F6 for ipsec@ietf.org; Wed, 22 Dec 2004 07:08:25 -0500 Received: from easymail.wineasy.se (easymail.wineasy.se [195.42.198.3] (may be forged)) by smtp.wineasy.se with ESMTP id iBMBwCrO002030 for ; Wed, 22 Dec 2004 12:58:12 +0100 Received: by easymail.wineasy.se (Postfix, from userid 33) id 0808023DB9; Wed, 22 Dec 2004 12:58:09 +0100 (CET) Content-Type: multipart/mixed; boundary="----------=_1103716689-4100-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: Magnus Alstr=?iso-8859-1?Q?=F6?=m To: ipsec@ietf.org Message-Id: <20041222115809.0808023DB9@easymail.wineasy.se> Date: Wed, 22 Dec 2004 12:58:09 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ipsec] 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 This is a multi-part message in MIME format... ------------=_1103716689-4100-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I have started implementing IKEv2 protocol I have found some issues that I need som help with: 1.3 The CREATE_CHILD_SA Exchange In the CHILD_SA created as part of the initial exchange, a second KE payload and nonce MUST NOT be sent. The result is that the CHILD_SA will always use the same DH group (or none). Should you not be allowed to use different groups? 2.15. Authentication of the IKE_SA (2.15) According to the draft should the authentication data be created by appending: , and . As a result will the complete data to be signed be quite large, of course depending on the original message. How are that signature supposed to be created? 2.23 NAT Traversal You are supposed to send the NAT_DETECTION payloads in the first IKE_SA_INIT exchange and are also supposed to add the payloads before CERT_REQ payload. The CERT_REQ payload is part of the IKE_SA_INIT exchange for responder and the following IKE_AUTH exchange for initiator. The NAT_DETECTION payloads should include the SPIs, but the initiator will not know the responder spi until the first message is received. When are the NAT_DETECTION payloads supposed to be transmitted? 3.6 Certificate payload Why is it a MUST requirement to send and receive first two Hash and URL formats. To add http lookup in a minimal implementation seems to be quite unneccessary. regards Magnus ------------=_1103716689-4100-0 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 ------------=_1103716689-4100-0-- From ipsec-bounces@ietf.org Thu Dec 23 01:33:05 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 BAA26277 for ; Thu, 23 Dec 2004 01:33:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChMVp-0004y1-R5; Thu, 23 Dec 2004 01:31:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChMTh-0004Lg-8G for ipsec@megatron.ietf.org; Thu, 23 Dec 2004 01:29:39 -0500 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 BAA26024 for ; Thu, 23 Dec 2004 01:29:36 -0500 (EST) Received: from web51503.mail.yahoo.com ([206.190.38.195]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ChMdV-0000u0-JJ for ipsec@ietf.org; Thu, 23 Dec 2004 01:39:46 -0500 Received: (qmail 20981 invoked by uid 60001); 23 Dec 2004 06:29:05 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=SR1+C/9l4cs2hH4tPaf+nvh4dNadsl87IJx9yUnwSbtMcPlG7JlFd+LWYlVk3H4GdqsOifcL+JhUw94hBkMJiIbOFrQK+2Ot9w9IaS2Ymj02xdK2Y9nacqn4TwSXJ8D+bbO32CpFrkteqUyVkofrm2XLKpKUW82acF9LJZ6RbX8= ; Message-ID: <20041223062905.20979.qmail@web51503.mail.yahoo.com> Received: from [221.15.137.198] by web51503.mail.yahoo.com via HTTP; Wed, 22 Dec 2004 22:29:05 PST Date: Wed, 22 Dec 2004 22:29:05 -0800 (PST) From: Park Lee Subject: Re: [Ipsec] Issue on input process of Linux native IPsec To: Kausty In-Reply-To: <41ae448404122203477e71bb83@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-net@vger.kernel.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 Wed, 22 Dec 2004 at 17:17, Kausty wrote: > > On Tue, 21 Dec 2004 10:52:22 -0800 (PST), Park Lee > wrote: > > Hi, > > We know that the output process of Linux native > > IPsec fully uses the XFRM architecture. The order > > of primal functions are xfrm_lookup(), > > xfrm_tmpl_resolve(), xfrm_bundle_create() and > > dst_output(). > > The input process for IPsec is more simple than > > output. The order of primal functions (in IPv4) > > are xfrm4_rcv(), xfrm4_rcv_encap(), > > xfrm4_parse_spi(), xfrm4_policy_check(). > > But, Why should the input process also go > > throught xfrm_lookup(), xfrm_tmpl_resolve(), > > xfrm_bundle_create()? What's the purpose of this? > > i havent gone through the code flow as u mentioned > but this is my general idea. > > these are generic lookup functions irrespective of > ipv6/v4. > the purpose is to ensure that all the SA's are > applied hence a bundle needs to be created > everytime a packet is recieved. > If no bundle is created then a seperate search > needs to be done for ESP/AH/Transport/Tunnel > > is this what u were looking for ?? Thanks. But, After a packet was received, It has already been processed by xfrm4_rcv(), xfrm4_rcv_encap(), ah_input(), esp_input(),etc. so, I think that there is no need to search(or created) a bundle everytime a packet is recieved, since it has already been processed. Am I right? ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 23 14:32: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 OAA12452 for ; Thu, 23 Dec 2004 14:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChYfG-0007a5-6X; Thu, 23 Dec 2004 14:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChYc0-0006Uj-Fj for ipsec@megatron.ietf.org; Thu, 23 Dec 2004 14:27:02 -0500 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 OAA11719 for ; Thu, 23 Dec 2004 14:26:58 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChYlw-0004zF-Ax for ipsec@ietf.org; Thu, 23 Dec 2004 14:37:16 -0500 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 iBNJQJjf012837; Thu, 23 Dec 2004 14:26:20 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41C92D31.1090200@zurich.ibm.com> References: <41C92D31.1090200@zurich.ibm.com> Date: Thu, 23 Dec 2004 14:26:15 -0500 To: Brian E Carpenter From: Stephen Kent X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: ipsec@ietf.org, kseo@bbn.com, housley@vigilsec.com Subject: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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="===============0859009189==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0859009189== Content-Type: multipart/alternative; boundary="============_-1108292518==_ma============" --============_-1108292518==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Brian, Thanks for the review comments. Our responses are inline below. >I think this is basically ready to go, but I have a few minor comments >and there are some nits. > >(I will flag this review to the authors etc once Avri has posted it.) > >Slightly substantive: >===================== > >>4.1 Definition and Scope >... >> If different classes of traffic (distinguished by Differentiated >> Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the >> same SA, and if the receiver is employing the optional anti-replay >> feature available in both AH and ESP, this could result in >> inappropriate discarding of lower priority packets due to the >> windowing mechanism used by this feature. 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 and receiver, with the same >> selectors. Distribution of traffic among these parallel SAs to >> support QoS is locally determined by the sender and is not negotiated >> by IKE. The receiver MUST process the packets from the different SAs >> without prejudice. > >I think it would be helpful to remind readers that (as indicated >in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, >which will not be changed en route (since in general, the DSCP >value may be changed en route and that destroys the model described, >since there would be no fixed relationship between DSCP value and SA). The text above applies to both tunnel and transport mode, but yes, in tunnel mode, we are talking about a DSCP value that appears in the inner header. also note that in transport mode a change to the DSCP value en route has no effect at the receiver in terms of IPsec processing, because the receiver is not paying attention to the DSCP value in demuxing the traffic (assigning it to an SA). I suggest we add the following text at the end of the paragraph cited above: This requirements applies to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not case problems with respect to IPse processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. >I also note that there is no reference to the IPv6 Flow Label. Since this >is an e2e field (RFC 3697) it would actually be easier to handle than the >DSCP, if there was any need to do so. We do talk about processing flow labels in 5.1.2.2, but we do not require that an implementation offer different SAs based on flow labels. The WG did not express an opinion that we needed to offer support for QoS based on this parameter, but did for DSCP, and that's what motivated the text in 4.1. > >>4.4.2.1 Data Items in the SAD >... >> o Bypass DF bit (T/F) - applicable to tunnel mode SAs > >Note that this only applies to IPv4 (ditto section 8.1). OK, we will change the text to be: Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4 8.1 DF Bit All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4. > >> >> o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if >> needed to restrict bypass of DSCP values - applicable to tunnel >> mode SAs > >This is unclear to me and needs some explanation. Actually, it's >unclear how the earlier suggested treatment of DSCPs works, >since the DSCP value(s) corresponding to an SA aren't stored anywhere >that I noticed, so the model does not allow for demultiplexing on >DSCP values in any case. The text immediately above says that either you can bypass a DSCP value from an inner IP header to the outer header in tunnel mode, OR you can map the inner value to an entry in an array of DSCP values that are used to populate outer IP headers in tunnel mode. The latter mechanism would be used if one wanted to try to limit the covert channel bandwidth associated with bypassing these values, or if the inner header values were meaningful only in the protected nets behind security gateways and had different, corresponding values in the nets on the other (unprotected) side of the gateways. here is some additional text: Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values - applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signalling concerns. Your second point is that we said that a sender had to be able to allow use of different SAs for different traffic classes, e.g., based on DSCP values, but here we didn't mandate support for storing the different values in the SAD, to aid the sender in selecting the right SA to use for different DSCPs. Good point! We will add the following text to the SAD description to fix this oversight o DSCP values: the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. Steve --============_-1108292518==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re
Brian,

Thanks for the review comments.  Our responses are inline below.

I think this is basically ready to go, but I have a few minor comments
and there are some nits.

(I will flag this review to the authors etc once Avri has posted it.)

Slightly substantive:
=====================
4.1 Definition and Scope
...
   If different classes of traffic (distinguished by Differentiated
   Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the
   same SA, and if the receiver is employing the optional anti-replay
   feature available in both AH and ESP, this could result in
   inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  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 and receiver, with the same
   selectors.  Distribution of traffic among these parallel SAs to
   support QoS is locally determined by the sender and is not negotiated
   by IKE. The receiver MUST process the packets from the different SAs
   without prejudice.

I think it would be helpful to remind readers that (as indicated
in RFC 2983) we are talking here about the "inner" DSCP in a tunnel,
which will not be changed en route (since in general, the DSCP
value may be changed en route and that destroys the model described,
since there would be no fixed relationship between DSCP value and SA).

The text above applies to both tunnel and transport mode, but yes, in tunnel mode, we are talking about a DSCP value that appears in the inner header.  also note that in transport mode a change to the DSCP value en route has no effect at the receiver in terms of IPsec processing, because the receiver is not paying attention to the DSCP value in demuxing the traffic (assigning it to an SA). I suggest we add the following text at the end of the paragraph cited above:

This requirements applies to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not case problems with respect to IPse processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation.

I also note that there is no reference to the IPv6 Flow Label. Since this
is an e2e field (RFC 3697) it would actually be easier to handle than the
DSCP, if there was any need to do so.

We do talk about processing flow labels in 5.1.2.2, but we do not require that an implementation offer different SAs based on flow labels. The WG did not express an opinion that we needed to offer support for QoS based on this  parameter, but did for DSCP, and that's what motivated the text in 4.1.


4.4.2.1 Data Items in the SAD
...
    o Bypass DF bit (T/F) - applicable to tunnel mode SAs

Note that this only applies to IPv4 (ditto section 8.1).

OK, we will change the text to be:

        Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4


8.1 DF Bit

   All IPsec implementations MUST support the option of copying the DF
   bit from an outbound packet to the tunnel mode header that it emits,
   when traffic is carried via a tunnel mode SA. This means that it MUST
   be possible to configure the implementation's treatment of the DF bit
   (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.



    o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values - applicable to tunnel
      mode SAs

This is unclear to me and needs some explanation. Actually, it's
unclear how the earlier suggested treatment of DSCPs works,
since the DSCP value(s) corresponding to an SA aren't stored anywhere
that I noticed, so the model does not allow for demultiplexing on
DSCP values in any case.

The text immediately above says that either you can bypass a DSCP value from an inner IP header to the outer header in tunnel mode, OR you can map the inner value to an entry in an array of DSCP values that are used to populate outer IP headers in tunnel mode. The latter mechanism would be used if one wanted to try to limit the covert channel bandwidth associated with bypassing these values, or if the inner header values were meaningful only in the protected nets behind security gateways and had different, corresponding values in the nets on the other (unprotected) side of the gateways. here is some additional text:

        Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values - applicable to tunnel
      mode SAs. This feature maps DSCP values from an inner header to
     values in an outer header, e.g., to address covert channel
     signalling concerns.


Your second point is that we said that a sender had to be able to allow use of different SAs for different traffic classes, e.g., based on DSCP values, but here we didn't mandate support for storing the different values in the SAD, to aid the sender in selecting the right SA to use for different DSCPs. Good point! We will add the following text to the SAD description to fix this oversight

    o DSCP values: the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. 


Steve

--============_-1108292518==_ma============-- --===============0859009189== 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 --===============0859009189==-- From ipsec-bounces@ietf.org Thu Dec 23 20:52: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 UAA17248 for ; Thu, 23 Dec 2004 20:52:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cheaj-0001nD-4c; Thu, 23 Dec 2004 20:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CheZn-0001R0-Pb; Thu, 23 Dec 2004 20:49:07 -0500 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 UAA17037; Thu, 23 Dec 2004 20:49:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Chejn-0006ZK-Ip; Thu, 23 Dec 2004 20:59:27 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CheZ3-00015H-Tz; Thu, 23 Dec 2004 20:48:21 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 23 Dec 2004 20:48:21 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' 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: - 'Cryptographic Algorithm Implementation Requirements For ESP And AH ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary This document specifies the mandatory-to-implement cryptographic algorithms for the IPsec ESP and AH protocols. In recognition of the fact that mandatory-to-implement algorithm will change over time, this document also specifies algorithms that should be implemented because they are likely to be promoted to mandatory-to-implement in the future. 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. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 24 08:33: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 IAA14950 for ; Fri, 24 Dec 2004 08:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChpR9-0003wZ-FI; Fri, 24 Dec 2004 08:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChpOq-0003ON-P0 for ipsec@megatron.ietf.org; Fri, 24 Dec 2004 08:22:33 -0500 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 IAA14267 for ; Fri, 24 Dec 2004 08:22:30 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChpYl-0002Z7-QC for ipsec@ietf.org; Fri, 24 Dec 2004 08:32:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Date: Fri, 24 Dec 2004 05:29:12 -0800 Message-ID: Thread-Topic: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] thread-index: AcTpJ6V65zh893ULS+iyGCNlO5b54wAXaI2A From: "Vishwas Manral" To: "Stephen Kent" , "Brian E Carpenter" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, kseo@bbn.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 Hi Steve, > This requirements applies to both transport and tunnel mode=20 > SAs. In the case of tunnel mode SAs, the DSCP values in question=20 > appear in the inner IP header. In transport mode, the DSCP value=20 > might change en route, but this should not case problems with=20 > respect to IPsec processing since the value is not employed for=20 > SA selection and MUST NOT be checked as part of SA/packet=20 > validation. When the DSCP value changes en-route can it defeat=20 > the reason of having DSCP as a classifier. " If different classes of traffic (distinguished by Differentiated Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support QoS appropriately." Do you think some clarification is required for this? Besides I do not = see a=20 reason we cannot support flowId as a classifier(it's a local matter at = the=20 tunnel head-end) as long as we allow multiple SA's between a sender = receiver pair. Thanks, Vishwas ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Stephen Kent Sent: Friday, December 24, 2004 12:56 AM To: Brian E Carpenter Cc: ipsec@ietf.org; kseo@bbn.com; housley@vigilsec.com Subject: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt = [Re: New batch of Last Call Documents]] Brian, Thanks for the review comments.=A0 Our responses are inline below. I think this is basically ready to go, but I have a few minor comments and there are some nits. (I will flag this review to the authors etc once Avri has posted it.) Slightly substantive: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.1 Definition and Scope ...=20 =A0=A0 If different classes of traffic (distinguished by Differentiated =A0=A0 Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on = the =A0=A0 same SA, and if the receiver is employing the optional = anti-replay =A0=A0 feature available in both AH and ESP, this could result in =A0=A0 inappropriate discarding of lower priority packets due to the =A0=A0 windowing mechanism used by this feature.=A0 Therefore a sender = SHOULD =A0=A0 put traffic of different classes, but with the same selector = values, =A0=A0 on different SAs to support QoS appropriately.=A0 To permit this, = the =A0=A0 IPsec implementation MUST permit establishment and maintenance of =A0=A0 multiple SAs between a given sender and receiver, with the same =A0=A0 selectors.=A0 Distribution of traffic among these parallel SAs to =A0=A0 support QoS is locally determined by the sender and is not = negotiated =A0=A0 by IKE. The receiver MUST process the packets from the different = SAs =A0=A0 without prejudice. I think it would be helpful to remind readers that (as indicated in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, which will not be changed en route (since in general, the DSCP value may be changed en route and that destroys the model described, since there would be no fixed relationship between DSCP value and SA). The text above applies to both tunnel and transport mode, but yes, in = tunnel mode, we are talking about a DSCP value that appears in the inner = header.=A0 also note that in transport mode a change to the DSCP value = en route has no effect at the receiver in terms of IPsec processing, = because the receiver is not paying attention to the DSCP value in = demuxing the traffic (assigning it to an SA). I suggest we add the = following text at the end of the paragraph cited above: This requirements applies to both transport and tunnel mode SAs. In the = case of tunnel mode SAs, the DSCP values in question appear in the inner = IP header. In transport mode, the DSCP value might change en route, but = this should not case problems with respect to IPse processing since the = value is not employed for SA selection and MUST NOT be checked as part = of SA/packet validation. I also note that there is no reference to the IPv6 Flow Label. Since = this is an e2e field (RFC 3697) it would actually be easier to handle than = the DSCP, if there was any need to do so. We do talk about processing flow labels in 5.1.2.2, but we do not = require that an implementation offer different SAs based on flow labels. = The WG did not express an opinion that we needed to offer support for = QoS based on this=A0 parameter, but did for DSCP, and that's what = motivated the text in 4.1. 4.4.2.1 Data Items in the SAD ...=20 =A0=A0=A0 o Bypass DF bit (T/F) - applicable to tunnel mode SAs Note that this only applies to IPv4 (ditto section 8.1). OK, we will change the text to be: =A0=A0=A0=A0=A0=A0=A0 Bypass DF bit (T/F) - applicable to tunnel mode = SAs where both inner and outer headers are IPv4 8.1 DF Bit =A0=A0 All IPsec implementations MUST support the option of copying the = DF =A0=A0 bit from an outbound packet to the tunnel mode header that it = emits, =A0=A0 when traffic is carried via a tunnel mode SA. This means that it = MUST =A0=A0 be possible to configure the implementation's treatment of the DF = bit =A0=A0 (set, clear, copy from inner header) for each SA. This applies to = SAs where both inner and outer headers are IPv4. =A0=A0=A0 o Bypass DSCP (T/F) or map to unprotected DSCP values (array) = if =A0=A0=A0=A0=A0 needed to restrict bypass of DSCP values - applicable to = tunnel =A0=A0=A0=A0=A0 mode SAs This is unclear to me and needs some explanation. Actually, it's unclear how the earlier suggested treatment of DSCPs works, since the DSCP value(s) corresponding to an SA aren't stored anywhere that I noticed, so the model does not allow for demultiplexing on DSCP values in any case. The text immediately above says that either you can bypass a DSCP value = from an inner IP header to the outer header in tunnel mode, OR you can = map the inner value to an entry in an array of DSCP values that are used = to populate outer IP headers in tunnel mode. The latter mechanism would = be used if one wanted to try to limit the covert channel bandwidth = associated with bypassing these values, or if the inner header values = were meaningful only in the protected nets behind security gateways and = had different, corresponding values in the nets on the other = (unprotected) side of the gateways. here is some additional text: =A0=A0=A0=A0=A0=A0=A0 Bypass DSCP (T/F) or map to unprotected DSCP = values (array) if =A0=A0=A0=A0=A0 needed to restrict bypass of DSCP values - applicable to = tunnel =A0=A0=A0=A0=A0 mode SAs. This feature maps DSCP values from an inner = header to =A0=A0=A0=A0 values in an outer header, e.g., to address covert channel =A0=A0=A0=A0 signalling concerns. Your second point is that we said that a sender had to be able to allow = use of different SAs for different traffic classes, e.g., based on DSCP = values, but here we didn't mandate support for storing the different = values in the SAD, to aid the sender in selecting the right SA to use = for different DSCPs. Good point! We will add the following text to the = SAD description to fix this oversight =A0=A0=A0 o DSCP values: the set of DSCP values allowed for packets = carried over this SA. If no values are specified, no DSCP-specific = filtering is applied. If one or more values are specified, these are = used to select one SA among several that match the traffic selectors for = an outbound packet. Note that these values are NOT checked against = inbound traffic arriving on the SA.=A0 Steve=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 24 14:30: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 OAA06806 for ; Fri, 24 Dec 2004 14:30:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chv4z-0002Jq-IR; Fri, 24 Dec 2004 14:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chv2N-0001tQ-Lw for ipsec@megatron.ietf.org; Fri, 24 Dec 2004 14:23:43 -0500 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 OAA06572 for ; Fri, 24 Dec 2004 14:23:41 -0500 (EST) Received: from web51506.mail.yahoo.com ([206.190.38.198]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ChvCV-0000UA-LP for ipsec@ietf.org; Fri, 24 Dec 2004 14:34:12 -0500 Received: (qmail 67182 invoked by uid 60001); 24 Dec 2004 19:23:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=jegRsKm5DEtdIjhUYieV00MTVWI7q18XO0fVk3RGgGkKPyiV9yjGta3E3AGPIRj3x6zUVARG8b5wsedas6Fn/i7O6QljAzDprohDgwiU/efXppB+DdACJPZGXruMlMA2xXGghaSujbh6M+hxtwd6cWAZfOzCqjVEc6GqrGQu6xw= ; Message-ID: <20041224192311.67180.qmail@web51506.mail.yahoo.com> Received: from [221.15.137.4] by web51506.mail.yahoo.com via HTTP; Fri, 24 Dec 2004 11:23:11 PST Date: Fri, 24 Dec 2004 11:23:11 -0800 (PST) From: Park Lee Subject: Re: [Ipsec] Issue on input process of Linux native IPsec To: David Dillow In-Reply-To: <1103869407.3016.7.camel@ori.thedillows.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-net@vger.kernel.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 Fri, 24 Dec 2004 at 01:23, David Dillow wrote: > On Wed, 2004-12-22 at 22:29 -0800, Park Lee wrote: > > Thanks. > > But, After a packet was received, It has already > > been processed by xfrm4_rcv(), xfrm4_rcv_encap(), > > ah_input(), esp_input(),etc. so, I think that > > there is no need to search(or created) a bundle > > everytime a packet is recieved, since it has > > already been processed. Am I right? > > Are you sure you're not seeing the creation of a > reply packet? Unless you're testing with UDP and a > listening socket on the receiver, you're going to > get a response packet if the incoming packet makes > it through the iptables rules. You were testing > with ICMP echo requests (ping), if I recall. > > I think either you're basing your idea of the > packet flow on printk()'s,or I'm just too tired and > missing where xfrm_lookup() gets called on the > rx path... Yes, I'm testing with ping and basing my idea of the packet flow on printk(). > (yes, sk can be NULL there, but I was wrong about > it being called for Rx'd packets, I think). Does this mean that when the reply (response) packet is sending out through xfrm_lookup(), the sk parameter of xfrm_lookup() will not be NULL? and When the incoming packet itself goes through xfrm_lookup(), the sk parameter will be NULL? Thank you and Merry Christmas. ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Dec 25 14:09: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 OAA08799 for ; Sat, 25 Dec 2004 14:09:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiHEQ-0000rm-RF; Sat, 25 Dec 2004 14:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch1fe-0006qg-Ky for ipsec@megatron.ietf.org; Wed, 22 Dec 2004 03:16:35 -0500 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 DAA00276 for ; Wed, 22 Dec 2004 03:16:27 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch1pB-0005hn-5t for ipsec@ietf.org; Wed, 22 Dec 2004 03:26:27 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iBM8FtSZ360022 for ; Wed, 22 Dec 2004 08:15:55 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBM8GDiN169478 for ; Wed, 22 Dec 2004 08:16:14 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iBM8FspI026904 for ; Wed, 22 Dec 2004 08:15:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iBM8FrRp026895; Wed, 22 Dec 2004 08:15:53 GMT Received: from zurich.ibm.com (sig-9-145-133-38.de.ibm.com [9.145.133.38]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA09798; Wed, 22 Dec 2004 09:15:46 +0100 Message-ID: <41C92D31.1090200@zurich.ibm.com> Date: Wed, 22 Dec 2004 09:15:45 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipsec@ietf.org, housley@vigilsec.com, kent@bbn.com, kseo@bbn.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Dec 2004 14:03:13 -0500 Subject: [Ipsec] [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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 was asked to make this review for Harald's General Area review team. Brian -------- Original Message -------- Subject: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents] Date: Mon, 20 Dec 2004 11:58:03 +0100 From: Brian E Carpenter Organization: IBM To: avri@psg.com CC: gen-art@alvestrand.no References: <18A6842A-4E1E-11D9-8830-000393CC2112@psg.com> I think this is basically ready to go, but I have a few minor comments and there are some nits. (I will flag this review to the authors etc once Avri has posted it.) Slightly substantive: ===================== > 4.1 Definition and Scope ... > If different classes of traffic (distinguished by Differentiated > Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > same SA, and if the receiver is employing the optional anti-replay > feature available in both AH and ESP, this could result in > inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. 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 and receiver, with the same > selectors. Distribution of traffic among these parallel SAs to > support QoS is locally determined by the sender and is not negotiated > by IKE. The receiver MUST process the packets from the different SAs > without prejudice. I think it would be helpful to remind readers that (as indicated in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, which will not be changed en route (since in general, the DSCP value may be changed en route and that destroys the model described, since there would be no fixed relationship between DSCP value and SA). I also note that there is no reference to the IPv6 Flow Label. Since this is an e2e field (RFC 3697) it would actually be easier to handle than the DSCP, if there was any need to do so. > 4.4.2.1 Data Items in the SAD ... > o Bypass DF bit (T/F) - applicable to tunnel mode SAs Note that this only applies to IPv4 (ditto section 8.1). > > o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values - applicable to tunnel > mode SAs This is unclear to me and needs some explanation. Actually, it's unclear how the earlier suggested treatment of DSCPs works, since the DSCP value(s) corresponding to an SA aren't stored anywhere that I noticed, so the model does not allow for demultiplexing on DSCP values in any case. Nits: ===== > 4.4.1 The Security Policy Database (SPD) ... > Decorrelation ... > (unordered) state. ppendix B provides an algorithm that can be s/Appendix/ppendix/ Then idnits has complaints: idnits 1.58 tmp/draft-ietf-ipsec-rfc2401bis-05.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3667/3668 boilerplate... * The document seems to lack an RFC 3667 Section 5.4 Copyright Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(C) Copyright Notice.) * The document seems to lack an RFC 3667 Section 5.5 Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? * There are 105 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : * The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. * The document seems to lack a 1id_guidelines paragraph about 6 months document validity. * The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. * The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Miscellaneous warnings: - There are 28 instances of lines with hyphenated line breaks in the document. - Line 512 has weird spacing: '...support multi...' - Line 1029 has weird spacing: '...g value examp...' - Line 1031 has weird spacing: '...elector selec...' - Line 1610 has weird spacing: '...oc addr list ...' - Line 1615 has weird spacing: '...em addr list ...' - (18 more instances...) Run idnits with the --verbose option for more detailed information. Brian _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Dec 25 14:12:19 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 OAA08967 for ; Sat, 25 Dec 2004 14:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiHER-0000rs-Ii; Sat, 25 Dec 2004 14:05:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChrkE-00051b-8g for ipsec@megatron.ietf.org; Fri, 24 Dec 2004 10:52:46 -0500 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 KAA24179 for ; Fri, 24 Dec 2004 10:52:43 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChruK-0005KI-OH for ipsec@ietf.org; Fri, 24 Dec 2004 11:03:13 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id iBOFqDdt116980 for ; Fri, 24 Dec 2004 15:52:13 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBOFqoDF151144 for ; Fri, 24 Dec 2004 16:52:50 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iBOFqDn6016087 for ; Fri, 24 Dec 2004 16:52:13 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iBOFqCfj016084; Fri, 24 Dec 2004 16:52:12 +0100 Received: from zurich.ibm.com (sig-9-145-254-59.de.ibm.com [9.145.254.59]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA62176; Fri, 24 Dec 2004 16:52:10 +0100 Message-ID: <41CC3B2A.20408@zurich.ibm.com> Date: Fri, 24 Dec 2004 16:52:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stephen Kent References: <41C92D31.1090200@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Dec 2004 14:03:13 -0500 Cc: ipsec@ietf.org, kseo@bbn.com, housley@vigilsec.com Subject: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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 Steve, Thanks, that all looks good to me. wrt to the Flow Label, I'm not surprised it didn't come up, because it is an unused field today and RFC 3697 is quite recent. With respect to Vishwas' comment on this, as long as the draft doesn't *forbid* it being used in an SA, I think it's probably better to wait for some experience with flow label usage before trying to craft language. Brian Stephen Kent wrote: > Brian, > > Thanks for the review comments. Our responses are inline below. > >> I think this is basically ready to go, but I have a few minor comments >> and there are some nits. >> >> (I will flag this review to the authors etc once Avri has posted it.) >> >> Slightly substantive: >> ===================== >> >>> 4.1 Definition and Scope >> >> ... >> >>> If different classes of traffic (distinguished by Differentiated >>> Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the >>> same SA, and if the receiver is employing the optional anti-replay >>> feature available in both AH and ESP, this could result in >>> inappropriate discarding of lower priority packets due to the >>> windowing mechanism used by this feature. 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 and receiver, with the same >>> selectors. Distribution of traffic among these parallel SAs to >>> support QoS is locally determined by the sender and is not negotiated >>> by IKE. The receiver MUST process the packets from the different SAs >>> without prejudice. >> >> >> I think it would be helpful to remind readers that (as indicated >> in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, >> which will not be changed en route (since in general, the DSCP >> value may be changed en route and that destroys the model described, >> since there would be no fixed relationship between DSCP value and SA). > > > The text above applies to both tunnel and transport mode, but yes, in > tunnel mode, we are talking about a DSCP value that appears in the inner > header. also note that in transport mode a change to the DSCP value en > route has no effect at the receiver in terms of IPsec processing, > because the receiver is not paying attention to the DSCP value in > demuxing the traffic (assigning it to an SA). I suggest we add the > following text at the end of the paragraph cited above: > > This requirements applies to both transport and tunnel mode SAs. In the > case of tunnel mode SAs, the DSCP values in question appear in the inner > IP header. In transport mode, the DSCP value might change en route, but > this should not case problems with respect to IPse processing since the > value is not employed for SA selection and MUST NOT be checked as part > of SA/packet validation. > >> I also note that there is no reference to the IPv6 Flow Label. Since this >> is an e2e field (RFC 3697) it would actually be easier to handle than the >> DSCP, if there was any need to do so. > > > We do talk about processing flow labels in 5.1.2.2, but we do not > require that an implementation offer different SAs based on flow labels. > The WG did not express an opinion that we needed to offer support for > QoS based on this parameter, but did for DSCP, and that's what > motivated the text in 4.1. > >> >>> 4.4.2.1 Data Items in the SAD >> >> ... >> >>> o Bypass DF bit (T/F) - applicable to tunnel mode SAs >> >> >> Note that this only applies to IPv4 (ditto section 8.1). > > > OK, we will change the text to be: > > Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner > and outer headers are IPv4 > > > 8.1 DF Bit > > All IPsec implementations MUST support the option of copying the DF > bit from an outbound packet to the tunnel mode header that it emits, > when traffic is carried via a tunnel mode SA. This means that it MUST > be possible to configure the implementation's treatment of the DF bit > (set, clear, copy from inner header) for each SA. This applies to SAs > where both inner and outer headers are IPv4. > >> >>> >>> o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if >>> needed to restrict bypass of DSCP values - applicable to tunnel >>> mode SAs >> >> >> This is unclear to me and needs some explanation. Actually, it's >> unclear how the earlier suggested treatment of DSCPs works, >> since the DSCP value(s) corresponding to an SA aren't stored anywhere >> that I noticed, so the model does not allow for demultiplexing on >> DSCP values in any case. > > > The text immediately above says that either you can bypass a DSCP value > from an inner IP header to the outer header in tunnel mode, OR you can > map the inner value to an entry in an array of DSCP values that are used > to populate outer IP headers in tunnel mode. The latter mechanism would > be used if one wanted to try to limit the covert channel bandwidth > associated with bypassing these values, or if the inner header values > were meaningful only in the protected nets behind security gateways and > had different, corresponding values in the nets on the other > (unprotected) side of the gateways. here is some additional text: > > Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values - applicable to tunnel > mode SAs. This feature maps DSCP values from an inner header to > values in an outer header, e.g., to address covert channel > signalling concerns. > > > Your second point is that we said that a sender had to be able to allow > use of different SAs for different traffic classes, e.g., based on DSCP > values, but here we didn't mandate support for storing the different > values in the SAD, to aid the sender in selecting the right SA to use > for different DSCPs. Good point! We will add the following text to the > SAD description to fix this oversight > > o DSCP values: the set of DSCP values allowed for packets carried > over this SA. If no values are specified, no DSCP-specific filtering is > applied. If one or more values are specified, these are used to select > one SA among several that match the traffic selectors for an outbound > packet. Note that these values are NOT checked against inbound traffic > arriving on the SA. > > Steve > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 27 00:26: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 AAA25197 for ; Mon, 27 Dec 2004 00:26:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CinJf-0002xH-Q1; Mon, 27 Dec 2004 00:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CinIf-0002iw-Iu for ipsec@megatron.ietf.org; Mon, 27 Dec 2004 00:20:09 -0500 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 AAA24918 for ; Mon, 27 Dec 2004 00:20:05 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CinT8-0007S5-25 for ipsec@ietf.org; Mon, 27 Dec 2004 00:31:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Date: Sun, 26 Dec 2004 21:26:57 -0800 Message-ID: Thread-Topic: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] thread-index: AcTqtuwk2K0kUlAiSfug2tirn4MO2QBHT6Hg From: "Vishwas Manral" To: "Brian E Carpenter" , "Stephen Kent" X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, kseo@bbn.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 Hi, I agree with what Brian said. I just noticed some formatting issues=20 with my previous mail because of which one of the points I stated got missed.=20 When the DSCP value changes en-route can it defeat the reason for=20 having DSCP as a classifier? " If different classes of traffic (distinguished by Differentiated Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support QoS appropriately." Do you think some clarification is required for this? Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, December 24, 2004 9:22 PM To: Stephen Kent Cc: ipsec@ietf.org; kseo@bbn.com; housley@vigilsec.com Subject: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Steve, Thanks, that all looks good to me. wrt to the Flow Label, I'm not surprised it didn't come up, because it is an unused field today and RFC 3697 is quite recent. With respect to Vishwas' comment on this, as long as the draft doesn't *forbid* it being used in an SA, I think it's probably better to wait for some experience with flow label usage before trying to craft language. Brian Stephen Kent wrote: > Brian, >=20 > Thanks for the review comments. Our responses are inline below. >=20 >> I think this is basically ready to go, but I have a few minor comments >> and there are some nits. >> >> (I will flag this review to the authors etc once Avri has posted it.) >> >> Slightly substantive: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> 4.1 Definition and Scope >> >> ... >> >>> If different classes of traffic (distinguished by Differentiated >>> Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the >>> same SA, and if the receiver is employing the optional anti-replay >>> feature available in both AH and ESP, this could result in >>> inappropriate discarding of lower priority packets due to the >>> windowing mechanism used by this feature. 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 and receiver, with the same >>> selectors. Distribution of traffic among these parallel SAs to >>> support QoS is locally determined by the sender and is not negotiated >>> by IKE. The receiver MUST process the packets from the different SAs >>> without prejudice. >> >> >> I think it would be helpful to remind readers that (as indicated >> in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, >> which will not be changed en route (since in general, the DSCP >> value may be changed en route and that destroys the model described, >> since there would be no fixed relationship between DSCP value and SA). >=20 >=20 > The text above applies to both tunnel and transport mode, but yes, in=20 > tunnel mode, we are talking about a DSCP value that appears in the inner=20 > header. also note that in transport mode a change to the DSCP value en=20 > route has no effect at the receiver in terms of IPsec processing,=20 > because the receiver is not paying attention to the DSCP value in=20 > demuxing the traffic (assigning it to an SA). I suggest we add the=20 > following text at the end of the paragraph cited above: >=20 > This requirements applies to both transport and tunnel mode SAs. In the=20 > case of tunnel mode SAs, the DSCP values in question appear in the inner=20 > IP header. In transport mode, the DSCP value might change en route, but=20 > this should not case problems with respect to IPse processing since the=20 > value is not employed for SA selection and MUST NOT be checked as part > of SA/packet validation. >=20 >> I also note that there is no reference to the IPv6 Flow Label. Since this >> is an e2e field (RFC 3697) it would actually be easier to handle than the >> DSCP, if there was any need to do so. >=20 >=20 > We do talk about processing flow labels in 5.1.2.2, but we do not=20 > require that an implementation offer different SAs based on flow labels.=20 > The WG did not express an opinion that we needed to offer support for=20 > QoS based on this parameter, but did for DSCP, and that's what=20 > motivated the text in 4.1. >=20 >> >>> 4.4.2.1 Data Items in the SAD >> >> ... >> >>> o Bypass DF bit (T/F) - applicable to tunnel mode SAs >> >> >> Note that this only applies to IPv4 (ditto section 8.1). >=20 >=20 > OK, we will change the text to be: >=20 > Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner=20 > and outer headers are IPv4 >=20 >=20 > 8.1 DF Bit >=20 > All IPsec implementations MUST support the option of copying the DF > bit from an outbound packet to the tunnel mode header that it emits, > when traffic is carried via a tunnel mode SA. This means that it MUST > be possible to configure the implementation's treatment of the DF bit > (set, clear, copy from inner header) for each SA. This applies to SAs=20 > where both inner and outer headers are IPv4. >=20 >> >>> >>> o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if >>> needed to restrict bypass of DSCP values - applicable to tunnel >>> mode SAs >> >> >> This is unclear to me and needs some explanation. Actually, it's >> unclear how the earlier suggested treatment of DSCPs works, >> since the DSCP value(s) corresponding to an SA aren't stored anywhere >> that I noticed, so the model does not allow for demultiplexing on >> DSCP values in any case. >=20 >=20 > The text immediately above says that either you can bypass a DSCP value=20 > from an inner IP header to the outer header in tunnel mode, OR you can > map the inner value to an entry in an array of DSCP values that are used=20 > to populate outer IP headers in tunnel mode. The latter mechanism would=20 > be used if one wanted to try to limit the covert channel bandwidth=20 > associated with bypassing these values, or if the inner header values=20 > were meaningful only in the protected nets behind security gateways and=20 > had different, corresponding values in the nets on the other=20 > (unprotected) side of the gateways. here is some additional text: >=20 > Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values - applicable to tunnel > mode SAs. This feature maps DSCP values from an inner header to > values in an outer header, e.g., to address covert channel > signalling concerns. >=20 >=20 > Your second point is that we said that a sender had to be able to allow=20 > use of different SAs for different traffic classes, e.g., based on DSCP=20 > values, but here we didn't mandate support for storing the different=20 > values in the SAD, to aid the sender in selecting the right SA to use=20 > for different DSCPs. Good point! We will add the following text to the > SAD description to fix this oversight >=20 > o DSCP values: the set of DSCP values allowed for packets carried=20 > over this SA. If no values are specified, no DSCP-specific filtering is=20 > applied. If one or more values are specified, these are used to select > one SA among several that match the traffic selectors for an outbound=20 > packet. Note that these values are NOT checked against inbound traffic > arriving on the SA. >=20 > Steve >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 27 12:15: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 MAA29602 for ; Mon, 27 Dec 2004 12:15:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiyQW-0005xn-Kb; Mon, 27 Dec 2004 12:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiyGI-00037Q-Ce for ipsec@megatron.ietf.org; Mon, 27 Dec 2004 12:02:26 -0500 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 MAA28727 for ; Mon, 27 Dec 2004 12:02:24 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiyQz-00088o-Ba for ipsec@ietf.org; Mon, 27 Dec 2004 12:13:32 -0500 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 iBRH1mjh026826; Mon, 27 Dec 2004 12:01:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 27 Dec 2004 11:12:09 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org, kseo@bbn.com, Brian E Carpenter , 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 At 9:26 PM -0800 12/26/04, Vishwas Manral wrote: >Hi, > >I agree with what Brian said. I just noticed some formatting issues >with my previous mail because of which one of the points I stated got >missed. > >When the DSCP value changes en-route can it defeat the reason for >having DSCP as a classifier? If an external DCSP value changes en route, it will not defeat the effect of using separate SAs for different traffic priorities, since the DSCP value is NOT used by a receiver to demux the trafic to different SAs. > >" If different classes of traffic (distinguished by Differentiated > Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > same SA, and if the receiver is employing the optional anti-replay > feature available in both AH and ESP, this could result in > inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. Therefore a sender SHOULD > put traffic of different classes, but with the same selector values, > on different SAs to support QoS appropriately." > >Do you think some clarification is required for this? > Brian said that I think the text I proposed addressed his concerns re clarifications, so I think I will stop with that text. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 27 12:21:12 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 MAA00111 for ; Mon, 27 Dec 2004 12:21:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiyQY-00060b-T9; Mon, 27 Dec 2004 12:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiyGJ-00037Z-CH for ipsec@megatron.ietf.org; Mon, 27 Dec 2004 12:02:27 -0500 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 MAA28733 for ; Mon, 27 Dec 2004 12:02:25 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiyQz-00088k-EP for ipsec@ietf.org; Mon, 27 Dec 2004 12:13:33 -0500 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 iBRH1mjf026826; Mon, 27 Dec 2004 12:01:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 27 Dec 2004 11:09:00 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipsec@ietf.org, kseo@bbn.com, Brian E Carpenter , 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 At 5:29 AM -0800 12/24/04, Vishwas Manral wrote: >Hi Steve, > >> This requirements applies to both transport and tunnel mode >> SAs. In the case of tunnel mode SAs, the DSCP values in question >> appear in the inner IP header. In transport mode, the DSCP value >> might change en route, but this should not case problems with >> respect to IPsec processing since the value is not employed for >> SA selection and MUST NOT be checked as part of SA/packet >> validation. When the DSCP value changes en-route can it defeat >> the reason of having DSCP as a classifier. > >" If different classes of traffic (distinguished by Differentiated > Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > same SA, and if the receiver is employing the optional anti-replay > feature available in both AH and ESP, this could result in > inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. Therefore a sender SHOULD > put traffic of different classes, but with the same selector values, > on different SAs to support QoS appropriately." > >Do you think some clarification is required for this? Besides I do not see a >reason we cannot support flowId as a classifier(it's a local matter at the >tunnel head-end) as long as we allow multiple SA's between a sender receiver >pair. > >Thanks, >Vishwas Since the text above mandates support for multiple SAs with the same traffic selectors between a pair of IPsec implementations, then yes, one could make a local decision to use the flowId as a classified. But, since 2401bis is silent on this detail, there is no guarantee that this capability will be available in any implementation. I agree with Brian that if we have experience suggesting that this is an important feature, we can make exlicit comments about it in a later revision. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 28 23:10: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 XAA01016 for ; Tue, 28 Dec 2004 23:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjUxb-0004xo-S1; Tue, 28 Dec 2004 22:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjUvr-0004Xv-71 for ipsec@megatron.ietf.org; Tue, 28 Dec 2004 22:55:31 -0500 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 WAA00142 for ; Tue, 28 Dec 2004 22:55:27 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjV6j-0000Xc-3g for ipsec@ietf.org; Tue, 28 Dec 2004 23:06:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Date: Tue, 28 Dec 2004 20:02:24 -0800 Message-ID: Thread-Topic: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] thread-index: AcTtEB7cyEFtc0bcQRig3bgl71Eu8QASfiCg From: "Vishwas Manral" To: "Stephen Kent" X-Spam-Score: 1.0 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Brian E Carpenter 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 Steve, As you said "such behavior by intermediate routers would tend to cause havoc with the traffic anyway, so I would hope that this would not be a common occurrence".=20 Would we however want to put a comment regarding the same? The text to add could be "Changing DSCP values en-route can result in different class of packets on the same SA and SHOULD be avoided." Sorry for the confusion caused. Thanks, Vishwas -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Tuesday, December 28, 2004 9:21 PM To: Vishwas Manral Cc: Brian E Carpenter; Stephen Kent Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] At 8:24 PM -0800 12/27/04, Vishwas Manral wrote: >Hi Steve, > >I understand (and you have repeated the point) that at the receiver we >do >not use DSCP to demultiplex traffic. I was coming more from the point >of the following: - > >"If different classes of traffic (distinguished by Differentiated >Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the >same SA, and if the receiver is employing the optional anti-replay >feature available in both AH and ESP, this could result in >inappropriate discarding of lower priority packets due to the >windowing mechanism used by this feature. Therefore a sender SHOULD >put traffic of different classes, but with the same selector values, >on different SAs to support QoS appropriately." > >If we are changing DSCP values en-route wouldn't we still have the >issue >"if the receiver is employing the optional anti-replay feature >available in both AH and ESP, this could result in inappropriate >discarding of lower priority packets due to the windowing mechanism >used by this feature." > >Thanks, >Vishwas I think I see what question you are trig to ask, although an example=20 would have helped, vs. just repeating the quotes from 2401bis. Assume two SAs between A and B, carrying traffic that exhibit the=20 same traffic selectors but different DSCP values. Call these SA1 and=20 SA2, both going from A to B. Assume that these are tunnel mode SAs.=20 The inner header has the original DSCP values, and the outer header=20 has these values copied to it. So, now we can look at what may happen due to changes in external=20 DSCP values. For example, along the path from A to B, the DSCP value=20 in the outer header of some of the packets on SA1 may be changed, but=20 not on SA2. Or maybe both traffic streams have changes to the outer=20 DSCP values. Such changes may cause traffic on an affected SA to=20 arrive in a different order that the inner DSCP values would suggest,=20 relative to the traffic on the other SA. But, since the traffic is=20 carried on different SAs, this will not affect the sequence number=20 checking that takes place on each SA separately. However, if the DSCP values change for traffic carried on one of the=20 SAs, e.g., flipping back and forth in a way that causes some packets=20 to speed along, and other packets to lag behind, then yes, that could=20 cause problems for traffic on that SA. Severe packet reordering=20 caused by inconsistent DSCP value changes applied to packets bound to=20 a single SA could cause rejection of packets by the anti-replay=20 mechanism. However, even in the absence of IPsec, such behavior by=20 intermediate routers would tend to cause havoc with the traffic=20 anyway, so I would hope that this would not be a common occurrence. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 29 09:45: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 JAA13298 for ; Wed, 29 Dec 2004 09:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjewm-0007XB-Or; Wed, 29 Dec 2004 09:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjer0-0006Ug-4A for ipsec@megatron.ietf.org; Wed, 29 Dec 2004 09:31:10 -0500 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 JAA11920 for ; Wed, 29 Dec 2004 09:31:08 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjf24-0008Sd-FD for ipsec@ietf.org; Wed, 29 Dec 2004 09:42:40 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iBTEV2vw000823; Wed, 29 Dec 2004 09:31:02 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Dec 2004 09:31:02 -0500 Message-ID: To: Vishwas@sinett.com Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.tx t [Re: New batch of Last Call Documents]] Date: Wed, 29 Dec 2004 09:31:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.12.28.44 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 > Would we however want to put a comment regarding the same? The text to > add could be "Changing DSCP values en-route can result in different > class of packets on the same SA and SHOULD be avoided." Not in that form - the proposed text is too broad. There are a number of situations in which DSCP values need to be changed en-route in a fashion that does not affect packet ordering - AF drop precedence remarking, and changing domain-specific DSCP usage when a tunnel crosses a diffserv domain boundary are two examples. The real concern here is not just DSCP changes, but rather that the anti-reply mechanism is (deliberately) not designed to support significant packet reordering within a single SA, hence reordering (from whatever cause) should be avoided and minimized if unavoidable. As Steve noted, significant reordering "would tend to cause havoc with the traffic anyway" - in particular, TCP is likely to react poorly. It ought to be obvious that significant packet reordering within a single SA will interact poorly with the small windows used for anti-replay. I'm not opposed to adding a statement to this effect, but as it expresses a requirement on network elements other than the IPsec implementation, an RFC 2119 "SHOULD" is not appropriate - a lower case "should" ought to be used instead. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Vishwas Manral > Sent: Tuesday, December 28, 2004 11:02 PM > To: Stephen Kent > Cc: ipsec@ietf.org; Brian E Carpenter > Subject: RE: [Ipsec] Re: [Fwd: Review of > draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last > Call Documents]] > > Hi Steve, > > As you said "such behavior by intermediate routers would tend to cause > havoc with the traffic anyway, so I would hope that this > would not be a > common occurrence". > > Would we however want to put a comment regarding the same? The text to > add could be "Changing DSCP values en-route can result in different > class of packets on the same SA and SHOULD be avoided." > > Sorry for the confusion caused. > > Thanks, > Vishwas > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, December 28, 2004 9:21 PM > To: Vishwas Manral > Cc: Brian E Carpenter; Stephen Kent > Subject: RE: [Ipsec] Re: [Fwd: Review of > draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call > Documents]] > > At 8:24 PM -0800 12/27/04, Vishwas Manral wrote: > >Hi Steve, > > > >I understand (and you have repeated the point) that at the > receiver we > >do > >not use DSCP to demultiplex traffic. I was coming more from the point > >of the following: - > > > >"If different classes of traffic (distinguished by Differentiated > >Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > >same SA, and if the receiver is employing the optional anti-replay > >feature available in both AH and ESP, this could result in > >inappropriate discarding of lower priority packets due to the > >windowing mechanism used by this feature. Therefore a sender SHOULD > >put traffic of different classes, but with the same selector values, > >on different SAs to support QoS appropriately." > > > >If we are changing DSCP values en-route wouldn't we still have the > >issue > >"if the receiver is employing the optional anti-replay feature > >available in both AH and ESP, this could result in inappropriate > >discarding of lower priority packets due to the windowing mechanism > >used by this feature." > > > >Thanks, > >Vishwas > > I think I see what question you are trig to ask, although an example > would have helped, vs. just repeating the quotes from 2401bis. > > Assume two SAs between A and B, carrying traffic that exhibit the > same traffic selectors but different DSCP values. Call these SA1 and > SA2, both going from A to B. Assume that these are tunnel mode SAs. > The inner header has the original DSCP values, and the outer header > has these values copied to it. > > So, now we can look at what may happen due to changes in external > DSCP values. For example, along the path from A to B, the DSCP value > in the outer header of some of the packets on SA1 may be changed, but > not on SA2. Or maybe both traffic streams have changes to the outer > DSCP values. Such changes may cause traffic on an affected SA to > arrive in a different order that the inner DSCP values would suggest, > relative to the traffic on the other SA. But, since the traffic is > carried on different SAs, this will not affect the sequence number > checking that takes place on each SA separately. > > However, if the DSCP values change for traffic carried on one of the > SAs, e.g., flipping back and forth in a way that causes some packets > to speed along, and other packets to lag behind, then yes, that could > cause problems for traffic on that SA. Severe packet reordering > caused by inconsistent DSCP value changes applied to packets bound to > a single SA could cause rejection of packets by the anti-replay > mechanism. However, even in the absence of IPsec, such behavior by > intermediate routers would tend to cause havoc with the traffic > anyway, so I would hope that this would not be a common occurrence. > > Steve > > > > _______________________________________________ > 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 Dec 29 13:20:12 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 NAA29102 for ; Wed, 29 Dec 2004 13:20:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjiPD-0005D1-Jk; Wed, 29 Dec 2004 13:18:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjiHP-0003S3-Au for ipsec@megatron.ietf.org; Wed, 29 Dec 2004 13:10:39 -0500 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 NAA28570 for ; Wed, 29 Dec 2004 13:10:35 -0500 (EST) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjiSY-00059K-KE for ipsec@ietf.org; Wed, 29 Dec 2004 13:22:11 -0500 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.11) with ESMTP id iBTI9g5n022015; Wed, 29 Dec 2004 12:09:42 -0600 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.11/Submit) id iBTI81i7021084; Wed, 29 Dec 2004 18:08:01 GMT Message-Id: <200412291808.iBTI81i7021084@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Wed, 29 Dec 2004 18:08:01 +0000 From: "William Dixon" To: , Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Date: Wed, 29 Dec 2004 10:06:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-Lux-Comment: LuxSci remailer message ID code - 1104343681-580774.870171045 [0] X-Spam-Score: 0.8 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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 Perhaps also add a comment that "If DSCP marking or remarking of IPsec packets is performed, attention must be given to also marking IKE packets appropriately to ensure successful negotiation of new IPsec SA pairs prior to the expiration of current IPsec SA lifetimes." > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Black_David@emc.com > Sent: Wednesday, December 29, 2004 6:31 AM > To: Vishwas@sinett.com > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] Re: [Fwd: Review of > draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last > Call Documents]] > > > Would we however want to put a comment regarding the same? > The text to > > add could be "Changing DSCP values en-route can result in different > > class of packets on the same SA and SHOULD be avoided." > > Not in that form - the proposed text is too broad. There are > a number of situations in which DSCP values need to be > changed en-route in a fashion that does not affect packet > ordering - AF drop precedence remarking, and changing > domain-specific DSCP usage when a tunnel crosses a diffserv > domain boundary are two examples. > > The real concern here is not just DSCP changes, but rather > that the anti-reply mechanism is (deliberately) not designed > to support significant packet reordering within a single SA, > hence reordering (from whatever cause) should be avoided and > minimized if unavoidable. > As Steve noted, significant reordering "would tend to cause > havoc with the traffic anyway" - in particular, TCP is likely > to react poorly. > > It ought to be obvious that significant packet reordering > within a single SA will interact poorly with the small > windows used for anti-replay. I'm not opposed to adding a > statement to this effect, but as it expresses a requirement > on network elements other than the IPsec implementation, an > RFC 2119 "SHOULD" is not appropriate - a lower case "should" > ought to be used instead. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Vishwas Manral > > Sent: Tuesday, December 28, 2004 11:02 PM > > To: Stephen Kent > > Cc: ipsec@ietf.org; Brian E Carpenter > > Subject: RE: [Ipsec] Re: [Fwd: Review of > > draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call > > Documents]] > > > > Hi Steve, > > > > As you said "such behavior by intermediate routers would > tend to cause > > havoc with the traffic anyway, so I would hope that this > would not be > > a common occurrence". > > > > Would we however want to put a comment regarding the same? > The text to > > add could be "Changing DSCP values en-route can result in different > > class of packets on the same SA and SHOULD be avoided." > > > > Sorry for the confusion caused. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Tuesday, December 28, 2004 9:21 PM > > To: Vishwas Manral > > Cc: Brian E Carpenter; Stephen Kent > > Subject: RE: [Ipsec] Re: [Fwd: Review of > > draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call > > Documents]] > > > > At 8:24 PM -0800 12/27/04, Vishwas Manral wrote: > > >Hi Steve, > > > > > >I understand (and you have repeated the point) that at the > > receiver we > > >do > > >not use DSCP to demultiplex traffic. I was coming more > from the point > > >of the following: - > > > > > >"If different classes of traffic (distinguished by Differentiated > > >Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are > sent on the > > >same SA, and if the receiver is employing the optional anti-replay > > >feature available in both AH and ESP, this could result in > > >inappropriate discarding of lower priority packets due to the > > >windowing mechanism used by this feature. Therefore a > sender SHOULD > > >put traffic of different classes, but with the same > selector values, > > >on different SAs to support QoS appropriately." > > > > > >If we are changing DSCP values en-route wouldn't we still have the > > >issue "if the receiver is employing the optional > anti-replay feature > > >available in both AH and ESP, this could result in inappropriate > > >discarding of lower priority packets due to the windowing > mechanism > > >used by this feature." > > > > > >Thanks, > > >Vishwas > > > > I think I see what question you are trig to ask, although > an example > > would have helped, vs. just repeating the quotes from 2401bis. > > > > Assume two SAs between A and B, carrying traffic that > exhibit the same > > traffic selectors but different DSCP values. Call these > SA1 and SA2, > > both going from A to B. Assume that these are tunnel mode SAs. > > The inner header has the original DSCP values, and the outer header > > has these values copied to it. > > > > So, now we can look at what may happen due to changes in > external DSCP > > values. For example, along the path from A to B, the DSCP > value in the > > outer header of some of the packets on SA1 may be changed, > but not on > > SA2. Or maybe both traffic streams have changes to the outer DSCP > > values. Such changes may cause traffic on an affected SA to > arrive in > > a different order that the inner DSCP values would suggest, > relative > > to the traffic on the other SA. But, since the traffic is > carried on > > different SAs, this will not affect the sequence number > checking that > > takes place on each SA separately. > > > > However, if the DSCP values change for traffic carried on > one of the > > SAs, e.g., flipping back and forth in a way that causes > some packets > > to speed along, and other packets to lag behind, then yes, > that could > > cause problems for traffic on that SA. Severe packet > reordering caused > > by inconsistent DSCP value changes applied to packets bound to a > > single SA could cause rejection of packets by the anti-replay > > mechanism. However, even in the absence of IPsec, such behavior by > > intermediate routers would tend to cause havoc with the traffic > > anyway, so I would hope that this would not be a common occurrence. > > > > Steve > > > > > > > > _______________________________________________ > > 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 Wed Dec 29 15: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 PAA09052 for ; Wed, 29 Dec 2004 15:38:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkUO-00050F-Kv; Wed, 29 Dec 2004 15:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkT2-00044l-5X for ipsec@megatron.ietf.org; Wed, 29 Dec 2004 15:30:48 -0500 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 PAA08635 for ; Wed, 29 Dec 2004 15:30:46 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjkeD-00080q-PX for ipsec@ietf.org; Wed, 29 Dec 2004 15:42:22 -0500 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 iBTKU2jj025332; Wed, 29 Dec 2004 15:30:14 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 29 Dec 2004 14:52:35 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] 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: 93238566e09e6e262849b4f805833007 Cc: ipsec@ietf.org, Brian E Carpenter 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:02 PM -0800 12/28/04, Vishwas Manral wrote: >Hi Steve, > >As you said "such behavior by intermediate routers would tend to cause >havoc with the traffic anyway, so I would hope that this would not be a >common occurrence". > >Would we however want to put a comment regarding the same? The text to >add could be "Changing DSCP values en-route can result in different >class of packets on the same SA and SHOULD be avoided." > >Sorry for the confusion caused. > >Thanks, >Vishwas We could add an advisory statement that warns folks, e.g., "If significant reordering of packets occurs in an SA, e.g, as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism." Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 30 01:15: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 BAA29903 for ; Thu, 30 Dec 2004 01:15:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjtWg-0002gn-4V; Thu, 30 Dec 2004 01:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjtRV-0000QO-EE for ipsec@megatron.ietf.org; Thu, 30 Dec 2004 01:05:49 -0500 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 BAA29060 for ; Thu, 30 Dec 2004 01:05:48 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjtcc-0006mE-4W for ipsec@ietf.org; Thu, 30 Dec 2004 01:17:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Dec 2004 22:13:53 -0800 Message-ID: Thread-Topic: draft-ietf-ipsec-esp-ah-algorithms-02.txt thread-index: AcTuNrx5A28r3JvQS4mNs3cB6B6maA== From: "Vishwas Manral" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Donald.Eastlake@Motorola.com Subject: [Ipsec] draft-ietf-ipsec-esp-ah-algorithms-02.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: , Content-Type: multipart/mixed; boundary="===============0918636134==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0918636134== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4EE36.BC7E3950" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4EE36.BC7E3950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Donald, =20 I have some minor comments: - =20 1. For ESP we state that "MUST NULL"(must support NULL = authentication). However=20 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt = = very clearly seems to state "However, this standard does not require ESP = implementations to offer an encryption-only service." =20 We may want to change the MUST to SHOULD. Steve? =20 2. A more general comment, what about all the algorithm's that are = specified by IETF but not in the document or a different key size, e.g. = "SHOULD+ AES-CBC with 128-bit keys" what about other key sizes. I = understand it is stated that: - "To ensure interoperability between disparate implementations it is = necessary to specify a set of mandatory-to-implement algorithms to ensure at least = one algorithm that all implementations will have available." however SHOULD's(I = guess not mandatory) are specified. =20 Thanks, Vishwas ------_=_NextPart_001_01C4EE36.BC7E3950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Donald,
=0A=
 
=0A=
I have some minor comments: = -
=0A=
 
=0A=
1. For ESP we state that = "MUST    =0A= NULL"(must support NULL authentication). However
=0A=
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.t= xt very clearly seems to state "However, this = standard does =0A= not require ESP implementations to offer an encryption-only =0A= service."
=0A=
 
=0A=
We may want to change the MUST to = SHOULD. =0A= Steve?
=0A=
 
=0A=
2. A more general comment, what about = all the =0A= algorithm's that are specified by IETF but not in the document or a = different =0A= key size, e.g. "SHOULD+    AES-CBC with 128-bit keys" = what about =0A= other key sizes. I understand it is stated that: -
  "To = ensure =0A= interoperability between disparate implementations it is necessary =0A= to
   specify a set of mandatory-to-implement algorithms to = ensure =0A= at least one algorithm
=0A=
   that all implementations = will have =0A= available." however SHOULD's(I guess not mandatory) are =0A= specified.
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
------_=_NextPart_001_01C4EE36.BC7E3950-- --===============0918636134== 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 --===============0918636134==-- From ipsec-bounces@ietf.org Thu Dec 30 02:28: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 CAA17956 for ; Thu, 30 Dec 2004 02:28:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjuhN-0007zc-TV; Thu, 30 Dec 2004 02:26:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjufv-0007KL-6U for ipsec@megatron.ietf.org; Thu, 30 Dec 2004 02:24:47 -0500 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 CAA17542 for ; Thu, 30 Dec 2004 02:24:46 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjur2-0008Ne-Nr for ipsec@ietf.org; Thu, 30 Dec 2004 02:36:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] Date: Wed, 29 Dec 2004 23:31:40 -0800 Message-ID: Thread-Topic: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] thread-index: AcTt5oHULt/l6rR6RtSEZpJYRy8yUgAWvPyQ From: "Vishwas Manral" To: "Stephen Kent" X-Spam-Score: 1.0 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Brian E Carpenter 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 Steve, I agree to the text you propose. Thanks, Vishwas -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, December 30, 2004 1:23 AM To: Vishwas Manral Cc: ipsec@ietf.org; Brian E Carpenter Subject: RE: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] At 8:02 PM -0800 12/28/04, Vishwas Manral wrote: >Hi Steve, > >As you said "such behavior by intermediate routers would tend to cause >havoc with the traffic anyway, so I would hope that this would not be a >common occurrence". > >Would we however want to put a comment regarding the same? The text to >add could be "Changing DSCP values en-route can result in different >class of packets on the same SA and SHOULD be avoided." > >Sorry for the confusion caused. > >Thanks, >Vishwas We could add an advisory statement that warns folks, e.g., "If significant reordering of packets occurs in an SA, e.g, as a=20 result of changes to DSCP values en route, this may trigger packet=20 discarding by a receiver due to application of the anti-replay=20 mechanism." Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 30 05:02: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 FAA28355 for ; Thu, 30 Dec 2004 05:02:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjwvd-0002B4-Q1; Thu, 30 Dec 2004 04:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjwuM-0001vW-55 for ipsec@megatron.ietf.org; Thu, 30 Dec 2004 04:47:50 -0500 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 EAA27303 for ; Thu, 30 Dec 2004 04:47:48 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjx5e-0003AN-C3 for ipsec@ietf.org; Thu, 30 Dec 2004 04:59:31 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iBU9liln019983 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 30 Dec 2004 11:47:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iBU9lhA7019977; Thu, 30 Dec 2004 11:47:43 +0200 (EET) 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16851.52927.238002.105876@fireball.kivinen.iki.fi> Date: Thu, 30 Dec 2004 11:47:43 +0200 From: Tero Kivinen To: Magnus Alstr=?iso-8859-1?Q?=F6?=m Subject: [Ipsec] IKEv2 In-Reply-To: <20041222115809.0808023DB9@easymail.wineasy.se> References: <20041222115809.0808023DB9@easymail.wineasy.se> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 20 min X-Total-Time: 19 min X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Magnus Alstr=F6m writes: > 1.3 The CREATE=5FCHILD=5FSA Exchange >=20 > In the CHILD=5FSA created as part of the initial exchange, a second K= E > payload and nonce MUST NOT be sent. The result is that the CHILD=5FSA= > will always use the same DH group (or none). Should you not be > allowed to use different groups=3F=20 No. There is no point of using different group there. In quite many cases this CHILD=5FSA will also be the only SA created. Having only one= group there and only one DH calculation simplifies the protocol and reduces calculation overhead. > 2.15. Authentication of the IKE=5FSA (2.15) >=20 > According to the draft should the authentication data be created by > appending: , and . As a res= ult > will the complete data to be signed be quite large, of course > depending on the original message. How are that signature supposed > to be created=3F Signing includes the normal phase of the calculating hash over the data before actually signing it. The old IKEv1 method of signing the already calculated digest caused some problems, as there is hardware implementation and APIs which only allow hash+sign, and do not offer any raw signing operations. So IKEv2 uses normal hash+sign operation.=20= > 2.23 NAT Traversal=20 >=20 > You are supposed to send the NAT=5FDETECTION payloads in the first > IKE=5FSA=5FINIT exchange and are also supposed to add the payloads > before CERT=5FREQ payload. The CERT=5FREQ payload is part of the > IKE=5FSA=5FINIT exchange for responder and the following IKE=5FAUTH > exchange for initiator. The location of the NAT=5FDETECTION payload is after the Ni and Nr payloads (and if there is CERTREQ in the responder IKE=5FSA=5FINIT then= it is between Nr and CERTREQ). There is no CERTREQ in the initiator IKE=5FSA=5FINIT packet, so the location is after Ni. I.e: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, =09 N(NAT=5FDETECTION=5FDESTINATION=5FIP), =09 N(NAT=5FDETECTION=5FSOURCE=5FIP),=20 =09 [N(NAT=5FDETECTION=5FSOURCE=5FIP) ...] --> <-- HDR, SAr1, KEr, Nr, =09=09=09=09=09N(NAT=5FDETECTION=5FDESTINATION=5FIP), =09=09=09=09=09N(NAT=5FDETECTION=5FSOURCE=5FIP),=20 =09=09=09=09=09[N(NAT=5FDETECTION=5FSOURCE=5FIP) ...], =09=09=09=09=09[CERTREQ] I.e. there is exactly one NAT=5FDETECTION=5FDESTINATION=5FIP payload, a= nd then one or more NAT=5FDETECTION=5FSOURCE=5FIP notifications. The draft= does not specify the order of the destination and source IP payloads, but I used the same order that is used in the rfc3947 (IKEv1 NAT-T).=20 > The NAT=5FDETECTION payloads should include the SPIs, but the > initiator will not know the responder spi until the first message is > received. When are the NAT=5FDETECTION payloads supposed to be > transmitted=3F The initiator will use responder SPIr of 0 when sending its own notifications (i.e the exactly same SPI it puts in the IKE=5FSA=5FINIT packet where it is sending this notification. The responder will use the same when checking the values sent by the initiator, but it will then use both SPIs when sending its own reply packet. I agree this is not perhaps very clear from the draft, and reason for this is that there is fewer round trips in the IKEv1 than what was in the main mode of the IKEv1 (where the payloads appeared in the 3rd and 4th packet (2nd round trip)). On the other hand we do not want to complicate the protocol description by defining the NAT=5FDETECTION=5F* payloads differently depending whether they are sent by the initiator or responder (i.e. say that skip SPIr in the initiators NAT=5FDETECTION=5F* payloads, now = we include SPIr, but use value of 0).=20 > 3.6 Certificate payload >=20 > Why is it a MUST requirement to send and receive first two Hash and > URL formats. To add http lookup in a minimal implementation seems to > be quite unneccessary.=20 This is trying to enforce that even minimal implementations can work even when you cannot send large enough UDP packets which could hold certificates.=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 30 10:04: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 KAA18483 for ; Thu, 30 Dec 2004 10:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck1k7-00047V-EA; Thu, 30 Dec 2004 09:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck1hR-0002zR-AE for ipsec@megatron.ietf.org; Thu, 30 Dec 2004 09:54:49 -0500 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 JAA17687 for ; Thu, 30 Dec 2004 09:54:47 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck1sl-0001xN-BR for ipsec@ietf.org; Thu, 30 Dec 2004 10:06:32 -0500 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 iBUEs6jj022286; Thu, 30 Dec 2004 09:54:10 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 30 Dec 2004 09:50:55 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-esp-ah-algorithms-02.txt X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ipsec@ietf.org, Donald.Eastlake@Motorola.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="===============0053636849==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0053636849== Content-Type: multipart/alternative; boundary="============_-1107704048==_ma============" --============_-1107704048==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:13 PM -0800 12/29/04, Vishwas Manral wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C4EE36.BC7E3950" > >Hi Donald, > >I have some minor comments: - > >1. For ESP we state that "MUST NULL"(must support NULL >authentication). However >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt very >clearly seems to state "However, this standard does not require ESP >implementations to offer an encryption-only service." > >We may want to change the MUST to SHOULD. Steve? Good point. since we changed the requirements for encryption-only support in this round of document revisions, I think a SHOULD here is correct. Steve --============_-1107704048==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] draft-ietf-ipsec-esp-ah-algorithms-02.txt
At 10:13 PM -0800 12/29/04, Vishwas Manral wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C4EE36.BC7E3950"
Hi Donald,
 
I have some minor comments: -
 
1. For ESP we state that "MUST    NULL"(must support NULL authentication). However
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt very clearly seems to state "However, this standard does not require ESP implementations to offer an encryption-only service."
 
We may want to change the MUST to SHOULD. Steve?

Good point. since we changed the requirements for encryption-only support in this round of document revisions, I think a SHOULD here is correct.

Steve
--============_-1107704048==_ma============-- --===============0053636849== 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 --===============0053636849==-- From ipsec-bounces@ietf.org Thu Dec 30 10:21: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 KAA20250 for ; Thu, 30 Dec 2004 10:21:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck1yb-0001mW-B5; Thu, 30 Dec 2004 10:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck1pL-0006uS-UZ for ipsec@megatron.ietf.org; Thu, 30 Dec 2004 10:02:59 -0500 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 KAA18334 for ; Thu, 30 Dec 2004 10:02:58 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck20h-0002B6-Hf for ipsec@ietf.org; Thu, 30 Dec 2004 10:14:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id iBUEs0ba025643 for ; Thu, 30 Dec 2004 07:54:00 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iBUExuXw018399 for ; Thu, 30 Dec 2004 08:59:56 -0600 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Dec 2004 10:02:47 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF238105CD4366@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'Vishwas Manral'" Date: Thu, 30 Dec 2004 10:02:39 -0500 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: 8b30eb7682a596edff707698f4a80f7d Cc: ipsec@ietf.org Subject: [Ipsec] RE: draft-ietf-ipsec-esp-ah-algorithms-02.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 See below at @@@ -----Original Message----- From: Vishwas Manral [mailto:Vishwas@sinett.com] Sent: Thursday, December 30, 2004 1:14 AM To: ipsec@ietf.org Cc: Eastlake III Donald-LDE008 Subject: draft-ietf-ipsec-esp-ah-algorithms-02.txt Hi Donald, I have some minor comments: - 1. For ESP we state that "MUST NULL"(must support NULL authentication). However http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt very clearly seems to state "However, this standard does not require ESP implementations to offer an encryption-only service." We may want to change the MUST to SHOULD. Steve? @@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. 2. A more general comment, what about all the algorithm's that are specified by IETF but not in the document or a different key size, e.g. "SHOULD+ AES-CBC with 128-bit keys" what about other key sizes. I understand it is stated that: - "To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory-to-implement algorithms to ensure at least one algorithm that all implementations will have available." however SHOULD's(I guess not mandatory) are specified. @@@ I don't see why this document needs to list every algorithm/key-size mentioned in any other IETF document. If there is consensus for additional entries, I'd be happy to start a successor document. The document's MUSTs are the most important part and are a complete list of what the IETF process has yielded as the mandatory-to-implement algorithms. But I don't see what the problem is with the document containing SHOULDs or other levels of implementation advice and hints as to how that advice might change. @@@ While the sentence you quote above is obviously true, that sentence does not deny that there are recommendations other than mandatory-to-implement in the document. Does every sentence in a document have to include every nuance from all of the rest of the material in a document? Thanks, Vishwas @@@ Thanks, @@@ Donald ========================================================= Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 31 01:36: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 BAA21164 for ; Fri, 31 Dec 2004 01:36:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkGCZ-0007WN-NC; Fri, 31 Dec 2004 01:23:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkG04-0005Od-NL for ipsec@megatron.ietf.org; Fri, 31 Dec 2004 01:11:01 -0500 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 BAA19555 for ; Fri, 31 Dec 2004 01:10:58 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkGBN-0007j7-BY for ipsec@ietf.org; Fri, 31 Dec 2004 01:22:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Dec 2004 22:17:56 -0800 Message-ID: Thread-Topic: draft-ietf-ipsec-esp-ah-algorithms-02.txt thread-index: AcTugdx/Vxgc0InMS26paw/2TyjiZwAfMpuw From: "Vishwas Manral" To: "Eastlake III Donald-LDE008" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] RE: draft-ietf-ipsec-esp-ah-algorithms-02.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 Content-Transfer-Encoding: quoted-printable Hi Donald, @@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. I don't agree the draft draft-ietf-ipsec-esp-v3-09 should be changed. The ESP document no longer requires the ESP only service to be there. As Steve said, we should have change to SHOULD or even a MAY (conforming to the ESP document). From the ESP document: - " - confidentiality-only (MAY be supported) - integrity-only (MUST be supported) - confidentiality and integrity (MUST be supported)" @@@ I don't see why this document needs to list every algorithm/key-size mentioned in any other IETF document. If there is consensus for additional entries, I'd be happy to start a successor document. I see no reason why we should not. Also if we do not want to keep (MAY's) in the document, you may have to remove (NULL AUTH) from the document altogether for ESP. A very happy and fruitful new year to you!! Thanks again, Vishwas -----Original Message----- From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake@motorola.com]=20 Sent: Thursday, December 30, 2004 8:33 PM To: Vishwas Manral Cc: ipsec@ietf.org Subject: RE: draft-ietf-ipsec-esp-ah-algorithms-02.txt See below at @@@ -----Original Message----- From: Vishwas Manral [mailto:Vishwas@sinett.com]=20 Sent: Thursday, December 30, 2004 1:14 AM To: ipsec@ietf.org Cc: Eastlake III Donald-LDE008 Subject: draft-ietf-ipsec-esp-ah-algorithms-02.txt Hi Donald, I have some minor comments: - 1. For ESP we state that "MUST NULL"(must support NULL authentication). However=20 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt very clearly seems to state "However, this standard does not require ESP implementations to offer an encryption-only service." We may want to change the MUST to SHOULD. Steve? @@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. 2. A more general comment, what about all the algorithm's that are specified by IETF but not in the document or a different key size, e.g. "SHOULD+ AES-CBC with 128-bit keys" what about other key sizes. I understand it is stated that: - "To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory-to-implement algorithms to ensure at least one algorithm that all implementations will have available." however SHOULD's(I guess not mandatory) are specified. @@@ I don't see why this document needs to list every algorithm/key-size mentioned in any other IETF document. If there is consensus for additional entries, I'd be happy to start a successor document. The document's MUSTs are the most important part and are a complete list of what the IETF process has yielded as the mandatory-to-implement algorithms. But I don't see what the problem is with the document containing SHOULDs or other levels of implementation advice and hints as to how that advice might change. @@@ While the sentence you quote above is obviously true, that sentence does not deny that there are recommendations other than mandatory-to-implement in the document. Does every sentence in a document have to include every nuance from all of the rest of the material in a document? Thanks, Vishwas @@@ Thanks, @@@ Donald = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 31 01:36: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 BAA21181 for ; Fri, 31 Dec 2004 01:36:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkGEC-0007uD-KB; Fri, 31 Dec 2004 01:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkG61-0006ef-EY for ipsec@megatron.ietf.org; Fri, 31 Dec 2004 01:17:09 -0500 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 BAA19752 for ; Fri, 31 Dec 2004 01:17:08 -0500 (EST) Received: from web90007.mail.scd.yahoo.com ([66.218.94.65]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CkGHU-0007qa-6P for ipsec@ietf.org; Fri, 31 Dec 2004 01:29:01 -0500 Received: (qmail 2256 invoked by uid 60001); 31 Dec 2004 06:16:36 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=feeF1G7jcYYu6n1AeUyiPmrt8gb4Wt5dN7WxTtFgN2Ug9WRsNiTYGCYgdTBiFc8iDaFJCjQRHjEnxzTM1/K1pSzy1TA+lkQLexsD+k4cii1HI6889nJjhWUSJ2OMioYKjRWXNcbJGW60Pj61Hi9+7r669DObyytmrsq8RDvVxfE= ; Message-ID: <20041231061636.2254.qmail@web90007.mail.scd.yahoo.com> Received: from [24.7.121.173] by web90007.mail.scd.yahoo.com via HTTP; Thu, 30 Dec 2004 22:16:36 PST Date: Thu, 30 Dec 2004 22:16:36 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] 'Name' as Selector 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 Section 4.4.1.1 of rfc2401-bis describes 'Name' in selectors and its usage of it. Based on my understanding after reading this section, this is mainly intended to be used in remote access scenarios. What is the advantage of using this over IRAC/IRAS method specified by IKEv2 draft? Aren't both addressing and solving the same problem? If so, why is the support for 'Names' is made MUST? If not, can somebody describe the usage scenaris of 'Name' field in SPD policy? Thanks Surya __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec