From owner-ipsec@lists.tislabs.com Sat Sep 1 13:18:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f81KIgD06783; Sat, 1 Sep 2001 13:18:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00665 Sat, 1 Sep 2001 15:10:02 -0400 (EDT) Date: Sat, 01 Sep 2001 15:15:25 -0400 From: George Hadjichristofi Subject: key management protocols To: ipsec@lists.tislabs.com Reply-to: Big.George@vt.edu Message-id: <3B9133CD.6DCE42AF@vt.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi everyone, I am new on this list. I am planning on doing a research on the weaknesses of key management protocols. I have read about Photuris, SKEME,SKIP, OAKLEY, and ISAKMP, but I am not sure what is used in the industry. Which are the most important key management protocol implementations that are currently used? Am I missing any protocol? Where can i get more info? Thanks for your help. George -- ************************************************* George C. Hadjichristofi Graduate Student,Computer Engineering Department Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 FAX:(775)-361-1201 ************************************************* From owner-ipsec@lists.tislabs.com Sat Sep 1 13:29:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f81KTtD06916; Sat, 1 Sep 2001 13:29:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00702 Sat, 1 Sep 2001 15:54:09 -0400 (EDT) Message-ID: <001f01c1019f$b646b6c0$dace1dd5@mahdavi> From: "mahdavi" To: "ipsec" Subject: ( need more answer) inbound VS. outbound. Date: Sun, 1 Jul 2001 00:33:19 +0430 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C101C5.6CF40100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C101C5.6CF40100 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi.=20 In a security gateway how you can distinguish between an Inbound packet = and outbound packet? Is this correct ?=20 "every packet is outbound else its destination IP is IP of this machine = and it is in tunnel mode(this security gateway)" if it is not correct Y?? sincerely yours mahdavi ------=_NextPart_000_001C_01C101C5.6CF40100 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi.
In a security gateway how = you can=20 distinguish between an Inbound packet and outbound packet?
 
Is this correct ? =
 
"every packet is outbound else its = destination IP=20 is IP of this machine and it is in tunnel mode(this security=20 gateway)"
 
if it is not correct Y??
 
sincerely yours
 
mahdavi
 
 
 
 
------=_NextPart_000_001C_01C101C5.6CF40100-- From owner-ipsec@lists.tislabs.com Sat Sep 1 13:29:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f81KTwD06928; Sat, 1 Sep 2001 13:29:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00696 Sat, 1 Sep 2001 15:52:12 -0400 (EDT) Message-ID: <001201c1019f$6116da40$dace1dd5@mahdavi> From: "mahdavi" To: "Puja Puri" Cc: References: Subject: Re: inbound vs outbound? Date: Sun, 1 Jul 2001 00:30:54 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi U R right about hosts. But I am to design a security gateway in hardaware that is located in heart of a high speed router that has many interfaces. no packet is generating from my machine. so with your idea there is no outbound there. just pay attention to this fact that every packet that is destined to my machine is in tunnel mode. By now tell me what is wrong with my opinion "every packet is outbound else its destination IP is IP of this machine and it is in tunnel mode (this security gateway) ." ----- Original Message ----- From: Puja Puri To: mahdavi Cc: Sent: Thursday, 30 August, 2001 9:18 ÕÈÍ Subject: Re: inbound vs outbound? > I beg to defer from this point of view "that every packet that is not > destined for my machine is outbound". I feel that the packets that are > originating from ur machine are outbound and the remaining packets > recieved by ur machine are inbound irrespective of whether they r destined > for ur machine or they r forwarded(in which case they also become > outbound). > > Puja Puri > Member of Technical Staff > Networking and Internet Software Group > C-DAC > Pune > > On Wed, 29 Aug 2001, mahdavi wrote: > > > Hi. > > In a security gateway how you can distinguish between an Inbound packet and outbound packet? > > > > Is this correct ? > > "every packet is outbound else its destination IP is IP of this machine (this security gateway) . > > > > > > From owner-ipsec@lists.tislabs.com Mon Sep 3 01:14:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f838EfD03284; Mon, 3 Sep 2001 01:14:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02703 Mon, 3 Sep 2001 03:25:48 -0400 (EDT) Message-ID: <3B93324B.86D68858@6wind.com> Date: Mon, 03 Sep 2001 09:33:31 +0200 From: Christophe Gouault Organization: 6WIND X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: mahdavi Cc: Puja Puri , ipsec@lists.tislabs.com Subject: Re: inbound vs outbound? References: <001201c1019f$6116da40$dace1dd5@mahdavi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, "inbound" and "outbound" have nothing to do with IP addresses. Since your machine forwards packets, each packet is processed twice by IPsec and is both inbound and outbound : first your packet is received on an interface, hence it is processed by IPsec as "inbound". Then it is forwarded and sent on another interface : it is processed by IPsec again, but as an "outbound" packet. Christophe. mahdavi wrote: > Hi > U R right about hosts. > But I am to design a security gateway in hardaware that is located in heart > of a high speed router that has many interfaces. > no packet is generating from my machine. so with your idea there is no > outbound there. just pay attention to this fact that every packet that is > destined to my machine is in tunnel mode. > > By now tell me what is wrong with my opinion > > "every packet is outbound else its destination IP is IP of this machine and > it is in tunnel mode (this security gateway) ." > ----- Original Message ----- > From: Puja Puri > To: mahdavi > Cc: > Sent: Thursday, 30 August, 2001 9:18 ÕÈÍ > Subject: Re: inbound vs outbound? > > > I beg to defer from this point of view "that every packet that is not > > destined for my machine is outbound". I feel that the packets that are > > originating from ur machine are outbound and the remaining packets > > recieved by ur machine are inbound irrespective of whether they r destined > > for ur machine or they r forwarded(in which case they also become > > outbound). > > > > Puja Puri > > Member of Technical Staff > > Networking and Internet Software Group > > C-DAC > > Pune > > > > On Wed, 29 Aug 2001, mahdavi wrote: > > > > > Hi. > > > In a security gateway how you can distinguish between an Inbound packet > and outbound packet? > > > > > > Is this correct ? > > > "every packet is outbound else its destination IP is IP of this machine > (this security gateway) . > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Sep 3 01:14:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f838EqD03481; Mon, 3 Sep 2001 01:14:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02599 Mon, 3 Sep 2001 02:57:16 -0400 (EDT) Message-ID: <000d01c13447$1e829040$e00210ac@cwcrrjkrrcfonk> From: "Hong Gie Ong" To: , References: <3B9133CD.6DCE42AF@vt.edu> Subject: Re: key management protocols Date: Mon, 3 Sep 2001 15:07:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm also in the starting phase of doing research on key management in a future wireless scenario based on Mobile-IP; here's a quick link to start with: http://citeseer.nj.nec.com/boyd98public.html There's enough to read and maybe we could exchange relevant info. The key word is "simple": keep it simple. I guess that's kind of the overall summary of discussions that have been going on in the lists, complexity in system design is the enemy of correctness, in this case, of security. (quoted) Also you should determine your scope 'cause there's too much information out there to cover it all; which layer etc. Finally, keep track of the important developments in the lists, like MIPv6 and this list, gan bei!! Hong Gie Ong EE M.Sc. student ----- Original Message ----- From: "George Hadjichristofi" To: Sent: Sunday, September 02, 2001 3:15 AM Subject: key management protocols > Hi everyone, > I am new on this list. I am planning on doing a research on the > weaknesses of key management protocols. I have read about Photuris, > SKEME,SKIP, OAKLEY, and ISAKMP, but I am not sure what is used in the > industry. > > Which are the most important key management protocol implementations > that are currently used? Am I missing any protocol? Where can i get more > info? > > Thanks for your help. > George > > -- > ************************************************* > George C. Hadjichristofi > Graduate Student,Computer Engineering Department > Virginia Tech,Blacksburg,VA 24061,U.S.A > TEL:(540)-951-8936 FAX:(775)-361-1201 > ************************************************* > > > From owner-ipsec@lists.tislabs.com Mon Sep 3 01:35:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f838ZKD26301; Mon, 3 Sep 2001 01:35:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02748 Mon, 3 Sep 2001 03:42:47 -0400 (EDT) Message-ID: <3B933640.37BFB2B0@F-Secure.com> Date: Mon, 03 Sep 2001 10:50:24 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: Jason Palmatier , ipsec@lists.tislabs.com Subject: Re: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE References: <200108311640.f7VGeZ024812@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > >>>>> "Ari" == Ari Huttunen writes: > Ari> 40000 + number of bits in the group. > > Ari> It would be nice to have officially assigned numbers, though. > Ari> Especially since you cannot negotiate this by having a VID, since > Ari> they are used in the first message. > > Ari> The same restriction applies to the.. dare I say it?.. here goes.. > Ari> X-Auth authentication type. There's no way to negotiate it's usage > Ari> by using a VID. Our new software version sends this automatically, > Ari> and a couple of vendors whose software refused any connection when > Ari> they received an attribute they didn't understand, agreed to change > Ari> their software that it skips a transform it doesn't fully understand > Ari> and tries to match the next transform. > > Ari> The current RFCs do not state what to do when something like this > Ari> happens.. i.e. an unknown attribute is received in a transform payload. > > I thought that you are supposed to ignore proposals that you do not > understand. Where "understand" means either that you match: > assigned #, > (VID, private#) That's the sensible thing to do. Can you please point out where it reads in the RFCs? It's at least not in "5.6 Transform Payload Processing" of ISAKMP RFC. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Mon Sep 3 09:45:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f83GjuD08470; Mon, 3 Sep 2001 09:45:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03428 Mon, 3 Sep 2001 11:48:45 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15251.43007.180999.350725@thomasm-u1.cisco.com> Date: Mon, 3 Sep 2001 08:55:43 -0700 (PDT) To: , ietf_kink@vpnc.org Subject: network partitions and DPD X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had a brief conversation with Bill Sommerfeld at last IETF about his idea of birth certificates for IKE with regards KINK. While the idea has a fairly straightforward solution for KINK (since there's a reliable source of time from the KDC), I realized that birth certificates only catch the case where one of the peers has rebooted. This leaves an important case with no solution. That case is where the two peers are separated for some amount of time by a network partition leaving a pending connection half open. Consider the case where the final reply is lost by the initiator and all subsequent retransmissions fail because of a network partition. This leaves correct state on the respondent and incorrect state on the initiator. If we want to solve for this -- and I think there's good motivation for plugging these sorts of black hole situations in the name of a robust protocol -- I believe that a failed operation must always result in the side perceiving the failure to remove its state for the operation in progress; this is simple enough. The more difficult problem to deal with is what happens on the side if it believes that its side of the connection is fully formed? In the example above, Bob would have both SA's installed and not know that the network had partitioned. In this case, Bob may send to a blackhole at Alice and given current IPsec mechanisms, I don't believe there's a way to recover. One proposal I've heard is that Alice should initiate keying if she sees SPI's from an unknown source. The problem is that Alice does not necessarily have enough information to figure out how to re-create the SA. This is particularly true if there are multiple acceptible forms of identity, different selectors on each end, etc. Thus, it seems to me that the only reasonable thing that Alice can do is send Bob an unauthenticated message giving him a clue that something might be amiss. The natural thing to here is to send some sort of ICMP message, I think. When Bob receives the ICMP message, he doesn't really know for sure that the message wasn't spoofed, but he at least knows how to reinstantiate the SA. What seems like it would be useful is for Bob to try to first see if this was a spoofed attack in the case of IKE (KINK doesn't suffer from the sort of public key make-work DoS attack as IKE, so it's more ignorable). Also, it would be nice if Bob could basically pick up where they left off. That is, if the ISAKMP SA was already established, then it would be advantageous to keep using it if it were a quick mode SA that was half open. At this point, it would seem that Bob should just remove its old SA's, and initiate a fresh one. Since Alice had no state in the first place, I'd think that we'd be back in the ground state, and that we'd be fully recovered by then. What is probably the interesting question is how best to implement the test to check if the ICMP message was legitimate. Also, there's a question in my mind whether there's a need to check other SA's at the same time. This, I think, needs more work. If you made it down here, happy labor day (or end 'o vacation outside NA :-) Mike From owner-ipsec@lists.tislabs.com Mon Sep 3 09:46:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f83Gk2D08623; Mon, 3 Sep 2001 09:46:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03440 Mon, 3 Sep 2001 11:54:04 -0400 (EDT) Date: Mon, 3 Sep 2001 09:01:07 -0700 (PDT) Message-Id: <200109031601.JAA23673@thomasm-u1.cisco.com> From: Michael Thomas To: , ietf-kink@vpnc.org Subject: network partitions and DPD X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had a brief conversation with Bill Sommerfeld at last IETF about his idea of birth certificates for IKE with regards KINK. While the idea has a fairly straightforward solution for KINK (since there's a reliable source of time from the KDC), I realized that birth certificates only catch the case where one of the peers has rebooted. This leaves an important case with no solution. That case is where the two peers are separated for some amount of time by a network partition leaving a pending connection half open. Consider the case where the final reply is lost by the initiator and all subsequent retransmissions fail because of a network partition. This leaves correct state on the respondent and incorrect state on the initiator. If we want to solve for this -- and I think there's good motivation for plugging these sorts of black hole situations in the name of a robust protocol -- I believe that a failed operation must always result in the side perceiving the failure to remove its state for the operation in progress; this is simple enough. The more difficult problem to deal with is what happens on the side if it believes that its side of the connection is fully formed? In the example above, Bob would have both SA's installed and not know that the network had partitioned. In this case, Bob may send to a blackhole at Alice and given current IPsec mechanisms, I don't believe there's a way to recover. One proposal I've heard is that Alice should initiate keying if she sees SPI's from an unknown source. The problem is that Alice does not necessarily have enough information to figure out how to re-create the SA. This is particularly true if there are multiple acceptible forms of identity, different selectors on each end, etc. Thus, it seems to me that the only reasonable thing that Alice can do is send Bob an unauthenticated message giving him a clue that something might be amiss. The natural thing to here is to send some sort of ICMP message, I think. When Bob receives the ICMP message, he doesn't really know for sure that the message wasn't spoofed, but he at least knows how to reinstantiate the SA. What seems like it would be useful is for Bob to try to first see if this was a spoofed attack in the case of IKE (KINK doesn't suffer from the sort of public key make-work DoS attack as IKE, so it's more ignorable). Also, it would be nice if Bob could basically pick up where they left off. That is, if the ISAKMP SA was already established, then it would be advantageous to keep using it if it were a quick mode SA that was half open. At this point, it would seem that Bob should just remove its old SA's, and initiate a fresh one. Since Alice had no state in the first place, I'd think that we'd be back in the ground state, and that we'd be fully recovered by then. What is probably the interesting question is how best to implement the test to check if the ICMP message was legitimate. Also, there's a question in my mind whether there's a need to check other SA's at the same time. This, I think, needs more work. If you made it down here, happy labor day (or end 'o vacation outside NA :-) Mike From owner-ipsec@lists.tislabs.com Mon Sep 3 23:25:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f846PbD29081; Mon, 3 Sep 2001 23:25:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA04334 Tue, 4 Sep 2001 01:29:04 -0400 (EDT) Message-ID: <005301c10381$cc587be0$dace1dd5@mahdavi> From: "mahdavi" To: "Christophe Gouault" Cc: "Puja Puri" , References: <001201c1019f$6116da40$dace1dd5@mahdavi> <3B93324B.86D68858@6wind.com> Subject: Re: inbound vs outbound? Date: Tue, 3 Jul 2001 10:02:35 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. Its Strange. I did not saw this matter that you said in RFC2401. there is no reason to look at SPD twice. do you think that we have two SPD for an ipsec system ? ( one for outbound and one for inbound !! ). but we just have one SPD per IPSEC system. Also I choosed native implementation s why I have to process one packet twice ? I have one Ipsec system for all interfaces with just one SPD. I choosed this Strategy. Every packet that is comming (iamgine it has not fragment problem) to my router will go to IPSEC system before that router do any thing for it. Ipsec makes a new packet ( perhaps same packet ) and gives it to router agian. After that router sends it on appropriate Interface. Imagine my router address is A. there are these kinds of packets. 1- A regular packet from B to C. Now I just put it under Outbound process. is there any thing wrong? ) . 2- An IPSEC packet that is not destined to my router. It is also outbound. is it wrong ? ). 3- An IPSEC packet that is destined to my machine. It is an inbound packet . Now it goes under inbound process. ( I can agree with you just in this case. after inbound process I gain another packet that. So it must go under outbound process.) Now I just redefine my opinion as the following sentence. "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" if this pharase has any error let me know. sincerely yours mahdavi. ----- Original Message ----- From: Christophe Gouault To: mahdavi Cc: Puja Puri ; Sent: Monday, 03 September, 2001 12:03 ÚÕÑ Subject: Re: inbound vs outbound? > Hello, > > "inbound" and "outbound" have nothing to do with IP addresses. Since your > machine forwards packets, each packet is processed twice by IPsec and is both > inbound and outbound : > first your packet is received on an interface, hence it is processed by IPsec as > "inbound". Then it is forwarded and sent on another interface : it is processed > by IPsec again, but as an "outbound" packet. > > Christophe. > > mahdavi wrote: > > > Hi > > U R right about hosts. > > But I am to design a security gateway in hardaware that is located in heart > > of a high speed router that has many interfaces. > > no packet is generating from my machine. so with your idea there is no > > outbound there. just pay attention to this fact that every packet that is > > destined to my machine is in tunnel mode. > > > > By now tell me what is wrong with my opinion > > > > "every packet is outbound else its destination IP is IP of this machine and > > it is in tunnel mode (this security gateway) ." > > ----- Original Message ----- > > From: Puja Puri > > To: mahdavi > > Cc: > > Sent: Thursday, 30 August, 2001 9:18 ÕÈÍ > > Subject: Re: inbound vs outbound? > > > > > I beg to defer from this point of view "that every packet that is not > > > destined for my machine is outbound". I feel that the packets that are > > > originating from ur machine are outbound and the remaining packets > > > recieved by ur machine are inbound irrespective of whether they r destined > > > for ur machine or they r forwarded(in which case they also become > > > outbound). > > > > > > Puja Puri > > > Member of Technical Staff > > > Networking and Internet Software Group > > > C-DAC > > > Pune > > > > > > On Wed, 29 Aug 2001, mahdavi wrote: > > > > > > > Hi. > > > > In a security gateway how you can distinguish between an Inbound packet > > and outbound packet? > > > > > > > > Is this correct ? > > > > "every packet is outbound else its destination IP is IP of this machine > > (this security gateway) . > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Sep 3 23:25:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f846PcD29279; Mon, 3 Sep 2001 23:25:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA04328 Tue, 4 Sep 2001 01:25:16 -0400 (EDT) Message-ID: <005201c10381$c7a18380$dace1dd5@mahdavi> From: "mahdavi" To: "Ramana Yarlagadda" Cc: "ipsec" , "Puja Puri" References: <4.3.2.7.1.20010903142108.00ba7960@golf.cpgdesign.analog.com> Subject: Re: inbound vs outbound? Date: Tue, 3 Jul 2001 10:02:29 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. (as I mentioned ) Its Strange. I did not saw this matter that you said in RFC2401. there is no reason to look at SPD twice. do you think that we have two SPD for an ipsec system ? ( one for outbound and one for inbound !! ). but we just have one SPD per IPSEC system. Also I choosed native implementation s why I have to process one packet twice ? I have one Ipsec system for all interfaces with just one SPD. I choosed this Strategy. Every packet that is comming (iamgine it has not fragment problem) to my router will go to IPSEC system before that router do any thing for it. Ipsec makes a new packet ( perhaps same packet ) and gives it to router agian. After that router sends it on appropriate Interface. Imagine my router address is A. there are these kinds of packets. 1- A regular packet from B to C. Now I just put it under Outbound process. is there any thing wrong? ) . 2- An IPSEC packet that is not destined to my router. It is also outbound. is it wrong ? ). 3- An IPSEC packet that is destined to my machine. It is an inbound packet . Now it goes under inbound process. ( I can agree with you just in this case. after inbound process I gain another packet that. So it must go under outbound process.) Now I just redefine my opinion as the following sentence. "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" if this pharase has any error let me know. sincerely yours mahdavi. From owner-ipsec@lists.tislabs.com Tue Sep 4 02:32:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f849WfD24443; Tue, 4 Sep 2001 02:32:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04752 Tue, 4 Sep 2001 04:34:52 -0400 (EDT) Message-ID: <3B949419.FE5508E8@6wind.com> Date: Tue, 04 Sep 2001 10:43:05 +0200 From: Christophe Gouault Organization: 6WIND X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: mahdavi Cc: Ramana Yarlagadda , ipsec , Puja Puri Subject: Re: inbound vs outbound? References: <4.3.2.7.1.20010903142108.00ba7960@golf.cpgdesign.analog.com> <005201c10381$c7a18380$dace1dd5@mahdavi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mahdavi, mahdavi wrote: > > Hi. > (as I mentioned ) > Its Strange. I did not saw this matter that you said in RFC2401. there is no > reason to look at SPD twice. In RFC2401's terminology, an "inbound" packet means a packet received on an interface, an "outbound" packet means a packet sent on an interface. I think you shouldn't use the terms "inbound" and "outbound" if you wish to express another concept. RFC2401, paragraph 4.4, states that "The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic." and also "Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis." It results that the SPD is consulted twice for forwarded packets. > do you think that we have two SPD for an ipsec system ? ( one for outbound > and one for inbound !! ). but we just have one SPD per IPSEC system. There are not necessarily two physically separate SPDs, but if you only have one SPD, you should add the "direction (inbound/outbound)" info in each entry. > [...] > > mahdavi. From owner-ipsec@lists.tislabs.com Tue Sep 4 04:32:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84BWfD03205; Tue, 4 Sep 2001 04:32:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04975 Tue, 4 Sep 2001 06:29:39 -0400 (EDT) From: mahdavi@sepahan.iut.ac.ir Message-Id: <200109041036.f84AaEQ10637@sepahan.iut.ac.ir> To: ipsec@lists.tislabs.com Subject: Re: inbound vs outbound? Date: Tue, 4 Sep 2001 05:31:13 GMT X-Mailer: Cafe MailMan v3.0.19 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. You R right. But pay attention to this fact that RFC is for all Implmentations. Now just verify this pharase ( if it is correct, and if it is not tell me Y ). "IF a regular packet received by our router and it was not tunneld to this router it is enough to apply just outbound process. " If above sentence is not correct let me know. (think about a security gateway --in arouter) sincerely yours mahdavi > > In RFC2401's terminology, > an "inbound" packet means a packet received on an interface, > an "outbound" packet means a packet sent on an interface. > > I think you shouldn't use the terms "inbound" and "outbound" if you wish > to express another concept. > > RFC2401, paragraph 4.4, states that "The SPD must be consulted during > the processing of all traffic (INBOUND and OUTBOUND), including > non-IPsec traffic." and also "Thus the administrative interface must > allow the user (or system administrator) to specify the security > processing to be applied to any packet entering or exiting the system, > on a packet by packet basis." > > It results that the SPD is consulted twice for forwarded packets. > > > There are not necessarily two physically separate SPDs, but if you only > have one SPD, you should add the "direction (inbound/outbound)" info in > each entry. > From owner-ipsec@lists.tislabs.com Tue Sep 4 06:47:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84DlcD09886; Tue, 4 Sep 2001 06:47:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05165 Tue, 4 Sep 2001 08:48:32 -0400 (EDT) To: mahdavi@sepahan.iut.ac.ir Cc: ipsec@lists.tislabs.com Subject: Re: inbound vs outbound? References: <200109041036.f84AaEQ10637@sepahan.iut.ac.ir> From: Derek Atkins Date: 04 Sep 2001 08:56:11 -0400 In-Reply-To: mahdavi@sepahan.iut.ac.ir's message of "Tue, 4 Sep 2001 05:31:13 GMT" Message-ID: Lines: 66 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, it is not enough. If IPsec is enabled on the inbound interface, then you MUST check the inbound packet against the SPD for that interface before relaying it. It does not matter _how_ the packet arrived; all that matters is that it arrived on a 'protected' interface. Ignore tunnels completely; they don't matter in this situation. -derek mahdavi@sepahan.iut.ac.ir writes: > Hi. > You R right. > But pay attention to this fact that RFC is for all Implmentations. > Now just verify this pharase ( if it is correct, and if it is not tell me > Y ). > > "IF a regular packet received by our router and it was not tunneld to this > router it is enough to apply just outbound process. " > > If above sentence is not correct let me know. (think about a security > gateway --in arouter) > > sincerely yours > > mahdavi > > > > > In RFC2401's terminology, > > an "inbound" packet means a packet received on an interface, > > an "outbound" packet means a packet sent on an interface. > > > > I think you shouldn't use the terms "inbound" and "outbound" if you wish > > to express another concept. > > > > RFC2401, paragraph 4.4, states that "The SPD must be consulted during > > the processing of all traffic (INBOUND and OUTBOUND), including > > non-IPsec traffic." and also "Thus the administrative interface must > > allow the user (or system administrator) to specify the security > > processing to be applied to any packet entering or exiting the system, > > on a packet by packet basis." > > > > It results that the SPD is consulted twice for forwarded packets. > > > > > > There are not necessarily two physically separate SPDs, but if you only > > have one SPD, you should add the "direction (inbound/outbound)" info in > > each entry. > > > > > > > > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Sep 4 08:56:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84Fu4D19683; Tue, 4 Sep 2001 08:56:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05395 Tue, 4 Sep 2001 10:56:33 -0400 (EDT) Message-Id: <200108311640.f7VGeZ024812@marajade.sandelman.ottawa.on.ca> To: Ari Huttunen cc: Jason Palmatier , ipsec@lists.tislabs.com Subject: Re: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE In-reply-to: Your message of "Tue, 28 Aug 2001 18:04:56 +0300." <3B8BB318.F210FC74@F-Secure.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Aug 2001 12:40:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ari" == Ari Huttunen writes: Ari> 40000 + number of bits in the group. Ari> It would be nice to have officially assigned numbers, though. Ari> Especially since you cannot negotiate this by having a VID, since Ari> they are used in the first message. Ari> The same restriction applies to the.. dare I say it?.. here goes.. Ari> X-Auth authentication type. There's no way to negotiate it's usage Ari> by using a VID. Our new software version sends this automatically, Ari> and a couple of vendors whose software refused any connection when Ari> they received an attribute they didn't understand, agreed to change Ari> their software that it skips a transform it doesn't fully understand Ari> and tries to match the next transform. Ari> The current RFCs do not state what to do when something like this Ari> happens.. i.e. an unknown attribute is received in a transform payload. I thought that you are supposed to ignore proposals that you do not understand. Where "understand" means either that you match: assigned #, (VID, private#) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Sep 4 08:56:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FuQD19769; Tue, 4 Sep 2001 08:56:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05433 Tue, 4 Sep 2001 11:00:34 -0400 (EDT) Message-ID: <001301c1342d$fa247330$e00210ac@cwcrrjkrrcfonk> From: "Hong Gie Ong" To: , References: <3B9133CD.6DCE42AF@vt.edu> Subject: Re: key management protocols Date: Mon, 3 Sep 2001 12:07:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm also in the starting phase of doing research on key management in a future wireless scenario based on Mobile-IP; here's a quick link to start with: http://citeseer.nj.nec.com/boyd98public.html There's enough to read and maybe we could exchange relevant info. The key word is "simple": keep it simple. I guess that's kind of the overall summary of discussions that have been going on in the lists, complexity in system design is the enemy of correctness, in this case, of security. (quoted) Also you should determine your scope 'cause there's too much information out there to cover it all; which layer etc. Finally, keep track of the important developments in the lists, like MIPv6 and this list, gan bei!! Hong Gie Ong EE M.Sc. student ----- Original Message ----- From: "George Hadjichristofi" To: Sent: Sunday, September 02, 2001 3:15 AM Subject: key management protocols > Hi everyone, > I am new on this list. I am planning on doing a research on the > weaknesses of key management protocols. I have read about Photuris, > SKEME,SKIP, OAKLEY, and ISAKMP, but I am not sure what is used in the > industry. > > Which are the most important key management protocol implementations > that are currently used? Am I missing any protocol? Where can i get more > info? > > Thanks for your help. > George > > -- > ************************************************* > George C. Hadjichristofi > Graduate Student,Computer Engineering Department > Virginia Tech,Blacksburg,VA 24061,U.S.A > TEL:(540)-951-8936 FAX:(775)-361-1201 > ************************************************* > > > From owner-ipsec@lists.tislabs.com Tue Sep 4 08:57:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84Fv1D19892; Tue, 4 Sep 2001 08:57:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05479 Tue, 4 Sep 2001 11:04:22 -0400 (EDT) Message-Id: <200109041511.AAL68817@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 04 Sep 2001 07:53:04 -0700 To: mahdavi@sepahan.iut.ac.ir, ipsec@lists.tislabs.com From: Scott Fluhrer Subject: Re: inbound vs outbound? In-Reply-To: <200109041036.f84AaEQ10637@sepahan.iut.ac.ir> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:31 PM 9/3/01 , mahdavi@sepahan.iut.ac.ir wrote: >Hi. >You R right. >But pay attention to this fact that RFC is for all Implmentations. >Now just verify this pharase ( if it is correct, and if it is not tell me >Y ). > >"IF a regular packet received by our router and it was not tunneld to this >router it is enough to apply just outbound process. " > >If above sentence is not correct let me know. (think about a security >gateway --in arouter) That is not correct. Again, RFC2401 states "The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic." One of the things that sentence implies is that all inbound non-ESP-for-us traffic must be checked against the SPD to verify whether it should have been encrypted, and drop it if it should have been. Here is an attack that can happen if you don't follow this rule. Suppose that there is a packet that the attacker wants to inject into the system. It might be, for example, a UDP packet that kicks off an RPC procedure on the target system. Since the attacker has access only to an section of the cloud where all such packets are IPSec protected, he shouldn't be able to do so. However, with your proposed method, all the attacker would have to do is inject the packet in the clear. When this packet hits the security gateway, he'll see that it didn't have the router as the destination, and hence just forward it on, and hence, the attacker has won. > >sincerely yours > >mahdavi > >> >> In RFC2401's terminology, >> an "inbound" packet means a packet received on an interface, >> an "outbound" packet means a packet sent on an interface. >> >> I think you shouldn't use the terms "inbound" and "outbound" if you wish >> to express another concept. >> >> RFC2401, paragraph 4.4, states that "The SPD must be consulted during >> the processing of all traffic (INBOUND and OUTBOUND), including >> non-IPsec traffic." and also "Thus the administrative interface must >> allow the user (or system administrator) to specify the security >> processing to be applied to any packet entering or exiting the system, >> on a packet by packet basis." >> >> It results that the SPD is consulted twice for forwarded packets. >> >> >> There are not necessarily two physically separate SPDs, but if you only >> have one SPD, you should add the "direction (inbound/outbound)" info in >> each entry. >> > From owner-ipsec@lists.tislabs.com Tue Sep 4 08:57:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FvGD19954; Tue, 4 Sep 2001 08:57:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05446 Tue, 4 Sep 2001 11:02:08 -0400 (EDT) Message-ID: <0333DB893597D311920D0090279AA8F004D19D8B@apmail3.sgp.agilent.com> From: "MAHAPATRA,ARIJIT (A-India,ex1)" To: "'ipsec@lists.tislabs.com'" Subject: RSA Signature with IKE Date: Mon, 3 Sep 2001 19:57:07 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have few questions regarding RSA signatures when used as the authenticatation method for IKE. 1) There are 2 signature generation schemes defined in RSA PKCS#1 - RSASSA-PKCS1-v1.5 and RSASSA-PSS and corresponding 2 separate verification schemes. Which is to be followed? 2) The private key can have 2 alternate formats: which one one should work with? 3) In Main Mode M5(/M6) what would it contain in SIG_I(/SIG_R)payload ? Only the Signature or Signature apppended to message HASH_I(/HASH_R). 4) What is meant by the following snippet from RFC 2409 ? "Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format and not as a signature in PKCS #1 format (which includes the OID of the hash algorithm)." 5) In real-world how a DUT/Security Gateway obtains Certificates from a Certificate Authority? How OpenSSL sofware can be used in this respect? Any help in form of suggesttion/feedback/link is highly appreciated. Thanks in advance! --Regards, Arijit. From owner-ipsec@lists.tislabs.com Tue Sep 4 08:58:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FwGD20143; Tue, 4 Sep 2001 08:58:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05465 Tue, 4 Sep 2001 11:03:35 -0400 (EDT) Reply-To: From: "Sridhar J" To: "Ipsec \(E-mail\)" Subject: ceritficate authority for testing Date: Tue, 4 Sep 2001 14:59:35 +0530 Message-Id: <002b01c13524$1d351f40$2702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , can anyone give some pointers on how to set up a ceritificate authority to be used for testing. I am preparing a test bed for testing ike software with certificate. Is there any free software availble which can be installed in Windows/Linux to act a Certification Authority and handle Certificate request for clients ex: Cisco router or Win 2K machines. thanks in advance regards, sridhara .j future software ltd chennai www.futsoft.com From owner-ipsec@lists.tislabs.com Tue Sep 4 08:58:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FwtD20269; Tue, 4 Sep 2001 08:58:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05372 Tue, 4 Sep 2001 10:55:34 -0400 (EDT) Message-Id: <200108311628.f7VGSFr24588@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, design@lists.freeswan.org Subject: Re: [Design] Re: opportunistic encryption deployment problems In-reply-to: Your message of "Tue, 21 Aug 2001 08:03:25 +0300." <018401c129fe$9bdd7b20$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Aug 2001 12:28:15 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> I very much like the idea of opportunistic encryption. However, Jari> I'm concerned on the reliance on secure DNS as the only Jari> authentication mechanism. While I do like how OE can be Certainly other systems of authentication can be created. The appeal of the reverse map is that control over reverse map is usually sufficient proof that you control the IP address. Unfortunately, it turns out to be too strong, as there are many people who feel they own their IP address, but do not own the reverse map. In gateway mode OE, one has only an IP address to go on. The only way we can get a different key is to involve the application in some way. Jari> used from small to large deployment of DNSSEC, I'm Jari> concerned that (a) DNSSEC will eventually bring the same Jari> trouble as a large scale PKI would [such as the worries Jari> about people being able to control their reverse mappings Jari> or their DNS at all], and (b) it may not be the most effective Jari> weak authentication scheme [and it is weak until the root Jari> gets signed]. These are certainly true claims. Given that people have difficulty getting control over their reverse maps, getting the additional leap of faith to get things signed may be asking far too much. Jari> In particular, I wonder if ssh-like leap-of-faith authentication at Jari> the time of first contact and subsequent strong authentication Jari> would be a better weak authentication scheme. Not much memory Jari> is needed for this, just a mapping from a claimed identity to Jari> a hash of the public key. Additionally, this has the benefit that I would agree that this is another approach. The SPP gateway discovery system could easily be modified to do this kind of thing. It has the additional advantage of discovering the topologically closest gateway. There have been comments that this won't work in the face of routing changes, but if there are routing changes, then one has to establish new tunnels anyway. SPP is supposed to be sent periodically. Jari> There are also other possibilities for making unauthenticated Jari> encryption become weak encryption. How about using server Jari> side certificates in part, noting that many servers already have Jari> them due to SSL? Then the other side would be authenticated If they already have them due to SSL, then they are probably using HTTPS only. Why secure this? We are concerned about securing all packets between all peers (not just clients and servers). ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO4+6lYqHRg3pndX9AQGp9wQA1DbnQ7wQ6QmtcysVAETxpgtUCWkKM8vb fe8/j18njndxUMql/LNZBc1SN41d2s2Fb4BBPrV+mtu/GPy8mKLD+XElS07Zfnvu CEEk34+ZVhaU6cId818WhsyZXKMss0dN9PutcXAKY9+Zlo9RjTh8NEO9wlZgbEdo cAmRw2C7bAc= =wYnv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Sep 4 08:59:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FxWD20405; Tue, 4 Sep 2001 08:59:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05371 Tue, 4 Sep 2001 10:55:34 -0400 (EDT) Message-Id: <200108311629.f7VGTBe24608@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, design@lists.freeswan.org Subject: Re: [Design] Re: opportunistic encryption deployment problems In-reply-to: Your message of "Tue, 21 Aug 2001 16:05:16 +0300." <3B825C8C.25906347@lmf.ericsson.se> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Aug 2001 12:29:11 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> Well... I'm not really on expert how secure DNS works, but Jari> in order for the in-addr.arpa zone to be signed, doesn't Jari> some big entity somewhere have to actually get down to Jari> doing this? I.e., we as a group of OE interested people Yes, but it needn't be as politically difficult as signing .com. In the meantime, we can publish lists of secure zones with contact information and do PGP-like web-of-trust stuff. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO4+7VoqHRg3pndX9AQGevwP9FxAWxiFD7ESaFLsg3FGG5fAfLBG4BkjY KQQOM4uBUdb373/8MpoaGAsBoKhVb0/qwNRND7cSltcKJdT8KY6rahlUkTML2X4W a66u/wy4bsIAgrmjtoFSz4KtGzWGpXGtPJnJ87wjaoME8Wk2yC1Z1U26apny1v/G aD4Xin+eqaU= =4WEu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Sep 4 09:01:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84G1kD20883; Tue, 4 Sep 2001 09:01:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05505 Tue, 4 Sep 2001 11:07:36 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: Subject: RE: Notify SPI field specifications Date: Tue, 4 Sep 2001 11:07:05 -0400 Message-Id: <004401c13553$51e03390$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <200108291730.f7THUfq00632@dharkins@lounge.orgatty.lounge.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Merging the documents is not a magic wand you can wave in > order to make the > > documents clearer; you actually have to write the text clearly and > > unambiguously. > > I never said it was a magic wand. I said it would clean up > just the sort > of confusion that started this thread: one document saying > one thing and > another saying something different. If there is one document then that > problem doesn't happen. I think that's a rather over-simplified line of reasoning, along the lines of the prevailing modern attitude that it's usually better to be unambiguous than correct. I've seen documentation split up in order to "clarify things," and I've seen the same documents consolidated in order to "clarify things." The second generation of documents is rarely any better than the first, usually because it was written with a reactionary and/or idealistic mindset. The same result usually applies to second generation code as well, mostly for the same reasons. > > Perhaps the problem is that RFC2409 didn't need to be a generic key > > exchange. Isn't it possible that only one of the 3 > documents is confusing? > > Criticizing your own document due to circumstances beyond > your control seems > > like passing the buck. > > No it didn't and no I don't think so. You may be able to > explain the true > meaning of the Commit Bit by just reading RFC2408 but no one else can. > And I don't think anyone can justify the seemingly mandated > covert channel > in RFC2408. The way I read it, [ISAKMP] specifies what the commit bit field is for, but doesn't say when to set it, or in which message to send the CONNECTED notify. That seems perfectly reasonable to me. [IKE] could have and should have constrained this further. Instead of being a focused protocol description, [IKE] is more of a mishmash of all the bits and pieces that were left open by [ISAKMP]. Why are the DH groups copied here, and not just referenced in the DOI like the ciphers? The myriad of implementation hints scattered throughout reads like a list of things not to do that someone obviously did at a bakeoff at some point. The problem, in my mind, is that [IKE] wouldn't make any sense to someone who hasn't read and absorbed [ISAKMP]. That's the wrong order. Instead, the IKE document would be easier to comprehend if it described the protocol behaviour, and referred to [ISAKMP] whenever necessary in order to fill in the details. It distresses me that you seem intent on a large scale (and slow) complete revamping of the protocol (with all the arguing and interoperability problems) when a smaller and quicker tweaking of one aspect of the protocol would suffice. > We have payloads being defined in one document and redefined > in another. Whole payloads? > We have overly generic descriptions of things simply because > there is this > artificial layering of the documents. That will all go away. I, for one, happen to not find the distinction between (among other things) the data model and the protocol details to be an artificial layering. If it is then someone better go tell IPSP, cuz they're screwing this one up big time. > > I keep hearing, without substantiation, that having a DOI > has greatly > > complicated IKE. However, I have noticed that 4 other > groups have exploited > > this feature to create keying protocols with much reduced > effort, and all > > without any extra work by me. > The artificial layering has creatly complicated the key > management protocol > for IPsec. It is completely unnecessary. The problem that the > DOI adds is > not only one of added genericicity (the attempt to be vague enough to > satisfy all sorts of possible key management protocols) but > it encourages > people to overload one single port with all sorts of security > protocols. > That is A Bad Thing. It is the generalized concept of a DOI that is useful, not the DOI field in various payloads or the ability to demultiplex on a single port. Probably the document should say not to do that. > Which 4 keying protocols have been created with the DOI > concept? KINK? No. > GDOI? Sort of but not really. OSPF DOI? That died. RIP DOI? > That died too. Literally using a DOI: OSPF, RIP, MPLS, MAP. Sort of using a DOI: KINK, GDOI. In all of these cases, it appeared to me that the work of the protocol designers was reduced by reusing the ISAKMP framework. > > > "I personally think it is very dangerous to organize > > > referendums when you're not sure to win them" > > > -- Louis Michel, President of the European Union > > > > You can aways hold another referendum next year, and keep > holding them once > > every few years until you win. > > You of all people should not be making fun of someone's sig. > I've left your > pompous one below for comparison. For the record, I wasn't actually making fun of your sig. I was merely commenting that perhaps Louis Michel could learn a thing or two from the government of Quebec. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Tue Sep 4 10:38:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HcwD22953; Tue, 4 Sep 2001 10:38:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05771 Tue, 4 Sep 2001 12:30:28 -0400 (EDT) From: Bill Manning Message-Id: <200109041636.f84Ga7c01486@zed.isi.edu> Subject: Re: [Design] Re: opportunistic encryption deployment problems To: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 4 Sep 2001 09:36:06 -0700 (PDT) Cc: ipsec@lists.tislabs.com, design@lists.freeswan.org In-Reply-To: <200108311629.f7VGTBe24608@marajade.sandelman.ottawa.on.ca> from "Michael Richardson" at Aug 31, 2001 12:29:11 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % In the meantime, we can publish lists of secure zones with contact % information and do PGP-like web-of-trust stuff. So, does anyone have a signed zone in the in-addr.arpa tree? -- --bill From owner-ipsec@lists.tislabs.com Tue Sep 4 10:44:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HiXD23101; Tue, 4 Sep 2001 10:44:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05834 Tue, 4 Sep 2001 12:55:38 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6C8@CORPMX14> To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: RE: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE Date: Tue, 4 Sep 2001 12:56:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2407 says: 4.5.3 Attribute Negotiation If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range. If an implementation receives an attribute value in the reserved range, an implementation MAY chose to continue based on local policy. This is a problem for adding new SA attributes because including an alternate proposal doesn't help. I believe there was agreement on the list that the text in the first paragraph above is too aggressive and should be replaced by a requirement to ignore any proposal containing an unsupported attribute or value. --David > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, August 31, 2001 12:41 PM > To: Ari Huttunen > Cc: Jason Palmatier; ipsec@lists.tislabs.com > Subject: Re: IKEv2 stuff.. Re: More MODP Diffie-Hellman > groups for IKE > > > > >>>>> "Ari" == Ari Huttunen writes: > Ari> 40000 + number of bits in the group. > > Ari> It would be nice to have officially assigned numbers, though. > Ari> Especially since you cannot negotiate this by having > a VID, since > Ari> they are used in the first message. > > Ari> The same restriction applies to the.. dare I say > it?.. here goes.. > Ari> X-Auth authentication type. There's no way to > negotiate it's usage > Ari> by using a VID. Our new software version sends this > automatically, > Ari> and a couple of vendors whose software refused any > connection when > Ari> they received an attribute they didn't understand, > agreed to change > Ari> their software that it skips a transform it doesn't > fully understand > Ari> and tries to match the next transform. > > Ari> The current RFCs do not state what to do when > something like this > Ari> happens.. i.e. an unknown attribute is received in a > transform payload. > > I thought that you are supposed to ignore proposals that you do not > understand. Where "understand" means either that you match: > assigned #, > (VID, private#) > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Sep 4 10:46:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84HktD23152; Tue, 4 Sep 2001 10:46:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05811 Tue, 4 Sep 2001 12:53:25 -0400 (EDT) Message-Id: <3.0.5.32.20010904174705.0400d7c0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 04 Sep 2001 17:47:05 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: RSA Signature with IKE In-Reply-To: <0333DB893597D311920D0090279AA8F004D19D8B@apmail3.sgp.agile nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA05570 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:57 03.09.01 +0900, MAHAPATRA,ARIJIT (A-India,ex1) wrote: > >1) There are 2 signature generation schemes defined in RSA PKCS#1 - >RSASSA-PKCS1-v1.5 and > RSASSA-PSS and corresponding 2 separate verification schemes. Which is to >be followed? > No idea, don't have that document on me right now, but see below. >2) The private key can have 2 alternate formats: which one one should work >with? > Your problem. Use whatever. PKCS#1, PKCS#8, PKCS#12 all do fine. Maybe... (gasp) support them all! >3) In Main Mode M5(/M6) what would it contain in SIG_I(/SIG_R)payload ? > Only the Signature or Signature apppended to message HASH_I(/HASH_R). > Only the signature, please. >> (4) > Therefore, RSA signatures MUST be encoded as a private > key encryption in PKCS #1 format and not as a signature in PKCS #1 > format (which includes the OID of the hash algorithm)." > This may be the most important hint of them all. There are several ways to sign stuff with RSA. The question is, do you want to hash the data first or not? If not, Pad the data (20 bytes, I guess) and run the RSA algorithm over it. If yes, hash it, put some DER encoding around it, including the hash algorithm, pad it, and run the RSA algorithm over it. BTW, for IKE, the answer is "NO". For instance, in PKCS#11, there is: CKM_RSA_PKCS CKM_MD5_RSA_PKCS CKM_SHA1_RSA_PKCS CKM_MD2_RSA_PKCS The first one does not hash the data or even put some DER-encoding into the sig. Therefore, it's the one you want for IKE. You don't want the other 3 ones. Heck, no. I have no idea what crypto lib you're using. So you have to figure out what to call by yourself. >5) In real-world how a DUT/Security Gateway obtains Certificates from a >Certificate Authority? > How OpenSSL sofware can be used in this respect? > Real world? (1) You copy files around on floppy disks. (2) Use (1) + cut&paste&someCAwebinterface (3) You use SCEP (4) You use one of them new protocols. For starters, use OpenSSL to generate a PKCS#12 bundle and use that directly in your GW. If that's too complicated, you can cut a PKCS#12 into pieces using OpenSSL. Maybe into a Cert and a PKCS#1 key. J–rn From owner-ipsec@lists.tislabs.com Tue Sep 4 11:12:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84IC4D23675; Tue, 4 Sep 2001 11:12:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05914 Tue, 4 Sep 2001 13:27:23 -0400 (EDT) Message-Id: <200109041732.f84HWQ000659@dharkins@lounge.orgatty.lounge.org> To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: Re: Notify SPI field specifications In-Reply-To: Your message of "Tue, 04 Sep 2001 11:07:05 EDT." <004401c13553$51e03390$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <656.999624746.1@lounge.org> Date: Tue, 04 Sep 2001 10:32:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 04 Sep 2001 11:07:05 EDT you wrote > > I've seen documentation split up in order to "clarify things," and I've seen > the same documents consolidated in order to "clarify things." The second > generation of documents is rarely any better than the first, usually because > it was written with a reactionary and/or idealistic mindset. The same result > usually applies to second generation code as well, mostly for the same > reasons. Which group of documents were both consolidated and split up to "clarify things"? It would be very interesting to compare the outcomes. A hint on the mindset ("reactionary and/or idealistic") for both outcomes would also be quite interesting. Please provide pointers to these documents. > Instead of being a focused protocol description, [IKE] is more of a mishmash > of all the bits and pieces that were left open by [ISAKMP]. Why are the DH > groups copied here, and not just referenced in the DOI like the ciphers? I don't think you understand.... IKE was supposed to be a generic exchange under which multiple DOIs could be implemented. It has to create its own SA which is different than the DOI-defined SA and therefore has to be able to do this independent of any DOI. The DH groups are critical to establishing the IKE SA! They cannot just be referenced in a DOI! If there were copied from anywhere they were copied from Oakley, not ISAKMP (or even [ISAKMP]). Similarly the ciphers necessary to construct the IKE SA are defined in IKE. They are not "just referenced in the DOI". I think it is safe to say that there are more people than just you who did not or do not understand how these things were done so let me point out again that if these layers go away these misunderstandings about the layers do too. Dan. "I personally think it is very dangerous to organize referendums when you're not sure to win them" -- Louis Michel, President of the European Union From owner-ipsec@lists.tislabs.com Tue Sep 4 12:02:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84J2lD22228; Tue, 4 Sep 2001 12:02:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06005 Tue, 4 Sep 2001 14:05:06 -0400 (EDT) Date: Tue, 4 Sep 2001 19:18:31 +0200 (MEST) From: Jakob Schlyter To: Michael Richardson Cc: , Subject: Re: [Design] Re: opportunistic encryption deployment problems In-Reply-To: <200108311629.f7VGTBe24608@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 31 Aug 2001, Michael Richardson wrote: > In the meantime, we can publish lists of secure zones with contact > information and do PGP-like web-of-trust stuff. you can not do PGP-like web-of-trust within DNSsec as all signatures needs to be strictly hierarchical. or do you mean distributing lists of secure zones together with their public keys using PGP? jakob From owner-ipsec@lists.tislabs.com Tue Sep 4 12:16:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84JGeD24541; Tue, 4 Sep 2001 12:16:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06097 Tue, 4 Sep 2001 14:30:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <005301c10381$cc587be0$dace1dd5@mahdavi> References: <001201c1019f$6116da40$dace1dd5@mahdavi> <3B93324B.86D68858@6wind.com> <005301c10381$cc587be0$dace1dd5@mahdavi> Date: Tue, 4 Sep 2001 14:35:39 -0400 To: "mahdavi" From: Stephen Kent Subject: Re: inbound vs outbound? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:02 AM +0430 7/3/01, mahdavi wrote: >Hi. >Its Strange. I did not saw this matter that you said in RFC2401. there is no >reason to look at SPD twice. > >do you think that we have two SPD for an ipsec system ? ( one for outbound >and one for inbound !! ). but we just have one SPD per IPSEC system. 2401 describes the SPD in terms of inbound and outbound traffic on a per interface basis. one can have one SPD IF it tags entries on a per-interface basis and based on directionality, but that becomes equivalent to per-interface, per-direction SPDs. > >Also I choosed native implementation s why I have to process one packet >twice ? I have one Ipsec system for all interfaces with just one SPD. one need not lookup a packet in the SPD twice. An IPsec-protected packet arriving from the Internet and directed to a system behind an SG is lookup up once in the SAD, to map it to an SA, and the processed packet is then lookup up in the SPD to ensure that it is consistent with the SA via which it was received. Steve From owner-ipsec@lists.tislabs.com Tue Sep 4 16:57:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84Nv2D03283; Tue, 4 Sep 2001 16:57:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06740 Tue, 4 Sep 2001 19:09:49 -0400 (EDT) Message-ID: <00a401c10416$8e5f81e0$ccce1dd5@mahdavi> From: "mahdavi" To: "ipsec" References: <4.3.2.7.1.20010903142108.00ba7960@golf.cpgdesign.analog.com> <005201c10381$c7a18380$dace1dd5@mahdavi> <3B949419.FE5508E8@6wind.com> Subject: Re: inbound vs outbound? Date: Tue, 3 Jul 2001 14:52:57 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. You R right. But pay attention to this fact that RFC is for all Implmentations. Now just verify this pharase ( if it is correct, and if it is not tell me Y ). "IF a regular packet received by our router and it was not tunneld to this router it is enough to apply just outbound process. " If above sentence is not correct let me know. (think about a security gateway --in arouter) sincerely yours mahdavi > > In RFC2401's terminology, > an "inbound" packet means a packet received on an interface, > an "outbound" packet means a packet sent on an interface. > > I think you shouldn't use the terms "inbound" and "outbound" if you wish > to express another concept. > > RFC2401, paragraph 4.4, states that "The SPD must be consulted during > the processing of all traffic (INBOUND and OUTBOUND), including > non-IPsec traffic." and also "Thus the administrative interface must > allow the user (or system administrator) to specify the security > processing to be applied to any packet entering or exiting the system, > on a packet by packet basis." > > It results that the SPD is consulted twice for forwarded packets. > > > There are not necessarily two physically separate SPDs, but if you only > have one SPD, you should add the "direction (inbound/outbound)" info in > each entry. > From owner-ipsec@lists.tislabs.com Tue Sep 4 16:57:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NvQD03297; Tue, 4 Sep 2001 16:57:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06762 Tue, 4 Sep 2001 19:11:07 -0400 (EDT) Message-ID: <00a801c10416$9149a980$ccce1dd5@mahdavi> From: "mahdavi" To: "Stephen Kent" Cc: References: <001201c1019f$6116da40$dace1dd5@mahdavi> <3B93324B.86D68858@6wind.com><005301c10381$cc587be0$dace1dd5@mahdavi> Subject: Re: inbound vs outbound? Date: Wed, 4 Jul 2001 03:43:03 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. many thanks for your comments. but > > 2401 describes the SPD in terms of inbound and outbound traffic on a > per interface basis. one can have one SPD IF it tags entries on a > per-interface basis and based on directionality, but that becomes > equivalent to per-interface, per-direction SPDs. > > > > >Also I choosed native implementation s why I have to process one packet > >twice ? I have one Ipsec system for all interfaces with just one SPD. > > one need not lookup a packet in the SPD twice. An IPsec-protected > packet arriving from the Internet and directed to a system behind an > SG is lookup up once in the SAD, to map it to an SA, and the > processed packet is then lookup up in the SPD to ensure that it is > consistent with the SA via which it was received. > > Steve I am implementing Ipsec as native in heart of a router. My Ipsec has not any contact to any interface. It dont knows anything about Interface for a certain packet. It dont knows which interface this packet came from. Inbound SPD and outbound SPD is same in my design. no differ between them. ----------------\ | ______________ ------------ | / | | | ___|____|____|____ / \ | __________ | ROUTER / \ -------| | | | | IPSEC | | | | | | system | -------| | | | | | | | | | \__________/ | | \__________________/ | | | | | | ----------/ | | | \________ | look at above figure. there is many interfaces but there is no relation between interface and IPsec. router work in this manner that gives every packet that is comming on any interface to IPsec. IPsec system will act on it then it generates new packet and gives it back to the router. then router will continue his work. right now let me now what is wrong with this sentence in such situation. "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" best wishes mahdavi. From owner-ipsec@lists.tislabs.com Tue Sep 4 16:59:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NxQD03322; Tue, 4 Sep 2001 16:59:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06750 Tue, 4 Sep 2001 19:09:59 -0400 (EDT) Message-ID: <00a601c10416$8fd86640$ccce1dd5@mahdavi> From: "mahdavi" To: "Derek Atkins" Cc: References: <200109041036.f84AaEQ10637@sepahan.iut.ac.ir> Subject: Re: inbound vs outbound? Date: Wed, 4 Jul 2001 03:21:59 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. thanks for your interest. > No, it is not enough. If IPsec is enabled on the inbound interface, > then you MUST check the inbound packet against the SPD for that > interface before relaying it. It does not matter _how_ the packet > arrived; all that matters is that it arrived on a 'protected' > interface. > > Ignore tunnels completely; they don't matter in this situation. > > -derek > forget about interfaces. I am implementing Ipsec as native in heart of a router. My Ipsec has not any contact to any interface. It dont knows anything about Interface for a certain packet. It dont knows which interface this packet came from. Inbound SPD and outbound SPD is same in my design. no differ between them. ----------------\ | ______________ ------------ | / | | | ___|____|____|____ / \ | __________ | ROUTER / \ -------| | | | | IPSEC | | | | | | system | -------| | | | | | | | | | \__________/ | | \__________________/ | | | | | | ----------/ | | | \________ | look at above figure. there is many interfaces but there is no relation between interface and IPsec. router work in this manner that gives every packet that is comming on any interface to IPsec. IPsec system will act on it then it generates new packet and gives it back to the router. then router will continue his work. in this manner are still say that below sentence is wrong ? "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" by now I think that above sentence is right. let me know your opinion. many thanks before sincerely yours mahdavi. From owner-ipsec@lists.tislabs.com Tue Sep 4 16:59:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NxkD03341; Tue, 4 Sep 2001 16:59:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06746 Tue, 4 Sep 2001 19:09:54 -0400 (EDT) Message-ID: <00a701c10416$9087e020$ccce1dd5@mahdavi> From: "mahdavi" To: , "Scott Fluhrer" References: <200109041511.AAL68817@mira-sjcm-3.cisco.com> Subject: Re: inbound vs outbound? Date: Wed, 4 Jul 2001 03:35:12 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. > That is not correct. Again, RFC2401 states "The SPD must be consulted > during the processing of all traffic (INBOUND and OUTBOUND), including > non-IPsec traffic." I did not said that I dont consult SPD. I just said "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" so you can see that I consult SPD in outbound process. > Here is an attack that can happen if you don't follow this rule. Suppose > that there is a packet that the attacker wants to inject into the system. > It might be, for example, a UDP packet that kicks off an RPC procedure on > the target system. Since the attacker has access only to an section of > the cloud where all such packets are IPSec protected, he shouldn't be > able to do so. However, with your proposed method, all the attacker > would have to do is inject the packet in the clear. When this packet > hits the security gateway, he'll see that it didn't have the router as > the destination, and hence just forward it on, and hence, the attacker > has won. > Oooooh. you R wrong with my opinion. I just said "every packet is outbound else it destined to my machine in tunnel mode. after inbound process on such a packet I have to process it as outbound" you can see that any packet will go under outbound IPsec operation according to my opinion. so you attacker cant win me . ok ? am I right ? It is better for me to redefine my sentence as follows. look at below figure. ----------------\ | ______________ ------------ | / | | | ___|____|____|____ / \ | __________ | ROUTER / \ -------| | | | | IPSEC | | | | | | system | -------| | | | | | | | | | \__________/ | | \__________________/ | | | | | | ----------/ | | | \________ | it has many interfaces but there is no relation between interfaces and IPsec system. router work in this manner that gives every packet that is comming on any interface to IPsec. IPsec system will act on it then it generates new packet and gives it back to the router. then router will continue his work. best regards mahdavi From owner-ipsec@lists.tislabs.com Tue Sep 4 17:05:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8505YD03444; Tue, 4 Sep 2001 17:05:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06802 Tue, 4 Sep 2001 19:27:38 -0400 (EDT) Message-ID: <006901c1359a$4171d760$34dcd03f@diver> From: "Gregory Stark" To: References: <3.0.5.32.20010904174705.0400d7c0@smtp.datafellows.com> Subject: Re: RSA Signature with IKE Date: Tue, 4 Sep 2001 19:35:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It will be less confusing if the poster retrieves the PKCS#1 ver. 1.5 document. He is probably looking at the PKCS#1 ver. 2+ document which is almost unreadable. ====================== Greg Stark ghstark@pobox.com ====================== ----- Original Message ----- From: "Joern Sierwald" To: Sent: Tuesday, September 04, 2001 11:47 AM Subject: Re: RSA Signature with IKE > At 19:57 03.09.01 +0900, MAHAPATRA,ARIJIT (A-India,ex1) wrote: > > > >1) There are 2 signature generation schemes defined in RSA PKCS#1 - > >RSASSA-PKCS1-v1.5 and > > RSASSA-PSS and corresponding 2 separate verification schemes. Which is to > >be followed? > > > > No idea, don't have that document on me right now, but see below. > > >2) The private key can have 2 alternate formats: which one one should work > >with? > > > > Your problem. Use whatever. PKCS#1, PKCS#8, PKCS#12 all do fine. > Maybe... (gasp) support them all! > > >3) In Main Mode M5(/M6) what would it contain in SIG_I(/SIG_R)payload ? > > Only the Signature or Signature apppended to message HASH_I(/HASH_R). > > > > Only the signature, please. > > >> (4) > > Therefore, RSA signatures MUST be encoded as a private > > key encryption in PKCS #1 format and not as a signature in PKCS #1 > > format (which includes the OID of the hash algorithm)." > > > > This may be the most important hint of them all. > > There are several ways to sign stuff with RSA. The question is, > do you want to hash the data first or not? > If not, Pad the data (20 bytes, I guess) and run the RSA algorithm > over it. If yes, hash it, put some DER encoding around it, including > the hash algorithm, pad it, and run the RSA algorithm over it. > > BTW, for IKE, the answer is "NO". > > For instance, in PKCS#11, there is: > > CKM_RSA_PKCS > CKM_MD5_RSA_PKCS > CKM_SHA1_RSA_PKCS > CKM_MD2_RSA_PKCS > > The first one does not hash the data or even put some DER-encoding > into the sig. Therefore, it's the one you want for IKE. > You don't want the other 3 ones. Heck, no. > > I have no idea what crypto lib you're using. So you have to figure out > what to call by yourself. > > >5) In real-world how a DUT/Security Gateway obtains Certificates from a > >Certificate Authority? > > How OpenSSL sofware can be used in this respect? > > > > Real world? > (1) You copy files around on floppy disks. > (2) Use (1) + cut&paste&someCAwebinterface > (3) You use SCEP > (4) You use one of them new protocols. > > For starters, use OpenSSL to generate a PKCS#12 bundle and use that > directly in your GW. If that's too complicated, you can cut a PKCS#12 > into pieces using OpenSSL. Maybe into a Cert and a PKCS#1 key. > > > J-rn > From owner-ipsec@lists.tislabs.com Tue Sep 4 18:49:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851nTD22553; Tue, 4 Sep 2001 18:49:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07076 Tue, 4 Sep 2001 21:09:09 -0400 (EDT) Message-Id: <200109050107.KAA09473@csnet1.cs.tsinghua.edu.cn> Date: Wed, 5 Sep 2001 9:16:27 +0800 From: dxh Reply-To: sleepy-cat@263.net To: Stephen Kent CC: "ipsec@lists.tislabs.com" Subject: Re: Re: inbound vs outbound? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >one need not lookup a packet in the SPD twice. An IPsec-protected >packet arriving from the Internet and directed to a system behind an >SG is lookup up once in the SAD, to map it to an SA, and the >processed packet is then lookup up in the SPD to ensure that it is >consistent with the SA via which it was received. Consider the case that there is a tunnel from router A to router B where packets of class P are transmitted. When the packets arrive at router B, some of them, say subclass P1, are forward to a lan directly. Others, say subclass P2, are tunneled to router C. I don't think only one consult of SPD can achieve it. Dong Xiaohu sleepy-cat@263.net From owner-ipsec@lists.tislabs.com Tue Sep 4 18:49:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851nYD23022; Tue, 4 Sep 2001 18:49:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07068 Tue, 4 Sep 2001 21:08:06 -0400 (EDT) Date: Tue, 4 Sep 2001 18:14:54 -0700 (PDT) From: Scott Fluhrer To: mahdavi cc: Subject: Re: inbound vs outbound? In-Reply-To: <00a701c10416$9087e020$ccce1dd5@mahdavi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 4 Jul 2001, mahdavi wrote: > Hi. > > > That is not correct. Again, RFC2401 states "The SPD must be consulted > > during the processing of all traffic (INBOUND and OUTBOUND), including > > non-IPsec traffic." > > I did not said that I dont consult SPD. I just said > > "every packet is outbound else it destined to my machine in tunnel mode. > after inbound process on such a packet I have to process it as outbound" > > so you can see that I consult SPD in outbound process. > > > Here is an attack that can happen if you don't follow this rule. Suppose > > that there is a packet that the attacker wants to inject into the system. > > It might be, for example, a UDP packet that kicks off an RPC procedure on > > the target system. Since the attacker has access only to an section of > > the cloud where all such packets are IPSec protected, he shouldn't be > > able to do so. However, with your proposed method, all the attacker > > would have to do is inject the packet in the clear. When this packet > > hits the security gateway, he'll see that it didn't have the router as > > the destination, and hence just forward it on, and hence, the attacker > > has won. > > > > Oooooh. you R wrong with my opinion. > > I just said > > "every packet is outbound else it destined to my machine in tunnel mode. > after inbound process on such a packet I have to process it as outbound" Or, in other words (simplifying just a little): "Decrypt anything that was encrypted, and encrypt anything that wasn't" > > you can see that any packet will go under outbound IPsec operation according > to my opinion. > > so you attacker cant win me . > > ok ? > > am I right ? No, even in cases where you have a relatively trivial topology (for example, topologies where you don't have to worry about decrypting and then reencrypting a packet, or with nested encryption). Consider the case: Attacker | +---+ V +---+ A --| B |-------| C |-- D +---+ +---+ where A and D are the protected hosts, and B and C are routers using your interpretation of IPSec policy. Then, all the attacker needs to do is form a plaintext packet from A to D, and send it to one of B's interface. Since it is not destined to B in tunnel mode, B will process it as outbound. Since packets from A to D need to be IPSec protected, B will encapsulate it in an appropriate SA, which it will forward to C. C will then decrypt the packet into the original A to D packet, which it will forward to D. D will then get a valid looking packet that was actually chosen by the attacker. > > It is better for me to redefine my sentence as follows. > > look at below figure. > > > ----------------\ > | ______________ > ------------ | / > | | | > ___|____|____|____ > / \ > | __________ > | ROUTER / \ > -------| | | > | | IPSEC | > | | | > | | system | > -------| | | > | | | > | | | > | \__________/ > | | > \__________________/ > | | | > | | | > ----------/ | | > | \________ > | > > > it has many interfaces but there is no relation between interfaces and IPsec > system. > router work in this manner that gives every packet that is comming on any > interface to IPsec. > IPsec system will act on it then it generates new packet and gives it back > to the router. > then router will continue his work. > > best regards > > mahdavi > > > From owner-ipsec@lists.tislabs.com Tue Sep 4 18:51:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851phD25729; Tue, 4 Sep 2001 18:51:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07121 Tue, 4 Sep 2001 21:16:19 -0400 (EDT) Message-ID: <23051C9F9BABD411A7850002B30847992588A8@delta.allegrosys.com> From: Bora Akyol To: "'mahdavi'" , ipsec Subject: RE: inbound vs outbound? Date: Tue, 4 Sep 2001 18:24:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I am not mistaken, you still need to look at the SPD on inbound packet reception to make sure that the packets that needed to get security treatment did in fact get the correct security treatment. The statement that you make below works perfectly fine when things are working OK, but does not detect the packets that should have been tunneled to the router and that did not. BTW, you may want to think about the overall architecture of this "router" that you are building. In routers you need to do RFC1812 checks that require you to know and **remember** the interface that the packet came in on. In fast (read OC48+ speeds) routers that employ a distributed switching architecture, these checks are usually done at ingress. Regards Bora |-----Original Message----- |From: mahdavi [mailto:mahdavi@sepahan.iut.ac.ir] |Sent: Tuesday, July 03, 2001 3:23 AM |To: ipsec |Subject: Re: inbound vs outbound? | | |Hi. |You R right. |But pay attention to this fact that RFC is for all Implmentations. |Now just verify this pharase ( if it is correct, and if it is |not tell me |Y ). | |"IF a regular packet received by our router and it was not |tunneld to this |router it is enough to apply just outbound process. " | |If above sentence is not correct let me know. (think about a security |gateway --in arouter) | |sincerely yours | |mahdavi | |> |> In RFC2401's terminology, |> an "inbound" packet means a packet received on an interface, |> an "outbound" packet means a packet sent on an interface. |> |> I think you shouldn't use the terms "inbound" and "outbound" |if you wish |> to express another concept. |> |> RFC2401, paragraph 4.4, states that "The SPD must be consulted during |> the processing of all traffic (INBOUND and OUTBOUND), including |> non-IPsec traffic." and also "Thus the administrative interface must |> allow the user (or system administrator) to specify the security |> processing to be applied to any packet entering or exiting |the system, |> on a packet by packet basis." |> |> It results that the SPD is consulted twice for forwarded packets. |> |> |> There are not necessarily two physically separate SPDs, but |if you only |> have one SPD, you should add the "direction |(inbound/outbound)" info in |> each entry. |> | | | | | From owner-ipsec@lists.tislabs.com Tue Sep 4 22:59:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f855xZD03980; Tue, 4 Sep 2001 22:59:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07346 Wed, 5 Sep 2001 00:59:33 -0400 (EDT) MIME-Version: 1.0 Message-Id: <3B95B361.000003.01240@puja> Date: Wed, 5 Sep 2001 10:38:49 +0530 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_PMB6G6G0000000000000" X-Mailer: IncrediMail 2001 (1400186) From: "Puja" References: <4.3.2.7.1.20010903142108.00ba7960@golf.cpgdesign.analog.com> <005201c10381$c7a18380$dace1dd5@mahdavi> <3B949419.FE5508E8@6wind.com> X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: , Cc: , , Subject: Re: inbound vs outbound? Reply-To: "Puja" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------Boundary-00=_PMB6G6G0000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi i absolutely agree with whatever christophe has said in his mail below ex= cept the point that u need to add an entry in ur spd for direction. SPD m= eans that no direction is required. It is the same for inbound as well ou= tbound. Mahdavi, acc to the rfc 2401 u have to do spd lookup for every inbound n = outbound packet. The only optimization u can do is cache the spd so that = u don't have to go the database for every packet. regards puja -------Original Message------- From: Christophe Gouault Date: Wednesday, September 05, 2001 06:01:21 AM To: mahdavi Cc: Ramana Yarlagadda; ipsec; Puja Puri Subject: Re: inbound vs outbound? mahdavi, mahdavi wrote: >=20 > Hi. > (as I mentioned ) > Its Strange. I did not saw this matter that you said in RFC2401. there = is no > reason to look at SPD twice. In RFC2401's terminology, an "inbound" packet means a packet received on an interface, an "outbound" packet means a packet sent on an interface. I think you shouldn't use the terms "inbound" and "outbound" if you wish to express another concept. RFC2401, paragraph 4.4, states that "The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic." and also "Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis." It results that the SPD is consulted twice for forwarded packets. > do you think that we have two SPD for an ipsec system ? ( one for outbo= und > and one for inbound !! ). but we just have one SPD per IPSEC system. There are not necessarily two physically separate SPDs, but if you only have one SPD, you should add the "direction (inbound/outbound)" info in each entry. > [...] >=20 > mahdavi. --------------Boundary-00=_PMB6G6G0000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
i absolutely agree with whatever christophe has said in his ma= il=20 below except the point that u need to add an entry in ur spd for=20 direction. SPD means that no direction is required. It is the same = for=20 inbound as well outbound.
 
Mahdavi, acc to the rfc 2401 u have to do spd lookup for every= =20 inbound n outbound packet. The only optimization u can do is cache = the spd=20 so that u don't have to go the  database for every packet.
 
regards
puja
 
 
-------Original Message-------<= /I>
 
From: Christophe Gouault=
Date: Wednes= day,=20 September 05, 2001 06:01:21 AM
To: mahdavi
Cc: Ramana Yarlagadda;= ipsec; Puja Puri
Subject: Re:= inbound vs=20 outbound?
 
mahdavi,

mahdavi wrote:
>
>=20 Hi.
> (as I mentioned )
> Its Strange. I did not saw th= is=20 matter that you said in RFC2401. there is no
> reason to look= at SPD=20 twice.

In RFC2401's terminology,
an "inbound" packet mean= s a=20 packet received on an interface,
an "outbound" packet means a pa= cket=20 sent on an interface.

I think you shouldn't use the terms "i= nbound"=20 and "outbound" if you wish
to express another concept.

RF= C2401,=20 paragraph 4.4, states that "The SPD must be consulted during
the= =20 processing of all traffic (INBOUND and OUTBOUND), including
non-= IPsec=20 traffic." and also "Thus the administrative interface must
allow= the=20 user (or system administrator) to specify the security
processin= g to be=20 applied to any packet entering or exiting the system,
on a packe= t by=20 packet basis."

It results that the SPD is consulted twice fo= r=20 forwarded packets.

> do you think that we have two SPD fo= r an=20 ipsec system ? ( one for outbound
> and one for inbound !! ).= but we=20 just have one SPD per IPSEC system.

There are not necessaril= y two=20 physically separate SPDs, but if you only
have one SPD, you shou= ld add=20 the "direction (inbound/outbound)" info in
each entry.

&g= t;=20 [...]
>
> mahdavi.
=09 =09 =09 =09 =09 =09 =09
_________________________________________________
IncrediMail - Email has finally= =20 evolved - Click=20 Here --------------Boundary-00=_PMB6G6G0000000000000-- From owner-ipsec@lists.tislabs.com Wed Sep 5 03:44:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85AifD07803; Wed, 5 Sep 2001 03:44:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07790 Wed, 5 Sep 2001 05:31:31 -0400 (EDT) Date: Wed, 5 Sep 2001 15:10:16 +0530 (IST) From: Puja Puri To: ipsec@lists.tislabs.com Subject: Exporting symbols into linux kernel? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all I have a problem. I am tampering the tcp/ip source code. In the /net/ipv4/ip_input.c file i want to call my function which is defined in another .c file and declared in another .h file(declared as extern function), and I will include this .h file in the ip_input.c. But this doesn't work? Do i need to export symbols? Do i have to make an entry in netsyms.c and what about /proc/kysms ?? Please tell me what should i do. I think exporting symbols might help. If i need to export symbols, then how should i go about doing it. Thanks for the help. regards puja Puja Puri Member of Technical Staff Networking and Internet Software Group C-DAC Pune From owner-ipsec@lists.tislabs.com Wed Sep 5 04:25:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85BPlD11623; Wed, 5 Sep 2001 04:25:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07864 Wed, 5 Sep 2001 06:39:54 -0400 (EDT) Message-ID: <005401c135f8$49a9a260$dace1dd5@mahdavi> From: "mahdavi" To: References: <200109041036.f84AaEQ10637@sepahan.iut.ac.ir> <00a601c10416$8fd86640$ccce1dd5@mahdavi> Subject: Re: inbound vs outbound? Date: Wed, 5 Sep 2001 15:16:00 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. Many thanks to Puja Puri, Christophe, ramana,derek,Scott Fluhrer, Steve,Paul Hoffman, Bora and Dong Xiaohu I got your idea. You helped me too much. best regards mahdavi From owner-ipsec@lists.tislabs.com Wed Sep 5 07:41:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EfYD21610; Wed, 5 Sep 2001 07:41:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08149 Wed, 5 Sep 2001 09:39:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <00a801c10416$9149a980$ccce1dd5@mahdavi> References: <001201c1 019f$6116da40$dace1dd5@mahdavi> <3B93324B.86D68858@6wind.com><005301c10381$cc587be0$dace1dd5@mahdavi> <00a801c10416$9149a980$ccce1dd5@mahdavi> Date: Wed, 5 Sep 2001 09:37:25 -0400 To: "mahdavi" From: Stephen Kent Subject: Re: inbound vs outbound? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:43 AM +0430 7/4/01, mahdavi wrote: >Hi. >many thanks for your comments. >but > > >> >> 2401 describes the SPD in terms of inbound and outbound traffic on a >> per interface basis. one can have one SPD IF it tags entries on a >> per-interface basis and based on directionality, but that becomes >> equivalent to per-interface, per-direction SPDs. >> >> > >> >Also I choosed native implementation s why I have to process one packet >> >twice ? I have one Ipsec system for all interfaces with just one SPD. >> >> one need not lookup a packet in the SPD twice. An IPsec-protected >> packet arriving from the Internet and directed to a system behind an >> SG is lookup up once in the SAD, to map it to an SA, and the >> processed packet is then lookup up in the SPD to ensure that it is >> consistent with the SA via which it was received. >> >> Steve > >I am implementing Ipsec as native in heart of a router. >My Ipsec has not any contact to any interface. It dont knows anything about >Interface for a certain packet. It dont knows which interface this packet >came from. >Inbound SPD and outbound SPD is same in my design. no differ between them. > Then you will have a non-compliant implementation, since it will be unable to apply different policies on a per-interface level. Steve P.S. BTW, it's September, month 9, not July, month 7. Please reset your system clock. From owner-ipsec@lists.tislabs.com Wed Sep 5 11:06:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85I60D02558; Wed, 5 Sep 2001 11:06:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08841 Wed, 5 Sep 2001 13:16:49 -0400 (EDT) Message-Id: <200109051706.f85H6il24872@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, design@lists.freeswan.org Subject: Re: [Design] Re: opportunistic encryption deployment problems In-reply-to: Your message of "Tue, 04 Sep 2001 19:18:31 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Sep 2001 13:06:44 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jakob" == Jakob Schlyter writes: Jakob> On Fri, 31 Aug 2001, Michael Richardson wrote: >> In the meantime, we can publish lists of secure zones with contact >> information and do PGP-like web-of-trust stuff. Jakob> you can not do PGP-like web-of-trust within DNSsec as all signatures needs Jakob> to be strictly hierarchical. Yes, that is true. But, if one assumes that one has a forest rather than a tree, then one can do web-of-trust like things on the "root" keys. Whether one does this with PGP signatures or using DNSsec signatures is a different question. Jakob> or do you mean distributing lists of secure Jakob> zones together with their public keys using PGP? So, the answer is "yes" ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Sep 5 11:06:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85I60D02559; Wed, 5 Sep 2001 11:06:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08797 Wed, 5 Sep 2001 13:08:57 -0400 (EDT) Message-ID: <002f01c1362e$9fe70ec0$c9ce1dd5@mahdavi> From: "mahdavi" To: "Stephen Kent" Cc: References: <001201c1019f$6116da40$dace1dd5@mahdavi><3B93324B.86D68858@6wind.com><005301c10381$cc587be0$dace1dd5@mahdavi><00a801c10416$9149a980$ccce1dd5@mahdavi> Subject: Re: inbound vs outbound? Date: Wed, 5 Sep 2001 21:34:38 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi U R right. I misundrestood something. I found complete answer in Scott Fluhrer's mail. U and Christophe Gouault were right. It caused to change architecture of my design. many thanks to you all. Sincerely yours mahdavi. > > Then you will have a non-compliant implementation, since it will be > unable to apply different policies on a per-interface level. > > Steve > > P.S. BTW, it's September, month 9, not July, month 7. Please reset > your system clock. From owner-ipsec@lists.tislabs.com Wed Sep 5 21:51:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f864peD14361; Wed, 5 Sep 2001 21:51:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09639 Wed, 5 Sep 2001 23:40:09 -0400 (EDT) From: "Geoffrey Huang" To: "Michael Thomas" , , Subject: RE: network partitions and DPD Date: Wed, 5 Sep 2001 20:47:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200109031601.JAA23673@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I had a brief conversation with Bill Sommerfeld at > last IETF about his idea of birth certificates for > IKE with regards KINK. While the idea has a fairly > straightforward solution for KINK (since there's a > reliable source of time from the KDC), I realized > that birth certificates only catch the case where > one of the peers has rebooted. This leaves an > important case with no solution. Yes, I've had the same conversation with Bill. I think we agreed that different problems would require different solutions. (This sentiment has been voiced by others -- Tero K. comes to mind at the bakeoff.) I've forgotten, btw, how the birth certificates idea differs from initial contact... > That case is where the two peers are separated for > some amount of time by a network partition leaving > a pending connection half open. Consider the case > where the final reply is lost by the initiator and > all subsequent retransmissions fail because of a > network partition. This leaves correct state on > the respondent and incorrect state on the > initiator. Yes. There's also the case where one of the peer crashes (and doesn't necessarily reboot). > If we want to solve for this -- and I think > there's good motivation for plugging these sorts > of black hole situations in the name of a robust > protocol -- I believe that a failed operation must > always result in the side perceiving the failure > to remove its state for the operation in progress; > this is simple enough. Agreed. This is what we specified in the DPD draft (curiously, you have "DPD" in the subject line, but you make no mention of it in your e-mail at all ;-). > The more difficult problem to deal with is what > happens on the side if it believes that its side > of the connection is fully formed? In the example > above, Bob would have both SA's installed and not > know that the network had partitioned. In this > case, Bob may send to a blackhole at Alice and > given current IPsec mechanisms, I don't believe > there's a way to recover. > > One proposal I've heard is that Alice should > initiate keying if she sees SPI's from an unknown > source. The problem is that Alice does not > necessarily have enough information to figure out > how to re-create the SA. This is particularly true > if there are multiple acceptible forms of > identity, different selectors on each end, etc. > Thus, it seems to me that the only reasonable > thing that Alice can do is send Bob an > unauthenticated message giving him a clue that > something might be amiss. The natural thing to > here is to send some sort of ICMP message, I > think. This assumes that connectivity between Alice and Bob has been restored. In many cases, it won't have been, in which I think DPD is probably the best way to solve the problem. If the case is that Alice has rebooted, and Bob continues to send IPSec traffic, Alice could send an unauthenticated Invalid SPI notify. It's up to Bob what to do at this point: ignore it (it was unprotected), kick off a new IKE SA to Alice, etc. The problem of DoS exists here, of course, which you point out below. -g > When Bob receives the ICMP message, he doesn't > really know for sure that the message wasn't > spoofed, but he at least knows how to > reinstantiate the SA. What seems like it would be > useful is for Bob to try to first see if this was > a spoofed attack in the case of IKE (KINK doesn't > suffer from the sort of public key make-work DoS > attack as IKE, so it's more ignorable). Also, it > would be nice if Bob could basically pick up where > they left off. That is, if the ISAKMP SA was > already established, then it would be advantageous > to keep using it if it were a quick mode SA that > was half open. > > At this point, it would seem that Bob should just > remove its old SA's, and initiate a fresh > one. Since Alice had no state in the first place, > I'd think that we'd be back in the ground state, > and that we'd be fully recovered by then. > > What is probably the interesting question is how > best to implement the test to check if the ICMP > message was legitimate. Also, there's a question > in my mind whether there's a need to check other > SA's at the same time. This, I think, needs more > work. > > If you made it down here, happy labor day (or end > 'o vacation outside NA :-) > > Mike > > > From owner-ipsec@lists.tislabs.com Sun Sep 9 08:25:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f89FPCD23873; Sun, 9 Sep 2001 08:25:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15492 Sun, 9 Sep 2001 09:58:43 -0400 (EDT) From: mahdavi@sepahan.iut.ac.ir Message-Id: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> To: ipsec@lists.tislabs.com Subject: How many spd recrds ? Date: Sun, 9 Sep 2001 09:00:26 GMT X-Mailer: Cafe MailMan v3.0.19 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD records are reqired ? about 10 ? about 50 ? about 100 ? about 1000 !!!??? how much? I want to have an estimation of maximum SPD records that an administrator may defines. sincerely yours mahdavi From owner-ipsec@lists.tislabs.com Mon Sep 10 06:03:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AD3eD15386; Mon, 10 Sep 2001 06:03:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17334 Mon, 10 Sep 2001 07:54:48 -0400 (EDT) Message-ID: <3B9CABD6.8A9EE535@lmf.ericsson.se> Date: Mon, 10 Sep 2001 15:02:30 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tytso@mit.edu CC: ipsec@lists.tislabs.com Subject: Re: DRAFT: ipsec charter update References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (A response to the charter update posting that was sent some weeks ago. I hope the matter is still relevant...) >The IPSEC working group will restrict itself to the following short-term >work items to improve the existing key management protocol (IKE): > >1) Changes to IKE to support NAT/Firewall traversal >2) Changes to IKE to support SCTP >3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors >4) IKE MIB documents >5) Sequence number extensions to ESP to support an expanded sequence > number space. >6) Clarification and standardization of rekeying procedures in IKE. It is not fully clear to me that all of these items are related to IKE as the first sentence claims, e.g. points 3 and 5? Also, as I've stated before I'd like to document somewhere certain clarifications on how IPsec policies and IKE work in the context of IPv6. Could that be put also on the list, it seems to fit well with the short-term-clarify-and-improve approach? Jari From owner-ipsec@lists.tislabs.com Mon Sep 10 07:26:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AEQSD19076; Mon, 10 Sep 2001 07:26:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17594 Mon, 10 Sep 2001 09:28:53 -0400 (EDT) To: mahdavi@sepahan.iut.ac.ir Cc: ipsec@lists.tislabs.com Subject: Re: How many spd recrds ? References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> From: Derek Atkins Date: 10 Sep 2001 09:36:14 -0400 In-Reply-To: mahdavi@sepahan.iut.ac.ir's message of "Sun, 9 Sep 2001 09:00:26 GMT" Message-ID: Lines: 36 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There isn't any theoretical maximum. It's like asking "how many firewall rules could you have?" The answer: unlimited. There is a practical limit of approximately 2^32 per interface per peer. -derek mahdavi@sepahan.iut.ac.ir writes: > Hi all. > > Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD > records are reqired ? > about 10 ? > about 50 ? > about 100 ? > about 1000 !!!??? > > how much? > > I want to have an estimation of maximum SPD records that an administrator may > defines. > > sincerely yours > mahdavi > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Sep 10 14:46:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ALk5D08966; Mon, 10 Sep 2001 14:46:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18290 Mon, 10 Sep 2001 16:31:21 -0400 (EDT) To: minutes@ietf.org cc: ipsec@lists.tislabs.com Subject: IPSEC Minutes From: tytso@mit.edu Phone: (781) 391-3464 Message-Id: Date: Mon, 10 Sep 2001 16:39:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec Working Group Meeting Minutes [ Minutes compiled from notes taken by Barbara Fraser, John Linn and Geoff Huang.] Monday, August 6, 2001 Document status/updates ======================= IPsec MIB doc had a few edits and they'll soon be ready to go to working group last call. The GSSAPI-IKE has a new draft just posted and it should go to wg last call immediately. This will be informational. The other one is the mod-p DH group definitions. Tero said it's ready to go, and it's ready to go to wg last call. We'll move all three of these immediately after the wg. Motivations for including an IV in AES counter modes ====================================================== Steve Kent presented why you might want to use IV in counter mode. Counter modes offer improved performance. Two counters: per packet and intrapacket counters. System perspective to get a nice number of bits to change each time, and have something you can do on the chip to stay within the current evaluation requirements. No less than 32 bits and may have to bring it up to 64 bits. AES cipher document =================== Current status of the AES cipher document was discussed by Sheila Frankel. It's (AES and CBC mode) been around for awhile. There are multiple implementations. They are planning a draft of AES MAC, and there has been interest in a draft for AES SHA. Son of Ike / Immediate Changes to Ike ===================================== Ted Ts'o made some opening comments to frame the discussion. Marcus, Jeff, and Steve's note to the list was a restatement of the position they set a year or so ago. The two things that require near term changes to IKE are SCTP compatibility and NAT/Firewall traversal. There haven't been many changes to the SCTP draft and Barbara and Ted will be talking to the editors after the meeting to see how we can move the document forward. NAT/firewall traversal drafts now exist that harmonize the previous drafts. The only problem remaining is AH. The AH part in encapsulation draft is incorrect. Question is do we need AH? About a dozen folks are implementing. Only one person in the room supported including AH, all others were against including AH. This topic will be taken to the list to allow for comment and within 3 weeks we should be able to go to wg last call. Opportunistic IPSEC =================== Hugh discussed the opportunistic keying, which is being pursued by the Freeswan project, and discussed in draft-richardson-ipsec-opportunistic-00.txt. It uses secure DNS to discover that two systems have keys out there that can be used for communications. It allows most hosts to communicate opportunistically. Freeswan v 1 came out about a month ago. They don't do any verification of the keys, assuming that's done by DNS-sec. Matt Blaze asked what the killer argument is for why someone should run this? Answer: A way to get encryption going on the net. Discussion continued on the motivation for using such a protocol. Hugh suggested that we need to get confidentiality deployed and then worry about authorization. Question asked as to whether most sites can afford it. For example, most people don't stay on a single site for lengthy periods of time. Can most hosts handle the CPU load given that are sites even now that want to use SSL but can't even handle that. Two things that make this difficult: very short transactions. Another issue is concern that the DNS SEC folks won't be happy about using DNS to pass around keys that are not DNS keys. Bill Sommerfeld responded to the DNS SEC comment saying that they are supporting Secure Shell wg and they also support IPsec. A comment was made that benchmarking showed that IPsec can be a win over SSL, etc. because of the use of kernel space. Comments made supporting the experimental use of this protocol and see what the activity and performance characteristics are. Tuesday, August 7, 2001 ======================= Clarification of IESG/IAB message ================================= Last week, Jeff Schiller, Marcus Leech, and Steve Bellovin published a position statement on the ground rules for further development of IKE. Marcus noted that its premises were well known to the Ipsec community, but others took it more critically than was intended. Steve and Marcus stated that no exploitable attacks on IKE are currently known. The main point that was meant in the position statement: IKE is too complex to analyze and determine whether or not it's bug-free. The intent is not to preclude progression of PIC in IPSRA, but rather to reiterate that IPSRA shouldn't change IKE. The message wasn't anything new; just a reiteration of what's been said for over a year: i.e., that there should be no drastically new changes to IKE. The issue, now, is what needs to be done to address the shortcomings of IKE. During the brief question and answer period, William Dixon raised a question about unpublished analysis of IPSEC; where they analysis of implementations or the protocol. The answer was that most of the analysis, especially the early ones, such as the one done by Cathy Meadows, focused on the protocol, and in some cases on draft versions of the documents. Steve Bellovin stated that a complex protocol requires complex implementations, and complex implementations lend themselves to bugs and security problems. He pointed out the majority of CERT advisories are just bugs. Marcus stated that no one has asserted that any particular implementation is known to be insecure; it's just that complex implementations, by nature, tend to have security problems. Introducing Son-of-Ike Discussion ================================== Barbara Fraser introduced the discussion by making the following observations: IPSec is entering a new phase, looking into IKE based on experience to filter requests into design requirements for how to move forward. It is premature to judge whether to modify or replace IKE. The two proposals to be discussed subsequently are proposed first steps in this direction. Open mike discussion will need to be followed up on the mailing list. Improving IKE ============= Improving IKE (Radia Perlman): The primary goal is simplification, that's code-preserving where possible, but also considering improvements. The draft is a summary of a paper co-authored with Charlie Kaufman (url available in the draft). Proposals: *) Remove aggressive mode, rather than expecting users to choose between main and aggressive and reducing the number of sub-protocols. Either identity hiding is important, or it isn't; removing aggressive mode would remove half the protocol. *) Remove public-key encryption variants, leaving signature modes; among other reasons, they're less likely to be escrowed, few will have encryption keys without signature keys, and everyone knows their signature keys before performing any protocol. This further reduces the set of sub-protocols. *) Allow stateless cookies, as provided in Photuris but not preserved in IKE. *) More compact parameter negotiation than possible in ISAKMP, with smaller number of negotiation proposals. *) Fix main mode preshared key operation, or remove preshared keys *) Remove Phase 2? This is recognized as a more contentious suggestion. If there aren't to be a lot of Phase 2s, amortizing a smaller number of Phase 1s, it's more efficient to combine the phases. *) Invert identity protection, hiding originator's rather than target's identity. The target's identity is generally less important to keep secret, since the identity is usually know due to a fixed IP address. *) Additional suggestion: SSL-like unidirectional authentication or strong password-based authentication (e.g., EKE). Implementation Cleanups ======================= Andrew Krywaniuk presented some protocol cleanup proposals from an implementors perspective. Primary concern: Don't destroy the existing code base. Andrew doesn't believe we should remove phase 2. However, he believes that Phase 2 PFS is superfluous given phase 1. The commit bit may also not be necessary. We should adopt Tero's revised authentication hash. Rekeying has been a major operational problem, since it's unspecified in the documents, and people try to do it in different ways. We need to clarify the use of certificate request/vendor ID payloads. Things which Andrew believes we should add include: Dead peer detection, replay protection into phase 2 exchange, distributed denial of service attack protection, and Reliable notification messages. Open Mike ========= Matt Blaze noted that he and his team is still working on Just Fast Keying (JFK). It should be ready for presentation by the next IETF. Various people noted that if we are creating a new protocol, or even modifying an existing one, we need to be clear about defining requirements and scope. (Who knew when we started that a protocol like iSCSI would want to use IPSEC?) A number of commentors (Steve Kent, HI, William Dixon) agreed that paring down the IKE feature list would be a good thing. Besides simplifying implementations, it improves the likelihood of interoperability. David Black from the iSCSI working group noted that iSCSI was sensitive to roundtrip counts, and so he thought aggressive mode might be needed. Howard from Intel noted that iSCSI would require fast rekeying, since with 10GB wire speed, rekeying might need to happen after 5 minutes. There was discussion both in favor and against preserving existing implementations. Some people believe it was important; others did not. Ted Ts'o noted that at the previous IETF meeting, a straw poll was taken, and a clear majority at that time believed that code preservation was important. At the end of the open mike session, another straw poll was taken; this time a clear majority (45) believed that code preservation was NOT important. Approximately 15 people believed that code preservation was important. Interestingly, these percentages were almost exactly reversed in Minneapolis. From owner-ipsec@lists.tislabs.com Mon Sep 10 16:47:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ANlmD29043; Mon, 10 Sep 2001 16:47:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18471 Mon, 10 Sep 2001 19:06:13 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" Cc: Subject: RE: IPSEC Minutes Date: Mon, 10 Sep 2001 19:12:05 -0400 Message-Id: <001301c13a4e$2f3a3b10$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There was discussion both in favor and against preserving existing > implementations. Some people believe it was important; others did > not. Ted Ts'o noted that at the previous IETF meeting, a straw poll > was taken, and a clear majority at that time believed that code > preservation was important. At the end of the open mike session, > another straw poll was taken; this time a clear majority (45) believed > that code preservation was NOT important. Approximately 15 people > believed that code preservation was important. Interestingly, these > percentages were almost exactly reversed in Minneapolis. It's not a fair comparison because, as I remember it, the poll in Minneapolis was taken only of implementers, whereas the poll in London was taken of the whole room. The poll had very high participation, and IMHO polls with high participation are unreliable because many of the voters are likely to be tourists. Also, some people thought that the question was whether the IETF should pursue alternate KMPs, and not whether the IETF should specifically replace IKE with an alternate KMP. I have to say that's not how I interpreted the question, but the guy sitting next to me did. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Sep 10 19:36:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B2aJD21335; Mon, 10 Sep 2001 19:36:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18756 Mon, 10 Sep 2001 21:19:19 -0400 (EDT) To: tytso@mit.edu Cc: minutes@ietf.org, ipsec@lists.tislabs.com In-reply-to: tytso's message of Mon, 10 Sep 2001 16:39:05 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC Minutes From: itojun@iijlab.net Date: Tue, 11 Sep 2001 10:27:05 +0900 Message-ID: <19231.1000171625@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Son of Ike / Immediate Changes to Ike >===================================== > >Ted Ts'o made some opening comments to frame the discussion. Marcus, >Jeff, and Steve's note to the list was a restatement of the position >they set a year or so ago. The two things that require near term changes >to IKE are SCTP compatibility and NAT/Firewall traversal. There haven't >been many changes to the SCTP draft and Barbara and Ted will be talking >to the editors after the meeting to see how we can move the document >forward. NAT/firewall traversal drafts now exist that harmonize the >previous drafts. The only problem remaining is AH. The AH part in >encapsulation draft is incorrect. Question is do we need AH? About a >dozen folks are implementing. Only one person in the room supported >including AH, all others were against including AH. This topic will be >taken to the list to allow for comment and within 3 weeks we should be >able to go to wg last call. I was not in the meeting room because of conflicting meeting. sorry. Not sure why "kill AH" is a part of son-of-IKE discussion. we do use AH (*) and would like to be able to negotiate AH. (*) specifically mobile-ip6. as you notice there are fair amount of discussions, but my guess is that AH will be used at the end - any changes to authentication mechanism does not help the lack of certificate infrastructure, therefore, the choice of authentication mechanism does not really matter. I believe it was incorrect to blame AH for mobile-ip6 "lack of cert infrastructure" issue. itojun From owner-ipsec@lists.tislabs.com Mon Sep 10 22:24:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B5OZD25571; Mon, 10 Sep 2001 22:24:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19003 Tue, 11 Sep 2001 00:36:56 -0400 (EDT) Message-ID: <003e01c13a7c$8a5d2380$cdce1dd5@mahdavi> From: "mahdavi" To: "Derek Atkins" Cc: References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> Subject: Re: How many spd recrds ? Date: Tue, 11 Sep 2001 08:54:40 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi O my God. what I asked that you answered me so ? I did not asked about theorical maximum. I just said "Typicaly how many SPD records are reqired ?". In Other sentence I said "I want to have an estimation of maximum SPD records that an administrator may defines". It is funny to think an administrator may define 2^32 firewall rules; and I know that. I mean regularly ( in average , typically , ... ) how many SPD record may an administrator define. Best regards mahdavi. > There isn't any theoretical maximum. It's like asking "how many firewall > rules could you have?" The answer: unlimited. > > There is a practical limit of approximately 2^32 per interface per peer. > > -derek > > mahdavi@sepahan.iut.ac.ir writes: > > > Hi all. > > > > Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD > > records are reqired ? > > about 10 ? > > about 50 ? > > about 100 ? > > about 1000 !!!??? > > > > how much? > > > > I want to have an estimation of maximum SPD records that an administrator may > > defines. > > > > sincerely yours > > mahdavi > > > > > > > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Sep 12 07:51:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CEp3D22036; Wed, 12 Sep 2001 07:51:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21150 Wed, 12 Sep 2001 09:17:14 -0400 (EDT) Reply-To: From: "Sridhar J" To: "Users \(E-mail\)" Subject: rsa encryption and signature keys - IKE Date: Wed, 12 Sep 2001 10:22:02 +0530 Message-Id: <001001c13b46$aa80c5c0$2702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , I have some questions regarding RSA : 1) can the same key used for both rsa encryption(encrypted nonces ) and also for rsa signatures in IKE . 2)Some implementations of IKE maintain two set of keys . thanks in advance re, sridhara .j www.futsoft.com chennai india . From owner-ipsec@lists.tislabs.com Wed Sep 12 20:02:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8D32CD11232; Wed, 12 Sep 2001 20:02:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA22149 Wed, 12 Sep 2001 21:56:16 -0400 (EDT) Message-Id: <200109130155.KAA02380@csnet1> Date: Thu, 13 Sep 2001 10:4:13 +0800 From: dxh Reply-To: sleepy-cat@263.net To: "ipsec@lists.tislabs.com" Subject: How are Initiator's Proposals checked by Responder? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I want to know if rfc2367 has defined the behavior of the responder in SA negotiation! I only see the initiator's behavior is defined in 5.1 of rfc2367. The proposals are passed from kernel to KMd using Message SADB_ACQUIRE. When responder's KMd gets the proposals, how it communicates with kernel to determine which proposal is proper? Dong Xiaohu sleepy-cat@263.net From owner-ipsec@lists.tislabs.com Mon Sep 17 06:43:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8HDhLD15661; Mon, 17 Sep 2001 06:43:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28248 Mon, 17 Sep 2001 08:04:17 -0400 (EDT) Message-ID: <038e01c13f72$88090a40$700110ac@roc.com> Reply-To: "jyothi" From: "jyothi" To: Subject: doubt regarding the newgroup mode Date: Mon, 17 Sep 2001 17:46:04 +0530 Organization: Intoto Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038B_01C13FA0.9F8FC040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_038B_01C13FA0.9F8FC040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some doubts regarding new group mode. 1. What exactly do we mean by a diffie-hellman private group? Does it mean that " we are sending some prime and generator which = satisfies Diffie-Hellman MODP conditions in case if group type is MODP = by encrypting with the sessions key established in phase-I SA."=20 2. If we are supporting both XAUTH and new group mode , which one MUST = be negotiated first. 3. If either peers start new group mode at the same time which one we = have to accept. In other words how this negotation should go on? 4. In the New Group Mode we send the prime, Generator and the group = number in a transform payload. How will the peer accept the matching = transforms if we send multiple transforms? Any help regarding these questions is highly appreciated.. Awaiting ur valuable response. Thanks in advance. Regards Jyothi ------=_NextPart_000_038B_01C13FA0.9F8FC040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
I have some doubts regarding new group=20 mode.
1.  What exactly do we mean by a=20 diffie-hellman private group?
 
Does it mean that " we are sending = some prime=20 and generator which satisfies Diffie-Hellman MODP conditions in case = if =20 group type is MODP by encrypting with the sessions key established in = phase-I=20 SA."
 
2. If we are supporting both XAUTH and = new group=20 mode , which one MUST be negotiated first.
 
3. If either peers start new group = mode at the=20 same time which one we have to accept. In other words how this = negotation should=20 go on?
 
4. In the New Group Mode we send the = prime,=20 Generator and the group number in a transform payload.  How will = the peer=20 accept the matching transforms if we send multiple = transforms?
 
 
Any help regarding these questions is = highly=20 appreciated..
 
Awaiting ur valuable = response.
 
Thanks in advance.
 
Regards
Jyothi
------=_NextPart_000_038B_01C13FA0.9F8FC040-- From owner-ipsec@lists.tislabs.com Mon Sep 17 08:50:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8HFo4D25747; Mon, 17 Sep 2001 08:50:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28441 Mon, 17 Sep 2001 10:38:31 -0400 (EDT) Message-Id: <200109171445.f8HEjTa09108@marajade.sandelman.ottawa.on.ca> To: IP Security List , design@lists.freeswan.org Subject: summary of changes in ipsec-opportunistic-02.txt Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Sep 2001 10:45:26 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- (Internet-drafts has been notified. 02 should appear this week. http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid contains all revisions) 1. removed section 11: "Performance Experience" - too soon to get real numbers. 2. section 1.2, added text on what occurs if OE setup fails. 3. section 2.1, description spoke of four gateways, diagram only shows three. 4. switched to using real IP addresses (from IANA reserved) instead of symbolic values. 5. section 3.2, IKE Main Mode exchange was missing one exchange. 6. section 5.2, note about asynchronous DNS lookups 7. section 6.2.1 added explaining why OPT is inappropriate. 8. section 10, unresolved issues, makes the challenge of how to deploy for people who do not control their reverse map out of scope for this document. 9. section 12 -> section 11. to be completed. 10. section 13->section 12, IANA Considerations. We believe that there are none. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO6YMhIqHRg3pndX9AQHGJwP/SHQHIi4lzmionEuROfVEupgpjkwe2PBj /aCZnNcX4Yb0eRJTdE6eadoMrgrDkLdfuqYL8yAebpYeFkYhT7dy/XwjmnDPAN5L Ae73y8acgvrs1/gckZmy0aX6c91LAFZClrERshEwbpacjb6DZhlGKVrYGkC33x+T XoG5Hv/bu0E= =M9pj -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Sep 17 17:05:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8I05gD09155; Mon, 17 Sep 2001 17:05:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29373 Mon, 17 Sep 2001 19:07:09 -0400 (EDT) From: Internet-Drafts@ietf.org X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:51:09 2001 Message-Id: <200106261101.HAA27044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-07.txt Date: Tue, 26 Jun 2001 07:01:20 -0400 X-OriginalArrivalTime: 17 Sep 2001 23:13:50.0360 (UTC) FILETIME=[692F3980:01C13FCE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-07.txt Pages : 11 Date : 25-Jun-01 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt 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-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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: <20010625095435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Con From owner-ipsec@lists.tislabs.com Tue Sep 18 04:01:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IB1PD19812; Tue, 18 Sep 2001 04:01:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00289 Tue, 18 Sep 2001 05:49:45 -0400 (EDT) Message-ID: <000901c13fb6$9b1c3780$700110ac@roc.com> Reply-To: "jyothi" From: "jyothi" To: Subject: doubt regarding the newgroup mode Date: Tue, 18 Sep 2001 01:53:24 +0530 Organization: Intoto Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C13FE4.B38DE9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C13FE4.B38DE9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some doubts regarding new group mode. 1. What exactly do we mean by a diffie-hellman private group? =20 Does it mean that " we are sending some prime and generator which = satisfies Diffie-Hellman MODP conditions in case if group type is MODP = by encrypting with the sessions key established in phase-I SA."=20 2. If we are supporting both XAUTH and new group mode , which one MUST = be negotiated first. 3. If either peers start new group mode at the same time which one we = have to accept. In other words how this negotation should go on? 4. In the New Group Mode we send the prime, Generator and the group = number in a transform payload. How will the peer accept the matching = transforms if we send multiple transforms? Any help regarding these questions is highly appreciated.. Awaiting ur valuable response. Thanks in advance. Regards Jyothi ------=_NextPart_000_0006_01C13FE4.B38DE9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi all,
I have some doubts regarding new group=20 mode.
1.  What exactly do we mean by a=20 diffie-hellman private group?
 
Does it mean that " we are sending = some prime=20 and generator which satisfies Diffie-Hellman MODP conditions in case = if =20 group type is MODP by encrypting with the sessions key established in = phase-I=20 SA."
 
2. If we are supporting both XAUTH and = new group=20 mode , which one MUST be negotiated first.
 
3. If either peers start new group = mode at the=20 same time which one we have to accept. In other words how this = negotation should=20 go on?
 
4. In the New Group Mode we send the = prime,=20 Generator and the group number in a transform payload.  How will = the peer=20 accept the matching transforms if we send multiple = transforms?
 
 
Any help regarding these questions is = highly=20 appreciated..
 
Awaiting ur valuable = response.
 
Thanks in advance.
 
Regards
Jyothi
------=_NextPart_000_0006_01C13FE4.B38DE9C0-- From owner-ipsec@lists.tislabs.com Tue Sep 18 08:10:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IFAHD07903; Tue, 18 Sep 2001 08:10:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00618 Tue, 18 Sep 2001 09:23:44 -0400 (EDT) Message-Id: <200109181332.JAA19741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, design@lists.freeswan.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-richardson-ipsec-opportunistic-02.txt Date: Tue, 18 Sep 2001 09:32:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A method for doing opportunistic encryption with IKE Author(s) : M. Richardson, D. Redelmeier, H. Spencer Filename : draft-richardson-ipsec-opportunistic-02.txt Pages : 30 Date : 17-Sep-01 This document discusses a method used by the Linux FreeS/WAN project to opportunistically encrypt traffic between peers without specific pre-arrangement. It describes the infrastructure necessary to support this configuration. Opportunistic Encryption (OE) provides major simplifications of typical configurations, as it scales linearly rather than quadratically in the number of systems involved. There are naturally some risks, which are described. | This document is offered up as an Informational RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-richardson-ipsec-opportunistic-02.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-richardson-ipsec-opportunistic-02.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: <20010917122626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-richardson-ipsec-opportunistic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-richardson-ipsec-opportunistic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010917122626.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Sep 18 09:39:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IGdlD20160; Tue, 18 Sep 2001 09:39:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00945 Tue, 18 Sep 2001 10:27:00 -0400 (EDT) Message-ID: <75A3CEA84682D311AAC70008C791823201E6FE4C@zbl6c016.corpeast.baynetworks.com> From: "Jerome Freedman Jr" To: ipsec@lists.tislabs.com Subject: Anybody got a copp of the rekey draft Date: Tue, 18 Sep 2001 07:33:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1404E.EE67EEA0" X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1404E.EE67EEA0 Content-Type: text/plain; charset="iso-8859-1" I am looking for T. Jenkins IKE rekey draft or a pointer to it. Can anyone help me? J. Freedman ------_=_NextPart_001_01C1404E.EE67EEA0 Content-Type: text/html; charset="iso-8859-1" Anybody got a copp of the rekey draft

I am looking for T. Jenkins IKE rekey draft or a pointer to it. Can anyone help me?

J. Freedman


 

------_=_NextPart_001_01C1404E.EE67EEA0-- From owner-ipsec@lists.tislabs.com Tue Sep 18 14:51:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ILp6D08338; Tue, 18 Sep 2001 14:51:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01428 Tue, 18 Sep 2001 16:13:21 -0400 (EDT) Reply-To: From: "Sridhar J" To: "SRI \(E-mail\)" Subject: rsa/dsa certificates Date: Tue, 18 Sep 2001 21:40:58 +0530 Message-Id: <000301c1405c$81416500$2702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, can anyone give me some pointers to get some rsa/dsa certificates ( self signed or certificate + CA's self signed certificate ) to check my IKE implementation for INTEROP thanks in advance re, sridharj. www.futsoft.com From owner-ipsec@lists.tislabs.com Tue Sep 18 14:55:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ILtnD08644; Tue, 18 Sep 2001 14:55:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01464 Tue, 18 Sep 2001 16:39:13 -0400 (EDT) Message-ID: <3BA7B2AF.C4369203@cisco.com> Date: Tue, 18 Sep 2001 13:46:39 -0700 From: Bart Giordano Organization: Cisco Systems, Core IP Engineering - Services and Security X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jerome Freedman Jr CC: ipsec@lists.tislabs.com Subject: Re: Anybody got a copp of the rekey draft References: <75A3CEA84682D311AAC70008C791823201E6FE4C@zbl6c016.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk http://www.alternic.org/drafts/drafts-j-k/draft-jenkins-ipsec-rekeying-06.txt > Jerome Freedman Jr wrote: > > I am looking for T. Jenkins IKE rekey draft or a pointer to it. Can > anyone help me? > > J. Freedman > > From owner-ipsec@lists.tislabs.com Tue Sep 18 16:30:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8INUcD13138; Tue, 18 Sep 2001 16:30:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01548 Tue, 18 Sep 2001 18:18:44 -0400 (EDT) X-Recipient: ipsec@lists.tislabs.com Message-Id: <200109190525.CAA01193@solo.mtu-net.ru> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: an ambiguity of draft-shacham-ippcp-rfc2393bis-07 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Sep 2001 02:25:28 -0300 From: "Maxim V. Patlasov" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk draft-shacham-ippcp-rfc2393bis-07 reads: > Note: In the case of an encapsulated IP header (e.g., tunnel mode > encapsulation in IPsec), the datagram payload is defined to start > immediately after the outer IP header; accordingly, the inner IP > header is considered part of the payload and is compressed. It implies that that datagram payload contains ESP header (SPI+RPL) and so is subject of compression. In the other hand it should not be compressed because: > The compression of outbound IP datagrams MUST be done before any IP > security processing, such as encryption and authentication, and How should the former quote be interpreted ? Thanks in advance, Maxim From owner-ipsec@lists.tislabs.com Wed Sep 19 05:27:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JCRmD10772; Wed, 19 Sep 2001 05:27:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02511 Wed, 19 Sep 2001 07:22:09 -0400 (EDT) From: James Tiller Reply-To: James Tiller To: Derek Atkins Cc: ipsec@lists.tislabs.com Date: Wed, 19 Sep 2001 07:29:58 -0400 X-Mailer: The Bat! (v1.53d) Organization: Lucent Technolgies X-Priority: 3 (Normal) Message-ID: <1401689058.20010919072958@lucent.com> Subject: Re: How many spd recrds ? In-Reply-To: References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek - Just out of curiosity, why 2^32? Is this because the SPI is 32 bits? If so, wouldn't this be the limits of the number of SA's effecting the SAD, whereas the policy database (SPD) is supporting the "types" or attributes defining the SA's? One more curious point. If the policy defines the accepted operations to apply, deny, or pass data - technically, wouldn't that be unlimited? Because I could build a policy that affects only certain selectors based on IP address or fully qualified name - which could be limitless. Just curious. Thankx for any answer! ------------- Best regards, -jim Monday, September 10, 2001, 9:36:14 AM, Derek wrote: Atkins> There isn't any theoretical maximum. It's like asking "how many firewall Atkins> rules could you have?" The answer: unlimited. Atkins> There is a practical limit of approximately 2^32 per interface per peer. Atkins> -derek Atkins> mahdavi@sepahan.iut.ac.ir writes: >> Hi all. >> >> Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD >> records are reqired ? >> about 10 ? >> about 50 ? >> about 100 ? >> about 1000 !!!??? >> >> how much? >> >> I want to have an estimation of maximum SPD records that an administrator may >> defines. >> >> sincerely yours >> mahdavi >> >> >> >> >> From owner-ipsec@lists.tislabs.com Wed Sep 19 05:27:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JCRnD10785; Wed, 19 Sep 2001 05:27:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02512 Wed, 19 Sep 2001 07:22:11 -0400 (EDT) From: James Tiller Reply-To: James Tiller To: mahdavi Cc: Derek Atkins , ipsec@lists.tislabs.com Date: Wed, 19 Sep 2001 07:30:07 -0400 X-Mailer: The Bat! (v1.53d) Organization: Lucent Technolgies X-Priority: 3 (Normal) Message-ID: <1551697791.20010919073007@lucent.com> Subject: Re: How many spd recrds ? In-Reply-To: <003e01c13a7c$8a5d2380$cdce1dd5@mahdavi> References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> <003e01c13a7c$8a5d2380$cdce1dd5@mahdavi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mahdavi - I would like to add to this question from a different perspective... If you have a high speed IPSec system, how do you look up a possible 4 billion records fast enough? ------------- Best regards, -jim Tuesday, September 11, 2001, 12:24:40 AM, mahdavi wrote: mahdavi> Hi mahdavi> O my God. what I asked that you answered me so ? mahdavi> I did not asked about theorical maximum. mahdavi> I just said "Typicaly how many SPD records are reqired ?". mahdavi> In Other sentence I said "I want to have an estimation of maximum SPD mahdavi> records that an administrator may defines". mahdavi> It is funny to think an administrator may define 2^32 firewall rules; and I mahdavi> know that. mahdavi> I mean regularly ( in average , typically , ... ) how many SPD record may mahdavi> an administrator define. mahdavi> Best regards mahdavi> mahdavi. >> There isn't any theoretical maximum. It's like asking "how many firewall >> rules could you have?" The answer: unlimited. >> >> There is a practical limit of approximately 2^32 per interface per peer. >> >> -derek >> >> mahdavi@sepahan.iut.ac.ir writes: >> >> > Hi all. >> > >> > Imagine we have a high speed security gateway (Giga bit). Typicaly how mahdavi> many SPD >> > records are reqired ? >> > about 10 ? >> > about 50 ? >> > about 100 ? >> > about 1000 !!!??? >> > >> > how much? >> > >> > I want to have an estimation of maximum SPD records that an mahdavi> administrator may >> > defines. >> > >> > sincerely yours >> > mahdavi >> > >> > >> > >> > >> > >> >> -- >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> Member, MIT Student Information Processing Board (SIPB) >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Sep 19 08:34:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JFYCD23823; Wed, 19 Sep 2001 08:34:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02832 Wed, 19 Sep 2001 10:10:27 -0400 (EDT) To: James Tiller Cc: ipsec@lists.tislabs.com Subject: Re: How many spd recrds ? References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> <1401689058.20010919072958@lucent.com> From: Derek Atkins Date: 19 Sep 2001 10:18:23 -0400 In-Reply-To: James Tiller's message of "Wed, 19 Sep 2001 07:29:58 -0400" Message-ID: Lines: 69 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, theoretically, it can be even bigger than that. You can imagine a SPD that had multiple entries for each SPI. Imagine a system where each SPI implies N SPD rules, because you want to define rules for, say, each and every port for each and every host out there on the internet (because each host is _special_). -derek James Tiller writes: > Derek - > > Just out of curiosity, why 2^32? Is this because the SPI is 32 bits? > If so, wouldn't this be the limits of the number of SA's effecting the > SAD, whereas the policy database (SPD) is supporting the "types" or > attributes defining the SA's? > > One more curious point. If the policy defines the accepted operations > to apply, deny, or pass data - technically, wouldn't that be > unlimited? Because I could build a policy that affects only certain > selectors based on IP address or fully qualified name - which could be > limitless. > > Just curious. Thankx for any answer! > > ------------- > Best regards, > -jim > > > > Monday, September 10, 2001, 9:36:14 AM, Derek wrote: > > Atkins> There isn't any theoretical maximum. It's like asking "how many firewall > Atkins> rules could you have?" The answer: unlimited. > > Atkins> There is a practical limit of approximately 2^32 per interface per peer. > > Atkins> -derek > > Atkins> mahdavi@sepahan.iut.ac.ir writes: > > >> Hi all. > >> > >> Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD > >> records are reqired ? > >> about 10 ? > >> about 50 ? > >> about 100 ? > >> about 1000 !!!??? > >> > >> how much? > >> > >> I want to have an estimation of maximum SPD records that an administrator may > >> defines. > >> > >> sincerely yours > >> mahdavi > >> > >> > >> > >> > >> -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Sep 19 12:35:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JJZ1D07838; Wed, 19 Sep 2001 12:35:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03105 Wed, 19 Sep 2001 14:06:16 -0400 (EDT) Message-Id: <5.0.0.25.0.20010919110308.022a3a90@192.168.1.10> X-Sender: pravin@192.168.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 19 Sep 2001 11:14:50 -0700 To: sleepy-cat@263.net, "ipsec@lists.tislabs.com" From: Pravin Kantak Subject: Re: How are Initiator's Proposals checked by Responder? In-Reply-To: <200109130155.KAA02380@csnet1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk dong, one conceptual model in the responder case could be: SPD entries with wild-carded selectors are stored at application level and managed by another daemon like KMd, say SPDd. when the ph-2 proposals are received from peer, KMd can find the matching application level wild-carded SPD by talking to SPDd. then do SADB_GETSPI to create larval inbound SA(s), and send the matched ph-2 proposal to peer. after completing ph-2 successfully, KMd can do SADB_UPDATE for the created larval inbound SA(s), and SADB_ADD for the outbound SA(s). hope this helps. - pravin At 10:04 AM 9/13/01 +0800, dxh wrote: > I want to know if rfc2367 has defined the behavior of the > responder in SA negotiation! > I only see the initiator's behavior is defined in 5.1 of rfc2367. > The proposals are passed from kernel to KMd using Message SADB_ACQUIRE. > When responder's KMd gets the proposals, how it communicates with kernel > to determine which proposal is proper? > > > Dong Xiaohu > sleepy-cat@263.net ********************************************************************* Pravin Kantak, http://www.intotoinc.com Intoto Inc. voice : (408)844-0480 Ext 318 3160, De La Cruz Blvd, #100, fax : (408)844-0488 Santa Clara, CA - 95054 ********************************************************************* From owner-ipsec@lists.tislabs.com Wed Sep 19 20:01:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8K31TD20286; Wed, 19 Sep 2001 20:01:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03770 Wed, 19 Sep 2001 21:48:56 -0400 (EDT) X-Originating-IP: [138.89.20.42] From: "john ipsec" To: ipsec@lists.tislabs.com Subject: ESP and AH questions Date: Wed, 19 Sep 2001 21:56:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Sep 2001 01:56:24.0406 (UTC) FILETIME=[73E00760:01C14177] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Sorry, if this topic had been discussed before. Is there an FAQ?) Questions: 1. In the tunnel mode, what is the value for the next-header field? The next-header seems to be the original IP header (unlike in the transport mode, the next-header is the "transport protocol" header). 2. The ESP header and trailer do not specify the size of the "Authentication Data," unlike the AH. It uses SA to deduce the size of the Authentication Data (if present). If so, why AH cannot use SA to deduce the size of the Authentication Data field? Thanks, John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ipsec@lists.tislabs.com Wed Sep 19 22:49:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8K5nOD24293; Wed, 19 Sep 2001 22:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03955 Thu, 20 Sep 2001 00:35:47 -0400 (EDT) Message-ID: <00b201c1418e$db330540$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , , "Pravin Kantak" References: <5.0.0.25.0.20010919110308.022a3a90@192.168.1.10> Subject: Re: How are Initiator's Proposals checked by Responder? Date: Thu, 20 Sep 2001 07:43:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I want to know if rfc2367 has defined the behavior of the > responder in SA negotiation! > I only see the initiator's behavior is defined in 5.1 of rfc2367. > The proposals are passed from kernel to KMd using Message SADB_ACQUIRE. > When responder's KMd gets the proposals, how it communicates with kernel > to determine which proposal is proper? This is an issue that can be solved either by the duplication of traffic-level policy information in both the kernel and user spaces, or by an extension to PF_KEY. An extension that I once designed and reported in a now expired internet draft can be found below: http://www.piuha.net/~jarkko/publications/draft-arkko-pfkey-reference-00.txt Jari From owner-ipsec@lists.tislabs.com Thu Sep 20 04:47:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KBluD02462; Thu, 20 Sep 2001 04:47:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04602 Thu, 20 Sep 2001 06:38:46 -0400 (EDT) Date: Thu, 20 Sep 2001 16:17:36 +0530 (IST) From: Puja Puri To: ipsec@lists.tislabs.com Subject: Data structure for SPD policies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi In order to store policies for ipsec, i need a data structure which has optimised search time. In few implementations i have come across, hash tables are most frequently used. Can anyone suggest me a data structure for it? what about using tries? Is anywhere some implementation library for this available? thanks in advance regards puja From owner-ipsec@lists.tislabs.com Thu Sep 20 06:38:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KDcuD10226; Thu, 20 Sep 2001 06:38:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04807 Thu, 20 Sep 2001 08:39:12 -0400 (EDT) Message-ID: <00ed01c141d2$681c3060$d7ce1dd5@mahdavi> From: "mahdavi" To: "James Tiller" Cc: "Derek Atkins" , References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> <003e01c13a7c$8a5d2380$cdce1dd5@mahdavi> <1551697791.20010919073007@lucent.com> Subject: Re: How many spd recrds ? Date: Thu, 20 Sep 2001 17:17:09 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.3825.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi dear James Tiller I think you misundrestood my question. I hope others tell me the answer . ----- Original Message ----- From: "James Tiller" To: "mahdavi" Cc: "Derek Atkins" ; Sent: Wednesday, 19 September, 2001 4:00 ÚÕÑ Subject: Re: How many spd recrds ? > mahdavi - > > I would like to add to this question from a different perspective... > > If you have a high speed IPSec system, how do you look up a possible 4 > billion records fast enough? > > ------------- > Best regards, > -jim > > > Tuesday, September 11, 2001, 12:24:40 AM, mahdavi wrote: > > mahdavi> Hi > mahdavi> O my God. what I asked that you answered me so ? > mahdavi> I did not asked about theorical maximum. > mahdavi> I just said "Typicaly how many SPD records are reqired ?". > > mahdavi> In Other sentence I said "I want to have an estimation of maximum SPD > mahdavi> records that an administrator may defines". > > mahdavi> It is funny to think an administrator may define 2^32 firewall rules; and I > mahdavi> know that. > > mahdavi> I mean regularly ( in average , typically , ... ) how many SPD record may > mahdavi> an administrator define. > > mahdavi> Best regards > mahdavi> mahdavi. > > > >> There isn't any theoretical maximum. It's like asking "how many firewall > >> rules could you have?" The answer: unlimited. > >> > >> There is a practical limit of approximately 2^32 per interface per peer. > >> > >> -derek > >> > >> mahdavi@sepahan.iut.ac.ir writes: > >> > >> > Hi all. > >> > > >> > Imagine we have a high speed security gateway (Giga bit). Typicaly how > mahdavi> many SPD > >> > records are reqired ? > >> > about 10 ? > >> > about 50 ? > >> > about 100 ? > >> > about 1000 !!!??? > >> > > >> > how much? > >> > > >> > I want to have an estimation of maximum SPD records that an > mahdavi> administrator may > >> > defines. > >> > > >> > sincerely yours > >> > mahdavi > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > >> Member, MIT Student Information Processing Board (SIPB) > >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > >> warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Sep 20 06:39:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KDd6D10243; Thu, 20 Sep 2001 06:39:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04858 Thu, 20 Sep 2001 08:44:32 -0400 (EDT) Message-ID: <00ff01c141d2$fba02a80$d7ce1dd5@mahdavi> From: "mahdavi" To: "James Tiller" , "Derek Atkins" Cc: References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> <1401689058.20010919072958@lucent.com> Subject: Re: How many spd recrds ? Date: Thu, 20 Sep 2001 17:21:11 +0430 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.3825.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek. I did not asked about theorical maximum. I just said "Typicaly how many SPD records are reqired ?". In Other sentence I said "I want to have an estimation of maximum SPD records that an administrator may defines". It is funny to think an administrator may define 2^32 firewall rules; and I know that. I mean regularly ( in average , typically , ... ) how many SPD record may an administrator define. Best regards mahdavi. ----- Original Message ----- From: "Derek Atkins" To: "James Tiller" Cc: Sent: Wednesday, 19 September, 2001 6:48 ÚÕÑ Subject: Re: How many spd recrds ? > Actually, theoretically, it can be even bigger than that. You can > imagine a SPD that had multiple entries for each SPI. Imagine a > system where each SPI implies N SPD rules, because you want to define > rules for, say, each and every port for each and every host out there > on the internet (because each host is _special_). > > -derek > > James Tiller writes: > > > Derek - > > > > Just out of curiosity, why 2^32? Is this because the SPI is 32 bits? > > If so, wouldn't this be the limits of the number of SA's effecting the > > SAD, whereas the policy database (SPD) is supporting the "types" or > > attributes defining the SA's? > > > > One more curious point. If the policy defines the accepted operations > > to apply, deny, or pass data - technically, wouldn't that be > > unlimited? Because I could build a policy that affects only certain > > selectors based on IP address or fully qualified name - which could be > > limitless. > > > > Just curious. Thankx for any answer! > > > > ------------- > > Best regards, > > -jim > > > > > > > > Monday, September 10, 2001, 9:36:14 AM, Derek wrote: > > > > Atkins> There isn't any theoretical maximum. It's like asking "how many firewall > > Atkins> rules could you have?" The answer: unlimited. > > > > Atkins> There is a practical limit of approximately 2^32 per interface per peer. > > > > Atkins> -derek > > > > Atkins> mahdavi@sepahan.iut.ac.ir writes: > > > > >> Hi all. > > >> > > >> Imagine we have a high speed security gateway (Giga bit). Typicaly how many SPD > > >> records are reqired ? > > >> about 10 ? > > >> about 50 ? > > >> about 100 ? > > >> about 1000 !!!??? > > >> > > >> how much? > > >> > > >> I want to have an estimation of maximum SPD records that an administrator may > > >> defines. > > >> > > >> sincerely yours > > >> mahdavi > > >> > > >> > > >> > > >> > > >> > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Sep 20 08:05:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KF5jD16663; Thu, 20 Sep 2001 08:05:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05041 Thu, 20 Sep 2001 09:49:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 20 Sep 2001 09:50:05 -0400 To: "john ipsec" From: Stephen Kent Subject: Re: ESP and AH questions Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:56 PM -0400 9/19/01, john ipsec wrote: >(Sorry, if this topic had been discussed before. Is there an FAQ?) > >Questions: > >1. In the tunnel mode, what is the value for the next-header field? >The next-header seems to be the original IP header (unlike in the >transport mode, the next-header is the "transport protocol" header). The outer IP header should contain a Next Protocol value for AH or ESP, and then AH or ESP should contain IP as the Next Protocol value within these IPsec protocols. > >2. The ESP header and trailer do not specify the size of the >"Authentication Data," unlike the AH. It uses SA to deduce the size >of the Authentication Data (if present). If so, why AH cannot use SA >to deduce the size of the Authentication Data field? AH carries a total length field to allow an intermediary to skip over it when used in the IPv6 context, i.e., when it is viewed as an extension header. Steve From owner-ipsec@lists.tislabs.com Thu Sep 20 09:27:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KGRID24963; Thu, 20 Sep 2001 09:27:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05281 Thu, 20 Sep 2001 10:47:39 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: How many spd records ? To: "mahdavi" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "James Tiller" , "Derek Atkins" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 20 Sep 2001 10:59:25 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 09/20/2001 04:00:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA05278 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mahdavi, The answer to your question, well, you won't like the answer, because it isn't black and white. It literally depends on the application, there is no set "right" number. And anyway, I like Jim's question better, as it is more relevant for the forum that is the ietf ipsec working group -- it doesn't just address one individual implementation. So, 4 billion records..... Just for fun..... OK, the first thing that springs to mind is that this requires a dynamic decorrelation algorithm, even though the number of records will increase, it guarantees that each policy (or SPD node) is unique (so no more need for total ordering). Now the policy or SPD database can be kept in a tree, or series of trees. Four billion is a lot, so even though I'd like to use a splay tree (so that last node accessed will be at the root) the amount of processing required to reorganize the tree suggests that this is not a good way to go. So, a fixed binary tree of some sort -- but also look at the traffic patterns a system like this is likely to face, maybe cache the last 20 - 30 entries in a splay tree (depending on the variety of traffic at any one time). Or maybe it's simpler to keep it (the cache, not the entire database) as a linked list and just push the last accessed node to the head of the list and remove the tail. Of course this relies on the thought that we don't have race conditions accessing the database. If we have multiple processors (or barrels) processing packets simultaneously, then the single cache idea won't work well, since access will have to be restricted to a single lookup at a time. -- So, how about a cache per processor? Make true database lookups reentrant, so multiple accesses are allowed, but this suggest that adding and removing entries from the table are going to require a semaphore to halt lookups during addition or removals... Ok, enough fun, I guess I should get back to work..... Steve "mahdavi" t.ac.ir> cc: "Derek Atkins" , Sent by: Subject: Re: How many spd recrds ? owner-ipsec@lists.t islabs.com 09/20/01 08:47 AM Hi dear James Tiller I think you misundrestood my question. I hope others tell me the answer . ----- Original Message ----- From: "James Tiller" To: "mahdavi" Cc: "Derek Atkins" ; Sent: Wednesday, 19 September, 2001 4:00 ÚÕÑ Subject: Re: How many spd recrds ? > mahdavi - > > I would like to add to this question from a different perspective... > > If you have a high speed IPSec system, how do you look up a possible 4 > billion records fast enough? > > ------------- > Best regards, > -jim > > > Tuesday, September 11, 2001, 12:24:40 AM, mahdavi wrote: > > mahdavi> Hi > mahdavi> O my God. what I asked that you answered me so ? > mahdavi> I did not asked about theorical maximum. > mahdavi> I just said "Typicaly how many SPD records are reqired ?". > > mahdavi> In Other sentence I said "I want to have an estimation of maximum SPD > mahdavi> records that an administrator may defines". > > mahdavi> It is funny to think an administrator may define 2^32 firewall rules; and I > mahdavi> know that. > > mahdavi> I mean regularly ( in average , typically , ... ) how many SPD record may > mahdavi> an administrator define. > > mahdavi> Best regards > mahdavi> mahdavi. > > > >> There isn't any theoretical maximum. It's like asking "how many firewall > >> rules could you have?" The answer: unlimited. > >> > >> There is a practical limit of approximately 2^32 per interface per peer. > >> > >> -derek > >> > >> mahdavi@sepahan.iut.ac.ir writes: > >> > >> > Hi all. > >> > > >> > Imagine we have a high speed security gateway (Giga bit). Typicaly how > mahdavi> many SPD > >> > records are reqired ? > >> > about 10 ? > >> > about 50 ? > >> > about 100 ? > >> > about 1000 !!!??? > >> > > >> > how much? > >> > > >> > I want to have an estimation of maximum SPD records that an > mahdavi> administrator may > >> > defines. > >> > > >> > sincerely yours > >> > mahdavi > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > >> Member, MIT Student Information Processing Board (SIPB) > >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > >> warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Sep 20 09:51:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KGp5D27970; Thu, 20 Sep 2001 09:51:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05493 Thu, 20 Sep 2001 11:52:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <00ff01c141d2$fba02a80$d7ce1dd5@mahdavi> References: <200109091405.f89E51Q04924@sepahan.iut.ac.ir> <1401689058.20010919072958@lucent.com> <00ff01c141d2$fba02a80$d7ce1dd5@mahdavi> Date: Thu, 20 Sep 2001 11:49:26 -0400 To: "mahdavi" From: Stephen Kent Subject: Re: How many spd recrds ? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:21 PM +0430 9/20/01, mahdavi wrote: >Hi Derek. >I did not asked about theorical maximum. >I just said "Typicaly how many SPD records are reqired ?". > >In Other sentence I said "I want to have an estimation of maximum SPD >records that an administrator may defines". > >It is funny to think an administrator may define 2^32 firewall rules; and I >know that. > >I mean regularly ( in average , typically , ... ) how many SPD record may >an administrator define. > >Best regards >mahdavi. > there is no simple answer to the question you asked. The number of SPD entries is a function of the local access control policy and the breadth of connectivity. A company using IPsec for an intranet VPN might have very different SPD sizes from a company using IPsec to support lots of dialup road warriors or telecommuters. In many instances your question is very analogous to asking what is the typicaly number of filter rules in a firewall. I think you will find significant variation in the answer to that question as well. Steve From owner-ipsec@lists.tislabs.com Thu Sep 20 09:56:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KGuoD28540; Thu, 20 Sep 2001 09:56:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05498 Thu, 20 Sep 2001 11:53:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 20 Sep 2001 11:54:37 -0400 To: Puja Puri From: Stephen Kent Subject: Re: Data structure for SPD policies Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >hi >In order to store policies for ipsec, i need a data structure which has >optimised search time. In few implementations i have come across, hash >tables are most frequently used. Can anyone suggest me a data structure >for it? >what about using tries? >Is anywhere some implementation library for this available? > >thanks in advance > >regards >puja Remember that, unless you decorrelate the SPD entries first, it must be searched in order, which may preclude other than linear searching. Steve From owner-ipsec@lists.tislabs.com Thu Sep 20 15:02:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8KM2MD07134; Thu, 20 Sep 2001 15:02:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05997 Thu, 20 Sep 2001 16:43:41 -0400 (EDT) Message-Id: <200109202051.f8KKpWE01258@thunk.east.sun.com> From: Bill Sommerfeld To: "Jari Arkko" cc: sleepy-cat@263.net, ipsec@lists.tislabs.com, "Pravin Kantak" Subject: Re: How are Initiator's Proposals checked by Responder? In-Reply-To: Your message of "Thu, 20 Sep 2001 07:43:55 +0300." <00b201c1418e$db330540$8a1b6e0a@arenanet.fi> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 20 Sep 2001 16:51:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is an issue that can be solved either by the duplication of traffic-level > policy information in both the kernel and user spaces, or by an extension > to PF_KEY. An extension that I once designed and reported in a now > expired internet draft can be found below: > > http://www.piuha.net/~jarkko/publications/draft-arkko-pfkey-reference-00.txt A future solaris release will include a PF_KEY extension along these lines (we're calling it "inverse acquire"). - Bill From owner-ipsec@lists.tislabs.com Fri Sep 21 03:29:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LATTD19261; Fri, 21 Sep 2001 03:29:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06893 Fri, 21 Sep 2001 05:23:36 -0400 (EDT) Message-ID: <003b01c14280$7c70d120$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: Subject: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 14:58:57 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C142AD.F163A7A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C142AD.F163A7A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, =20 Can anyone help me to find an answers to following questions 1. One of the reasons cited in support of AH is that=20 it is needed for mobile IP users since, their ip addresses change and need Authentication for the source IP address=20 that can be done by AH. Here I want to know, why can't=20 we make ESP authenticate IP header also? are there any=20 other issues involved in this? 2. Apart from mobile ip user reason, is there any other requirement that needs AH ? -Lokesh ------=_NextPart_000_0038_01C142AD.F163A7A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello all,
 
Can anyone help me to find an answers = to following=20 questions
 
1. One of the reasons cited in support = of AH is=20 that
    it is needed for = mobile IP users=20 since, their ip addresses
   change and need = Authentication for the=20 source IP address
   that can be done by = AH. Here I=20 want to know, why can't
   we make ESP authenticate = IP header=20 also? are there any
   other issues involved in=20 this?
 
2. Apart from mobile ip user reason, is = there=20 any  other
   requirement that needs AH=20 ?
 
 
-Lokesh
------=_NextPart_000_0038_01C142AD.F163A7A0-- From owner-ipsec@lists.tislabs.com Fri Sep 21 06:00:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LD0cD28773; Fri, 21 Sep 2001 06:00:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07103 Fri, 21 Sep 2001 08:12:30 -0400 (EDT) Message-Id: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de> From: "Scheffler, Thomas" To: lokeshnb@intotoinc.com, ipsec@lists.tislabs.com Subject: AW: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 13:56:44 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Lokesh, >Can anyone help me to find an answers to following questions > >1. One of the reasons cited in support of AH is that > it is needed for mobile IP users since, their ip addresses > change and need Authentication for the source IP address > that can be done by AH. Here I want to know, why can't > we make ESP authenticate IP header also? are there any > other issues involved in this? The ESP authentication does not include the IP-header, which is included in the AH authentication. Also you would need a none-encryption for the ESP-'encryptor' which is discouraged. >2. Apart from mobile ip user reason, is there any other > requirement that needs AH ? Huh, I think the whole IPv6-world depends heavily on IPsec and especially AH to authenticate Router-Advertisements and such. There are not so many IPv6 folks active in the IPsec area, or the other way around, therefore it tends to be forgotten. Cheers, Thomas ******************************************** Dipl. Inform. Thomas Scheffler T-Systems Nova GmbH Berkom Berlin, Germany Tel: ++49 (0)30 - 3497 2274 Fax: ++49 (0)30 - 3497 2275 email: thomas.scheffler@telekom.de #>Custom designed reality is a labour intensive product ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. From owner-ipsec@lists.tislabs.com Fri Sep 21 06:01:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LD1bD28826; Fri, 21 Sep 2001 06:01:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07091 Fri, 21 Sep 2001 08:08:30 -0400 (EDT) Subject: main mode with signature authentication To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: 0xLJCDF5BBAABBF0z/0xLJC4CFBEA9B7D6B2BFz/CDMA0xLJCAC2D2B5B2BFz/zte_ltd <0xLJCDF5BBAABBF0z/0xLJC4CFBEA9B7D6B2BFz/CDMA0xLJCAC2D2B5B2BFz/zte_ltd@mail.zte.com.cn> Date: Fri, 21 Sep 2001 08:47:01 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 5.0.8 |June 18, 2001) at 2001-09-21 09:07:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, there are there roundtrips in the process of ISAKMP SA establishment using main mode authenticated with signature,the message is encrypted and authenticated in the last roundtrip,there are two statements: 1.the encryption algorithm is negotiated in payload SA during the first roundtrip, and the key is derivated from SKEYID_e after the second roundtrip. 2.the authentication algorithm(Signature) is designated before current ISAKMP SA negotiation,ie. its designation is irrelevant with current ISAKMP SA negotiation. i cannot confirm the statements,any comment is appreciated. thanks in advance whh From owner-ipsec@lists.tislabs.com Fri Sep 21 06:42:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LDgED01261; Fri, 21 Sep 2001 06:42:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07200 Fri, 21 Sep 2001 08:52:23 -0400 (EDT) Message-ID: <005701c1429d$97f81080$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: "Scheffler, Thomas" Cc: References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de> Subject: Re: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 18:31:49 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Scheffler, Thomas" To: ; Sent: Friday, September 21, 2001 5:26 PM Subject: AW: Why can't ESP authenticate IP header? Hello Thomas, > > >Can anyone help me to find answers to following questions > > > >1. One of the reasons cited in support of AH is that > > it is needed for mobile IP users since, their ip addresses > > change and need Authentication for the source IP address > > that can be done by AH. Here I want to know, why can't > > we make ESP authenticate IP header also? are there any > > other issues involved in this? > > The ESP authentication does not include the IP-header, which is > included in the AH authentication. Also you would need a > none-encryption for the ESP-'encryptor' which is discouraged. I think to you didn't get my question right, I asked why a separate protocol AH is designed just to authenticate ip header, when it could have been very well done using authnetication provided by esp. Also, you said something none-encryption (I assume you mean null-encryption) is required , I don't understand that point, how we need a null encryption if you need to authenticate ip header? -Lokesh > > >2. Apart from mobile ip user reason, is there any other > > requirement that needs AH ? > > Huh, I think the whole IPv6-world depends heavily on IPsec > and especially AH to authenticate Router-Advertisements and > such. > There are not so many IPv6 folks active in the IPsec area, > or the other way around, therefore it tends to be forgotten. > > Cheers, > Thomas > > ******************************************** > > Dipl. Inform. Thomas Scheffler > > T-Systems Nova GmbH > Berkom > Berlin, Germany > > Tel: ++49 (0)30 - 3497 2274 > Fax: ++49 (0)30 - 3497 2275 > > email: thomas.scheffler@telekom.de > > #>Custom designed reality is a labour intensive product > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > From owner-ipsec@lists.tislabs.com Fri Sep 21 10:58:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LHwaD18767; Fri, 21 Sep 2001 10:58:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07468 Fri, 21 Sep 2001 12:37:40 -0400 (EDT) Message-ID: <23051C9F9BABD411A7850002B30847992588F7@delta.allegrosys.com> From: Bora Akyol To: "'lokesh'" Cc: ipsec@lists.tislabs.com Subject: RE: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 09:47:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lokesh There are times when one only needs authentication but not encryption. For example, routing protocol updates will be authenticated but not encrypted. Authentication for BGP, for example, would be a **good** thing (tm). AH fits the bill for this type of application whereas ESP would be overkill. Also, I am not sure how many ESP implementations include NULL encryption. Regards Bora |-----Original Message----- |From: lokesh [mailto:lokeshnb@intotoinc.com] |Sent: Friday, September 21, 2001 6:02 AM |To: Scheffler, Thomas |Cc: ipsec@lists.tislabs.com |Subject: Re: Why can't ESP authenticate IP header? | | | |----- Original Message ----- |From: "Scheffler, Thomas" |To: ; |Sent: Friday, September 21, 2001 5:26 PM |Subject: AW: Why can't ESP authenticate IP header? | | | Hello Thomas, |> |> >Can anyone help me to find answers to following questions |> > |> >1. One of the reasons cited in support of AH is that |> > it is needed for mobile IP users since, their ip addresses |> > change and need Authentication for the source IP address |> > that can be done by AH. Here I want to know, why can't |> > we make ESP authenticate IP header also? are there any |> > other issues involved in this? |> |> The ESP authentication does not include the IP-header, which is |> included in the AH authentication. Also you would need a |> none-encryption for the ESP-'encryptor' which is discouraged. | |I think to you didn't get my question right, I asked why a |separate protocol |AH is designed just to authenticate ip header, when it could |have been very |well done |using authnetication provided by esp. Also, you said something |none-encryption (I assume you mean null-encryption) |is required , I don't understand that point, |how we need a null encryption if you need to authenticate ip header? | |-Lokesh | |> |> >2. Apart from mobile ip user reason, is there any other |> > requirement that needs AH ? |> |> Huh, I think the whole IPv6-world depends heavily on IPsec |> and especially AH to authenticate Router-Advertisements and |> such. |> There are not so many IPv6 folks active in the IPsec area, |> or the other way around, therefore it tends to be forgotten. |> |> Cheers, |> Thomas |> |> ******************************************** |> |> Dipl. Inform. Thomas Scheffler |> |> T-Systems Nova GmbH |> Berkom |> Berlin, Germany |> |> Tel: ++49 (0)30 - 3497 2274 |> Fax: ++49 (0)30 - 3497 2275 |> |> email: thomas.scheffler@telekom.de |> |> #>Custom designed reality is a labour intensive product |> |********************************************************************** |> This email and any files transmitted with it are confidential and |> intended solely for the use of the individual or entity to whom they |> are addressed. If you have received this email in error please notify |> the system manager. |> | From owner-ipsec@lists.tislabs.com Fri Sep 21 11:04:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LI4AD18917; Fri, 21 Sep 2001 11:04:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07556 Fri, 21 Sep 2001 12:59:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 10:09:29 -0700 Message-ID: <4EBB5C35607E7F48B4AE162D956666EF7D4526@guam.corp.axcelerant.com> Thread-Topic: Why can't ESP authenticate IP header? Thread-Index: AcFCrT8zjMgWU7GwRWGay9IKgf3hWgAEh5SQ From: "Christopher Gripp" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA07553 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Each protocol was designed with a different intention in mind. You can think of them as complementary in a way, although in my experience, the majority of today's remote access IPSec VPNs incorporate only ESP. Mostly due to the vast number of NAT'd networks being used. Christopher Gripp Systems Engineer Axcelerant -----Original Message----- From: lokesh [mailto:lokeshnb@intotoinc.com] Sent: Friday, September 21, 2001 6:02 AM To: Scheffler, Thomas Cc: ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? ----- Original Message ----- From: "Scheffler, Thomas" To: ; Sent: Friday, September 21, 2001 5:26 PM Subject: AW: Why can't ESP authenticate IP header? Hello Thomas, > > >Can anyone help me to find answers to following questions > > > >1. One of the reasons cited in support of AH is that > > it is needed for mobile IP users since, their ip addresses > > change and need Authentication for the source IP address > > that can be done by AH. Here I want to know, why can't > > we make ESP authenticate IP header also? are there any > > other issues involved in this? > > The ESP authentication does not include the IP-header, which is > included in the AH authentication. Also you would need a > none-encryption for the ESP-'encryptor' which is discouraged. I think to you didn't get my question right, I asked why a separate protocol AH is designed just to authenticate ip header, when it could have been very well done using authnetication provided by esp. Also, you said something none-encryption (I assume you mean null-encryption) is required , I don't understand that point, how we need a null encryption if you need to authenticate ip header? -Lokesh > > >2. Apart from mobile ip user reason, is there any other > > requirement that needs AH ? > > Huh, I think the whole IPv6-world depends heavily on IPsec > and especially AH to authenticate Router-Advertisements and > such. > There are not so many IPv6 folks active in the IPsec area, > or the other way around, therefore it tends to be forgotten. > > Cheers, > Thomas > > ******************************************** > > Dipl. Inform. Thomas Scheffler > > T-Systems Nova GmbH > Berkom > Berlin, Germany > > Tel: ++49 (0)30 - 3497 2274 > Fax: ++49 (0)30 - 3497 2275 > > email: thomas.scheffler@telekom.de > > #>Custom designed reality is a labour intensive product > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > From owner-ipsec@lists.tislabs.com Fri Sep 21 13:54:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LKshD22530; Fri, 21 Sep 2001 13:54:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07788 Fri, 21 Sep 2001 15:45:04 -0400 (EDT) Message-Id: <5.0.0.25.0.20010921124600.022e6a70@192.168.1.10> X-Sender: pravin@192.168.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 21 Sep 2001 12:52:30 -0700 To: Bora Akyol , "Scheffler, Thomas" From: Pravin Kantak Subject: RE: Why can't ESP authenticate IP header? Cc: ipsec@lists.tislabs.com In-Reply-To: <23051C9F9BABD411A7850002B30847992588F7@delta.allegrosys.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello folks, can somebody point me to the discussion on securing the routing updates with IPSec. it would be very interesting to follow up that discussion. i think, nasty things like OSPF and RIPv2 are still being worked on under the heading "IPSec multicast support". thank you, - pravin At 09:47 AM 9/21/01 -0700, Bora Akyol wrote: >Lokesh > >There are times when one only needs authentication but not encryption. For >example, routing protocol updates will be authenticated but not encrypted. >Authentication for BGP, for example, would be a **good** thing (tm). > >AH fits the bill for this type of application whereas ESP would be overkill. >Also, I am not sure how many ESP implementations include NULL encryption. > >Regards > >Bora > ********************************************************************* Pravin Kantak, http://www.intotoinc.com Intoto Inc. voice : (408)844-0480 Ext 318 3160, De La Cruz Blvd, #100, fax : (408)844-0488 Santa Clara, CA - 95054 ********************************************************************* From owner-ipsec@lists.tislabs.com Fri Sep 21 14:01:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LL1mD22687; Fri, 21 Sep 2001 14:01:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07831 Fri, 21 Sep 2001 16:10:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5.0.0.25.0.20010921124600.022e6a70@192.168.1.10> References: <5.0.0.25.0.20010921124600.022e6a70@192.168.1.10> Date: Fri, 21 Sep 2001 16:13:46 -0400 To: Pravin Kantak From: Stephen Kent Subject: RE: Why can't ESP authenticate IP header? Cc: Bora Akyol , "Scheffler, Thomas" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For use of IPsec with BGP (S-BGP), see the following web site for details: www.ir.bbn.com/projects/sbgp From owner-ipsec@lists.tislabs.com Fri Sep 21 14:28:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LLSED23477; Fri, 21 Sep 2001 14:28:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07879 Fri, 21 Sep 2001 16:40:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <005701c1429d$97f81080$ae0510ac@roc.com> References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de> <005701c1429d$97f81080$ae0510ac@roc.com> Date: Fri, 21 Sep 2001 16:47:40 -0400 To: "lokesh" From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: "Scheffler, Thomas" , Content-Type: multipart/alternative; boundary="============_-1211017089==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1211017089==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >----- Original Message ----- >From: "Scheffler, Thomas" >To: ; >Sent: Friday, September 21, 2001 5:26 PM >Subject: AW: Why can't ESP authenticate IP header? > > > Hello Thomas, >> >> >Can anyone help me to find answers to following questions >> > >> >1. One of the reasons cited in support of AH is that >> > it is needed for mobile IP users since, their ip addresses >> > change and need Authentication for the source IP address >> > that can be done by AH. Here I want to know, why can't >> > we make ESP authenticate IP header also? are there any >> > other issues involved in this? >> >> The ESP authentication does not include the IP-header, which is >> included in the AH authentication. Also you would need a >> none-encryption for the ESP-'encryptor' which is discouraged. > >I think to you didn't get my question right, I asked why a separate protocol >AH is designed just to authenticate ip header, when it could have been very >well done >using authnetication provided by esp. Also, you said something >none-encryption (I assume you mean null-encryption) >is required , I don't understand that point, >how we need a null encryption if you need to authenticate ip header? > Lokesh, ESP can be used to provide authentication for its payload, without encrypting the payload. This is referred to as ESP with NULL encryption, for reasons having to do with how IKE works. If the payload for ESP is an IP packet, i.e., ESP in tunnel mode, then the effect is much like AH, but is much more efficient computationally, because there is no need to jump around the IP header protecting only selected fields. Redesigning ESP to optionally cover selected parts of the IP header, in transport mode, as AH does, would make it a more complex protocol, as a time when simplicity is revered. Making ESP always cover parts of the IP header would cause problems in many instances, although it would make for a simpler protocol than one in which the coverage was optional. Having a separate protocol, AH, is simpler if not everyone has to use it, which is the way we may be heading now. Steve --============_-1211017089==_ma============ Content-Type: text/html; charset="us-ascii" Re: Why can't ESP authenticate IP header?

----- Original Message -----
From: "Scheffler, Thomas" <Thomas.Scheffler@t-systems.de>
To: <lokeshnb@intotoinc.com>; <ipsec@lists.tislabs.com>
Sent: Friday, September 21, 2001 5:26 PM
Subject: AW: Why can't ESP authenticate IP header?


 Hello Thomas,
>
> >Can anyone help me to find  answers to following questions
> >
> >1. One of the reasons cited in support of AH is that
> >    it is needed for mobile IP users since, their ip addresses
> >   change and need Authentication for the source IP address
> >   that can be done by AH. Here I want to know, why can't
> >   we make ESP authenticate IP header also? are there any
> >   other issues involved in this?
>
> The ESP authentication does not include the IP-header, which is
> included in the AH authentication. Also you would need a
> none-encryption for the ESP-'encryptor' which is discouraged.

I think to you didn't get my question right, I asked why a separate protocol
AH is designed just to authenticate ip header, when it could have been very
well done
using authnetication provided by esp. Also, you said something
none-encryption (I assume you mean null-encryption)
is required , I don't understand that point,
how we need a null encryption if you need to authenticate ip header?

Lokesh,

ESP can be used to provide authentication for its payload, without encrypting the payload.  This is referred to as ESP with NULL encryption, for reasons having to do with how IKE works.  If the payload for ESP is an IP packet, i.e., ESP in tunnel mode, then the effect is much like AH, but is much more efficient computationally, because there is no need to jump around the IP header protecting only selected fields.

Redesigning ESP to optionally cover selected parts of the IP header, in transport mode, as AH does, would make it a more complex protocol, as a time when simplicity is revered.  Making ESP always cover parts of the IP header would cause problems in many instances, although it would make for a simpler protocol than one in which the coverage was optional.  Having a separate protocol, AH, is simpler if not everyone has to use it, which is the way we may be heading now.

Steve
--============_-1211017089==_ma============-- From owner-ipsec@lists.tislabs.com Fri Sep 21 15:41:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LMfTD24870; Fri, 21 Sep 2001 15:41:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08000 Fri, 21 Sep 2001 17:50:04 -0400 (EDT) X-Originating-IP: [204.178.20.13] From: "john ipsec" To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 17:57:37 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2001 21:57:37.0547 (UTC) FILETIME=[6D3A55B0:01C142E8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In RFC-2406 (ESP), in "Introduction," it says: "ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality." How can it provide "data origin authentication" in transport mode? John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ipsec@lists.tislabs.com Fri Sep 21 15:41:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LMfXD24881; Fri, 21 Sep 2001 15:41:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07962 Fri, 21 Sep 2001 17:39:44 -0400 (EDT) Message-ID: <23051C9F9BABD411A7850002B30847992588FC@delta.allegrosys.com> From: Bora Akyol To: ipsec@lists.tislabs.com Cc: Bora Akyol Subject: RE: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 14:49:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is good work, but did not get a lot of traction in the IDR WG due to concern on taxing router CPUs that are already taxed. BTW, (afaik) the BBN work is aimed at authenticating individual advertised prefixes as opposed to communication between the hosts which relies on TCP MD5 authentication. The authentication of prefixes prevents a renegade BGP speaker from taking down a portion Internet. The current system in place is based mainly on trust. Bora |-----Original Message----- |From: Stephen Kent [mailto:kent@bbn.com] |Sent: Friday, September 21, 2001 1:14 PM |To: Pravin Kantak |Cc: Bora Akyol; Scheffler, Thomas; ipsec@lists.tislabs.com |Subject: RE: Why can't ESP authenticate IP header? | | |For use of IPsec with BGP (S-BGP), see the following web site |for details: | |www.ir.bbn.com/projects/sbgp | From owner-ipsec@lists.tislabs.com Fri Sep 21 15:54:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LMsOD25165; Fri, 21 Sep 2001 15:54:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08053 Fri, 21 Sep 2001 18:10:11 -0400 (EDT) Message-Id: <200109212218.f8LMI8E10006@thunk.east.sun.com> From: Bill Sommerfeld To: "john ipsec" cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: Your message of "Fri, 21 Sep 2001 17:57:37 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Fri, 21 Sep 2001 18:18:08 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > How can it provide "data origin authentication" in transport mode? By allowing SA's to have a source address attribute and checking this on receipt (as suggested by Steve Bellovin a long time ago). You don't need to include the source address in the hash function if you do a literal compare between the packet source address and the source address of the SA. Solaris's IPsec does this. - Bill From owner-ipsec@lists.tislabs.com Fri Sep 21 15:56:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LMuRD25194; Fri, 21 Sep 2001 15:56:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08060 Fri, 21 Sep 2001 18:12:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <23051C9F9BABD411A7850002B30847992588FC@delta.allegrosys.com> References: <23051C9F9BABD411A7850002B30847992588FC@delta.allegrosys.com> Date: Fri, 21 Sep 2001 18:16:08 -0400 To: Bora Akyol From: Stephen Kent Subject: RE: Why can't ESP authenticate IP header? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:49 PM -0700 9/21/01, Bora Akyol wrote: >This is good work, but did not get a lot of traction in the IDR WG due to >concern on taxing router CPUs that are already taxed. > >BTW, (afaik) the BBN work is aimed at authenticating individual advertised >prefixes as opposed to communication between the hosts which relies on TCP >MD5 authentication. The authentication of prefixes prevents a renegade BGP >speaker from taking down a portion Internet. The current system in place is >based mainly on trust. > >Bora S-BGP uses other mechanisms, in the form of digital signatures carried as transitive optional path attributes, to verify the authorization of AS's to advertise prefixes. The use of IPsec I referred to was precisely for point-to-point router authentication and integrity and is used in lieu of the TCP MD5 checksum hack, since that hack is not cryptographically strong and since it lacks an automated key management protocol. Steve From owner-ipsec@lists.tislabs.com Fri Sep 21 16:00:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LN0ND25242; Fri, 21 Sep 2001 16:00:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08065 Fri, 21 Sep 2001 18:12:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 21 Sep 2001 18:18:26 -0400 To: "john ipsec" From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:57 PM -0400 9/21/01, john ipsec wrote: >In RFC-2406 (ESP), in "Introduction," it says: > >"ESP is used to provide confidentiality, data origin authentication, >connectionless integrity, an anti-replay service (a form of partial >sequence integrity), and limited traffic flow confidentiality." > >How can it provide "data origin authentication" in transport mode? > >John > >_ here data origin authentication is effected by binding the ESP payload (in either mode) to the SA over which it is carried. That SA specifies the granularity of data origin authentication, which might be per subnet, per host, per process, ... Steve From owner-ipsec@lists.tislabs.com Fri Sep 21 17:04:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8M04fD26455; Fri, 21 Sep 2001 17:04:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08247 Fri, 21 Sep 2001 19:15:47 -0400 (EDT) Message-Id: <5.0.0.25.0.20010921161554.05905820@192.168.1.10> X-Sender: pravin@192.168.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 21 Sep 2001 16:22:11 -0700 To: sommerfeld@East.Sun.COM, "john ipsec" From: Pravin Kantak Subject: Re: Why can't ESP authenticate IP header? Cc: kent@bbn.com, ipsec@lists.tislabs.com In-Reply-To: <200109212218.f8LMI8E10006@thunk.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:18 PM 9/21/01 -0400, Bill Sommerfeld wrote: > > How can it provide "data origin authentication" in transport mode? > >By allowing SA's to have a source address attribute and checking this >on receipt (as suggested by Steve Bellovin a long time ago). > >You don't need to include the source address in the hash function if >you do a literal compare between the packet source address and the >source address of the SA. bill, i hope you are talking AH. afaik, ESP processing does not include the source IP address in hash function. IPSec standard does not talk about comparing packet source IP address and SA source IP address. it mentions comparing packet's "destination address + SPI + security protocol" against same triplet in SADB. >Solaris's IPsec does this. if solaris does this, then most probably it has interop issues. - pravin > - Bill ********************************************************************* Pravin Kantak, http://www.intotoinc.com Intoto Inc. voice : (408)844-0480 Ext 318 3160, De La Cruz Blvd, #100, fax : (408)844-0488 Santa Clara, CA - 95054 ********************************************************************* From owner-ipsec@lists.tislabs.com Fri Sep 21 17:10:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8M0AoD26556; Fri, 21 Sep 2001 17:10:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08253 Fri, 21 Sep 2001 19:18:25 -0400 (EDT) Message-Id: <200109212326.f8LNQNE11715@thunk.east.sun.com> From: Bill Sommerfeld To: Pravin Kantak cc: sommerfeld@East.Sun.COM, "john ipsec" , kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: Your message of "Fri, 21 Sep 2001 16:22:11 PDT." <5.0.0.25.0.20010921161554.05905820@192.168.1.10> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 21 Sep 2001 19:26:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >You don't need to include the source address in the hash function if > >you do a literal compare between the packet source address and the > >source address of the SA. > > bill, i hope you are talking AH. afaik, ESP processing does not > include the source IP address in hash function. We don't include the source address in the ESP hash function. We bind the SA to the source address. repeating myself: We do a COMPARE between the packet's source address and the SA's source address (if it has one). > IPSec standard does not talk about comparing packet source IP > address and SA source IP address. it mentions comparing packet's > "destination address + SPI + security protocol" against same triplet > in SADB. > > >Solaris's IPsec does this. > > if solaris does this, then most probably it has interop > issues. we interoperate quite well in transport mode, thank you. - Bill From owner-ipsec@lists.tislabs.com Fri Sep 21 17:22:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8M0M1D26697; Fri, 21 Sep 2001 17:22:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08287 Fri, 21 Sep 2001 19:26:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5.0.0.25.0.20010921161554.05905820@192.168.1.10> References: <5.0.0.25.0.20010921161554.05905820@192.168.1.10> Date: Fri, 21 Sep 2001 19:31:00 -0400 To: Pravin Kantak From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: sommerfeld@East.Sun.COM, "john ipsec" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:22 PM -0700 9/21/01, Pravin Kantak wrote: >At 06:18 PM 9/21/01 -0400, Bill Sommerfeld wrote: >> > How can it provide "data origin authentication" in transport mode? >> >>By allowing SA's to have a source address attribute and checking this >>on receipt (as suggested by Steve Bellovin a long time ago). >> >>You don't need to include the source address in the hash function if >>you do a literal compare between the packet source address and the >>source address of the SA. > > bill, i hope you are talking AH. afaik, ESP processing does >not include the source IP address in hash function. IPSec standard >does not talk about comparing packet source IP address and SA source >IP address. it mentions comparing packet's "destination address + >SPI + security protocol" against same triplet in SADB. Look at 5.2.1 in RFC 2401. That text specifies the matching of the header info in the received (decrypted) packet against the SPD entry associated with the SA in question. Your reference above is for SA selection at a receiver, not checking of the inbound packet for consistency with the SA selectors. Steve From owner-ipsec@lists.tislabs.com Fri Sep 21 17:56:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8M0uHD27489; Fri, 21 Sep 2001 17:56:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08395 Fri, 21 Sep 2001 20:13:10 -0400 (EDT) X-Originating-IP: [138.89.20.42] From: "john ipsec" To: sommerfeld@East.Sun.COM Cc: ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? Date: Fri, 21 Sep 2001 20:20:42 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Sep 2001 00:20:43.0044 (UTC) FILETIME=[6A953640:01C142FC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >By allowing SA's to have a source address attribute and checking this >on receipt (as suggested by Steve Bellovin a long time ago). Thanks for the info. Can the same trick be applied AH, assuming AH does not hash part of the IP header? Of cause, AH includes more bits of the IP header than just the source address. What confuses me is that ESP provides authentication similar to AH, but does it in a different way. Thanks, John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ipsec@lists.tislabs.com Sat Sep 22 04:21:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8MBLqD06137; Sat, 22 Sep 2001 04:21:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08894 Sat, 22 Sep 2001 06:20:16 -0400 (EDT) Message-Id: <200109221027.f8MARdl06488@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: Bora Akyol , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-reply-to: Your message of Fri, 21 Sep 2001 18:16:08 EDT. Date: Sat, 22 Sep 2001 12:27:39 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: The use of IPsec I referred to was precisely for point-to-point router authentication and integrity and is used in lieu of the TCP MD5 checksum hack, since that hack is not cryptographically strong and since it lacks an automated key management protocol. => the main drawback of the MD5 checksum hack is that this doesn't provide a defense against TCP RST attacks (or any attacks at layer 3). IMHO now IPsec is available on routers so you should consider to switch from MD5 checksum hacks to IPsec. We proposed this for IPv6 routers (which are supposed to get IPsec with IPv6 :-): there was a proposal to make AH mandatory for BGP in the 6-bone many years ago. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sat Sep 22 04:21:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8MBLsD06145; Sat, 22 Sep 2001 04:21:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08880 Sat, 22 Sep 2001 06:11:39 -0400 (EDT) Message-Id: <200109221016.f8MAGql06402@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@East.Sun.COM cc: Pravin Kantak , "john ipsec" , kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-reply-to: Your message of Fri, 21 Sep 2001 19:26:23 EDT. <200109212326.f8LNQNE11715@thunk.east.sun.com> Date: Sat, 22 Sep 2001 12:16:52 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: We bind the SA to the source address. repeating myself: We do a COMPARE between the packet's source address and the SA's source address (if it has one). => this is in RFC 2401 5.2.1 step 2 mandatory checks for inbound traffic. But for tunnel mode, do you perform the check on the right source address, the wrong one or on both (cf RFC 2401 r.1.2.1 note 3)? Thanks Francis.Dupont@enst-bretagne.fr PS: the thread is about transport mode where there is only one header so one source address (which MUST be checked against the SA selector which can be a wildcard). From owner-ipsec@lists.tislabs.com Sat Sep 22 04:36:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8MBaxD06411; Sat, 22 Sep 2001 04:36:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08910 Sat, 22 Sep 2001 06:26:52 -0400 (EDT) Message-Id: <200109221032.f8MAWil06524@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "john ipsec" cc: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-reply-to: Your message of Fri, 21 Sep 2001 20:20:42 EDT. Date: Sat, 22 Sep 2001 12:32:44 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: What confuses me is that ESP provides authentication similar to AH, but does it in a different way. => this is true for addresses but not for options/extension headers (as IPv4 options have a very little use this is more an issue for IPv6). Regards Francis.Dupont@enst-bretagne.fr PS: there is a historic point too: the first ESP version have no hash field. From owner-ipsec@lists.tislabs.com Sat Sep 22 09:47:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8MGllD27863; Sat, 22 Sep 2001 09:47:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09268 Sat, 22 Sep 2001 11:36:44 -0400 (EDT) Message-Id: <200109221544.f8MFieNd009142@kebe.east.sun.com> Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: from john ipsec at "Sep 21, 2001 08:20:42 pm" To: john ipsec Date: Sat, 22 Sep 2001 11:44:40 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >By allowing SA's to have a source address attribute and checking this > >on receipt (as suggested by Steve Bellovin a long time ago). > > Thanks for the info. Can the same trick be applied AH, assuming AH does not > hash part of the IP header? Of cause, AH includes more bits of the IP header > than just the source address. Yes the same "trick" can be applied - and even if AH does hash the part of the IP header! In Solaris, we don't even run the HMAC if we the source doesn't match what's in the SA. Consider this way-out corner case: - I have an inbound AH SA - Machine "weirdo" sends me an IP datagram with src=other-guy, dst=me with AH, and the cryptography checks out. - Because my inbound SA has src = weirdo, I reject the inbound AH SA at SA lookup time. If you have a need for a multi-sender SA (e.g. multicast), you should set src = INADDR{,6}_ANY on your SAs. > What confuses me is that ESP provides authentication similar to AH, but does > it in a different way. Yes it is confusing. (There's much historical weirdness as to how this came about.) Dan From owner-ipsec@lists.tislabs.com Sat Sep 22 13:06:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8MK6LD01636; Sat, 22 Sep 2001 13:06:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09528 Sat, 22 Sep 2001 14:48:25 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15276.57020.932624.330098@thomasm-u1.cisco.com> Date: Sat, 22 Sep 2001 11:55:56 -0700 (PDT) To: Dan McDonald Cc: john ipsec , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: <200109221544.f8MFieNd009142@kebe.east.sun.com> References: <200109221544.f8MFieNd009142@kebe.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Doesn't this make multi homing problematic, especially for transport mode? It implies that I have to have an established SA for each interface since the *real* security binding is the three tuple of (src-ip, identity (via spi), key). This sort of sucks. In fact, I'll bet what's really lurking here is the desire to have application layer cross checking since what you're effectively doing is providing a (weak) check to filter out authenticated but unauthorized traffic (ie, filtering crypto protected source spoofing). Mike Dan McDonald writes: > Consider this way-out corner case: > > - I have an inbound AH SA > > - Machine "weirdo" sends me an IP datagram with src=other-guy, dst=me > with AH, and the cryptography checks out. > > - Because my inbound SA has src = weirdo, I reject the inbound AH > SA at SA lookup time. > > If you have a need for a multi-sender SA (e.g. multicast), you should set src > = INADDR{,6}_ANY on your SAs. > > > What confuses me is that ESP provides authentication similar to AH, but does > > it in a different way. > > Yes it is confusing. (There's much historical weirdness as to how this came > about.) > > Dan From owner-ipsec@lists.tislabs.com Sun Sep 23 07:09:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8NE9ZD23119; Sun, 23 Sep 2001 07:09:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10587 Sun, 23 Sep 2001 08:48:29 -0400 (EDT) Message-Id: <200109231254.f8NCsBl14002@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Dan McDonald , john ipsec , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-reply-to: Your message of Sat, 22 Sep 2001 11:55:56 PDT. <15276.57020.932624.330098@thomasm-u1.cisco.com> Date: Sun, 23 Sep 2001 14:54:11 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Doesn't this make multi homing problematic, especially for transport mode? => yes for the transport mode but should not for the tunnel mode (RFC 2401 specifies clearly that the *outer* source address should *not* be checked). It implies that I have to have an established SA for each interface since the *real* security binding is the three tuple of (src-ip, identity (via spi), key). This sort of sucks. => note that the issue is symmetrical, i.e. if the destination is multi-homed then you have to use several SAs or to add address sets in valid selectors or to implement something based on names (this is in RFC 2401 but I never see a concrete implementation of this for SADB). So multi-homing is like mobility: doesn't live in a pleasant way together with IPsec today... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Sep 23 14:01:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8NL1KD08172; Sun, 23 Sep 2001 14:01:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11089 Sun, 23 Sep 2001 15:47:47 -0400 (EDT) Date: Sun, 23 Sep 2001 20:53:24 +0100 From: Derek Fawcus To: lokesh Cc: ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? Message-ID: <20010923205324.A2188@dfawcus-gw-home.cisco.com> References: <003b01c14280$7c70d120$ae0510ac@roc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <003b01c14280$7c70d120$ae0510ac@roc.com>; from lokeshnb@intotoinc.com on Fri, Sep 21, 2001 at 02:58:35PM +0530 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Sep 21, 2001 at 02:58:35PM +0530, lokesh wrote: > > 2. Apart from mobile ip user reason, is there any other > requirement that needs AH ? It also allows a routing header to be authenticated, thus allowing the receiving node to automatically reverse the route. Mind, as to if anyone will use that capability... DF From owner-ipsec@lists.tislabs.com Sun Sep 23 22:03:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O53ID13896; Sun, 23 Sep 2001 22:03:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11624 Sun, 23 Sep 2001 23:51:48 -0400 (EDT) Message-ID: <002501c144ad$97b902c0$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: "Stephen Kent" Cc: References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c1429d$97f81080$ae0510ac@roc.com> Subject: Re: Why can't ESP authenticate IP header? Date: Mon, 24 Sep 2001 09:31:26 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C144DB.AF369100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C144DB.AF369100 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header?Stephan, Thanks for answer, you said making ESP always cover parts of IP header = will create problems in many instances. may I know what are those? Thanks Lokesh ----- Original Message -----=20 From: Stephen Kent=20 To: lokesh=20 Cc: Scheffler, Thomas ; ipsec@lists.tislabs.com=20 Sent: Saturday, September 22, 2001 2:17 AM Subject: Re: Why can't ESP authenticate IP header? ----- Original Message ----- From: "Scheffler, Thomas" To: ; Sent: Friday, September 21, 2001 5:26 PM Subject: AW: Why can't ESP authenticate IP header? Hello Thomas, > > >Can anyone help me to find answers to following questions > > > >1. One of the reasons cited in support of AH is that > > it is needed for mobile IP users since, their ip addresses > > change and need Authentication for the source IP address > > that can be done by AH. Here I want to know, why can't > > we make ESP authenticate IP header also? are there any > > other issues involved in this? > > The ESP authentication does not include the IP-header, which is > included in the AH authentication. Also you would need a > none-encryption for the ESP-'encryptor' which is discouraged. I think to you didn't get my question right, I asked why a separate = protocol AH is designed just to authenticate ip header, when it could have = been very well done using authnetication provided by esp. Also, you said something none-encryption (I assume you mean null-encryption) is required , I don't understand that point, how we need a null encryption if you need to authenticate ip header? Lokesh, ESP can be used to provide authentication for its payload, without = encrypting the payload. This is referred to as ESP with NULL = encryption, for reasons having to do with how IKE works. If the payload = for ESP is an IP packet, i.e., ESP in tunnel mode, then the effect is = much like AH, but is much more efficient computationally, because there = is no need to jump around the IP header protecting only selected fields. Redesigning ESP to optionally cover selected parts of the IP header, = in transport mode, as AH does, would make it a more complex protocol, as = a time when simplicity is revered. Making ESP always cover parts of the = IP header would cause problems in many instances, although it would make = for a simpler protocol than one in which the coverage was optional. = Having a separate protocol, AH, is simpler if not everyone has to use = it, which is the way we may be heading now. Steve ------=_NextPart_000_0022_01C144DB.AF369100 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header?
Stephan,
Thanks for answer, you said making ESP = always cover=20 parts of IP header will create problems in many instances.
may I know what are those?
 
Thanks
Lokesh
----- Original Message -----
From:=20 Stephen Kent =
To: lokesh=20
Cc: Scheffler, Thomas ; ipsec@lists.tislabs.com
Sent: Saturday, September 22, = 2001 2:17=20 AM
Subject: Re: Why can't ESP = authenticate=20 IP header?


----- Original Message -----
From:=20 "Scheffler, Thomas" <Thomas.Scheffler@t-systems.= de>
To:=20 <lokeshnb@intotoinc.com>;=20 <ipsec@lists.tislabs.com>Sent:=20 Friday, September 21, 2001 5:26 PM
Subject: AW: Why can't ESP=20 authenticate IP header?


 Hello = Thomas,
>
>=20 >Can anyone help me to find  answers to following = questions
>=20 >
> >1. One of the reasons cited in support of AH is=20 that
> >    it is needed for mobile IP users = since,=20 their ip addresses
> >   change and need = Authentication=20 for the source IP address
> >   that can be done = by AH.=20 Here I want to know, why can't
> >   we make ESP=20 authenticate IP header also? are there any
> >   = other=20 issues involved in this?
>
> The ESP authentication does = not=20 include the IP-header, which is
> included in the AH = authentication.=20 Also you would need a
> none-encryption for the = ESP-'encryptor' which=20 is discouraged.

I think to you didn't get my question right, = I asked=20 why a separate protocol
AH is designed just to authenticate ip = header,=20 when it could have been very
well done
using authnetication = provided=20 by esp. Also, you said something
none-encryption (I assume you = mean=20 null-encryption)
is required , I don't understand that = point,
how we need a null encryption if you = need to=20 authenticate ip header?

Lokesh,

ESP can be used to provide authentication for its payload, = without=20 encrypting the payload.  This is referred to as ESP with NULL = encryption,=20 for reasons having to do with how IKE works.  If the payload for = ESP is=20 an IP packet, i.e., ESP in tunnel mode, then the effect is much like = AH, but=20 is much more efficient computationally, because there is no need to = jump=20 around the IP header protecting only selected fields.

Redesigning ESP to optionally cover selected parts of the IP = header, in=20 transport mode, as AH does, would make it a more complex protocol, as = a time=20 when simplicity is revered.  Making ESP always cover parts = of the=20 IP header would cause problems in many instances, although it would = make for a=20 simpler protocol than one in which the coverage was optional.  = Having a=20 separate protocol, AH, is simpler if not everyone has to use it, which = is the=20 way we may be heading now.

Steve
------=_NextPart_000_0022_01C144DB.AF369100-- From owner-ipsec@lists.tislabs.com Sun Sep 23 23:59:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O6xID25984; Sun, 23 Sep 2001 23:59:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA11844 Mon, 24 Sep 2001 01:59:45 -0400 (EDT) Message-ID: <000801c144bf$7f85c500$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: Subject: need a pointer Date: Mon, 24 Sep 2001 11:39:38 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C144ED.9792C200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C144ED.9792C200 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello All, I have got couple of questions on purely TCP and its operation.=20 can anybody point me to correct mailing list for TCP? or is it ok to post them here? thanks Lokesh ------=_NextPart_000_0005_01C144ED.9792C200 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I  have got couple of questions on = purely TCP=20 and its operation.
can anybody point me to correct = mailing list=20 for TCP?
or is it ok to post them = here?
 
thanks
Lokesh
------=_NextPart_000_0005_01C144ED.9792C200-- From owner-ipsec@lists.tislabs.com Mon Sep 24 08:02:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OF2jD02040; Mon, 24 Sep 2001 08:02:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12665 Mon, 24 Sep 2001 10:04:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <002501c144ad$97b902c0$ae0510ac@roc.com> References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c142 9d$97f81080$ae0510ac@roc.com> <002501c144ad$97b902c0$ae0510ac@roc.com> Date: Mon, 24 Sep 2001 10:08:54 -0400 To: "lokesh" From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: Content-Type: multipart/alternative; boundary="============_-1210781618==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1210781618==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:31 AM +0530 9/24/01, lokesh wrote: >Stephan, >Thanks for answer, you said making ESP always cover parts of IP >header will create problems in many instances. >may I know what are those? > >Thanks >Lokesh As noted, ESP coverage of selected header fields would increase complexity and reduce performance. It also would create even more circumstances where NAT could interfere with IPsec use. Today, using ESP in tunnel mode can be made to work with NAT, but if the outer S/D IP addresses were covered, that capability (I hesitate to call it a feature) would go away. Steve --============_-1210781618==_ma============ Content-Type: text/html; charset="us-ascii" Re: Why can't ESP authenticate IP header?
At 9:31 AM +0530 9/24/01, lokesh wrote:
Stephan,
Thanks for answer, you said making ESP always cover parts of IP header will create problems in many instances.
may I know what are those?
 
Thanks
Lokesh

As noted, ESP coverage of selected header fields would increase complexity and reduce performance. It also would create even more circumstances where NAT could interfere with IPsec use. Today, using ESP in tunnel mode can be made to work with NAT, but if the outer S/D IP addresses were covered, that capability (I hesitate to call it a feature) would go away.

Steve
--============_-1210781618==_ma============-- From owner-ipsec@lists.tislabs.com Mon Sep 24 08:03:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OF3XD02069; Mon, 24 Sep 2001 08:03:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12642 Mon, 24 Sep 2001 09:44:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15276.57020.932624.330098@thomasm-u1.cisco.com> References: <200109221544.f8MFieNd009142@kebe.east.sun.com> <15276.57020.932624.330098@thomasm-u1.cisco.com> Date: Mon, 24 Sep 2001 09:45:38 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:55 AM -0700 9/22/01, Michael Thomas wrote: >Doesn't this make multi homing problematic, >especially for transport mode? It implies that I >have to have an established SA for each interface >since the *real* security binding is the three >tuple of (src-ip, identity (via spi), key). This >sort of sucks. > >In fact, I'll bet what's really lurking here is >the desire to have application layer cross >checking since what you're effectively doing is >providing a (weak) check to filter out >authenticated but unauthorized traffic (ie, >filtering crypto protected source spoofing). > > Mike Mike, I would not characterize this as "application layer cross checking." Access control is the motivation for this check, and it is consistent with the principle of least privilege. We have many examples of systems that have been vulnerable because they made the assumption that everyone peer is "trusted." We often hear folks use this sort of terminology in discussing IPsec SAs. A compliant IPsec implementation, using the SPD, expresses access control constraints on all communication that passes through it. The check performed by a receiver after IPsec processing ensures that no peer can violate the access control parameters that characterize the SA carrying traffic from that peer. This is just good security engineering. Yes, the traffic has passed a cryptographic data origin authentication check, but a failure to perform this check would undermine the access control features. Relative to the stated goals, the check is not "weak;" it is precise. Steve From owner-ipsec@lists.tislabs.com Mon Sep 24 08:11:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OFBWD03074; Mon, 24 Sep 2001 08:11:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12718 Mon, 24 Sep 2001 10:20:14 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15279.17123.505135.414551@thomasm-u1.cisco.com> Date: Mon, 24 Sep 2001 07:27:47 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: References: <200109221544.f8MFieNd009142@kebe.east.sun.com> <15276.57020.932624.330098@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >In fact, I'll bet what's really lurking here is > >the desire to have application layer cross > >checking since what you're effectively doing is > >providing a (weak) check to filter out > >authenticated but unauthorized traffic (ie, > >filtering crypto protected source spoofing). > > > Mike, > > I would not characterize this as "application layer cross > checking." Nor would I. At best, it's a substitute for application layer cross checking which does not exist. > Access control is the motivation for this check, and it is consistent > with the principle of least privilege. We have many examples of > systems that have been vulnerable because they made the assumption > that everyone peer is "trusted." Sure. That's why applications need the ability get access to credentials when available. Enforcing source address to SA foils exactly one attack but leaves you completely vulnerable to any number of attacks with the higher layer protocols which have no clue whether the credentials presented at the IP layer disagree with the identities presented at the application layer. Also: as I mentioned, binding to the source IP address makes multi-homing, mobility, and renumbering problematic. > We often hear folks use this sort of > terminology in discussing IPsec SAs. A compliant IPsec > implementation, using the SPD, expresses access control constraints > on all communication that passes through it. The check performed by a > receiver after IPsec processing ensures that no peer can violate the > access control parameters that characterize the SA carrying traffic > from that peer. This is just good security engineering. Good security engineering needs to consider the whole system. If I can use strong credentials at one layer and weak credentials at another, the system is as strong as the weak credentials. For many protocols, IPsec is about the only answer if you want strong credentials any time soon (TLS isn't currently viable if you want to use UDP). What we have right now, however, is a return to the past for those applications where you can be pretty sure about their source IP address, but have to resort reverse DNS mappings (and their well known weaknesses) or worse to have any ability to cross check the asserted identity in, say, a SIP or SMTP message. > Yes, the > traffic has passed a cryptographic data origin authentication check, > but a failure to perform this check would undermine the access > control features. Relative to the stated goals, the check is not > "weak;" it is precise. Hamfisted is closer to the truth. ACL based security is better than nothing, but it is both crude and weak in comparison to a well integrated system with strong authentication throughout the layers. Mike From owner-ipsec@lists.tislabs.com Mon Sep 24 15:39:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OMdbD19261; Mon, 24 Sep 2001 15:39:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13261 Mon, 24 Sep 2001 17:34:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <15279.17123.505135.414551@thomasm-u1.cisco.com> References: <200109221544.f8MFieNd009142@kebe.east.sun.com> <15276.57020.932624.330098@thomasm-u1.cisco.com> <15279.17123.505135.414551@thomasm-u1.cisco.com> Date: Mon, 24 Sep 2001 17:40:17 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: Michael Thomas , ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1210754704==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1210754704==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:27 AM -0700 9/24/01, Michael Thomas wrote: >Stephen Kent writes: > > >In fact, I'll bet what's really lurking here is > > >the desire to have application layer cross > > >checking since what you're effectively doing is > > >providing a (weak) check to filter out > > >authenticated but unauthorized traffic (ie, > > >filtering crypto protected source spoofing). > > > > > Mike, > > > > I would not characterize this as "application layer cross > > checking." > > Nor would I. At best, it's a substitute for > application layer cross checking which does > not exist. The terms quoted above are your words! But, my point is that the term "application later" is inappropriate, because the fields in question are from the IP and transport layer. Also, it is not always desirable to rely solely on applications to perform access control. For example, if we fail to match traffic against SA parameters within IPsec, we loose the ability to easily identify the sources of traffic with spoofed IP source addresses. We all realize that it's very difficult to manage the configuration of access controls on all hosts inside of an organization security perimeter, hence the popularity of firewalls. IPsec offers the same sort of perimeter access controls that we have come to rely on, but with cryptographic protection for traffic flows, which adds a considerable level of assurance to this mechanism. > > > Access control is the motivation for this check, and it is consistent > > with the principle of least privilege. We have many examples of > > systems that have been vulnerable because they made the assumption > > that everyone peer is "trusted." > > Sure. That's why applications need the ability get > access to credentials when available. Enforcing > source address to SA foils exactly one attack but > leaves you completely vulnerable to any number of > attacks with the higher layer protocols which have > no clue whether the credentials presented at the > IP layer disagree with the identities presented at > the application layer. Also: as I mentioned, binding > to the source IP address makes multi-homing, mobility, > and renumbering problematic. As noted above, if we are implementing IPsec at a security gateway, there is no standard means of relaying credentials between the SG and a host. Even in an end system IPsec implementation, use of the SPD allows one to specify and enforce access controls for applications without modifying those applications. Also, some vendors are planning to offer IPsec in a NIC, which would enforce these controls without having to rely on the host OS, an attractive option given the sorry state of OS security. Your last comment argues that this requirement of IPsec makes support for some communication scenarios harder. I don't see this as true for renumbering, unless the renumbering takes place while the SA is in place. Remember that one can populate SPD entries for source and destination addresses with symbolic values (e.g., DNS names or RFC822 addresses), which insulates them from renumbering conducted on a longer time scale. The same is true for mobility. Anyway, the requirement to match traffic against the SPD corresponding SPD entries is not new; it has been a part of IPsec for a long time and I do not see it changing in the next rounds of revisions to 2401. > > We often hear folks use this sort of > > terminology in discussing IPsec SAs. A compliant IPsec > > implementation, using the SPD, expresses access control constraints > > on all communication that passes through it. The check performed by a > > receiver after IPsec processing ensures that no peer can violate the > > access control parameters that characterize the SA carrying traffic > > from that peer. This is just good security engineering. > > Good security engineering needs to consider the > whole system. If I can use strong credentials at > one layer and weak credentials at another, the > system is as strong as the weak credentials. For > many protocols, IPsec is about the only answer if > you want strong credentials any time soon (TLS isn't > currently viable if you want to use UDP). I assume that what you meant to say above was that if I can choose to supply weak or strong credentials, then an attacker may exploit that design error. That's true, whether the error occurs due to mismatches arising at different layers or via other means, e.g., the ability to negotiate user authentication mechanisms "down." But, what we are talking about is provision of access controls (not quite the same as user or data origin authentication) in IPsec not in lieu of other controls, but in addition to other controls that might be employed. Also, TLS will NEVER support UDP, unless one redesigns the protocol and keeps the name constant, since TLS/SSL rely on sequenced delivery of the record protocol sublayer. > What we have right now, however, is a return to the > past for those applications where you can be pretty > sure about their source IP address, but have to resort > reverse DNS mappings (and their well known weaknesses) > or worse to have any ability to cross check the > asserted identity in, say, a SIP or SMTP message. Your comments here are not very clear, but I'll take a guess at what you may be trying to express and respond accordingly. If one makes use of the symbolic IP address facility of IPsec, and uses appropriate credentials, then you can do better, but DNS security is a limiting factor in any case. > > > Yes, the > > traffic has passed a cryptographic data origin authentication check, > > but a failure to perform this check would undermine the access > > control features. Relative to the stated goals, the check is not > > "weak;" it is precise. > > Hamfisted is closer to the truth. ACL based security > is better than nothing, but it is both crude and weak > in comparison to a well integrated system with strong > authentication throughout the layers. I presume that you are referring to a rather narrow definition of "ACL" here, one that applies only to filter rules in a router, firewall, or IPsec device. Stong authentication is not necessarily a great measure "throughout the layers." We have enough trouble getting people to invest in security measures at any layer, so it behoves us to not make suggestions for security mechanisms that may have moderate or high costs and minimal benefits. Your closing comment, interpreted literally, would call for crypto authentication at the MAC layer (we could use IEEE 802.11), IP layer (IPsec), transport layer (no current standards here), session layer (SSL/TLS), and application layer (application specific protocols or maybe GSSAPI-based measures). Is it really appropriate to invest in strong authentication at all layers for all traffic? Probably not. That, in part, is why we have no transport layer security protocols today (despite the TLS misnomer). That is why we have almost no deployed use of MAC layer security protocols today. Application layer security requires retrofitting applications, which is costly, and it fails to provide protection for applications that offer backwards-compatible non-authenticated modes of operations. In part IPsec is offered as an alternative to this sort of retrofit, for applications that do not really need application-specific security. It's not the only choice, e.g., TLS/SSL is also popular, but has limitations re transport protocols and the need to deploy it at the end system, not at an intermediate system. Steve --============_-1210754704==_ma============ Content-Type: text/html; charset="us-ascii" Re: Why can't ESP authenticate IP header?
At 7:27 AM -0700 9/24/01, Michael Thomas wrote:
Stephen Kent writes:
 > >In fact, I'll bet what's really lurking here is
 > >the desire to have application layer cross
 > >checking since what you're effectively doing is
 > >providing a (weak) check to filter out
 > >authenticated but unauthorized traffic (ie,
 > >filtering crypto protected source spoofing).
 > >
 > Mike,
 >
 > I would not characterize this as "application layer cross
 > checking."

   Nor would I. At best, it's a substitute for
   application layer cross checking which does
   not exist.

The terms quoted above are your words! But, my point is that the term "application later" is inappropriate, because the fields in question are from the IP and transport layer. Also, it is not always desirable to rely solely on applications to perform access control. For example, if we fail to match traffic against SA parameters within IPsec, we loose the ability to easily identify the sources of traffic with spoofed IP source addresses. We all realize that it's very difficult to manage the configuration of access controls on all hosts inside of an organization security perimeter, hence the popularity of firewalls. IPsec offers the same sort of perimeter access controls that we have come to rely on, but with cryptographic protection for traffic flows, which adds a considerable level of assurance to this mechanism.


 > Access control is the motivation for this check, and it is consistent
 > with the principle of least privilege. We have many examples of
 > systems that have been vulnerable because they made the assumption
 > that everyone peer is "trusted."

   Sure. That's why applications need the ability get
   access to credentials when available. Enforcing
   source address to SA foils exactly one attack but
   leaves you completely vulnerable to any number of
   attacks with the higher layer protocols which have
   no clue whether the credentials presented at the
   IP layer disagree with the identities presented at
   the application layer. Also: as I mentioned, binding
   to the source IP address makes multi-homing, mobility,
   and renumbering problematic.

As noted above, if we are implementing IPsec at a security gateway, there is no standard means of relaying credentials between the SG and a host. Even in an end system IPsec implementation, use of the SPD allows one to specify and enforce access controls for applications without modifying those applications. Also, some vendors are planning to offer IPsec in a NIC, which would enforce these controls without having to rely on the host OS, an attractive option given the sorry state of OS security.

Your last comment argues that this requirement of IPsec makes support for some communication scenarios harder.  I don't see this as true for renumbering, unless the renumbering takes place while the SA is in place.  Remember that one can populate SPD entries for source and destination addresses with symbolic values (e.g., DNS names or RFC822 addresses), which insulates them from renumbering conducted on a longer time scale. The same is true for mobility.  Anyway, the requirement to match traffic against the SPD corresponding SPD entries is not new; it has been a part of IPsec for a long time and I do not see it changing in the next rounds of revisions to 2401.

 > We often hear folks use this sort of
 > terminology in discussing IPsec SAs.  A compliant IPsec
 > implementation, using the SPD, expresses access control constraints
 > on all communication that passes through it. The check performed by a
 > receiver after IPsec processing ensures that no peer can violate the
 > access control parameters that characterize the SA carrying traffic
 > from that peer. This is just good security engineering. 

   Good security engineering needs to consider the
   whole system. If I can use strong credentials at
   one layer and weak credentials at another, the
   system is as strong as the weak credentials. For
   many protocols, IPsec is about the only answer if
   you want strong credentials any time soon (TLS isn't
   currently viable if you want to use UDP).

I assume that what you meant to say above was that if I can choose to supply weak or strong credentials, then an attacker may exploit that design error. That's true, whether the error occurs due to mismatches arising at different layers or via other means, e.g., the ability to negotiate user authentication mechanisms "down." But, what we are talking about is provision of access controls (not quite the same as user or data origin authentication) in IPsec not in lieu of other controls, but in addition to other controls that might be employed. Also, TLS will NEVER support UDP, unless one redesigns the protocol and keeps the name constant, since TLS/SSL rely on sequenced delivery of the record protocol sublayer.

   What we have right now, however, is a return to the
   past for those applications where you can be pretty
   sure about their source IP address, but have to resort
   reverse DNS mappings (and their well known weaknesses)
   or worse to have any ability to cross check the
   asserted identity in, say, a SIP or SMTP message.

Your comments here are not very clear, but I'll take a guess at what you may be trying to express and respond accordingly. If one makes use of the symbolic IP address facility of IPsec, and uses appropriate credentials, then you can do better, but DNS security is a limiting factor in any case.


 > Yes, the
 > traffic has passed a cryptographic data origin authentication check,
 > but a failure to perform this check would undermine the access
 > control features. Relative to the stated goals, the check is not
 > "weak;" it is precise.

   Hamfisted is closer to the truth. ACL based security
   is better than nothing, but it is both crude and weak
   in comparison to a well integrated system with strong
   authentication throughout the layers.

I presume that you are referring to a rather narrow definition of "ACL" here, one that applies only to filter rules in a router, firewall, or IPsec device.  Stong authentication is not necessarily a great measure "throughout the layers." We have enough trouble getting people to invest in security measures at any layer, so it behoves us to not make suggestions for security mechanisms that may have moderate or high costs and minimal benefits.

Your closing comment, interpreted literally, would call for crypto authentication at the MAC layer (we could use IEEE 802.11), IP layer (IPsec), transport layer (no current standards here), session layer (SSL/TLS), and application layer (application specific protocols or maybe GSSAPI-based measures). Is it really appropriate to invest in strong authentication at all layers for all traffic? Probably not. That, in part, is why we have no transport layer security protocols today (despite the TLS misnomer). That is why we have almost no deployed use of MAC layer security protocols today.  Application layer security requires retrofitting applications, which is costly, and it fails to provide protection for applications that offer backwards-compatible non-authenticated modes of operations. In part IPsec is offered as an alternative to this sort of retrofit, for applications that do not really need application-specific security.  It's not the only choice, e.g., TLS/SSL is also popular, but has limitations re transport protocols and the need to deploy it at the end system, not at an intermediate system.

Steve
--============_-1210754704==_ma============-- From owner-ipsec@lists.tislabs.com Mon Sep 24 16:23:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ONN8D20137; Mon, 24 Sep 2001 16:23:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13447 Mon, 24 Sep 2001 18:37:05 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15279.46933.30963.876231@thomasm-u1.cisco.com> Date: Mon, 24 Sep 2001 15:44:37 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: delete grace timers X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wanted to get this group's read on the utility of grace timers, specifically when deleting SA's. As far as I know IKE is silent on this matter, but there is a potential race condition with packets on a to-be-deleted SA with the delete notification. With QoS reordering this may actually be more frequent than it sounds. So the question I have is: 1) Does implementing grace timers sound like a useful addition to the protocol? 2) Should this actually be recommended by the specs? I ask both in terms of KINK and SOI. At some level, it really is an implentation detail, but it sounds like experience shows that unless it's a MUST or a SHOULD, implementation will be spotty. Mike From owner-ipsec@lists.tislabs.com Mon Sep 24 19:10:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8P2AYD22731; Mon, 24 Sep 2001 19:10:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13770 Mon, 24 Sep 2001 21:17:36 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15279.56567.804586.658196@thomasm-u1.cisco.com> Date: Mon, 24 Sep 2001 18:25:11 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? In-Reply-To: References: <200109221544.f8MFieNd009142@kebe.east.sun.com> <15276.57020.932624.330098@thomasm-u1.cisco.com> <15279.17123.505135.414551@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve -- I think we are much more in agreement than disagreement. My main thrust of this admitted ongoing hobby horse is that IPsec for better or worse is the best we're likely to get for some time for a whole range of protocols which either do not have any native crypto support or have modules which aren't widely implemented. Unfortuntely, IPsec has had a very clear bias toward security gateways because quite frankly that's where the money is. I'm in agreement that TLS is a misnomer which is why I want to make certain that transport mode IPsec is a first class citizen, and that it can be used as an alternative when TLS is not possible or desirable. The fact that nobody's built an API which allows transport of credentials up to the application layer says to me quite clearly that IPsec is not yet complete for the role that I think we can all agree would be highly advantageous: having strong crypto deployed far and wide on as many hosts and routers as possible, with the concomitant utility of being able to provide strong authentication to various applications which would otherwise have no other recourse. A few more inline: Stephen Kent writes: > The terms quoted above are your words! But, my point is that the term > "application later" is inappropriate, because the fields in question > are from the IP and transport layer. Also, it is not always desirable > to rely solely on applications to perform access control. For > example, if we fail to match traffic against SA parameters within > IPsec, we loose the ability to easily identify the sources of traffic > with spoofed IP source addresses. Yes, but at the cost of transparency of IP addresses to security associations. This affects mobility, multihoming and renumbering; it's not a zero cost tradeoff. > As noted above, if we are implementing IPsec at a security gateway, > there is no standard means of relaying credentials between the SG and > a host. I only meant this in the context of transport mode host to host. > Your last comment argues that this requirement of IPsec makes support > for some communication scenarios harder. I don't see this as true > for renumbering, unless the renumbering takes place while the SA is > in place. Well...? Is that not a valid concern? > Remember that one can populate SPD entries for source and > destination addresses with symbolic values (e.g., DNS names or RFC822 > addresses), which insulates them from renumbering conducted on a > longer time scale. The same is true for mobility. But that doesn't do much good if the kernel then happily helps you by filtering out that obvious spoofing attack for you... > I assume that what you meant to say above was that if I can choose to > supply weak or strong credentials, then an attacker may exploit that > design error. I meant that if I have to supply strong credentials at lower layer, but have to rely on weak credentials at a higher layer, then the system is only as strong as the weak credentials. This in fact may be adequate for some use scenarios; manifestly: this is what IPsec as currently implemented provides. However, this is not a panecea, and specifically does not help you in situations where attackers might be able to authenticate via IPsec/IKE but forge identities with some application layer protocol like, say, SIP. > We have enough trouble getting > people to invest in security measures at any layer, so it behoves us > to not make suggestions for security mechanisms that may have > moderate or high costs and minimal benefits. I meant "throughout" figuratively. Mike From owner-ipsec@lists.tislabs.com Mon Sep 24 22:46:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8P5kfD26222; Mon, 24 Sep 2001 22:46:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14131 Tue, 25 Sep 2001 00:46:19 -0400 (EDT) Message-ID: <002101c1457e$62e73540$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: "Stephen Kent" Cc: References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c1429d$97f81080$ae0510ac@roc.com> <002501c144ad$97b902c0$ae0510ac@roc.com> Subject: Re: Why can't ESP authenticate IP header? Date: Tue, 25 Sep 2001 10:25:54 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C145AC.75278420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C145AC.75278420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header?As noted, ESP coverage of = selected header fields would increase complexity and reduce performance. = It also would create even more circumstances where NAT could interfere = with IPsec use. Today, using ESP in tunnel mode can be made to work with = NAT, but if the outer S/D IP addresses were covered, that capability (I = hesitate to call it a feature) would go away. Steve, As for as I know, in many implementations, NAT is done prior to ipsec = processing at the sending end, and Ipsec processing is done before NAT = at the receiving end.=20 Are there situvations where NAT would interfere in ipsec processing ? = if so, kindly will you brief them? Assuming there will be situations where NAT will interfere with IPsec = processing, how AH in transport mode will work there?=20 Thanks=20 Lokesh. ------=_NextPart_000_001E_01C145AC.75278420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header?
As noted, ESP coverage of selected header fields would increase=20 complexity and reduce performance. It also would create even more=20 circumstances where NAT could interfere with IPsec use. Today, using = ESP in=20 tunnel mode can be made to work with NAT, but if the outer S/D IP = addresses=20 were covered, that capability (I hesitate to call it a feature) would = go=20 away.
 
Steve,
 
As for as I know, in  many = implementations,=20 NAT is done prior to ipsec processing at the sending end, and Ipsec = processing=20 is done before NAT at the receiving end.
Are there situvations where NAT would = interfere=20 in ipsec processing ? if so, kindly will you brief them?
 
Assuming there will be situations = where NAT will=20 interfere with IPsec processing, how AH in transport mode will work = there?=20
 
Thanks
Lokesh.
------=_NextPart_000_001E_01C145AC.75278420-- From owner-ipsec@lists.tislabs.com Tue Sep 25 06:04:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PD4xD04368; Tue, 25 Sep 2001 06:04:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14864 Tue, 25 Sep 2001 08:01:25 -0400 (EDT) Reply-To: From: "Sridhar J" To: "Ipsec \(E-mail\)" , "Users \(E-mail\)" , Subject: cisco rsa key - openssl read Date: Sat, 22 Sep 2001 14:43:05 +0530 Message-Id: <000c01c14346$cb737e00$2702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , I am sorry this may not be the appropriate mailing list to ask this problem . I was under the impression that cisco router which I have displays the rsa public key in asn1 der form as decsribed in rfc 2459 . I need to extract mod and exponent from this key , so I copied the displayed public key into a file and gave input to openssl (0.9.5a) using the command openssl rsa -inform DER -in infile1.der -text -out outfile2.txt which is failing to read the key.. Is cisco router and displaying properly or openssl is not able to read can anyone help me reqarding this issue , thanks in advance . re sridhara .j www.futsoft.com From owner-ipsec@lists.tislabs.com Tue Sep 25 06:13:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PDDkD04671; Tue, 25 Sep 2001 06:13:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14941 Tue, 25 Sep 2001 08:34:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <002101c1457e$62e73540$ae0510ac@roc.com> References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c142 9d$97f81080$ae0510ac@roc.com> <002501c144ad$97b902c0$ae0510ac@roc. com> <002101c1457e$62e73540$ae0510ac@roc.com> Date: Tue, 25 Sep 2001 08:43:02 -0400 To: "lokesh" From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: Content-Type: multipart/alternative; boundary="============_-1210700706==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1210700706==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:25 AM +0530 9/25/01, lokesh wrote: >As noted, ESP coverage of selected header fields would increase >complexity and reduce performance. It also would create even more >circumstances where NAT could interfere with IPsec use. Today, using >ESP in tunnel mode can be made to work with NAT, but if the outer >S/D IP addresses were covered, that capability (I hesitate to call >it a feature) would go away. > >Steve, > >As for as I know, in many implementations, NAT is done prior to >ipsec processing at the sending end, and Ipsec processing is done >before NAT at the receiving end. >Are there situvations where NAT would interfere in ipsec processing >? if so, kindly will you brief them? > >Assuming there will be situations where NAT will interfere with >IPsec processing, how AH in transport mode will work there? I get the feeling that you have not been reading this list for very long. Yes, a combined IPsec/NAT implementation in a security gateway avoids the problems I cited. The NAT problems I refer to arise when NAT takes place at a device that is between the IPsec implementation and the Internet. For example, I am in a hotel room in London now and if I had IPsec on my laptop, it would have to deal with the NAT box that the hotel has deployed. Same problem arises in many cable modem nets, and for desktop IPsec implementations in corporate environments where NAT is performed at the gateway/firewall. Steve --============_-1210700706==_ma============ Content-Type: text/html; charset="us-ascii" Re: Why can't ESP authenticate IP header?
At 10:25 AM +0530 9/25/01, lokesh wrote:
As noted, ESP coverage of selected header fields would increase complexity and reduce performance. It also would create even more circumstances where NAT could interfere with IPsec use. Today, using ESP in tunnel mode can be made to work with NAT, but if the outer S/D IP addresses were covered, that capability (I hesitate to call it a feature) would go away.
 
Steve,
 
As for as I know, in  many implementations, NAT is done prior to ipsec processing at the sending end, and Ipsec processing is done before NAT at the receiving end.
Are there situvations where NAT would interfere in ipsec processing ? if so, kindly will you brief them?
 
Assuming there will be situations where NAT will interfere with IPsec processing, how AH in transport mode will work there?

I get the feeling that you have not been reading this list for very long.

Yes, a combined IPsec/NAT implementation in a security gateway avoids the problems I cited. The NAT problems I refer to arise when NAT takes place at a device that is between the IPsec implementation and the Internet. For example, I am in a hotel room in London now and if I had IPsec on my laptop, it would have to deal with the NAT box that the hotel has deployed. Same problem arises in many cable modem nets, and for desktop IPsec implementations in corporate environments where NAT is performed at the gateway/firewall.

Steve
--============_-1210700706==_ma============-- From owner-ipsec@lists.tislabs.com Tue Sep 25 07:23:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PENID06144; Tue, 25 Sep 2001 07:23:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15349 Tue, 25 Sep 2001 09:31:50 -0400 (EDT) Message-ID: <00a801c145c7$cbf93580$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: "Stephen Kent" Cc: References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c1429d$97f81080$ae0510ac@roc.com><002501c144ad$97b902c0$ae0510ac@roc.com> <002101c1457e$62e73540$ae0510ac@roc.com> Subject: Re: Why can't ESP authenticate IP header? Date: Tue, 25 Sep 2001 19:11:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C145F5.E322D760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C145F5.E322D760 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header? ----- Original Message -----=20 From: Stephen Kent=20 To: lokesh=20 Cc: ipsec@lists.tislabs.com=20 Sent: Tuesday, September 25, 2001 6:13 PM Subject: Re: Why can't ESP authenticate IP header? At 10:25 AM +0530 9/25/01, lokesh wrote: As noted, ESP coverage of selected header fields would increase = complexity and reduce performance. It also would create even more = circumstances where NAT could interfere with IPsec use. Today, using ESP = in tunnel mode can be made to work with NAT, but if the outer S/D IP = addresses were covered, that capability (I hesitate to call it a = feature) would go away. Steve, As for as I know, in many implementations, NAT is done prior to = ipsec processing at the sending end, and Ipsec processing is done before = NAT at the receiving end. Are there situvations where NAT would interfere in ipsec = processing ? if so, kindly will you brief them? Assuming there will be situations where NAT will interfere with = IPsec processing, how AH in transport mode will work there? I get the feeling that you have not been reading this list for very = long.=20 Yes, a combined IPsec/NAT implementation in a security gateway avoids = the problems I cited. The NAT problems I refer to arise when NAT takes = place at a device that is between the IPsec implementation and the = Internet. For example, I am in a hotel room in London now and if I had = IPsec on my laptop, it would have to deal with the NAT box that the = hotel has deployed. Same problem arises in many cable modem nets, and = for desktop IPsec implementations in corporate environments where NAT is = performed at the gateway/firewall. Steve, yes , I have subscribed it very recently,=20 in such scenarios, as the one you mention above, I think AH in = transport mode should not be used right? Thanks -Lokesh ------=_NextPart_000_00A5_01C145F5.E322D760 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: Why can't ESP authenticate IP header?
 
----- Original Message -----
From:=20 Stephen Kent =
To: lokesh=20
Cc: ipsec@lists.tislabs.com
Sent: Tuesday, September 25, = 2001 6:13=20 PM
Subject: Re: Why can't ESP = authenticate=20 IP header?

At 10:25 AM +0530 9/25/01, lokesh wrote:
As noted, ESP coverage of selected header fields would=20 increase complexity and reduce performance. It also would create = even more=20 circumstances where NAT could interfere with IPsec use. Today, = using ESP=20 in tunnel mode can be made to work with NAT, but if the outer S/D = IP=20 addresses were covered, that capability (I hesitate to call it a = feature)=20 would go away.
 
Steve,
 
As for as I know, in  = many=20 implementations, NAT is done prior to ipsec processing at the = sending end,=20 and Ipsec processing is done before NAT at the receiving=20 end.
Are there situvations where = NAT would=20 interfere in ipsec processing ? if so, kindly will you brief=20 them?
 
Assuming there will be = situations=20 where NAT will interfere with IPsec processing, how AH in = transport mode=20 will work there?

I get the feeling that you have not been reading this list for = very long.=20

Yes, a combined IPsec/NAT implementation in a security gateway = avoids the=20 problems I cited. The NAT problems I refer to arise when NAT takes = place at a=20 device that is between the IPsec implementation and the Internet. For = example,=20 I am in a hotel room in London now and if I had IPsec on my laptop, it = would=20 have to deal with the NAT box that the hotel has deployed. Same = problem arises=20 in many cable modem nets, and for desktop IPsec implementations in = corporate=20 environments where NAT is performed at the gateway/firewall.

Steve,
 
yes , I have subscribed it very = recently,=20
 
in such scenarios, as the one you = mention above,=20 I think AH in transport mode should not be used right?
 
Thanks
-Lokesh
 
 
 
------=_NextPart_000_00A5_01C145F5.E322D760-- From owner-ipsec@lists.tislabs.com Tue Sep 25 08:31:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PFVUD09913; Tue, 25 Sep 2001 08:31:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15514 Tue, 25 Sep 2001 10:36:43 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "lokesh" Cc: "Stephen Kent" , ipsec@lists.tislabs.com Subject: Re: Why can't ESP authenticate IP header? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Sep 2001 10:44:48 -0400 Message-Id: <20010925144448.ACC4C7BFD@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <002101c1457e$62e73540$ae0510ac@roc.com>, "lokesh" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_001E_01C145AC.75278420 >Content-Type: text/plain; > charset="us-ascii" >Content-Transfer-Encoding: quoted-printable > >Re: Why can't ESP authenticate IP header?As noted, ESP coverage of = >selected header fields would increase complexity and reduce performance. = >It also would create even more circumstances where NAT could interfere = >with IPsec use. Today, using ESP in tunnel mode can be made to work with = >NAT, but if the outer S/D IP addresses were covered, that capability (I = >hesitate to call it a feature) would go away. > > Steve, > > As for as I know, in many implementations, NAT is done prior to ipsec = >processing at the sending end, and Ipsec processing is done before NAT = >at the receiving end.=20 > Are there situvations where NAT would interfere in ipsec processing ? = >if so, kindly will you brief them? > > Assuming there will be situations where NAT will interfere with IPsec = >processing, how AH in transport mode will work there?=20 Read draft-aboba-nat-ipsec-04.txt for a description of the interactions between IPsec and NAT. --Steve Bellovin, http://www.research.att.com/~smb http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Sep 25 13:17:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PKHLD04885; Tue, 25 Sep 2001 13:17:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16412 Tue, 25 Sep 2001 15:05:39 -0400 (EDT) Reply-To: From: "Josh Shaul" To: Subject: AES with SHA-2 Date: Tue, 25 Sep 2001 15:15:14 -0400 Message-ID: <005c01c145f6$680a9580$1e64a8c0@jshaul> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C145D4.E0F8F580" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C145D4.E0F8F580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi all… I wonder what the consensus is on using SHA-2 with AES for ESP. Are you all implementing such a transform? Do you plan to? Thanks! Josh Shaul ------=_NextPart_000_005D_01C145D4.E0F8F580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all…<= /p>

 <= /p>

        = ;    I wonder what the consensus is on using SHA-2 with AES for ESP. Are you = all implementing such a transform? Do you plan to? <= /p>

 <= /p>

Thanks!<= /p>

 <= /p>

Josh Shaul<= /p>

 

------=_NextPart_000_005D_01C145D4.E0F8F580-- From owner-ipsec@lists.tislabs.com Tue Sep 25 15:20:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PMKvD15239; Tue, 25 Sep 2001 15:20:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16653 Tue, 25 Sep 2001 17:13:47 -0400 (EDT) Date: Tue, 25 Sep 2001 14:21:06 -0700 (PDT) From: Jan Vilhuber To: Sridhar J cc: "Ipsec (E-mail)" , "Users (E-mail)" , tech-crpto@netbsd.org Subject: Re: cisco rsa key - openssl read In-Reply-To: <000c01c14346$cb737e00$2702060a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please contact me off the list, as this question is not appropriate for the list (either of them)... jan On Sat, 22 Sep 2001, Sridhar J wrote: > > > Hi , > I am sorry this may not be the appropriate mailing list to ask this > problem . > I was under the impression that cisco router which I have displays the > rsa public key in asn1 der form as decsribed in rfc 2459 . > > I need to extract mod and exponent from this key , so I copied the displayed > public > key into a file and gave input to openssl (0.9.5a) using the command > > openssl rsa -inform DER -in infile1.der -text -out outfile2.txt > which is failing to read the key.. > Is cisco router and displaying properly or openssl is not able to read > can anyone help me reqarding this issue , thanks in advance . > > re > sridhara .j > > www.futsoft.com > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Sep 26 01:02:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8Q82YD20723; Wed, 26 Sep 2001 01:02:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17648 Wed, 26 Sep 2001 02:34:48 -0400 (EDT) Message-ID: From: Raghunath Tilak To: "'ipsec@lists.tislabs.com'" Subject: Question on IPSec protocol Date: Wed, 26 Sep 2001 12:17:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14657.2784ACB0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C14657.2784ACB0 Content-Type: text/plain; charset="iso-8859-1" Hello All, I came across a paper by Bruce Schneier & Neals Ferguson. The title is "Cryptographic Evaluation of IPsec". The URL is http://www.counterpane.com/ipsec.html The paper suggests some improvements to IPSec protocol. Are those (suggested improvements) already considered in the present suite of RFCs? (RFC 2401-2412) Will those be considered in the future revisions of RFCs in case they are not? Please don't feel offended by the question. Consider it as a doubt from a newbie to IPSec. Regards, Raghu Tilak Amber Networks India Pvt Ltd ---------------------------------------------------------------------------- --------------------------- Excerpt from the URL ---------------------------------------------------------------------------- --------------------------- A Cryptographic Evaluation of IPsec N. Ferguson and B. Schneier ABSTRACT: We perform a cryptographic review of the IPsec protocol, as described in the November 1998 RFCs. Even though the protocol is a disappointment--our primary complaint is with its complexity--it is the best IP security protocol available at the moment. [full text - PDF (Acrobat)] [full text - Postscript] ---------------------------------------------------------------------------- --------------------------- ------_=_NextPart_001_01C14657.2784ACB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on IPSec protocol

Hello All,

I came across a paper by Bruce Schneier & Neals = Ferguson.

The title is "Cryptographic Evaluation of = IPsec".
The URL is http://www.counterpane.com/ipsec.html

The paper suggests some improvements to IPSec = protocol.

Are those (suggested improvements) already considered = in
the present suite of RFCs? (RFC 2401-2412)
Will those be considered in the future revisions of = RFCs in
case they are not?

Please don't feel offended by the question. Consider = it as a
doubt from a newbie to IPSec.

Regards,

Raghu Tilak
Amber Networks India Pvt Ltd

---------------------------------------------------------------= ----------------------------------------
Excerpt from the URL
---------------------------------------------------------------= ----------------------------------------

A Cryptographic Evaluation of IPsec
N. Ferguson and B. Schneier


ABSTRACT: We perform a cryptographic review of the = IPsec protocol, as described in the November 1998 RFCs. Even though the = protocol is a disappointment--our primary complaint is with its = complexity--it is the best IP security protocol available at the = moment.

[full text - PDF (Acrobat)] [full text - Postscript] =
---------------------------------------------------------------= ----------------------------------------

------_=_NextPart_001_01C14657.2784ACB0-- From owner-ipsec@lists.tislabs.com Wed Sep 26 01:30:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8Q8UHD23167; Wed, 26 Sep 2001 01:30:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17759 Wed, 26 Sep 2001 03:41:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <00a801c145c7$cbf93580$ae0510ac@roc.com> References: <73D3E97F639DD5119642000347055F0581620B@G9JNS.mgb01.telekom.de><005701c142 9d$97f81080$ae0510ac@roc.com><002501 c144ad$97b902c0$ae0510ac@roc.com> <002101c1457e$62e73540$ae0510ac@roc. com> <00a801c145c7$cbf93580$ae0510ac@roc.com> Date: Wed, 26 Sep 2001 03:49:51 -0400 To: "lokesh" From: Stephen Kent Subject: Re: Why can't ESP authenticate IP header? Cc: Content-Type: multipart/alternative; boundary="============_-1210631898==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1210631898==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:11 PM +0530 9/25/01, lokesh wrote: > > >----- Original Message ----- >From: Stephen Kent >To: lokesh >Cc: ipsec@lists.tislabs.com >Sent: Tuesday, September 25, 2001 6:13 PM >Subject: Re: Why can't ESP authenticate IP header? > >At 10:25 AM +0530 9/25/01, lokesh wrote: > >>As noted, ESP coverage of selected header fields would increase >>complexity and reduce performance. It also would create even more >>circumstances where NAT could interfere with IPsec use. Today, >>using ESP in tunnel mode can be made to work with NAT, but if the >>outer S/D IP addresses were covered, that capability (I hesitate to >>call it a feature) would go away. >> >> >> >>Steve, >> >> >> >>As for as I know, in many implementations, NAT is done prior to >>ipsec processing at the sending end, and Ipsec processing is done >>before NAT at the receiving end. >> >>Are there situvations where NAT would interfere in ipsec processing >>? if so, kindly will you brief them? >> >> >> >>Assuming there will be situations where NAT will interfere with >>IPsec processing, how AH in transport mode will work there? >> > >I get the feeling that you have not been reading this list for very long. > >Yes, a combined IPsec/NAT implementation in a security gateway >avoids the problems I cited. The NAT problems I refer to arise when >NAT takes place at a device that is between the IPsec implementation >and the Internet. For example, I am in a hotel room in London now >and if I had IPsec on my laptop, it would have to deal with the NAT >box that the hotel has deployed. Same problem arises in many cable >modem nets, and for desktop IPsec implementations in corporate >environments where NAT is performed at the gateway/firewall. > >Steve, > >yes , I have subscribed it very recently, > >in such scenarios, as the one you mention above, I think AH in >transport mode should not be used right? > >Thanks >-Lokesh AH in any mode will break in these contexts, as will ESP in transport mode, but ESP in tunnel mode is less problematic. Steve --============_-1210631898==_ma============ Content-Type: text/html; charset="us-ascii" Re: Why can't ESP authenticate IP header?
At 7:11 PM +0530 9/25/01, lokesh wrote:
 
----- Original Message -----
From: Stephen Kent
To: lokesh
Cc: ipsec@lists.tislabs.com
Sent: Tuesday, September 25, 2001 6:13 PM
Subject: Re: Why can't ESP authenticate IP header?

At 10:25 AM +0530 9/25/01, lokesh wrote:
As noted, ESP coverage of selected header fields would increase complexity and reduce performance. It also would create even more circumstances where NAT could interfere with IPsec use. Today, using ESP in tunnel mode can be made to work with NAT, but if the outer S/D IP addresses were covered, that capability (I hesitate to call it a feature) would go away.
 
Steve,
 
As for as I know, in  many implementations, NAT is done prior to ipsec processing at the sending end, and Ipsec processing is done before NAT at the receiving end.
Are there situvations where NAT would interfere in ipsec processing ? if so, kindly will you brief them?
 
Assuming there will be situations where NAT will interfere with IPsec processing, how AH in transport mode will work there?

I get the feeling that you have not been reading this list for very long.

Yes, a combined IPsec/NAT implementation in a security gateway avoids the problems I cited. The NAT problems I refer to arise when NAT takes place at a device that is between the IPsec implementation and the Internet. For example, I am in a hotel room in London now and if I had IPsec on my laptop, it would have to deal with the NAT box that the hotel has deployed. Same problem arises in many cable modem nets, and for desktop IPsec implementations in corporate environments where NAT is performed at the gateway/firewall.

Steve,
 
yes , I have subscribed it very recently,
 
in such scenarios, as the one you mention above, I think AH in transport mode should not be used right?
 
Thanks
-Lokesh

AH in any mode will break in these contexts, as will ESP in transport mode, but ESP in tunnel mode is less problematic.

Steve
--============_-1210631898==_ma============-- From owner-ipsec@lists.tislabs.com Wed Sep 26 07:39:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8QEdCD03135; Wed, 26 Sep 2001 07:39:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18202 Wed, 26 Sep 2001 09:20:31 -0400 (EDT) From: joern@dfintra.f-secure.com Message-Id: <5.1.0.14.0.20010925230916.01eb4c90@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Sep 2001 23:16:59 +0200 To: ipsec@lists.tislabs.com Subject: Re: AES with SHA-2 In-Reply-To: <005c01c145f6$680a9580$1e64a8c0@jshaul> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA16633 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:15 25.09.2001 -0400, you wrote: >Hi all& > > > > I wonder what the consensus is on using SHA-2 with AES for > ESP. Are you all implementing such a transform? Do you plan to? > > > >Thanks! > > > >Josh Shaul No, we're not. What's the point of using sha-2 in ESP anyway? We are using a truncated (96 bits) output of sha-1 or md5 today. Using sha-2-96 would be utterly pointless, because the only advantage of sha-2 over sha-1 is the longer output. Before you plan anything, you should wonder how many bits you want. More than 96 bit, apparently. But how much more? Then, wouldn't sha-1-128 or sha-1-160 be enough for you? I'm happy with 96 bits..... Jörn Sierwald From owner-ipsec@lists.tislabs.com Wed Sep 26 08:08:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8QF8fD05862; Wed, 26 Sep 2001 08:08:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18274 Wed, 26 Sep 2001 10:04:07 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Raghunath Tilak Cc: "'ipsec@lists.tislabs.com'" Subject: Re: Question on IPSec protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Sep 2001 10:12:15 -0400 Message-Id: <20010926141216.B99647B69@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Raghunath Tilak writes: >This message is in MIME format. Since your mail reader does not understand >this format, some or all of this message may not be legible. > >------_=_NextPart_001_01C14657.2784ACB0 >Content-Type: text/plain; > charset="iso-8859-1" > >Hello All, > >I came across a paper by Bruce Schneier & Neals Ferguson. > >The title is "Cryptographic Evaluation of IPsec". >The URL is http://www.counterpane.com/ipsec.html > >The paper suggests some improvements to IPSec protocol. > >Are those (suggested improvements) already considered in >the present suite of RFCs? (RFC 2401-2412) >Will those be considered in the future revisions of RFCs in >case they are not? > >Please don't feel offended by the question. Consider it as a >doubt from a newbie to IPSec. Check the archives -- it's been discussed a number of times. --Steve Bellovin, http://www.research.att.com/~smb http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Wed Sep 26 09:01:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8QG10D12077; Wed, 26 Sep 2001 09:01:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18352 Wed, 26 Sep 2001 10:37:57 -0400 (EDT) Date: Wed, 26 Sep 2001 10:15:24 -0400 (EDT) From: Matt Benjamin To: Jan Vilhuber cc: Sridhar J , "Ipsec (E-mail)" , "Users (E-mail)" , Subject: Re: [Users] Re: cisco rsa key - openssl read In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excuse me, Jan, Why is it that you consider this FreeSWAN/Cisco interoperability discussion "off topic" for the Freeswan list (Tislabs I can agree with)? Matt Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 pgr. 734-431-0118 On Tue, 25 Sep 2001, Jan Vilhuber wrote: > Please contact me off the list, as this question is not appropriate for the > list (either of them)... > > jan > > > On Sat, 22 Sep 2001, Sridhar J wrote: > > > > > > > Hi , > > I am sorry this may not be the appropriate mailing list to ask this > > problem . > > I was under the impression that cisco router which I have displays the > > rsa public key in asn1 der form as decsribed in rfc 2459 . > > > > I need to extract mod and exponent from this key , so I copied the displayed > > public > > key into a file and gave input to openssl (0.9.5a) using the command > > > > openssl rsa -inform DER -in infile1.der -text -out outfile2.txt > > which is failing to read the key.. > > Is cisco router and displaying properly or openssl is not able to read > > can anyone help me reqarding this issue , thanks in advance . > > > > re > > sridhara .j > > > > www.futsoft.com > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > _______________________________________________ > Users mailing list > Users@lists.freeswan.org > http://lists.freeswan.org/mailman/listinfo/users > From owner-ipsec@lists.tislabs.com Fri Sep 28 10:27:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SHRWD22919; Fri, 28 Sep 2001 10:27:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26686 Fri, 28 Sep 2001 11:50:08 -0400 (EDT) From: lz6@njit.edu To: ipsec@lists.tislabs.com Subject: SAD/SPD question Message-ID: <1001692703.3bb49e1f3a59e@mailhost.njit.edu> Date: Fri, 28 Sep 2001 11:58:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 38.246.253.2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I find there are some overlappings between SAD and SPD, so can we have one database instaed of two? If we cannot, what are the benefits to keep two kind of database in the system? Thanks Li From owner-ipsec@lists.tislabs.com Fri Sep 28 12:38:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SJcZD25724; Fri, 28 Sep 2001 12:38:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27244 Fri, 28 Sep 2001 14:35:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <1001692703.3bb49e1f3a59e@mailhost.njit.edu> References: <1001692703.3bb49e1f3a59e@mailhost.njit.edu> Date: Fri, 28 Sep 2001 14:43:10 -0400 To: lz6@njit.edu From: Stephen Kent Subject: Re: SAD/SPD question Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:58 AM -0400 9/28/01, lz6@njit.edu wrote: >Hi, > >I find there are some overlappings between SAD and SPD, so can we have one >database instaed of two? If we cannot, what are the benefits to keep two kind >of database in the system? > >Thanks > >Li The SPD is a (nominally static) DB describing the SAs that could potentially be created. The SAD represents the current set of active SAs. In general, the two databases cannot be combined, but if you wish to do so in a fashion that preserves the functionality defined in 2401, that's OK. Steve From owner-ipsec@lists.tislabs.com Fri Sep 28 14:21:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SLLTD28000; Fri, 28 Sep 2001 14:21:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27797 Fri, 28 Sep 2001 16:22:20 -0400 (EDT) Date: Fri, 28 Sep 2001 23:30:32 +0300 Message-Id: <200109282030.XAA06832@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <1001692703.3bb49e1f3a59e@mailhost.njit.edu> (lz6@njit.edu) Subject: Re: SAD/SPD question References: <1001692703.3bb49e1f3a59e@mailhost.njit.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I find there are some overlappings between SAD and SPD, so can we > have one database instaed of two? If we cannot, what are the > benefits to keep two kind of database in the system? I don't see any overlap. If there is, it may be an artifact of some implementations, which mix the policy and key negotiation. (like IKE does). From owner-ipsec@lists.tislabs.com Fri Sep 28 15:50:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SMoED29765; Fri, 28 Sep 2001 15:50:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28114 Fri, 28 Sep 2001 18:04:22 -0400 (EDT) Message-ID: <3BB4F5A4.8FFAA349@juniper.net> Date: Fri, 28 Sep 2001 15:11:48 -0700 From: Abraham Shacham X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Maxim V. Patlasov" CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: an ambiguity of draft-shacham-ippcp-rfc2393bis-07 References: <200109190525.CAA01193@solo.mtu-net.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Maxim V. Patlasov" wrote: > draft-shacham-ippcp-rfc2393bis-07 reads: > > Note: In the case of an encapsulated IP header (e.g., tunnel mode > > encapsulation in IPsec), the datagram payload is defined to start > > immediately after the outer IP header; accordingly, the inner IP > > header is considered part of the payload and is compressed. > > It implies that that datagram payload contains ESP header (SPI+RPL) > and so is subject of compression. In the other hand it should not be > compressed because: > > The compression of outbound IP datagrams MUST be done before any IP > > security processing, such as encryption and authentication, and > > How should the former quote be interpreted ? > The first paragraph of the spec (now rfc3173, the I-D announcement came out-of-the-blue) is part of the definition of the IP payload to compress. The spec earlier points to the fact that encrypted data does not compress -- the reason for introducing compression at layer 3 -- therefore compression must be done before encryption. Regards, avram > > Thanks in advance, > Maxim From owner-ipsec@lists.tislabs.com Fri Sep 28 18:46:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8T1krD02884; Fri, 28 Sep 2001 18:46:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28324 Fri, 28 Sep 2001 20:48:42 -0400 (EDT) Message-Id: <200109290048.IAA03334@csnet1> Date: Sat, 29 Sep 2001 8:57:43 +0800 From: dxh Reply-To: sleepy-cat@263.net To: "ipsec@lists.tislabs.com" Subject: Does an outbound packet need to be reroute? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since in tunnel mode, it get a new ip header which has a different destination ip address. Does the packet need to be reroute to a new interface (may be the same) and bypass this interface's ipsec processing? Best regard! Dong Xiaohu