From owner-ipsec@lists.tislabs.com Fri Mar 1 00:11:43 2002 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 g218Bhi19298; Fri, 1 Mar 2002 00:11:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07835 Fri, 1 Mar 2002 02:35:10 -0500 (EST) Date: Thu, 28 Feb 2002 23:45:54 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Tero Kivinen , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chinna, ESP and IKE ALGs, which direct packets based on SPI values and Cookies solve some of problems associated with IKE/IPSEC traffic going via NAT box. They have got their limitations. NAT Discovery/Traversal is one good effort which solves these problems, but with added complexity in IKE and IPSEC. Your point is well taken that NAT speicific changes don't belong in IKE. If NAT discovery and NAT traversal are seperated from IKE and IPSEC, it not only reduces the complexity, but also, other protocols can make use of it. You seem to be indicating that, NAT discovery and traversal work was done in NAT related groups. Can you point out standards/drafts in regards to this? I have seen similar (but not same) functionality in 'IP mobility Support' related standards. But, I am not sure whether you are referring to some other standard/draft documents. Thanks Srini On Thu, 28 Feb 2002, Chinna N.R. Pellacuru wrote: > On Thu, 28 Feb 2002, Tero Kivinen wrote: > > > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > > Depending on local policy, one of the following MUST be done: > > > a) If the protocol header after the ESP header is a TCP/UDP > > > header, zero the checksum field in the TCP/UDP header. > > > b) If the protocol header after the ESP header is a TCP/UDP > > > header, recompute the checksum field in the TCP/UDP header. > > > c) If the protocol header after the ESP header is a TCP/UDP > > > header and the peer's real source IP address has been received > > > according to [Kiv00], incrementally recompute the TCP/UDP checksum: > > > - subtract the IP source address in the received packet > > > from the checksum > > > - add the real IP source address received via IKE to the checksum > > > > > > - What "local policy" is being reffered to here? > > > > Implementations own local policy. If the implementation knows for sure > > that it's TCP/UDP stack does not care about checksums, it can simply > > zero them. If the IPsec + NAT-T is working under operating system > > TCP/UDP stack, and cannot affect the checksumming code of the stack, > > it needs to recalculate the checksum (either by incremental update or > > with full packet). > > "local policy" is only applicable to end system IPsec implementations. If > we are dealing with a security gateway IPsec implementation, then it won't > be easy to make any assumptions on what the hundreds of applications > expect which are running on thousands of hosts behind it. These machines > could be running different Operating Systems too. > > > > > > - If it is OK here to just "recompute the checksum field" why not do it > > > for all ESP decapsulation. > > > > Performance reasons. Also it is simply extra stuff if you know that > > the operating system stack is going to ignore it anyways. > > > > Calculating the checksum is a very cheap operation. > > > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > > > > I agree. Some people in the WG think that we should also allow NATs to > > live, thus we must cope with them. If you do not agree with the IPsec > > WG, then you should complain to WG in general. > > > > The IPsec WG charter has item: > > > > ---------------------------------------------------------------------- > > The IPSEC working group will restrict itself to the following > > short-term work items to improve the existing key management protocol > > (IKE) and IPSEC encapsulation protocols: > > > > 1. Changes to IKE to support NAT/Firewall traversal > > ... > > ---------------------------------------------------------------------- > > > > My only question is why should "NAT discovery" be included in a key > management protocol. Why can't it be done as a separate protocol, in and > of itself, so that as more generic protocols for "NAT discovery" evolve, > we can easily use those. "NAT discovery" is a generic problem that many > people are trying to solve. Why do we have to clutter the IKE protocol > with another vendor-id? Why should we try and come up with yet another way > of discovering NAT when there is already a lot of work done in the NAT > related working groups. > > > > > - Cookies are used to identify IKE SAs. Just because you have a bizzare > > > > Yes. Cookies identify IKE, and there is NOTHING anybody else can > > assume that the cookies are. For example the one of the son of the ike > > drafts changes the order of the cookies to fix one problem in IKE (i.e > > the cookie order will always be receiver, sender, not initiator, > > responder). Also the sender cookie can change. This means that all the > > NATs doing IKE cookie magic will be broken again... > > But, the UDP encapsulation scheme tries to use the cookie as a "NON-IKE > marker". If cookies only identify the IKE SA, and there is NOTHING anybody > else can assume, why is the UDP encapsulation scheme trying to use the > cookie as a differentiator of whether the IKE packet is a IKE packet or a > packet which has ESP encapsulated in UDP? You can use something else. > Possibly a flag in the IKE header? > > Even if you change the order of the cookies in son-of-ike, the cookies are > still being used for identifying an IKE SA. And, how often do we revise a > protocol like IKE? > > "IKE cookie magic" is actually being done by NAT boxes not because the NAT > boxes are broken, but because of some broken IPsec implementations! The > "IKE cookie magic" is being done by NAT boxes because some IKE > implementations cannot deal with a src port other than 500 on the IKE > packets! The NAT boxes are trying to workaround broken IPsec boxes. I > don't think it is fair to turn around and blame those NAT boxes in this > situation. > > So, for some reason, people felt that upgrading the NAT box by working > around a broken IPsec implementation is much easier than fixing and > upgrading the IPsec implementation. And, your "most important" design goal > is to not touch the NAT box, but only upgrade all IPsec boxes! > > This supports our assumption that the NAT boxes are the ones which are > upgraded all the time, even if it so happens that there are some broken > IPsec boxes, and NAT has to come up with a workaround for it. > > > > > > - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of > > > the world assumed that, and now that you are coming in later and breaking > > > that assumption, you should deal it somehow, and not expect the rest of > > > the world to just vanish. How convenient! > > > > Because of the broken NAT boxes we propably need to do special hack to > > switch ports on the fly inside phase 1 just to get those broken NAT > > boxes working. > > > > Those NAT boxes are not broken. They are just trying to help out with > broken IKE implementations. > > > > What design principles is your solution based on? > > > > Has to work with existing hardware. When this proposal was first made > > none of the NAT boxes did this kind of broken magic on the IKE > > packets, thus it worked fine with NAT boxes out there. Then we > > suddenly noticed that our fine proposal that worked everywhere has > > been broken by people doing some kind of magic that do work sometimes > > somewhere if the phase of the moon is right. > > > > Does "existing hardware" include all existing hardware? UDP doesn't seem > to be working with all existing hardware. TCP seems to be the better > choice in some situations. If your goal is to work with all existing > hardware, then you should consider flexibility in which protocol to use > for encapsulation. > > > > Why is not changing a NAT device the "most important" design > > > principle? > > > > I think second largist (or so) ISP in Finland would be too happy if I > > go there and say that I want to change their NAT boxes, so that I can > > run IPsec through it. > > Probably that is the reason they are only the second largest, and not the > largest. What would it take to upgrade a handful of NAT boxes wihtout a > blip, and that too for such an important protocol like IPsec. To stay > competitive ISPs have to upgrade and honor the requirements of its users. > If there is no solution, then it's fine, but when there is a solution, if > one ISP doesn't upgrade, users will find one that is more sensible. I > don't see why upgrading a NAT box is being portrayed as if it is something > like upgrading all the switches in a Frame Relay cloud at once. If you > look at how NAT works, NAT is probably the simplest of all the upgrades an > ISP has to deal with. > > > > > > NAT changes every day to accomidate new protocols. > > > > NAT might change, installed base does not change that often. What I > > would really like to see to get those broken NAT boxes to support > > basic IP properly before they start breaking other protocols. If the > > NAT vendors cannot even get the fragmentation/reassembly working I > > don't think we can assume they can get anything done properly. > > If basic stuff is broken, then we are hosed anyway. Why bother to even > encapsulate ESP in another protocol? > > > > > > Ever wonder why customers are buying those "IPsec pass-through" boxes like > > > crazy? > > > > Propably because they don't know anything about it and they do not > > know how it works? They think it might work, and next time when they > > start using it they will notice that it only works in some limited > > cases? > > > > Firstly, UDP encapsulation will also only work in some limited cases. > There are claims of supporting some more *corner* cases by having a > "built-in NAT" implementation, which is actually a whole NAT > implementation within IPsec. I don't think anyone will actually implement > a whole NAT implementation within the IPsec implementation just to cover > some corner cases. > > I know that Cisco has only recently implemented the basic "IPsec > pass-through" becuase of customers asking for it. This is deployed in the > field, and is working in production networks. These customers are not > consumers (not that consumers are not real customers), but real > enterprises who run business critical data over IPsec and use NAT. So, > saying that the "IPsec pass-through" doesn't work, is just trying to > mis-lead everyone here. > > > > Because they work and it is simple and elegant and because of it's > > > simplicity they are cheap. > > > > Considering how much IPsec is now used if we count out all the VPN > > stuff, I don't think you can say that they work because people buy > > them... I think most of the customers who buy them haven't run single > > IPsec session through the boxes. > > -- > > No, there are real enterprises running their business critical data over > "IPsec pass-through" solution. The pressure on Cisco was so high that we > had to come up with something in a very short time that will improve the > scalability and predictablity of the "IPsec pass-through" solution, by > doing the SPI matching. This solution is not something that we just made > up. We already have it working. > > > kivinen@ssh.fi > > SSH Communications Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > > chinna narasimha reddy pellacuru > s/w engineer > > > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Fri Mar 1 07:15:30 2002 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 g21FFTi26735; Fri, 1 Mar 2002 07:15:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08916 Fri, 1 Mar 2002 09:19:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020301062635.04678318@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Mar 2002 06:27:37 -0800 To: Michael Richardson From: Mark Baugher Subject: Re: new ISAKMP ping draft Cc: ipsec@lists.tislabs.com In-Reply-To: <200202282336.g1SNaB015585@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:36 PM 2/28/2002 -0500, Michael Richardson wrote: > > > >4.8 Informational Exchange > > > > The Informational Exchange is designed as a one-way transmittal of > > information that can be used for security association management. > > The intention is not one, way and is not for SA management. Basically, >I'd like to stay completely out of that place. I don't get it: If you're not managing SAs then what are you doing with ISAKMP? regards, Mark >2) why not use a notify? > > Well, using a notify means sending it in some kind of exchange, e.g. an >Informational Exchange. If not using Informational Exchanges, I see no reason >to use a notify. > >3) combine with the heartbeat/make-dead systems. > > These are used to detect a dead phase 1 SA. They are, AFAIK, encrypted > Notifies. > I do not want the ISAKMP echo request/reply to take any crypto resources >(in particular, no entropy!) and I do not want anyone to be confused into >thinking that these have anything to do with the things sent within a >phase 1 SA. > >4) It has been suggested that the cookies match the current IKE style rather > than any proposed replacement. > > I made up the cookie stuff. I didn't want the responder to waste a single >iota of entropy, but to do something easily noticable to the packet. I do not >really care about the cookies, and upon reflection, the current proposal >likely won't get through "IKE enabled" NAT boxes. > I'm open to anything. > >5) echo response > > I considered having the responder copy the source IP and port number into >the body of the reply. It could even stick it in as its cookie. That would >permit a request'or to diagnose that they are in fact behind a NAT. > >] 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 > >iQCVAwUBPH6+5IqHRg3pndX9AQHk2AP9GkqWleMmC1uSEddWWgC4hRNDwEKAgYL1 >KgpXD6SxPfe6VhtTaOCtEE90koIKYnNwJNiuRdg09fydhG7zwMsrAurOYU/SVK6G >Vx2kXOSMDgdsrP1zLI1iM95s7HKgzlar1n+w8mbQM4ninTqPTmq74VDYGZfU3stB >2ja52RmKAF0= >=gYj4 >-----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 1 07:51:40 2002 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 g21FpdG27577; Fri, 1 Mar 2002 07:51:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09038 Fri, 1 Mar 2002 10:15:10 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15487.36821.537419.263885@ryijy.hel.fi.ssh.com> Date: Fri, 1 Mar 2002 16:27:33 +0200 From: Tero Kivinen To: "Chinna N.R. Pellacuru" Cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: References: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 17 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna N.R. Pellacuru writes: > On Thu, 28 Feb 2002, Tero Kivinen wrote: > > > Depending on local policy, one of the following MUST be done: > > > a) If the protocol header after the ESP header is a TCP/UDP > > > header, zero the checksum field in the TCP/UDP header. > > > b) If the protocol header after the ESP header is a TCP/UDP > > > header, recompute the checksum field in the TCP/UDP header. > > > c) If the protocol header after the ESP header is a TCP/UDP > > > header and the peer's real source IP address has been received > > > according to [Kiv00], incrementally recompute the TCP/UDP checksum: > > > - subtract the IP source address in the received packet > > > from the checksum > > > - add the real IP source address received via IKE to the checksum > "local policy" is only applicable to end system IPsec implementations. If > we are dealing with a security gateway IPsec implementation, then it won't > be easy to make any assumptions on what the hundreds of applications > expect which are running on thousands of hosts behind it. These machines > could be running different Operating Systems too. If you are forwarding the packet to the network there is no other option that to update the checksum for TCP packets and either clear or update it for UDP. Then you can select either the b or c above. The case a is mostly for the end system implementations, it cannot be used for TCP for any other cases. > > Performance reasons. Also it is simply extra stuff if you know that > > the operating system stack is going to ignore it anyways. > Calculating the checksum is a very cheap operation. True, but if it is done after the decryption etc it must be done using the CPU (i.e the ethernet card etc cannot do it, the crypto hardware could do it, but I don't think they support this kind of operations (yet)). CPU is limited resource and might be too slow for this kind of operations. > My only question is why should "NAT discovery" be included in a key > management protocol. Why can't it be done as a separate protocol, in and > of itself, so that as more generic protocols for "NAT discovery" evolve, > we can easily use those. "NAT discovery" is a generic problem that many > people are trying to solve. Why do we have to clutter the IKE protocol > with another vendor-id? Why should we try and come up with yet another way > of discovering NAT when there is already a lot of work done in the NAT > related working groups. I don't know any such protocols (note, it must work without modifying the NAT, and preferrably it will also tell what is the exact translation so we can do the checksum fixing quickly). Can you give me some pointers? > But, the UDP encapsulation scheme tries to use the cookie as a "NON-IKE > marker". If cookies only identify the IKE SA, and there is NOTHING anybody > else can assume, why is the UDP encapsulation scheme trying to use the > cookie as a differentiator of whether the IKE packet is a IKE packet or a > packet which has ESP encapsulated in UDP? You can use something else. > Possibly a flag in the IKE header? If would have done it by putting the complete IKE header and special IKE payload number which contains the whole packet inside, but some other people considered 28 bytes of IKE header too much. > Even if you change the order of the cookies in son-of-ike, the cookies are > still being used for identifying an IKE SA. And, how often do we revise a > protocol like IKE? Yes we still use them to identify IKE SA, but all the existing NAT boxes need to be updated to support new format. I am sure NAT vendors will be more than happy to sell new versions of the boxes which support next version of IKE, but I don't think customers are going to update their boxes any time soon. This means that we again have broken NAT traversal for those who relied on the NAT box doing this magic. > "IKE cookie magic" is actually being done by NAT boxes not because the NAT > boxes are broken, but because of some broken IPsec implementations! The > "IKE cookie magic" is being done by NAT boxes because some IKE > implementations cannot deal with a src port other than 500 on the IKE > packets! The NAT boxes are trying to workaround broken IPsec boxes. I > don't think it is fair to turn around and blame those NAT boxes in this > situation. I agree that there is broken IPsec implementations there. I still would have fixed those broken implementations instead of making the patch for NAT boxes. > So, for some reason, people felt that upgrading the NAT box by working > around a broken IPsec implementation is much easier than fixing and > upgrading the IPsec implementation. And, your "most important" design goal > is to not touch the NAT box, but only upgrade all IPsec boxes! There are much fewer IPsec boxes in the world than there are NAT boxes. Also IPsec boxes / software is normally adminstrated by you, you can control them. On the other hand NAT boxes normally are not adminstrated by you, you cannot update hotel's NAT box at will. > Does "existing hardware" include all existing hardware? UDP doesn't seem > to be working with all existing hardware. TCP seems to be the better > choice in some situations. If your goal is to work with all existing > hardware, then you should consider flexibility in which protocol to use > for encapsulation. Running tcp over tcp has some quite bad characteristics (I know, we tried that in our first vpn systems, i.e running normal IP traffic over encrypted tcp/ip stream). I think most of the NAT boxes out there do support UDP. > Probably that is the reason they are only the second largest, and not the > largest. What would it take to upgrade a handful of NAT boxes wihtout a > blip, and that too for such an important protocol like IPsec. Money? They will propably add new NAT box and sell you IPsec enabled version of their IP-connectivity :-) They are the ISP you know, they can do anything they want... > If basic stuff is broken, then we are hosed anyway. Why bother to even > encapsulate ESP in another protocol? That was about the same comment I gave when I heard that NAT boxes does not support fragmentation... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 1 07:59:35 2002 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 g21FxYG27870; Fri, 1 Mar 2002 07:59:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09056 Fri, 1 Mar 2002 10:19:24 -0500 (EST) Message-Id: <200203011527.g21FRH125570@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: new ISAKMP ping draft In-reply-to: Your message of "Fri, 01 Mar 2002 06:27:37 PST." <4.3.2.7.2.20020301062635.04678318@mira-sjc5-6.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 01 Mar 2002 10:27:17 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mark" == Mark Baugher writes: Mark> I don't get it: If you're not managing SAs then what are you doing with Mark> ISAKMP? Did you read the draft? The purpose is to debug the network path used by ISAKMP before one gets lost in ISAKMP 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"); [ From owner-ipsec@lists.tislabs.com Fri Mar 1 08:05:36 2002 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 g21G5aG28082; Fri, 1 Mar 2002 08:05:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09037 Fri, 1 Mar 2002 10:15:09 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15487.35607.13211.15952@ryijy.hel.fi.ssh.com> Date: Fri, 1 Mar 2002 16:07:19 +0200 From: Tero Kivinen To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: References: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Thu, 28 Feb 2002, Tero Kivinen wrote: > > Implementations own local policy. If the implementation knows for sure > > that it's TCP/UDP stack does not care about checksums, it can simply > > zero them. > There is no such thing as a (standard conforming) TCP/UDP stack which does > not care about checksums. Checking checksums is mandatory; discarding Note, that we are talking about packets which are already verified using the MAC of the ESP payload. We are not talking about the random packets received from the network. Also for those packets we know that the UDP and TCP checksums are incorrect because we know that some NAT device between has changed the ip-addresses and it could not fix the checksums because the checksum was encrypted. For those cases I think it is ok for an implementation to mark the packet after decryption and MAC verification that it had correct tcp/udp checksum so that the operating system stack can then notice that ok, I should not do checksum checks for this packet, as something inside my system already claimed that it is ok. Another option is to recalculate the checksum either completely or by incremental method. This ignoring of the checksum is completely internal to the operating system stack, the incorrect checksum does cannot go out from the host (if the packet is forwarded then the checksum must be updated). > packets with bad checksums is mandatory. A UDP implementation may > optionally choose not to include a checksum with a packet it generates (by > setting the checksum field to zero), but it must still check checksums on > incoming packets and discard bad ones. A TCP implementation does not even > have that little bit of flexibility; the TCP checksum is not optional. > See RFC 1122. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 1 08:36:36 2002 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 g21GaaG00484; Fri, 1 Mar 2002 08:36:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09221 Fri, 1 Mar 2002 10:51:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15487.35607.13211.15952@ryijy.hel.fi.ssh.com> References: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> <15487.35607.13211.15952@ryijy.hel.fi.ssh.com> Date: Fri, 1 Mar 2002 10:55:48 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: NAT Traversal Cc: Henry Spencer , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:07 PM +0200 3/1/02, Tero Kivinen wrote: >Henry Spencer writes: >> On Thu, 28 Feb 2002, Tero Kivinen wrote: >> > Implementations own local policy. If the implementation knows for sure >> > that it's TCP/UDP stack does not care about checksums, it can simply >> > zero them. >> There is no such thing as a (standard conforming) TCP/UDP stack which does >> not care about checksums. Checking checksums is mandatory; discarding > >Note, that we are talking about packets which are already verified >using the MAC of the ESP payload. We are not talking about the random >packets received from the network. Also for those packets we know that >the UDP and TCP checksums are incorrect because we know that some NAT >device between has changed the ip-addresses and it could not fix the >checksums because the checksum was encrypted. > >For those cases I think it is ok for an implementation to mark the >packet after decryption and MAC verification that it had correct >tcp/udp checksum so that the operating system stack can then notice >that ok, I should not do checksum checks for this packet, as something >inside my system already claimed that it is ok. We would need some standard means of signalling this across a network if the IPsec implementation is in an SG, vs. in the same host. That strikes me as problematic. Steve From owner-ipsec@lists.tislabs.com Fri Mar 1 09:40:29 2002 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 g21HeSG03706; Fri, 1 Mar 2002 09:40:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09526 Fri, 1 Mar 2002 11:53:26 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A9C0D59@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec mailling list Subject: Towards closure on NAT traversal. Date: Fri, 1 Mar 2002 09:05:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C143.52B04D60" 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_000_01C1C143.52B04D60 Content-Type: text/plain; charset="iso-8859-1" People appear to be so caught up in whether we should be supporting NAT that the issue of how to support NAT is forgotten about. A good analogy here IMHO is email. In the email world all sorts of horrible kludges have been deemed necessary because most email servers are hopelessly broken. They arbirarily change character sets to no good purpose (esp. lossy ASCII to ASCII translations), they strip out bit 7 for no reason, they insert CRs at random points to support broken mail clients from the 1950s. And as for mailing lists, the protocols are hopelessly broken. But if you are in a mail group you are expected to work with the existing legacy infrastructure. I find the idea that the NAT infrastructure that is out there is going to be changed to be hopelessly naive. The problem is only going to get worse the longer the IPSEC group refuses to admit that it is a major problem. We already have a major problem with vendors introducing proprietary work arrounds. The only infrastructure you can change to make IPSEC work is IPSEC. I really don't care how we got to here. I really don't care what the Internet architecture was. I have no interest in normative architectural values, I care about the infrastructure as it exists. There are OSI working groups for those who care about architectural perfection. Otherwise, just treat NAT boxes as an adversary that is attempting a DoS service on your protocol. You protocol does not pass acceptance testing unless it works (i.e. packets get through) in the presence of a NAT attack. Reading through the NAT 'requirements' draft the issues appear to divide into two sets: 1) Those that affect only AH mode 2) Those that are due to the design of IKE The solution to 1 would appear to be to simply admit that AH mode is not going to be compatible with NAT. The solution to 2 does not appear likely to be a minor tweak to IKE, not least because there is now the problem of dealing with infrastructure that is attempting to anticipate IKE behavior. At the very least we need a version rev here. Since the majority of the problems appear to be due to the key exchange it would appear to be best to concentrate on developing a NAT compatible key exchange, i.e. ensuring that IKEv2/JFK or whatever hybrid emerges is NAT friendly. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C1C143.52B04D60 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C143.52B04D60-- From owner-ipsec@lists.tislabs.com Fri Mar 1 10:08:06 2002 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 g21I85G04491; Fri, 1 Mar 2002 10:08:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09642 Fri, 1 Mar 2002 12:29:13 -0500 (EST) Message-ID: <3C7FBD0F.7060303@isi.edu> Date: Fri, 01 Mar 2002 09:40:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ipsec mailling list Subject: NAT support and laws for the lawless References: <2F3EC696EAEED311BB2D009027C3F4F40A9C0D59@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > People appear to be so caught up in whether we should be supporting NAT that > the issue of how to support NAT is forgotten about. Agreed. However, at some point we're writing laws for the lawless. NATs exist only by breaking what few real standards we've had in the Internet. Writing standards for the rest of us to traverse a moving, lawless target is not necessarily productive, IMO. email is a specious analogy, because many of the legacy systems were implemented before, not in defiance of, Internet specs. That said, it still can be useful to _try_ to proceed; we can certainly continue this thread either off-line or this separate subject. Joe From owner-ipsec@lists.tislabs.com Fri Mar 1 11:53:09 2002 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 g21Jr9G08044; Fri, 1 Mar 2002 11:53:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09951 Fri, 1 Mar 2002 14:03:37 -0500 (EST) Date: Fri, 1 Mar 2002 11:14:26 -0800 (PST) From: Srinivasa Addepalli To: "Hallam-Baker, Phillip" cc: ipsec mailling list Subject: Re: Towards closure on NAT traversal. In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40A9C0D59@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AH can't be passed through NAT. ESP works, but some intelligence is needed in the NAT/firewall boxes. If NAT friendly IPSEC/IKE is required (which solves many problems), then both IKE and ESP have to be fixed or encapsulated within UDP packet. NAT traversal, outside IPSEC/IKE seems to be a good solution to me. This does not require changes to already deployed IPSEC and NAT solutions. L2TP is one such solution. This can encapsulate packets in UDP which is understood by NAT. But, it adds lot of baggage to the packets and since NAT discovery is not part of L2TP, it encapsulates all packets. Other solution is to come out with some standard which is lightweight and does NAT discovery and encapsulates packets of required services (based on local configuration and NAT discovery results). Thanks Srini On Fri, 1 Mar 2002, Hallam-Baker, Phillip wrote: > People appear to be so caught up in whether we should be supporting NAT that > the issue of how to support NAT is forgotten about. > > A good analogy here IMHO is email. In the email world all sorts of horrible > kludges have been deemed necessary because most email servers are hopelessly > broken. They arbirarily change character sets to no good purpose (esp. lossy > ASCII to ASCII translations), they strip out bit 7 for no reason, they > insert CRs at random points to support broken mail clients from the 1950s. > And as for mailing lists, the protocols are hopelessly broken. > > But if you are in a mail group you are expected to work with the existing > legacy infrastructure. > > I find the idea that the NAT infrastructure that is out there is going to be > changed to be hopelessly naive. The problem is only going to get worse the > longer the IPSEC group refuses to admit that it is a major problem. We > already have a major problem with vendors introducing proprietary work > arrounds. > > The only infrastructure you can change to make IPSEC work is IPSEC. > > I really don't care how we got to here. I really don't care what the > Internet architecture was. I have no interest in normative architectural > values, I care about the infrastructure as it exists. There are OSI working > groups for those who care about architectural perfection. Otherwise, just > treat NAT boxes as an adversary that is attempting a DoS service on your > protocol. You protocol does not pass acceptance testing unless it works > (i.e. packets get through) in the presence of a NAT attack. > > > Reading through the NAT 'requirements' draft the issues appear to divide > into two sets: > > 1) Those that affect only AH mode > 2) Those that are due to the design of IKE > > The solution to 1 would appear to be to simply admit that AH mode is not > going to be compatible with NAT. > > The solution to 2 does not appear likely to be a minor tweak to IKE, not > least because there is now the problem of dealing with infrastructure that > is attempting to anticipate IKE behavior. > > > At the very least we need a version rev here. Since the majority of the > problems appear to be due to the key exchange it would appear to be best to > concentrate on developing a NAT compatible key exchange, i.e. ensuring that > IKEv2/JFK or whatever hybrid emerges is NAT friendly. > > > Phill > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Fri Mar 1 11:55:30 2002 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 g21JtUG08117; Fri, 1 Mar 2002 11:55:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09968 Fri, 1 Mar 2002 14:17:51 -0500 (EST) Message-ID: <3C7FD690.7020300@isi.edu> Date: Fri, 01 Mar 2002 11:29:20 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020224 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: ipsec@lists.tislabs.com, Joe Touch Subject: ID update: draft-touch-ipsec-vpn-03.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020904070405040708030003" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020904070405040708030003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we have just submitted an update to draft-touch-ipsec-vpn ("Use of IPsec Transport Mode for Virtual Networks") to the ID editor. Until it becomes available in the repository, a copy is located at: http://www.isi.edu/larse/papers/draft-touch-ipsec-vpn-03.txt The major change in this update is an extended section 3.2 on existing approaches to dynamic routing for IPsec tunnel mode overlays. (Editorial changes have been made to other sections). Please send comments to the list. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms020904070405040708030003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMwMTE5MjkyMFowIwYJKoZIhvcNAQkEMRYEFG3Z72/akxRaKSzmWWDvPCFPZTm5MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAlQlgjY0NuC0r6OE/rV8r/UI/7e1J3MJuGG4txnV6lJV3uhgn09lIQBzzaIW9oPy8i Sntp3UCSrHCTPY4UY+WyUBOv8EizfePZq0wWT33u9ZhtEnSFmQhi7fq7FcsiZJkfATZLl+pU SNBqIgJjdwKDs3GyvbIJ9AsYHlmM+Q7higAAAAAAAA== --------------ms020904070405040708030003-- From owner-ipsec@lists.tislabs.com Fri Mar 1 12:37:33 2002 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 g21KbXG09546; Fri, 1 Mar 2002 12:37:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10176 Fri, 1 Mar 2002 14:54:40 -0500 (EST) Date: Fri, 1 Mar 2002 12:05:30 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Tero Kivinen cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <15487.36821.537419.263885@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 1 Mar 2002, Tero Kivinen wrote: > Chinna N.R. Pellacuru writes: > > On Thu, 28 Feb 2002, Tero Kivinen wrote: > > > Performance reasons. Also it is simply extra stuff if you know that > > > the operating system stack is going to ignore it anyways. > > Calculating the checksum is a very cheap operation. > > True, but if it is done after the decryption etc it must be done using > the CPU (i.e the ethernet card etc cannot do it, the crypto hardware > could do it, but I don't think they support this kind of operations > (yet)). CPU is limited resource and might be too slow for this kind of > operations. Consider adding 24 bytes of encapsulation on each packet, and decapsulating it and sending keepalives on the IKE SA for IKE and each IPsec SA if each of them are using different source ports. Compared to all this, recomputing the checksum is probably .01% of the cost. Encapsulation, decapsulation and sending keepalives isn't done in hardware too. > > > My only question is why should "NAT discovery" be included in a key > > management protocol. Why can't it be done as a separate protocol, in and > > of itself, so that as more generic protocols for "NAT discovery" evolve, > > we can easily use those. "NAT discovery" is a generic problem that many > > people are trying to solve. Why do we have to clutter the IKE protocol > > with another vendor-id? Why should we try and come up with yet another way > > of discovering NAT when there is already a lot of work done in the NAT > > related working groups. > > I don't know any such protocols (note, it must work without modifying > the NAT, and preferrably it will also tell what is the exact > translation so we can do the checksum fixing quickly). Can you give me > some pointers? > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt Abstract Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the nat. STUN works with nearly all existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. The STUN protocol is very simple, being almost identical to echo. Is that close enough? It's almost looks like they wrote the draft just for us! http://www.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt Seems to be asking more long term questions and seeking a longer term solution to the problem of middleboxes interfearing with network applications and protocols. > > But, the UDP encapsulation scheme tries to use the cookie as a "NON-IKE > > marker". If cookies only identify the IKE SA, and there is NOTHING anybody > > else can assume, why is the UDP encapsulation scheme trying to use the > > cookie as a differentiator of whether the IKE packet is a IKE packet or a > > packet which has ESP encapsulated in UDP? You can use something else. > > Possibly a flag in the IKE header? > > If would have done it by putting the complete IKE header and special > IKE payload number which contains the whole packet inside, but some > other people considered 28 bytes of IKE header too much. 24 Vs 28. How much is too much? 24 is OK but 28 is too much? 24 bytes of encapsulation on every data packet is huge! And, this is on top of what ESP adds. > > > Even if you change the order of the cookies in son-of-ike, the cookies are > > still being used for identifying an IKE SA. And, how often do we revise a > > protocol like IKE? > > Yes we still use them to identify IKE SA, ------------------------------------------------------------------------ No, you are NOT using cookies to identify the IKE SA. You are using them as a "NON-IKE marker". ----------------------------------------------------------------------- but all the existing NAT > boxes need to be updated to support new format. I am sure NAT vendors > will be more than happy to sell new versions of the boxes which > support next version of IKE, but I don't think customers are going to > update their boxes any time soon. This means that we again have broken > NAT traversal for those who relied on the NAT box doing this magic. Firstly, the son-of-ike isn't finilized yet, and generally the time line for updating IKE seems to be more like once every 5-10 years. We don't update IKE every year. > > > "IKE cookie magic" is actually being done by NAT boxes not because the NAT > > boxes are broken, but because of some broken IPsec implementations! The > > "IKE cookie magic" is being done by NAT boxes because some IKE > > implementations cannot deal with a src port other than 500 on the IKE > > packets! The NAT boxes are trying to workaround broken IPsec boxes. I > > don't think it is fair to turn around and blame those NAT boxes in this > > situation. > > I agree that there is broken IPsec implementations there. I still > would have fixed those broken implementations instead of making the > patch for NAT boxes. > Wonder why those people went and updated their NAT boxes instead of fixing their broken IPsec boxes. Is it easier to update a NAT box then to update a broken IPsec box? > > So, for some reason, people felt that upgrading the NAT box by working > > around a broken IPsec implementation is much easier than fixing and > > upgrading the IPsec implementation. And, your "most important" design goal > > is to not touch the NAT box, but only upgrade all IPsec boxes! > > There are much fewer IPsec boxes in the world than there are NAT > boxes. Also IPsec boxes / software is normally adminstrated by you, > you can control them. On the other hand NAT boxes normally are not > adminstrated by you, you cannot update hotel's NAT box at will. > This seems to be the main theme in your design principles. IPsec boxes are administered by the user, but NAT boxes are administered by the hotels and conferences. You seem to be heavily over engineered towards the "road-warrior" scenario. "road-warrior" is just one scenario in which IPsec is used, there are many other scenarios where someone has more control over where the data is going, and how it is being routed. > > Does "existing hardware" include all existing hardware? UDP doesn't seem > > to be working with all existing hardware. TCP seems to be the better > > choice in some situations. If your goal is to work with all existing > > hardware, then you should consider flexibility in which protocol to use > > for encapsulation. > > Running tcp over tcp has some quite bad characteristics (I know, we > tried that in our first vpn systems, i.e running normal IP traffic > over encrypted tcp/ip stream). I think most of the NAT boxes out there > do support UDP. So, your goal is to work with "most" NAT boxes, and NOT "all" NAT boxes. Just confirming that, I think there were some claims made that you need to work with "all" NAT boxes. > > > Probably that is the reason they are only the second largest, and not the > > largest. What would it take to upgrade a handful of NAT boxes wihtout a > > blip, and that too for such an important protocol like IPsec. > > Money? They will propably add new NAT box and sell you IPsec enabled > version of their IP-connectivity :-) They are the ISP you know, they > can do anything they want... > Hey, if they want to follow the money, you should advice them to start talking about "VALUE-ADD". You should advice them to not focus only on cyber cowboys who don't care whether their traffic is being routed over long-haul DWDM or barbed wire. They should also focus on businesses that want to run misson critical data over their networks. If you talk to such businesses they have very detailed requirements. Their requirements are down to the level of what door stop you use in your office, if you want to provide service/equipement to them. That is where the $$$$$$$ is, in "VALUE-ADD". How much does a "business" DSL cost, and how much does a "consumer" DSL cost? A road-warrior who doesn't care what kind of NAT box the ISP is running isn't going to pay big $. It's the business customers and corporations who specify every detail of how they want their traffic to be routed, that pay the big $$$$$$$. ---------------------------------------------------------------------- If an ISP can say, you can run what ever IPsec implementation you want, and our NAT boxes can handle and translate the traffic, that is what a serious customer will choose. Not an ISP who says, you have to UDP encapsulate your ESP traffic (24 bytes of overhead) because we don't know what our NAT boxes will do to the IPsec traffic. I think we are coming from totally different angles, and hence the totally different approaches. ---------------------------------------------------------------------- chinna > > If basic stuff is broken, then we are hosed anyway. Why bother to even > > encapsulate ESP in another protocol? > > That was about the same comment I gave when I heard that NAT boxes > does not support fragmentation... > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Mar 1 14:25:49 2002 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 g21MPmG13104; Fri, 1 Mar 2002 14:25:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10601 Fri, 1 Mar 2002 16:46:48 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A9C0E06@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Joe Touch , "Hallam-Baker, Phillip" Cc: ipsec mailling list Subject: RE: NAT support and laws for the lawless Date: Fri, 1 Mar 2002 13:59:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C16C.4E9634A0" 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_000_01C1C16C.4E9634A0 Content-Type: text/plain; charset="iso-8859-1" > Hallam-Baker, Phillip wrote: > > People appear to be so caught up in whether we should be > supporting NAT that > > the issue of how to support NAT is forgotten about. > > Agreed. However, at some point we're writing laws for the > lawless. NATs > exist only by breaking what few real standards we've had in the > Internet. Writing standards for the rest of us to traverse a moving, > lawless target is not necessarily productive, IMO. Most of the NAT vendors are engaged in IETF and have shown wilingness to comply with IETF standards, provided they allow them to get their job done. NAT has an important security role. We deploy it because our customers want to conceal their IP addresses against traffic analysis. Given that in the original Internet design IP was just the protocol run on the 'network of networks' I don't think that the claims that NAT is foreign to the Internet is valid. NAT appears to me to be part and parcel of the original concept. > email is a specious analogy, because many of the legacy systems were > implemented before, not in defiance of, Internet specs. Many of the problems with email are caused by compliance with IETF specs that were based on a broken model. The idea that servers should perform character set translation was broken, as was the idea that servers should do line wrapping for the client. But those servers are out there. When we designed HTTP all sorts of people were telling us that the protocol should assume that proxies mangle headers in the same way that mail agents do. Some well known IETF folks were screaming and stamping their feet, claiming that we should transport all images using BASE64 encoding, in case someone was using a connection that was not 8 bit clean. But as I said, it does not matter how we got into the swamp or whose fault it is. We are now in the swampt and we cannot get out of it using the mathematicians technique 'assume that we are on dry land'. Phill ------_=_NextPart_000_01C1C16C.4E9634A0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C16C.4E9634A0-- From owner-ipsec@lists.tislabs.com Fri Mar 1 15:16:55 2002 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 g21NGsG14463; Fri, 1 Mar 2002 15:16:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10761 Fri, 1 Mar 2002 17:44:41 -0500 (EST) From: "Tony Hain" To: "Markus Stenberg" , Subject: RE: NAT Traversal Date: Fri, 1 Mar 2002 14:56:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: <878z9dpxc1.fsf@ssh.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markus Stenberg wrote: > If 'change all network devices' was applicable solution, I'd > say we'd be > running IPv6 and not worrying about the legacy issues (such > as NAT) at all. Fortunately IPv6 does not require 'change all network devices' as its deployment model. It will work fine by treating the existing IPv4 Internet as a layer-2 multi-access media (which happens to have a well recognized 20 byte frame header) like IPv4 does with Frame Relay. Refer to draft-ietf-ngtrans-teredo-05.txt as a way to push the NAT traversal problem out of your space, so you can focus on simply making end-to-end IPsec work well. There is no reason to waste the time of this WG on an experiment that escaped from the lab and went very wrong... Tony From owner-ipsec@lists.tislabs.com Fri Mar 1 16:21:29 2002 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 g220LTG15769; Fri, 1 Mar 2002 16:21:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11004 Fri, 1 Mar 2002 18:44:20 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , "Joe Touch" Cc: "ipsec mailling list" Subject: RE: NAT support and laws for the lawless Date: Fri, 1 Mar 2002 15:55:48 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F40A9C0E06@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > NAT has an important security role. We deploy it because our > customers want > to conceal their IP addresses against traffic analysis. This is just bogus crap they have been sold. It is easier to perform traffic analysis on a NAT address that doesn't move than to figure out if a particular address cooresponds to a node that has changed subnets. NAT is not a security tool, get over it. If they really want to avoid traffic analysis have them use RFC3041 addresses with ESP. > > Given that in the original Internet design IP was just the > protocol run on > the 'network of networks' I don't think that the claims that > NAT is foreign > to the Internet is valid. NAT appears to me to be part and > parcel of the > original concept. > The original concept was based on a single global address space with multiple administrative partitions, not the brokenness of multiple overlapping address spaces. > > > email is a specious analogy, because many of the legacy > systems were > > implemented before, not in defiance of, Internet specs. > > Many of the problems with email are caused by compliance with > IETF specs > that were based on a broken model. The idea that servers > should perform > character set translation was broken, as was the idea that > servers should do > line wrapping for the client. But those servers are out there. > > When we designed HTTP all sorts of people were telling us > that the protocol > should assume that proxies mangle headers in the same way > that mail agents > do. Some well known IETF folks were screaming and stamping their feet, > claiming that we should transport all images using BASE64 > encoding, in case > someone was using a connection that was not 8 bit clean. > > But as I said, it does not matter how we got into the swamp > or whose fault > it is. We are now in the swampt and we cannot get out of it using the > mathematicians technique 'assume that we are on dry land'. > In this case you can. Assume you have an IPv6 network between the endpoints, and let the stack work out the layers of framing necessary to make that true. Tony From owner-ipsec@lists.tislabs.com Fri Mar 1 16:21:30 2002 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 g220LUG15775; Fri, 1 Mar 2002 16:21:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10973 Fri, 1 Mar 2002 18:37:21 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C17B.A35D6670" Subject: IKE failed to find valid machine certificate Date: Fri, 1 Mar 2002 18:48:50 -0500 Message-ID: Thread-Topic: IKE failed to find valid machine certificate Thread-Index: AcHBe6L1XucTkYnRRTCcO4tN7JP5aA== From: "Bob Kupperstein" To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1C17B.A35D6670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I get this event from my w2k ipsec client during IKE negotiation. My root certificate was generated by openssl on Linux and installed in the w2k trusted authority store. The client certificate request was generated on the client (XEnroll.createPKCS10), signed by the CA on the Linux server and installed in the LOCAL_MACHINE/personal store on the client (XEnroll.acceptPKCS7). =20 During the IKE negotiations, the w2k client gives event #547 (IKE failed to find valid machine certificate). =20 I tried switching to using a w2k-generated CA and client cert, and ipsec was able to find the cert okay. =20 Any clues as to what is wrong or how to get more information? =20 Are there any requirements about the DN of the client cert? =20 Thanks. =20 ------_=_NextPart_001_01C1C17B.A35D6670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I get this event from my w2k ipsec client during IKE negotiation.  My root certificate was = generated by openssl on Linux and installed in the w2k trusted authority store.  The client certificate request = was generated on the client (XEnroll.createPKCS10), signed by the CA on the = Linux server and installed in the LOCAL_MACHINE/personal store on the client (XEnroll.acceptPKCS7).

 

During the IKE negotiations, the w2k client gives event #547 (IKE failed to = find valid machine certificate).

 

I tried switching to using a w2k-generated CA and client cert, and ipsec = was able to find the cert okay.

 

Any clues as to what is wrong or how to get more = information?

 

Are there any requirements about the DN of the client = cert?

 

Thanks.

 

------_=_NextPart_001_01C1C17B.A35D6670-- From owner-ipsec@lists.tislabs.com Fri Mar 1 17:34:30 2002 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 g221YTG17176; Fri, 1 Mar 2002 17:34:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11219 Fri, 1 Mar 2002 19:56:18 -0500 (EST) Date: Fri, 1 Mar 2002 20:06:59 -0500 (EST) From: Henry Spencer To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: <15487.35607.13211.15952@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 1 Mar 2002, Tero Kivinen wrote: > > There is no such thing as a (standard conforming) TCP/UDP stack which does > > not care about checksums... > > Note, that we are talking about packets which are already verified > using the MAC of the ESP payload. That verifies that they have not been damaged between the time they were encrypted and the time they were decrypted. That is *NOT* a substitute for the end-to-end check provided by the checksums. The encryption and decryption points are not necessarily the ends. (Bad enough that you have to somehow indicate to the final destination that it shouldn't bother with the checksum... but how do you catch damage done while the packet was in transit from the original sender to the encryption point?) It is very, very, very important that the checksums are END TO END checks, computed by the original sender and checked by the final destination. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Mar 2 01:06:07 2002 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 g22966G14291; Sat, 2 Mar 2002 01:06:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12165 Sat, 2 Mar 2002 03:11:13 -0500 (EST) From: "Henrik Levkowetz" To: "Chinna N.R. Pellacuru" , "ipsec mailling list" Subject: RE: NAT Traversal Date: Sat, 2 Mar 2002 09:22:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, February 28, 2002 Chinna wrote: ...... > > I would also like to extend the request to everyone (the veterans who can > help us technically and also guide us through the IETF process, and > frankly THE MORE THE MERRIER). Please join us if you want to help us. If > you are skeptical of us due to the flame exchange, honestly, that's not > our true nature. Please send me an email. > Well, I'm taking you up on this; then we'll see if I end up hit by a barrage of pies, eggs, tomatoes and whatnot from every direction... I've followed the discussions with respect to NAT traversal on the ipsec mailing list during the last half year or so, while I've been working on the current draft on NAT traversal for Mobile IP, and also implementing NAT traversal for Mobile IP. I also had the IPsec drafts on NAT traversal as part of the input to that work. It seems to me, viewing this discussion somewhat from the outside, that in the matter of NAT traversal for IPsec you have as a group become the victims of your own success. Let me explain what I mean; it is leading somewhere: One goal in IPsec work would naturally be to have the protocols concerned be as opaque and resistant as possible to both traffic and content analysis. One goal for NATs is to leverage extra information (in the form of port addresses preferably) in order to make up for a scarcity of ip-addresses. So the more you succeed in making the communication opaque, the less there is for NATs to work with. The (in this respect) straightforward solution to accomplish NAT traversal _is_ then to give NATs their favourite stuff to work with: Port numbers. All ALGs (Application Layer Gateways) which are added to NATs are there to take care of the protocols which do NOT give the NATs port numbers to work with. They sometimes work, and sometimes work well. The solution subdivides into (at least) two parts: Discovering if you are behind a NAT, and doing something about it if you are. Chinna had a reference to an excellent draft which answers the first part in a generic way: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt The answer to the second part will have to consider the particular requirements of the protocols which you want to get trough a NAT, but if you would accept input from someone who's not of the IPsec community, I'd be willing to pitch in. I don't believe the problem is too intractable. Best regards, Henrik From owner-ipsec@lists.tislabs.com Sat Mar 2 12:33:35 2002 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 g22KXYG27320; Sat, 2 Mar 2002 12:33:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14152 Sat, 2 Mar 2002 14:32:10 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Sat, 2 Mar 2002 11:43:33 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Updated successor-to-IKE info Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. I have updated to contain links to the IKEv2 rationale document and a link to the new version of the JFK document (while we are waiting for it to be published in the Internet Drafts directory). --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Mar 2 12:58:37 2002 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 g22KwaG27820; Sat, 2 Mar 2002 12:58:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14321 Sat, 2 Mar 2002 15:20:54 -0500 (EST) From: "Greg Bailey" To: Cc: "ark-gvb-x" Subject: RE: Towards closure on NAT traversal. Date: Sat, 2 Mar 2002 12:32:06 -0800 Message-ID: MIME-Version: 1.0 charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yet there are some things that seem to me logically impossible in the presence of a NAT. Consider an ESP encrypted, or even just authenticated, FTP control channel. In order for the NAT to function "transparently" it must assemble, parse, and alter the TCP stream when necessary (PORT command). How can this possibly work using straight IP with IPSec unless the NAT cracks the keys et cetera? Not to mention that a NAT box with such capabilities would be an even more powerful assault weapon than is a plain old NAT box... I would submit FTP as a proof of existence of insoluble problems in *transparently* traversing a NAT with IPSec. Even adding Security Gateway code to a NAT, which in many respects would seem the best form of "IPSec pass-through", would still leave the problems caused by uncoordinated use of private address space on the other side of the NAT in non VPN environments. How long a list of exceptions can any "solution" to this charter item tolerate and still deserve to be called a solution? Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Srinivasa Addepalli > Sent: Fri 01 Mar 02 11:14 > To: Hallam-Baker, Phillip > Cc: ipsec mailling list > Subject: Re: Towards closure on NAT traversal. > > > > AH can't be passed through NAT. ESP works, but some intelligence > is needed in the NAT/firewall boxes. If NAT friendly IPSEC/IKE is > required (which solves many problems), then both IKE and ESP have to be > fixed or encapsulated within UDP packet. > > NAT traversal, outside IPSEC/IKE seems to be a good solution to me. > This does not require changes to already deployed IPSEC and NAT solutions. > L2TP is one such solution. This can encapsulate packets in UDP which > is understood by NAT. But, it adds lot of baggage to the packets and > since NAT discovery is not part of L2TP, it encapsulates all packets. > Other solution is to come out with some standard which is lightweight > and does NAT discovery and encapsulates packets of required services > (based on local configuration and NAT discovery results). > > Thanks > Srini From owner-ipsec@lists.tislabs.com Sat Mar 2 15:19:16 2002 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 g22NJG801791; Sat, 2 Mar 2002 15:19:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14754 Sat, 2 Mar 2002 17:36:52 -0500 (EST) Message-ID: <3C81554B.21A3B51A@storm.ca> Date: Sat, 02 Mar 2002 17:42:19 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Towards closure on NAT traversal. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg Bailey wrote: > > Yet there are some things that seem to me logically impossible in > the presence of a NAT. Consider an ESP encrypted, or even just > authenticated, FTP control channel. In order for the NAT to function > "transparently" it must assemble, parse, and alter the TCP stream > when necessary (PORT command). How can this possibly work using > straight IP with IPSec unless the NAT cracks the keys et cetera? Not > to mention that a NAT box with such capabilities would be an even > more powerful assault weapon than is a plain old NAT box... > > I would submit FTP as a proof of existence of insoluble problems in > *transparently* traversing a NAT with IPSec. Doesn't passive mode FTP solve that problem? > Even adding Security Gateway code to a NAT, which in many respects > would seem the best form of "IPSec pass-through", would still leave > the problems caused by uncoordinated use of private address space > on the other side of the NAT in non VPN environments. > > How long a list of exceptions can any "solution" to this charter > item tolerate and still deserve to be called a solution? How large a subset of the problem can a reasonably simple solution handle? Even if all it handled was web browsing, it might still be worth doing. Yes, there are things like some of the stranger H323 or gaming protocols that might be quite problematic. I cann see, though, that such exceptions matter a lot, let alone that their existence would invalidate a proposal that provided useful services. From owner-ipsec@lists.tislabs.com Sat Mar 2 22:45:13 2002 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 g236jC811902; Sat, 2 Mar 2002 22:45:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16040 Sun, 3 Mar 2002 00:45:31 -0500 (EST) From: "Greg Bailey" To: "Sandy Harris" , Cc: "ark-gvb-x" Subject: RE: Towards closure on NAT traversal. Date: Sat, 2 Mar 2002 21:56:45 -0800 Message-ID: MIME-Version: 1.0 charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C81554B.21A3B51A@storm.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Sandy Harris Sent: Sat 02 Mar 02 14:42 > > Greg Bailey wrote: > > > > Yet there are some things that seem to me logically impossible in > > the presence of a NAT. Consider an ESP encrypted, or even just > > authenticated, FTP control channel. In order for the NAT to function > > "transparently" it must assemble, parse, and alter the TCP stream > > when necessary (PORT command). How can this possibly work using > > straight IP with IPSec unless the NAT cracks the keys et cetera? Not > > to mention that a NAT box with such capabilities would be an even > > more powerful assault weapon than is a plain old NAT box... > > > > I would submit FTP as a proof of existence of insoluble problems in > > *transparently* traversing a NAT with IPSec. > > Doesn't passive mode FTP solve that problem? Not if the FTP server doesn't implement PASV (it is not required). This may seem to be niggling but if people are going to make fundamental changes such as NAT which change the requirements for interoperability it would be nice to at least publish those requirements in an RFC. More relevantly, not if the FTP server is itself behind a NAT box. Don't laugh, I have customers who are inflicting this sort of thing on themselves. Since PASV elicits a reply with IP address and port, the same problems exist with respect to ESP auth and/or encryption when traversing the server's NAT box ... unless I am missing something embarassingly obvious. > > Even adding Security Gateway code to a NAT, which in many respects > > would seem the best form of "IPSec pass-through", would still leave > > the problems caused by uncoordinated use of private address space > > on the other side of the NAT in non VPN environments. > > > > How long a list of exceptions can any "solution" to this charter > > item tolerate and still deserve to be called a solution? > > How large a subset of the problem can a reasonably simple solution > handle? Even if all it handled was web browsing, it might still be > worth doing. > > Yes, there are things like some of the stranger H323 or gaming > protocols that might be quite problematic. I cann see, though, > that such exceptions matter a lot, let alone that their existence > would invalidate a proposal that provided useful services. I figure that FTP is a pretty darn basic entitlement, and is also one that benefits greatly from the availability of IPSec. As long as NAT boxes are successfully pitched to people with no IPv4 address space problems as "security" devices, it seems ironic that their presence tends to interfere with actual end to end security. Is there a well defined mandatory form of ID for an IKE agent that is not based on its IP address and will universally interoperate? I do not see it in the current set of RFC's. If IKEv2 is supposed to be aware of the existence of NATs, I certainly hope a non IP based interoperable unique ID is required as part of it. Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | From owner-ipsec@lists.tislabs.com Sun Mar 3 07:27:45 2002 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 g23FRi801713; Sun, 3 Mar 2002 07:27:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17417 Sun, 3 Mar 2002 09:05:23 -0500 (EST) Message-Id: <5.1.0.14.0.20020303091153.00aa2a60@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Mar 2002 09:19:59 -0500 To: "Greg Bailey" , "Sandy Harris" , From: Melinda Shore Subject: RE: Towards closure on NAT traversal. Cc: "ark-gvb-x" In-Reply-To: References: <3C81554B.21A3B51A@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:56 PM 3/2/02 -0800, Greg Bailey wrote: >Not if the FTP server doesn't implement PASV (it is not required). This >may seem to be niggling but if people are going to make fundamental >changes such as NAT which change the requirements for interoperability >it would be nice to at least publish those requirements in an RFC. That's been done. You're actually talking about two different things: network/ transport-layer NAT traversal and application-layer NAT traversal. We're working on application-layer NAT traversal by developing mechanisms that allow applications to "know" their NATted-to address, and I would argue that this is not really an IPSec NAT problem. Requiring that boxes in the network know how application protocols work is bad mojo. Constraining the problem at hand to just getting individual IPSec flows across NATs will tend to work in favor of architectural cleanliness, will modularize the work so that it's doable (otherwise you're basically talking about rearchitecting IP), and will provide people who have to deal with applications with a tool they can use. Melinda From owner-ipsec@lists.tislabs.com Sun Mar 3 08:42:47 2002 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 g23Ggk806052; Sun, 3 Mar 2002 08:42:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17665 Sun, 3 Mar 2002 10:39:05 -0500 (EST) Date: Sun, 3 Mar 2002 07:49:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Henrik Levkowetz cc: ipsec mailling list Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 2 Mar 2002, Henrik Levkowetz wrote: > On Thursday, February 28, 2002 Chinna wrote: > ...... > > > > I would also like to extend the request to everyone (the veterans who can > > help us technically and also guide us through the IETF process, and > > frankly THE MORE THE MERRIER). Please join us if you want to help us. If > > you are skeptical of us due to the flame exchange, honestly, that's not > > our true nature. Please send me an email. > > > > Well, I'm taking you up on this; then we'll see if I end up hit > by a barrage of pies, eggs, tomatoes and whatnot from every direction... Thankyou very much for supporting our proposal and joining us. > > I've followed the discussions with respect to NAT traversal on the ipsec > mailing list during the last half year or so, while I've been working on > the current draft on NAT traversal for Mobile IP, and also implementing > NAT traversal for Mobile IP. > > It seems to me, viewing this discussion somewhat from the outside, that > in the matter of NAT traversal for IPsec you have as a group become the > victims of your own success. Let me explain what I mean; it is leading > somewhere: > > One goal in IPsec work would naturally be to have the protocols concerned > be as opaque and resistant as possible to both traffic and content analysis. > > One goal for NATs is to leverage extra information (in the form of port > addresses preferably) in order to make up for a scarcity of ip-addresses. > > So the more you succeed in making the communication opaque, the less there > is for NATs to work with. The (in this respect) straightforward solution to > accomplish NAT traversal is then to give NATs their favourite stuff to work > with: Port numbers. All ALGs (Application Layer Gateways) which are > added to NATs are there to take care of the protocols which do NOT give > the NATs port numbers to work with. They sometimes work, and sometimes > work well. > > The solution subdivides into (at least) two parts: Discovering if you are > behind a NAT, and doing something about it if you are. > > Chinna had a reference to an excellent draft which answers the first part > in a generic way: > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt > > The answer to the second part will have to consider the particular > requirements of the protocols which you want to get trough a NAT, but > if you would accept input from someone who's not of the IPsec community, > I'd be willing to pitch in. I don't believe the problem is too intractable. > For our solution we do not require to even discover NAT. The SPIs can be generated as a pair in all cases because this is such a simple operation. If there are any NATs enroute, they will use this property to de-multiplex the IPsec traffic and do IPsec pass-through. If doing encapsulation, you MUST do NAT discovery becuase the price they pay for encapsulation is high, 16 bytes of overhead (okay not 24 as I said in my previous mail). So, you want to do encapsulation and send keepalives every 9 seconds, only when you are absolutely sure that it is needed. Thanks again for your support, chinna From owner-ipsec@lists.tislabs.com Sun Mar 3 09:53:35 2002 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 g23HrY808995; Sun, 3 Mar 2002 09:53:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18064 Sun, 3 Mar 2002 12:10:13 -0500 (EST) From: "Jayant Shukla" To: "'Greg Bailey'" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Sun, 3 Mar 2002 09:18:34 -0800 Message-ID: <000001c1c2d7$738f68a0$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I would submit FTP as a proof of existence of insoluble problems in > *transparently* traversing a NAT with IPSec. > This problem has been solved. I specifically mentioned this case at the San Diego meeting. Wait for our ID for a more detailed description. > Even adding Security Gateway code to a NAT, which in many respects > would seem the best form of "IPSec pass-through", would still leave I don't think adding Security Gateway code to the NAT is a good solution. It makes IPsec not scalable and does not provide end-to-end security. > > How long a list of exceptions can any "solution" to this charter > item tolerate and still deserve to be called a solution? > The problem is that if a NAT traversal solution does not take into account everything a NAT box does, it will always have to deal with exceptions. If the solution lets the NAT box do its job, you won't have to deal with exceptions. Regards, Jayant www.trlokom.com > Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | > ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | > greg@minerva.com | Portland, OR 97204 US | > > > From owner-ipsec@lists.tislabs.com Sun Mar 3 10:27:49 2002 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 g23IRn810816; Sun, 3 Mar 2002 10:27:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18217 Sun, 3 Mar 2002 12:47:19 -0500 (EST) Date: Sun, 3 Mar 2002 09:58:09 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Tero Kivinen cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <15490.12610.696868.294810@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 3 Mar 2002, Tero Kivinen wrote: > Chinna N.R. Pellacuru writes: > > Consider adding 24 bytes of encapsulation on each packet, and > > decapsulating it > > All this can (and will) be done using hardware without problems, > adding fixed amount of the header is quite easy to implement on the > hardware.... Anything can be done in hardware. I am not sure what you are referring to as "hardware". I think even basic ESP and AH are still only being implemented in firmware mostly. I don't think people are doing encapsulation in hardware yet. > > > and sending keepalives on the IKE SA for IKE and each > > IPsec SA if each of them are using different source ports. > > The keepalives are only needed if you are actually the one who is > behind NAT box. If we are talking about road warrior - SGW case, then > the road warrior will send keepalives, the SGW will not send them. > Also we are mostly interested in the performance in the SGW end the > road warriors laptop do have enough cpu to do the few SA flow > processing it is doing. The SGW might be doing thousands of tunnels > and every small operation we need to do there counts. > That's good. Is that mentioned in the drafts? I thought that the draft didn't give so much detail about keepalives. It just says "A peer SHOULD send a NAT-keepalive packet if a need to send such packets is detected according to [Kiv00] and if no other packet to the peer has...". It also says that the keepalive timer should be 20 seconds, but I read somewhere else that the practical recommended default timer is 9 seconds. > > Compared to all this, recomputing the checksum is probably .01% of > > the cost. > > If that is so small why do you think people are adding checksum > calculation on the ethernet cards then? > The checksum is a simple 16-bit ones-complement sum of the data. If the checksum is so fool proof why is it not a MUST, and is only optional. I think even back in those days when the hardware wasn't so reliable, the designers made a conscious decision to use a dumb checksum which may not catch all the errors in favour of an efficient and cheap software implementation. This can be done in "hardware" too for IPsec as part of the ESP decapsulation. > > Encapsulation, decapsulation and sending keepalives isn't done in hardware > > too. > > Encapsulation and decapsulation can be done in the hardware, the > keepalives are not usually sent by the end that is more performance > limited, thus they are not interesting here. OK. It's done in "hardware". It's generally done in firmware. > > > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt > ... > > Is that close enough? It's almost looks like they wrote the draft just for > > us! > > I have to check it out. BTW they also complains that upgrading NAT(s) > is not an option, so I agree with them at least with that :-) > > The STUN protocol seems quite complicated, it for example does binary > search with different timeouts to find out the lifetime discovery etc. What do you propose? Instead use a very low lifetime so that it would work everywhere? I think it would save a lot of chatter by choosing the right lifetime, and using an appropriate lifetime rather than using a minimum default of 9 seconds always, like some implementations do. > It also does not implement any tunneling mechanism, and it does not > provide protocol to give the information to the other end (to undo the > modifications done by NAT box, both ends needs to know what > transformations are happening). I am not proposing that you come up with another version of IKE just for NAT traversal. I am saying that you can use a generic "NAT discovery" protocol before even starting IKE. If you use a generic protocol like the one above, you get those tremendrous benefits like finding out the lifetime you have to use. Keepalives are also consuming precious bandwidth. They shouldn't be just considered from a CPU cost on laptops point of view. > > > > If would have done it by putting the complete IKE header and special > > > IKE payload number which contains the whole packet inside, but some > > > other people considered 28 bytes of IKE header too much. > > > > 24 Vs 28. > > 8 vs 28 or 16 vs 36 bytes. Current UDP encapsulation has UDP header > (8 bytes) + non-ike marker (8 bytes). If we add full ike header it > would be UDP header (8 bytes) + ike header (28 bytes). All of those > packets then have still IP header (20 bytes). > OK. It's 16 bytes of overhead. I think that I saw a proposal that used 24 bytes at some point. 16 bytes is still a lot of overhead for each ESP packet. > > How much is too much? 24 is OK but 28 is too much? 24 bytes of > > encapsulation on every data packet is huge! And, this is on top of what > > ESP adds. > > I think you have something wrong with the calculations. Normal ESP > packet is > > IP(20) + ESP(xxx) > > trasnport mode nat encapsulated IP packet is: > > IP(20) + UDP(8) + NonIKE(8) + ESP(xxx) > > So the difference is 16 bytes. Where does the 24 come? If we would add > full IKE header then the difference would be 36 bytes. Some people > think that is too much. > Who said 16 bytes of overhead is OK? People are already screaming about the ESP overhead. > > This seems to be the main theme in your design principles. IPsec boxes are > > administered by the user, but NAT boxes are administered by the hotels and > > conferences. You seem to be heavily over engineered towards the > > "road-warrior" scenario. "road-warrior" is just one scenario in which > > IPsec is used, there are many other scenarios where someone has more > > control over where the data is going, and how it is being routed. > > I agree, I am considering the case where I am moving around with my > laptop, and I want to connect all kinds of hosts around the world > using ipsec. This includes office network in Finland, my home machine, > and hopefully later more and more using opportunistic encryption or > similar. In that kind of cases I normally don't have option do > anything for the NAT, but I have option for updating at least some of > the ipsec systems I am talking with (actually I wrote most of those > IKE implementations, and they do work already, and have been working > from the beginning). > > If I can control the NAT box then the problem space is different, but > in that case I also usually do have control over the IPsec still (or > can you give me example where I have control over the NAT box, but I > don't have control over the IPsec box ("having control" meaning that I > can update / change the box)). > > So I almost always have control over the IPsec box and for some of > those case I can also have control over the NAT box. > Yes, there are a ton of cases where someone has total control over all the boxes, and in those cases the encapsulation overhead and keepalive overhead can be saved both in terms of bandwidth and CPU costs on the IPsec endpoints. Just because laptops have enough CPU capacity to do whatever including stuff like sending keepalives very frequently, all the nodes across the route has to forward them even the security gateway has to some how deal with them to even simply discard them. > > So, your goal is to work with "most" NAT boxes, and NOT "all" NAT boxes. > > Just confirming that, I think there were some claims made that you need > > to work with "all" NAT boxes. > > We tried to work with "most" NAT boxes, because some of the NAT boxes > do not for example support UDP at all. We do not try to work with > those. Also I am pretty much sure there are yet another type of NAT > boxes I have never ever heard about that will not work, because they > do something different. And there are these NAT boxes that were upgraded because some IPsec implementations were broken, and your proposal will again not work through these NAT boxes. It's ironic that broken IPsec will work through these upgraded NAT boxes, but IPsec-NAT-traversal won't work. ------------------------------------------------------------------------ Some IPsec implementations were broken, and so people to workaround it upgraded their NAT boxes with a hack. Now, there comes along this new IPsec NAT traversal protocol which again doesn't work with these NAT boxes, and so the NAT boxes need to be upgraded again to come up with another hack to work with this new IPsec NAT Traversal protocol. The second upgrade to the NAT box is required because the IPsec NAT traversal protocol is designed with the most important design goal as, NAT boxes will NOT be upgraded! There seems to be a BIG disconnect between your design goals and practical deployment. If people are upgrading their NAT boxes with hacks to make broken IPsec implementations work through them, then I am 100% sure that people will upgrade them with a standard IPsec pass-through solution, that is much more reliable adn doesn't have the enourmous costs of encapsulation and keepalives. ------------------------------------------------------------------------- > Knowing how much broken stuff there is out there, I think there is no > way anybody can make anything that will work with "all" boxes. > OK. I just wanted to confirm, so that we are not setting unrealisitc goals. > > Hey, if they want to follow the money, you should advice them to start > > talking about "VALUE-ADD". You should advice them to not focus only on > > cyber cowboys who don't care whether their traffic is being routed over > > long-haul DWDM or barbed wire. They should also focus on businesses that > > want to run misson critical data over their networks. If you talk to such > > businesses they have very detailed requirements. Their requirements are > > down to the level of what door stop you use in your office, if you want to > > provide service/equipement to them. That is where the $$$$$$$ is, in > > "VALUE-ADD". How much does a "business" DSL cost, and how much does a > > "consumer" DSL cost? > > Business DSL (without NAT at all) costs about double to the "consumer" > DSL (most of them are with NAT). Exactly, "VALUE-ADD" is what people are willing to pay for double the cost, and sometimes even more. My point is that the ISPs can add some "VALUE" using our proposal, by translating IPsec properly, instead of the customers trying to figure out a way by themselves to somehow sneak through the ISP's NAT implementation. > > > A road-warrior who doesn't care what kind of NAT box the ISP is running > > isn't going to pay big $. It's the business customers and corporations who > > specify every detail of how they want their traffic to be routed, that pay > > the big $$$$$$$. > > And they do not want to have anything that looks like NAT anywhere > near if they can avoid it. Yes, most importantly "if" they can avoid it. Like anything else, NAT is also trying to solve some important problems. chinna From owner-ipsec@lists.tislabs.com Sun Mar 3 10:59:12 2002 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 g23IxB811341; Sun, 3 Mar 2002 10:59:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18367 Sun, 3 Mar 2002 13:17:50 -0500 (EST) Date: Sun, 3 Mar 2002 13:28:18 -0500 (EST) From: Henry Spencer To: "Chinna N.R. Pellacuru" cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 3 Mar 2002, Chinna N.R. Pellacuru wrote: > The checksum is a simple 16-bit ones-complement sum of the data. If the > checksum is so fool proof why is it not a MUST, and is only optional... It *is* a MUST for TCP. Only for UDP does the sender have the option of not including a checksum... and if it's included, checking it is a MUST. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sun Mar 3 12:23:07 2002 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 g23KN7813010; Sun, 3 Mar 2002 12:23:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18635 Sun, 3 Mar 2002 14:27:43 -0500 (EST) Date: Sun, 3 Mar 2002 11:38:08 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 3 Mar 2002, Henry Spencer wrote: > On Sun, 3 Mar 2002, Chinna N.R. Pellacuru wrote: > > The checksum is a simple 16-bit ones-complement sum of the data. If the > > checksum is so fool proof why is it not a MUST, and is only optional... > > It *is* a MUST for TCP. Only for UDP does the sender have the option of > not including a checksum... and if it's included, checking it is a MUST. > > Henry Spencer > henry@spsystems.net > Good point. My assumption is that we don't have to deal with the checksum of the true data packet, because we can never fully support true transport mode. Please see my other mails. The proposal has been to do a full NAT implementation in IPsec, and I don't think that is a reasonable way to solve this problem. We are dealing with checksums in either UDP because the original data packet was tunneled in UDP, or in other tunneling protocols like IPinIP or GRE, then we would not have to worry about the checksum on the original data packet (possibly TCP also) because that packet will never be touched by anyone. So, if telnet was encapsulated in L2TP, the original TCP checksum on the telnet packet won't be touched by anyone. We are only dealing with the checksum in the UDP header, which is added by L2TP. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Sun Mar 3 23:25:36 2002 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 g247PZ807923; Sun, 3 Mar 2002 23:25:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20509 Mon, 4 Mar 2002 01:24:39 -0500 (EST) From: "Jayant Shukla" To: "'Melinda Shore'" , "'Greg Bailey'" , "'Sandy Harris'" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Sun, 3 Mar 2002 22:32:59 -0800 Message-ID: <000001c1c346$6e32baf0$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <5.1.0.14.0.20020303091153.00aa2a60@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Melinda Shore > Sent: Sunday, March 03, 2002 6:20 AM > To: Greg Bailey; Sandy Harris; ipsec@lists.tislabs.com > Cc: ark-gvb-x > Subject: RE: Towards closure on NAT traversal. > > At 09:56 PM 3/2/02 -0800, Greg Bailey wrote: > >Not if the FTP server doesn't implement PASV (it is not required). This > >may seem to be niggling but if people are going to make fundamental > >changes such as NAT which change the requirements for interoperability > >it would be nice to at least publish those requirements in an RFC. > > That's been done. > So you have the PASV ftp working, right? > You're actually talking about two different things: network/ > transport-layer NAT traversal and application-layer NAT traversal. This is new! I though we were just dealing with the NAT traversal problem. Now you have split the NAT traversal problem into NAT traversal at TCP/IP layer and NAT traversal at application layer. > We're working on application-layer NAT traversal by developing > mechanisms that allow applications to "know" their NATted-to > address, and I would argue that this is not really an IPSec NAT > problem. Requiring that boxes in the network know how application > protocols work is bad mojo. > hmm! NAT boxes already do that! That is how it all started. What's your point? Are you suggesting that NAT boxes should not do what they are doing? > Constraining the problem at hand to just getting individual IPSec flows > across NATs will tend to work in favor of architectural cleanliness, > will modularize the work so that it's doable (otherwise you're > basically talking about rearchitecting IP), and will provide people > who have to deal with applications with a tool they can use. > > Melinda So now all FTP servers will have to be NAT aware, right? Try selling that to your customers. That is in addition to the modifications to IPsec, IKE, and NAT required by your solution. Regards, Jayant From owner-ipsec@lists.tislabs.com Sun Mar 3 23:25:40 2002 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 g247Pd807955; Sun, 3 Mar 2002 23:25:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20560 Mon, 4 Mar 2002 01:34:39 -0500 (EST) From: "Jayant Shukla" To: "'Chinna N.R. Pellacuru'" , "'Henrik Levkowetz'" Cc: "'ipsec mailling list'" Subject: RE: NAT Traversal Date: Sun, 3 Mar 2002 22:42:57 -0800 Message-ID: <000101c1c347$d2511cb0$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Chinna N.R. Pellacuru > > For our solution we do not require to even discover NAT. The SPIs can be > generated as a pair in all cases because this is such a simple operation. > If there are any NATs enroute, they will use this property to de-multiplex > the IPsec traffic and do IPsec pass-through. > So, you are suggesting modifications to IKE, right? This is interesting! According to your earlier e-mail, IKE modification for "NAT discovery" is not acceptable, but now IKE modification for "NAT traversal" is acceptable? Regards, Jayant http://www.trlokom.com > If doing encapsulation, you MUST do NAT discovery becuase the price they > pay for encapsulation is high, 16 bytes of overhead (okay not 24 as I said > in my previous mail). So, you want to do encapsulation and send keepalives > every 9 seconds, only when you are absolutely sure that it is needed. > > Thanks again for your support, > chinna From owner-ipsec@lists.tislabs.com Sun Mar 3 23:37:53 2002 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 g247br810319; Sun, 3 Mar 2002 23:37:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20662 Mon, 4 Mar 2002 01:59:13 -0500 (EST) Message-Id: <200203040708.g2478cp01450@fatty.lounge.org> To: ipsec@lists.tislabs.com Subject: DoS attack on JFK MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1447.1015225718.1@tibernian.com> Date: Sun, 03 Mar 2002 23:08:38 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The new JFK draft claims that resistance to CPU exhaustion attacks against the responder is a design goal. It also refers to Photuris and its use of cookies to thwart this sort of attack and further mentions that "[a]lthough the concept of the cookie was adopted by IKE, its use in that protocol did not follow the guidelines established by Photuris and left it open to DoS attacks." While JFK has not adopted the use of cookies it uses an "authenticator" blob for the same function. Unfortunately it also has not followed the guidlines established by Photuris and it is also open to DoS attack. The first basic requirement for cookies that Photuris laid down was: "1. The cookie MUST depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with requests from randomly chosen IP addresses or ports." In JFK the authenticator does not include anything specific to the initiator that would prevent using valid authenticator blobs to swamp a victim with requests from random IP addresses. The attack is a varient on Simpson's "cookie jar attack": 1. An attacker sends N different message ones to a target. Each of these contains different Ni and g^i values, but the attacker need not use any energy generating these different values, they can all just be garbage. 2. He will get N different message twos back. Each one will contain an authenticator blob, HMAC{HKr}(Ni, Nr, g^i, g^r), specific to a message he sent (the messages are correlated by comparing the Ni values). Provided that g^r on the Nth message two is the same as the g^r on the first message two the attacker knows that all the authenticator blobs are all signed by the current HKr. If the first and last g^r differ then the attacker starts the attack over. 3. Once he has N message twos he constructs N message threes with the nonces and exponentials tied to the correct authenticator blob with more garbage in the place of the encrypted identity, sa, and signature. These are all sent from randomly chosen IP addresses. The responder is forced to exponentiate to generate Ke to decrypt the garbage. My repeatedly sending "Ni, g^i" to the target and noting when g^r changes an attacker can get a pretty good idea on when to begin the attack and how high to set N for maximum effect. To limit the amount of resources necessary to launch this attack the attacker could use a "stateless" form of attack where it maintains a bunch of garbage bits whose length makes them look like a valid g^i value and when it generates a garbage Ni it replaces the last len(Ni) bits of the g^i with Ni. When it sends the message one containing "Ni, g^i" it can promptly forget Ni and g^i since Ni will be returned by the target in message two. Upon receipt of message two the attacker can reconstruct the g^i used with the particular Ni returned by the target to make message three. If the authenticator blob included something specific to the initiator, like his IP address, it would prevent this attack. Either the bogus message threes would be thrown away prior to exponentiation because the authenticator check failed (IP address was wrong) or if the attacker chose to send all the bogus message threes from the same IP address (to cause the authenticator check to be successful) the responder could make note of an unsuccessful decryption from a particular IP address and refuse any more messages from it for a period of time. At most it would be one pointless exponentiation and decryption. I suggest that the the authenticator be changed to: HMAC{HKr}(IPi, Ni, Nr, g^i, g^r) where IPi is the source IP address of the received message one. Dan. From owner-ipsec@lists.tislabs.com Mon Mar 4 04:46:41 2002 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 g24Cke812049; Mon, 4 Mar 2002 04:46:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22321 Mon, 4 Mar 2002 06:52:57 -0500 (EST) Message-Id: <200203041204.HAA20225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-01.txt Date: Mon, 04 Mar 2002 07:04:26 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Propsal for the IKEv2 Protocol Author(s) : D. Harkins, C. Kaufman et al. Filename : draft-ietf-ipsec-ikev2-01.txt Pages : 67 Date : 01-Mar-02 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP, AH and/or IPcomp. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on public signature keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-01.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-ietf-ipsec-ikev2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-01.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: <20020301134435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301134435.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Mar 4 07:13:50 2002 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 g24FDn823007; Mon, 4 Mar 2002 07:13:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23018 Mon, 4 Mar 2002 09:30:06 -0500 (EST) Message-Id: <5.1.0.14.0.20020304093409.00aa0c70@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 09:44:39 -0500 To: "Jayant Shukla" , From: Melinda Shore Subject: RE: Towards closure on NAT traversal. Cc: "'ark-gvb-x'" In-Reply-To: <000001c1c346$6e32baf0$0100a8c0@trlhpc1> References: <5.1.0.14.0.20020303091153.00aa2a60@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:32 PM 3/3/02 -0800, Jayant Shukla wrote: >> You're actually talking about two different things: network/ >> transport-layer NAT traversal and application-layer NAT traversal. > >This is new! It's not, actually - it's been going on for several years within the IETF and longer than that outside of the IETF >I though we were just dealing with the NAT traversal >problem. Now you have split the NAT traversal problem into NAT traversal >at TCP/IP layer and NAT traversal at application layer. You're dealing, I believe, with getting IPSec across NATs. If you expand the problem without separating it into its component parts you run the very real risk of 1) completely re-engineering IP, and 2) failing to respect layer boundaries. I'm not particularly dogmatic about the latter, although I've found that egregious layer violations tend to lead to routing problems/complexity, as routing tables and routing updates need to be shoved from one layer to another. >hmm! NAT boxes already do that! That is how it all started. What's your >point? Are you suggesting that NAT boxes should not do what they are >doing? Yes, partially. NATs and IP are fundamentally incompatible, and with session-oriented protocols and with servers behind NATs either the NAT need to know about the application or the application needs to know about the NAT. The problem with putting application awareness into NATs is that it has terrible scaling characteristics, it deals with some situations very badly (if at all - for example, multiple instances of the same service behind a single NAT), and it isn't particularly responsive to the deployment of new protocols or new versions of old protocols. If you're arguing that NAT traversal problems need to be solved, well sure, I agree - I chair midcom and am working on additional approaches to the problem. If you're arguing that the IPSec working group should figure out how to get non-PASV FTP across NATs, that's just silly. Melinda From owner-ipsec@lists.tislabs.com Mon Mar 4 07:14:03 2002 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 g24FE3823021; Mon, 4 Mar 2002 07:14:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23093 Mon, 4 Mar 2002 09:35:41 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15490.9405.810075.114327@ryijy.hel.fi.ssh.com> Date: Sun, 3 Mar 2002 15:27:25 +0200 From: Tero Kivinen To: Cc: Subject: RE: draft-ietf-ipsec-ikev2-01.txt In-Reply-To: <002101c1c0b5$01e7b320$1e72788a@ca.alcatel.com> References: <15486.35392.127648.448194@ryijy.hel.fi.ssh.com> <002101c1c0b5$01e7b320$1e72788a@ca.alcatel.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 17 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > It is easy to write software to check if someone is spoofing your IP from > your own LAN if you're so inclined, although I suppose they could be > silently listening on the LAN, forwarding the cookies to another location > and spoofing the responses from there. Because as you say it is easy to stop the machine that actually does something nasty and is along the path, but it is very hard to detect the machine that only listens and send the information need to launch the attack to another host(s). > > Sending faked packet can be done from completely different host > > (some hacked machine out there in Elboinia), and from different > > machine every time. This way finding the attackers listening post is > > much harder, and he can continue the attack much longer. > I'm not including those cases because we're talking about attacks against > the initiator here. The adversary has to be on the data path in order to > learn the initiator's cookie. I am very concern about attacks that are very hard to block and very hard to find who is doing it. I was mostly talking about this kind of listening post + sending info to somewhere else attack. > Well, the new draft of IKEv2 seems to imply that this is the expected > behaviour of the initiator (a SHOULD). I have no problems with it being a > MAY, but I don't think this should be the default behaviour. You are merely > trading one DoS attack for another. I agree that it should be MAY instead of SHOULD. And perhaps we need to add more text about the how this is done. I.e you need to process all packets, and you need to start as many partial exchanges, to do that you want to do that only if you have spare time. Also it should be done in a way that if you detect this kind of problem you only first gather some time for possible response packets and then start processing them in random order. If you happen to hit timeout before you can process all packets then you try again with new exchange and this time you propably take different cookies where you respond, meaning that the propablity of succeeding is 1 / (number of attacker packets ) * (number of packets per second you can process * timeout in seconds). If the attacker is sending 10000 packets, you can process 50 packets per second and the timeout is 30 seconds, the propability is 15%. > Let's face it. Most machines out there aren't ultra-reliable under load. So > unless you're ultra-confident about your robustness, you shouldn't try to > outlast a DoS attack. Also, if you're being swamped with bogus replies then > chances are you are dropping some packets. If so, you might as well drop the > packets that are 99% likely to be spoofed and focus on giving good QoS to > the rest of your flows. If you have some spare cycles, you can try to > process some of the spoofed packets in the hope that it really is Bob. Keep > in mind that Alice is not necessarily a user sitting in front of the > computer who has the ability to abort the connection in real time. Lets put it this way. Not all implementations are going to do it, but I think the protocol should not make it impossible to try to do it. It is then only implementation detail how it is done, if done at all. > I just noticed that with IKEv2 you can avoid this attack against the gateway > in a client to gateway scenario (the original responder can take advantage > of IKEv2's ability to rekey under the protection of the original phase 1), > which is good. True. This is the kind of things I am looking for. Things that do not complicate things but makes it possible to have some kind of protection against DoS. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 4 07:15:07 2002 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 g24FF7823081; Mon, 4 Mar 2002 07:15:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23082 Mon, 4 Mar 2002 09:34:41 -0500 (EST) From: "Henrik Levkowetz" To: "Chinna N.R. Pellacuru" , "ipsec mailling list" Subject: RE: NAT Traversal Date: Sat, 2 Mar 2002 08:54:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, February 28, 2002 Chinna wrote: ...... > > I would also like to extend the request to everyone (the veterans who can > help us technically and also guide us through the IETF process, and > frankly THE MORE THE MERRIER). Please join us if you want to help us. If > you are skeptical of us due to the flame exchange, honestly, that's not > our true nature. Please send me an email. > Well, I'm taking you up on this; then we'll see if I end up hit by a barrage of pies, eggs, tomatoes and whatnot from every direction... I've followed the discussions with respect to NAT traversal on the ipsec mailing list during the last half year or so, while I've been working on the current draft on NAT traversal for Mobile IP, and also implementing NAT traversal for Mobile IP. It seems to me, viewing this discussion somewhat from the outside, that in the matter of NAT traversal for IPsec you have as a group become the victims of your own success. Let me explain what I mean; it is leading somewhere: One goal in IPsec work would naturally be to have the protocols concerned be as opaque and resistant as possible to both traffic and content analysis. One goal for NATs is to leverage extra information (in the form of port addresses preferably) in order to make up for a scarcity of ip-addresses. So the more you succeed in making the communication opaque, the less there is for NATs to work with. The (in this respect) straightforward solution to accomplish NAT traversal is then to give NATs their favourite stuff to work with: Port numbers. All ALGs (Application Layer Gateways) which are added to NATs are there to take care of the protocols which do NOT give the NATs port numbers to work with. They sometimes work, and sometimes work well. The solution subdivides into (at least) two parts: Discovering if you are behind a NAT, and doing something about it if you are. Chinna had a reference to an excellent draft which answers the first part in a generic way: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt The answer to the second part will have to consider the particular requirements of the protocols which you want to get trough a NAT, but if you would accept input from someone who's not of the IPsec community, I'd be willing to pitch in. I don't believe the problem is too intractable. Best regards, Henrik From owner-ipsec@lists.tislabs.com Mon Mar 4 07:15:15 2002 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 g24FFF823093; Mon, 4 Mar 2002 07:15:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23119 Mon, 4 Mar 2002 09:36:45 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15490.10089.996924.236616@ryijy.hel.fi.ssh.com> Date: Sun, 3 Mar 2002 15:38:49 +0200 From: Tero Kivinen To: Stephen Kent Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: References: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> <15487.35607.13211.15952@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >For those cases I think it is ok for an implementation to mark the > >packet after decryption and MAC verification that it had correct > >tcp/udp checksum so that the operating system stack can then notice > >that ok, I should not do checksum checks for this packet, as something > >inside my system already claimed that it is ok. > We would need some standard means of signalling this across a network > if the IPsec implementation is in an SG, vs. in the same host. That > strikes me as problematic. I don't think there must be any protocol signalling it across networks, I think we can only allow this kind of thing if it is happening inside one machine. I.e if the IPsec knows that this packet is going to end to this machines local IP stack, it can put flag up, saying I don't care about checksum I already verified the auth header. Also quite often the OS will also know that there is one more checksum inside the packet (i.e more tunneling protocols inside the UDP/TCP packets), thus this is not actually end to end case merely decapsulation. I think this checksum calculation discussion is not very usefull. The current NAT-T draft makes it possible for you to recalculate the checksum incrementatally, or completely, and that is the normal way. In some exceptional cases where you know that the checksum is not used at all anyways, you can simply put flag on in the MBUF chain saying that I already "verified" the checksum, ignore it. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 4 07:16:41 2002 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 g24FGe823142; Mon, 4 Mar 2002 07:16:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23162 Mon, 4 Mar 2002 09:38:43 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15490.38630.213860.838659@ryijy.hel.fi.ssh.com> Date: Sun, 3 Mar 2002 23:34:30 +0200 From: Tero Kivinen To: "Chinna N.R. Pellacuru" Cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: References: <15490.12610.696868.294810@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 27 min X-Total-Time: 32 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna N.R. Pellacuru writes: > > The keepalives are only needed if you are actually the one who is > > behind NAT box. If we are talking about road warrior - SGW case, then > > the road warrior will send keepalives, the SGW will not send them. > > Also we are mostly interested in the performance in the SGW end the > > road warriors laptop do have enough cpu to do the few SA flow > > processing it is doing. The SGW might be doing thousands of tunnels > > and every small operation we need to do there counts. > > That's good. Is that mentioned in the drafts? I thought that the draft > didn't give so much detail about keepalives. It just says "A peer SHOULD > send a NAT-keepalive packet if a need to send such packets is detected > according to [Kiv00] and if no other packet to the peer has...". draft-ietf-ipsec-nat-t-ike-01.txt ([Kiv00]) says: ---------------------------------------------------------------------- ... 3.2. Detecting presense of NAT The purpose of the NAT-D payload is twofold, It not only detects the presence of NAT between two IKE peers, it also detects where the NAT is. The location of the NAT device is important in that the keepalives need to initiate from the peer "behind" the NAT. ... If there is no NAT between then the first NAT-D payload should match one of the local NAT-D packet (i.e the local NAT-D payloads this host is sending out), and the one of the other NAT-D payloads must match the remote ends IP address and port. If the first check fails (i.e first NAT-D payload does not match any of the local IP addresses and ports), then it means that there is dynamic NAT between, and this end should start sending keepalives as defined in the [Hutt01]. ---------------------------------------------------------------------- > It also says that the keepalive timer should be 20 seconds, but I read > somewhere else that the practical recommended default timer is 9 seconds. Normal time to keep udp connections is usually few minutes, but as there are boxes which are using shorter timeouts (even down to 30 seconds), that is the reson draft-ietf-ipsec-udp-encaps-01.txt suggests the 20 seconds. Also as the keepalive packets are usually sent via the local area network only, that means that they are usually more reliable than the global internet. This means that it is quite often enough if we send only one packet per timeout value, i.e we don't need to care about lost packets. Again, because this is not always the case the parameter needs to be configurable. One more thing to note about the keepalives is that they are only sent where there is no other traffic going on the IPsec or IKE SA. Normally there is constant data going for the IPsec SA, thus it is already keeping the mapping up. This is also one of the benfits of having IKE and IPSec SA share the mapping, so we don't need to keep the IKE SA up with timeouts, as the IPsec SA packets keeps it up. > The checksum is a simple 16-bit ones-complement sum of the data. If the > checksum is so fool proof why is it not a MUST, and is only optional. I It is MUST to implement for both UDP and TCP, and it MUST to be on by default. There MAY be option to turn it off for UDP. It is always MUST for tcp. This has already been pointed out in this thread with reference to rfc1122. Note, that the case where we talk about turning off the checksum calculation is mostly for the cases where there is one more checksum inside the packet anyways, and where the local stack is going to process the packet. > > The STUN protocol seems quite complicated, it for example does binary > > search with different timeouts to find out the lifetime discovery etc. > What do you propose? Instead use a very low lifetime so that it would work > everywhere? I think it would save a lot of chatter by choosing the right > lifetime, and using an appropriate lifetime rather than using a minimum > default of 9 seconds always, like some implementations do. There are few problems. Firstly doing lifetime parameter detection takes real time. To see if the lifetime parameter is more than 5 minutes, we need to wait for 5 minutes. Of course we could start with the short timeouts, and while the probe goes on, we could raise the keepalive timers used in the IKE. Another problem is that the lifetime parameter isn't constant. When the load goes up, those timers usually goes down, because the NAT box is running out of the memory. This means that we might start up with 5 minute timers, but when the load goes up suddenly our connections are broken because the NAT box lowered the timer value to 2 minute. > I am not proposing that you come up with another version of IKE just for > NAT traversal. I am saying that you can use a generic "NAT discovery" > protocol before even starting IKE. That would be one of the options. When we ware discussing this in the Minneapolis IETF year ago, this draft wasn't available. I have to check the STUN protocol more to say if there is something that is missing that IKE needs. > If you use a generic protocol like the one above, you get those > tremendrous benefits like finding out the lifetime you have to use. > Keepalives are also consuming precious bandwidth. They shouldn't be just > considered from a CPU cost on laptops point of view. One of the things we ware discussing was also limiting the TTL of the keepalives. They only need to reach the last NAT box to keep that one up, thus we could configure the TTL to be short enough so that they will be expired before the actually go any furter out. This was rejected mostly because finding out the proper TTL complicates things and the TTL could change during the normal operation. Also as the keepalives are only sent when there is no other traffic going, their bandwidth usage is limited only in the case where the client is not doing anything. > OK. It's 16 bytes of overhead. I think that I saw a proposal that used > 24 bytes at some point. 16 bytes is still a lot of overhead for each ESP > packet. That might be old Stenberg proposal, that was changed because people considered its overhead too big. > And there are these NAT boxes that were upgraded because some IPsec > implementations were broken, and your proposal will again not work through > these NAT boxes. It's ironic that broken IPsec will work through these > upgraded NAT boxes, but IPsec-NAT-traversal won't work. No, it does not work through those boxes. Put two clients behind one NAT box that maps them to same IP address, and think what happens when the second one of them is sending the INITIAL-CONTACT notification. That notification will remove all IKE SAs and IPsec SA associated with the remote system. In this case the remote system is the port 500 of the NAT box. In our case the remote port will be different, meaning that the remote systems can be considered different. I think there are quite a lot of implementations out there that will check the remote ip-address, but if they want to implement NAT-T they will have to modify their interpretation to check port number too. > Some IPsec implementations were broken, and so people to workaround it > upgraded their NAT boxes with a hack. Now, there comes along this new > IPsec NAT traversal protocol which again doesn't work with these NAT I wouldn't say our proposals come out now. They have been out for several years. During that time NAT boxes changed. > boxes, and so the NAT boxes need to be upgraded again to come up with > another hack to work with this new IPsec NAT Traversal protocol. The > second upgrade to the NAT box is required because the IPsec NAT traversal > protocol is designed with the most important design goal as, NAT boxes > will NOT be upgraded! There seems to be a BIG disconnect between your > design goals and practical deployment. There is already been discussion about changing the current draft so that it will float to different port in the middle of the Phase 1 to cope with that kind of NAT boxes. Of course it makes things more complicated but we have to do something for the issue. > Exactly, "VALUE-ADD" is what people are willing to pay for double the > cost, and sometimes even more. My point is that the ISPs can add some > "VALUE" using our proposal, by translating IPsec properly, instead of the > customers trying to figure out a way by themselves to somehow sneak > through the ISP's NAT implementation. I wouldn't be paying double for the different kind of NAT, I am paying about double to get fixed ip-address without NAT at all. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 4 07:18:31 2002 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 g24FIU823219; Mon, 4 Mar 2002 07:18:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23137 Mon, 4 Mar 2002 09:37:42 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15490.12610.696868.294810@ryijy.hel.fi.ssh.com> Date: Sun, 3 Mar 2002 16:20:50 +0200 From: Tero Kivinen To: "Chinna N.R. Pellacuru" Cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: References: <15487.36821.537419.263885@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 28 min X-Total-Time: 41 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna N.R. Pellacuru writes: > Consider adding 24 bytes of encapsulation on each packet, and > decapsulating it All this can (and will) be done using hardware without problems, adding fixed amount of the header is quite easy to implement on the hardware.... > and sending keepalives on the IKE SA for IKE and each > IPsec SA if each of them are using different source ports. The keepalives are only needed if you are actually the one who is behind NAT box. If we are talking about road warrior - SGW case, then the road warrior will send keepalives, the SGW will not send them. Also we are mostly interested in the performance in the SGW end the road warriors laptop do have enough cpu to do the few SA flow processing it is doing. The SGW might be doing thousands of tunnels and every small operation we need to do there counts. > Compared to all this, recomputing the checksum is probably .01% of > the cost. If that is so small why do you think people are adding checksum calculation on the ethernet cards then? > Encapsulation, decapsulation and sending keepalives isn't done in hardware > too. Encapsulation and decapsulation can be done in the hardware, the keepalives are not usually sent by the end that is more performance limited, thus they are not interesting here. > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt ... > Is that close enough? It's almost looks like they wrote the draft just for > us! I have to check it out. BTW they also complains that upgrading NAT(s) is not an option, so I agree with them at least with that :-) The STUN protocol seems quite complicated, it for example does binary search with different timeouts to find out the lifetime discovery etc. It also does not implement any tunneling mechanism, and it does not provide protocol to give the information to the other end (to undo the modifications done by NAT box, both ends needs to know what transformations are happening). > > If would have done it by putting the complete IKE header and special > > IKE payload number which contains the whole packet inside, but some > > other people considered 28 bytes of IKE header too much. > > 24 Vs 28. 8 vs 28 or 16 vs 36 bytes. Current UDP encapsulation has UDP header (8 bytes) + non-ike marker (8 bytes). If we add full ike header it would be UDP header (8 bytes) + ike header (28 bytes). All of those packets then have still IP header (20 bytes). > How much is too much? 24 is OK but 28 is too much? 24 bytes of > encapsulation on every data packet is huge! And, this is on top of what > ESP adds. I think you have something wrong with the calculations. Normal ESP packet is IP(20) + ESP(xxx) trasnport mode nat encapsulated IP packet is: IP(20) + UDP(8) + NonIKE(8) + ESP(xxx) So the difference is 16 bytes. Where does the 24 come? If we would add full IKE header then the difference would be 36 bytes. Some people think that is too much. > This seems to be the main theme in your design principles. IPsec boxes are > administered by the user, but NAT boxes are administered by the hotels and > conferences. You seem to be heavily over engineered towards the > "road-warrior" scenario. "road-warrior" is just one scenario in which > IPsec is used, there are many other scenarios where someone has more > control over where the data is going, and how it is being routed. I agree, I am considering the case where I am moving around with my laptop, and I want to connect all kinds of hosts around the world using ipsec. This includes office network in Finland, my home machine, and hopefully later more and more using opportunistic encryption or similar. In that kind of cases I normally don't have option do anything for the NAT, but I have option for updating at least some of the ipsec systems I am talking with (actually I wrote most of those IKE implementations, and they do work already, and have been working from the beginning). If I can control the NAT box then the problem space is different, but in that case I also usually do have control over the IPsec still (or can you give me example where I have control over the NAT box, but I don't have control over the IPsec box ("having control" meaning that I can update / change the box)). So I almost always have control over the IPsec box and for some of those case I can also have control over the NAT box. > So, your goal is to work with "most" NAT boxes, and NOT "all" NAT boxes. > Just confirming that, I think there were some claims made that you need > to work with "all" NAT boxes. We tried to work with "most" NAT boxes, because some of the NAT boxes do not for example support UDP at all. We do not try to work with those. Also I am pretty much sure there are yet another type of NAT boxes I have never ever heard about that will not work, because they do something different. Knowing how much broken stuff there is out there, I think there is no way anybody can make anything that will work with "all" boxes. > Hey, if they want to follow the money, you should advice them to start > talking about "VALUE-ADD". You should advice them to not focus only on > cyber cowboys who don't care whether their traffic is being routed over > long-haul DWDM or barbed wire. They should also focus on businesses that > want to run misson critical data over their networks. If you talk to such > businesses they have very detailed requirements. Their requirements are > down to the level of what door stop you use in your office, if you want to > provide service/equipement to them. That is where the $$$$$$$ is, in > "VALUE-ADD". How much does a "business" DSL cost, and how much does a > "consumer" DSL cost? Business DSL (without NAT at all) costs about double to the "consumer" DSL (most of them are with NAT). > A road-warrior who doesn't care what kind of NAT box the ISP is running > isn't going to pay big $. It's the business customers and corporations who > specify every detail of how they want their traffic to be routed, that pay > the big $$$$$$$. And they do not want to have anything that looks like NAT anywhere near if they can avoid it. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 4 08:25:49 2002 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 g24GPm801904; Mon, 4 Mar 2002 08:25:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23866 Mon, 4 Mar 2002 10:42:16 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A9C0FE1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Tony Hain , "Hallam-Baker, Phillip" , Joe Touch Cc: ipsec mailling list Subject: RE: NAT support and laws for the lawless Date: Mon, 4 Mar 2002 07:54:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C394.DE2C8400" 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_000_01C1C394.DE2C8400 Content-Type: text/plain; charset="iso-8859-1" > In this case you can. Assume you have an IPv6 network between the > endpoints, and let the stack work out the layers of framing > necessary to make that true. Ah assume that we solve the problem by merely replacing the entire Internet routing infrastructure. How about we face reality and assume IPv4 will outlive us all whether or not IPv6 is ever deployed. The title of this thread implies that people believe that the IETF sets laws and has a right of veto over net use. The IETF is no difference in principle to any other open source type project, people can and do fork the code tree. This is not about the morality of NAT, after all if electricity is created by eletrons that means that morality is created by morons. Phill ------_=_NextPart_000_01C1C394.DE2C8400 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C394.DE2C8400-- From owner-ipsec@lists.tislabs.com Mon Mar 4 08:58:46 2002 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 g24Gwj803309; Mon, 4 Mar 2002 08:58:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24100 Mon, 4 Mar 2002 11:17:12 -0500 (EST) Message-Id: <5.1.0.14.0.20020304112655.00a8db20@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 11:31:33 -0500 To: Tero Kivinen From: Melinda Shore Subject: Re: NAT Traversal Cc: ipsec mailling list In-Reply-To: <15490.12610.696868.294810@ryijy.hel.fi.ssh.com> References: <15487.36821.537419.263885@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:20 PM 3/3/02 +0200, Tero Kivinen wrote: >The STUN protocol seems quite complicated, it for example does binary >search with different timeouts to find out the lifetime discovery etc. >It also does not implement any tunneling mechanism, and it does not >provide protocol to give the information to the other end (to undo the >modifications done by NAT box, both ends needs to know what >transformations are happening). The intent of STUN is to allow the sending host to determine what its "external" address is. This is *strictly* in order to allow protocols which make use of embedded IP addresses to function properly. That is to say, a host placing an H.323 call can use STUN to determine the address/port tuples at which media channels will appear to the outside, allowing it to provide correct parameters to OpenLogicalChannel commands. STUN does not provide any traversal capabilities, per se. Melinda From owner-ipsec@lists.tislabs.com Mon Mar 4 09:54:46 2002 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 g24Hsj805549; Mon, 4 Mar 2002 09:54:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24358 Mon, 4 Mar 2002 12:16:28 -0500 (EST) From: "Tony Hain" To: Cc: Subject: RE: NAT Traversal Date: Mon, 4 Mar 2002 09:27:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: <3C802F16.245A29F6@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apparently Christian didn't name it the way he said it would be done. The doc is actually: http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-05.tx t Tony > -----Original Message----- > From: asimu@cisco.com [mailto:asimu@cisco.com] > Sent: Friday, March 01, 2002 5:47 PM > To: Tony Hain > Subject: Re: NAT Traversal > > > Hi Tony > > I couldn't find the draft on the IETF site. Could you please send a > pointer? > > Thanks > -Adina > > Tony Hain wrote: > > > > Markus Stenberg wrote: > > > If 'change all network devices' was applicable solution, I'd > > > say we'd be > > > running IPv6 and not worrying about the legacy issues (such > > > as NAT) at all. > > > > Fortunately IPv6 does not require 'change all network > devices' as its > > deployment model. It will work fine by treating the existing IPv4 > > Internet as a layer-2 multi-access media (which happens to > have a well > > recognized 20 byte frame header) like IPv4 does with Frame > Relay. Refer > > to draft-ietf-ngtrans-teredo-05.txt as a way to push the > NAT traversal > > problem out of your space, so you can focus on simply > making end-to-end > > IPsec work well. There is no reason to waste the time of > this WG on an > > experiment that escaped from the lab and went very wrong... > > > > Tony From owner-ipsec@lists.tislabs.com Mon Mar 4 09:54:47 2002 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 g24Hsk805556; Mon, 4 Mar 2002 09:54:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24333 Mon, 4 Mar 2002 12:12:33 -0500 (EST) From: "Jayant Shukla" To: "'Melinda Shore'" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Mon, 4 Mar 2002 09:20:55 -0800 Message-ID: <000001c1c3a0$f246e280$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <5.1.0.14.0.20020304093409.00aa0c70@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > > If you're arguing that NAT traversal problems need to be solved, well > sure, I think now we all agree that NAT traversal problem need to be solved. However, at the San Diego meeting a gentleman from your company chimed, "We will just wait for IPv6." I presume that is not your company policy (anymore). > I agree - I chair midcom and am working on additional approaches to the > problem. If you're arguing that the IPSec working group should figure out > how to get non-PASV FTP across NATs, that's just silly. > > Melinda In the end, somebody has to provide the full solution and that is all customers care about. If it is all done at one place it is far more attractive than a split solution. A split solution requires too many changes everywhere. People "might" digest changes to IKE, IPsec, and NATs. However, if you start proposing changes to applications as well, you will be in trouble as that would inconvenience your customers a bit too much. That is why we are advocating a single solution and want to leave the applications untouched. The fact that our solution does not require changes to IKE or NATs, makes it more attractive. Also, figuring out how to get non-PASV FTP across NATs is not silly, but it is important. That is how mirror ftp sites get updated. Because we solve this problem, it has made several of our clients very happy. BTW, PORT mode usage accounts for over 77% of the users on Microsoft site. Site statistics from Microsoft site (9:17 am 4 March 2002) PASV : 249596 PORT : 845979 Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Mon Mar 4 10:03:27 2002 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 g24I3Q806871; Mon, 4 Mar 2002 10:03:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24427 Mon, 4 Mar 2002 12:22:28 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A9C1020@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Melinda Shore , Jayant Shukla , ipsec@lists.tislabs.com Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Mon, 4 Mar 2002 09:34:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C3A2.DDA486F0" 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_000_01C1C3A2.DDA486F0 Content-Type: text/plain; charset="iso-8859-1" > You're dealing, I believe, with getting IPSec across NATs. If > you expand the problem without separating it into its component > parts you run the very real risk of 1) completely re-engineering > IP, and 2) failing to respect layer boundaries. I'm not particularly > dogmatic about the latter, although I've found that egregious layer > violations tend to lead to routing problems/complexity, as routing > tables and routing updates need to be shoved from one layer > to another. Here IPSEC is likely to have beneficial effect on NAT by severely limiting the scope for NAT developers to mess with packets. This may mean that a number of protocols cannot be used behind a NAT, but this should not be a suprise since machines that are behind a NAT do not have an incomming address. Leave those problems for the Network Address Service Translation Yet (NASTY) working group. To take IPSEC to the next level we need to make IPSEC work well enough through a NAT that it can support SMTP client, HTTP client, POP3 client, IMAP client, NNTP client. We do not need to start addressing problems that have not been solved for NAT in general (and hacking up packets with protocol sensitive modifications is not a solution). The only way to fix those problems properly is to charter the NASTY working group to do a standards protcol for NAT discovery and port reservation and then deep integrate that into the IP stack so that when the call for 'give me a new socket' is made the IP stack sends a message off to the NAT box to request a port to be reserved. This probably does not require a degree in Nuclear Physics. If people stopped complaining about how anti-social NATs are and started working out how we could socialize them into more acceptable modes of behavior the degree of damage caused could be rendered tollerable. Phill ------_=_NextPart_000_01C1C3A2.DDA486F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C3A2.DDA486F0-- From owner-ipsec@lists.tislabs.com Mon Mar 4 10:11:20 2002 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 g24IBJ807317; Mon, 4 Mar 2002 10:11:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24475 Mon, 4 Mar 2002 12:34:02 -0500 (EST) Message-Id: <5.1.0.14.0.20020304124420.00a8e950@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 12:48:11 -0500 To: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com From: Melinda Shore Subject: RE: Towards closure on NAT traversal. Cc: "'ark-gvb-x'" In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40A9C1020@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:34 AM 3/4/02 -0800, Hallam-Baker, Phillip wrote: >The only way to fix those problems properly is to charter the NASTY working >group to do a standards protcol for NAT discovery and port reservation and >then deep integrate that into the IP stack so that when the call for 'give >me a new socket' is made the IP stack sends a message off to the NAT box to >request a port to be reserved. That working group exists (midcom). I chair it but don't agree with the basic model, preferring something closer to TED (see my "network-friendlier midcom" draft). There's recently been a bunch of work in the academic community on overlay networks, which is probably closer to what's being discussed here. Melinda From owner-ipsec@lists.tislabs.com Mon Mar 4 10:21:17 2002 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 g24ILH808091; Mon, 4 Mar 2002 10:21:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24549 Mon, 4 Mar 2002 12:46:31 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , "Joe Touch" Cc: "ipsec mailling list" Subject: RE: NAT support and laws for the lawless Date: Mon, 4 Mar 2002 09:58:02 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F40A9C0FE1@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > Ah assume that we solve the problem by merely replacing the > entire Internet > routing infrastructure. Not replacing, leveraging it as a layer-2 substrate. > > How about we face reality and assume IPv4 will outlive us all > whether or not > IPv6 is ever deployed. I didn't say IPv4 would go away, in fact the argument counts on it being there until the ISPs decide that routing IPv6 packets is in their best interest. The argument is that there is no need for this group to figure out how to traverse NATs. IPsec works well end-to-end. We know the IPv4 environment doesn't provide that, and the IPv6 environment does. > > The title of this thread implies that people believe that the > IETF sets laws > and has a right of veto over net use. The IETF is no > difference in principle > to any other open source type project, people can and do fork > the code tree. I didn't even read the subject until you pointed it out, but the point is not about what authority the IETF has over use of its writings. The point is that the IETF is in control of the focus of the WGs and how much time they spend trying to define duplicate solutions. Since the problem being solved is 'below' the space IPsec should be worried about, the WGs responsible for those lower layer issues should be doing the work. If nothing was in process that could solve the problem, or a willing WG could not be found, it is much more reasonable for this WG to take on the work. In this case the problem is being addressed, so this WG should drop it and get back to a valuable use of its time. Tony > > This is not about the morality of NAT, after all if > electricity is created > by eletrons that means that morality is created by morons. > > > Phill > > > > > From owner-ipsec@lists.tislabs.com Mon Mar 4 10:26:37 2002 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 g24IQa808325; Mon, 4 Mar 2002 10:26:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24560 Mon, 4 Mar 2002 12:47:04 -0500 (EST) Date: Mon, 4 Mar 2002 09:58:02 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Jayant Shukla cc: "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: <000101c1c347$d2511cb0$0100a8c0@trlhpc1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 3 Mar 2002, Jayant Shukla wrote: > > -----Original Message----- > > On Behalf Of Chinna N.R. Pellacuru > > > > For our solution we do not require to even discover NAT. The SPIs can > be > > generated as a pair in all cases because this is such a simple > operation. > > If there are any NATs enroute, they will use this property to > de-multiplex > > the IPsec traffic and do IPsec pass-through. > > > > So, you are suggesting modifications to IKE, right? > > This is interesting! According to your earlier e-mail, IKE modification > for "NAT discovery" is not acceptable, but now IKE modification for "NAT > traversal" is acceptable? > SPI is an IPsec parameter as opposed to IKE. In almost all implementations the SPI space is managed by the IPsec implementation (if we divide IPsec into IPsec implementation and IKE). When a responder receives a bunch of Phase2 proposals in Quick mode, it'll pick one proposal, and for that proposal it generates the SPI(s) which are a hash of the initiator's SPI(s). In general, IKE will have to request SPIs from the IPsec implementation because SPI is an IPsec parameter. We only propose to change the semantics of the SPI, IE., now incoming and outgoing SPIs of an IPsec protocol (ESP or AH) can be paired. One of them will be the hash of the other. Actually only half of one of them is a hash of the other. The other half is still left free, to allow some flexibility for implementations who want to do fancy things with SPI generation. No other change is required in IPsec or IKE. NAT implementation will use this extra intelligence to translate ESP traffic. NAT can place the IPsec SPIs in its translation table and pair the SPIs which belong to an IPsec flow and demultiplex the incoming traffic. NAT also does NOT change anything in either IKE or IPsec. NAT does a passive IPsec pass-through. Please let me know if you need more details. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 10:29:04 2002 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 g24IT4808358; Mon, 4 Mar 2002 10:29:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24612 Mon, 4 Mar 2002 12:56:50 -0500 (EST) Message-ID: <3C83B818.7000402@isi.edu> Date: Mon, 04 Mar 2002 10:08:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Hain CC: "Hallam-Baker, Phillip" , ipsec mailling list Subject: Re: NAT support and laws for the lawless References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tony Hain wrote: > Hallam-Baker, Phillip wrote: ... > >>The title of this thread implies that people believe that the >>IETF sets laws >>and has a right of veto over net use. The IETF is no >>difference in principle >>to any other open source type project, people can and do fork >>the code tree. >> > > I didn't even read the subject until you pointed it out, but the point > is not about what authority the IETF has over use of its writings. The > point is that the IETF is in control of the focus of the WGs and how > much time they spend trying to define duplicate solutions. Since I created the title, perhaps I should clarify. By 'law', I meant 'standard', as in 'protocol standard'. There are a set of such standards, a subset of the RFCs which have "STD" numbers, including 1122, 1123, 1812, etc. A combination of the IETF/IAB/IESG do determine what RFCs become STDs. The IETF does set laws, in the above sense. There is no authority about 'veto' over net use, but they have, as Tony points out, authority over whether to pass mutually conflicting 'laws' or create WGs to spend time doing so. Joe From owner-ipsec@lists.tislabs.com Mon Mar 4 10:30:48 2002 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 g24IUm808430; Mon, 4 Mar 2002 10:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24628 Mon, 4 Mar 2002 12:57:48 -0500 (EST) Date: Mon, 4 Mar 2002 10:08:02 -0800 (PST) From: Srinivasa Addepalli To: Henrik Levkowetz cc: "Chinna N.R. Pellacuru" , ipsec mailling list Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, MobileIP working group did lot of work in regards to NAT discovery and Traversal. We can use this work as basis to define discovery and traversal of NAT boxes in this working group OR see the possibility of using mobileIP work here. This will not require any changes to either IKE/IPSEC or no changes to NAT boxes. Mr Henrik is kind enough to offer his services to solve the problem with his expertise in mobileIP. I really would like to see some solution which solves the problem without any changes to IKE/IPSEC and NAT boxes. Regards Srini On Sat, 2 Mar 2002, Henrik Levkowetz wrote: > On Thursday, February 28, 2002 Chinna wrote: > ...... > > > > I would also like to extend the request to everyone (the veterans who can > > help us technically and also guide us through the IETF process, and > > frankly THE MORE THE MERRIER). Please join us if you want to help us. If > > you are skeptical of us due to the flame exchange, honestly, that's not > > our true nature. Please send me an email. > > > > Well, I'm taking you up on this; then we'll see if I end up hit > by a barrage of pies, eggs, tomatoes and whatnot from every direction... > > I've followed the discussions with respect to NAT traversal on the ipsec > mailing list during the last half year or so, while I've been working on > the current draft on NAT traversal for Mobile IP, and also implementing > NAT traversal for Mobile IP. > > It seems to me, viewing this discussion somewhat from the outside, that > in the matter of NAT traversal for IPsec you have as a group become the > victims of your own success. Let me explain what I mean; it is leading > somewhere: > > One goal in IPsec work would naturally be to have the protocols concerned > be as opaque and resistant as possible to both traffic and content analysis. > > One goal for NATs is to leverage extra information (in the form of port > addresses preferably) in order to make up for a scarcity of ip-addresses. > > So the more you succeed in making the communication opaque, the less there > is for NATs to work with. The (in this respect) straightforward solution to > accomplish NAT traversal is then to give NATs their favourite stuff to work > with: Port numbers. All ALGs (Application Layer Gateways) which are > added to NATs are there to take care of the protocols which do NOT give > the NATs port numbers to work with. They sometimes work, and sometimes > work well. > > The solution subdivides into (at least) two parts: Discovering if you are > behind a NAT, and doing something about it if you are. > > Chinna had a reference to an excellent draft which answers the first part > in a generic way: > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt > > The answer to the second part will have to consider the particular > requirements of the protocols which you want to get trough a NAT, but > if you would accept input from someone who's not of the IPsec community, > I'd be willing to pitch in. I don't believe the problem is too intractable. > > Best regards, > > Henrik > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon Mar 4 10:42:55 2002 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 g24Igt808677; Mon, 4 Mar 2002 10:42:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24760 Mon, 4 Mar 2002 13:06:55 -0500 (EST) Date: Mon, 4 Mar 2002 13:17:46 -0500 (EST) From: Henry Spencer To: "Chinna N.R. Pellacuru" cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > SPI is an IPsec parameter as opposed to IKE. In almost all implementations > the SPI space is managed by the IPsec implementation (if we divide IPsec > into IPsec implementation and IKE). Note that not all implementations support such a division. Some use the IKE daemon for general IPsec policy/management as well, in which case it may be assigning the SPIs. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 4 10:58:48 2002 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 g24Iwm808977; Mon, 4 Mar 2002 10:58:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24846 Mon, 4 Mar 2002 13:19:02 -0500 (EST) Message-Id: <4.3.2.7.2.20020304102532.05312ed8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Mar 2002 10:27:36 -0800 To: "Jayant Shukla" From: Mark Baugher Subject: RE: Towards closure on NAT traversal. Cc: "'Melinda Shore'" , , "'ark-gvb-x'" In-Reply-To: <000001c1c3a0$f246e280$0100a8c0@trlhpc1> References: <5.1.0.14.0.20020304093409.00aa0c70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >I think now we all agree that NAT traversal problem need to be solved. >However, at the San Diego meeting a gentleman from your company chimed, >"We will just wait for IPv6." I presume that is not your company policy >(anymore). Why do you expect that every company employee spouts company policy at every WG meeting at every IETF? You expect too much. > > I agree - I chair midcom and am working on additional approaches to >the > > problem. If you're arguing that the IPSec working group should figure >out > > how to get non-PASV FTP across NATs, that's just silly. > > > > Melinda > >In the end, somebody has to provide the full solution and that is all >customers care about. If it is all done at one place it is far more >attractive than a split solution. > >A split solution requires too many changes everywhere. People "might" >digest changes to IKE, IPsec, and NATs. However, if you start proposing >changes to applications as well, you will be in trouble as that would >inconvenience your customers a bit too much. > >That is why we are advocating a single solution and want to leave the >applications untouched. The fact that our solution does not require >changes to IKE or NATs, makes it more attractive. > >Also, figuring out how to get non-PASV FTP across NATs is not silly, but >it is important. That is how mirror ftp sites get updated. Because we >solve this problem, it has made several of our clients very happy. > >BTW, PORT mode usage accounts for over 77% of the users on Microsoft >site. > >Site statistics from Microsoft site (9:17 am 4 March 2002) > PASV : 249596 > PORT : 845979 > >Regards, >Jayant >www.trlokom.com From owner-ipsec@lists.tislabs.com Mon Mar 4 10:58:49 2002 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 g24Iwm808980; Mon, 4 Mar 2002 10:58:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24895 Mon, 4 Mar 2002 13:24:52 -0500 (EST) Date: Mon, 4 Mar 2002 10:35:23 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Henry Spencer wrote: > On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > > SPI is an IPsec parameter as opposed to IKE. In almost all implementations > > the SPI space is managed by the IPsec implementation (if we divide IPsec > > into IPsec implementation and IKE). > > Note that not all implementations support such a division. Some use the > IKE daemon for general IPsec policy/management as well, in which case it > may be assigning the SPIs. > In that case these implementations might have some inefficiencies if they want to use another or multiple key management protocols for IPsec. In any case who ever is doing the SPI management should honor the new semantics of the SPI. No bits on the wire are changed for IKE. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 11:16:29 2002 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 g24JGS809428; Mon, 4 Mar 2002 11:16:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25037 Mon, 4 Mar 2002 13:41:26 -0500 (EST) Date: Mon, 4 Mar 2002 10:52:22 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Henrik Levkowetz , ipsec mailling list Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > MobileIP working group did lot of work in regards to NAT discovery > and Traversal. We can use this work as basis to define discovery > and traversal of NAT boxes in this working group OR see the > possibility of using mobileIP work here. This will not require > any changes to either IKE/IPSEC or no changes to NAT boxes. You could do all this work in the Mobile IP group or you could do it in the midcom group who is chartered to help everyone with this. I don't see why this should be on the charter for the IPsec working group. > > Mr Henrik is kind enough to offer his services to solve the > problem with his expertise in mobileIP. I really would like to > see some solution which solves the problem without any changes > to IKE/IPSEC and NAT boxes. > A solution "without any changes to IKE/IPSEC and NAT boxes" would definitely be ideal. Please give the details if you have come up with such a solution, and we don't even have to have a "standard" for solving NAT IPsec problem, because nothing changes. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 11:19:25 2002 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 g24JJO809522; Mon, 4 Mar 2002 11:19:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25095 Mon, 4 Mar 2002 13:44:39 -0500 (EST) Date: Mon, 4 Mar 2002 10:54:57 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am not sure whether you can restrict the responder to choose its own SPI. Lot of implementations take advantage of SPI for faster lookups. This is possible if the IPSEC implementation is given chance to choose its own SPI without any limitation. There are some implementations which use all bits of SPI value for different functionalities within the device. Regards Srini On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > On Sun, 3 Mar 2002, Jayant Shukla wrote: > > > -----Original Message----- > > > On Behalf Of Chinna N.R. Pellacuru > > > > > > For our solution we do not require to even discover NAT. The SPIs can > > be > > > generated as a pair in all cases because this is such a simple > > operation. > > > If there are any NATs enroute, they will use this property to > > de-multiplex > > > the IPsec traffic and do IPsec pass-through. > > > > > > > So, you are suggesting modifications to IKE, right? > > > > This is interesting! According to your earlier e-mail, IKE modification > > for "NAT discovery" is not acceptable, but now IKE modification for "NAT > > traversal" is acceptable? > > > > SPI is an IPsec parameter as opposed to IKE. In almost all implementations > the SPI space is managed by the IPsec implementation (if we divide IPsec > into IPsec implementation and IKE). > > When a responder receives a bunch of Phase2 proposals in Quick mode, it'll > pick one proposal, and for that proposal it generates the SPI(s) which are > a hash of the initiator's SPI(s). In general, IKE will have to request > SPIs from the IPsec implementation because SPI is an IPsec parameter. > > We only propose to change the semantics of the SPI, IE., now incoming and > outgoing SPIs of an IPsec protocol (ESP or AH) can be paired. One of them > will be the hash of the other. Actually only half of one of them is a hash > of the other. The other half is still left free, to allow some flexibility > for implementations who want to do fancy things with SPI generation. > > No other change is required in IPsec or IKE. NAT implementation will use > this extra intelligence to translate ESP traffic. NAT can place the IPsec > SPIs in its translation table and pair the SPIs which belong to an IPsec > flow and demultiplex the incoming traffic. NAT also does NOT change > anything in either IKE or IPsec. NAT does a passive IPsec pass-through. > > Please let me know if you need more details. > > chinna > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon Mar 4 11:35:59 2002 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 g24JZx809957; Mon, 4 Mar 2002 11:35:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25312 Mon, 4 Mar 2002 13:59:50 -0500 (EST) Date: Mon, 4 Mar 2002 11:09:55 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Also think of Manual Key Managed IPSEC policies. SPIs are manually configured. Srini On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > On Sun, 3 Mar 2002, Jayant Shukla wrote: > > > -----Original Message----- > > > On Behalf Of Chinna N.R. Pellacuru > > > > > > For our solution we do not require to even discover NAT. The SPIs can > > be > > > generated as a pair in all cases because this is such a simple > > operation. > > > If there are any NATs enroute, they will use this property to > > de-multiplex > > > the IPsec traffic and do IPsec pass-through. > > > > > > > So, you are suggesting modifications to IKE, right? > > > > This is interesting! According to your earlier e-mail, IKE modification > > for "NAT discovery" is not acceptable, but now IKE modification for "NAT > > traversal" is acceptable? > > > > SPI is an IPsec parameter as opposed to IKE. In almost all implementations > the SPI space is managed by the IPsec implementation (if we divide IPsec > into IPsec implementation and IKE). > > When a responder receives a bunch of Phase2 proposals in Quick mode, it'll > pick one proposal, and for that proposal it generates the SPI(s) which are > a hash of the initiator's SPI(s). In general, IKE will have to request > SPIs from the IPsec implementation because SPI is an IPsec parameter. > > We only propose to change the semantics of the SPI, IE., now incoming and > outgoing SPIs of an IPsec protocol (ESP or AH) can be paired. One of them > will be the hash of the other. Actually only half of one of them is a hash > of the other. The other half is still left free, to allow some flexibility > for implementations who want to do fancy things with SPI generation. > > No other change is required in IPsec or IKE. NAT implementation will use > this extra intelligence to translate ESP traffic. NAT can place the IPsec > SPIs in its translation table and pair the SPIs which belong to an IPsec > flow and demultiplex the incoming traffic. NAT also does NOT change > anything in either IKE or IPsec. NAT does a passive IPsec pass-through. > > Please let me know if you need more details. > > chinna > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon Mar 4 11:44:31 2002 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 g24JiV810239; Mon, 4 Mar 2002 11:44:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25419 Mon, 4 Mar 2002 14:12:05 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , "Melinda Shore" , "Jayant Shukla" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Mon, 4 Mar 2002 11:22:46 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F40A9C1020@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > ... > To take IPSEC to the next level we need to make IPSEC work well enough > through a NAT that it can support SMTP client, HTTP client, > POP3 client, > IMAP client, NNTP client. We do not need to start addressing > problems that > have not been solved for NAT in general (and hacking up packets with > protocol sensitive modifications is not a solution). > ... > If people stopped complaining about how anti-social NATs are > and started > working out how we could socialize them into more acceptable modes of > behavior the degree of damage caused could be rendered tollerable. Note the problem set you listed above is limited to 'clients'. Since one endpoint in all those applications requires a 'server', and it appears that the set is limited to your particular view of the problem space, there will be complaints that NAT behavior is anti-social. The other point this simple statement misses are that not all NATs are created equal. A simple solution to the problem for one variant is unlikely to work for all. Rather than waste time trying to figure out the possible modes, look at http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-05.tx t. Then, rather than waste time trying to solve the problem in a specific way for IPsec, just reference it as the way to get past IPv4 NATs and use IPv6 as the end-to-end protocol. Tony From owner-ipsec@lists.tislabs.com Mon Mar 4 12:07:11 2002 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 g24K7A810656; Mon, 4 Mar 2002 12:07:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25607 Mon, 4 Mar 2002 14:30:21 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.52705.62875.604554@pkoning.dev.equallogic.com> Date: Mon, 4 Mar 2002 14:41:21 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <000101c1c347$d2511cb0$0100a8c0@trlhpc1> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> When a responder receives a bunch of Phase2 proposals in Chinna> Quick mode, it'll pick one proposal, and for that proposal it Chinna> generates the SPI(s) which are a hash of the initiator's Chinna> SPI(s). In general, IKE will have to request SPIs from the Chinna> IPsec implementation because SPI is an IPsec parameter. I'm not sure what you mean by "...are a hash of the initator's SPI(s)". In the existing IPsec/IKE the algorithm for choosing SPI values is unconstrained. You can certainly use a hash, but you don't have to. The implementation I once worked on did not use a hash at all. Chinna> We only propose to change the semantics of the SPI, IE., now Chinna> incoming and outgoing SPIs of an IPsec protocol (ESP or AH) Chinna> can be paired. One of them will be the hash of the Chinna> other. Actually only half of one of them is a hash of the Chinna> other. The other half is still left free, to allow some Chinna> flexibility for implementations who want to do fancy things Chinna> with SPI generation. That only works if you want IPsec gateways to be limited to 64k SA pairs. Also, if the SPI has 16 bits generated by hashing, you're likely to have duplicates in that field once you have more than 256 SA pairs (birthday rule). That seems like it would be a problem for NAT processing that relies on these hash fields being effective discriminators. I don't think this approach is workable... paul From owner-ipsec@lists.tislabs.com Mon Mar 4 12:12:41 2002 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 g24KCe810885; Mon, 4 Mar 2002 12:12:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25653 Mon, 4 Mar 2002 14:37:15 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A9C1087@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Tony Hain , "Hallam-Baker, Phillip" , Melinda Shore , Jayant Shukla , ipsec@lists.tislabs.com Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Mon, 4 Mar 2002 11:48:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C3B5.8EED5560" 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_000_01C1C3B5.8EED5560 Content-Type: text/plain; charset="iso-8859-1" I find it very difficult to understand the argument you appear to be trying to make. Wait for IPv6 is not an acceptable solution. If nothing is done until IPv6 is deployable the vendors will long since have taken their IPSEC standards business to another forum. You appear to be arguing that 1) The group should do nothing to accomodate NAT 2) The proposal to provide minimal accomodation of NAT is insufficient. So which is it? Both arguments may point to 'do nothing' but they are inconsistent. When I see that type of bifurcated argument being made I suspect that the true position is 'I don't want to accomodate NAT in any circumstance whatsoever but I will be opportunistic in my arguments'. NAT introduces some intrinsic problems with any protocol that opens up a listening port. IPSEC will inevitable screw up sone of the kludges and work-arrounds out in the wild. I don't think that is a problem, demand for IPSEC is much stronger than any of the protocols affected by the kludges that will be broken. The Internet may be about much more than client side HTTP and email, however if you are behind a NAT box that does not provide for a principled support for advertising a listening port to the NAT you should probably learn not to expect very much more. The problem is at that point outside IPSEC scope. IPv6 does not eliminate the need for NAT, in fact some companies will be deploying NAT to conceal leakage of ethernet MAC addresses and the like from their domain that people seem to want to encode into IPv6 addresses. One of the uses of NAT is to provide an auditable means of determining whether the trafic on a network segment is compliant with the routing policy or not and in particular whether there is an unauthorized bridge to an external network in operation. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C1C3B5.8EED5560 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C3B5.8EED5560-- From owner-ipsec@lists.tislabs.com Mon Mar 4 12:15:47 2002 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 g24KFk810962; Mon, 4 Mar 2002 12:15:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25714 Mon, 4 Mar 2002 14:40:16 -0500 (EST) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899B032414@01mail.nomadix.com> To: henry@spsystems.net, pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal Date: Mon, 4 Mar 2002 11:41:39 -0800 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 Just to clarify what Chinna was talking about was that as far as NAT is concerned the 2 traffic types - IKE and ESP are independent although the SPI exchange for ESP takes place via IKE. Since they are encrypted within IKE, NAT can mux/demux those connections independently. One problem NAT encounters is serializing of connections till both inbound and outbound SPIs are known to NAT. I am working for a company which lives on existence of such boxes. And one big drawback is NAT not knowing this information apriori or through a formula. I don't want to get into the debate of what is better - SPI magic formula or UDP encapsulation. This is for the research community to hash out. But NAT is not malicious and actually wants to facilitate IPsec connections through it for multiple users behind it. IKE itself is so unreliable that it just makes life hell for a programmer. We have tried so many implementations like floating source ports and cookie tracking, but interoperability and reliability is always an issue. Hopefully you guys can churn out something that is reliable and robust to make life easy for our friendly, n'hood NAT. -Bik > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 04, 2002 10:18 AM > To: Chinna N.R. Pellacuru > Cc: 'ipsec mailling list' > Subject: RE: NAT Traversal > > > On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > > SPI is an IPsec parameter as opposed to IKE. In almost all > implementations > > the SPI space is managed by the IPsec implementation (if we > divide IPsec > > into IPsec implementation and IKE). > > Note that not all implementations support such a division. > Some use the > IKE daemon for general IPsec policy/management as well, in > which case it > may be assigning the SPIs. > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Mar 4 12:26:23 2002 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 g24KQM811183; Mon, 4 Mar 2002 12:26:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25797 Mon, 4 Mar 2002 14:51:08 -0500 (EST) Date: Mon, 4 Mar 2002 22:02:38 +0200 Message-Id: <200203042002.WAA18244@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <200203041204.HAA20225@ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-ietf-ipsec-ikev2-01.txt References: <200203041204.HAA20225@ietf.org> 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 My comment about Traffic Selector Payload... ..basic idea is acceptable, if it is also understood that it specifies the values for the negotiated SAs (into SAD). It has nothing to do with the policy selectors in SPD. However, I cannot find a way to specify information concerning both source and destination (ports and addresses). This required. To clarify, and example, I can have a policy selector remote-port = 25 -> "protection suite" The "protection suite" could be 1) all connections the same host use the same SA's (sharing), then the traffic selector payload will need contain following info protocol ID = TCP remote-start-port = 25 remote-end-port = 25 local-start-port = 0 local-start-port = 65535 I suppose I don't need to specify any addresses in this case, as they are implicit from the phase 1. Unless either or both host is multihomed, and SA's are to be limited to specific addresses. 2) each connection will have own SA's, traffic selector will be protocol ID = TCP remote-start-port = 25 remote-end-port = 25 local-start-port = 'x' local-end-port = 'x' where 'x' is the local port chosen for the particular connection. Another example: I want all TCP connections to a specified destination to be protected, e.g. policy selector protocol = TCP, dest='d' -> "require own SA for each connection" the traffic selector will be protocol ID = TCP remote-start-port = 'x' remote-end-port = 'x' local-start-port = 'y' local-end-port = 'y' dest-address = 'd' where 'x' and 'y' the ports chosen for the particular TCP connection. If I want to share the same SA with all TCP, then traffic selector becomes protocol ID = TCP remote-start-port = 0 remote-end-port = 65535 local-start-port = 0 local-end-port = 65535 dest-address = 'd' Note, that the *SPD policy selector* doesn't change! WHat does change in policy, is the SA requirements. From owner-ipsec@lists.tislabs.com Mon Mar 4 13:02:37 2002 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 g24L2b812444; Mon, 4 Mar 2002 13:02:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26004 Mon, 4 Mar 2002 15:20:12 -0500 (EST) Date: Mon, 4 Mar 2002 12:31:06 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > Also think of Manual Key Managed IPSEC policies. SPIs are manually > configured. > And, why can't manually configured SPIs follow the new semantics? chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 13:17:35 2002 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 g24LHY812832; Mon, 4 Mar 2002 13:17:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26121 Mon, 4 Mar 2002 15:38:06 -0500 (EST) Date: Mon, 4 Mar 2002 12:49:03 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15491.52705.62875.604554@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> When a responder receives a bunch of Phase2 proposals in > Chinna> Quick mode, it'll pick one proposal, and for that proposal it > Chinna> generates the SPI(s) which are a hash of the initiator's > Chinna> SPI(s). In general, IKE will have to request SPIs from the > Chinna> IPsec implementation because SPI is an IPsec parameter. > > I'm not sure what you mean by "...are a hash of the initator's > SPI(s)". In the existing IPsec/IKE the algorithm for choosing SPI > values is unconstrained. You can certainly use a hash, but you don't > have to. The implementation I once worked on did not use a hash at > all. Yes, this is adding new semantics to the SPIs so that NAT can find out which SPIs are a pair. > > Chinna> We only propose to change the semantics of the SPI, IE., now > Chinna> incoming and outgoing SPIs of an IPsec protocol (ESP or AH) > Chinna> can be paired. One of them will be the hash of the > Chinna> other. Actually only half of one of them is a hash of the > Chinna> other. The other half is still left free, to allow some > Chinna> flexibility for implementations who want to do fancy things > Chinna> with SPI generation. > > That only works if you want IPsec gateways to be limited to 64k SA > pairs. Also, if the SPI has 16 bits generated by hashing, you're > likely to have duplicates in that field once you have more than 256 SA > pairs (birthday rule). That seems like it would be a problem for NAT > processing that relies on these hash fields being effective > discriminators. > > I don't think this approach is workable... > The actual working of this technique in NAT is much more complicated than what you describe above. This will require for you to understand how NAT works more. We have 16 bits in the responder's SPI for a hash of the initiator's SPI and we have 16 bits that don't have any constraints. Let's assume that the unspecified 16 bits are filled randomly. When a NAT tries to translate the ESP traffic based on matching the SPI in the above scheme, it maintains these SPIs in its translation table. When there is some outgoing ESP traffic that NAT sees, which has a SPI that NAT has never seen before, it will create an entry in its translation table, which is incomplete. When there is some incoming ESP traffic with a SPI that NAT hasn't seen before, it will try to match the incoming SPI to any of the SPIs in the *incomplete* translations only within its translation table. If there is a match, the translation is completed. If there is no match the traffic is dropped. In this context, a collision happens when we are trying to find out which of the incomplete translations corresponds to the incoming SPI. Once a translation is made, the new incoming SPIs don't have to be matched with the already completed translations. So the probability of a collision is very low, and also a collison can only happen among the incomplete translations. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 13:17:53 2002 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 g24LHq812848; Mon, 4 Mar 2002 13:17:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26135 Mon, 4 Mar 2002 15:41:39 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Tero Kivinen'" , "Andrew Krywaniuk" Cc: Subject: RE: draft-ietf-ipsec-ikev2-01.txt Date: Mon, 4 Mar 2002 15:45:22 -0500 Message-ID: <004501c1c3bd$81f077e0$1e72788a@ca.alcatel.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 In-Reply-To: <15490.9405.810075.114327@ryijy.hel.fi.ssh.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay, so the bottom line is that we both agree that this should be a MAY and not a SHOULD. Do people on the list object to this change in requirements language? > I.e you need to process all packets, and you need to start as many > partial exchanges, to do that you want to do that only if you have > spare time. Also it should be done in a way that if you detect this > kind of problem you only first gather some time for possible response > packets and then start processing them in random order. If you happen > to hit timeout before you can process all packets then you try again > with new exchange and this time you propably take different cookies > where you respond, meaning that the propablity of succeeding is 1 / > (number of attacker packets ) * (number of packets per second you can > process * timeout in seconds). If the attacker is sending 10000 > packets, you can process 50 packets per second and the timeout is 30 > seconds, the propability is 15%. If an implementation chooses to use this feature, I think it's an implementation detail what exact algorithm they use. I think the only advice we really need to give them is to (a) give priority to SAs on which you don't detect this attack, and (b) don't attempt to store all the packets and process them sequentially (e.g. randomly drop x% of the packets). Also, should the initiator retransmit the first packet more frequently in this case? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tero Kivinen > Sent: Sunday, March 03, 2002 8:27 AM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ikev2-01.txt > > > Andrew Krywaniuk writes: > > It is easy to write software to check if someone is > spoofing your IP from > > your own LAN if you're so inclined, although I suppose they could be > > silently listening on the LAN, forwarding the cookies to > another location > > and spoofing the responses from there. > > Because as you say it is easy to stop the machine that actually > does something nasty and is along the path, but it is very hard to > detect the machine that only listens and send the information need to > launch the attack to another host(s). > > > > Sending faked packet can be done from completely different host > > > (some hacked machine out there in Elboinia), and from different > > > machine every time. This way finding the attackers > listening post is > > > much harder, and he can continue the attack much longer. > > I'm not including those cases because we're talking about > attacks against > > the initiator here. The adversary has to be on the data > path in order to > > learn the initiator's cookie. > > I am very concern about attacks that are very hard to block and very > hard to find who is doing it. I was mostly talking about this kind of > listening post + sending info to somewhere else attack. > > > Well, the new draft of IKEv2 seems to imply that this is > the expected > > behaviour of the initiator (a SHOULD). I have no problems > with it being a > > MAY, but I don't think this should be the default > behaviour. You are merely > > trading one DoS attack for another. > > I agree that it should be MAY instead of SHOULD. And perhaps we need > to add more text about the how this is done. > > I.e you need to process all packets, and you need to start as many > partial exchanges, to do that you want to do that only if you have > spare time. Also it should be done in a way that if you detect this > kind of problem you only first gather some time for possible response > packets and then start processing them in random order. If you happen > to hit timeout before you can process all packets then you try again > with new exchange and this time you propably take different cookies > where you respond, meaning that the propablity of succeeding is 1 / > (number of attacker packets ) * (number of packets per second you can > process * timeout in seconds). If the attacker is sending 10000 > packets, you can process 50 packets per second and the timeout is 30 > seconds, the propability is 15%. > > > Let's face it. Most machines out there aren't > ultra-reliable under load. So > > unless you're ultra-confident about your robustness, you > shouldn't try to > > outlast a DoS attack. Also, if you're being swamped with > bogus replies then > > chances are you are dropping some packets. If so, you might > as well drop the > > packets that are 99% likely to be spoofed and focus on > giving good QoS to > > the rest of your flows. If you have some spare cycles, you > can try to > > process some of the spoofed packets in the hope that it > really is Bob. Keep > > in mind that Alice is not necessarily a user sitting in front of the > > computer who has the ability to abort the connection in real time. > > Lets put it this way. Not all implementations are going to do it, but > I think the protocol should not make it impossible to try to do it. It > is then only implementation detail how it is done, if done at all. > > > I just noticed that with IKEv2 you can avoid this attack > against the gateway > > in a client to gateway scenario (the original responder can > take advantage > > of IKEv2's ability to rekey under the protection of the > original phase 1), > > which is good. > > True. This is the kind of things I am looking for. Things that do not > complicate things but makes it possible to have some kind of > protection against DoS. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Mon Mar 4 13:28:36 2002 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 g24LSZ813050; Mon, 4 Mar 2002 13:28:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26217 Mon, 4 Mar 2002 15:55:03 -0500 (EST) Date: Mon, 4 Mar 2002 13:05:59 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > On Mon, 4 Mar 2002, Paul Koning wrote: > > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > Chinna> When a responder receives a bunch of Phase2 proposals in > > Chinna> Quick mode, it'll pick one proposal, and for that proposal it > > Chinna> generates the SPI(s) which are a hash of the initiator's > > Chinna> SPI(s). In general, IKE will have to request SPIs from the > > Chinna> IPsec implementation because SPI is an IPsec parameter. > > > > I'm not sure what you mean by "...are a hash of the initator's > > SPI(s)". In the existing IPsec/IKE the algorithm for choosing SPI > > values is unconstrained. You can certainly use a hash, but you don't > > have to. The implementation I once worked on did not use a hash at > > all. > > Yes, this is adding new semantics to the SPIs so that NAT can find out > which SPIs are a pair. > > > > > Chinna> We only propose to change the semantics of the SPI, IE., now > > Chinna> incoming and outgoing SPIs of an IPsec protocol (ESP or AH) > > Chinna> can be paired. One of them will be the hash of the > > Chinna> other. Actually only half of one of them is a hash of the > > Chinna> other. The other half is still left free, to allow some > > Chinna> flexibility for implementations who want to do fancy things > > Chinna> with SPI generation. > > > > That only works if you want IPsec gateways to be limited to 64k SA > > pairs. Also, if the SPI has 16 bits generated by hashing, you're > > likely to have duplicates in that field once you have more than 256 SA > > pairs (birthday rule). That seems like it would be a problem for NAT > > processing that relies on these hash fields being effective > > discriminators. > > > > I don't think this approach is workable... > > > > The actual working of this technique in NAT is much more complicated than > what you describe above. This will require for you to understand how NAT > works more. We have 16 bits in the responder's SPI for a hash of the > initiator's SPI and we have 16 bits that don't have any constraints. Let's > assume that the unspecified 16 bits are filled randomly. > > When a NAT tries to translate the ESP traffic based on matching the SPI in > the above scheme, it maintains these SPIs in its translation table. When > there is some outgoing ESP traffic that NAT sees, which has a SPI that NAT > has never seen before, it will create an entry in its translation table, > which is incomplete. When there is some incoming ESP traffic with a SPI > that NAT hasn't seen before, it will try to match the incoming SPI to any > of the SPIs in the *incomplete* translations only within its translation > table. If there is a match, the translation is completed. If there is no > match the traffic is dropped. In this context, a collision happens when > we are trying to find out which of the incomplete translations corresponds > to the incoming SPI. Once a translation is made, the new incoming SPIs > don't have to be matched with the already completed translations. So the > probability of a collision is very low, and also a collison can only > happen among the incomplete translations. > And considering the fact that an IPsec SA is identified by the tuple: Destination, Protocol and SPI, the probability of a collision is even lower, and for all practical purposes zero. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 13:43:55 2002 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 g24Lhs813549; Mon, 4 Mar 2002 13:43:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26195 Mon, 4 Mar 2002 15:53:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40A9C0E06@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F40A9C0E06@vhqpostal.verisign.com> Date: Mon, 4 Mar 2002 15:55:35 -0500 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: NAT support and laws for the lawless Cc: Joe Touch , "Hallam-Baker, Phillip" , ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:59 PM -0800 3/1/02, Hallam-Baker, Phillip wrote: > > Hallam-Baker, Phillip wrote: >> > People appear to be so caught up in whether we should be >> supporting NAT that >> > the issue of how to support NAT is forgotten about. >> >> Agreed. However, at some point we're writing laws for the >> lawless. NATs >> exist only by breaking what few real standards we've had in the >> Internet. Writing standards for the rest of us to traverse a moving, >> lawless target is not necessarily productive, IMO. > >Most of the NAT vendors are engaged in IETF and have shown wilingness to >comply with IETF standards, provided they allow them to get their job done. > >NAT has an important security role. We deploy it because our customers want >to conceal their IP addresses against traffic analysis. > >Given that in the original Internet design IP was just the protocol run on >the 'network of networks' I don't think that the claims that NAT is foreign >to the Internet is valid. NAT appears to me to be part and parcel of the >original concept. As one of the folks who was around when "the original concept" was developed, I can emphatically say that NAT is not consistent with that model. The reason is that IP was designed to run over any underlying network layer protocol, and across layer 3 gateways, but it was assumed to provide end-to-end service for realtime communication. There were no firewalls back then and TCP and UDP were intended to operate in end systems only. Note that one of the problems associated with NAT in the IPsec context arises because the TCP checksum includes the addresses from the IP header. This was not one of our better protocol design decisions, but it obviously would not have been made if there were any thought that an intermediate system would modify these addresses. Also, I have to question the purported traffic analysis security you cite for NAT. Since it is probably fair to assume that very little traffic sent through NAt devices is layer 3 encrypted, and since higher layer security protocols usually provide lots of info suitable for TA (e.g., SSL thoughtfully sends server and, optionally, client, certs in the clear) it's hard to argue that NAT provide an effective form of TFS. Steve From owner-ipsec@lists.tislabs.com Mon Mar 4 13:56:28 2002 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 g24LuR813882; Mon, 4 Mar 2002 13:56:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26338 Mon, 4 Mar 2002 16:16:59 -0500 (EST) Message-Id: <200203042127.g24LRZUZ011267@ack.east.sun.com> From: Bill Sommerfeld To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: Re: DoS attack on JFK In-Reply-To: Your message of "Sun, 03 Mar 2002 23:08:38 PST." <200203040708.g2478cp01450@fatty.lounge.org> Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Mar 2002 16:27:35 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, this attack is not without risk for the attacker -- someone monitoring the system under attack can correlate the inbound flood of message #3 with the source address of the previous message #1's and use this to trace the attack back to the coordinator. Provided that g^r on the Nth message two is the same as the g^r on the first message two the attacker knows that all the authenticator blobs are all signed by the current HKr. If the first and last g^r differ then the attacker starts the attack over. My understanding was that a JFK implementation could have a pool of precomputed g^r values to pick from rather than a single "current" g^r, so this exact method wouldn't work (since each g^r would likely differ from message to message). However, it's relatively easy to modify the attack to compensate for this. [... if the initiator ip address is included in the HMAC ...] the responder could make note of an unsuccessful decryption from a particular IP address and refuse any more messages from it for a period of time. Yah, this would work, but a responder could also blacklist "Ni,Nr" pairs or HMAC values; that might be a more effective strategy than blacklisting by source address -- with IPv6, an attacker on a link which does stateless address autoconfig has access to on the order of 2^64 usable source addresses; and even with ipv4, an attacker might have access to many valid addresses. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 4 14:09:01 2002 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 g24M90814211; Mon, 4 Mar 2002 14:09:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26471 Mon, 4 Mar 2002 16:35:32 -0500 (EST) Date: Mon, 4 Mar 2002 13:46:25 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > I am not sure whether you can restrict the responder to choose > its own SPI. Lot of implementations take advantage of SPI > for faster lookups. This is possible if the IPSEC implementation > is given chance to choose its own SPI without any limitation. > There are some implementations which use all bits of SPI value > for different functionalities within the device. We only place a restriction on half of the SPI for this reason only. We want the other half to be unresticted for implemenations to still have some flexibility with picking a SPI for whatever fancy scheme they have. You should also honor what RFC 2401 says "SAD is indexed by a destination IP address, IPsec protocol type, and SPI. o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] We will be reducing this un-restricted SPI space from 32 bits to 16 bits, because the other 16 bits are generated based on the SPI that the peer has picked. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 14:09:22 2002 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 g24M9L814224; Mon, 4 Mar 2002 14:09:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26455 Mon, 4 Mar 2002 16:33:05 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , "Melinda Shore" , "Jayant Shukla" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Mon, 4 Mar 2002 13:43:46 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F40A9C1087@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > Wait for IPv6 is not an acceptable solution. If nothing is > done until IPv6 > is deployable the vendors will long since have taken their > IPSEC standards > business to another forum. I am simply pointing out that IPv6 will be there well before this group can figure out a solution that works with the deployed NATs, agree on all the details, implement them, and deploy. In some parts of the world IPv6 is being deployed today, so just because you don't see it happening in your area is no reason to take the toys to another forum. > > You appear to be arguing that > 1) The group should do nothing to accomodate NAT > 2) The proposal to provide minimal accomodation of NAT is > insufficient. > > So which is it? Both arguments may point to 'do nothing' but they are > inconsistent. When I see that type of bifurcated argument being made I > suspect that the true position is 'I don't want to accomodate > NAT in any > circumstance whatsoever but I will be opportunistic in my arguments'. Try; the set of applications to be addressed (all client side) is inadequate, and this group should give requirements to MidCom for IPv4 capabilities, but otherwise rely on IPv6. Wasting time in yet another WG on figuring out how to work around NAT is a bad idea, so the IESG should revisit the IPsec WG charter. > > NAT introduces some intrinsic problems with any protocol that > opens up a > listening port. IPSEC will inevitable screw up sone of the kludges and > work-arrounds out in the wild. I don't think that is a > problem, demand for > IPSEC is much stronger than any of the protocols affected by > the kludges > that will be broken. If demand for IPsec is really that strong, why are people still putting in NATs when they know that it will be broken? If people really want IPsec they can still get IPv4 addresses. Yes we need IPsec, and yes we need to live in a world with IPv4 NAT, but those two requirements don't mean the IPsec WG needs to be wasting time figuring out how to get IPsec through a NAT. MidCom is working on a generic solution to the problem for IPv4, and using IPv6 to push the entire IPv4/NAT mess down a layer gives you a cleaner way out. > > The Internet may be about much more than client side HTTP and > email, however > if you are behind a NAT box that does not provide for a > principled support > for advertising a listening port to the NAT you should > probably learn not to > expect very much more. The problem is at that point outside > IPSEC scope. > I am sorry, I thought this discussion was about traversing NAT to make IPsec work. So it is really about how to do the easy half (and a small subset of that), maybe it should be titled 'the client side of a few applications NAT traversal'. > > IPv6 does not eliminate the need for NAT, in fact some > companies will be > deploying NAT to conceal leakage of ethernet MAC addresses > and the like from > their domain that people seem to want to encode into IPv6 addresses. And clearly the consultants that lead them there need to be fired. There is no requirement to encode MAC addresses, it is simply suggested as a simple way to get a number that should be unique. If people were keeping up rather than nay-saying IPv6 they would have noticed that RFC 3041 addresses that specific issue in a much cleaner way than NAT, and it even works without modifications to IPsec. > > One of the uses of NAT is to provide an auditable means of determining > whether the trafic on a network segment is compliant with the > routing policy > or not and in particular whether there is an unauthorized bridge to an > external network in operation. Clearly the network manager in this case doesn't understand the reality of NAT. If that unauthorized bridge were operating behind an unauthorized NAT that had an allowed address, the ability to detect it would fail. Further if that unauthorized NAT from time-to-time changed it's MAC and used DHCP (or better gratuitous arp to detect unassigned addresses), there would be no easy way to track it down. Tony From owner-ipsec@lists.tislabs.com Mon Mar 4 14:21:09 2002 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 g24ML9814633; Mon, 4 Mar 2002 14:21:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26550 Mon, 4 Mar 2002 16:44:10 -0500 (EST) Message-Id: <200203042154.g24LsdUZ011315@ack.east.sun.com> From: Bill Sommerfeld To: "Chinna N.R. Pellacuru" cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: Your message of "Mon, 04 Mar 2002 12:49:03 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Mar 2002 16:54:39 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "responder SPI as a hash of the initiator's SPI"? Which initiator? phase 1 initiator? phase 2 initiator? When a rekey occurs, the initiator and responder roles can be swapped. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 4 14:24:00 2002 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 g24MNx814726; Mon, 4 Mar 2002 14:23:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26603 Mon, 4 Mar 2002 16:49:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.61081.840848.291447@pkoning.dev.equallogic.com> Date: Mon, 4 Mar 2002 17:00:57 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: >> Also think of Manual Key Managed IPSEC policies. SPIs are manually >> configured. Chinna> And, why can't manually configured SPIs follow the new Chinna> semantics? Because users aren't about to do a hash calculation when they are asked what SPI values they want? The more I look at the feedback the more I get the impression that this proposal is all hole. paul From owner-ipsec@lists.tislabs.com Mon Mar 4 14:26:34 2002 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 g24MQX814784; Mon, 4 Mar 2002 14:26:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26622 Mon, 4 Mar 2002 16:54:33 -0500 (EST) Date: Mon, 4 Mar 2002 14:05:28 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Bill Sommerfeld cc: Paul Koning , Subject: Re: NAT Traversal In-Reply-To: <200203042154.g24LsdUZ011315@ack.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Bill Sommerfeld wrote: > "responder SPI as a hash of the initiator's SPI"? > > Which initiator? phase 1 initiator? phase 2 initiator? > > When a rekey occurs, the initiator and responder roles can be swapped. > Yes, good point. We are referring to the phase2 initiator. The NAT device need not know which SPI is the initiator SPI and which one is the responder SPI though. When a NAT device has a pair of SPIs that it needs to see whether they belong to a pair, it has to see for the relation both ways. So, if we have SPI1 and SPI2, the NAT box will try to see if the hash of SPI1 is equal to the half of SPI2, or the hash of SPI2 is equal to the half of SPI1. Both of these result in a match. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 14:37:46 2002 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 g24Mbj815107; Mon, 4 Mar 2002 14:37:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26660 Mon, 4 Mar 2002 17:01:04 -0500 (EST) Date: Mon, 4 Mar 2002 14:12:00 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15491.61081.840848.291447@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > >> Also think of Manual Key Managed IPSEC policies. SPIs are manually > >> configured. > > Chinna> And, why can't manually configured SPIs follow the new > Chinna> semantics? > > Because users aren't about to do a hash calculation when they are > asked what SPI values they want? Too bad for them, they can't get through NAT. > > The more I look at the feedback the more I get the impression that > this proposal is all hole. > It's not impossible to get manual keying working through our scheme, and how important is manual keying to this discussion? So, do you have a solution that is not "all hole"? If you think you have one, then please give out the details, and the rest of us will try to see if it is really not "all hole". In any solution there are tradeoffs. We would have debate whether a tradeoff is sensible, and whether the downside is prohibitive. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 14:37:58 2002 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 g24Mbw815125; Mon, 4 Mar 2002 14:37:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26670 Mon, 4 Mar 2002 17:01:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 17:05:41 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:46 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: >On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: >> I am not sure whether you can restrict the responder to choose >> its own SPI. Lot of implementations take advantage of SPI >> for faster lookups. This is possible if the IPSEC implementation >> is given chance to choose its own SPI without any limitation. >> There are some implementations which use all bits of SPI value >> for different functionalities within the device. > >We only place a restriction on half of the SPI for this reason only. We >want the other half to be unresticted for implemenations to still have >some flexibility with picking a SPI for whatever fancy scheme they have. > >You should also honor what RFC 2401 says "SAD is indexed by a destination >IP address, IPsec protocol type, and SPI. > > o SPI: the 32-bit value used to distinguish among different > SAs terminating at the same destination and using the same > IPsec protocol. > [REQUIRED for all implementations] > >We will be reducing this un-restricted SPI space from 32 bits to 16 bits, >because the other 16 bits are generated based on the SPI that the peer has >picked. > > chinna Chinna, Just a few notes re this discussion: - the revised ESP/AH documents emphasize that an IPsec implementation need not use the protocol type for SPI differentiation. so, if one starts assuming this is true, it will be yet another conflict with the IPsec specs - similarly, an IPsec implementation does not need to use the dest IP address as part of the SPI lookup, unless that address is for a multicast group. - do I understand correctly that you are suggesting a change to the specs to reduce the effective SPI space by a factor of 65K? is everyone comfortable with this? Steve From owner-ipsec@lists.tislabs.com Mon Mar 4 14:45:05 2002 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 g24Mj4815333; Mon, 4 Mar 2002 14:45:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26767 Mon, 4 Mar 2002 17:10:25 -0500 (EST) Date: Mon, 4 Mar 2002 14:21:17 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Stephen Kent wrote: > At 1:46 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: > >On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > >> I am not sure whether you can restrict the responder to choose > >> its own SPI. Lot of implementations take advantage of SPI > >> for faster lookups. This is possible if the IPSEC implementation > >> is given chance to choose its own SPI without any limitation. > >> There are some implementations which use all bits of SPI value > >> for different functionalities within the device. > > > >We only place a restriction on half of the SPI for this reason only. We > >want the other half to be unresticted for implemenations to still have > >some flexibility with picking a SPI for whatever fancy scheme they have. > > > >You should also honor what RFC 2401 says "SAD is indexed by a destination > >IP address, IPsec protocol type, and SPI. > > > > o SPI: the 32-bit value used to distinguish among different > > SAs terminating at the same destination and using the same > > IPsec protocol. > > [REQUIRED for all implementations] > > > >We will be reducing this un-restricted SPI space from 32 bits to 16 bits, > >because the other 16 bits are generated based on the SPI that the peer has > >picked. > > > > chinna > > Chinna, > > Just a few notes re this discussion: > > - the revised ESP/AH documents emphasize that an IPsec > implementation need not use the protocol type for SPI > differentiation. so, if one starts assuming this is true, it will be > yet another conflict with the IPsec specs Curious what are the reasons for removing this restriction, and what are the cons of still reqiring that this restriction apply. > > - similarly, an IPsec implementation does not need to use the > dest IP address as part of the SPI lookup, unless that address is for > a multicast group. > Here also, curious why that it is not required anymore to have dest IP address as part of SPI lookup. > - do I understand correctly that you are suggesting a change > to the specs to reduce the effective SPI space by a factor of 65K? > is everyone comfortable with this? > > Steve > I am suggesting that the original concept of IPsec SA being identified by a tuple: destination IP, protocol, SPI be required, and within the SPI add new semantics for picking a SPI on the phase2 responder. thanks, chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 14:45:27 2002 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 g24MjQ815356; Mon, 4 Mar 2002 14:45:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26754 Mon, 4 Mar 2002 17:09:19 -0500 (EST) To: Stephen Kent Cc: "Chinna N.R. Pellacuru" , Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" From: Derek Atkins Subject: Re: NAT Traversal References: Date: 04 Mar 2002 17:20:16 -0500 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > - do I understand correctly that you are suggesting a change > to the specs to reduce the effective SPI space by a factor of 65K? is > everyone comfortable with this? I'm not. I already thought that 32bits was too small. > Steve -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 4 14:45:36 2002 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 g24MjZ815371; Mon, 4 Mar 2002 14:45:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26775 Mon, 4 Mar 2002 17:10:53 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Bill Sommerfeld , Paul Koning , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 04 Mar 2002 17:22:19 -0500 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > The NAT device need not know which SPI is the initiator SPI and which one > is the responder SPI though. When a NAT device has a pair of SPIs that it > needs to see whether they belong to a pair, it has to see for the relation > both ways. So, if we have SPI1 and SPI2, the NAT box will try to see if > the hash of SPI1 is equal to the half of SPI2, or the hash of SPI2 is > equal to the half of SPI1. Both of these result in a match. What do you do if you find multiple matches? Unfortunately this case can happen with a non-zero probablility due to your limiting the space to a 16-bit by 16-bit comparison. > chinna -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 4 14:48:45 2002 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 g24Mmj815488; Mon, 4 Mar 2002 14:48:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26808 Mon, 4 Mar 2002 17:12:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.62462.899549.242738@pkoning.dev.equallogic.com> Date: Mon, 4 Mar 2002 17:23:58 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15491.52705.62875.604554@pkoning.dev.equallogic.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On Mon, 4 Mar 2002, Paul Koning wrote: Chinna> We only propose to change the semantics of the SPI, IE., now Chinna> incoming and outgoing SPIs of an IPsec protocol (ESP or AH) Chinna> can be paired. One of them will be the hash of the Chinna> other. Actually only half of one of them is a hash of the Chinna> other. The other half is still left free, to allow some Chinna> flexibility for implementations who want to do fancy things Chinna> with SPI generation. >> That only works if you want IPsec gateways to be limited to 64k >> SA pairs. Also, if the SPI has 16 bits generated by hashing, >> you're likely to have duplicates in that field once you have more >> than 256 SA pairs (birthday rule). That seems like it would be a >> problem for NAT processing that relies on these hash fields being >> effective discriminators. >> >> I don't think this approach is workable... >> Chinna> The actual working of this technique in NAT is much more Chinna> complicated than what you describe above. This will require Chinna> for you to understand how NAT works more. We have 16 bits in Chinna> the responder's SPI for a hash of the initiator's SPI and we Chinna> have 16 bits that don't have any constraints. Let's assume Chinna> that the unspecified 16 bits are filled randomly. Let's assume instead that the "unspecified" 16 bits are an index, used by the ESP implementation to index into a vector of inbound SAs. That's a max of 64k SAs. That's a reasonably large number but not a large enough number. You didn't answer this objection -- do you propose that the scheme should work only for IPsec gateways that support fewer than 64k SA pairs? Chinna> When a NAT tries to translate the ESP traffic based on Chinna> matching the SPI in the above scheme, it maintains these SPIs Chinna> in its translation table. When there is some outgoing ESP Chinna> traffic that NAT sees, which has a SPI that NAT has never Chinna> seen before, it will create an entry in its translation Chinna> table, which is incomplete. When there is some incoming ESP Chinna> traffic with a SPI that NAT hasn't seen before, it will try Chinna> to match the incoming SPI to any of the SPIs in the Chinna> *incomplete* translations only within its translation Chinna> table. If there is a match, the translation is completed. If Chinna> there is no match the traffic is dropped. In this context, a Chinna> collision happens when we are trying to find out which of the Chinna> incomplete translations corresponds to the incoming SPI. Once Chinna> a translation is made, the new incoming SPIs don't have to be Chinna> matched with the already completed translations. So the Chinna> probability of a collision is very low, and also a collison Chinna> can only happen among the incomplete translations. Now consider the "monday morning" case where lots of new SAs are being established around the same time. You have 256 or so "incomplete translations" at some point. That gives a 0.5 probability of duplicate hash. So I don't think your claim that the probability of a collision is "very low" is necessarily valid. Now for those two SAs that have the same hash, you can't unambiguously find the opposite direction SA because there are two candidates. What do you do then? paul From owner-ipsec@lists.tislabs.com Mon Mar 4 14:50:25 2002 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 g24MoO815568; Mon, 4 Mar 2002 14:50:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26849 Mon, 4 Mar 2002 17:17:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.62739.203933.991923@pkoning.dev.equallogic.com> Date: Mon, 4 Mar 2002 17:28:35 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> And considering the fact that an IPsec SA is identified by Chinna> the tuple: Destination, Protocol and SPI, the probability of Chinna> a collision is even lower, and for all practical purposes Chinna> zero. But we're talking about NAT. NAT hides addresses behind it and makes everything look like a single address. So in the context of NAT (at the other end) you have lots of SAs from the same address, and of course the protocol is constant (50). paul From owner-ipsec@lists.tislabs.com Mon Mar 4 14:51:19 2002 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 g24MpJ815629; Mon, 4 Mar 2002 14:51:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26854 Mon, 4 Mar 2002 17:17:43 -0500 (EST) Date: Mon, 4 Mar 2002 14:28:03 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Bill Sommerfeld , Paul Koning , Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 4 Mar 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > The NAT device need not know which SPI is the initiator SPI and which one > > is the responder SPI though. When a NAT device has a pair of SPIs that it > > needs to see whether they belong to a pair, it has to see for the relation > > both ways. So, if we have SPI1 and SPI2, the NAT box will try to see if > > the hash of SPI1 is equal to the half of SPI2, or the hash of SPI2 is > > equal to the half of SPI1. Both of these result in a match. > > What do you do if you find multiple matches? Unfortunately this case > can happen with a non-zero probablility due to your limiting the space > to a 16-bit by 16-bit comparison. > Let's take a case in which you think will have the highest probability of this happening, and then we can come up with a resonable estimate of the probability of that happening. It is hard to come up with the probability of this happening in general for all case and all scenarios. So, let's take the worst case (atleast what we think is the worst case), and analyse the probabilities. I agree that the probability is non-zero. When this happens, we would have to drop the traffic. NAT itself is not a very deterministic process, and so we should be willing to have some non-determinism in the total solution. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 14:51:39 2002 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 g24Mpc815651; Mon, 4 Mar 2002 14:51:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26814 Mon, 4 Mar 2002 17:13:54 -0500 (EST) Message-Id: <200203042223.g24MN6UZ011365@ack.east.sun.com> From: Bill Sommerfeld To: Stephen Kent cc: "Chinna N.R. Pellacuru" , Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: Re: NAT Traversal In-Reply-To: Your message of "Mon, 04 Mar 2002 17:05:41 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Mar 2002 17:23:06 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - do I understand correctly that you are suggesting a change > to the specs to reduce the effective SPI space by a factor of 65K? > is everyone comfortable with this? I, for one, am not. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 4 14:55:53 2002 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 g24Mtr815821; Mon, 4 Mar 2002 14:55:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26889 Mon, 4 Mar 2002 17:22:15 -0500 (EST) Date: Mon, 4 Mar 2002 14:32:48 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > > Also think of Manual Key Managed IPSEC policies. SPIs are manually > > configured. > > > > And, why can't manually configured SPIs follow the new semantics? > > chinna Both IKE and manual key management exist on the same device. Typically, to make the management and configuration easy, devices restrict the SPIs to be in some range for MKM policies, so that there will not be any conflict on SPIs chosen for IKE based SPD policies and MKM based SPD policies. Though this is not a strong argument, it might make configuration difficult. > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon Mar 4 15:03:21 2002 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 g24N3K816219; Mon, 4 Mar 2002 15:03:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26946 Mon, 4 Mar 2002 17:27:57 -0500 (EST) Date: Mon, 4 Mar 2002 14:38:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15491.62739.203933.991923@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> And considering the fact that an IPsec SA is identified by > Chinna> the tuple: Destination, Protocol and SPI, the probability of > Chinna> a collision is even lower, and for all practical purposes > Chinna> zero. > > But we're talking about NAT. NAT hides addresses behind it and makes > everything look like a single address. > > So in the context of NAT (at the other end) you have lots of SAs from > the same address, and of course the protocol is constant (50). > I think that there seems to be a big problem with people who want to only casually look at this problem of NAT and IPsec. I think that these casual observers tend to assume that any and every possible scenario of NATs and IPsec will work with some solution. You'll have to first take the time to understand what is feasible, and what is not. Once you have come up with a set of scenarios in which it is feasible to solve this problem, then you have to pick a technique that will only work in those scenarios. Now, given that, please let me know what scenario are you particularly interested in, and I can try and see if our solution will work. Without the details, I don't know what you are talking about. Lets not try and talk about NAT and IPsec in general, because I think both of these protocols are very complex individually, and once you combine them, they tend to become intractable. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 15:16:55 2002 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 g24NGs816633; Mon, 4 Mar 2002 15:16:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27079 Mon, 4 Mar 2002 17:42:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.64257.270449.228447@pkoning.dev.equallogic.com> Date: Mon, 4 Mar 2002 17:53:53 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15491.62739.203933.991923@pkoning.dev.equallogic.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> I think that there seems to be a big problem with people who Chinna> want to only casually look at this problem of NAT and Chinna> IPsec. I think that these casual observers tend to assume Chinna> that any and every possible scenario of NATs and IPsec will Chinna> work with some solution. You'll have to first take the time Chinna> to understand what is feasible, and what is not. Once you Chinna> have come up with a set of scenarios in which it is feasible Chinna> to solve this problem, then you have to pick a technique that Chinna> will only work in those scenarios. I guess I'm confused about the process. It looked like you were proposing a solution, or at least components of one. Several people started saying "but what about x? What about y?" That seems reasonable. Now, if you want to start with a problem statement, and from there derive a solution that addresses the scenarios in the problem statement, that sounds fine. But it didn't look like you were doing that. If your answer to each note questioning some case is to ECO the (unstated) problem statement to exclude the case being asked about, that's certainly one way to proceed, but I'm not sure it will yield a meaningful solution... paul From owner-ipsec@lists.tislabs.com Mon Mar 4 15:27:36 2002 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 g24NRa816796; Mon, 4 Mar 2002 15:27:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27109 Mon, 4 Mar 2002 17:46:52 -0500 (EST) Message-Id: <200203042258.g24MwZN71393@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: JFK Algorithm Choice Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Mar 2002 14:58:35 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just finished reading the new JFK draft at VPNC and I'm still unclear on how algorithm choice is supposed to work. As I understand it, there are actually two different sets of algorithms: those used for protecting MSG 3 and MSG 4 (JFK algorithms) and those used in the SA being established (SA algorithms). (1) JFK Algorithm Choice I think I understand this one, but I'd like to be sure. The responder provides his choice of algorithms in GRPINFOr in MSG 2. This includes the digest algorithm, the symmetric encryption algorithm and one or more DH groups. The initiator can take them or leave them. (2) SA Algorithm Choice My general understanding of how this works (based on S 2.2) is as follows: (1) The initiator offers some set of algorithms in the SA payload of MSG 3. (2) The responder chooses one and sends it in the SA' payload in MSG 4. Is this more or less correct? Questions: (1) What exactly are the contents of the SA payload. Section 2.1 says: sa: Defines the cryptographic and other properties of the Security Association (SA) the Initiator wants to establish. It contains a Domain-of-Interpretation, which JFK understands, and an application-specific bitstring. Is the idea here that this is the Security Association payload described in S 4.6.1 of RFC 2407 (possibly profiled down)? If so, this appears to be inconsistent with the claim in S 5 that: the acceptable combinations are denoted by 16-bit, unstructured integers. Since this isn't how things are done in 2407, as I understand it. (2) You list algorithms that "must be supported". Does this mean that they must be enabled or merely implemented? (3) How does the responder indicate that the initiator hasn't offered any algorithms that it supports? Is there some way to give a hint? -Ekr From owner-ipsec@lists.tislabs.com Mon Mar 4 15:38:40 2002 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 g24Nce816971; Mon, 4 Mar 2002 15:38:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27326 Mon, 4 Mar 2002 18:04:24 -0500 (EST) Message-Id: <200203042315.SAA05765@bcn.East.Sun.COM> Date: Mon, 4 Mar 2002 18:15:55 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: ikev2 DOS protection mechanisms To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qvFMXMtpWenK8jkwLo0V0g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>Re: protection for Alice from false responder DOS attack. Yes. I agree it should be a MAY and not a SHOULD. What do people think about the other DOS protection we added in this version of IKEv2 (the fragmentation attack protection). We didn't actually change the protocol, we just added implementation hints for how to protect against this attack. And it convinced us, as we said in the rationale document, to keep the handshake as an extra round trip if Bob wants to use a stateless cookie, because then we could guarantee that Bob does not need to keep state for reassembly until he's gotten a valid cookie. Until he gets a valid cookie from that IP address, the IKEv2 messages are guaranteed to be sufficiently small not to need fragmentation. If the IKE code can tell the IP reassembly code which IP addresses should be preferred for reassembly resources, (and the protocol does not require Bob receiving a very large message before he gets a cookie), then Bob can really be stateless until the IP address has sent a valid cookie. In contrast, even though on paper a 4-message protocol might look like Bob can be stateless, if packets are sufficiently large to need to be fragmented, then Bob has to use state to reassemble the messages. With the IKEv2 handshake, msg 1 is small, and the repeated msg 1, this time with Bob's cookie, will still be small, so Bob will know before message 3 (which contains a cert and therefore might need to be fragmented) if this IP address is worthy of using up reassembly resources. Not all implementations will be able to have IKE pass hints to the IP reassembly code, but I think it would be nice to have the handshake designed to *enable* people to write their code that way, in case fragmentation DOS attacks become prevalent. Anyway, comments? Radia From owner-ipsec@lists.tislabs.com Mon Mar 4 15:38:47 2002 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 g24Ncl816985; Mon, 4 Mar 2002 15:38:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27284 Mon, 4 Mar 2002 18:00:39 -0500 (EST) Message-Id: <200203042311.g24NBFUZ011503@ack.east.sun.com> From: Bill Sommerfeld To: "Chinna N.R. Pellacuru" cc: Stephen Kent , Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: Re: NAT Traversal In-Reply-To: Your message of "Mon, 04 Mar 2002 14:21:17 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Mar 2002 18:11:15 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I am suggesting that the original concept of IPsec SA being identified by > a tuple: destination IP, protocol, SPI be required, and within the SPI add > new semantics for picking a SPI on the phase2 responder. I strongly object. UDP encapsulation works JUST FINE to get through NATs which aren't trying to be too clever (and it appears that there are other workarounds to deal with overly-clever NATs). There's no need to introduce potential vulnerabilities/points of collision/etc. elsewhere in the system. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 4 15:39:17 2002 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 g24NdG817000; Mon, 4 Mar 2002 15:39:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27342 Mon, 4 Mar 2002 18:05:56 -0500 (EST) Date: Mon, 4 Mar 2002 15:16:51 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: ipsec mailling list Subject: RE: NAT Traversal In-Reply-To: <15491.64257.270449.228447@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> I think that there seems to be a big problem with people who > Chinna> want to only casually look at this problem of NAT and > Chinna> IPsec. I think that these casual observers tend to assume > Chinna> that any and every possible scenario of NATs and IPsec will > Chinna> work with some solution. You'll have to first take the time > Chinna> to understand what is feasible, and what is not. Once you > Chinna> have come up with a set of scenarios in which it is feasible > Chinna> to solve this problem, then you have to pick a technique that > Chinna> will only work in those scenarios. > > I guess I'm confused about the process. > > It looked like you were proposing a solution, or at least components > of one. Several people started saying "but what about x? What about > y?" That seems reasonable. I am not saying that it is unreasonable to ask about x and y, but what I am saying is that they should also fully specify x and y. > > Now, if you want to start with a problem statement, and from there > derive a solution that addresses the scenarios in the problem > statement, that sounds fine. But it didn't look like you were doing > that. > I think it is getting more and more clear where we started, and where we are heading. In the beginning there was this push to solve every possible scenario. Even a casual observer can shoot down all feasible solutions, because some fairly obvious scenarios are very hard, if not impossible to solve. Then AH was dropped altogether. Then, all mention of "built-in NAT" is dropped. If you followed some recent discussion, some (including me) are still asking the basic question: what is a resonable solution supposed to solve? ----------------------------------------------------------------------- Date: Sat, 2 Mar 2002 12:32:06 -0800 From: Greg Bailey To: ipsec@lists.tislabs.com Cc: ark-gvb-x Subject: RE: Towards closure on NAT traversal. Yet there are some things that seem to me logically impossible in the presence of a NAT. Consider an ESP encrypted, or even just authenticated, FTP control channel. In order for the NAT to function "transparently" it must assemble, parse, and alter the TCP stream when necessary (PORT command). How can this possibly work using straight IP with IPSec unless the NAT cracks the keys et cetera? Not to mention that a NAT box with such capabilities would be an even more powerful assault weapon than is a plain old NAT box... I would submit FTP as a proof of existence of insoluble problems in *transparently* traversing a NAT with IPSec. Even adding Security Gateway code to a NAT, which in many respects would seem the best form of "IPSec pass-through", would still leave the problems caused by uncoordinated use of private address space on the other side of the NAT in non VPN environments. How long a list of exceptions can any "solution" to this charter item tolerate and still deserve to be called a solution? Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | ---------------------------------------------------------------------- > If your answer to each note questioning some case is to ECO the > (unstated) problem statement to exclude the case being asked about, > that's certainly one way to proceed, but I'm not sure it will yield a > meaningful solution... > Agreed. I am just asking for those who are saying that something won't work, to please spell out all the details of what is it that you are saying will not work. I don't think that is an unreasonable thing to expect. Once you fully specify the scenario in which you think our or other solutions don't work, then we can first start by seeing if that scenario itself is something that anyone is trying to accomidate, and if so, how important is it to accomidate it. What are the various tradeoffs for including or excluding that scenario, and which proposed solutions will work, and which won't work. chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 15:53:17 2002 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 g24NrH817250; Mon, 4 Mar 2002 15:53:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27410 Mon, 4 Mar 2002 18:10:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 18:22:50 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, Reasonable questions. Let me try to provide some history and explain the motivations for the clarifications: > > > Just a few notes re this discussion: >> >> - the revised ESP/AH documents emphasize that an IPsec >> implementation need not use the protocol type for SPI >> differentiation. so, if one starts assuming this is true, it will be >> yet another conflict with the IPsec specs > >Curious what are the reasons for removing this restriction, and what are >the cons of still reqiring that this restriction apply. There was never a real need to use the protocol type and, in fact, one IPsec device generally cannot tell if its peer is or is not using the protocol type for SPI demuxing. We got feedback over the last 2 years from vendors asking us to revise the description to better reflect what they tended to do, and which in no way detracted from interoperability. As for the destination address, this was a result of poor wording, i.e., we never needed this for demuxing, except for multicast, but we did a very poor job of saying that. Again, we have gotten feedback from vendors who didn't understand why this "requirement" was imposed, and so we explained under what circumstances one really needs to use the dest addr for SPI demuxing. > >> >> - similarly, an IPsec implementation does not need to use the >> dest IP address as part of the SPI lookup, unless that address is for >> a multicast group. >> > >Here also, curious why that it is not required anymore to have dest IP >address as part of SPI lookup. It never was needed, as noted above, except for multicast. It is needed for multicast only because in that case the receiver does NOT select the SPI, i.e., the multicast controller does. If you propose to impose restrictions on SPI generation, you should take into account the multicast case as well. The MSEC WG is getting close to promulgating standards that will support the simple case, single sender, multiple receivers, so we should be careful to not do anything that will interfere with that work. > >> - do I understand correctly that you are suggesting a change >> to the specs to reduce the effective SPI space by a factor of 65K? >> is everyone comfortable with this? >> >> Steve >> > >I am suggesting that the original concept of IPsec SA being identified by >a tuple: destination IP, protocol, SPI be required, and within the SPI add >new semantics for picking a SPI on the phase2 responder. The new ESP ID, published before the December IETF, clarified the SPI demuxing description. We have received feedback on the ID, and nobody has voiced any objections to this revised SPI demuxing description. There appear to be no "cons" to the new wording. The "pros" are that IPsec implementations need not spend cycles matching additional fields in inbound IPsec headers that are not needed to demux SAs, which potentially improves performance. As people develop high speed IPsec implementations (note the extended sequence number option is motivated by the need to support multi-gigabit IPsec speeds), using fewer inputs to SA selection for inbound traffic reduces costs (e.g., narrower CAMs). Steve From owner-ipsec@lists.tislabs.com Mon Mar 4 16:10:24 2002 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 g250AN817601; Mon, 4 Mar 2002 16:10:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27786 Mon, 4 Mar 2002 18:34:34 -0500 (EST) Date: Mon, 4 Mar 2002 15:44:45 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Paul Koning , ipsec@lists.tislabs.com Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chinna, As I see it, we are trying to debate on three solutions: 1. Supporting ESP ALG in NAT boxes with SPI changes. 2. NAT traversal as defined in current drafts. 3. Some independent solution. ( You indicated that independent NAT discovery and NAT traversal alerady being taken care off by midcom working group. So, we can postpone this discussion). Solution 2: By standardizing different UDP port for encapsulating ESP/AH traffic, it works through all existing NATs (supporting ESP ALG or not). One disadvantage is that it requires changes to IKE/IPSEC implementations. By having different UDP port, the overhead also comes down by 8 bytes. But, one more keepalive timer is required to make the NAT session alive. Solution 1: Have limitations such as only ESP traffic, no AH traffic. What about Transport Mode? Does this solution support? SPI modifications which require changes in existing hardware and software implementations. (It was assumed that SPI selection is local matter). What happens if hash value of different SPIs come out to be same? How does it work, if quick mode responder sends the packets first? Keeping both the solutions in mind, it appears that solution 2 is better. Regards Srini On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > On Mon, 4 Mar 2002, Paul Koning wrote: > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > Chinna> And considering the fact that an IPsec SA is identified by > > Chinna> the tuple: Destination, Protocol and SPI, the probability of > > Chinna> a collision is even lower, and for all practical purposes > > Chinna> zero. > > > > But we're talking about NAT. NAT hides addresses behind it and makes > > everything look like a single address. > > > > So in the context of NAT (at the other end) you have lots of SAs from > > the same address, and of course the protocol is constant (50). > > > > I think that there seems to be a big problem with people who want to only > casually look at this problem of NAT and IPsec. I think that these casual > observers tend to assume that any and every possible scenario of NATs and > IPsec will work with some solution. You'll have to first take the time to > understand what is feasible, and what is not. Once you have come up with a > set of scenarios in which it is feasible to solve this problem, then you > have to pick a technique that will only work in those scenarios. > > Now, given that, please let me know what scenario are you particularly > interested in, and I can try and see if our solution will work. Without > the details, I don't know what you are talking about. Lets not try and > talk about NAT and IPsec in general, because I think both of these > protocols are very complex individually, and once you combine them, they > tend to become intractable. > > chinna > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon Mar 4 16:16:46 2002 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 g250Gj817859; Mon, 4 Mar 2002 16:16:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27864 Mon, 4 Mar 2002 18:41:33 -0500 (EST) Date: Mon, 4 Mar 2002 15:52:26 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Srinivasa Addepalli , Jayant Shukla , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Is it possible that along with the sequence number, we also increase the SPI space so that we can use some of the SPI space for NAT translation. We could keep the original restrictions on how to pick an SA, or we need to come up with elaborate schemes to effectively increase the SPI space, like you are attempting to increase the sequence number. How does the transition happen? If the new ESP ID is placing additional restrictions that did not exist originally I think it is fair to ask the new ID to accomidate NAT traversal by increasing the SPI space. It's like shutting off all the doors for us. You bring up another good point about multicast. Frankly, I haven't thought about it. I'll have to look at this and get back to you and the list. thanks, chinna On Mon, 4 Mar 2002, Stephen Kent wrote: > Chinna, > > Reasonable questions. Let me try to provide some history and explain > the motivations for the clarifications: > > > > > > > > Just a few notes re this discussion: > >> > >> - the revised ESP/AH documents emphasize that an IPsec > >> implementation need not use the protocol type for SPI > >> differentiation. so, if one starts assuming this is true, it will be > >> yet another conflict with the IPsec specs > > > >Curious what are the reasons for removing this restriction, and what are > >the cons of still reqiring that this restriction apply. > > There was never a real need to use the protocol type and, in fact, > one IPsec device generally cannot tell if its peer is or is not using > the protocol type for SPI demuxing. We got feedback over the last 2 > years from vendors asking us to revise the description to better > reflect what they tended to do, and which in no way detracted from > interoperability. > > As for the destination address, this was a result of poor wording, > i.e., we never needed this for demuxing, except for multicast, but we > did a very poor job of saying that. Again, we have gotten feedback > from vendors who didn't understand why this "requirement" was > imposed, and so we explained under what circumstances one really > needs to use the dest addr for SPI demuxing. > > > > >> > >> - similarly, an IPsec implementation does not need to use the > >> dest IP address as part of the SPI lookup, unless that address is for > >> a multicast group. > >> > > > >Here also, curious why that it is not required anymore to have dest IP > >address as part of SPI lookup. > > It never was needed, as noted above, except for multicast. It is > needed for multicast only because in that case the receiver does NOT > select the SPI, i.e., the multicast controller does. If you propose > to impose restrictions on SPI generation, you should take into > account the multicast case as well. The MSEC WG is getting close to > promulgating standards that will support the simple case, single > sender, multiple receivers, so we should be careful to not do > anything that will interfere with that work. > > > > >> - do I understand correctly that you are suggesting a change > >> to the specs to reduce the effective SPI space by a factor of 65K? > >> is everyone comfortable with this? > >> > >> Steve > >> > > > >I am suggesting that the original concept of IPsec SA being identified by > >a tuple: destination IP, protocol, SPI be required, and within the SPI add > >new semantics for picking a SPI on the phase2 responder. > > The new ESP ID, published before the December IETF, clarified the SPI > demuxing description. We have received feedback on the ID, and nobody > has voiced any objections to this revised SPI demuxing description. > There appear to be no "cons" to the new wording. The "pros" are that > IPsec implementations need not spend cycles matching additional > fields in inbound IPsec headers that are not needed to demux SAs, > which potentially improves performance. As people develop high speed > IPsec implementations (note the extended sequence number option is > motivated by the need to support multi-gigabit IPsec speeds), using > fewer inputs to SA selection for inbound traffic reduces costs (e.g., > narrower CAMs). > > Steve > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon Mar 4 16:51:14 2002 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 g250pD818511; Mon, 4 Mar 2002 16:51:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28068 Mon, 4 Mar 2002 19:11:06 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 19:22:46 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:52 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: >Hi Steve, > >Is it possible that along with the sequence number, we also increase the >SPI space so that we can use some of the SPI space for NAT translation. >We could keep the original restrictions on how to pick an SA, or we need >to come up with elaborate schemes to effectively increase the SPI space, >like you are attempting to increase the sequence number. I see a problem here. We increased the sequence number size, but didn't transmit the extra (high order) 32 bits! So, I can't see folks being fond of an increase in SPI size. It is no accident that the current ESP header is a multiple of both 4 and 8 bytes, using the default integrity algorithm length, specifically to ensure IPv4 and v6 alignment for the payload. Adding 2 bytes for a bigger SPI would break that alignment. >How does the transition happen? If the new ESP ID is placing additional >restrictions that did not exist originally I think it is fair to ask the >new ID to accomidate NAT traversal by increasing the SPI space. It's like >shutting off all the doors for us. The extended sequence number is an option that is negotiated by IKE (or its successor), so it is backward compatible with existing implementations that do not support the extended sequence number facility. > >You bring up another good point about multicast. Frankly, I haven't >thought about it. I'll have to look at this and get back to you and the >list. OK. Steve From owner-ipsec@lists.tislabs.com Mon Mar 4 16:54:00 2002 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 g250s0818565; Mon, 4 Mar 2002 16:54:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28133 Mon, 4 Mar 2002 19:18:04 -0500 (EST) Date: Mon, 4 Mar 2002 16:28:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Paul Koning , Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that we have sufficiently diluted the discussion, and pulled it in all possible tangents, let me try to summarize the main disadvantages of UDP encapsulation. This is the thought process that prompted us to look for another soluton: - overhead of 16 bytes per ESP packet (according to latest drafts). The real time voice protocols are already effected by the ESP overhead per voice frame. If we keep on adding to this overhead then fewer and fewer protocols will use IPsec. It's always a tradeoff between the benefits Vs cost, and these people will develop their own protocols for securing their traffic. We are increasing the price people have to pay for security, which is already too high according to many people. - Because of the above enormous overhead, it becomes absolutely necessary for the encapsulation schemes to "discover NAT". All the current schemes propose modifying IKE to do this. IKE is already considered to be too complex, and we thought that the IETF will not approve anymore changes to IKE anyway. But, looks like most people are OK with modifying IKE just for this one thing. Even if the WG is OK with it, we are still paying a price of increasing the complexity of IKE. - UDP encapsulation schemes require the use of keepalives to keep the translation alive. That would not be easy to do, particularly if you are assuming that no one knows what kind of NAT boxes are out there. It's like trying to sneak through NAT, and when we get burnt, give up. It is more prudent for a customer with business critical data that needs to get across, to make absolutely sure about what kind of NAT devices exist enroute, and plan his network accordingly end-to-end. We felt that the UDP encapsulation schemes are heavyly over engineered for the "road-warrior" scenario, at the expence of everyone else. There are some very simplistic assumptions that a "road-warror" can never have any control over what NAT devices are out there. While it is true, not everyone is a "road-warrior". There is a vast majority of IPsec users who have a home and an office, and can know and influence what kind of NAT devices are butchering their IPsec traffic. - We had reports of some UDP encapsulation deployments having trouble, and the solution being using TCP, but using a skinny TCP protocol without retransmits and other stuff on each side. We felt that using TCP isn't going to be an option because of all the violations that it would need. - As people have pointed out, even our solution has a lot of restrictions on which scenarios are supported. But, those restrictions also apply to the UDP encapsulation schemes. There are some schemes that claim to support more scenarios, but when we looked at them, they were paying a price that we were not willing to pay in terms of implementing a "built-in NAT". That's a whole NAT implementation within IPsec. That is exporting the NAT functionality to another device that is actually an IPsec device. It is not easy to manage multiple NAT devices, and it would be almost impossible to manage multiple NAT devices, and multiple NAT implementations within each IPsec implementation. I hope people can appreciate what prompted us to look for an alternative solution to the UDP encapsulation schemes. chinna On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > > Hi Chinna, > As I see it, we are trying to debate on three solutions: > > 1. Supporting ESP ALG in NAT boxes with SPI changes. > 2. NAT traversal as defined in current drafts. > 3. Some independent solution. ( You indicated that independent NAT > discovery > and NAT traversal alerady being taken care off by midcom > working group. So, we can postpone this discussion). > > Solution 2: > By standardizing different UDP port for encapsulating ESP/AH traffic, > it works through all existing NATs (supporting ESP ALG or not). > One disadvantage is that it requires changes to IKE/IPSEC > implementations. > > By having different UDP port, the overhead also comes down by > 8 bytes. But, one more keepalive timer is required to make > the NAT session alive. > > Solution 1: > Have limitations such as only ESP traffic, no AH traffic. > What about Transport Mode? Does this solution support? > SPI modifications which require changes in existing hardware > and software implementations. (It was assumed that SPI selection > is local matter). > What happens if hash value of different SPIs come out to be same? > How does it work, if quick mode responder sends the packets first? > > > Keeping both the solutions in mind, it appears that solution 2 is > better. > > > Regards > Srini > > On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > > > On Mon, 4 Mar 2002, Paul Koning wrote: > > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > > > Chinna> And considering the fact that an IPsec SA is identified by > > > Chinna> the tuple: Destination, Protocol and SPI, the probability of > > > Chinna> a collision is even lower, and for all practical purposes > > > Chinna> zero. > > > > > > But we're talking about NAT. NAT hides addresses behind it and makes > > > everything look like a single address. > > > > > > So in the context of NAT (at the other end) you have lots of SAs from > > > the same address, and of course the protocol is constant (50). > > > > > > > I think that there seems to be a big problem with people who want to only > > casually look at this problem of NAT and IPsec. I think that these casual > > observers tend to assume that any and every possible scenario of NATs and > > IPsec will work with some solution. You'll have to first take the time to > > understand what is feasible, and what is not. Once you have come up with a > > set of scenarios in which it is feasible to solve this problem, then you > > have to pick a technique that will only work in those scenarios. > > > > Now, given that, please let me know what scenario are you particularly > > interested in, and I can try and see if our solution will work. Without > > the details, I don't know what you are talking about. Lets not try and > > talk about NAT and IPsec in general, because I think both of these > > protocols are very complex individually, and once you combine them, they > > tend to become intractable. > > > > chinna > > > > -- > Srinivasa Rao Addepalli > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > USA > Ph: 408-844-0480 x317 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon Mar 4 17:02:19 2002 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 g2512J818831; Mon, 4 Mar 2002 17:02:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28189 Mon, 4 Mar 2002 19:27:11 -0500 (EST) Date: Mon, 4 Mar 2002 16:38:12 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I somehow feel that placing additional restrictions on selecting an IPsec SA is not very good just based on performance reasons. Why was a 32 bit sequence selected the first time, and how did we endup trying to extend it now. If we look at how we ended up with only 4 bytes for the IP address instead of a variable length IP address: there too, it could be performance and other reasons that prompted people to go with a 4 byte IP address. I can see people arguing that 4 bytes of IP address, yes, we will never have enough nodes to use up all those addresses. We did endup using or scrambling all our IP addresses, and now moving to IPv6 just becuase we are running out out IPv4 addresses. I think we should not place those restrictions just for performance reasons. thanks, chinna On Mon, 4 Mar 2002, Stephen Kent wrote: > At 3:52 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: > >Hi Steve, > > > >Is it possible that along with the sequence number, we also increase the > >SPI space so that we can use some of the SPI space for NAT translation. > >We could keep the original restrictions on how to pick an SA, or we need > >to come up with elaborate schemes to effectively increase the SPI space, > >like you are attempting to increase the sequence number. > > I see a problem here. We increased the sequence number size, but > didn't transmit the extra (high order) 32 bits! So, I can't see > folks being fond of an increase in SPI size. It is no accident that > the current ESP header is a multiple of both 4 and 8 bytes, using the > default integrity algorithm length, specifically to ensure IPv4 and > v6 alignment for the payload. Adding 2 bytes for a bigger SPI would > break that alignment. > > >How does the transition happen? If the new ESP ID is placing additional > >restrictions that did not exist originally I think it is fair to ask the > >new ID to accomidate NAT traversal by increasing the SPI space. It's like > >shutting off all the doors for us. > > The extended sequence number is an option that is negotiated by IKE > (or its successor), so it is backward compatible with existing > implementations that do not support the extended sequence number > facility. > > > > >You bring up another good point about multicast. Frankly, I haven't > >thought about it. I'll have to look at this and get back to you and the > >list. > > OK. > > Steve > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon Mar 4 17:17:00 2002 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 g251Gx819357; Mon, 4 Mar 2002 17:17:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28325 Mon, 4 Mar 2002 19:41:56 -0500 (EST) Message-Id: <200203050051.g250pPU02132@fatty.lounge.org> To: sommerfeld@east.sun.com Cc: ipsec@lists.tislabs.com Subject: Re: DoS attack on JFK In-Reply-To: Your message of "Mon, 04 Mar 2002 16:27:35 EST." <200203042127.g24LRZUZ011267@ack.east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2129.1015289485.1@tibernian.com> Date: Mon, 04 Mar 2002 16:51:25 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 04 Mar 2002 16:27:35 EST you wrote > So, this attack is not without risk for the attacker -- someone > monitoring the system under attack can correlate the inbound flood of > message #3 with the source address of the previous message #1's and > use this to trace the attack back to the coordinator. Yea but it would be nice if a security protocol did not require some external system to defend itself against DoS attacks. Especially if the external system must maintain the state the the protocol is saying is not required to be kept. > [... if the initiator ip address is included in the HMAC ...] > the responder could make note of an unsuccessful decryption from a > particular IP address and refuse any more messages from it for a > period of time. > > Yah, this would work, but a responder could also blacklist "Ni,Nr" > pairs or HMAC values; that might be a more effective strategy than > blacklisting by source address -- with IPv6, an attacker on a link > which does stateless address autoconfig has access to on the order of > 2^64 usable source addresses; and even with ipv4, an attacker might > have access to many valid addresses. I think a JFK implementation should implement blacklisting of bad authenticator blobs anyway. The attack is so much easier if it doesn't: send one message one, get back one message two, and send N message threes with the same nonces, exponentials, and authenticator using random source IP addresses. I don't see how blacklisting the authenticator or "Ni,Nr" pairs would be more effective than blacklisting the IP address (provided it is included in the authenticator as I am suggesting) since it is trivial to use different "Ni,Nr" pairs and different authenticators in each of the N message threes used to launch this attack. If someone has 2^64 usable source addresses from which to launch attacks it will be difficult to stop but including the IP address in the authenticator calculations would provide more information on where that link is. Each failed decryption would indicate a valid IP address of the attacker. Dan. From owner-ipsec@lists.tislabs.com Mon Mar 4 18:41:42 2002 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 g252ff821183; Mon, 4 Mar 2002 18:41:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28919 Mon, 4 Mar 2002 21:01:06 -0500 (EST) content-class: urn:content-classes:message Subject: RE: NAT Traversal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Mar 2002 18:12:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <3FFBC907DD03A34CA4410C5C745DEB126AD13C@WNIMAIL.WoodsideNet.Com> Thread-Topic: NAT Traversal Thread-Index: AcHD6b/pSL3IkZzwS2C8XghMBIZfUAAABslQ From: "Paul Lambert" To: "Chinna N.R. Pellacuru" Cc: "ipsec mailling list" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA28916 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Increasing SPI size is very bad idea. They are only as large as they are now because of IPv6 considerations for word/byte alignment. The SPI was originally called a SAID it that incarnation been the sole identifier for a security association (SA). The size need only be as large as the maximum number of SAs for a system This seems like a very confused set of proposals for NAT that are randomly mutating fields in the hopes that by some sort of Darwinian process a better protocol will be created. The suggestions that the solution should be based on well defined scenarios would help to clarify this discussion. Paul From owner-ipsec@lists.tislabs.com Mon Mar 4 19:50:18 2002 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 g253oH822628; Mon, 4 Mar 2002 19:50:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29327 Mon, 4 Mar 2002 22:03:58 -0500 (EST) Date: Mon, 4 Mar 2002 19:14:50 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Paul Koning , Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > - Because of the above enormous overhead, it becomes absolutely necessary > for the encapsulation schemes to "discover NAT". All the current schemes > propose modifying IKE to do this. IKE is already considered to be too > complex, and we thought that the IETF will not approve anymore changes to > IKE anyway. But, looks like most people are OK with modifying IKE just for > this one thing. Even if the WG is OK with it, we are still paying a price > of increasing the complexity of IKE. > It almost looks as if some people seem to be having their own hidden agenda to make IKE as complex as possible, so that when the complexity becomes unmanageble, they can promote their pet key management protocols, over IKE :-) chinna From owner-ipsec@lists.tislabs.com Mon Mar 4 21:37:33 2002 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 g255bX824207; Mon, 4 Mar 2002 21:37:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA29921 Mon, 4 Mar 2002 23:50:25 -0500 (EST) From: "Jayant Shukla" To: , "'Chinna N.R. Pellacuru'" Cc: "'Stephen Kent'" , "'Srinivasa Addepalli'" , "'Henrik Levkowetz'" , "'ipsec mailling list'" Subject: RE: NAT Traversal Date: Mon, 4 Mar 2002 20:58:44 -0800 Message-ID: <000001c1c402$6e254700$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <200203042311.g24NBFUZ011503@ack.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Bill Sommerfeld > Sent: Monday, March 04, 2002 3:11 PM > To: Chinna N.R. Pellacuru > Cc: Stephen Kent; Srinivasa Addepalli; Jayant Shukla; 'Henrik Levkowetz'; > 'ipsec mailling list' > Subject: Re: NAT Traversal > > > I am suggesting that the original concept of IPsec SA being identified > by > > a tuple: destination IP, protocol, SPI be required, and within the SPI > add > > new semantics for picking a SPI on the phase2 responder. > > I strongly object. > That's understandable. > UDP encapsulation works JUST FINE to get through NATs which aren't > trying to be too clever (and it appears that there are other > workarounds to deal with overly-clever NATs). > UDP encapsulation does not work JUST FINE! This proposal has significant problems and they have been discussed copiously. Please check earlier e-mails of this thread. > There's no need to introduce potential vulnerabilities/points of > collision/etc. elsewhere in the system. > > - Bill > Sending all traffic through port 500 sounds like a BIG vulnerability to me! A simple DoS attack on port 500 will kill all VPN traffic. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Tue Mar 5 04:17:27 2002 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 g25CHR805704; Tue, 5 Mar 2002 04:17:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02663 Tue, 5 Mar 2002 06:07:59 -0500 (EST) Message-Id: <200203051119.GAA23323@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-02.txt Date: Tue, 05 Mar 2002 06:19:29 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-02.txt Pages : 41 Date : 04-Mar-02 This memo describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. 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. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-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-ietf-ipsec-esp-v3-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-ietf-ipsec-esp-v3-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: <20020304133327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304133327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Mar 5 04:48:49 2002 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 g25Cmm806524; Tue, 5 Mar 2002 04:48:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03123 Tue, 5 Mar 2002 07:09:48 -0500 (EST) Message-Id: <200203051221.g25CLWN78365@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: JFK ID payload Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Mar 2002 04:21:32 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Section 4.2 of the new draft specifies the value of the ID payload as: IDi and IDr is expressed as a single octet specifying the type of ID used, followed by the ID material. The following ID types are specified. ID tag Meaning 1 A bundle of one or more PKIX certificates, CRLs, and OCSP responses, concatenated. While this may work in theory, it will be difficult to implement correctly, since the recipient will be forced to partially parse the BER of each element in order to determine what type of entity he's dealing with. In general it would probably be better for JFK to separate and tag each entity. -Ekr From owner-ipsec@lists.tislabs.com Tue Mar 5 06:52:12 2002 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 g25EqB813822; Tue, 5 Mar 2002 06:52:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03979 Tue, 5 Mar 2002 09:06:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 5 Mar 2002 09:11:26 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:38 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: >Hi Steve, > >I somehow feel that placing additional restrictions on selecting an IPsec >SA is not very good just based on performance reasons. Why was a 32 bit >sequence selected the first time, and how did we endup trying to extend it >now. We're not "placing additional restrictions on SA selection." We clarified what was technically required in the first place, but which was not expressed clearly. We selected 32 bits for the SPI in much the same way we selected 32 bits for IP v4 addresses: it was the smallest multiple of 4 bytes that seemed reasonable. (BTW, I erred in my comments re alignment yesterday, confusing ESP and AH. The ESP header is exactly 8 bytes long, which is the smallest length that satisfies the v4 and v6 payload alignment criteria. The integrity check appears after the payload and thus is not relevant to payload alignment. In AH, the total length of the protocol header affects payload alignment, and there the magic number we have adopted, using the default integrity algorithm, is 24 bytes.) We did debate on the list whether to go with 16 bits, years ago, and many folks felt that might not be enough in some contexts. You'd have to review the archives from 6 or more years ago to reconstruct the arguments. I'm not saying that we could not revisit the issue, but I am noting that we did debate it once before. >If we look at how we ended up with only 4 bytes for the IP address instead >of a variable length IP address: there too, it could be performance and >other reasons that prompted people to go with a 4 byte IP address. I can >see people arguing that 4 bytes of IP address, yes, we will never have >enough nodes to use up all those addresses. We did endup using or >scrambling all our IP addresses, and now moving to IPv6 just becuase we >are running out out IPv4 addresses. Yes, as my comments above note, we went through an analogous discussion for SPIs. > >I think we should not place those restrictions just for performance >reasons. > > thanks, > chinna Again, I don't think the characterization you're citing is accurate. I gave performance-based motivations for why a receiver would prefer to use just the SPI for SA lookup in unicast contexts. SA lookup is purely a receiver function, and the specs have ALWAYS made it clear that the receiver has tremendous leeway in selecting SPI values to facilitate lookup. Our clarifications in the most recent IDs merely make clear how a receiver can take advantage of the flexibility that has always been accorded to it. We're not changing the rules, as you seem to suggest; we're explaining what a receiver can do within the scope of the protocol design, and providing rationale that clarifies when one needs to use more than the SPI to select the right SA. Steve From owner-ipsec@lists.tislabs.com Tue Mar 5 06:57:49 2002 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 g25Evm813927; Tue, 5 Mar 2002 06:57:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04027 Tue, 5 Mar 2002 09:17:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.54798.172308.775905@pkoning.dev.equallogic.com> Date: Tue, 5 Mar 2002 09:28:30 -0500 From: Paul Koning To: kent@bbn.com Cc: pcn@cisco.com, ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> ... >>> - do I understand correctly that you are suggesting a change to >>> the specs to reduce the effective SPI space by a factor of 65K? >>> is everyone comfortable with this? >>> >>> Steve >>> >> I am suggesting that the original concept of IPsec SA being >> identified by a tuple: destination IP, protocol, SPI be required, >> and within the SPI add new semantics for picking a SPI on the >> phase2 responder. Stephen> The new ESP ID, published before the December IETF, Stephen> clarified the SPI demuxing description. We have received Stephen> feedback on the ID, and nobody has voiced any objections to Stephen> this revised SPI demuxing description. There appear to be Stephen> no "cons" to the new wording. The "pros" are that IPsec Stephen> implementations need not spend cycles matching additional Stephen> fields in inbound IPsec headers that are not needed to demux Stephen> SAs, which potentially improves performance. Indeed. And that's already allowed by the earlier specs, because of the fact that the SPI is chosen by the receiver. That's a classic good design approach for fast demuxing. For example, a receiver might choose the SPI so the low order N bits (across *all* inbound SAs, not just the SAs for a particular remote address) are unique and index a vector of SA state pointers. Clearly that's a permitted design, and it's a design that is currently in use. (Obviously, it then has to verify that the address and protocol are correct, but that's a compare for equality, not a search key operation.) Right now that design works up to a very large number of SAs -- 32 bits is a reasonable size for this scheme. On the other hand, if you reduce the portion of the SPI that the receiver can control to 16 bits, this direct indexing approach becomes problematic for larger implementations. So in answer to your earlier question: no, reducing the effective SPI space to 16 bits is not acceptable. paul From owner-ipsec@lists.tislabs.com Tue Mar 5 09:02:03 2002 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 g25H22822343; Tue, 5 Mar 2002 09:02:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04892 Tue, 5 Mar 2002 11:03:03 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699B0@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Tony Hain'" , "Hallam-Baker, Phillip" , Melinda Shore , Jayant Shukla , ipsec@lists.tislabs.com Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 08:15:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C460.EF405600" 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_000_01C1C460.EF405600 Content-Type: text/plain; charset="iso-8859-1" > Wasting time in yet another WG > on figuring out how to work around NAT is a bad idea, so the IESG should > revisit the IPsec WG charter. The IESG should do no such thing. IPSEC needs to fix their protocol. > In some parts of the world > IPv6 is being deployed today, so just because you don't see > it happening > in your area is no reason to take the toys to another forum. I am probably more aware of the extent of IPv6 deployment than you are. Yes it does exist, no the extend and pace of deployment does not support your argument that we can all wait for IPv6 to happen. Having been part of the transitioning of a much smaller network from DECNET to OSI I think I have a more realistic understanding of what is involved. > If demand for IPsec is really that strong, why are people > still putting > in NATs when they know that it will be broken? The people who want IPSEC are often different from the people performing NAT attacks on them. > If people really want > IPsec they can still get IPv4 addresses. Yes we need IPsec, and yes we > need to live in a world with IPv4 NAT, but those two > requirements don't > mean the IPsec WG needs to be wasting time figuring out how > to get IPsec > through a NAT. MidCom is working on a generic solution to the problem > for IPv4, and using IPv6 to push the entire IPv4/NAT mess down a layer > gives you a cleaner way out. This is sophistry. IPSEC needs to address the NAT problems that IPSEC introduces. MidCom is not about to go fixing IKE to work through NATs. Again it is very clear that what you are really trying to do here is to kill NAT by some bizare IETF machinations. Won't work, been there tried that. All that approach would do is cause the vendors to diverge further. > I am sorry, I thought this discussion was about traversing NAT to make > IPsec work. So it is really about how to do the easy half (and a small > subset of that), maybe it should be titled 'the client side of a few > applications NAT traversal'. I don't think that it is rational to expect NAT + IPSEC to provide greater connectivity than NAT alone. NAT reduces the functionality of IP, IPSEC + NAT currently eliminates the functionality of IP, the objective of IPSEC has to be to get IPSEC + NAT to give equivalent functionality to plain NAT. Phill ------_=_NextPart_000_01C1C460.EF405600 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C460.EF405600-- From owner-ipsec@lists.tislabs.com Tue Mar 5 09:30:31 2002 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 g25HUU823428; Tue, 5 Mar 2002 09:30:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05238 Tue, 5 Mar 2002 11:46:11 -0500 (EST) Message-ID: <20020305031542.48150.qmail@web10402.mail.yahoo.com> Date: Mon, 4 Mar 2002 19:15:42 -0800 (PST) From: Saroop Mathur Subject: RE: NAT Traversal To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Mar 2002, Stephen Kent wrote: > At 3:52 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: > >Hi Steve, > > > >Is it possible that along with the sequence number, we also increase the > >SPI space so that we can use some of the SPI space for NAT translation. > >We could keep the original restrictions on how to pick an SA, or we need > >to come up with elaborate schemes to effectively increase the SPI space, > >like you are attempting to increase the sequence number. > > I see a problem here. We increased the sequence number size, but > didn't transmit the extra (high order) 32 bits! So, I can't see > folks being fond of an increase in SPI size. It is no accident that > the current ESP header is a multiple of both 4 and 8 bytes, using the > default integrity algorithm length, specifically to ensure IPv4 and > v6 alignment for the payload. Adding 2 bytes for a bigger SPI would > break that alignment. If changing the ESP header bits is an option, then it may make more sense to include both source and dest SPIs in the header instead of increasing the SPI size to either 6 or 8 bytes. IP, TCP and UDP include both src/dest fields. This way the semantics of the entire SPI bits remain with the entity generating the SPIs while allowing the NAT devices to allow proper mapping. In order to maintain 8-byte alignment, the Sequence number can also be increased to 64 bits. Alternatively SPIs can be increased to 48-bits and the sequence number bits remain the same. -Saroop __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Mar 5 09:32:51 2002 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 g25HWo823559; Tue, 5 Mar 2002 09:32:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05250 Tue, 5 Mar 2002 11:47:11 -0500 (EST) From: icon2002@sp.edu.sg Subject: ICON2002 - Call-For-Papers Deadline Extension To: icon00-01a%SP_SF@sp.edu.sg, icon00-01b%SP_SF@sp.edu.sg, icon00-01c%SP_SF@sp.edu.sg, icon00-01d%SP_SF@sp.edu.sg, icon00-01e%SP_SF@sp.edu.sg, icon00-01f%SP_SF@sp.edu.sg, icon00-01g%SP_SF@sp.edu.sg, icon00-01h%SP_SF@sp.edu.sg, icon00-01i%SP_SF@sp.edu.sg X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 5 Mar 2002 18:22:38 +0800 X-MIMETrack: Serialize by Router on SSPWS010/SP/SP_SF(Release 5.0.2b (Intl)|16 December 1999) at 05/03/2002 06:24:41 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 FAA02158 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ========================================================================= ICON2002 : Deadline for submission of papers has been extended to March 22, 2002 ========================================================================= In response to the numerous request for extension of the paper submission deadline, the ICON2002 Organising Committee has decided to extend the deadline for submission of papers to March 22, 2002. The updated Call-For-Papers is appended below. We hope that, with the extended deadline, there will be sufficient time to complete your paper for submission. Sincerely, ICON2002 Organising Committee ********************************************************************** Our apologies if you receive multiple copies of this message. We highly appreciate your help to publicize the CFP locally. ********************************************************************** IEEE INTERNATIONAL CONFERENCE ON NETWORKS (ICON 2002) http://icon2002.calendarone.com CALL FOR PAPERS IEEE INTERNATIONAL CONFERENCE ON NETWORKS Tues, August 27 - Fri, August 30, 2002, Singapore Organised by Computer Chapter, IEEE Singapore School of EEE, Singapore Polytechnic In Cooperation with National University of Singapore Nanyang Technological University Laboratories for Information Technology Supported by Singapore Exhibition & Convention Bureau Conference Theme: Towards Network Superiority The IEEE International Conference on Networks (ICON2002) will be held in Singapore. Two days of tutorials and two days of technical presentations are planned for the conference. The conference will also include invited speakers, poster presentations and an exhibition. ICON2002 will provide a forum to discuss the recent advances in computer networks and communications. Contributions describing original research, surveys and applications are solicited. Topics of interest include, but are not limited to, the following areas: Active / Intelligent Networks Ad-hoc Networks BISDN and ATM Congestion / Admission Control Converged Data and Telecom Networks Data Traffic Engineering and Management High Speed Network Protocols Internet Services / Applications Label Switching Protocol Mobile Communication Multicast / Broadcast Protocols Multimedia Protocols and Networking Multimedia over Internet Multiple Access Technology Network Architecture and Protocol Performance Network Management and Control Network Monitoring Network Security and Privacy Network Signalling and Connection Management Optical Communication Networks MPLS in WDM Networks IP over WDM Networks Personal Communication Services Pervasive Networks Quality of Service Routing and Routing Protocols Storage Area Networks Test-beds and Measurements Virtual Private Networks Voice over Internet Wireless/Mobile/Satellite/ Networks and Protocols Wireless Internet Submissions of original, unpublished papers on various aspects of mobility in computer networks are particularly encouraged. All submitted papers will be internationally reviewed and accepted papers will be published. PAPER SUBMISSION INSTRUCTIONS The paper should present original, unpublished research and be no longer than 5000 words. The submission should include a cover page containing the title, author name(s), complete address (telephone, fax, email) for all authors, indication of the corresponding author, and an abstract (100-150 words), followed by keywords and one or more areas of interest from the list above. Electronic submission in PDF is preferred. Instructions on the submission of papers can be found on the conference web page. Submission of paper(s) implies the authors' willingness to register at the conference and present the paper(s). An accepted paper will be published in the proceedings only if the final version is accompanied by the registration form and fee for at least one of the authors. One author registration will guarantee publication of up to only two accepted papers. SPECIAL SESSION / PLENARY SESSION PROPOSALS Proposals for Special Sessions/Plenary Sessions are also solicited. Proposals may be submitted to the Conference Co-Chair, Lee-Yee LAU via email at icon2002@sp.edu.sg by January 1, 2002. TUTORIAL PROPOSALS Proposals for full- or half-day tutorial topics including but not restricted to these areas are solicited: high-speed networks, mobile and wireless networks, optical networks, network security and advanced internet. Each proposal should be about 1000 words long and should include a synopsis, tutorial outline and brief biography of the speaker. Please submit your proposals to the Tutorial Chair, Yew-Chiong LOH via email at icon2002@sp.edu.sg by March 1, 2002. IMPORTANT DATES Proposal for Special/ Plenary Sessions due: Jan 1, 2002 Proposal for Tutorials due: March 1, 2002 Full paper due: March 22, 2002 Notification of acceptance: May 15, 2002 Camera-ready paper due: June 15, 2002 Tutorial: Aug 27-28, 2002 Conference: Aug 29-30, 2002 ORGANISING COMMITTEE Conference Co-Chairs: Lawrence WONG (National University of Singapore, Singapore) Lee-Yee LAU (Singapore Polytechnic, Singapore) Technical Program Co-Chairs: Liren ZHANG (Nanyang Technological University, Singapore) Lek-Heng NGOH (Laboratories for Information Technology, Singapore) Finance Chair: Sudhir K JHAJHARIA (Singapore Polytechnic, Singapore) Publicity Chair: Weng-Yew WONG (Singapore Polytechnic, Singapore) Tutorial Chair: Yew-Chiong LOH (Singapore Polytechnic, Singapore) Local Arrangements Chair: Teck-Bee TAN (Singapore Polytechnic, Singapore) Conference Secretary: Siti Marina Masduki (Singapore Polytechnic, Singapore) Webmaster: Cindy LAI (Singapore Polytechnic, Singapore) INTERNATIONAL TECHNICAL PROGRAM COMMITTEE A L Ananda (National University of Singapore, Singapore) Andrew Campbell (Columbia University, USA) Aruna Seneviratne (University of New South Wales, Australia) Athanassios Manikas (Imperial College of Science, Technology and Medicine, UK) Bharadwaj Veeravalli (National University of Singapore, Singapore) Brahim Bensaou (Hong Kong University of Science and Technology, Hong Kong) Chai-Keong Toh (Georgia Institute of Technology, USA) Chen-Khong Tham (National University of Singapore, Singapore) Francis Lee (Nanyang Technological University, Singapore) Gee-Swee Poo (Nanyang Technological University, Singapore) HT Kung (Harvard University, USA) Heng-Seng Cheng (Laboratories for Information Technology, Singapore) Hung-Keng Pung (National University of Singapore, Singapore) Jadwiga Indulska (University of Queensland, Australia) Javier A. Barria (Imperial College of Science, Technology and Medicine, UK) Jens Schmitt (Darmstadt University of Technology, Germany) Jit Biswas (Laboratories for Information Technology, Singapore) K R Subramanian (Nanyang Technological University, Singapore) Kwok-Yan Lam (National University of Singapore, Singapore) Lindsay Jackson (Australia) Minzhe Zhao (DataVideo Co. Ltd, China) Mun-Choon Chan (Bell Labs, Lucent Technologies, USA) Mustafa Gurcan (Imperial College of Science, Technology and Medicine, UK) Peter Beadle (Motorola Australia Research Centre, Australia) Peter Steenkiste (Carnegie Mellon University, USA) Radhakrishna Pillai (Indian Institute of Management, India) Raj Jain (Nayna Networks, USA) Ralf Steinmetz (Darmstadt University of Technology, Germany) Rocky Chang (Hong Kong Polytechnic University, Hong Kong) S Venkatesan (University of Texas-Dallas, USA) S V Raghavan (IIT Madras, India) Steven Low (California Institute of Technology, USA) Wei-Kang (Kevin) Tsai (UC Irvine, USA) Weiguo Wang (Alcatel, Singapore) Werasak Kurutach (Mahanakorn University of Technology, Thailand) Whay-Chiou Lee (Motorola, USA) Winston Seah (Centre for Wireless Communications, Singapore) Yew-Hock Ang (Nanyang Technological University, Singapore) From owner-ipsec@lists.tislabs.com Tue Mar 5 09:51:49 2002 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 g25Hpm824873; Tue, 5 Mar 2002 09:51:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05460 Tue, 5 Mar 2002 12:16:22 -0500 (EST) Message-ID: <3C85004B.681B9B72@sonicwall.com> Date: Tue, 05 Mar 2002 09:28:43 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Saroop Mathur CC: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: <20020305031542.48150.qmail@web10402.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2002 17:28:43.0591 (UTC) FILETIME=[32CCC570:01C1C46B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Saroop Mathur wrote: > If changing the ESP header bits is an option, then it may make more > sense to include both source and dest SPIs in the header instead of > increasing the SPI size to either 6 or 8 bytes. IP, TCP and UDP include > both src/dest fields. This way the semantics of the entire SPI bits > remain with the entity generating the SPIs while allowing the NAT > devices to allow proper mapping. > > In order to maintain 8-byte alignment, the Sequence number can also be > increased to 64 bits. Alternatively SPIs can be increased to 48-bits > and the sequence number bits remain the same. One obvious problem with changing the ESP header is that it does not contain a version number. Hence, an intermediary (such as a nat box) would have difficulty determining what it was looking at. I don't think changing the ESP header is seriously up for consideration here. Scott From owner-ipsec@lists.tislabs.com Tue Mar 5 09:51:49 2002 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 g25Hpm824874; Tue, 5 Mar 2002 09:51:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05375 Tue, 5 Mar 2002 12:06:12 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <20020305031542.48150.qmail@web10402.mail.yahoo.com> References: <20020305031542.48150.qmail@web10402.mail.yahoo.com> Date: Tue, 5 Mar 2002 12:16:53 -0500 To: Saroop Mathur From: Stephen Kent Subject: RE: NAT Traversal Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:15 PM -0800 3/4/02, Saroop Mathur wrote: >On Mon, 4 Mar 2002, Stephen Kent wrote: > > > At 3:52 PM -0800 3/4/02, Chinna N.R. Pellacuru wrote: > > >Hi Steve, > > > > > >Is it possible that along with the sequence number, we also increase >the > > >SPI space so that we can use some of the SPI space for NAT >translation. > > >We could keep the original restrictions on how to pick an SA, or we >need > > >to come up with elaborate schemes to effectively increase the SPI >space, > > >like you are attempting to increase the sequence number. > > > > I see a problem here. We increased the sequence number size, but > > didn't transmit the extra (high order) 32 bits! So, I can't see > > folks being fond of an increase in SPI size. It is no accident that > > the current ESP header is a multiple of both 4 and 8 bytes, using the > > default integrity algorithm length, specifically to ensure IPv4 and > > v6 alignment for the payload. Adding 2 bytes for a bigger SPI would > > break that alignment. > >If changing the ESP header bits is an option, then it may make more >sense to include both source and dest SPIs in the header instead of >increasing the SPI size to either 6 or 8 bytes. IP, TCP and UDP include >both src/dest fields. This way the semantics of the entire SPI bits >remain with the entity generating the SPIs while allowing the NAT >devices to allow proper mapping. Please reread my comments. We explicitly did NOT change the header to accommodate the extra sequence number bits. Also, the reasons that IP, TCP and UDP include both source and destination addresses and/or port fields has to do with the model for demuxing that they adopted (>25 years ago). We articulated an approach to demuxing for ESP/AH that is different, and more space efficient. We have different modes here. >In order to maintain 8-byte alignment, the Sequence number can also be >increased to 64 bits. Alternatively SPIs can be increased to 48-bits >and the sequence number bits remain the same. > >-Saroop If one wanted to increase the size of the header and maintain 8-byte alignment, there are many ways to do that. But I don't think the IPsec community has expressed a general desire to double the header size for all traffic, as a means of reducing the overhead for NAT traversal. Steve From owner-ipsec@lists.tislabs.com Tue Mar 5 10:53:54 2002 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 g25Irr827662; Tue, 5 Mar 2002 10:53:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05945 Tue, 5 Mar 2002 13:16:44 -0500 (EST) From: "Henrik Levkowetz" To: , "'ipsec mailling list'" Subject: RE: NAT Traversal Date: Tue, 5 Mar 2002 19:09:26 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200203042311.g24NBFUZ011503@ack.east.sun.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > I am suggesting that the original concept of IPsec SA being identified by > > a tuple: destination IP, protocol, SPI be required, and within the SPI add > > new semantics for picking a SPI on the phase2 responder. > > I strongly object. > > UDP encapsulation works JUST FINE to get through NATs which aren't > trying to be too clever (and it appears that there are other > workarounds to deal with overly-clever NATs). I agree. By handling NATs through UDP encapsulation, you will get through most if not all NATs. And if the cost can be kept down to only the addition of 8 or 16 bytes, would that be too much? Henrik > > There's no need to introduce potential vulnerabilities/points of > collision/etc. elsewhere in the system. > > - Bill > From owner-ipsec@lists.tislabs.com Tue Mar 5 11:49:00 2002 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 g25Jn0829203; Tue, 5 Mar 2002 11:49:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06356 Tue, 5 Mar 2002 14:13:20 -0500 (EST) Date: Tue, 5 Mar 2002 12:34:33 -0800 (PST) From: Srinivasa Addepalli To: ipsec@lists.tislabs.com Subject: Classification engine and IPSEC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, There are some difficult protocols such as FTP, H.323, RTSP, SIP etc.. These protocols have control connection and several data connections. Control connection uses standard service port. But data connections use ephemeral ports, which are negotiated during the control connection. For example, FTP data connection information goes as part of 'PORT' command of control connection. IPSEC SPD policies can be defined based on transport selectors such as 'source' and 'dest' ports (ranges) along with IP addresses. We see requirement that all packets belonging to a flow (control and data connections ) should have same security properties. That is, only one IPSEC policy defined for the service and all child connections (data connections ) should also use the same policy. But, this requires interoperability as the other party also should treat this similar way. Today, we are solving this using proprietary mechanism and works only with our solutions. When working with other IPSEC solutions, data connections will follow the IPSEC policy list to get the new security properties. Do people see any requirement like this? If so, how do we solve this problem such that it is interoperable? Regards Srini -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Tue Mar 5 12:33:00 2002 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 g25KWx800399; Tue, 5 Mar 2002 12:32:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06590 Tue, 5 Mar 2002 14:51:48 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , "Melinda Shore" , "Jayant Shukla" , Cc: "'ark-gvb-x'" Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 12:03:18 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F4058699B0@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > The IESG should do no such thing. IPSEC needs to fix their > protocol. There is nothing wrong with the IPsec protocol in an environment that doesn't include NAT (read IPv6 here). > > I am probably more aware of the extent of IPv6 deployment than > you are. Yes it does exist, no the extend and pace of deployment > does not support your argument that we can all wait for IPv6 > to happen. Hard to believe, but I would never claim to be aware of everything that is happening in the deployment space. If you are basing your perceptions on the allocation rate for IPv6 prefixes to ISPs, you really don't understand the implications of RFC-3056 or draft-ietf-ngtrans-shipworm. > > Having been part of the transitioning of a much smaller network > from DECNET to OSI I think I have a more realistic understanding > of what is involved. Been there, done that (actually that was number 3 of network protocol transitions), and never did get a T-shirt, but I do have a nice leather case with DIGITAL on the side. :) While that transition worked to some degree in a limited enterprise context, the only way to pull it off in a global multi-administration context would have been to preconfigure then stage a global power outage. The piece that is missing from the IPv6 deployment picture today is the porting of applications to the new APIs. Since this will happen as people attempt to 'shut up' the compiler that is bitching at them for using an obsolete API, it is only a matter of time. If the IPsec WG focused more of its energy into making sure the IPv6 deployability was clean, than fighting a loosing battle where even the participants acknowledge that the outcome will never be right, we would probably be making more progress on getting app developers motivated in doing the API port. > > The people who want IPSEC are often different from the people > performing NAT attacks on them. I don't understand your point. For IPsec to work, both parties have to be willing and interested. If one of those parties puts up a NAT, they obvoiusly aren't interested. > > > This is sophistry. IPSEC needs to address the NAT problems > that IPSEC introduces. MidCom is not about to go fixing IKE > to work through NATs. It appears your perspective of reality is simply backasswards. NAT is the one introducing the problems to IPsec, there is nothing IPsec did that caused a problem for NATs. I would not wish fixing IKE on MidCom (independent of getting it through a NAT), but the real issue is finding a generalized NAT traversal which IPsec can use. If every WG does a one-off, it is less likely that any given path will contain the right set of NAT hacks to make any applications work. > > Again it is very clear that what you are really trying to do > here is to kill NAT by some bizare IETF machinations. Won't > work, been there tried that. All that approach would do is > cause the vendors to diverge further. No I am not trying to kill NAT, look at RFC-2993 if you still don't understand. If I was really trying to kill off NAT, the first thing I would do is spin up 50 WGs to create as divergent and demanding a set of requirements for implementation as possible. In reality we have MidCom trying to figure out a common set of requirements that make it reasonable for NAT vendors to implement them. In that context, this group should be feeding requirements to MidCom, and leaving the details to others. > > I don't think that it is rational to expect NAT + IPSEC to > provide greater connectivity than NAT alone. NAT reduces the > functionality of IP, IPSEC + NAT currently eliminates the > functionality of IP, the objective of IPSEC has to be to > get IPSEC + NAT to give equivalent functionality to plain NAT. Again, your perspective seems warped. IPsec + NAT doesn't eliminate the functionality of IP, NAT eliminates the functionality of IPsec. This thread has been about how to remove that blockage, which duplicates the work of two other WGs. In those cases their charter is explicitly to make it possible to get through NAT, while the charter here is to focus on securing the communications path. Tony From owner-ipsec@lists.tislabs.com Tue Mar 5 12:55:04 2002 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 g25Kt3800843; Tue, 5 Mar 2002 12:55:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06771 Tue, 5 Mar 2002 15:20:29 -0500 (EST) Date: Tue, 5 Mar 2002 12:31:30 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 5 Mar 2002, Stephen Kent wrote: > > Again, I don't think the characterization you're citing is accurate. > I gave performance-based motivations for why a receiver would prefer > to use just the SPI for SA lookup in unicast contexts. SA lookup is > purely a receiver function, and the specs have ALWAYS made it clear > that the receiver has tremendous leeway in selecting SPI values to > facilitate lookup. Our clarifications in the most recent IDs merely > make clear how a receiver can take advantage of the flexibility that > has always been accorded to it. We're not changing the rules, as you > seem to suggest; we're explaining what a receiver can do within the > scope of the protocol design, and providing rationale that clarifies > when one needs to use more than the SPI to select the right SA. > > We based our design on what the RFC 2401 says: " o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] " So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by 4 bytes of IP address, and a bit for protocol (because we currently have only two IPsec protocols, AH and ESP). Effectively reducing the SAID space by 33 bits. This is being suggested only for performance-based reasons. I don't think the performance benefits are significant enough for us to change RFC 2401. TCAMs can handle large selectors. Selector size is not the most important problem that TCAMs are dealing with now. I think the resoning that TCAMs cannot handle large selector sizes is dated. We are only talking about adding 4 bytes of destination IP address, and a byte for protocol into the selector for the TCAM. That is just 5 bytes. The TCAMs are alredy having to deal with the increase in IP address from 4 bytes to 16 bytes, and there can be multiple of these IP addresses in the selector (for IPsec atleast 2). I think it is just a myth that the biggest problem with TCAMs is the selector size. Even in software, I don't think that there is any significant performance benefit. I think it's more of a burden (regardless of hardware or software) to make absolutely sure that the SPI we use is unique on the box, if we are going to require it to be unique. The SPIs are sent with each proposal, and we only endup using one of the proposals. We need to keep track of what SPIs were allocated to these proposals that are being negotiated. We can NOT just look at the SADB and pick a SPI that is not in the SADB. And, there needs to be some garbage collection to be done to scavange all the SPIs we burn up when we propose a bunch of proposals. The SPI space can get pretty fragmented once rekeys happen, and it just becomes a nightmare to have to pick a SPI that we are absolutely sure that it is unique. It is much more easier to not have to change RFC 2401 and reduce the existing SAID space. chinna From owner-ipsec@lists.tislabs.com Tue Mar 5 12:57:25 2002 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 g25KvP800884; Tue, 5 Mar 2002 12:57:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06810 Tue, 5 Mar 2002 15:22:53 -0500 (EST) Date: Mon, 4 Mar 2002 16:28:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Srinivasa Addepalli cc: Paul Koning , Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that we have sufficiently diluted the discussion, and pulled it in all possible tangents, let me try to summarize the main disadvantages of UDP encapsulation. This is the thought process that prompted us to look for another soluton: - overhead of 16 bytes per ESP packet (according to latest drafts). The real time voice protocols are already effected by the ESP overhead per voice frame. If we keep on adding to this overhead then fewer and fewer protocols will use IPsec. It's always a tradeoff between the benefits Vs cost, and these people will develop their own protocols for securing their traffic. We are increasing the price people have to pay for security, which is already too high according to many people. - Because of the above enormous overhead, it becomes absolutely necessary for the encapsulation schemes to "discover NAT". All the current schemes propose modifying IKE to do this. IKE is already considered to be too complex, and we thought that the IETF will not approve anymore changes to IKE anyway. But, looks like most people are OK with modifying IKE just for this one thing. Even if the WG is OK with it, we are still paying a price of increasing the complexity of IKE. - UDP encapsulation schemes require the use of keepalives to keep the translation alive. That would not be easy to do, particularly if you are assuming that no one knows what kind of NAT boxes are out there. It's like trying to sneak through NAT, and when we get burnt, give up. It is more prudent for a customer with business critical data that needs to get across, to make absolutely sure about what kind of NAT devices exist enroute, and plan his network accordingly end-to-end. We felt that the UDP encapsulation schemes are heavyly over engineered for the "road-warrior" scenario, at the expence of everyone else. There are some very simplistic assumptions that a "road-warror" can never have any control over what NAT devices are out there. While it is true, not everyone is a "road-warrior". There is a vast majority of IPsec users who have a home and an office, and can know and influence what kind of NAT devices are butchering their IPsec traffic. - We had reports of some UDP encapsulation deployments having trouble, and the solution being using TCP, but using a skinny TCP protocol without retransmits and other stuff on each side. We felt that using TCP isn't going to be an option because of all the violations that it would need. - As people have pointed out, even our solution has a lot of restrictions on which scenarios are supported. But, those restrictions also apply to the UDP encapsulation schemes. There are some schemes that claim to support more scenarios, but when we looked at them, they were paying a price that we were not willing to pay in terms of implementing a "built-in NAT". That's a whole NAT implementation within IPsec. That is exporting the NAT functionality to another device that is actually an IPsec device. It is not easy to manage multiple NAT devices, and it would be almost impossible to manage multiple NAT devices, and multiple NAT implementations within each IPsec implementation. I hope people can appreciate what prompted us to look for an alternative solution to the UDP encapsulation schemes. chinna On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > > Hi Chinna, > As I see it, we are trying to debate on three solutions: > > 1. Supporting ESP ALG in NAT boxes with SPI changes. > 2. NAT traversal as defined in current drafts. > 3. Some independent solution. ( You indicated that independent NAT > discovery > and NAT traversal alerady being taken care off by midcom > working group. So, we can postpone this discussion). > > Solution 2: > By standardizing different UDP port for encapsulating ESP/AH traffic, > it works through all existing NATs (supporting ESP ALG or not). > One disadvantage is that it requires changes to IKE/IPSEC > implementations. > > By having different UDP port, the overhead also comes down by > 8 bytes. But, one more keepalive timer is required to make > the NAT session alive. > > Solution 1: > Have limitations such as only ESP traffic, no AH traffic. > What about Transport Mode? Does this solution support? > SPI modifications which require changes in existing hardware > and software implementations. (It was assumed that SPI selection > is local matter). > What happens if hash value of different SPIs come out to be same? > How does it work, if quick mode responder sends the packets first? > > > Keeping both the solutions in mind, it appears that solution 2 is > better. > > > Regards > Srini > > On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > > > On Mon, 4 Mar 2002, Paul Koning wrote: > > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > > > Chinna> And considering the fact that an IPsec SA is identified by > > > Chinna> the tuple: Destination, Protocol and SPI, the probability of > > > Chinna> a collision is even lower, and for all practical purposes > > > Chinna> zero. > > > > > > But we're talking about NAT. NAT hides addresses behind it and makes > > > everything look like a single address. > > > > > > So in the context of NAT (at the other end) you have lots of SAs from > > > the same address, and of course the protocol is constant (50). > > > > > > > I think that there seems to be a big problem with people who want to only > > casually look at this problem of NAT and IPsec. I think that these casual > > observers tend to assume that any and every possible scenario of NATs and > > IPsec will work with some solution. You'll have to first take the time to > > understand what is feasible, and what is not. Once you have come up with a > > set of scenarios in which it is feasible to solve this problem, then you > > have to pick a technique that will only work in those scenarios. > > > > Now, given that, please let me know what scenario are you particularly > > interested in, and I can try and see if our solution will work. Without > > the details, I don't know what you are talking about. Lets not try and > > talk about NAT and IPsec in general, because I think both of these > > protocols are very complex individually, and once you combine them, they > > tend to become intractable. > > > > chinna > > > > -- > Srinivasa Rao Addepalli > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > USA > Ph: 408-844-0480 x317 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 5 13:44:11 2002 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 g25LiA802680; Tue, 5 Mar 2002 13:44:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07079 Tue, 5 Mar 2002 15:55:25 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699BE@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 13:07:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C489.CE961330" 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_000_01C1C489.CE961330 Content-Type: text/plain; charset="iso-8859-1" > > The people who want IPSEC are often different from the people > > performing NAT attacks on them. > > I don't understand your point. For IPsec to work, both parties have to > be willing and interested. If one of those parties puts up a NAT, they > obvoiusly aren't interested. You make the bizare assumption that people have control over their environments. I have much more control over the protocols I use than the network I have access to. Phill ------_=_NextPart_000_01C1C489.CE961330 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C489.CE961330-- From owner-ipsec@lists.tislabs.com Tue Mar 5 14:30:48 2002 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 g25MUl804276; Tue, 5 Mar 2002 14:30:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07487 Tue, 5 Mar 2002 16:54:03 -0500 (EST) Message-ID: <29B5A21C13C8D51190F900805F65B4EC39F0B4@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'Hallam-Baker, Phillip'" , ipsec@lists.tislabs.com Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 17:03:37 -0500 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 I think some people are also making bizarre assumptions that NAT will go away when IPv6 gets deployed. A lot of NAT is deployed today for economic reasons, the cost of getting multiple IP addresses from an ISP is way, way more than the cost of getting just one address. So people/small companies use NAT to multiplex and lower costs. Unless the tariffs are changed, I see no reason to assume that NAT will go away. -lee > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, March 05, 2002 4:08 PM > To: ipsec@lists.tislabs.com > Subject: RE: Towards closure on NAT traversal. > > > > > > The people who want IPSEC are often different from the people > > > performing NAT attacks on them. > > > > I don't understand your point. For IPsec to work, both > parties have to > > be willing and interested. If one of those parties puts up > a NAT, they > > obvoiusly aren't interested. > > You make the bizare assumption that people have control over > their environments. > > I have much more control over the protocols I use than the > network I have access to. > > Phill > > From owner-ipsec@lists.tislabs.com Tue Mar 5 15:14:12 2002 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 g25NEB805056; Tue, 5 Mar 2002 15:14:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07733 Tue, 5 Mar 2002 17:35:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.19131.377227.690909@pkoning.dev.equallogic.com> Date: Tue, 5 Mar 2002 17:46:19 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On Tue, 5 Mar 2002, Stephen Kent wrote: >> Again, I don't think the characterization you're citing is >> accurate. I gave performance-based motivations for why a receiver >> would prefer to use just the SPI for SA lookup in unicast >> contexts. SA lookup is purely a receiver function, and the specs >> have ALWAYS made it clear that the receiver has tremendous leeway >> in selecting SPI values to facilitate lookup. Our clarifications >> in the most recent IDs merely make clear how a receiver can take >> advantage of the flexibility that has always been accorded to >> it. We're not changing the rules, as you seem to suggest; we're >> explaining what a receiver can do within the scope of the protocol >> design, and providing rationale that clarifies when one needs to >> use more than the SPI to select the right SA. >> >> Chinna> We based our design on what the RFC 2401 says: Chinna> " o SPI: the 32-bit value used to distinguish among different Chinna> SAs terminating at the same destination and using the same Chinna> IPsec protocol. [REQUIRED for all implementations] " Chinna> So, RFC 2401 is wrong? No. But you missed something. RFC 2401 gives the receiving end of an SA full authority over the SPI value. It requires that the SPI values must be unique for a given protocol and remote destination. That's the minimum required for demuxing to work. But it does NOT require that SPI values be reused among SAs that have different protocol or destination! If you had a wide CAM, or fast hash lookup of wide keys, you can reuse SPI values and lookup on the {address,SPI,protocol} triple. However, you're also allowed to select SPI values that are unique among all SAs no matter what destination or protocol they belong to. You might do that because you can efficiently look up with small keys, but not with keys > 32 bits. Or you might like the direct indexing scheme I mentioned. All these are permitted by RFC 2401. The problem with your proposal is that a subset of the permitted implementations (and, I suspect, a large subset) would become limited to 64k SAs total, across all destinations. That is not reasonable. paul From owner-ipsec@lists.tislabs.com Tue Mar 5 15:23:53 2002 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 g25NNr805233; Tue, 5 Mar 2002 15:23:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07812 Tue, 5 Mar 2002 17:48:27 -0500 (EST) Date: Tue, 5 Mar 2002 14:59:24 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15493.19131.377227.690909@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 5 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> We based our design on what the RFC 2401 says: > > Chinna> " o SPI: the 32-bit value used to distinguish among different > Chinna> SAs terminating at the same destination and using the same > Chinna> IPsec protocol. [REQUIRED for all implementations] " > > Chinna> So, RFC 2401 is wrong? > > No. But you missed something. > > RFC 2401 gives the receiving end of an SA full authority over the SPI > value. It requires that the SPI values must be unique for a given > protocol and remote destination. That's the minimum required for > demuxing to work. > > But it does NOT require that SPI values be reused among SAs that have > different protocol or destination! "[REQUIRED for all implementations]" > > If you had a wide CAM, or fast hash lookup of wide keys, you can reuse > SPI values and lookup on the {address,SPI,protocol} triple. "[REQUIRED for all implementations]" > > However, you're also allowed to select SPI values that are unique > among all SAs no matter what destination or protocol they belong to. > You might do that because you can efficiently look up with small keys, > but not with keys > 32 bits. Or you might like the direct indexing > scheme I mentioned. > > All these are permitted by RFC 2401. "[REQUIRED for all implementations]" > > The problem with your proposal is that a subset of the permitted > implementations (and, I suspect, a large subset) would become limited > to 64k SAs total, across all destinations. That is not reasonable. "[REQUIRED for all implementations]" When is RFC 2401 being updated? I do NOT think it is fair to point to IDs and implementations do NOT follow the RFC to say that our proposal will have a potential problem. chinna From owner-ipsec@lists.tislabs.com Tue Mar 5 15:27:23 2002 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 g25NRM805300; Tue, 5 Mar 2002 15:27:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07856 Tue, 5 Mar 2002 17:52:24 -0500 (EST) From: "Henrik Levkowetz" To: "Tony Hain" , Subject: RE: Towards closure on NAT traversal. Date: Wed, 6 Mar 2002 00:03:28 +0100 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: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tony Hain wrote: > > Hallam-Baker, Phillip wrote: > > The IESG should do no such thing. IPSEC needs to fix their > > protocol. > > There is nothing wrong with the IPsec protocol in an environment that > doesn't include NAT (read IPv6 here). No. But if one is a vendor attempting to deploy IPsec in gateways and on employees machines at home today, it is necessary to find a solution which will permit co-existence of IPsec with NATs of many varied kinds. In Sweden, where I'm situated, ADSL is being rolled out on a wide front, and many households have multiple machines which they connect through (at best) the one public IP- address they've been given -- or at worst through the one private IP-address they've got. So at least here it's a very real problem, to accomplish consistent NAT traversal for IPsec, today, not tomorrow. There's a potential customer base with existing equipment here which a commercial firm can't ignore. And that equipment is not IPv6 capable. ...... > I would not wish fixing IKE on MidCom (independent of getting it through > a NAT), but the real issue is finding a generalized NAT traversal which > IPsec can use. If every WG does a one-off, it is less likely that any > given path will contain the right set of NAT hacks to make any > applications work. Unfortunately, sometimes a generic NAT traversal mechanism may not take care of a specific protocol's needs, or may give much more overhead than a solution tailored to one specific protocol. By using Mobile-IP's NAT traversal, and running IPsec inside a MIP tunnel, we can today reliably and consistently accomplish NAT traversal for IPsec. IF that is an acceptable solution with acceptable overhead, then all we have to do ( >:-} ) is to deploy Mobile-IP clients and Agents with all IPsec implementations, and the problem is solved. But how many would find that acceptable as a general solution? > > > > > Again it is very clear that what you are really trying to do > > here is to kill NAT by some bizare IETF machinations. Won't > > work, been there tried that. All that approach would do is > > cause the vendors to diverge further. > > No I am not trying to kill NAT, look at RFC-2993 if you still don't > understand. If I was really trying to kill off NAT, the first thing I > would do is spin up 50 WGs to create as divergent and demanding a set of > requirements for implementation as possible. In reality we have MidCom > trying to figure out a common set of requirements that make it > reasonable for NAT vendors to implement them. In that context, this > group should be feeding requirements to MidCom, and leaving the details > to others. >From my understanding of midcom's charter, they will not be looking at NAT traversal solutions, but rather will be defining standards for applications to talk to middleboxes in order to effect better interoperation. This means that any results from midcom will not be of benefit for situations where you want to traverse the NATs which are already deployed in homes and ISP's today. > > > > > I don't think that it is rational to expect NAT + IPSEC to > > provide greater connectivity than NAT alone. NAT reduces the > > functionality of IP, IPSEC + NAT currently eliminates the > > functionality of IP, the objective of IPSEC has to be to > > get IPSEC + NAT to give equivalent functionality to plain NAT. > > Again, your perspective seems warped. IPsec + NAT doesn't eliminate the > functionality of IP, NAT eliminates the functionality of IPsec. This > thread has been about how to remove that blockage, which duplicates the > work of two other WGs. In those cases their charter is explicitly to > make it possible to get through NAT, while the charter here is to focus > on securing the communications path. Which two other WGs is that? Regards, Henrik From owner-ipsec@lists.tislabs.com Tue Mar 5 16:43:12 2002 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 g260hC807423; Tue, 5 Mar 2002 16:43:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08314 Tue, 5 Mar 2002 19:07:00 -0500 (EST) From: "Tony Hain" To: "Hallam-Baker, Phillip" , Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 16:18:31 -0800 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: <2F3EC696EAEED311BB2D009027C3F4F4058699BE@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: > I have much more control over the protocols I use than the > network I have access to. and yet you still insist on beating your head against the NAT wall to make IPv4 work when you could just use a more reasonable protocol where IPsec already works... ;) Tony From owner-ipsec@lists.tislabs.com Tue Mar 5 16:43:18 2002 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 g260hH807433; Tue, 5 Mar 2002 16:43:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08278 Tue, 5 Mar 2002 19:03:46 -0500 (EST) From: "Tony Hain" To: "Dilkie, Lee" , "'Hallam-Baker, Phillip'" , Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 16:15:16 -0800 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: <29B5A21C13C8D51190F900805F65B4EC39F0B4@rndex50.ottawa.mitel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dilkie, Lee wrote: > A lot of NAT is deployed today for economic reasons, the cost > of getting multiple IP addresses from an ISP is way, way more > than the cost of getting just one address. So people/small > companies use NAT to multiplex and lower costs. Unless the > tariffs are changed, I see no reason to assume that NAT will go away. The economic issues of IPv4 addresses are strictly related to the artificial scarcity of conservation. For every public IPv4 /32 you have today, you already have an IPv6 /48 (ie:16 bits for local subnetting - RFC 3056). For every IPv4 NAT connected host with a private address, you have an IPv6 /64 (ie:local use subnet for this machine, or for it to layer-2 bridge - draft-ietf-ngtrans-shipworm). Current allocation policies being recommended to registries for them to provide to their ISP customers; unless you really, really know that the connecting device is a single entity which will not further forward packets, allocate a /48. In any case the minimum allocation to end points is a /64 (ie: subnet). There is no assumption that NAT will magicly go away, and there is a specific form of NAT for translating between IPv6-only nodes and IPv4-only ones. There is however an assumption that we should not be wasting time designing new hacks to work around and optimize IPv4 NAT traversal when the time would be better spent developing IPv6 products that will have a longer lifetime. Tony From owner-ipsec@lists.tislabs.com Tue Mar 5 17:13:46 2002 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 g261Dj807982; Tue, 5 Mar 2002 17:13:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08485 Tue, 5 Mar 2002 19:34:47 -0500 (EST) From: "Tony Hain" To: "Henrik Levkowetz" , Subject: RE: Towards closure on NAT traversal. Date: Tue, 5 Mar 2002 16:46:18 -0800 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henrik Levkowetz wrote: > No. But if one is a vendor attempting to deploy IPsec in gateways > and on employees machines at home today, it is necessary to find > a solution which will permit co-existence of IPsec with NATs of > many varied kinds. In Sweden, where I'm situated, ADSL is being > rolled out on a wide front, and many households have multiple > machines which they connect through (at best) the one public IP- > address they've been given -- or at worst through the one private > IP-address they've got. > > So at least here it's a very real problem, to accomplish consistent > NAT traversal for IPsec, today, not tomorrow. There's a potential > customer base with existing equipment here which a commercial firm > can't ignore. And that equipment is not IPv6 capable. > And IPsec over UDP does this job just fine, in fact I am running that on another machine as I type with a remote X desktop. > ...... > > > I would not wish fixing IKE on MidCom (independent of > getting it through > > a NAT), but the real issue is finding a generalized NAT > traversal which > > IPsec can use. If every WG does a one-off, it is less > likely that any > > given path will contain the right set of NAT hacks to make any > > applications work. > > Unfortunately, sometimes a generic NAT traversal mechanism may > not take care of a specific protocol's needs, or may give much more > overhead than a solution tailored to one specific protocol. Shades of not-invented-here... Overhead comes in many forms, and the one that is being overlooked in this thread is the cost of an additional NAT traversal mechansim that requires implementation resources, testing, troubleshooting, documentation, memory & disk on every machine... > > By using Mobile-IP's NAT traversal, and running IPsec inside a MIP > tunnel, we can today reliably and consistently accomplish NAT > traversal for IPsec. IF that is an acceptable solution with acceptable > overhead, then all we have to do ( >:-} ) is to deploy > Mobile-IP clients > and Agents with all IPsec implementations, and the problem is solved. > > But how many would find that acceptable as a general solution? If we didn't already have IPsec over UDP it might be reasonable. > > From my understanding of midcom's charter, they will not be looking > at NAT traversal solutions, but rather will be defining standards for > applications to talk to middleboxes in order to effect better > interoperation. This means that any results from midcom will not be of > benefit for situations where you want to traverse the NATs which are > already deployed in homes and ISP's today. But taking some period of time to define something completely new here, that will take additional time to implement and ship, and may only work with a subset of existing NATs, is an acceptable approach? > > > Which two other WGs is that? MidCom & IPv6 transition. From owner-ipsec@lists.tislabs.com Tue Mar 5 17:29:48 2002 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 g261Tl808227; Tue, 5 Mar 2002 17:29:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08642 Tue, 5 Mar 2002 19:56:22 -0500 (EST) From: "Henrik Levkowetz" To: "Tony Hain" , Subject: RE: Towards closure on NAT traversal. Date: Wed, 6 Mar 2002 02:07:23 +0100 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: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tony Hain wrote: > > Henrik Levkowetz wrote: > > No. But if one is a vendor attempting to deploy IPsec in gateways > > and on employees machines at home today, it is necessary to find > > a solution which will permit co-existence of IPsec with NATs of > > many varied kinds. In Sweden, where I'm situated, ADSL is being > > rolled out on a wide front, and many households have multiple > > machines which they connect through (at best) the one public IP- > > address they've been given -- or at worst through the one private > > IP-address they've got. > > > > So at least here it's a very real problem, to accomplish consistent > > NAT traversal for IPsec, today, not tomorrow. There's a potential > > customer base with existing equipment here which a commercial firm > > can't ignore. And that equipment is not IPv6 capable. > > > > And IPsec over UDP does this job just fine, in fact I am running that on > another machine as I type with a remote X desktop. Excellent! Does that mean that the job is done and the solution standardized? If we have a consistent IPsec over UDP mechanism, that's fine by me. I'm outta here if the job's done. > > > ...... > > > > > I would not wish fixing IKE on MidCom (independent of > > getting it through > > > a NAT), but the real issue is finding a generalized NAT > > traversal which > > > IPsec can use. If every WG does a one-off, it is less > > likely that any > > > given path will contain the right set of NAT hacks to make any > > > applications work. > > > > Unfortunately, sometimes a generic NAT traversal mechanism may > > not take care of a specific protocol's needs, or may give much more > > overhead than a solution tailored to one specific protocol. > > Shades of not-invented-here... I don't understand what you mean to say by that. > Overhead comes in many forms, and the one > that is being overlooked in this thread is the cost of an additional NAT > traversal mechansim that requires implementation resources, testing, > troubleshooting, documentation, memory & disk on every machine... Additional to what? If you mean additional to a functioning IPsec over UDP standard, I fully agree. The IPsec over UDP drafts were the starting point for our MIP over UDP work, but are they complete and progressing? My impression was that there's some hesitancy here, but I could be woefully wrong; if so, my apologies. > > > > > By using Mobile-IP's NAT traversal, and running IPsec inside a MIP > > tunnel, we can today reliably and consistently accomplish NAT > > traversal for IPsec. IF that is an acceptable solution with acceptable > > overhead, then all we have to do ( >:-} ) is to deploy > > Mobile-IP clients > > and Agents with all IPsec implementations, and the problem is solved. > > > > But how many would find that acceptable as a general solution? > > If we didn't already have IPsec over UDP it might be reasonable. Ok > > > > > From my understanding of midcom's charter, they will not be looking > > at NAT traversal solutions, but rather will be defining standards for > > applications to talk to middleboxes in order to effect better > > interoperation. This means that any results from midcom will not be of > > benefit for situations where you want to traverse the NATs which are > > already deployed in homes and ISP's today. > > But taking some period of time to define something completely new here, > that will take additional time to implement and ship, and may only work > with a subset of existing NATs, is an acceptable approach? Mmm, are you talking of codifying IPsec over UDP, or inventing something different? I don't think anything different is needed, but I think that IPsec over UDP belongs here and would be acceptable. > > > > > > > Which two other WGs is that? > > MidCom & IPv6 transition. Sorry, no sale. Midcom is not doing NAT traversal, and IPv6 is not doing NAT traversal except possibly indirectly, and that's not for currently deployed NATs today. Regards, Henrik From owner-ipsec@lists.tislabs.com Tue Mar 5 17:29:53 2002 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 g261Tq808239; Tue, 5 Mar 2002 17:29:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08630 Tue, 5 Mar 2002 19:55:37 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.27551.530000.737373@gargle.gargle.HOWL> Date: Tue, 5 Mar 2002 20:06:39 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15493.19131.377227.690909@pkoning.dev.equallogic.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > On Tue, 5 Mar 2002, Paul Koning wrote: > > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > Chinna> We based our design on what the RFC 2401 says: > > > > Chinna> " o SPI: the 32-bit value used to distinguish among different > > Chinna> SAs terminating at the same destination and using the same > > Chinna> IPsec protocol. [REQUIRED for all implementations] " > > > > Chinna> So, RFC 2401 is wrong? > > > > No. But you missed something. > > > > RFC 2401 gives the receiving end of an SA full authority over the SPI > > value. It requires that the SPI values must be unique for a given > > protocol and remote destination. That's the minimum required for > > demuxing to work. > > > > But it does NOT require that SPI values be reused among SAs that have > > different protocol or destination! > > "[REQUIRED for all implementations]" > > > > > If you had a wide CAM, or fast hash lookup of wide keys, you can reuse > > SPI values and lookup on the {address,SPI,protocol} triple. > > "[REQUIRED for all implementations]" > ... Judging by the tone of your note, I am probably wasting my time, but I will make one more attempt to explain this to you. Look in RFC 2401, page 46: ... An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. (The "usually" refers to the exception case of manual SAs, where management chooses the SPI.) The creator of the SA -- the receiver for that SA, in the case of dynamic SAs -- may choose the bits of the SPI to facilitate local processing. One such choice is to make the SPI values unique across all SAs in the box. It can do that because SPI values have local significance -- anyone outside the box is explicitly NOT allowed to interpret the bits of the SPI and assume they have any particular meaning. So long as the values are chosen such that the receiver can identify the correct SA, the implementation conforms with the requirement that you keep quoting ad nauseam. Clearly, if the SPI alone is sufficient to identify the SA, then the triple SPI/address/protocol is also sufficient. paul From owner-ipsec@lists.tislabs.com Tue Mar 5 18:10:52 2002 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 g262Aq809266; Tue, 5 Mar 2002 18:10:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08784 Tue, 5 Mar 2002 20:33:32 -0500 (EST) Date: Tue, 5 Mar 2002 17:44:09 -0800 (PST) From: Srinivasa Addepalli To: "Chinna N.R. Pellacuru" cc: Paul Koning , ipsec@lists.tislabs.com Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Solution 3: I had gone through midcom documents. It seems that midcom NAT traversal is different from what we are trying to achieve. But mobileIP working group NAT traversal is similar to what we are discussing here. Is there any interest in using mobileIP nat traversal? It seems that, it works even if IPSEC device gets the private IP address from the local service provider. It works with any other applications too. No changes to IPSEC/IKE and NAT boxes. Once mobile IP is implemented on both ends of communication, it should work. Regards Srini On Mon, 4 Mar 2002, Srinivasa Addepalli wrote: > > Hi Chinna, > As I see it, we are trying to debate on three solutions: > > 1. Supporting ESP ALG in NAT boxes with SPI changes. > 2. NAT traversal as defined in current drafts. > 3. Some independent solution. ( You indicated that independent NAT > discovery > and NAT traversal alerady being taken care off by midcom > working group. So, we can postpone this discussion). > > Solution 2: > By standardizing different UDP port for encapsulating ESP/AH traffic, > it works through all existing NATs (supporting ESP ALG or not). > One disadvantage is that it requires changes to IKE/IPSEC > implementations. > > By having different UDP port, the overhead also comes down by > 8 bytes. But, one more keepalive timer is required to make > the NAT session alive. > > Solution 1: > Have limitations such as only ESP traffic, no AH traffic. > What about Transport Mode? Does this solution support? > SPI modifications which require changes in existing hardware > and software implementations. (It was assumed that SPI selection > is local matter). > What happens if hash value of different SPIs come out to be same? > How does it work, if quick mode responder sends the packets first? > > > Keeping both the solutions in mind, it appears that solution 2 is > better. > > > Regards > Srini > > On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote: > > > On Mon, 4 Mar 2002, Paul Koning wrote: > > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > > > > > Chinna> And considering the fact that an IPsec SA is identified by > > > Chinna> the tuple: Destination, Protocol and SPI, the probability of > > > Chinna> a collision is even lower, and for all practical purposes > > > Chinna> zero. > > > > > > But we're talking about NAT. NAT hides addresses behind it and makes > > > everything look like a single address. > > > > > > So in the context of NAT (at the other end) you have lots of SAs from > > > the same address, and of course the protocol is constant (50). > > > > > > > I think that there seems to be a big problem with people who want to only > > casually look at this problem of NAT and IPsec. I think that these casual > > observers tend to assume that any and every possible scenario of NATs and > > IPsec will work with some solution. You'll have to first take the time to > > understand what is feasible, and what is not. Once you have come up with a > > set of scenarios in which it is feasible to solve this problem, then you > > have to pick a technique that will only work in those scenarios. > > > > Now, given that, please let me know what scenario are you particularly > > interested in, and I can try and see if our solution will work. Without > > the details, I don't know what you are talking about. Lets not try and > > talk about NAT and IPsec in general, because I think both of these > > protocols are very complex individually, and once you combine them, they > > tend to become intractable. > > > > chinna > > > > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Tue Mar 5 18:30:49 2002 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 g262Um809677; Tue, 5 Mar 2002 18:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08958 Tue, 5 Mar 2002 20:54:11 -0500 (EST) Date: Tue, 5 Mar 2002 18:05:08 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15493.27551.530000.737373@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 5 Mar 2002, Paul Koning wrote: > Judging by the tone of your note, I am probably wasting my time, but I > will make one more attempt to explain this to you. Same here. I'll also try and make one last attempt to try and convince you that RFC2401 pretty strongly recomments that the IPsec SA be picked on {dest IP, IPsec protocol, SPI}. First of all, the performance argument is pretty moot. Please clarify your position more: And, are you saying that RFC 2401 is irrelevant to IPsec, because we are fully and more clearly specifying in an update to the ESP RFC, how all IPsec implementations should *implement* their internal SPI selection logic, (which has only local significance). How about an RFC just to specify how all IPsec implementations MUST *implement* their SPI selection. That way there will be no need to update RFC 2401 just because by "mistake" the *implementation* of SPI selection by all IPsec implementations was not specified properly. - Are there any IDs already trying to supercede RFC 2401? - Are there any IDs trying to just specify how all IPsec implemenations MUST *implemnt* their internal SPI selection. - How can an ESP RFC supercede some behaviour in the Architecture RFC? - Are there any IDs that are trying to "fix" this in AH too? - People are already complaining about the number of redirections that are needed becuase there are already too many RFCs that people have to read, to get a basic understanding of IPsec. By having a new kind of dependency where something is specified in one RFC (the Architecture RFC), and "fixed" in another RFC (a new ESP RFC) which is actually superceding another RFC (original ESP RFC), will just make people crazy. According to RFC 2119: "1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. " The excerpts from RFC 2401: excerpt 1: Page 7, Section 4.1 Definition and Scope " A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. " excerpt 2: Page 16, Section 4.4.1 The Security Policy Database (SPD) " For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. " excerpt 3: Page 17, same Section as above " Note that this selector is conceptually different from the "Destination IP Address" field in the tuple used to uniquely identify an SA. When a tunneled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. " excerpt 4: Page 20, Section 4.4.3 Security Association Database (SAD) " For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation. For inbound processing: The following packet fields are used to look up the SA in the SAD: o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] " excerpt 5: " 5.2.1 Selecting and Using an SA or SA Bundle Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are: 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. " excerpt 6: " SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. " excerpt 7: Page 54, B.3 Path MTU Discovery " The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. " excerpt 8: Page 55, section B.3.2 Calculation of PMTU "Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). " chinna From owner-ipsec@lists.tislabs.com Tue Mar 5 20:52:49 2002 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 g264qn812758; Tue, 5 Mar 2002 20:52:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09846 Tue, 5 Mar 2002 23:08:22 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.39144.213313.480106@ryijy.hel.fi.ssh.com> Date: Wed, 6 Mar 2002 06:19:52 +0200 From: Tero Kivinen To: pcn@cisco.com ("Chinna N.R. Pellacuru") CC: Srinivasa Addepalli , Subject: Re: NAT Traversal X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy References: X-Edit-Time: 48 min X-Total-Time: 57 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > - UDP encapsulation schemes require the use of keepalives to keep the > translation alive. That would not be easy to do, particularly if you are > assuming that no one knows what kind of NAT boxes are out there. And, again I will once more repeat, only you are sending keeplives only if there is no other traffic going out, and only from the host that is behind NAT box (i.e the "server" end with fixed ip-address will not ever send them), and also the interval can be configured. > While it is true, not everyone is a "road-warrior". There is a vast > majority of IPsec users who have a home and an office, and can know > and influence what kind of NAT devices are butchering their IPsec > traffic. If they can control the NAT boxes, then fine, they can modify the NAT-T translation lifetime up to 1 hour, and set the keepalive interval of the IPsec to 30 minutes. No need to complain about keepalives consuming bandwidth. > - As people have pointed out, even our solution has a lot of restrictions > on which scenarios are supported. But, those restrictions also apply to > the UDP encapsulation schemes. There are some schemes that claim to > support more scenarios, but when we looked at them, they were paying a > price that we were not willing to pay in terms of implementing a "built-in > NAT". Lets put it this way, if you ever want to get active mode FTP through the NAT that is forwarding IPsec packets, someone who has the clear text traffic must do the translation of the application data. Lets take example. We have IPsec road warrior with laptop. He is in an hotel that provides internet through NAT box. His corporate headquarters have IPsec SGW which he can connect to make connection to the corporate network. The corporate network has internal ftp-site which can be used to get latest evaluation software. Option 1) The client will take IPsec connection to the IPsec SGW. Now the IPsec SGW MUST do some kind of NAT for the IP address of the client coming from the tunnel as he must forward the packet to the internal network and he must ensure that the packets are routed back to him. The client takes connection to the ftp server, he encapsulates the packet to the UDP and sends it out, the hotel NAT will change the outer IP address of the packet. The IPsec SGW will decapsulate the UDP, check the MAC, decrypt the data, notice that the original internal IP header has address that cannot be routed inside the internal network, it modifies it to something that can be routed back to SGW (i.e NAT on the internal header after it is decrypted) and sends it to the network. The ftp server receives the packet send reply back. It ends to the SGW, which will use the existing NAT translation it created in the beginning and after that it will encrypt, mac, encapsulate in UPD and send it to internet. Hotel NAT will again do another NAT transformation for the outer IP header, and then the client will do the decapsulation, decryption, etc. Now when the client needs the IP address for the FTP port command it uses the ip-number from the hotel network, and when the packet will reach the IPsec SGW it must do the application NAT for the FTP port command and change that IP address to something it starts listening and which it can then NAT back to the UDP+IPsec tunnel. Option 2) The client connects to the IPsec SGW and then it will request the IPsec SGW for an internal IP address which it can use in the internal network (dhcp-over-ipsec or similar). Then it will create the IPsec SA using that IP number, which now is routable in the corporate network, meaning that the IPsec SGW does not have to do any NAT for the packets when they are going through it. Again now client can use that IP address it received from the IPsec SGW and use that for the FTP port command, and everything will work fine. The option 2 is much simplier and thats why in most cases you don't need NAT inside the IPsec SGW. If the client always requires internal ip address from the IPsec SGW then we never need it. The simple NAT inside SGW might be needed in case we have a case where the IPsec SGW is actually the IPsec enabled www-server and we use UDP encapsulated transport mode (less overhead) to connect it. In this case the client normally will not request internal ip address from SGW, because it does not need it for normal operations. What we might now need is to have simple address NAT inside the server host in case it has two clients in hotel1 and hotel2 which both decide to give out ip-numbers starting from the 10.0.0.1 and both those clients managed to receive the 10.0.0.1 ip number. When the IPsec processes the packets it knows that this packet came from the tunnel1, and the real ip number of the other end is 10.0.0.1. It can let that packet through (provided that when the www-server replies to the 10.0.0.1 the packet will end up back to the IPsec and it can map that packet back to the tunnel1). When the packet comes from the tunnel2, the IPsec must also NAT it to some other address. To which address, it actually doesn't matter, as the packet never leaves the host, 127.0.1.2 would be as fine as 192.168.1.1, the ip address simply must be such that the operating system will know that this is meant to be tunneled through IPsec and it must be unique between all tunnels. Lets say the internal implementation decided to select first free 10.42.0.0 network address, i.e it selected 10.42.0.1. When the www-server replies the IPsec will see that 10.42.0.1 ip number (which was BTW allocated when the second IPsec SA with overlapping address was created) and it will know that this packet should be forwarded to tunnel2. As the option 2 is so much simplier, and more things work through it I think we should be using it always unless we are talking about the transport mode between client and the server. Using option 2 also in that case (i.e get the ip-address from the IPsec server) even when using transport mode removes the need for application level NAT for the FTP port command for that case also. Of course this means that if the corporate network and the hotel network are using the same ip address space, then only one of them can be used at time (i.e most likely all packets are being forwarded to the IPsec tunnel), but on the other hand that is that most of the SGW adminstrators would want to do anyways (i.e disable access to the other hosts when the VPN tunnel is up, so nobody can use the laptop to attack the corporate network). > That's a whole NAT implementation within IPsec. That is exporting > the NAT functionality to another device that is actually an IPsec device. > It is not easy to manage multiple NAT devices, and it would be almost > impossible to manage multiple NAT devices, and multiple NAT > implementations within each IPsec implementation. Those NATs can be avoided if the hosts connecting to the server are using addresses offered by the server. There is already protocol for that. Also quite often the IPsec SGW contains some kind of firewall capabilities also, and that includes NAT... > > Solution 2: > > By standardizing different UDP port for encapsulating ESP/AH traffic, > > it works through all existing NATs (supporting ESP ALG or not). > > One disadvantage is that it requires changes to IKE/IPSEC > > implementations. > > > > By having different UDP port, the overhead also comes down by > > 8 bytes. But, one more keepalive timer is required to make > > the NAT session alive. Actually if we move the IKE SA traffic at the same time to the new port also then we only need to keep that mapping up. This would happen that in the middle of the main mode or after the main mode, when the initiator knows it is behind NAT it moves all traffic to new port and let the port 500 mapping to die. All traffic then happens with this new port. To get the overhead down we can defined the new port usage so that IKE payloads are identified with 4 bytes of 0 in beginning (i.e the ESP spi field), and the IKE packet starts after that. This makes things little more complicated and the responder needs to update the IKE SA ip and port numbers when it sees the same IKE SA cookies it did see previously but from different ip address and port. I think Dixon has some kind of draft about this, but I don't know the current status of it (I think it waits for me to incorporate it to draft-ietf-ipsec-nat-t-ike-01.txt :-) The reason we don't want directly to start from different port is that that would require either long initial timeout in case the other end does not support new NAT-T (i.e we send packets to port xxxx, but the other end will ignore them and then we fall back to port 500), or we consume more resources by starting two negotiations at the same time one in port 500 and one in port xxxx, and the NAT-T aware implementation would propably answer to both... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 5 21:11:12 2002 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 g265BC813538; Tue, 5 Mar 2002 21:11:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10054 Tue, 5 Mar 2002 23:33:38 -0500 (EST) Date: Tue, 5 Mar 2002 20:44:29 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Tero Kivinen cc: Srinivasa Addepalli , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <15493.39144.213313.480106@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Tero Kivinen wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > - UDP encapsulation schemes require the use of keepalives to keep the > > translation alive. That would not be easy to do, particularly if you are > > assuming that no one knows what kind of NAT boxes are out there. > > And, again I will once more repeat, only you are sending keeplives > only if there is no other traffic going out, and only from the host > that is behind NAT box (i.e the "server" end with fixed ip-address > will not ever send them), and also the interval can be configured. Consider a small router that is providing IPsec protection to a SOHO network. If they are doing "continuous channel implementation", with no "dangling SAs", then the box has the SAs up all the time, and even when there is no data traffic, the router will be forced to keepalive the NAT translations by sending IKE NAT keepalives. If the recommended NAT keepalive timer is 20 seconds (I have seen practical deployment recommendations as low as 9 seconds), that is a lot of bandwidth being consumed by probably a lot of otherwise idle boxes that are trying to keepalive NAT translations. > > > While it is true, not everyone is a "road-warrior". There is a vast > > majority of IPsec users who have a home and an office, and can know > > and influence what kind of NAT devices are butchering their IPsec > > traffic. > > If they can control the NAT boxes, then fine, they can modify the > NAT-T translation lifetime up to 1 hour, and set the keepalive > interval of the IPsec to 30 minutes. No need to complain about > keepalives consuming bandwidth. If they can control the NAT boxes, why should they take a hit of 16 bytes of UDP encapsulation? My complaint is more about the encapsulation overhead here. > > > - As people have pointed out, even our solution has a lot of restrictions > > on which scenarios are supported. But, those restrictions also apply to > > the UDP encapsulation schemes. There are some schemes that claim to > > support more scenarios, but when we looked at them, they were paying a > > price that we were not willing to pay in terms of implementing a "built-in > > NAT". > > Lets put it this way, if you ever want to get active mode FTP through > the NAT that is forwarding IPsec packets, someone who has the clear > text traffic must do the translation of the application data. > I vote for your option #2, because it is simpler, and that is why even we support this scenario only. chinna From owner-ipsec@lists.tislabs.com Tue Mar 5 22:43:24 2002 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 g266hN815044; Tue, 5 Mar 2002 22:43:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10338 Wed, 6 Mar 2002 00:01:55 -0500 (EST) Date: Tue, 5 Mar 2002 21:12:47 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Tero Kivinen cc: Srinivasa Addepalli , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 5 Mar 2002, Chinna N.R. Pellacuru wrote: > On Wed, 6 Mar 2002, Tero Kivinen wrote: > > > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > > - UDP encapsulation schemes require the use of keepalives to keep the > > > translation alive. That would not be easy to do, particularly if you are > > > assuming that no one knows what kind of NAT boxes are out there. > > > > And, again I will once more repeat, only you are sending keeplives > > only if there is no other traffic going out, and only from the host > > that is behind NAT box (i.e the "server" end with fixed ip-address > > will not ever send them), and also the interval can be configured. > > Consider a small router that is providing IPsec protection to a SOHO > network. If they are doing "continuous channel implementation", with no > "dangling SAs", then the box has the SAs up all the time, and even when > there is no data traffic, the router will be forced to keepalive the NAT > translations by sending IKE NAT keepalives. If the recommended NAT > keepalive timer is 20 seconds (I have seen practical deployment > recommendations as low as 9 seconds), that is a lot of bandwidth being > consumed by probably a lot of otherwise idle boxes that are trying to > keepalive NAT translations. > And you seem to suggest that this bandwidth that is being used for IKE NAT keeplives should not be charged by an ISP. Why should an ISP bear such an abuse of their bandwidth, that they cannot charge for? Particulary if you consider an ISP trying to provide DSL or Cable access, where most people are having a little IPsec router (or some other IPsec box) at home connecting to their corporation. The ISP can instead choose to upgrade their NAT boxes, and suggest to all plausible customers to use the SPI matching technique so that bandwidth wastage for both the UDP encapsulation and keepalives can be saved. chinna From owner-ipsec@lists.tislabs.com Wed Mar 6 00:24:14 2002 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 g268OE801568; Wed, 6 Mar 2002 00:24:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11124 Wed, 6 Mar 2002 02:40:52 -0500 (EST) From: "Henrik Levkowetz" To: "Srinivasa Addepalli" Cc: Subject: RE: NAT Traversal Date: Wed, 6 Mar 2002 08:52:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Srini wrote: > > Solution 3: > I had gone through midcom documents. It seems that midcom > NAT traversal is different from what we are trying to > achieve. Yes, traversal solutions through existing NATs does not seem to be in their charter. > > But mobileIP working group NAT traversal is similar to what > we are discussing here. > > Is there any interest in using mobileIP nat traversal? > It seems that, it works even if IPSEC device gets the > private IP address from the local service provider. > It works with any other applications too. > > No changes to IPSEC/IKE and NAT boxes. Once mobile IP is > implemented on both ends of communication, it should work. It DOES work. I'm running IPsec over MIP through NATs every day. But the deployment and byte overhead may seem a bit high? Best, Henrik From owner-ipsec@lists.tislabs.com Wed Mar 6 01:58:09 2002 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 g269w8816115; Wed, 6 Mar 2002 01:58:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA11851 Wed, 6 Mar 2002 04:11:47 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC0173B9B8@highway> From: 827 <827@nu.edu.pk> To: "'ipsec'" Subject: Selector Fields Date: Wed, 6 Mar 2002 14:23:23 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the minimum number of selector fields required to look for an SPD entry? i.e. which fields MUST not be OPAQUE to get an accurate/required entry from the SPD? From owner-ipsec@lists.tislabs.com Wed Mar 6 01:59:15 2002 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 g269xF816410; Wed, 6 Mar 2002 01:59:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA11885 Wed, 6 Mar 2002 04:16:05 -0500 (EST) From: "Henrik Levkowetz" To: "Tero Kivinen" Cc: Subject: RE: NAT Traversal Date: Wed, 6 Mar 2002 10:27:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <15493.39144.213313.480106@ryijy.hel.fi.ssh.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, A thorough and clear summary. It clarified some things for me. Some more comments inline: Tero wrote: > > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > - UDP encapsulation schemes require the use of keepalives to keep the > > translation alive. That would not be easy to do, particularly if you are > > assuming that no one knows what kind of NAT boxes are out there. > > And, again I will once more repeat, only you are sending keeplives > only if there is no other traffic going out, and only from the host > that is behind NAT box (i.e the "server" end with fixed ip-address > will not ever send them), and also the interval can be configured. Right. And ll traffic through a NAT has to live with the fact that the NAT uses timeouts to take down mappings. Keepalives are not particularly bothersome. ...... I'd just want to add that in the scenario below, there is an option 3) which you don't mention, which might be the most feasible: Run IPsec over MIP with MIP's NAT traversal. ,:-). (End of comments -- Henrik) > > Lets put it this way, if you ever want to get active mode FTP through > the NAT that is forwarding IPsec packets, someone who has the clear > text traffic must do the translation of the application data. > > Lets take example. We have IPsec road warrior with laptop. He is > in an hotel that provides internet through NAT box. His corporate > headquarters have IPsec SGW which he can connect to make connection to > the corporate network. The corporate network has internal ftp-site > which can be used to get latest evaluation software. > > Option 1) > > The client will take IPsec connection to the IPsec SGW. Now the IPsec > SGW MUST do some kind of NAT for the IP address of the client coming > from the tunnel as he must forward the packet to the internal network > and he must ensure that the packets are routed back to him. > > The client takes connection to the ftp server, he encapsulates the > packet to the UDP and sends it out, the hotel NAT will change the > outer IP address of the packet. The IPsec SGW will decapsulate the > UDP, check the MAC, decrypt the data, notice that the original > internal IP header has address that cannot be routed inside the > internal network, it modifies it to something that can be routed back > to SGW (i.e NAT on the internal header after it is decrypted) and > sends it to the network. The ftp server receives the packet send reply > back. It ends to the SGW, which will use the existing NAT translation > it created in the beginning and after that it will encrypt, mac, > encapsulate in UPD and send it to internet. Hotel NAT will again do > another NAT transformation for the outer IP header, and then the > client will do the decapsulation, decryption, etc. > > Now when the client needs the IP address for the FTP port command it > uses the ip-number from the hotel network, and when the packet will > reach the IPsec SGW it must do the application NAT for the FTP port > command and change that IP address to something it starts listening > and which it can then NAT back to the UDP+IPsec tunnel. > > Option 2) > > The client connects to the IPsec SGW and then it will request the > IPsec SGW for an internal IP address which it can use in the internal > network (dhcp-over-ipsec or similar). Then it will create the IPsec SA > using that IP number, which now is routable in the corporate network, > meaning that the IPsec SGW does not have to do any NAT for the packets > when they are going through it. Again now client can use that IP > address it received from the IPsec SGW and use that for the FTP port > command, and everything will work fine. > > The option 2 is much simplier and thats why in most cases you don't > need NAT inside the IPsec SGW. If the client always requires internal > ip address from the IPsec SGW then we never need it. > > The simple NAT inside SGW might be needed in case we have a case where > the IPsec SGW is actually the IPsec enabled www-server and we use > UDP encapsulated transport mode (less overhead) to connect it. In this > case the client normally will not request internal ip address from > SGW, because it does not need it for normal operations. What we might > now need is to have simple address NAT inside the server host in case > it has two clients in hotel1 and hotel2 which both decide to give out > ip-numbers starting from the 10.0.0.1 and both those clients managed > to receive the 10.0.0.1 ip number. > > When the IPsec processes the packets it knows that this packet came > from the tunnel1, and the real ip number of the other end is 10.0.0.1. > It can let that packet through (provided that when the www-server > replies to the 10.0.0.1 the packet will end up back to the IPsec and > it can map that packet back to the tunnel1). > > When the packet comes from the tunnel2, the IPsec must also NAT it to > some other address. To which address, it actually doesn't matter, as > the packet never leaves the host, 127.0.1.2 would be as fine as > 192.168.1.1, the ip address simply must be such that the operating > system will know that this is meant to be tunneled through IPsec and > it must be unique between all tunnels. Lets say the internal > implementation decided to select first free 10.42.0.0 network address, > i.e it selected 10.42.0.1. When the www-server replies the IPsec will > see that 10.42.0.1 ip number (which was BTW allocated when the second > IPsec SA with overlapping address was created) and it will know that > this packet should be forwarded to tunnel2. > > As the option 2 is so much simplier, and more things work through it I > think we should be using it always unless we are talking about the > transport mode between client and the server. > > Using option 2 also in that case (i.e get the ip-address from the > IPsec server) even when using transport mode removes the need for > application level NAT for the FTP port command for that case also. > > Of course this means that if the corporate network and the hotel > network are using the same ip address space, then only one of them can > be used at time (i.e most likely all packets are being forwarded to > the IPsec tunnel), but on the other hand that is that most of the SGW > adminstrators would want to do anyways (i.e disable access to the > other hosts when the VPN tunnel is up, so nobody can use the laptop to > attack the corporate network). > > > That's a whole NAT implementation within IPsec. That is exporting > > the NAT functionality to another device that is actually an IPsec device. > > It is not easy to manage multiple NAT devices, and it would be almost > > impossible to manage multiple NAT devices, and multiple NAT > > implementations within each IPsec implementation. > > Those NATs can be avoided if the hosts connecting to the server are > using addresses offered by the server. There is already protocol for > that. Also quite often the IPsec SGW contains some kind of firewall > capabilities also, and that includes NAT... > > > > Solution 2: > > > By standardizing different UDP port for encapsulating ESP/AH traffic, > > > it works through all existing NATs (supporting ESP ALG or not). > > > One disadvantage is that it requires changes to IKE/IPSEC > > > implementations. > > > > > > By having different UDP port, the overhead also comes down by > > > 8 bytes. But, one more keepalive timer is required to make > > > the NAT session alive. > > Actually if we move the IKE SA traffic at the same time to the new > port also then we only need to keep that mapping up. > > This would happen that in the middle of the main mode or after the > main mode, when the initiator knows it is behind NAT it moves all > traffic to new port and let the port 500 mapping to die. All traffic > then happens with this new port. To get the overhead down we can > defined the new port usage so that IKE payloads are identified with 4 > bytes of 0 in beginning (i.e the ESP spi field), and the IKE packet > starts after that. > > This makes things little more complicated and the responder needs to > update the IKE SA ip and port numbers when it sees the same IKE SA > cookies it did see previously but from different ip address and port. > > I think Dixon has some kind of draft about this, but I don't know the > current status of it (I think it waits for me to incorporate it to > draft-ietf-ipsec-nat-t-ike-01.txt :-) > > The reason we don't want directly to start from different port is that > that would require either long initial timeout in case the other end > does not support new NAT-T (i.e we send packets to port xxxx, but the > other end will ignore them and then we fall back to port 500), or we > consume more resources by starting two negotiations at the same time > one in port 500 and one in port xxxx, and the NAT-T aware > implementation would propably answer to both... > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 6 05:59:51 2002 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 g26Dxo803739; Wed, 6 Mar 2002 05:59:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13605 Wed, 6 Mar 2002 08:04:15 -0500 (EST) Message-Id: <200203061315.IAA06206@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Date: Wed, 06 Mar 2002 08:15:44 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Pages : 11 Date : 05-Mar-02 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for mes- sages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-01.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-ietf-ipsec-ciph-aes-xcbc-mac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-01.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: <20020305134238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Mar 6 06:22:07 2002 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 g26EM6804705; Wed, 6 Mar 2002 06:22:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13978 Wed, 6 Mar 2002 08:45:42 -0500 (EST) Date: Wed, 6 Mar 2002 08:56:47 -0500 (EST) From: Henry Spencer To: IP Security List Subject: new implementation-issues draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those interested, draft-spencer-ipsec-ike-implementation-02.txt, the latest version of the IKE Implementation Issues draft by myself and Hugh Redelmeier, is now up in the IETF drafts directories. Comments are welcome. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 6 07:09:53 2002 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 g26F9r806344; Wed, 6 Mar 2002 07:09:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14297 Wed, 6 Mar 2002 09:24:53 -0500 (EST) Message-Id: <5.1.0.14.0.20020306093602.00aa84e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 09:39:42 -0500 To: "Henrik Levkowetz" , "Srinivasa Addepalli" From: Melinda Shore Subject: RE: NAT Traversal Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:52 AM 3/6/02 +0100, Henrik Levkowetz wrote: >Yes, traversal solutions through existing NATs does not seem to >be in their [midcom] charter. It is, actually, but the revised charter hasn't been posted. The work is being referred to informally as "pre-midcom," and includes STUN and a yet-to-be-named protocol to allow NATted servers. Please note that in the case of both midcom and pre-midcom we're trying to allow NATted endpoints to find their public addresses so that they can embed correct information in packet payloads (for protocols like SIP, H.323, RTSP, etc.). We're *not* assuming that the endpoint is going to dink with the IP header or that the IP header is not going to be touched by the NAT. We're up a layer or two. Melinda From owner-ipsec@lists.tislabs.com Wed Mar 6 07:33:16 2002 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 g26FXF807829; Wed, 6 Mar 2002 07:33:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14501 Wed, 6 Mar 2002 09:55:07 -0500 (EST) From: "Henrik Levkowetz" To: "Melinda Shore" , "Srinivasa Addepalli" Cc: Subject: RE: NAT Traversal Date: Wed, 6 Mar 2002 15:48:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <5.1.0.14.0.20020306093602.00aa84e0@localhost> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, that's good info. It seems more appropriate to place STUN with midcom than with SIP, where I believe it originated? It'll be interesting to see what the protocol to allow NATed servers will enable / permit. Thanks, Henrik Melinda Shore wrote: > > At 08:52 AM 3/6/02 +0100, Henrik Levkowetz wrote: > >Yes, traversal solutions through existing NATs does not seem to > >be in their [midcom] charter. > > It is, actually, but the revised charter hasn't been posted. > The work is being referred to informally as "pre-midcom," and > includes STUN and a yet-to-be-named protocol to allow NATted > servers. > > Please note that in the case of both midcom and pre-midcom we're > trying to allow NATted endpoints to find their public addresses > so that they can embed correct information in packet payloads > (for protocols like SIP, H.323, RTSP, etc.). We're *not* assuming > that the endpoint is going to dink with the IP header or that > the IP header is not going to be touched by the NAT. We're up a > layer or two. > > Melinda From owner-ipsec@lists.tislabs.com Wed Mar 6 09:34:45 2002 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 g26HYi814722; Wed, 6 Mar 2002 09:34:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15247 Wed, 6 Mar 2002 11:47:36 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.19142.266098.524569@ryijy.hel.fi.ssh.com> Date: Wed, 6 Mar 2002 18:58:46 +0200 From: Tero Kivinen To: "Chinna N.R. Pellacuru" Cc: Srinivasa Addepalli , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: References: X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 24 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna N.R. Pellacuru writes: > And you seem to suggest that this bandwidth that is being used for IKE NAT > keeplives should not be charged by an ISP. Why not. I didn't say anything about that. Firstly the bandwidth used by them is neglitable. Secondly the user sending those packet can configure them with suitable timeout that the nat box still support. Thirdly the user sending them can also put the TTL of those packet so low that they will only reach the NAT box not the box behind that. > Why should an ISP bear such an abuse of their bandwidth, that they cannot > charge for? Particulary if you consider an ISP trying to provide DSL or ISP has can also filter those packets out if they consider them as an abuse of their network, hopefully they will filter them after the NAT :-) > Cable access, where most people are having a little IPsec router (or some > other IPsec box) at home connecting to their corporation. The ISP can > instead choose to upgrade their NAT boxes, and suggest to all plausible > customers to use the SPI matching technique so that bandwidth wastage for > both the UDP encapsulation and keepalives can be saved. I have to say that for all ISP here in Finland the price for the keepalives is such a neglitable even when sent in 20 second interval as suggested by the draft (I still don't understand why do you keep on using the 9 seconds and assume that nobody can configure it. The draft clearly says that this timeout is "locally configurable parameter with a default value of 20 seconds"). If we assume the ISP is actually account per byte (and I assume here they account only actual data bytes not the ethernet frame bytes). This means that each keepalive is 20 bytes of IP header, 8 bytes of UDP header and 1 byte of payload i.e 29 bytes. If the connection is totally idle (and for some reason we want to keep the SA up and the connection up even when we are not sending any traffic) there will be 4320 keepalive packets sent per day. That means 122 kB per day. The most expensive pay per byte here is something like 2.3736 euros per MB (www.sonera.net when using GRPS on mobile phone to connect to the internet), meaning that those keepalives will cost 0.28 euros per day, and note here that user here wanted to keep completely unused SA up and running for the whole day without configuring the keepalives longer. If the user really cares about costs of the keepalives, he sould propably close the connection when he is not using it, or select operator that uses fixed price (16.6 euros / month). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 6 09:34:54 2002 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 g26HYs814736; Wed, 6 Mar 2002 09:34:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15313 Wed, 6 Mar 2002 11:54:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.19543.762000.134095@gargle.gargle.HOWL> Date: Wed, 6 Mar 2002 12:05:27 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15493.27551.530000.737373@gargle.gargle.HOWL> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > Same here. I'll also try and make one last attempt to try and convince you > that RFC2401 pretty strongly recomments that the IPsec SA be picked on > {dest IP, IPsec protocol, SPI}. There is absolutely nothing in any RFC that requires an IPsec implementation to allow the existence of two inbound SAs for and where DA1 != DA2 || Prot1 != Prot2 such that SPI1 == SPI2. Yes, that's allowed, no, it's not required. Furthermore, there's this point: how many distinct values of DA and Prot are there in a given IPsec implementation in the first place? For an edge device with one WAN-side interface, there may very well be just one possible DA for inbound IPsec traffic -- that WAN interface address. If only ESP is used by the customer, there is just one protocol (50). So it doesn't matter whether the SPI values are distinct among all SAs in the box, or unique only within a single DA and protocol -- because there may easily be just one DA and one protocol. > First of all, the performance argument is pretty moot. Only if you don't care about the price/performance of your product. > Please clarify your position more: > > And, are you saying that RFC 2401 is irrelevant to IPsec, because we are > fully and more clearly specifying in an update to the ESP RFC, how all > IPsec implementations should *implement* their internal SPI selection > logic, (which has only local significance). How about an RFC just to > specify how all IPsec implementations MUST *implement* their SPI > selection. That way there will be no need to update RFC 2401 just because > by "mistake" the *implementation* of SPI selection by all IPsec > implementations was not specified properly. > > - Are there any IDs already trying to supercede RFC 2401? Nothing I said relies in any way, shape, or form on any I-D whatsoever. I'm only talking about what's in the RFCs. Of course RFC 2401 is relevant to IPsec. Why else would I quote from RFC 2401 to support an argument about IPsec? Right now, the RFCs say that choice of SPIs is a local matter. For example, RFC 2409, page 18, says: Different SPIs for each SA (one chosen by the initiator, the other by the responder)... The text from RFC 2401 I quoted earlier makes the same point. So there is specific text that says the choice of SPI values is a local matter done at each end. There is no text that imposes specific requirements on the algorithm used for doing this, with one exception: values 0-255 are reserved. Yes, it would be possible to create an RFC that requires a particular algorithm for SPI assignment. Such an RFC would impose new restrictions, thereby requiring redesign of some IPsec implementations. That redesign will come at a performance penalty if it requires the SA lookup to become more complex. If such a proposed new restriction was well enough justified, it would presumably be adopted. So the real question is: is the specific new restriction which you are proposing -- requring half of the SPI bits to be computed as a function of some other input -- justified by something sufficiently valuable to convince people that they should support this notion? That's for the WG to decide. I've stated my answer, which is "no". The reason is that I don't see a good argument for limiting the max SA count to 64k. Or more precisely, 64k for some currently conforming implementations, and 64k times the number of protocols (1 or 2) times the number of local SA endpoint addresses (which is 1 for a significant class of products/configurations) in the most general case. paul From owner-ipsec@lists.tislabs.com Wed Mar 6 11:26:48 2002 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 g26JQl820226; Wed, 6 Mar 2002 11:26:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16239 Wed, 6 Mar 2002 13:48:01 -0500 (EST) Message-Id: <4.3.2.7.1.20020306103859.00c95f00@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 10:57:13 -0800 To: Srinivasa Addepalli , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Classification engine and IPSEC In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk HI, Sreeni >Hi, > There are some difficult protocols such as FTP, H.323, RTSP, SIP etc.. > These protocols have control connection and several data connections. > Control connection uses standard service port. But data connections > use ephemeral ports, which are negotiated during the control > connection. For example, FTP data connection information goes > as part of 'PORT' command of control connection. > > IPSEC SPD policies can be defined based on transport selectors > such as 'source' and 'dest' ports (ranges) along with IP addresses. > > We see requirement that all packets belonging to a flow > (control and data connections ) should have same security properties. > That is, only one IPSEC policy defined for the service and all > child connections (data connections ) should also use the same > policy. But, this requires interoperability as the other party also > should treat this similar way. Today, we are solving this using > proprietary mechanism and works only with our solutions. When working > with other IPSEC solutions, data connections will follow the IPSEC > policy list to get the new security properties. > > Do people see any requirement like this? If so, how do we solve > this problem such that it is interoperable? this requirement needs, 1) set-up policies for all the connections. a separate policy for each connection. 2) Have one policy which protects the control connection + data connection. First one is fair and simple . We have to treat like any other flow. But in second case there my be some complexity in matching the policy and handling the child connections. Does anybody have a solution for interoperability? -regards -ramana From owner-ipsec@lists.tislabs.com Wed Mar 6 11:26:57 2002 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 g26JQv820239; Wed, 6 Mar 2002 11:26:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16101 Wed, 6 Mar 2002 13:31:35 -0500 (EST) Message-Id: <200203061843.NAA26391@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-00.txt Date: Wed, 06 Mar 2002 13:43:06 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-00.txt Pages : 30 Date : 05-Mar-02 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-00.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-ietf-ipsec-rfc2402bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20020305152455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305152455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Mar 6 11:26:58 2002 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 g26JQv820244; Wed, 6 Mar 2002 11:26:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16224 Wed, 6 Mar 2002 13:46:53 -0500 (EST) Date: Wed, 6 Mar 2002 10:57:41 -0800 (PST) From: Srinivasa Addepalli To: Tero Kivinen cc: "Chinna N.R. Pellacuru" , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: <15493.39144.213313.480106@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Tero Kivinen wrote: > > > > Solution 2: > > > By standardizing different UDP port for encapsulating ESP/AH traffic, > > > it works through all existing NATs (supporting ESP ALG or not). > > > One disadvantage is that it requires changes to IKE/IPSEC > > > implementations. > > > > > > By having different UDP port, the overhead also comes down by > > > 8 bytes. But, one more keepalive timer is required to make > > > the NAT session alive. > > Actually if we move the IKE SA traffic at the same time to the new > port also then we only need to keep that mapping up. > > This would happen that in the middle of the main mode or after the > main mode, when the initiator knows it is behind NAT it moves all > traffic to new port and let the port 500 mapping to die. All traffic > then happens with this new port. To get the overhead down we can > defined the new port usage so that IKE payloads are identified with 4 > bytes of 0 in beginning (i.e the ESP spi field), and the IKE packet > starts after that. > > This makes things little more complicated and the responder needs to > update the IKE SA ip and port numbers when it sees the same IKE SA > cookies it did see previously but from different ip address and port. > > I think Dixon has some kind of draft about this, but I don't know the > current status of it (I think it waits for me to incorporate it to > draft-ietf-ipsec-nat-t-ike-01.txt :-) > > The reason we don't want directly to start from different port is that > that would require either long initial timeout in case the other end > does not support new NAT-T (i.e we send packets to port xxxx, but the > other end will ignore them and then we fall back to port 500), or we > consume more resources by starting two negotiations at the same time > one in port 500 and one in port xxxx, and the NAT-T aware > implementation would propably answer to both... > IKE still can use port 500. I am suggesting that ESP/AH use some other port xxxx as suggested in 5.2 section of draft-ietf-udp-encaps-01.txt. This will reduce the packet overhead for ESP packets to 8 bytes and it works with NAT boxes which already implemented ESP/IKE passthrough. Regards Srini -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Wed Mar 6 11:53:05 2002 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 g26Jr4820859; Wed, 6 Mar 2002 11:53:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16374 Wed, 6 Mar 2002 14:12:42 -0500 (EST) Message-Id: <200203061754.g26HsZUe014422@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: JFK ID payload In-reply-to: Your message of "Tue, 05 Mar 2002 04:21:32 PST." <200203051221.g25CLWN78365@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Mar 2002 12:54:35 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In general, I'd agree. However, allowing for multiple payloads of the same type introduces the potential for confusion, as well as making it difficult to give a concise notation for the protocol. Furthermore, the receiver has to do the same job regardless of the message encoding (the same certs, CRLs, etc. have to be examined); I don't think there is any gain in splitting the payload into multiple instances (or sub-payloads). Am I missing something ? -Angelos In message <200203051221.g25CLWN78365@romeo.rtfm.com>, Eric Rescorla writes: >Section 4.2 of the new draft specifies the value of the ID payload as: > > IDi and IDr is expressed as a single octet specifying the type of > ID used, followed by the ID material. The following ID types are > specified. > > ID tag Meaning > 1 A bundle of one or more PKIX certificates, CRLs, and OCSP > responses, concatenated. > >While this may work in theory, it will be difficult to implement >correctly, since the recipient will be forced to partially parse >the BER of each element in order to determine what type of entity >he's dealing with. In general it would probably be better for >JFK to separate and tag each entity. > >-Ekr > From owner-ipsec@lists.tislabs.com Wed Mar 6 11:53:45 2002 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 g26Jrj820884; Wed, 6 Mar 2002 11:53:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16329 Wed, 6 Mar 2002 14:08:58 -0500 (EST) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6019297C4@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: ipsec@lists.tislabs.com Subject: Regarding the next version of IKE Date: Wed, 6 Mar 2002 14:19:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C543.E37941E0" 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_01C1C543.E37941E0 Content-Type: text/plain; charset="iso-8859-1" Hello, In the interest of stimulating a positive IPSec WG debate on the next version of IKE, I would like to offer a few key observations that my colleagues and I have found in a review of the IKEv2 proposal (February 2002; Harkin, Kaufman, Perlman, et al). A first observation in evaluating the merits of any proposal is the state of or possibility of implementation given what we read. This aspect was the intellectual or common sense criteria we looked for first. Of the 3 proposals discussed at the last meeting (Salt Lake City), only the IKEv2 proposal had enough detail, in our opinion, for organizations to implement the protocol (not just the key exchange) as written. Perhaps by now, March 5, 2002, the other proposals too have been substantially detailed so that the same thing may be said of their work. Thanks to Mr. Paul Hoffman, Director-VPN Consortium, for providing a useful link where this material may be found. A second observation or concern was a proposal's ability to be compatible with deployed devices using IKEv1. Investment costs would indeed be heavy if all v1-enabled devices could no longer play in the next version of the IKE world. The IKEv2 proposal as written offers a methodology whereby an IKEv2/IKEv1 device (or node) can interact with an IKEv1 only device by detecting that single version characteristic and communicate only in v1. This attribute preserves the usability of v1 devices and the end user's huge equipment investment. Some other observations that we found and wish to share with the membership are listed below. They are not ranked in any particular order of importance. * The proposal seems a straightforward key and SA management protocol for IPsec while providing critical functionality. Some of the functionalities that my colleagues and I find important are; inexpensive and graceful rekeying, dead peer detection, support for multiple services co-located at an IP address, and negotiation of peer-dependent IPsec policies. * IKEv2 cryptographic negotiation makes it possible to deploy a new algorithm should that become necessary. This flexibility is in contrast to a situation where a server stipulates the algorithm to use without the benefit of negotiation. * From our analysis, we believe IKEv2 is a complete proposal and doesn't refer to any of the previous documents. (One stop shopping.) It appeared to cleanse or selectively remove the problem areas of v1 without resorting to total amputation of the old. * We believe that it is a positive development to preserve some legacy code that is used and accepted today rather than jettison v1 completely. What works now and is preserved in v2 creates a more acceptable market climate for both vendors and end users as it lessens implementation costs (and fears). * We also see that it provides capability to create multiple phase 2 SAs piggybacking off a single phase 1 SA. Further, the proposal offers clean and low cost rekeying as well as traffic selector negotiation. * IKEv2 hides both identities, and doesn't give proof that the parties intentionally communicated with each other. * Since IKEv2 is a complete proposal, it appears that the authors have thoroughly groomed the v1 protocol and removed the more objectionable bugs. We didn't find in v2 the same v1 problems with traffic selector negotiation and message Ids. Did others find this observation to be true? The authors of JFK have, to their credit, achieved name recognition and favorable press attention in the last several months. Being fairly new to the IETF and IPSec WG in December 2001, it appeared that there was only one alternative to v1 and that was JFK. Further WG involvement and analysis suggests this is not the case and I would invite other members to comment or expand upon the pros or cons listed above. We owe it to ourselves to make an informed decision based on the usability of what we read. Cheers, Dennis Beard 613-768-0323 ------_=_NextPart_001_01C1C543.E37941E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the next version of IKE

Hello,
In the interest of = stimulating a positive IPSec WG debate on the next version of IKE, I = would like to offer a few key observations that my colleagues and I = have found in a review of the IKEv2 proposal (February 2002; Harkin, = Kaufman, Perlman, et al).

A first observation in = evaluating the merits of any proposal is the state of or possibility of = implementation given what we read.  This aspect was the = intellectual or common sense criteria we looked for first.  Of the = 3 proposals discussed at the last meeting (Salt Lake City), only the = IKEv2 proposal had enough detail, in our opinion, for organizations to = implement the protocol (not just the key exchange) as written. Perhaps = by now, March 5, 2002, the other proposals too have been substantially = detailed so that the same thing may be said of their work.  Thanks = to Mr. Paul Hoffman, Director-VPN Consortium, for providing a useful = link where this material may be found.

A second observation or = concern was a proposal's ability to be compatible with deployed devices = using IKEv1.  Investment costs would indeed be heavy if all = v1-enabled devices could no longer play in the next version of the IKE = world.  The IKEv2 proposal as written offers a methodology whereby = an IKEv2/IKEv1 device (or node) can interact with an IKEv1 only device = by detecting that single version characteristic and communicate only in = v1. This attribute preserves the usability of v1 devices and the end = user's huge equipment investment. 

Some other observations that = we found and wish to share with the membership are listed below. They = are not ranked in any particular order of importance.

    ·       The proposal seems a straightforward = key and SA management protocol for IPsec while providing critical = functionality.  Some of the functionalities that my colleagues and = I find important are; inexpensive and graceful rekeying, dead peer = detection, support for multiple services co-located at an IP address, = and negotiation of peer-dependent IPsec policies.

    ·       IKEv2 cryptographic negotiation makes = it possible to deploy a new algorithm should that become = necessary.  This flexibility is in contrast to a situation where a = server stipulates the algorithm to use without the benefit of = negotiation.

    ·       From our analysis, we believe IKEv2 is = a complete proposal and doesn't refer to any of the previous documents. = (One stop shopping.) It appeared to cleanse or selectively remove the = problem areas of v1 without resorting to total amputation of the = old. 

    ·       We believe that it is a positive = development to preserve some legacy code that is used and accepted = today rather than jettison v1 completely.  What works now and is = preserved in v2 creates a more acceptable market climate for both = vendors and end users as it lessens implementation costs (and = fears).

    ·       We also see that it provides = capability to create multiple phase 2 SAs piggybacking off a single = phase 1 SA.  Further, the proposal offers clean and low cost = rekeying as well as traffic selector negotiation.

    ·       IKEv2 hides both identities, and = doesn't give proof that the parties intentionally communicated with = each other.

    ·       Since IKEv2 is a complete proposal, it = appears that the authors have thoroughly groomed the v1 protocol and = removed the more objectionable bugs. We didn't find in v2 the same v1 problems with traffic = selector negotiation and message Ids.   Did others find this = observation to be true?

The authors of JFK have, to = their credit, achieved name recognition and favorable press attention = in the last several months.  Being fairly new to the IETF and = IPSec WG in December 2001, it appeared that there was only one = alternative to v1 and that was JFK.  Further WG involvement and = analysis suggests this is not the case and I would invite other members = to comment or expand upon the pros or cons listed above. We owe it to = ourselves to make an informed decision based on the usability of what = we read.

Cheers,

Dennis Beard
613-768-0323












------_=_NextPart_001_01C1C543.E37941E0-- From owner-ipsec@lists.tislabs.com Wed Mar 6 11:54:52 2002 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 g26Jsp820913; Wed, 6 Mar 2002 11:54:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16377 Wed, 6 Mar 2002 14:12:45 -0500 (EST) Message-Id: <200203061809.g26I9SUe005014@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: JFK Algorithm Choice In-reply-to: Your message of "Mon, 04 Mar 2002 14:58:35 PST." <200203042258.g24MwZN71393@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Mar 2002 13:09:28 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200203042258.g24MwZN71393@romeo.rtfm.com>, Eric Rescorla writes: >I just finished reading the new JFK draft at VPNC and I'm still >unclear on how algorithm choice is supposed to work. > >As I understand it, there are actually two different sets of >algorithms: those used for protecting MSG 3 and MSG 4 (JFK >algorithms) and those used in the SA being established (SA algorithms). Correct. >(1) JFK Algorithm Choice >I think I understand this one, but I'd like to be sure. The >responder provides his choice of algorithms in GRPINFOr in >MSG 2. This includes the digest algorithm, the symmetric >encryption algorithm and one or more DH groups. The initiator >can take them or leave them. Yes. >(2) SA Algorithm Choice >My general understanding of how this works (based on S 2.2) is as >follows: > >(1) The initiator offers some set of algorithms in the SA > payload of MSG 3. >(2) The responder chooses one and sends it in the SA' payload > in MSG 4. > >Is this more or less correct? Yes. In MSG 4, the responder may include additional information (e.g., the SPI for the SA in that direction), as needed. >Questions: >(1) What exactly are the contents of the SA payload. Section >2.1 says: > > sa: Defines the cryptographic and other properties of the Security > Association (SA) the Initiator wants to establish. It contains > a Domain-of-Interpretation, which JFK understands, and an > application-specific bitstring. > >Is the idea here that this is the Security Association payload >described in S 4.6.1 of RFC 2407 (possibly profiled down)? If so, >this appears to be inconsistent with the claim in S 5 that: > > the > acceptable combinations are denoted by 16-bit, unstructured > integers. > >Since this isn't how things are done in 2407, as I understand it. Correct -- it's not RFC 2407. Basically, the SA payload is a TLV with a 32-bit DoI (value 0x00000001 allocated for IPsec), followed by a list of 16-bit algorithm choices, followed by two SPD elements. >(2) You list algorithms that "must be supported". Does this mean >that they must be enabled or merely implemented? It means that a complying JFK implementation should understand these choices. The IPsec layer itself might not support some of these --- there's nothing JFK can do about that :-) >(3) How does the responder indicate that the initiator hasn't >offered any algorithms that it supports? Is there some way to >give a hint? Section 2.5, rejection messages (not discussed in great length). -Angelos From owner-ipsec@lists.tislabs.com Wed Mar 6 12:08:23 2002 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 g26K8N821133; Wed, 6 Mar 2002 12:08:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16549 Wed, 6 Mar 2002 14:25:32 -0500 (EST) Date: Wed, 6 Mar 2002 11:36:31 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15494.19543.762000.134095@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Paul Koning wrote: > Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > > Same here. I'll also try and make one last attempt to try and convince you > > that RFC2401 pretty strongly recomments that the IPsec SA be picked on > > {dest IP, IPsec protocol, SPI}. > > There is absolutely nothing in any RFC that requires an IPsec > implementation to allow the existence of two inbound SAs for > and where DA1 != DA2 || Prot1 != Prot2 > such that SPI1 == SPI2. Yes, that's allowed, no, it's not required. I just want to make sure that there is no technical content in this discussion anymore. We are down to the phase where are trying to figure out what the meaning of "is" is. I agree to your above assertion, and I also want to state that RFC 2401 REQUIRES all IPsec implementations to search the SA on {dest IP, IPsec Protocol, SPI}, and also pretty strongly recommends all IPsec implementations to index their SAD by Destination Address, Protocol and SPI. Do you agree to this? chinna From owner-ipsec@lists.tislabs.com Wed Mar 6 12:51:40 2002 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 g26Kpd822381; Wed, 6 Mar 2002 12:51:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16877 Wed, 6 Mar 2002 15:05:36 -0500 (EST) Date: Wed, 6 Mar 2002 12:16:18 -0800 (PST) From: Srinivasa Addepalli To: Paul Koning cc: pcn@cisco.com, ipsec@lists.tislabs.com Subject: RE: NAT Traversal In-Reply-To: <15494.19543.762000.134095@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk SPI values are not only chosen for performance, but also being used by other functionalities. For example, it being used to indicate MPLS tag to be used to route the packets after the packet is decrypted. The point is that, since the RFC 2401 indicates that, it is locally generated, people started using for different purposes. If we start changing the semantics of SPI field, then other applications start to fail and will not be acceptable. Srini On Wed, 6 Mar 2002, Paul Koning wrote: > Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > > Same here. I'll also try and make one last attempt to try and convince you > > that RFC2401 pretty strongly recomments that the IPsec SA be picked on > > {dest IP, IPsec protocol, SPI}. > > There is absolutely nothing in any RFC that requires an IPsec > implementation to allow the existence of two inbound SAs for > and where DA1 != DA2 || Prot1 != Prot2 > such that SPI1 == SPI2. Yes, that's allowed, no, it's not required. > > Furthermore, there's this point: how many distinct values of DA and > Prot are there in a given IPsec implementation in the first place? > > For an edge device with one WAN-side interface, there may very well be > just one possible DA for inbound IPsec traffic -- that WAN interface > address. If only ESP is used by the customer, there is just one > protocol (50). > > So it doesn't matter whether the SPI values are distinct among all SAs > in the box, or unique only within a single DA and protocol -- because > there may easily be just one DA and one protocol. > > > First of all, the performance argument is pretty moot. > > Only if you don't care about the price/performance of your product. > > > Please clarify your position more: > > > > And, are you saying that RFC 2401 is irrelevant to IPsec, because we are > > fully and more clearly specifying in an update to the ESP RFC, how all > > IPsec implementations should *implement* their internal SPI selection > > logic, (which has only local significance). How about an RFC just to > > specify how all IPsec implementations MUST *implement* their SPI > > selection. That way there will be no need to update RFC 2401 just because > > by "mistake" the *implementation* of SPI selection by all IPsec > > implementations was not specified properly. > > > > - Are there any IDs already trying to supercede RFC 2401? > > Nothing I said relies in any way, shape, or form on any I-D > whatsoever. I'm only talking about what's in the RFCs. > > Of course RFC 2401 is relevant to IPsec. Why else would I quote from > RFC 2401 to support an argument about IPsec? > > Right now, the RFCs say that choice of SPIs is a local matter. For > example, RFC 2409, page 18, says: > > Different SPIs for each SA (one chosen by > the initiator, the other by the responder)... > > The text from RFC 2401 I quoted earlier makes the same point. > > So there is specific text that says the choice of SPI values is a > local matter done at each end. There is no text that imposes specific > requirements on the algorithm used for doing this, with one > exception: values 0-255 are reserved. > > Yes, it would be possible to create an RFC that requires a particular > algorithm for SPI assignment. Such an RFC would impose new > restrictions, thereby requiring redesign of some IPsec > implementations. That redesign will come at a performance penalty > if it requires the SA lookup to become more complex. > > If such a proposed new restriction was well enough justified, it would > presumably be adopted. > > So the real question is: is the specific new restriction which you are > proposing -- requring half of the SPI bits to be computed as a > function of some other input -- justified by something sufficiently > valuable to convince people that they should support this notion? > > That's for the WG to decide. I've stated my answer, which is "no". > The reason is that I don't see a good argument for limiting the max SA > count to 64k. Or more precisely, 64k for some currently conforming > implementations, and 64k times the number of protocols (1 or 2) times > the number of local SA endpoint addresses (which is 1 for a > significant class of products/configurations) in the most general > case. > > paul > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Wed Mar 6 13:14:19 2002 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 g26LEI822762; Wed, 6 Mar 2002 13:14:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17128 Wed, 6 Mar 2002 15:34:18 -0500 (EST) Message-Id: <200203062044.g26KisUZ013606@ack.east.sun.com> From: Bill Sommerfeld To: "Chinna N.R. Pellacuru" cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: Your message of "Wed, 06 Mar 2002 11:36:31 PST." Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Mar 2002 15:44:54 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I agree to your above assertion, and I also want to state that RFC 2401 > REQUIRES all IPsec implementations to search the SA on {dest IP, IPsec > Protocol, SPI}, and also pretty strongly recommends all IPsec > implementations to index their SAD by Destination Address, Protocol and > SPI. This is not my interpretation of 2401. 2401 says that the receiver picks the SPI. A consequence of this is that: - the IPsec protocol value *may* be used as part of the lookup but there is no requirement that it be used. - in the case of unicast traffic, an implementation could assign SPIs in such a way that it need not use the destination address to look up the SA (however, it might examine the destination address in subsequent policy checks). - Bill From owner-ipsec@lists.tislabs.com Wed Mar 6 13:26:25 2002 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 g26LQP823385; Wed, 6 Mar 2002 13:26:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17181 Wed, 6 Mar 2002 15:40:31 -0500 (EST) To: Srinivasa Addepalli Cc: Tero Kivinen , "Chinna N.R. Pellacuru" , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: NAT Traversal References: Date: 06 Mar 2002 15:51:49 -0500 In-Reply-To: Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that you need to keep both the IKE and 'ESPoUDP' connections alive. If you move 'ESPoUDP' to a different port without moving the IKE session, you now have two ports that you need to keep open. You need to keep IKE open in order to allow notify and rekey messages through. The suggestion has been made to move to keep IKE phase-1 as-is but if NAT is detected to move both IKE-phase-2 and ESPoUDP to a new port and reverse the sense of the port, such that ESP traffic requires no extra overhead (beyond the UDP header) and IKE traffic requires a four-byte overhead to indicate its IKE. Personally I like this idea; it seems to be the best of both worlds. You negotiate in IKE as normal, detect the presense of NAT as defined by the NAT-D payloads, and then 'move' the IKE/ESP session to a new port for ESPoUDP encapsulation. -derek Srinivasa Addepalli writes: > IKE still can use port 500. I am suggesting that ESP/AH use some > other port xxxx as suggested in 5.2 section of > draft-ietf-udp-encaps-01.txt. > > This will reduce the packet overhead for ESP packets to 8 bytes > and it works with NAT boxes which already implemented ESP/IKE > passthrough. > > Regards > Srini > > -- > Srinivasa Rao Addepalli > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > USA > Ph: 408-844-0480 x317 > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Mar 6 13:59:57 2002 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 g26Lxv824026; Wed, 6 Mar 2002 13:59:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17404 Wed, 6 Mar 2002 16:13:37 -0500 (EST) Date: Wed, 6 Mar 2002 13:24:26 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Bill Sommerfeld cc: Paul Koning , Subject: Re: NAT Traversal In-Reply-To: <200203062044.g26KisUZ013606@ack.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk " For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI." " For inbound processing: The following packet fields are used to look up the SA in the SAD: o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] " I only see REQUIRED all over this. I don't see a "*may*" anywhere here. Wondering if there are multiple versions of RFC 2401, and we are looking at different versions? In any case, I think you bring up another point. Probably you in your implementation (probably being an "endpoint" IPsec implementation), will only deal with a maximum of a couple of IPsec SAs at any time. I can understand why someone with such a narrow point of view, obviously feels that indexing the SAD by destination address, protocol and SPI for just a couple of IPsec SAs, is such a performance hog and also so obviously feels that they are unnecessarily complicating the SAD data structures. You should atleast try and visualize how an implementation that is claiming to support hunderds of thousands of IPsec peers simultaneously, should implement their SAD. There are various reasons for having more structure to the SAD (I can't beleive that we are discussing this implementation stuff on a WG maillist!). You want to classify your SAD entires on Destination address, and Protocol because we need to consult the SAD for other purposes, than just finding an SA. For example we would want to know if we have any IPsec SAs to a peer with a particular Destination IP address, in order to decide whether to send an Initial Contact. Walking through your entire hash table which is indexed only on the SPI, and looking at each IPsec SA, and looking at the peer address is one way to do it. But, that is not an efficient way to do it, even if you have a reasonable number of IPsec SAs in your SAD. On top of that we maintain multiple SADs per box. Probably one per interface and one per VPN routing/forwarding instances (VRF). So it becomes pretty inefficient pretty quick if you don't have more structure in your SAD. So, we endup with different kinds of indexing for different purposes. If we are doing something pretty often, in order to optimise just that query to the SAD, we might endup with another parellel indexing scheme for the SAD. Good for you, you probably don't have to deal with all this complicated stuff. Unfortunately, we have to. So, please try to understand our position too. thanks, chinna On Wed, 6 Mar 2002, Bill Sommerfeld wrote: > > I agree to your above assertion, and I also want to state that RFC 2401 > > REQUIRES all IPsec implementations to search the SA on {dest IP, IPsec > > Protocol, SPI}, and also pretty strongly recommends all IPsec > > implementations to index their SAD by Destination Address, Protocol and > > SPI. > > This is not my interpretation of 2401. 2401 says that the receiver > picks the SPI. A consequence of this is that: > > - the IPsec protocol value *may* be used as part of the lookup but > there is no requirement that it be used. > > - in the case of unicast traffic, an implementation could assign SPIs > in such a way that it need not use the destination address to look up the > SA (however, it might examine the destination address in subsequent > policy checks). > > - Bill > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 6 14:07:54 2002 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 g26M7r824242; Wed, 6 Mar 2002 14:07:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17558 Wed, 6 Mar 2002 16:28:09 -0500 (EST) Message-Id: <200203062138.g26LchUZ013762@ack.east.sun.com> From: Bill Sommerfeld To: "Chinna N.R. Pellacuru" cc: Bill Sommerfeld , Paul Koning , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: Your message of "Wed, 06 Mar 2002 13:24:26 PST." Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Mar 2002 16:38:43 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, Please see also: The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. This means that *IN PRACTICE*, the "REQUIRED" verbiage you cite means very little. Moreover, the author of 2401 has stated in public on several occasions without objection that the "REQUIRED" bits will be weakened in a 2401 followon. > In any case, I think you bring up another point. Probably you in your > implementation (probably being an "endpoint" IPsec implementation), will > only deal with a maximum of a couple of IPsec SAs at any time. Please keep ad-hominem attacks off the list. The Solaris IPsec implementation handles quite a few more SAs than that. - Bill From owner-ipsec@lists.tislabs.com Wed Mar 6 14:41:28 2002 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 g26MfS825153; Wed, 6 Mar 2002 14:41:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17818 Wed, 6 Mar 2002 17:02:43 -0500 (EST) Date: Wed, 6 Mar 2002 14:13:45 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Bill Sommerfeld cc: Paul Koning , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <200203062138.g26LchUZ013762@ack.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Bill Sommerfeld wrote: > Chinna, > > Please see also: > > The receiver-orientation of the Security Association implies that, in > the case of unicast traffic, the destination system will normally > select the SPI value. By having the destination select the SPI > value, there is no potential for manually configured Security > Associations to conflict with automatically configured (e.g., via a > key management protocol) Security Associations or for Security > Associations from multiple sources to conflict with each other. > > This means that *IN PRACTICE*, the "REQUIRED" verbiage you cite means > very little. "REQUIRED" in an RFC means nothing, but an obscure paragraph that is trying to say something about multicast and manually configured SAs MUST be followed *IN PRACTICE*. The paragraph is trying to suggest an exception to the regular SA selection process, in the case of a remote possibility that someone has setup Manual IPsec SAs to protect Multicast traffic. That is my understanding of the above paragraph. > > Moreover, the author of 2401 has stated in public on several occasions > without objection that the "REQUIRED" bits will be weakened in a 2401 > followon. Sorry for having missed these suggestions in the past. There's so much going on in this WG, it's hard to keep track of what is happening anymore. Even if the "REQUIRED" bits are weakened, I hope Steve is OK with not mandating that IPsec implementations are "NOT REQUIRED" to find an SA based on {dest IP, protocol, SPI}. I do not see why an RFC should say that all IPsec implementations "MUST NOT" use {dest IP, protocol, SPI} to pick and SA, because it is not very efficient if you have a small number of IPsec SAs. I also don't see why and RFC should say, all IPsec implementations "MUST" use only the SPI to pick an IPsec SA, because it is much more efficient if you have a small number of IPsec SAs. I would like to strongly object to any RFC that is trying to mandate what exact SPI selection logic needs to be used by *ALL* IPsec implementations. Why should the SAID space be delibirately reduced by 33 bits for no reason. Not everybody has to implement every proposal that is being considered by the IETF. Not everybody needs to implement our proposal. Our proposal is not central to the basic working of IPsec. If someone wants to traverse through NATs, they can implement a proposal that suits them. So, I don't see why the general IPsec community should worry about us reducing the SPI space by 16 bits. If there is enough flexibility in the SA selection, those who want to use our SPI matching technique, will choose to use {dest IP, protocol, SPI} to pick their SAs. As you said, this is totally internal implementation logic, and an understanding between the parties that want to interoperate using our particular proposal. The whole IPsec community in general is not doing special stuff for navigating through MPLS that someone else suggested. chinna From owner-ipsec@lists.tislabs.com Wed Mar 6 15:21:18 2002 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 g26NLI826067; Wed, 6 Mar 2002 15:21:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18107 Wed, 6 Mar 2002 17:37:04 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.40103.826000.692699@gargle.gargle.HOWL> Date: Wed, 6 Mar 2002 17:48:07 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15494.19543.762000.134095@gargle.gargle.HOWL> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 6 March 2002) by Chinna N.R. Pellacuru: > On Wed, 6 Mar 2002, Paul Koning wrote: > > > Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > > > Same here. I'll also try and make one last attempt to try and convince you > > > that RFC2401 pretty strongly recomments that the IPsec SA be picked on > > > {dest IP, IPsec protocol, SPI}. > > > > There is absolutely nothing in any RFC that requires an IPsec > > implementation to allow the existence of two inbound SAs for > > and where DA1 != DA2 || Prot1 != Prot2 > > such that SPI1 == SPI2. Yes, that's allowed, no, it's not required. > > I just want to make sure that there is no technical content in this > discussion anymore. > > We are down to the phase where are trying to figure out what the meaning > of "is" is. I find your attempt to compare me with William J. Clinton utterly offensive and entirely unacceptable for a technical discussion. paul From owner-ipsec@lists.tislabs.com Wed Mar 6 15:22:04 2002 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 g26NM3826093; Wed, 6 Mar 2002 15:22:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18052 Wed, 6 Mar 2002 17:34:41 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699D1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dennis Beard'" , ipsec@lists.tislabs.com Subject: RE: Regarding the next version of IKE Date: Wed, 6 Mar 2002 14:47:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C560.D3964EE0" 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_000_01C1C560.D3964EE0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C560.D3964EE0" ------_=_NextPart_001_01C1C560.D3964EE0 Content-Type: text/plain; charset="iso-8859-1" I am not convinced that compatibility with IKEv1 needs to be an overiding concern at this stage, however it is certainly an advantage. Although IPSEC is in principle a peer-peer protocol current deployment is largely to support VPNs, the killer app being securing remote access. I am not particularly concerned about IPSEC embedded in operating systems, security patches are not uncommon these days. A simpler IKE that is 'backwards compatible' would be nice, but how much compatibility would I really get in practice? The penalty for losing backwards compatibility will be starting adoption from a lower base, but I might be willing to swap that for a higher rate of adoption. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_001_01C1C560.D3964EE0 Content-Type: text/html; charset="iso-8859-1" Regarding the next version of IKE
I am not convinced that compatibility with IKEv1 needs to be an overiding concern at this stage, however it is certainly an advantage.
 
Although IPSEC is in principle a peer-peer protocol current deployment is largely to support VPNs, the killer app being securing remote access. I am not particularly concerned about IPSEC embedded in operating systems, security patches are not uncommon these days.
 
A simpler IKE that is 'backwards compatible' would be nice, but how much compatibility would I really get in practice?
 
The penalty for losing backwards compatibility will be starting adoption from a lower base, but I might be willing to swap that for a higher rate of adoption.
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227



 
------_=_NextPart_001_01C1C560.D3964EE0-- ------_=_NextPart_000_01C1C560.D3964EE0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C560.D3964EE0-- From owner-ipsec@lists.tislabs.com Wed Mar 6 15:34:50 2002 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 g26NYo826354; Wed, 6 Mar 2002 15:34:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18237 Wed, 6 Mar 2002 17:54:04 -0500 (EST) Message-ID: <009801c1c563$509794b0$272745ab@cisco.com> From: "Scott Fanning" To: "Hallam-Baker, Phillip" , "'Dennis Beard'" , References: <2F3EC696EAEED311BB2D009027C3F4F4058699D1@vhqpostal.verisign.com> Subject: Re: Regarding the next version of IKE Date: Wed, 6 Mar 2002 15:04:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01C1C520.42638BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C1C520.42638BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the next version of IKEI think I brought this issue up a = couple of months ago. The resounding answer at the time is that the = version number in the isakmp hdr is enough to direct message to the = correct process running a specific IKE version. I think there is some = code reuse here (although that is a debatable requirement as well). On a very different note: Also, I was wondering if it would be possible to add a "message type" in = the isakmp hdr in the IKEv2 (Harkins et al) to indicate what part of the = exchange the message represents. This would be different than the = "Exchange Type" as it would offer a finer level of granularity. I know = you can look at how the message is constructed to determine that = information, but it seems to be that a simple identifier to validate a = message against a state machine would be a cheaper operation. Of course, = it does not remove the requirement to examine the payloads to ensure = that all is in order. Just an idea. Scott ----- Original Message -----=20 From: Hallam-Baker, Phillip=20 To: 'Dennis Beard' ; ipsec@lists.tislabs.com=20 Sent: Wednesday, March 06, 2002 2:47 PM Subject: RE: Regarding the next version of IKE I am not convinced that compatibility with IKEv1 needs to be an = overiding concern at this stage, however it is certainly an advantage. Although IPSEC is in principle a peer-peer protocol current deployment = is largely to support VPNs, the killer app being securing remote access. = I am not particularly concerned about IPSEC embedded in operating = systems, security patches are not uncommon these days. A simpler IKE that is 'backwards compatible' would be nice, but how = much compatibility would I really get in practice? The penalty for losing backwards compatibility will be starting = adoption from a lower base, but I might be willing to swap that for a = higher rate of adoption. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 =20 ------=_NextPart_000_0095_01C1C520.42638BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the next version of IKE
I think I brought this issue up a = couple of months=20 ago. The resounding answer at the time is that the version number in the = isakmp=20 hdr is enough to direct message to the correct process running a = specific IKE=20 version. I think there is some code reuse here (although that is a = debatable=20 requirement as well).
 
On a very different note:
 
Also, I was wondering if it would be = possible to=20 add a "message type" in the isakmp hdr in the IKEv2 (Harkins et al) to = indicate=20 what part of the exchange the message represents. This would be = different than=20 the "Exchange Type" as it would offer a finer level of granularity. I = know you=20 can look at how the message is constructed to determine that = information, but it=20 seems to be that a simple identifier to validate a message against a = state=20 machine would be a cheaper operation. Of course, it does not remove the=20 requirement to examine the payloads to ensure that all is in order. Just = an=20 idea.
 
Scott
----- Original Message -----
From:=20 Hallam-Baker,=20 Phillip
To: 'Dennis Beard' ; ipsec@lists.tislabs.com =
Sent: Wednesday, March 06, 2002 = 2:47=20 PM
Subject: RE: Regarding the next = version=20 of IKE

I am=20 not convinced that compatibility with IKEv1 needs to be an overiding = concern=20 at this stage, however it is certainly an = advantage.
 
Although IPSEC is in principle a peer-peer = protocol=20 current deployment is largely to support VPNs, the killer app = being=20 securing remote access. I am not particularly concerned about IPSEC = embedded=20 in operating systems, security patches are not uncommon these=20 days.
 
A=20 simpler IKE that is 'backwards compatible' would be nice, but how much = compatibility would I really get in practice?
 
The=20 penalty for losing backwards compatibility will be starting adoption = from a=20 lower base, but I might be willing to swap that for a higher rate = of=20 adoption.
 
       =20 Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal=20 Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996=20 x227



 
------=_NextPart_000_0095_01C1C520.42638BD0-- From owner-ipsec@lists.tislabs.com Wed Mar 6 15:53:01 2002 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 g26Nr0827107; Wed, 6 Mar 2002 15:53:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18390 Wed, 6 Mar 2002 18:10:17 -0500 (EST) Date: Wed, 6 Mar 2002 15:21:22 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15494.40103.826000.692699@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Paul Koning wrote: > Excerpt of message (sent 6 March 2002) by Chinna N.R. Pellacuru: > > On Wed, 6 Mar 2002, Paul Koning wrote: > > > > > Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru: > > > > Same here. I'll also try and make one last attempt to try and convince you > > > > that RFC2401 pretty strongly recomments that the IPsec SA be picked on > > > > {dest IP, IPsec protocol, SPI}. > > > > > > There is absolutely nothing in any RFC that requires an IPsec > > > implementation to allow the existence of two inbound SAs for > > > and where DA1 != DA2 || Prot1 != Prot2 > > > such that SPI1 == SPI2. Yes, that's allowed, no, it's not required. > > > > I just want to make sure that there is no technical content in this > > discussion anymore. > > > > We are down to the phase where are trying to figure out what the meaning > > of "is" is. > > I find your attempt to compare me with William J. Clinton utterly > offensive and entirely unacceptable for a technical discussion. > > paul > I found your comment about our implementation being "all hole" utterly offensive and entirely unacceptable for a technical discussion. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 6 16:25:30 2002 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 g270PU827945; Wed, 6 Mar 2002 16:25:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18589 Wed, 6 Mar 2002 18:41:10 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <009801c1c563$509794b0$272745ab@cisco.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058699D1@vhqpostal.verisign.com> <009801c1c563$509794b0$272745ab@cisco.com> Date: Wed, 6 Mar 2002 15:52:35 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Regarding the next version of IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:04 PM -0800 3/6/02, Scott Fanning wrote: >I think I brought this issue up a couple of months ago. The >resounding answer at the time is that the version number in the >isakmp hdr is enough to direct message to the correct process >running a specific IKE version. I think there is some code reuse >here (although that is a debatable requirement as well). Note that the on-the-wire protocol in JFK is not set in stone. It could easily be changed to look almost identical to IKEv2; that is, I have already written up that change. If the WG wants the features of JFK but to have it run on port 500 and look enough like IKEv2 so that it will not crash an IKEv1 implementation, that is pretty easy. >On a very different note: > >Also, I was wondering if it would be possible to add a "message >type" in the isakmp hdr in the IKEv2 (Harkins et al) to indicate >what part of the exchange the message represents. This would be >different than the "Exchange Type" as it would offer a finer level >of granularity. I know you can look at how the message is >constructed to determine that information, but it seems to be that a >simple identifier to validate a message against a state machine >would be a cheaper operation. Of course, it does not remove the >requirement to examine the payloads to ensure that all is in order. >Just an idea. Or, instead of changing the ISAKMP header, you could add granularity to the new exchange types. Instead of the current: Phase One 34 CREATE-CHILD-SA 35 Informational 36 You might have: Phase One message 1 34 Phase One message 2 35 Phase One message 3 36 . . . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 6 17:10:46 2002 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 g271Ak828706; Wed, 6 Mar 2002 17:10:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18939 Wed, 6 Mar 2002 19:26:29 -0500 (EST) To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: JFK ID payload References: <200203061754.g26HsZUe014422@nyarlathotep.keromytis.org> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 06 Mar 2002 16:37:41 -0800 In-Reply-To: "Angelos D. Keromytis"'s message of "Wed, 06 Mar 2002 12:54:35 -0500" Message-ID: Lines: 47 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Angelos D. Keromytis" writes: > In general, I'd agree. However, allowing for multiple payloads of the > same type introduces the potential for confusion, as well as making it > difficult to give a concise notation for the protocol. Furthermore, the > receiver has to do the same job regardless of the message encoding (the > same certs, CRLs, etc. have to be examined); I don't think there is any > gain in splitting the payload into multiple instances (or sub-payloads). > Am I missing something ? I think so. My point is that certs, CRLs, and OCSP responses aren't tagged. Here's the ASN.1 for the first couple fields of the each structure: CERTIFICATE Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, CRL CertificateList ::= SIGNED { SEQUENCE { version Version OPTIONAL, -- if present, shall be v2 signature AlgorithmIdentifier, OCSP response OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } If these structures are just concatenated, then the recipient needs to do something like: if(parseCertificate()==SUCCESS){ ... } else if(parseCRL()==SUCCESS)){ ... } else if(parseOCSPResponse()==SUCCESS){ ... } This isn't much fun. It would be a lot easier if the various chunks were wrapped in a TLV wrapper, thus saving you from having to do it. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Mar 6 17:30:03 2002 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 g271U3829066; Wed, 6 Mar 2002 17:30:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19128 Wed, 6 Mar 2002 19:48:03 -0500 (EST) Message-Id: <200203070059.g270xlN87810@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: Choosing between IKEv2 and JFK Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Mar 2002 16:59:47 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk INTRODUCTION The WG milestones say that we're supposed to select an IKE-replacement protocol design in April so it's probably time to start thinking about this now. Although neither of the leading contenders is completely nailed down, the direction they're heading is clear enough that we should be able to pick a winner at MSP or shortly thereafter. In the interest of reaching a decision, here are my top 5 differences between IKEv2 and JFK. I attempt to discuss each issue a bit but I'm not taking sides here, just trying to elucidate the relevant differences in a single document. (1) Algorithm Negotiation (2) 2-phase handshake (3) Management messages (4) Non-public-key authentication (5) DoS protection Note that I've deliberately not mentioned the cryptographic core, for two reasons: (1) The cores are actually quite similar. (2) Both groups seem perfectly willing to adapt a different core if that's what the WG group wants. (In fact, JFKr adopts SIGMA's core). In my view, the important differences between JFK and IKEv2 are in the stuff that surrounds the cryptographic core, rather than the core itself. ALGORITHM NEGOTIATION IKEv2 follows a fairly traditional approach to algorithm negotiation. The initiator offers the algorithms he's happy with and the responder selects among them. This is the same general approach used by TLS. JFK uses two different approaches, one for negotiating protection of the rest of the handshake and one for the IPsec traffic to be protected. The handshake protection algorithms are not negotiated--the responder simply chooses and the initiator can take it or leave it (with the exception of the DH group, which is proposed by the responder and chosen by the initiator). The traffic protection negotiation is conceptually similar to that of IKEv2, with some simplifications: namely that it uses cipher suites instead of proposals and has a simplified traffic selector model. The former was proposed (but rejected) by the IKEv2 authors. Discussion: I'm not sure how relevant this difference is in practice. There's been a lot of discussion of JFK not negotiating, but that really only applies to the handshake-protection algorithms. SA algorithms are negotiated in JFK, just as in IKEv2, albeit with a rather simpler negotiation model. It would be easy to graft IKEv2's negotiation model onto JFK (especially since JFK's negotiation is somewhat underspecified in the spec), or alternately, to simplify IKEv2's negotiation so it looks more like JFK's. [0] 2-PHASE HANDSHAKE [This section refers only to keying material establishment. The next section discusses the use of phase II for management traffic.] IKEv2 uses the same two-phase approach as IKE. The peers first negotiate an SA for protecting the rest of the handshake (the IKE SA) and then negotiate a second SA for protecting traffic. The idea here is that you might want to use different SAs for different traffic flows but don't want to perform a new DH exchange for each SA establishment. Once you have the "IKE SA" established you can use that to create other SAs for individual traffic flows. In order to minimize round trips, you can establish a single traffic SA at the same time as you establish the IKE SA. JFK does not have two phases. If you want multiple SAs you do multiple JFK handshakes. The rationale is as follows. We also feel that JFK is efficient enough that avoiding the overhead of a full key exchange is not required. Rather than add new SAs to an existing Phase I SA, we suggest that a full JFK exchange be initiated instead. We note that the client can also choose to reuse its exponential, it if wishes to trade perfect forward secrecy for computation time. Discussion: This ultimately comes down to performance: is it too expensive to perform a new exchange for each traffic flow or not? Although JFK is lighter weight than IKEv2, the reduced complexity is largely in protocol processing, not cryptography. Extensive experience with SSL performance tuning suggests that the vast majority of the time in both JFK and IKEv2 will be in the cryptographic computations, which are essentially identical. The question, then, is whether IPsec implementations need to negotiate a lot of different SAs for any given set of peers or not. In principle this is an empirical question, but I don't know if we have enough deployment experience to decide one way or the other. MANAGEMENT TRAFFIC Aside from child SA creation, IKEv2 allows a number of other messages to be transmitted in Phase II, using the IKE SA. These messages are primarily for management purposes including: (1) Dead peer detection (2) Rekeying (3) Deletion JFK doesn't have a Phase II and uses separate and somewhat ad hoc mechanisms for each of these: (1) Dead peer detection is done with pings. (2) Rekeying and deletion are both done via a new SA exchange (you delete by offering a zero lifetime). Discussion: The right approach really depends on how much is going to be done in the Phase II exchange. Any individual one of these tasks can be performed by other mechanisms (though JFK SA deletion is clumsy). However, if we want all three features, it may be better to simply write them into the protocol rather than develop ad hoc techniques for each one. NON PUBLIC-KEY AUTHENTICATION IKEv2 supports both public key authentication and shared-key based authentication. JFK supports only public key authentication, with the expectation that they will be supported via some outboard protocol. Discussion: As we've seen from mailing list traffic, this is an incredibly controversial issue. Despite our best efforts to the contrary, legacy authentication systems which support/use shared keys aren't going away any time soon and I'm not sure that there's any point in standing athwart history yelling "Stop". DoS PROTECTION and COOKIE EXCHANGE IKEv2 uses a variable-round-trip handshake, with 4 messages under normal circumstances and 6 under attack. The extra two messages are a simple cookie exchange designed to force the attacker to prove that he has a round-trip to the responsder. JFK uses 4 messages in all cases. DoS protection is achieved by not creating JFK state until message 3 has been read. Discussion: Both protocols are resistant to DoS attacks based on computational loading. JFK is slightly more network efficient under attack because it has two fewer messages. However, it is more susceptible to an IP fragmentation memory consumption attack where the attacker sends a series of partial messages to consume reassembly buffers, thus blocking delivery of legitimate fragmented message 3s. If one assumes a rather intimate relationship between IKEv2 and the TCP stack, IKEv2 is less susceptible to this attack. FINAL COMMENTS Although neither IKEv2 nor JFK is completely finished, I think it's clear enough what direction they're following to choose which protocol we're going to pursue. I've attempted to list what I consider to be the major technical (as opposed to stylistic) differences between the two protocols. If people feel that I've missed some important difference, please point it out and I'll try to cover that as well. -Ekr [0] Incidentally, why does JFK have two different sets of algorithms? It seems like life would be simpler if the algorithms used for traffic protection were the same as those used for the handshake. I suppose one might complain if the SA negotiated message integrity only but I can't see that peers who don't care about confidentiality care about identity protection. From owner-ipsec@lists.tislabs.com Wed Mar 6 17:46:46 2002 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 g271kj829366; Wed, 6 Mar 2002 17:46:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19283 Wed, 6 Mar 2002 20:07:04 -0500 (EST) Message-ID: <001f01c1c575$e1ea78d0$1e80ad40@cisco.com> From: "Scott Fanning" To: , "Paul Hoffman / VPNC" References: <2F3EC696EAEED311BB2D009027C3F4F4058699D1@vhqpostal.verisign.com> <009801c1c563$509794b0$272745ab@cisco.com> Subject: Re: Regarding the next version of IKE Date: Wed, 6 Mar 2002 17:17:42 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was thinking about that, but I was not sure if we wanted to overload the meaning of the field. You might want to say that I am in Message X of Exchange Type Y. Scott ----- Original Message ----- From: "Paul Hoffman / VPNC" To: Sent: Wednesday, March 06, 2002 3:52 PM Subject: Re: Regarding the next version of IKE > At 3:04 PM -0800 3/6/02, Scott Fanning wrote: > >I think I brought this issue up a couple of months ago. The > >resounding answer at the time is that the version number in the > >isakmp hdr is enough to direct message to the correct process > >running a specific IKE version. I think there is some code reuse > >here (although that is a debatable requirement as well). > > Note that the on-the-wire protocol in JFK is not set in stone. It > could easily be changed to look almost identical to IKEv2; that is, I > have already written up that change. If the WG wants the features of > JFK but to have it run on port 500 and look enough like IKEv2 so that > it will not crash an IKEv1 implementation, that is pretty easy. > > >On a very different note: > > > >Also, I was wondering if it would be possible to add a "message > >type" in the isakmp hdr in the IKEv2 (Harkins et al) to indicate > >what part of the exchange the message represents. This would be > >different than the "Exchange Type" as it would offer a finer level > >of granularity. I know you can look at how the message is > >constructed to determine that information, but it seems to be that a > >simple identifier to validate a message against a state machine > >would be a cheaper operation. Of course, it does not remove the > >requirement to examine the payloads to ensure that all is in order. > >Just an idea. > > Or, instead of changing the ISAKMP header, you could add granularity > to the new exchange types. Instead of the current: > Phase One 34 > CREATE-CHILD-SA 35 > Informational 36 > You might have: > Phase One message 1 34 > Phase One message 2 35 > Phase One message 3 36 > . > . > . > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 6 18:29:25 2002 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 g272TO801199; Wed, 6 Mar 2002 18:29:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19615 Wed, 6 Mar 2002 20:46:38 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 13:33:38 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:05 PM -0800 3/5/02, Chinna N.R. Pellacuru wrote: >On Tue, 5 Mar 2002, Paul Koning wrote: >> Judging by the tone of your note, I am probably wasting my time, but I >> will make one more attempt to explain this to you. > >Same here. I'll also try and make one last attempt to try and convince you >that RFC2401 pretty strongly recomments that the IPsec SA be picked on >{dest IP, IPsec protocol, SPI}. > >First of all, the performance argument is pretty moot. You have expressed an opinion that, for some types of designs, it's not a critical path factor. That's not the same as declaring it irrelevant in the overall, discussion. > >Please clarify your position more: > >And, are you saying that RFC 2401 is irrelevant to IPsec, because we are >fully and more clearly specifying in an update to the ESP RFC, how all >IPsec implementations should *implement* their internal SPI selection >logic, (which has only local significance). How about an RFC just to >specify how all IPsec implementations MUST *implement* their SPI >selection. That way there will be no need to update RFC 2401 just because >by "mistake" the *implementation* of SPI selection by all IPsec >implementations was not specified properly. > >- Are there any IDs already trying to supercede RFC 2401? I announced plans to revise ESP, AH, and 2401, in that order, in the later half of 2001. I noted the flavor of changes being made. So, when we are finished, all three of these document will again be consistent. >- Are there any IDs trying to just specify how all IPsec implemenations >MUST *implemnt* their internal SPI selection. Not to the best of my knowledge, unless you count the proposal you have put forth. >- How can an ESP RFC supercede some behaviour in the Architecture RFC? see the above reminder of what was announced many months ago. >- Are there any IDs that are trying to "fix" this in AH too? yes, you will see an updated AH published today or tomorrow, consistent with the timeline I advertised previously. >- People are already complaining about the number of redirections that are >needed becuase there are already too many RFCs that people have to read, >to get a basic understanding of IPsec. By having a new kind of dependency >where something is specified in one RFC (the Architecture RFC), and >"fixed" in another RFC (a new ESP RFC) which is actually superceding >another RFC (original ESP RFC), will just make people crazy. first, despite your protestations, what we have described in the new ESP and AH drafts (with regard to SA demuxing) does not mandate changes to existing implementations and it is consistent with the current specs, from the perspective of an external IPsec peer. second, we chose not to wait until all the documents were revised to publish any of them. specifically, the iSCSI folks were anxiously awaiting the definition of the extended sequence number option, so we published the ESP update first, to address their needs. The bottom line is that your proposal would affect how IPsec implementations choose SPIs, and thus is in conflict with the parts of 2401 that you choose not to quote, but which Paul pointed to earlier. More importantly, as I described in detail in my previous message, in most common contexts, the clarifications expressed in the new AH and ESP drafts do NOT have any appreciable impact on the effective SPI space. This is because: - AH is rarely used - an implementation that serves a single IPsec destination (i.e., and end system or a security gateway in a firewall, etc.) has no opportunity to use destination address for demuxing That minimal or non-existent impact stands in stark contrast to a proposal to reduce the space by a factor of 65K. Steve From owner-ipsec@lists.tislabs.com Wed Mar 6 18:29:45 2002 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 g272Ti801215; Wed, 6 Mar 2002 18:29:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19610 Wed, 6 Mar 2002 20:46:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 20:58:46 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >We based our design on what the RFC 2401 says: > >" o SPI: the 32-bit value used to distinguish among different > SAs terminating at the same destination and using the same > IPsec protocol. > [REQUIRED for all implementations] >" Chiana, I'll continue to explain the reasoning behind the clarifications that have already appeared in the revised ESP ID and in the about to be published AH ID, despite your increasingly belligerent messages. Ignoring my responses to your comments and pointing to isolated pieces of text from RFCs to support your position is not constructive. >So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by >4 bytes of IP address, and a bit for protocol (because we currently have >only two IPsec protocols, AH and ESP). Effectively reducing the SAID space >by 33 bits. I wrote RFC 2401, so, of course it's not wrong :-). RFC 2401 is one of 3 RFCs dealing with processing AH and ESP traffic. There is overlap among the RFCs and we try to maintain consistency among them. The text cited above does not REQUIRE a receiver to use all three data items to demux inbound IPsec traffic; it ALLOWS a receiver to use all of these data items. The demuxing mechanism details are at the discretion of the receiver, just as is the checking of sequence numbers. Elswehere the RFC alludes to that, noting that any structure associated with the SPI up to the receiver, while the transmitter must view the SPI as opaque. Does your proposal require that a receiver coordinate with a NAT device in constructing an SPI? If so, that arguably violates the SPI model embodied in 2401. >This is being suggested only for performance-based reasons. I don't think >the performance benefits are significant enough for us to change RFC 2401. >TCAMs can handle large selectors. Selector size is not the most important >problem that TCAMs are dealing with now. I think the resoning that TCAMs >cannot handle large selector sizes is dated. We are only talking about >adding 4 bytes of destination IP address, and a byte for protocol into the >selector for the TCAM. That is just 5 bytes. The TCAMs are alredy having >to deal with the increase in IP address from 4 bytes to 16 bytes, and >there can be multiple of these IP addresses in the selector (for IPsec >atleast 2). I think it is just a myth that the biggest problem with TCAMs >is the selector size. I don't recall arguing that the TCAM lookup on a larger amount of data was a gating factor in performance; just that it was a factor (e.g., a cost factor due to larger CAM size or a performnace hit in software). Nonetheless, we are not changing the requirements; we are clarifying what the requirements have always been, in reality, and better describing how many folks have implemented the demuxing process. What we are describing is within the bounds of what receiver have always been allowed to do, consistent with all the RFCs. >Even in software, I don't think that there is any significant performance >benefit. I think it's more of a burden (regardless of hardware or >software) to make absolutely sure that the SPI we use is unique on the >box, if we are going to require it to be unique. The SPIs are sent with >each proposal, and we only endup using one of the proposals. We need to >keep track of what SPIs were allocated to these proposals that are being >negotiated. We can NOT just look at the SADB and pick a SPI that is not in >the SADB. And, there needs to be some garbage collection to be done to >scavange all the SPIs we burn up when we propose a bunch of proposals. The >SPI space can get pretty fragmented once rekeys happen, and it just >becomes a nightmare to have to pick a SPI that we are absolutely sure that >it is unique. We always require the SPI to be unique, relative to some context, period. We're just arguing over the scope of that context. (there is the kernel of an old joke there, but I digress ...) The context you envision makes use of the destination address and protocol type at each receiver for additional demuxing. For a unicast traffic flow directed to an IPsec receiver, the destination address is generally constant, and thus there is no change in the effective SAID space if one uses this value for demuxing. For a multicast receiver, the destination address is always needed, because the receiver does not select the SPI in this case. We have only two protocols here, AH and ESP, and we are moving to a situation in which only ESP may be of interest. So, at most, the effective SAID space might be doubled if one demuxed on protocol type, but in general, and in what is like to be the common case in the future, there is NO increase, since only ESP is being used. This brief analysis suggests that your protests are a red herring. In the common cases noted above, the effective SAID space is unchanged, irrespective of whether the destination address or protocol fields are used by a receiver, in addition to the SPI. However, if one reduces by half the number of bits in the SPI that are available to the receiver, as I think you propose, that DOES have a very significant impact on the difficulty of ensuing uniqueness, since you are reducing the SAID space by a factor of about 65K! One final comment: when we wrote 2401 we identified several options for IPsec deployment, but not the POP model, where IPsec is deployed at a POP serving many subscribers. If one chooses to implement IPsec in this environment and if one associates multiple, distinct IP addresses with the implementations (representing each of the subscribers), then in that case the destination address would need to be used for SPI demuxing, and we will note that fact in the revised text. I don't recall you mentioning this case in any of your correspondence, so I hope this case has not been the motivation for this prolonged discussion. >It is much more easier to not have to change RFC 2401 and reduce the >existing SAID space. "much more easier?" Steve From owner-ipsec@lists.tislabs.com Wed Mar 6 18:36:09 2002 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 g272a8801357; Wed, 6 Mar 2002 18:36:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19647 Wed, 6 Mar 2002 20:50:18 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Bill Sommerfeld , Paul Koning , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 06 Mar 2002 21:01:50 -0500 In-Reply-To: Message-ID: Lines: 102 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > For inbound processing: The following packet fields are used to look > up the SA in the SAD: > > o Outer Header's Destination IP address: the IPv4 or IPv6 > Destination address. > [REQUIRED for all implementations] Note this this says _OUTER_ header. This means that this will be the address of the Security Gateway or the NAT box, in all cases except a BITW. In other words, for the vast majority of all cases, this basically means "on which inbound interface this packet arrive?" or at worst "to which interface was this packet addressed?" In other words, this is a practical no-op. > o IPsec Protocol: AH or ESP, used as an index for SA lookup > in this database. Specifies the IPsec protocol to be > applied to the traffic on this SA. > [REQUIRED for all implementations] Ok, you might have something here, but you only get 1 bit of lookup space. Is that really significant? > o SPI: the 32-bit value used to distinguish among different > SAs terminating at the same destination and using the same > IPsec protocol. > [REQUIRED for all implementations] This is where the major differences are between SA. Chinna, I think you are being a bit confused about what the (new) intention is with regards to the "required" elements. That fact that a particular process is not required does not mean that you cannot do it that way. What it means is that you cannot EXPECT a peer to do it that way. If you want to continue, in your implementation, looking up a SAD by the tuple {destIP,Protocol,SPI} you are more than welcome to do so. However, with the relaxted constraints you cannot assume that your peer is going to look it up in the same manner. On a different note, you never answered a key question I had: in your proposal what is the NAT gateway supposed to do if it has multiple cache hits? Here's what I mean: assume the following network architecture: Private network Public network Host-(A)-- \ Host-(B)--+-- (N) NAT Box (NP) ------- Security Gateway (SG) / Host-()C-- Feel free to add as many hosts as you want on the left side -- assume you're at a conference with thousands of people, with many co-workers from the same company. Next, all these users try to connect to one security gateway. Assume they all connect at the same time (the current working groups just let out and they are all on break now). You get three IKE sessions -- fine -- the IKE cookies uniquely identify them. No problem. Each pair agree on a set of SPIs and start sending out ESP packets. The NAT box sees packets that look like the following: IP {src=A, dst=SG} ESP {SPI=spiA1} ... IP {src=B, dst=SG} ESP {SPI=spiB1} ... IP {src=C, dst=SG} ESP {SPI=spiC1} ... The NAT box will add these entries to its table, convert the IP address, and send them on: IP {src=NP, dst=SG} ESP {SPI=spiA1} ... IP {src=NP, dst=SG} ESP {SPI=spiB1} ... IP {src=NP, dst=SG} ESP {SPI=spiC1} ... This is all well and good. Now the Security Gateway responds. The NAT box gets three packets that look like: IP {src=SG, dst=NP} ESP {SPI=spiX1} ... IP {src=SG, dst=NP} ESP {SPI=spiX2} ... IP {src=SG, dst=NP} ESP {SPI=spiX3} ... Now, the NAT box has to somehow has to map these three packets back onto the original sources. Clearly the only thing it has to work with is the SPI, because everything else is the same. So, how does it do that? Worse, what happens if hash{spiX1} === hash{spiXn} (for some value n)? If you have enough hosts connecting through the NAT then you can make the probability of this occuring arbitrarily large. Can you please explain how you expect to handle this? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Mar 6 18:39:37 2002 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 g272db801404; Wed, 6 Mar 2002 18:39:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19700 Wed, 6 Mar 2002 20:56:45 -0500 (EST) Date: Wed, 6 Mar 2002 18:07:49 -0800 (PST) From: Jan Vilhuber To: Eric Rescorla cc: Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203070059.g270xlN87810@romeo.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Eric Rescorla wrote: > INTRODUCTION > The WG milestones say that we're supposed to select an IKE-replacement > protocol design in April so it's probably time to start thinking > about this now. Meta-comment: Wouldn't it be MUCH better if we had discussion of the requirements document? We can then better evaluate which candidate better matches the requirements.. A new version of the requirements document should be coming shortly. > Although neither of the leading contenders is > completely nailed down, the direction they're heading is clear > enough that we should be able to pick a winner at MSP or shortly > thereafter. > > In the interest of reaching a decision, here are my top 5 differences > between IKEv2 and JFK. I attempt to discuss each issue a bit but I'm > not taking sides here, just trying to elucidate the relevant > differences in a single document. > > (1) Algorithm Negotiation > (2) 2-phase handshake > (3) Management messages > (4) Non-public-key authentication > (5) DoS protection > > Note that I've deliberately not mentioned the cryptographic core, for > two reasons: > > (1) The cores are actually quite similar. > (2) Both groups seem perfectly willing to adapt a different > core if that's what the WG group wants. (In fact, JFKr adopts > SIGMA's core). > > In my view, the important differences between JFK and IKEv2 are in the > stuff that surrounds the cryptographic core, rather than the core > itself. > I very much agree. > > ALGORITHM NEGOTIATION > IKEv2 follows a fairly traditional approach to algorithm negotiation. > The initiator offers the algorithms he's happy with and the > responder selects among them. This is the same general approach > used by TLS. > > JFK uses two different approaches, one for negotiating protection > of the rest of the handshake and one for the IPsec traffic to be > protected. The handshake protection algorithms are not negotiated--the > responder simply chooses and the initiator can take it or leave it > (with the exception of the DH group, which is proposed by the > responder and chosen by the initiator). The traffic protection > negotiation is conceptually similar to that of IKEv2, with some > simplifications: namely that it uses cipher suites instead of > proposals and has a simplified traffic selector model. The former was > proposed (but rejected) by the IKEv2 authors. > > Discussion: > I'm not sure how relevant this difference is in practice. There's been > a lot of discussion of JFK not negotiating, but that really only > applies to the handshake-protection algorithms. SA algorithms are > negotiated in JFK, just as in IKEv2, albeit with a rather simpler > negotiation model. It would be easy to graft IKEv2's negotiation model > onto JFK (especially since JFK's negotiation is somewhat > underspecified in the spec), or alternately, to simplify IKEv2's > negotiation so it looks more like JFK's. [0] > > > 2-PHASE HANDSHAKE > [This section refers only to keying material establishment. > The next section discusses the use of phase II for management > traffic.] > IKEv2 uses the same two-phase approach as IKE. The peers first > negotiate an SA for protecting the rest of the handshake (the IKE SA) > and then negotiate a second SA for protecting traffic. The idea > here is that you might want to use different SAs for different > traffic flows but don't want to perform a new DH exchange for > each SA establishment. Once you have the "IKE SA" established > you can use that to create other SAs for individual traffic flows. > In order to minimize round trips, you can establish a single > traffic SA at the same time as you establish the IKE SA. > > JFK does not have two phases. If you want multiple SAs you do > multiple JFK handshakes. The rationale is as follows. > > We also feel that JFK is efficient enough that avoiding the overhead > of a full key exchange is not required. Rather than add new SAs > to an existing Phase I SA, we suggest that a full JFK exchange > be initiated instead. We note that the client can also choose > to reuse its exponential, it if wishes to trade perfect forward > secrecy for computation time. > > Discussion: > This ultimately comes down to performance: is it too expensive to > perform a new exchange for each traffic flow or not? Although JFK is > lighter weight than IKEv2, the reduced complexity is largely in > protocol processing, not cryptography. Extensive experience with SSL > performance tuning suggests that the vast majority of the time in both > JFK and IKEv2 will be in the cryptographic computations, which are > essentially identical. > > The question, then, is whether IPsec implementations need to > negotiate a lot of different SAs for any given set of peers or > not. In principle this is an empirical question, but I don't > know if we have enough deployment experience to decide one way > or the other. > I'm not sure I would say that (I do think I see lots of need to have multiple Sa's between peers), I can offer some other arguments: A) Consider a aggregator b) Consider that you really do need one IPsec Sa per QoS level b') Have a look at IP Storage (which, I'm told) calls for one SA per flow (??) (There's others, most (or all?) or which are, of course debatable in whether they are relevant or sane). Now the aggregator is likely to have quite a large number of SA's created to it from peers. Having to redo all cert-chain-validation and public key operations for each SA seems prohibitive (reusing the DH is really only one part of the computational complexity of a phase 1; especially if the exchange only supports rsa authentication). How many SA's do we expect to be created between peers/per Qos-level? I don't know. Video and Voice are quickly becoming more prevalent, so this needs to definitely be considered. Also, be sure to multiply the number of SA's between peers by the number of peers you can have (which is likely to be large for an aggregator). On a personal note, I prefer the 2-phase approach because it does offer a way to amortize the cost of both the ephemeral DH and the authentication (which, if it's certs, can be quite substantial) over multiple phase 2's, and I believe that there WILL be more than a pair of SA's between hosts. It's not much of an issue if you think purely of end-to-end encryption, but if there's any kind of aggregator in the picture that aggregator is quickly going to go to its knees. If you can guarantee that we will NEVER(*) need a fair number of SA's between two peers (which I don't believe for a second), then I'd rather have the tiny bit of added complexity of 2 phases. In summary: Cookie crumbs have calories, too. jan (*) where NEVER is defined as being the lifetime of son-of-ike, and I'd hope that it doesn't become obsolete the day we standardize it because our assumptions were wrong. > > MANAGEMENT TRAFFIC > Aside from child SA creation, IKEv2 allows a number of other > messages to be transmitted in Phase II, using the IKE SA. These > messages are primarily for management purposes including: > > (1) Dead peer detection > (2) Rekeying > (3) Deletion > > JFK doesn't have a Phase II and uses separate and somewhat ad > hoc mechanisms for each of these: > > (1) Dead peer detection is done with pings. > (2) Rekeying and deletion are both done via a new > SA exchange (you delete by offering a zero lifetime). > > Discussion: > The right approach really depends on how much is going to be done in > the Phase II exchange. Any individual one of these tasks can be > performed by other mechanisms (though JFK SA deletion is > clumsy). However, if we want all three features, it may be better to > simply write them into the protocol rather than develop ad hoc > techniques for each one. > > > NON PUBLIC-KEY AUTHENTICATION > IKEv2 supports both public key authentication and shared-key based > authentication. > > JFK supports only public key authentication, with the expectation that > they will be supported via some outboard protocol. > > Discussion: > As we've seen from mailing list traffic, this is an incredibly > controversial issue. Despite our best efforts to the contrary, > legacy authentication systems which support/use shared keys > aren't going away any time soon and I'm not sure that there's > any point in standing athwart history yelling "Stop". > > > DoS PROTECTION and COOKIE EXCHANGE > IKEv2 uses a variable-round-trip handshake, with 4 messages > under normal circumstances and 6 under attack. The extra > two messages are a simple cookie exchange designed to force > the attacker to prove that he has a round-trip to the responsder. > > JFK uses 4 messages in all cases. DoS protection is achieved by > not creating JFK state until message 3 has been read. > > Discussion: > Both protocols are resistant to DoS attacks based on computational > loading. JFK is slightly more network efficient under attack because > it has two fewer messages. However, it is more susceptible to an IP > fragmentation memory consumption attack where the attacker sends a > series of partial messages to consume reassembly buffers, thus > blocking delivery of legitimate fragmented message 3s. If one assumes > a rather intimate relationship between IKEv2 and the TCP stack, IKEv2 > is less susceptible to this attack. > > > FINAL COMMENTS > Although neither IKEv2 nor JFK is completely finished, I think it's > clear enough what direction they're following to choose which protocol > we're going to pursue. I've attempted to list what I consider to > be the major technical (as opposed to stylistic) differences between > the two protocols. If people feel that I've missed some important > difference, please point it out and I'll try to cover that as well. > > -Ekr > > > > [0] Incidentally, why does JFK have two different sets of algorithms? It > seems like life would be simpler if the algorithms used for traffic > protection were the same as those used for the handshake. I suppose > one might complain if the SA negotiated message integrity only but > I can't see that peers who don't care about confidentiality care about > identity protection. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Mar 6 18:50:23 2002 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 g272oM801571; Wed, 6 Mar 2002 18:50:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19823 Wed, 6 Mar 2002 21:08:12 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.52771.613459.175178@pkoning.akdesign.com> Date: Wed, 6 Mar 2002 21:19:15 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15494.40103.826000.692699@gargle.gargle.HOWL> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On Wed, 6 Mar 2002, Paul Koning wrote: >> > I just want to make sure that there is no technical content in this >> > discussion anymore. >> > >> > We are down to the phase where are trying to figure out what the meaning >> > of "is" is. >> >> I find your attempt to compare me with William J. Clinton utterly >> offensive and entirely unacceptable for a technical discussion. Chinna> I found your comment about our implementation being "all Chinna> hole" utterly offensive and entirely unacceptable for a Chinna> technical discussion. Ah. I did not think those words would be read as an attack on your personal honesty and integrity. Instead, I intended it as a criticism (perhaps a harsh one) on the technical soundness of your proposal (not your implementation, which I do not know -- nor on you personally). If it came across as a personal attack, my apologies. On the other hand, I find it difficult to interpret your comment as anything other than an attack on my honesty and personal integrity. I do not believe I have given anyone any cause for calling me dishonest and of unsound moral character. Yet your words appear to do just that. Why? paul From owner-ipsec@lists.tislabs.com Wed Mar 6 19:19:01 2002 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 g273J1801992; Wed, 6 Mar 2002 19:19:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20028 Wed, 6 Mar 2002 21:29:46 -0500 (EST) Date: Wed, 6 Mar 2002 18:40:50 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: Subject: RE: NAT Traversal In-Reply-To: <15494.52771.613459.175178@pkoning.akdesign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Paul Koning wrote: > >>>>> "Chinna" == Chinna N R Pellacuru writes: > > Chinna> On Wed, 6 Mar 2002, Paul Koning wrote: > > >> > I just want to make sure that there is no technical content in this > >> > discussion anymore. > >> > > >> > We are down to the phase where are trying to figure out what the meaning > >> > of "is" is. > >> > >> I find your attempt to compare me with William J. Clinton utterly > >> offensive and entirely unacceptable for a technical discussion. > > Chinna> I found your comment about our implementation being "all > Chinna> hole" utterly offensive and entirely unacceptable for a > Chinna> technical discussion. > > Ah. I did not think those words would be read as an attack on your > personal honesty and integrity. Instead, I intended it as a criticism > (perhaps a harsh one) on the technical soundness of your proposal (not > your implementation, which I do not know -- nor on you personally). > If it came across as a personal attack, my apologies. > > On the other hand, I find it difficult to interpret your comment as > anything other than an attack on my honesty and personal integrity. I > do not believe I have given anyone any cause for calling me dishonest > and of unsound moral character. Yet your words appear to do just > that. Why? > > paul > Hi Paul, I sincerely did not intend to compare you with anyone. It's just that the expression that you are offended about, was played on TV and radio so many times that, I sub-consiously included it in the mail. If you see my statement I didn't even re-read my statement, and I am probably missing a "we" in there. I did not intend to offend you like you took it. My sincere apologies. I just wanted to confirm that we are now debating on how to parse the statements in RFC 2401. I am here promoting our proposal as a better proposal than the existing proposals, and you turn around and call our proposal "all hole". It always sounds different on the receiving end. sorry, chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 6 20:18:57 2002 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 g274Iv803306; Wed, 6 Mar 2002 20:18:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20385 Wed, 6 Mar 2002 22:18:17 -0500 (EST) Date: Wed, 6 Mar 2002 19:28:49 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 6 Mar 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > For inbound processing: The following packet fields are used to look > > up the SA in the SAD: > > > > o Outer Header's Destination IP address: the IPv4 or IPv6 > > Destination address. > > [REQUIRED for all implementations] > > Note this this says _OUTER_ header. This means that this will be the > address of the Security Gateway or the NAT box, in all cases except a > BITW. In other words, for the vast majority of all cases, this > basically means "on which inbound interface this packet arrive?" or at > worst "to which interface was this packet addressed?" > > In other words, this is a practical no-op. Tunnel endpoint need not be the address on the incoming interface. You can pick whatever tunnel endpoint as long as everyone knows how to route the traffic to that tunnel endpoint. > > > o IPsec Protocol: AH or ESP, used as an index for SA lookup > > in this database. Specifies the IPsec protocol to be > > applied to the traffic on this SA. > > [REQUIRED for all implementations] > > Ok, you might have something here, but you only get 1 bit of lookup > space. Is that really significant? > > > o SPI: the 32-bit value used to distinguish among different > > SAs terminating at the same destination and using the same > > IPsec protocol. > > [REQUIRED for all implementations] > > This is where the major differences are between SA. > > Chinna, I think you are being a bit confused about what the (new) > intention is with regards to the "required" elements. That fact that > a particular process is not required does not mean that you cannot do > it that way. What it means is that you cannot EXPECT a peer to do it > that way. > That makes sense. I don't think I said anything about any assumsion that an IPsec peer needs to expect something from the other IPsec peer regarding what SPIs it picks. There was definitely discussion about internal indexing of the SAD. I don't think I was confused about that. > If you want to continue, in your implementation, looking up a SAD by > the tuple {destIP,Protocol,SPI} you are more than welcome to do so. Makes sense. > However, with the relaxted constraints you cannot assume that your > peer is going to look it up in the same manner. > We do not require that any IPsec peer of ours, have any assumptions on its peer's SPI (IE. our local SPI). Where is the local SPI in the outgoing ESP or AH packet for the peer to even lookup? > On a different note, you never answered a key question I had: in your > proposal what is the NAT gateway supposed to do if it has multiple > cache hits? Here's what I mean: assume the following network > architecture: > > Private network Public network > > Host-(A)-- > \ > Host-(B)--+-- (N) NAT Box (NP) ------- Security Gateway (SG) > / > Host-()C-- > > Feel free to add as many hosts as you want on the left side -- assume > you're at a conference with thousands of people, with many co-workers > from the same company. > > Next, all these users try to connect to one security gateway. Assume > they all connect at the same time (the current working groups just let > out and they are all on break now). > > You get three IKE sessions -- fine -- the IKE cookies uniquely > identify them. No problem. Each pair agree on a set of SPIs > and start sending out ESP packets. The NAT box sees packets that > look like the following: > > IP {src=A, dst=SG} ESP {SPI=spiA1} ... > IP {src=B, dst=SG} ESP {SPI=spiB1} ... > IP {src=C, dst=SG} ESP {SPI=spiC1} ... > > The NAT box will add these entries to its table, convert the > IP address, and send them on: > > IP {src=NP, dst=SG} ESP {SPI=spiA1} ... > IP {src=NP, dst=SG} ESP {SPI=spiB1} ... > IP {src=NP, dst=SG} ESP {SPI=spiC1} ... > > This is all well and good. Now the Security Gateway responds. > The NAT box gets three packets that look like: > > IP {src=SG, dst=NP} ESP {SPI=spiX1} ... > IP {src=SG, dst=NP} ESP {SPI=spiX2} ... > IP {src=SG, dst=NP} ESP {SPI=spiX3} ... > > Now, the NAT box has to somehow has to map these three packets back > onto the original sources. Clearly the only thing it has to work with > is the SPI, because everything else is the same. So, how does it do > that? When the NAT box receives traffic with spiX1 then it tries to see if spiX1 pairs with which of spiA1, spiB1 or spiC1. As I have already explained, this test is done by the actual algorithm that was used to pair the SPIs by the QM responder. One of the proposed algorithm is to make half of the responder SPI as the hash of the initiator SPI. Here initiator and responder are roles in IKE Quick Mode. There is nothing bad upto here. Curious why you have worse below. Worse, what happens if hash{spiX1} === hash{spiXn} (for some > value n)? As I had already mentioned, we have no way in this case to demux. We just drop the traffic, and hope that the IPsec boxes will try and renegotiate because they find that none of their data traffic is going through. If you find someone at a conference who is banging on the keyboard and frustrated that his ESP traffic isn't going through, he is probably using our SPI matching technique, and probably is working for a company who has sent a lot of employees to that conference, and all of them suddenly decided to connect back to the corporate network simultaneously. You can help him by telling him to try and connect after a couple of minutes. You are truly picking on our worst case here. We have not designed our solution for a "road-warrior" or road warriors who take a break and try to connect just after the break simultaneously. If you have enough hosts connecting through the NAT then > you can make the probability of this occuring arbitrarily large. > "enough hosts" trying to use the same Security Gateway, and also using the same tunnel endpoint on that Security Gateway. There is no reason why all users have to use the same tunnel endpoint, even if they are all using the same Security Gateway. Generally you would want a corporation to have multiple Security Gateways for redundancy, and for load balancing you would want the user community to be split across the different Security Gateways. Curious what was your estimate of the probability of a "collision" in NAT translation in this scenario. > Can you please explain how you expect to handle this? > Yes, the NAT box drops the traffic when it cannot demux. IP is a best effort protocol, and it is connectionless. If IP was connection based, we would not have to come up with the SPI matching logic to identify the inbound stream to the outbound stream. UDP is also connectionless, and if for some reason a UDP translation is lost in a NAT translation table, the endpoints have to start over, and setup another UDP session. This is not just for the UDP encapsulation scheme, but for UDP in general, and for any connectionless protocol. Our proposal is geared to help people who are willing and have the luxury to design their network end to end. Thank you very much for following this entire discussion, and taking the time to understand our proposal, even though we don't have a draft yet. chinna > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 7 06:06:57 2002 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 g27E6v827134; Thu, 7 Mar 2002 06:06:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24861 Thu, 7 Mar 2002 08:03:57 -0500 (EST) Message-ID: <20020307071559.26392.qmail@web11504.mail.yahoo.com> Date: Wed, 6 Mar 2002 23:15:59 -0800 (PST) From: sankar ramamoorthi Subject: Re: NAT Traversal To: "Scott G. Kelly" , Saroop Mathur Cc: ipsec@lists.tislabs.com In-Reply-To: <3C85004B.681B9B72@sonicwall.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1112632292-1015485359=:24675" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-1112632292-1015485359=:24675 Content-Type: text/plain; charset=us-ascii "Scott G. Kelly" wrote: Saroop Mathur wrote: > If changing the ESP header bits is an option, then it may make more > sense to include both source and dest SPIs in the header instead of > increasing the SPI size to either 6 or 8 bytes. IP, TCP and UDP include > both src/dest fields. This way the semantics of the entire SPI bits > remain with the entity generating the SPIs while allowing the NAT > devices to allow proper mapping. > > In order to maintain 8-byte alignment, the Sequence number can also be > increased to 64 bits. Alternatively SPIs can be increased to 48-bits > and the sequence number bits remain the same. One obvious problem with changing the ESP header is that it does not contain a version number. Hence, an intermediary (such as a nat box) would have difficulty determining what it was looking at. I don't think changing the ESP header is seriously up for consideration here. Scott without taking any sides on the NAT issue and whether ESP header should be modified or not - would like to point out the lack of a version number issue can be worked around by using reserved SPI values to indicate a new header is being used - however it will waste 3 bytes of ESP header - definitely not efficient. If ESP header is made transparent to NAT intermediaries by encapsulation, then the format of the ESP header need to be known only to the end-points. The format and version of the ESP header can then be determined during SA setup protocol. -- sankar -- --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-1112632292-1015485359=:24675 Content-Type: text/html; charset=us-ascii

  "Scott G. Kelly" <skelly@SonicWALL.com> wrote:

Saroop Mathur wrote:
> If changing the ESP header bits is an option, then it may make more
> sense to include both source and dest SPIs in the header instead of
> increasing the SPI size to either 6 or 8 bytes. IP, TCP and UDP include
> both src/dest fields. This way the semantics of the entire SPI bits
> remain with the entity generating the SPIs while allowing the NAT
> devices to allow proper mapping.
>
> In order to maintain 8-byte alignment, the Sequence number can also be
> increased to 64 bits. Alternatively SPIs can be increased to 48-bits
> and the sequence number bits remain the same.

One obvious problem with changing the ESP header is that it does not
contain a version number. Hence, an intermediary (such as a nat box)
would have difficulty determining what it was looking at. I don't think
changing the ESP header is seriously up for consideration here.

Scott

 

without taking any sides on the NAT issue and whether ESP header should be modified or not -

would like to point out the lack of a version number issue can be worked around by using reserved SPI values to indicate a new header is being used - however it will waste 3 bytes of ESP header - definitely not efficient. 

If ESP header is made transparent to NAT intermediaries by encapsulation, then the format of the ESP header need to be known only to the end-points. The format and version of the ESP header can then be determined during SA setup protocol.

-- sankar --

 

 



Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-1112632292-1015485359=:24675-- From owner-ipsec@lists.tislabs.com Thu Mar 7 06:40:46 2002 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 g27Eej828114; Thu, 7 Mar 2002 06:40:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25283 Thu, 7 Mar 2002 08:58:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.29840.242508.245747@pkoning.dev.equallogic.com> Date: Thu, 7 Mar 2002 09:09:20 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal References: <15494.52771.613459.175178@pkoning.akdesign.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On Wed, 6 Mar 2002, Paul Koning wrote: >> >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> I sincerely did not intend to compare you with anyone. ... Chinna> ...I did not intend to offend you like you took it. My Chinna> sincere apologies. Thanks. Chinna> I just wanted to confirm that we are now debating on how to Chinna> parse the statements in RFC 2401. That's right. I think I'll drop out of the discussion for a while, having consumed more than enough bandwidth lately. paul From owner-ipsec@lists.tislabs.com Thu Mar 7 08:50:12 2002 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 g27GoC806992; Thu, 7 Mar 2002 08:50:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26406 Thu, 7 Mar 2002 11:04:12 -0500 (EST) Date: Thu, 7 Mar 2002 08:15:16 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Stephen Kent wrote: > > > >We based our design on what the RFC 2401 says: > > > >" o SPI: the 32-bit value used to distinguish among different > > SAs terminating at the same destination and using the same > > IPsec protocol. > > [REQUIRED for all implementations] > >" > > Chiana, > > I'll continue to explain the reasoning behind the clarifications that > have already appeared in the revised ESP ID and in the about to be > published AH ID, despite your increasingly belligerent messages. > Ignoring my responses to your comments and pointing to isolated > pieces of text from RFCs to support your position is not constructive. Hi Steve, If you follow the discussion more, I think it is not fair to blame only me for quoting text from RFC 2401. I had to resort to quoting text from RFC 2401 because other people were trying to quote other text from RFC 2401 to support their position. I agree, it was a waste of time, because you plan to update it anyway. > > >So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by > >4 bytes of IP address, and a bit for protocol (because we currently have > >only two IPsec protocols, AH and ESP). Effectively reducing the SAID space > >by 33 bits. > > I wrote RFC 2401, so, of course it's not wrong :-). > > RFC 2401 is one of 3 RFCs dealing with processing AH and ESP traffic. > There is overlap among the RFCs and we try to maintain consistency > among them. The text cited above does not REQUIRE a receiver to use > all three data items to demux inbound IPsec traffic; it ALLOWS a > receiver to use all of these data items. The demuxing mechanism > details are at the discretion of the receiver, just as is the > checking of sequence numbers. I think I was a bit confused by the discussion about performance and internal indexing of the SAD, which seems not very relevant to the question of how a receiver can demux. I am in complete agreement to your above statement. Elswehere the RFC alludes to that, > noting that any structure associated with the SPI up to the receiver, > while the transmitter must view the SPI as opaque. Does your proposal > require that a receiver coordinate with a NAT device in constructing > an SPI? If so, that arguably violates the SPI model embodied in 2401. > IMHO, a NAT device is not an IPsec device, and the NAT device is not a receiver of the SPI. The NAT device is only trying to translate ESP traffic by *looking* at the SPIs in both directions. Our scheme suggests that the Quick Mode responder choose to pick a SPI according to a known alogrithm so that the NAT device can use that extra information to translate the ESP traffic. The transmitter will still view the SPI as opaque. The Quick Mode responder chooses to pick its SPI by using a hash function on the Quick Mode initiator SPI to derive half of its SPI. This hash function is known to the NAT device, and the NAT device uses that information to Pair the incoming and outgoing SPIs. We do not require all IPsec implementations to do it. We only require implementations that want to implement our proposal to do so all the time. All IPsec implementations can do it too. We will not restrict any IPsec implementation from doing it. The proposal only advices the various IPsec peers to pick their SPIs in a particular way so that the intermediate NAT devices can pair the SPIs. This extra information is in no way used by the IPsec peers themselves. This extra information is only used by the NAT device. chinna From owner-ipsec@lists.tislabs.com Thu Mar 7 09:00:57 2002 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 g27H0u807521; Thu, 7 Mar 2002 09:00:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26551 Thu, 7 Mar 2002 11:18:07 -0500 (EST) Date: Thu, 7 Mar 2002 08:29:12 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: "'ipsec mailling list'" Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A correction below: On Thu, 7 Mar 2002, Chinna N.R. Pellacuru wrote: > On Wed, 6 Mar 2002, Stephen Kent wrote: > > > > > > > >We based our design on what the RFC 2401 says: > > > > > >" o SPI: the 32-bit value used to distinguish among different > > > SAs terminating at the same destination and using the same > > > IPsec protocol. > > > [REQUIRED for all implementations] > > >" > > > > Chiana, > > > > I'll continue to explain the reasoning behind the clarifications that > > have already appeared in the revised ESP ID and in the about to be > > published AH ID, despite your increasingly belligerent messages. > > Ignoring my responses to your comments and pointing to isolated > > pieces of text from RFCs to support your position is not constructive. > > Hi Steve, > > If you follow the discussion more, I think it is not fair to blame only me > for quoting text from RFC 2401. I had to resort to quoting text from RFC > 2401 because other people were trying to quote other text from RFC 2401 to > support their position. I agree, it was a waste of time, because you plan > to update it anyway. > > > > > >So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by > > >4 bytes of IP address, and a bit for protocol (because we currently have > > >only two IPsec protocols, AH and ESP). Effectively reducing the SAID space > > >by 33 bits. > > > > I wrote RFC 2401, so, of course it's not wrong :-). > > > > RFC 2401 is one of 3 RFCs dealing with processing AH and ESP traffic. > > There is overlap among the RFCs and we try to maintain consistency > > among them. The text cited above does not REQUIRE a receiver to use > > all three data items to demux inbound IPsec traffic; it ALLOWS a > > receiver to use all of these data items. The demuxing mechanism > > details are at the discretion of the receiver, just as is the > > checking of sequence numbers. > > I think I was a bit confused by the discussion about performance and > internal indexing of the SAD, which seems not very relevant to the > question of how a receiver can demux. I am in complete agreement to your > above statement. > > Elswehere the RFC alludes to that, > > noting that any structure associated with the SPI up to the receiver, > > while the transmitter must view the SPI as opaque. Does your proposal > > require that a receiver coordinate with a NAT device in constructing > > an SPI? If so, that arguably violates the SPI model embodied in 2401. > > > > IMHO, a NAT device is not an IPsec device, and the NAT device is not a > receiver of the SPI. The NAT device is only trying to translate ESP ^^^^^^^^^^ transmitter (not the receiver) > traffic by *looking* at the SPIs in both directions. > > Our scheme suggests that the Quick Mode responder choose to pick a SPI > according to a known alogrithm so that the NAT device can use that extra > information to translate the ESP traffic. The transmitter will still view > the SPI as opaque. The Quick Mode responder chooses to pick its SPI by > using a hash function on the Quick Mode initiator SPI to derive half of > its SPI. This hash function is known to the NAT device, and the NAT device > uses that information to Pair the incoming and outgoing SPIs. > > We do not require all IPsec implementations to do it. We only require > implementations that want to implement our proposal to do so all the time. > All IPsec implementations can do it too. We will not restrict any IPsec > implementation from doing it. The proposal only advices the various IPsec > peers to pick their SPIs in a particular way so that the intermediate NAT > devices can pair the SPIs. This extra information is in no way used by the > IPsec peers themselves. This extra information is only used by the NAT > device. > > chinna > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 7 09:18:22 2002 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 g27HIM808365; Thu, 7 Mar 2002 09:18:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26750 Thu, 7 Mar 2002 11:42:54 -0500 (EST) Date: Thu, 7 Mar 2002 08:53:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Mar 2002, Stephen Kent wrote: > first, despite your protestations, what we have described in the new > ESP and AH drafts (with regard to SA demuxing) does not mandate > changes to existing implementations and it is consistent with the > current specs, from the perspective of an external IPsec peer. That clears up a lot for me. > > The bottom line is that your proposal would affect how IPsec > implementations choose SPIs, and thus is in conflict with the parts > of 2401 that you choose not to quote, but which Paul pointed to > earlier. We plan to only effect IPsec implementations that choose to use our proposal. They can choose our proposal if they want to get through NAT the way we propose is a better way to get through NAT if someone has the control or influence on the NAT devices. More importantly, as I described in detail in my previous > message, in most common contexts, the clarifications expressed in the > new AH and ESP drafts do NOT have any appreciable impact on the > effective SPI space. This is because: > - AH is rarely used > - an implementation that serves a single IPsec destination > (i.e., and end system or a security gateway in a firewall, etc.) has > no opportunity to use destination address for demuxing > I agree, I do not see anything I want to object to in your ESP draft. Even though IPsec implementations that use destination address for demuxing are rare by looking at raw numbers, I don't see how some important kind of VPNs can be deployed wihtout having this flexibility of choosing whatever tunnel endpoint the user wants to. > That minimal or non-existent impact stands in stark contrast to a > proposal to reduce the space by a factor of 65K. > > Steve > Point taken. We propose to folks who want to use our proposal to reduce the SPI space by 16 bits, but not give up their flexibility of using different tunnel endpoints to demux incoming ESP/AH traffic. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 7 09:44:41 2002 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 g27Hie809149; Thu, 7 Mar 2002 09:44:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26914 Thu, 7 Mar 2002 12:02:12 -0500 (EST) Date: Thu, 7 Mar 2002 09:13:16 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Chinna N.R. Pellacuru wrote: > On Wed, 6 Mar 2002, Stephen Kent wrote: > > > That minimal or non-existent impact stands in stark contrast to a > > proposal to reduce the space by a factor of 65K. > > > > Steve > > > > Point taken. We propose to folks who want to use our proposal to reduce > the SPI space by 16 bits, but not give up their flexibility of using > different tunnel endpoints to demux incoming ESP/AH traffic. > That way people can use a SPI as: SPI: the 16-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. The tunnel endpoint discussion is a different one than this one. So, for each peer an IPsec implementation is peering with, we can still have 64k SPIs that are generated locally. So, an IPsec implementation is in no way restricted to a total of 64k total SPIs but are restricted to a total of 64k SPIs to a particular peer (a particular remote tunnel endpoint). chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 7 10:05:14 2002 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 g27I5E810502; Thu, 7 Mar 2002 10:05:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27082 Thu, 7 Mar 2002 12:19:06 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Stephen Kent , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 07 Mar 2002 12:30:34 -0500 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > Point taken. We propose to folks who want to use our proposal to reduce > the SPI space by 16 bits, but not give up their flexibility of using > different tunnel endpoints to demux incoming ESP/AH traffic. Having different endpoints necessarily requires your endpoint to actually be able to use those various IP addresses. If you're in a situation where you're using NAT, most likely you only have one address to use on that end, and generally a Security Gateway only has one address. It's not like a company is going to supply a /24 subnet to a single Security Gateway. Also, I think that assuming that you have control over your destiny is not a very scalable approach. When I visit a hotel and use the network in my room, I have no control over the NAT box they provide me. I want a solution that I can use through _ANY_ NAT box that is curently deployed, because I don't expect these hotels to spend any money to upgrade their current hardware. > chinna -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Mar 7 10:05:23 2002 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 g27I5M810533; Thu, 7 Mar 2002 10:05:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27103 Thu, 7 Mar 2002 12:21:30 -0500 (EST) Message-Id: <200203071718.g27HIiUe005381@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: EKR Cc: ipsec@lists.tislabs.com Subject: Re: JFK ID payload In-reply-to: Your message of "06 Mar 2002 16:37:41 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 12:18:44 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, I see what you mean. Point taken. In message , Eric Rescorla writes: >"Angelos D. Keromytis" writes: >> In general, I'd agree. However, allowing for multiple payloads of the >> same type introduces the potential for confusion, as well as making it >> difficult to give a concise notation for the protocol. Furthermore, the >> receiver has to do the same job regardless of the message encoding (the >> same certs, CRLs, etc. have to be examined); I don't think there is any >> gain in splitting the payload into multiple instances (or sub-payloads). >> Am I missing something ? >I think so. My point is that certs, CRLs, and OCSP responses aren't >tagged. Here's the ASN.1 for the first couple fields of the each >structure: > >CERTIFICATE >Certificate ::= SIGNED { SEQUENCE { > version [0] Version DEFAULT v1, > serialNumber CertificateSerialNumber, > >CRL >CertificateList ::= SIGNED { SEQUENCE { > version Version OPTIONAL, -- if present, shall be v2 > signature AlgorithmIdentifier, > > >OCSP response >OCSPResponse ::= SEQUENCE { > responseStatus OCSPResponseStatus, > responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } > >If these structures are just concatenated, then the recipient needs >to do something like: > >if(parseCertificate()==SUCCESS){ >... >} else if(parseCRL()==SUCCESS)){ >... >} else if(parseOCSPResponse()==SUCCESS){ >... >} > >This isn't much fun. It would be a lot easier if the various chunks >were wrapped in a TLV wrapper, thus saving you from having to do it. > >-Ekr > >-- >[Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu Mar 7 10:37:44 2002 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 g27Ibh813322; Thu, 7 Mar 2002 10:37:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27413 Thu, 7 Mar 2002 12:58:37 -0500 (EST) Date: Thu, 7 Mar 2002 10:09:42 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Subject: RE: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Chinna N.R. Pellacuru wrote: > On Thu, 7 Mar 2002, Chinna N.R. Pellacuru wrote: > > > On Wed, 6 Mar 2002, Stephen Kent wrote: > > > > > That minimal or non-existent impact stands in stark contrast to a > > > proposal to reduce the space by a factor of 65K. > > > > > > Steve > > > > > > > Point taken. We propose to folks who want to use our proposal to reduce > > the SPI space by 16 bits, but not give up their flexibility of using > > different tunnel endpoints to demux incoming ESP/AH traffic. > > > > That way people can use a SPI as: > > SPI: the 16-bit value used to distinguish among different > SAs terminating at the same destination and using the same > IPsec protocol. > > The tunnel endpoint discussion is a different one than this one. So, for > each peer an IPsec implementation is peering with, we can still have 64k > SPIs that are generated locally. > > So, an IPsec implementation is in no way restricted to a total of 64k > total SPIs but are restricted to a total of 64k SPIs to a particular peer > (a particular remote tunnel endpoint). > OK, for each local tunnel endpoint, we are restricted to 64k SPIs, and it may be more depending what hash function is used to generate the other half. chinna From owner-ipsec@lists.tislabs.com Thu Mar 7 10:49:22 2002 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 g27InL813654; Thu, 7 Mar 2002 10:49:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27556 Thu, 7 Mar 2002 13:12:51 -0500 (EST) Message-Id: <200203071814.g27IEpUf021438@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Wed, 06 Mar 2002 18:07:49 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 13:14:51 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, Let me point out that, in the test scenario you are describing, different certificates would be used for the different QoS levels, even if though it is the same two peers (hosts) establishing multiple SAs. I ran into the exact same situation in a different context: per-user (or per-socket) keying using distinct SAs for each TCP connection. Since certificates are exchanged only during Phase 1 (in both IKE and IKEv2), you end up running complete Phase 1/Phase 2 exchanges for each such connection. As for dealing with the cost of cert-chain verification when re-establishing an expiring SA: on any crypto protocol where this is a consideration (and I'm not very convinced it is -- I just saw a crypto card that does a few thousand RSA verifications/sec), one can simply cache the result of a verification. Here's a simple scheme: hash the contents of the JFK ID payload for slightly longer than the lifetime of the SA that was established by that session, and check next time an ID is received; you have to also keep track of how long this is going to be valid (wrt CRLs or OCSP status results), but you have to make the same decision when establishing a Phase 1 SA in IKE/IKEv2. Cheers, -Angelos In message , Jan Vilhuber writes: > >I'm not sure I would say that (I do think I see lots of need to have >multiple Sa's between peers), I can offer some other arguments: > >A) Consider a aggregator >b) Consider that you really do need one IPsec Sa per QoS level >b') Have a look at IP Storage (which, I'm told) calls for one SA per > flow (??) > >(There's others, most (or all?) or which are, of course debatable in >whether they are relevant or sane). > >Now the aggregator is likely to have quite a large number of SA's >created to it from peers. Having to redo all cert-chain-validation and >public key operations for each SA seems prohibitive (reusing the DH is >really only one part of the computational complexity of a phase 1; >especially if the exchange only supports rsa authentication). > >How many SA's do we expect to be created between peers/per Qos-level? >I don't know. Video and Voice are quickly becoming more prevalent, so >this needs to definitely be considered. Also, be sure to multiply the >number of SA's between peers by the number of peers you can have >(which is likely to be large for an aggregator). > > >On a personal note, I prefer the 2-phase approach because it does >offer a way to amortize the cost of both the ephemeral DH and the >authentication (which, if it's certs, can be quite substantial) over >multiple phase 2's, and I believe that there WILL be more than a pair >of SA's between hosts. It's not much of an issue if you think purely >of end-to-end encryption, but if there's any kind of aggregator in the >picture that aggregator is quickly going to go to its knees. If you >can guarantee that we will NEVER(*) need a fair number of SA's between >two peers (which I don't believe for a second), then I'd rather have >the tiny bit of added complexity of 2 phases. > >In summary: Cookie crumbs have calories, too. > >jan > >(*) where NEVER is defined as being the lifetime of son-of-ike, and >I'd hope that it doesn't become obsolete the day we standardize it >because our assumptions were wrong. From owner-ipsec@lists.tislabs.com Thu Mar 7 10:54:20 2002 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 g27IsJ813806; Thu, 7 Mar 2002 10:54:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27584 Thu, 7 Mar 2002 13:17:17 -0500 (EST) Date: Thu, 7 Mar 2002 10:28:18 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Eric Rescorla , Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203071814.g27IEpUf021438@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Angelos D. Keromytis wrote: > > Jan, > Let me point out that, in the test scenario you are describing, different > certificates would be used for the different QoS levels, Not always true. > even if though it > is the same two peers (hosts) establishing multiple SAs. I ran into > the exact same situation in a different context: per-user (or per-socket) > keying using distinct SAs for each TCP connection. That's not the scenario I'm talking about. You're thinking of a multi-users system. I'm talking about vpn aggregators or security gateways. The SAME user is likely do be doing http traffic while trying to make an IP Phone call (I do this from home all the time, for what it's worth). Currently, I don't see a great number of QoS levels being used (heck.. I don't see QoS used at all most of the time.. ipsec gets in the way), but that's not to say that as greater bandwidth becomes more prevalent, that more QoS level PER PEER (and same user) won't become an issue. In a pure peer-to-peer scenario, even 64 or so SA's won't present much difficulty. But if a machine is an aggregator or a gateway terminating the SA's, then you have to multiply the small to medium number of Sa's per peer by the number of peers. That's not cheap. > Since certificates are > exchanged only during Phase 1 (in both IKE and IKEv2), you end up running > complete Phase 1/Phase 2 exchanges for each such connection. > > As for dealing with the cost of cert-chain verification when re-establishing an > expiring SA: on any crypto protocol where this is a consideration (and I'm not > very convinced it is -- I just saw a crypto card that does a few thousand RSA > verifications/sec), one can simply cache the result of a verification. Here's a > simple scheme: hash the contents of the JFK ID payload for slightly longer than > the lifetime of the SA that was established by that session, and check next > time an ID is received; you have to also keep track of how long this is > going to be valid (wrt CRLs or OCSP status results), but you have to make the > same decision when establishing a Phase 1 SA in IKE/IKEv2. > You still need to go throught the rsa checks, even if you cache the certificates, which, when you think orders of magnitude larger than PC to PC communications becomes very expensive. Some people claim that rsa is 'cheap'. I tend to disagree (symmetric cryptography is cheap). Yes, there's new hardware that can do it fast. There's also old hardware that will want to run ikev2. The cost of an rsa operation is not trivial, and when multiplied by large numbers of peers becomes decidedly non-trivial. While I admit that old tired hardware shouldn't hobble new protocols, the alternative is clear, and, IMHO, not a terrible burden, i.e. 2 phases. The advantages (having essentially a tunnel-management tunnel) also weigh in favorably. jan > Cheers, > -Angelos > > In message , Jan > Vilhuber writes: > > > >I'm not sure I would say that (I do think I see lots of need to have > >multiple Sa's between peers), I can offer some other arguments: > > > >A) Consider a aggregator > >b) Consider that you really do need one IPsec Sa per QoS level > >b') Have a look at IP Storage (which, I'm told) calls for one SA per > > flow (??) > > > >(There's others, most (or all?) or which are, of course debatable in > >whether they are relevant or sane). > > > >Now the aggregator is likely to have quite a large number of SA's > >created to it from peers. Having to redo all cert-chain-validation and > >public key operations for each SA seems prohibitive (reusing the DH is > >really only one part of the computational complexity of a phase 1; > >especially if the exchange only supports rsa authentication). > > > >How many SA's do we expect to be created between peers/per Qos-level? > >I don't know. Video and Voice are quickly becoming more prevalent, so > >this needs to definitely be considered. Also, be sure to multiply the > >number of SA's between peers by the number of peers you can have > >(which is likely to be large for an aggregator). > > > > > >On a personal note, I prefer the 2-phase approach because it does > >offer a way to amortize the cost of both the ephemeral DH and the > >authentication (which, if it's certs, can be quite substantial) over > >multiple phase 2's, and I believe that there WILL be more than a pair > >of SA's between hosts. It's not much of an issue if you think purely > >of end-to-end encryption, but if there's any kind of aggregator in the > >picture that aggregator is quickly going to go to its knees. If you > >can guarantee that we will NEVER(*) need a fair number of SA's between > >two peers (which I don't believe for a second), then I'd rather have > >the tiny bit of added complexity of 2 phases. > > > >In summary: Cookie crumbs have calories, too. > > > >jan > > > >(*) where NEVER is defined as being the lifetime of son-of-ike, and > >I'd hope that it doesn't become obsolete the day we standardize it > >because our assumptions were wrong. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 7 11:04:21 2002 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 g27J4L814206; Thu, 7 Mar 2002 11:04:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27684 Thu, 7 Mar 2002 13:26:12 -0500 (EST) Date: Thu, 7 Mar 2002 10:36:39 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Stephen Kent , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 7 Mar 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > Point taken. We propose to folks who want to use our proposal to reduce > > the SPI space by 16 bits, but not give up their flexibility of using > > different tunnel endpoints to demux incoming ESP/AH traffic. > > Having different endpoints necessarily requires your endpoint to > actually be able to use those various IP addresses. If you're in a > situation where you're using NAT, most likely you only have one > address to use on that end, and generally a Security Gateway only has > one address. It's not like a company is going to supply a /24 subnet > to a single Security Gateway. If someone has just one IP address to use as his local endpoint, then probably 64K IPsec connections is more than enough for him. That box has to first be able to handle so many IPsec connections. > > Also, I think that assuming that you have control over your destiny is > not a very scalable approach. When I visit a hotel and use the > network in my room, I have no control over the NAT box they provide > me. > As I have repeated many times, our proposal is geared more towards people who can plan their network end-to-end. It is becoming more and more important as people are putting buissiness critical applications on thier network, for them to plan their network end-to-end. If you think you have total control over your destiny, our solution is the one you should be supporting :-) Network designers, IT administrators and others who have total control over what solution they want for their network should support us, because you can save yourself the overhead of UDP encapsulation and other overheads. Please refer to the mail I sent enumarating our reasons for coming up with a different solution to the udp encapsulation scheme. > I want a solution that I can use through _ANY_ NAT box that is > curently deployed, because I don't expect these hotels to spend any > money to upgrade their current hardware. > I don't think there is any current proposal that has been disclosed and discussed fully on this list, that can do that. I agree that you will have a better chance of getting IPsec through unknown NAT boxes if you use UDP encapsulation, assuming that those NAT boxes don't have any hacks to deal with broken IPsec implementations. Even if we hit a NAT box has a hack for broken IPsec implementations, we can influence the NAT box owners to upgrade and remove that hack so that our IPsec implementation which is not broken can go through. As far as hotels are concerned, I will choose a hotel who is more oriented towards a business traveller, and who is willing to accomidate any reasonable requests from its clients. What is the use of an Internet connection in every room if the hotel's equipment doesn't support an important VPN technology like IPsec. chinna From owner-ipsec@lists.tislabs.com Thu Mar 7 11:24:50 2002 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 g27JOo814807; Thu, 7 Mar 2002 11:24:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27876 Thu, 7 Mar 2002 13:48:04 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Stephen Kent , ipsec mailling list From: Derek Atkins Subject: Re: NAT Traversal References: Date: 07 Mar 2002 13:51:23 -0500 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > If someone has just one IP address to use as his local endpoint, then > probably 64K IPsec connections is more than enough for him. That box has > to first be able to handle so many IPsec connections. You are missing one thing. Yes, there is a potential to hold 64k connections, except by the birthday paradox you will get a hash collision after 256 connections. Don't you think that 256 connections is too few? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Mar 7 11:25:17 2002 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 g27JPG814822; Thu, 7 Mar 2002 11:25:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27920 Thu, 7 Mar 2002 13:51:19 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699D8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Angelos D. Keromytis'" , Jan Vilhuber Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: RE: Choosing between IKEv2 and JFK Date: Thu, 7 Mar 2002 11:03:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C60A.CB35FC50" 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_000_01C1C60A.CB35FC50 Content-Type: text/plain; charset="iso-8859-1" I think we need to get out of the habit of thinking about certificates when at the protocol level we really mean public keys. Although the certificates may be delivering the key there may well be another mechanism in use, in particular XKMS or DNS-SEC. We should also get way from thinking that the IPSEC stack is necessarily the place where the trust decision is going to be made. Trust relationships are relationships between enterprises and people, they are never relationships between devices. It is unfortunate that the 'alice sends bob an email' scenario became the certificate paradigm. The End to End principle, properly understood in the network context is about where you put complexity, put complexity where it can be managed. In the security context 'end to end' is the antithesis of link by link encryption. If however the trust relationship is between enterprises and the network communication is between devices it may be the case that the 'ends' of the turst relationship are not the same as the 'ends' of the network communication. I am however somewhat skeptical as for the need or utility of introducing separate QoS levels at the packet layer. An application that really cares about QoS should be doing the trust path processing itself and not pushing down to the O/S level. If you care about different QoS level you almost certainly care about non-repudiation at some point, this is not a problem that has a pretty solution at the packet level. It does not seem likely to me that anyone will be implementing IKEv2 or JFK without providing support for AES (particularly if we make it mandatory). I don't see any reason why someone should be anxious to use anything less strong than AES. If they are coerced into using something less the issue of encryption level will not arise. So I do not believe that QoS etc. is going to give rise to a performance issue in practice in IPSEC. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Angelos D. Keromytis [mailto:angelos@cs.columbia.edu] > Sent: Thursday, March 07, 2002 1:15 PM > To: Jan Vilhuber > Cc: Eric Rescorla; ipsec@lists.tislabs.com > Subject: Re: Choosing between IKEv2 and JFK > > > > Jan, > Let me point out that, in the test scenario you are > describing, different > certificates would be used for the different QoS levels, even > if though it > is the same two peers (hosts) establishing multiple SAs. I ran into > the exact same situation in a different context: per-user (or > per-socket) > keying using distinct SAs for each TCP connection. Since > certificates are > exchanged only during Phase 1 (in both IKE and IKEv2), you > end up running > complete Phase 1/Phase 2 exchanges for each such connection. > > As for dealing with the cost of cert-chain verification when > re-establishing an > expiring SA: on any crypto protocol where this is a > consideration (and I'm not > very convinced it is -- I just saw a crypto card that does a > few thousand RSA > verifications/sec), one can simply cache the result of a > verification. Here's a > simple scheme: hash the contents of the JFK ID payload for > slightly longer than > the lifetime of the SA that was established by that session, > and check next > time an ID is received; you have to also keep track of how > long this is > going to be valid (wrt CRLs or OCSP status results), but you > have to make the > same decision when establishing a Phase 1 SA in IKE/IKEv2. > > Cheers, > -Angelos > > In message > , Jan > Vilhuber writes: > > > >I'm not sure I would say that (I do think I see lots of need to have > >multiple Sa's between peers), I can offer some other arguments: > > > >A) Consider a aggregator > >b) Consider that you really do need one IPsec Sa per QoS level > >b') Have a look at IP Storage (which, I'm told) calls for one SA per > > flow (??) > > > >(There's others, most (or all?) or which are, of course debatable in > >whether they are relevant or sane). > > > >Now the aggregator is likely to have quite a large number of SA's > >created to it from peers. Having to redo all > cert-chain-validation and > >public key operations for each SA seems prohibitive > (reusing the DH is > >really only one part of the computational complexity of a phase 1; > >especially if the exchange only supports rsa authentication). > > > >How many SA's do we expect to be created between peers/per > Qos-level? > >I don't know. Video and Voice are quickly becoming more > prevalent, so > >this needs to definitely be considered. Also, be sure to > multiply the > >number of SA's between peers by the number of peers you can have > >(which is likely to be large for an aggregator). > > > > > >On a personal note, I prefer the 2-phase approach because it does > >offer a way to amortize the cost of both the ephemeral DH and the > >authentication (which, if it's certs, can be quite substantial) over > >multiple phase 2's, and I believe that there WILL be more > than a pair > >of SA's between hosts. It's not much of an issue if you think purely > >of end-to-end encryption, but if there's any kind of > aggregator in the > >picture that aggregator is quickly going to go to its knees. If you > >can guarantee that we will NEVER(*) need a fair number of > SA's between > >two peers (which I don't believe for a second), then I'd rather have > >the tiny bit of added complexity of 2 phases. > > > >In summary: Cookie crumbs have calories, too. > > > >jan > > > >(*) where NEVER is defined as being the lifetime of son-of-ike, and > >I'd hope that it doesn't become obsolete the day we standardize it > >because our assumptions were wrong. > ------_=_NextPart_000_01C1C60A.CB35FC50 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C60A.CB35FC50-- From owner-ipsec@lists.tislabs.com Thu Mar 7 11:32:33 2002 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 g27JWW814986; Thu, 7 Mar 2002 11:32:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27989 Thu, 7 Mar 2002 13:57:10 -0500 (EST) Date: Thu, 7 Mar 2002 11:08:11 -0800 (PST) From: Jan Vilhuber To: "Hallam-Baker, Phillip" cc: "'Angelos D. Keromytis'" , Eric Rescorla , Subject: RE: Choosing between IKEv2 and JFK In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058699D8@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wasn't making a performance argument. If you send two different levels of QoS through the same Sa, you replay counter/window will likely march ahead with the higher priority traffic, causing all lower priority traffic to be dropped. The solution is a separate counter for the different levels of QoS, i.e. separate SA's. Hence the need for multiple SA's for the same 'user' or 'peer'. Hence a need for 2 phases. Again: From a 'client' perspective, the number of Sa's, even if on the order or 60, should be fine. it's an an aggregator this this becomes an issue. If you want authentication of the voice traffic itself, that's best handled by a different layer and end-to-end (most likely.. I'm no voice, rtp, rtcp, etc expert). The point is purely on of replay counters. Sorry if I wasn't clear. jan On Thu, 7 Mar 2002, Hallam-Baker, Phillip wrote: > I think we need to get out of the habit of thinking about certificates when > at the protocol level we really mean public keys. Although the certificates > may be delivering the key there may well be another mechanism in use, in > particular XKMS or DNS-SEC. > > We should also get way from thinking that the IPSEC stack is necessarily the > place where the trust decision is going to be made. Trust relationships are > relationships between enterprises and people, they are never relationships > between devices. It is unfortunate that the 'alice sends bob an email' > scenario became the certificate paradigm. The End to End principle, properly > understood in the network context is about where you put complexity, put > complexity where it can be managed. In the security context 'end to end' is > the antithesis of link by link encryption. If however the trust relationship > is between enterprises and the network communication is between devices it > may be the case that the 'ends' of the turst relationship are not the same > as the 'ends' of the network communication. > > I am however somewhat skeptical as for the need or utility of introducing > separate QoS levels at the packet layer. An application that really cares > about QoS should be doing the trust path processing itself and not pushing > down to the O/S level. If you care about different QoS level you almost > certainly care about non-repudiation at some point, this is not a problem > that has a pretty solution at the packet level. > > It does not seem likely to me that anyone will be implementing IKEv2 or JFK > without providing support for AES (particularly if we make it mandatory). I > don't see any reason why someone should be anxious to use anything less > strong than AES. If they are coerced into using something less the issue of > encryption level will not arise. > > > So I do not believe that QoS etc. is going to give rise to a performance > issue in practice in IPSEC. > > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Angelos D. Keromytis [mailto:angelos@cs.columbia.edu] > > Sent: Thursday, March 07, 2002 1:15 PM > > To: Jan Vilhuber > > Cc: Eric Rescorla; ipsec@lists.tislabs.com > > Subject: Re: Choosing between IKEv2 and JFK > > > > > > > > Jan, > > Let me point out that, in the test scenario you are > > describing, different > > certificates would be used for the different QoS levels, even > > if though it > > is the same two peers (hosts) establishing multiple SAs. I ran into > > the exact same situation in a different context: per-user (or > > per-socket) > > keying using distinct SAs for each TCP connection. Since > > certificates are > > exchanged only during Phase 1 (in both IKE and IKEv2), you > > end up running > > complete Phase 1/Phase 2 exchanges for each such connection. > > > > As for dealing with the cost of cert-chain verification when > > re-establishing an > > expiring SA: on any crypto protocol where this is a > > consideration (and I'm not > > very convinced it is -- I just saw a crypto card that does a > > few thousand RSA > > verifications/sec), one can simply cache the result of a > > verification. Here's a > > simple scheme: hash the contents of the JFK ID payload for > > slightly longer than > > the lifetime of the SA that was established by that session, > > and check next > > time an ID is received; you have to also keep track of how > > long this is > > going to be valid (wrt CRLs or OCSP status results), but you > > have to make the > > same decision when establishing a Phase 1 SA in IKE/IKEv2. > > > > Cheers, > > -Angelos > > > > In message > > , Jan > > Vilhuber writes: > > > > > >I'm not sure I would say that (I do think I see lots of need to have > > >multiple Sa's between peers), I can offer some other arguments: > > > > > >A) Consider a aggregator > > >b) Consider that you really do need one IPsec Sa per QoS level > > >b') Have a look at IP Storage (which, I'm told) calls for one SA per > > > flow (??) > > > > > >(There's others, most (or all?) or which are, of course debatable in > > >whether they are relevant or sane). > > > > > >Now the aggregator is likely to have quite a large number of SA's > > >created to it from peers. Having to redo all > > cert-chain-validation and > > >public key operations for each SA seems prohibitive > > (reusing the DH is > > >really only one part of the computational complexity of a phase 1; > > >especially if the exchange only supports rsa authentication). > > > > > >How many SA's do we expect to be created between peers/per > > Qos-level? > > >I don't know. Video and Voice are quickly becoming more > > prevalent, so > > >this needs to definitely be considered. Also, be sure to > > multiply the > > >number of SA's between peers by the number of peers you can have > > >(which is likely to be large for an aggregator). > > > > > > > > >On a personal note, I prefer the 2-phase approach because it does > > >offer a way to amortize the cost of both the ephemeral DH and the > > >authentication (which, if it's certs, can be quite substantial) over > > >multiple phase 2's, and I believe that there WILL be more > > than a pair > > >of SA's between hosts. It's not much of an issue if you think purely > > >of end-to-end encryption, but if there's any kind of > > aggregator in the > > >picture that aggregator is quickly going to go to its knees. If you > > >can guarantee that we will NEVER(*) need a fair number of > > SA's between > > >two peers (which I don't believe for a second), then I'd rather have > > >the tiny bit of added complexity of 2 phases. > > > > > >In summary: Cookie crumbs have calories, too. > > > > > >jan > > > > > >(*) where NEVER is defined as being the lifetime of son-of-ike, and > > >I'd hope that it doesn't become obsolete the day we standardize it > > >because our assumptions were wrong. > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 7 11:35:17 2002 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 g27JZH815043; Thu, 7 Mar 2002 11:35:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28008 Thu, 7 Mar 2002 13:58:46 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699D9@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Jan Vilhuber'" , "Angelos D. Keromytis" Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: RE: Choosing between IKEv2 and JFK Date: Thu, 7 Mar 2002 11:11:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C60B.D54567C0" 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_000_01C1C60B.D54567C0 Content-Type: text/plain; charset="iso-8859-1" > > Jan, > > Let me point out that, in the test scenario you are > describing, different > > certificates would be used for the different QoS levels, > > Not always true. In fact what has network QoS got to do with it? My PDA is the same PDA if it is connecting to my mail server or sending streaming video. The only thing a certificate is going to have any link to is the cryptography used, hence my earlier message in which I assumed that QoS was being eroneously used to refer to crypto parameters. Phill ------_=_NextPart_000_01C1C60B.D54567C0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C60B.D54567C0-- From owner-ipsec@lists.tislabs.com Thu Mar 7 12:17:56 2002 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 g27KHt816477; Thu, 7 Mar 2002 12:17:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28347 Thu, 7 Mar 2002 14:31:21 -0500 (EST) Date: Thu, 7 Mar 2002 11:41:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Stephen Kent , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 7 Mar 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > If someone has just one IP address to use as his local endpoint, then > > probably 64K IPsec connections is more than enough for him. That box has > > to first be able to handle so many IPsec connections. > > You are missing one thing. Yes, there is a potential to hold 64k > connections, except by the birthday paradox you will get a hash > collision after 256 connections. Don't you think that 256 connections > is too few? > > -derek > Yes, I stumped on the "birthday paradox". Thanks to Paul and you too for pointing that out. Hey, I haven't given out the full details of my "hash function". I think we should be more careful and not to pick a real hash fuction :-) A hash fuction could just be: output the last two bytes of the SPI, assuming that the SPI was generated randomly or atleast the last two bytes of the initiator SPI was generated randomly. I would like to request help in coming up with a good hash function for this specific purpose. I am still waiting on the help in general that I requested earlier too. thanks, chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 7 12:19:57 2002 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 g27KJu816550; Thu, 7 Mar 2002 12:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28481 Thu, 7 Mar 2002 14:43:55 -0500 (EST) Message-Id: <200203071949.g27JnEUe003226@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Thu, 07 Mar 2002 10:28:18 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 14:49:14 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >In a pure peer-to-peer scenario, even 64 or so SA's won't present much >difficulty. But if a machine is an aggregator or a gateway terminating >the SA's, then you have to multiply the small to medium number of Sa's >per peer by the number of peers. That's not cheap. If you're using the same certificates/keys, then the caching I mentioned will help you. >You still need to go throught the rsa checks, even if you cache the >certificates, which, when you think orders of magnitude larger than PC >to PC communications becomes very expensive. You don't cache the certificates, you cache the result of the verification of the certificates. If you received the same set of certificates as an hour ago (when you established the SA last), and you verified all the signatures then, you don't need to re-check the signatures. You need to verify the RSA signature on the message itself. >Some people claim that rsa is 'cheap'. I tend to disagree (symmetric >cryptography is cheap). Yes, there's new hardware that can do it >fast. There's also old hardware that will want to run ikev2. The cost >of an rsa operation is not trivial, and when multiplied by large >numbers of peers becomes decidedly non-trivial. On an 850Mhz P3 IBM laptop running two network interfaces, doing bridging over IPsec (yes, really), playing MP3s, and running X (I'm sending this email from it), I get the following: nyarlathotep_JFK_38_$_openssl speed rsa To get the most accurate results, try to run this program when this computer is idle. Doing 512 bit private rsa's for 10s: 3102 512 bit private RSA's in 9.59s Doing 512 bit public rsa's for 10s: 35182 512 bit public RSA's in 9.56s Doing 1024 bit private rsa's for 10s: 554 1024 bit private RSA's in 9.62s Doing 1024 bit public rsa's for 10s: 11088 1024 bit public RSA's in 9.59s Doing 2048 bit private rsa's for 10s: 91 2048 bit private RSA's in 9.68s Doing 2048 bit public rsa's for 10s: 3297 2048 bit public RSA's in 9.60s Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 9.70s Doing 4096 bit public rsa's for 10s: 957 4096 bit public RSA's in 9.65s OpenSSL 0.9.6b [engine] 9 Jul 2001 built on: date not available options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) compiler: information not available sign verify sign/s verify/s rsa 512 bits 0.0031s 0.0003s 323.3 3679.2 rsa 1024 bits 0.0174s 0.0009s 57.6 1156.7 rsa 2048 bits 0.1064s 0.0029s 9.4 343.4 rsa 4096 bits 0.6931s 0.0101s 1.4 99.2 Your concentrator is likely to be somewhat faster than this laptop. I think that, even in software, it can deal with a few hundred RSA operations/sec. -Angelos From owner-ipsec@lists.tislabs.com Thu Mar 7 12:30:12 2002 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 g27KUB816881; Thu, 7 Mar 2002 12:30:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28606 Thu, 7 Mar 2002 14:52:58 -0500 (EST) Date: Thu, 7 Mar 2002 12:04:02 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Eric Rescorla , Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203071949.g27JnEUe003226@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >In a pure peer-to-peer scenario, even 64 or so SA's won't present much > >difficulty. But if a machine is an aggregator or a gateway terminating > >the SA's, then you have to multiply the small to medium number of Sa's > >per peer by the number of peers. That's not cheap. > > If you're using the same certificates/keys, then the caching I mentioned > will help you. > > >You still need to go throught the rsa checks, even if you cache the > >certificates, which, when you think orders of magnitude larger than PC > >to PC communications becomes very expensive. > > You don't cache the certificates, you cache the result of the verification of > the certificates. If you received the same set of certificates as an hour ago > (when you established the SA last), and you verified all the signatures then, > you don't need to re-check the signatures. You need to verify the RSA signature > on the message itself. > That's what I meant. > >Some people claim that rsa is 'cheap'. I tend to disagree (symmetric > >cryptography is cheap). Yes, there's new hardware that can do it > >fast. There's also old hardware that will want to run ikev2. The cost > >of an rsa operation is not trivial, and when multiplied by large > >numbers of peers becomes decidedly non-trivial. > > On an 850Mhz P3 IBM laptop running two network interfaces, doing bridging over > IPsec (yes, really), playing MP3s, and running X (I'm sending this email from > it), I get the following: > > nyarlathotep_JFK_38_$_openssl speed rsa > To get the most accurate results, try to run this > program when this computer is idle. > Doing 512 bit private rsa's for 10s: 3102 512 bit private RSA's in 9.59s > Doing 512 bit public rsa's for 10s: 35182 512 bit public RSA's in 9.56s > Doing 1024 bit private rsa's for 10s: 554 1024 bit private RSA's in 9.62s > Doing 1024 bit public rsa's for 10s: 11088 1024 bit public RSA's in 9.59s > Doing 2048 bit private rsa's for 10s: 91 2048 bit private RSA's in 9.68s > Doing 2048 bit public rsa's for 10s: 3297 2048 bit public RSA's in 9.60s > Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 9.70s > Doing 4096 bit public rsa's for 10s: 957 4096 bit public RSA's in 9.65s > OpenSSL 0.9.6b [engine] 9 Jul 2001 > built on: date not available > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) > compiler: information not available > sign verify sign/s verify/s > rsa 512 bits 0.0031s 0.0003s 323.3 3679.2 > rsa 1024 bits 0.0174s 0.0009s 57.6 1156.7 > rsa 2048 bits 0.1064s 0.0029s 9.4 343.4 > rsa 4096 bits 0.6931s 0.0101s 1.4 99.2 > > Your concentrator is likely to be somewhat faster than this laptop. Actually, no. Some maybe. Some won't be. Also, the speed of the processor doesn't really matter, does it? If the speed of the processor increases, the numberof tunnels per processor will likely go up to, and customers generally want as many as possible. If you give me a faster box, I'll just want more tunnels per second. If I need 3 SA's per peer, I've just tripled the number of RSA operations I need to do on an aggregator with a single-phase protocol. Is there anyone that disagrees that for reasons of the replay counter/window, you need multiple SA's per peer (for the same user!) for QoS? If so, let's discuss that, since that's more or less my premise. > I think > that, even in software, it can deal with a few hundred RSA > operations/sec. Maybe. I still don't think rsa operations are cheap enough that we can throw them around like candy and ignore the costs completely. If I can cut the number of public key (rsa) operations down by half or down by a factor of 3, I'm all for that. No need to be wasteful. No doubt' it's one of those engineering trade-offs Radia talked about in an email a few months ago. Why not amortize that cost, while at the same time getting a "tunnel management tunnel" for free, i.e. a phase 2, as long as it doesn't overcomplicate the protocol? I'm willing to pay some complexity if it buys me a better protocol (I realize that sentence has a lot of subjective words in it, like 'complexity', 'better', and 'overcomplicate' ;), i.e. one with built-in keepalives/DPD, informational exchanges, etc. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 7 13:54:45 2002 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 g27Lsi819585; Thu, 7 Mar 2002 13:54:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29363 Thu, 7 Mar 2002 16:15:29 -0500 (EST) Message-Id: <4.3.2.7.2.20020307102307.0191ead8@mira-sjcm-2.cisco.com> X-Sender: cmadson@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 13:30:55 -0800 To: ipsec@lists.tislabs.com From: Cheryl Madson Subject: updated requirements document Cc: cmadson@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since I didn't make the cutoff, Paul graciously posted the draft on the vpnc.org web site. URL is A couple of sections still aren't written yet; hopefully soon. Beware: it's big. In part, since protocol + policy + security requirements are all together in one spot. [We can talk about how best to subdivide it later.] A couple of you sent me email, which I couldn't find later, so if I missed your issue, please remind me. Please post all comments to the mailing list, so there's an archive of them somewhere. thx - C ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Thu Mar 7 14:14:20 2002 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 g27MEJ820103; Thu, 7 Mar 2002 14:14:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29493 Thu, 7 Mar 2002 16:28:55 -0500 (EST) Message-Id: <200203072132.g27LWfUe019562@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Thu, 07 Mar 2002 12:04:02 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 16:32:41 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >That's what I meant. That's one signature per exchange. Numbers show this is easy to deal with, even for large numbers of exchanges and no hardware acceleration. >Actually, no. Some maybe. Some won't be. Also, the speed of the >processor doesn't really matter, does it? If the speed of the >processor increases, the numberof tunnels per processor will likely go >up to, and customers generally want as many as possible. You need more than 1000 tunnels/second set up, on your palmpilot ? I wonder how realistic these assumptions are --- do you have any usage statistics ? >Is there anyone that disagrees that for reasons of the replay >counter/window, you need multiple SA's per peer (for the same user!) >for QoS? If so, let's discuss that, since that's more or less my >premise. How is QoS related to the replay counter (I'm assuming you mean the ESP/AH header replay counter) ? >Maybe. I still don't think rsa operations are cheap enough that we can >throw them around like candy and ignore the costs completely. If I can >cut the number of public key (rsa) operations down by half or down by >a factor of 3, I'm all for that. No need to be wasteful. No doubt' >it's one of those engineering trade-offs Radia talked about in an >email a few months ago. They're not very cheap, but they're not prohibitively expensive either. Web servers do the inverse operation (which is a lot more expensive) all the time. Of course, cutting down on any cost is always a good thing; however, if it's at the cost of complexity (*) -- and for this particular cost, and given your assumptions as I understand them --- my choice is on the side of a few more pubkey operations if needed (no big surprise there :-) (*) The distinction between Phase 1 and Phase 2 really is ugly for implementors: there are all kinds of "secret" policy checks when determining whether an existing Phase 1 SA can be used to establish a new Phase 2 SA, because of the different parameters that may be relevant when establishing a new Phase 2 SA (initiator/responder credentials, IDs, source/destination addresses, Phase 2 parameters, etc.) I've implemented IKEv1 twice so far, and it wasn't particularly pleasant dealing with all the dependencies hidden in the protocol. >Why not amortize that cost, while at the same time getting a "tunnel >management tunnel" for free, i.e. a phase 2, as long as it doesn't >overcomplicate the protocol? I'm willing to pay some complexity if it >buys me a better protocol (I realize that sentence has a lot of >subjective words in it, like 'complexity', 'better', and >'overcomplicate' ;), i.e. one with built-in keepalives/DPD, >informational exchanges, etc. We clearly have different definitions of "better" :-) You would find many people arguing for a clear separation of protocol functionality --- huge, monolithic protocols are not pleasant to specify, analyze, implement, or debug. On a slightly more philosophical vein, they promote both bloat (see IKEv1) and bad APIs (another source of trouble and embarassments). As for informational exchanges, surely you jest :-) I have yet to see an IKE implementation that (a) does anything meaningful on receipt of an informational message, or (b) depends on information exchanges for its correct operation. -Angelos From owner-ipsec@lists.tislabs.com Thu Mar 7 14:23:50 2002 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 g27MNn820398; Thu, 7 Mar 2002 14:23:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29675 Thu, 7 Mar 2002 16:48:44 -0500 (EST) Date: Thu, 7 Mar 2002 13:59:49 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Eric Rescorla , Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203072132.g27LWfUe019562@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >That's what I meant. > > That's one signature per exchange. Numbers show this is easy to deal with, > even for large numbers of exchanges and no hardware acceleration. > > >Actually, no. Some maybe. Some won't be. Also, the speed of the > >processor doesn't really matter, does it? If the speed of the > >processor increases, the numberof tunnels per processor will likely go > >up to, and customers generally want as many as possible. > > You need more than 1000 tunnels/second set up, on your palmpilot ? What does a palm pilot have to do with anything? I'm talking about aggregators where the order of magnitude of negotiations is MUCH higher. If you tell me that a palm pilot can handle 1 tunnel with JFK and 3 tunnels with IKEv2, I'll choose IKEv2. But again: You're looking at it from the end-station point of view, where 1 or 60 doesn't REALLY matter all that much. I'm looking at it from the aggregator point of view where it clearly DOES matter. If you tell me that an aggregator with a gazillion GHz Foo processor can handle X tunnel creations per second with JFK and 3*X with IKEv2, which do you think people will want? So processor is irrelevant (it's not a variable. It's a constant). > I wonder > how realistic these assumptions are --- do you have any usage statistics ? > > >Is there anyone that disagrees that for reasons of the replay > >counter/window, you need multiple SA's per peer (for the same user!) > >for QoS? If so, let's discuss that, since that's more or less my > >premise. > > How is QoS related to the replay counter (I'm assuming you mean the ESP/AH > header replay counter) ? > Yes. Think about it: If you have load and high priority traffic on the same SA, and there are not only reordering (and prioritization) of packets as they leave the box, but also when they enter (and are processed by) the receiver AND there is prioritization and reordering happening IN THE NETWORK (assuming QoS ever becomes more prevalent), then chances are the receiver will see a LOT of the higher priority packets before he sees any low priority packets. hence each high priority packet will advance the replay window, until finally some low priority packet comes in which is rejected, since the replay window has moved too far forward due to the high priority packets. Hence: Separate SA's and replay counters. > >Maybe. I still don't think rsa operations are cheap enough that we can > >throw them around like candy and ignore the costs completely. If I can > >cut the number of public key (rsa) operations down by half or down by > >a factor of 3, I'm all for that. No need to be wasteful. No doubt' > >it's one of those engineering trade-offs Radia talked about in an > >email a few months ago. > > They're not very cheap, but they're not prohibitively expensive either. Web > servers do the inverse operation (which is a lot more expensive) all > the time. Yes, and note that there's strong demand for off-load servers to handle all those operations. > Of course, cutting down on any cost is always a good thing; however, if it's at > the cost of complexity (*) -- and for this particular cost, and given your > assumptions as I understand them --- my choice is on the side of a few more > pubkey operations if needed (no big surprise there :-) > > (*) The distinction between Phase 1 and Phase 2 really is ugly for > implementors: there are all kinds of "secret" policy checks when determining > whether an existing Phase 1 SA can be used to establish a new Phase 2 SA, > because of the different parameters that may be relevant when establishing a > new Phase 2 SA (initiator/responder credentials, IDs, source/destination > addresses, Phase 2 parameters, etc.) I've implemented IKEv1 twice so far, and > it wasn't particularly pleasant dealing with all the dependencies hidden in the > protocol. > > >Why not amortize that cost, while at the same time getting a "tunnel > >management tunnel" for free, i.e. a phase 2, as long as it doesn't > >overcomplicate the protocol? I'm willing to pay some complexity if it > >buys me a better protocol (I realize that sentence has a lot of > >subjective words in it, like 'complexity', 'better', and > >'overcomplicate' ;), i.e. one with built-in keepalives/DPD, > >informational exchanges, etc. > > We clearly have different definitions of "better" :-) > I realize that :) That's what this is all about... > You would find many people arguing for a clear separation of protocol > functionality And you'll find many people who prefer two phases due to amortization of the public key operations and management tunnel. The question is, who's in the majority. I expect we'll find out in Minneapolis :) > --- huge, monolithic protocols are not pleasant to specify, > analyze, implement, or debug. On a slightly more philosophical vein, they > promote both bloat What kind of bloat are we talking about? > (see IKEv1) and bad APIs (another source of trouble and > embarassments). > Underspecification in a protocol definition leads to bad API's, not a comprehensive protocol... > As for informational exchanges, surely you jest :-) Nope. > I have yet to see an > IKE implementation that (a) does anything meaningful on receipt of an > informational message, IOS does, I believe. Not an unprotected notify, of course. > or (b) depends on information exchanges for its > correct operation. That's because so far there's been much confusion surrounding these exchanges. If they were clearly spelled out in their use and semantics (note: well defined protocol specification), this wouldn't be nearly as confusing. We're finding that it's becoming very important to have these informational exchanges and are starting to use them more and more. jan > -Angelos > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 7 15:28:57 2002 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 g27NSv822286; Thu, 7 Mar 2002 15:28:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00181 Thu, 7 Mar 2002 17:40:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.61112.901790.504193@thomasm-u1.cisco.com> Date: Thu, 7 Mar 2002 14:50:32 -0800 (PST) To: "Angelos D. Keromytis" Cc: Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203071814.g27IEpUf021438@nyarlathotep.keromytis.org> References: <200203071814.g27IEpUf021438@nyarlathotep.keromytis.org> 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 Angelos D. Keromytis writes: > > Jan, > Let me point out that, in the test scenario you are describing, different > certificates would be used for the different QoS levels, even if though it > is the same two peers (hosts) establishing multiple SAs. I ran into > the exact same situation in a different context: per-user (or per-socket) > keying using distinct SAs for each TCP connection. Since certificates are > exchanged only during Phase 1 (in both IKE and IKEv2), you end up running > complete Phase 1/Phase 2 exchanges for each such connection. Huh? The certs are only there for identity. If I want to have two different SA's so I get differential queuing treatment, there's nothing that says that I need two different identities. I just change the traffic selectors. This isn't any different than RSVP flow selectors and queuing treatment. Mike From owner-ipsec@lists.tislabs.com Thu Mar 7 15:31:06 2002 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 g27NV6822363; Thu, 7 Mar 2002 15:31:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00298 Thu, 7 Mar 2002 17:50:57 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.61766.480181.108549@thomasm-u1.cisco.com> Date: Thu, 7 Mar 2002 15:01:26 -0800 (PST) To: "Angelos D. Keromytis" Cc: Michael Thomas , Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203072250.g27MoWUe011938@nyarlathotep.keromytis.org> References: <15495.61112.901790.504193@thomasm-u1.cisco.com> <200203072250.g27MoWUe011938@nyarlathotep.keromytis.org> 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 Angelos D. Keromytis writes: > > In message <15495.61112.901790.504193@thomasm-u1.cisco.com>, Michael Thomas wri > tes: > > > > Huh? The certs are only there for identity. If I > > want to have two different SA's so I get differential > > queuing treatment, there's nothing that says that I > > need two different identities. I just change the > > traffic selectors. This isn't any different than > > RSVP flow selectors and queuing treatment. > > If you reuse the same certs, then you can simply reuse cached results. Given > that, I assumed that different QoS levels corresponded to different > credentials. Disclaimer: I've been scanning this thread very lightly. If I'm hopelessly misreading this, feel free to ignore. I thought -- maybe wrongly -- that the point of this threadlet was that if you have multiple SA's from a single device due to QoS considerations, it would be advantageous to have some public key amortization mechanism ala quick mode. I took your response to be that they'd all require different credentials anyway, so it wouldn't help in reality. Assuming I've got this correct, I disagree: there's no reason to assume that you wouldn't use the same credentials in each case since granting QoS and/or SA's is an authorization issue. The certs are only providing the identity piece (normally). As such, being able to amortize the main mode public operations is a win in that case. Mike From owner-ipsec@lists.tislabs.com Thu Mar 7 17:20:08 2002 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 g281K8824511; Thu, 7 Mar 2002 17:20:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01208 Thu, 7 Mar 2002 19:34:13 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Jan Vilhuber'" , "'Angelos D. Keromytis'" Cc: "'Eric Rescorla'" , Subject: RE: Choosing between IKEv2 and JFK Date: Thu, 7 Mar 2002 19:37:56 -0500 Message-ID: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > What kind of bloat are we talking about? > > > (see IKEv1) and bad APIs (another source of trouble and > > embarassments). > > > > Underspecification in a protocol definition leads to bad API's, not a > comprehensive protocol... Definitely. This fact is often ignored when designing a protocol on paper (it keeps the complexity-nazis at bay), but it becomes apparent when you're trying to interop later. > > As for informational exchanges, surely you jest :-) > > Nope. > > > I have yet to see an > > IKE implementation that (a) does anything meaningful on > receipt of an > > informational message, > > or (b) depends on information exchanges for its > > correct operation. > That's because so far there's been much confusion surrounding these > exchanges. If they were clearly spelled out in their use and semantics > (note: well defined protocol specification), this wouldn't be nearly > as confusing. We're finding that it's becoming very important to have > these informational exchanges and are starting to use them more and > more. This all depends on what you think the purpose of the notifies is. JFK obviously intends the notifies to be processed by the initiator and used to alter its behaviour. I think the notify is more likely to be used as a troubleshooting tool by the user. If the SA is failing due to some configuration issue, I like to think that the peer will give me some indication of what went wrong so that I can display a message to the user instead of forcing them to call up the remote sysadmin and ask to see the negotiation logs. Also, our customer support people gradually learn what the notifies mean, and they how they correlate to various bugs or configuration issues. An alternative is to send an error message in text, but this brings up the issue of language choice, and it prevents me from choosing the text I want to display to the user. In retrospect, the notifies defined in ISAKMP are quite inadequate. I'm sure we could improve them, given what we know now. If you remember, there was an effort to more clearly define the notifies and send a more elaborate description of the problem, but this wasn't widely implemented, I think because building and parsing the more elaborate notify payload didn't integrate well into most people's existing code. Even despite this, when someone phones me and says customer X can't interop with vendor Y and they send notify Z, I can usally guess what the problem might be. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Mar 7 20:30:49 2002 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 g284Un828580; Thu, 7 Mar 2002 20:30:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02772 Thu, 7 Mar 2002 22:30:13 -0500 (EST) Message-ID: <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> From: "Jia Xu" To: "Jia Xu" Cc: References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> Subject: Problem about reassembly and fragmentation Date: Fri, 8 Mar 2002 11:40:52 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 03/08/2002 11:40:20 AM, Serialize by Router on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 03/08/2002 11:40:22 AM, Serialize complete at 03/08/2002 11:40:22 AM Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id WAA02768 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, I have a question about implementing IPSec by Bump-In-The-Wire approach. When I received IP fragments, can I directly apply IPSec transform on them individually, or should I first reassemble them into an integrated IP datagram? Thanks, Jia Xu From owner-ipsec@lists.tislabs.com Thu Mar 7 22:06:27 2002 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 g2866R829815; Thu, 7 Mar 2002 22:06:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03738 Fri, 8 Mar 2002 00:21:53 -0500 (EST) Message-ID: <3C884C59.D6411822@lucent.com> Date: Fri, 08 Mar 2002 11:00:01 +0530 From: "Nagendra B.S" X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Jia Xu , ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <3C884C0E.7688876B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Read as "As per RFC 2401" -Nagendra "Nagendra B.S" wrote: > > As per RFC 2661, all fragmented packets should be reassembled before > applying IPSEC. > > >From RFC 2401 > > Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues > > B.2 Fragmentation > > If required, IP fragmentation occurs after IPsec processing within an > IPsec implementation. Thus, transport mode AH or ESP is applied only > to whole IP datagrams (not to IP fragments). An IP packet to which > AH or ESP has been applied may itself be fragmented by routers en > route, and such fragments MUST be reassembled prior to IPsec > processing at a receiver. In tunnel mode, AH or ESP is applied to an > IP packet, the payload of which may be a fragmented IP packet. For > example, a security gateway, "bump-in-the-stack" (BITS), or "bump- > in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to > such fragments. Note that BITS or BITW implementations are examples > of where a host IPsec implementation might receive fragments to which > tunnel mode is to be applied. However, if transport mode is to be > applied, then these implementations MUST reassemble the fragments > prior to applying IPsec. > > -Nagendra > > Jia Xu wrote: > > > > Dear all, > > > > I have a question about implementing IPSec by Bump-In-The-Wire approach. When I received IP fragments, can I directly apply IPSec transform on them individually, or should I first reassemble them into an integrated IP datagram? > > > > Thanks, > > Jia Xu > > -- > ------------------------------------------------------------------------ > Nagendra B.S nbs@lucent.com > Infosys - India Phone Office : 91-80-8520261 xtn : 6566 > ------------------------------------------------------------------------ -- ------------------------------------------------------------------------ Nagendra B.S nbs@lucent.com Infosys - India Phone Office : 91-80-8520261 xtn : 6566 ------------------------------------------------------------------------ From owner-ipsec@lists.tislabs.com Thu Mar 7 22:06:30 2002 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 g2866U829828; Thu, 7 Mar 2002 22:06:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03722 Fri, 8 Mar 2002 00:20:43 -0500 (EST) Message-ID: <3C884C0E.7688876B@lucent.com> Date: Fri, 08 Mar 2002 10:58:46 +0530 From: "Nagendra B.S" X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Jia Xu CC: ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As per RFC 2661, all fragmented packets should be reassembled before applying IPSEC. >From RFC 2401 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues B.2 Fragmentation If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec. -Nagendra Jia Xu wrote: > > Dear all, > > I have a question about implementing IPSec by Bump-In-The-Wire approach. When I received IP fragments, can I directly apply IPSec transform on them individually, or should I first reassemble them into an integrated IP datagram? > > Thanks, > Jia Xu -- ------------------------------------------------------------------------ Nagendra B.S nbs@lucent.com Infosys - India Phone Office : 91-80-8520261 xtn : 6566 ------------------------------------------------------------------------ From owner-ipsec@lists.tislabs.com Thu Mar 7 23:31:02 2002 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 g287V1808426; Thu, 7 Mar 2002 23:31:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA04390 Fri, 8 Mar 2002 01:36:11 -0500 (EST) Message-Id: <200203080634.ADY27396@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 07 Mar 2002 22:40:37 -0800 To: "Nagendra B.S" , Jia Xu From: Scott Fluhrer Subject: Re: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com In-Reply-To: <3C884C0E.7688876B@lucent.com> References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:28 PM 3/7/02 , Nagendra B.S wrote: >As per RFC [2401], all fragmented packets should be reassembled before >applying IPSEC. How do you come to that conclusion? The text reads: In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. It would appear to state that if you are using tunnel mode, you can encrypt fragments. >Jia Xu wrote: >> >> Dear all, >> >> I have a question about implementing IPSec by Bump-In-The-Wire approach. When I received IP fragments, can I directly apply IPSec transform on them individually, or should I first reassemble them into an integrated IP datagram? >> >> Thanks, >> Jia Xu > >-- >------------------------------------------------------------------------ >Nagendra B.S nbs@lucent.com >Infosys - India Phone Office : 91-80-8520261 xtn : 6566 >------------------------------------------------------------------------ > From owner-ipsec@lists.tislabs.com Fri Mar 8 04:43:23 2002 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 g28ChM812921; Fri, 8 Mar 2002 04:43:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07110 Fri, 8 Mar 2002 06:45:31 -0500 (EST) Message-Id: <200203081157.GAA29391@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-jfk-01.txt Date: Fri, 08 Mar 2002 06:57:05 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Just Fast Keying (JFK) Author(s) : W. Aiello, S. Bellovin et al. Filename : draft-ietf-ipsec-jfk-01.txt Pages : Date : 07-Mar-02 This draft discusses JFK, a key management protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-01.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-ietf-ipsec-jfk-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-jfk-01.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: <20020307120035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-jfk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-jfk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 8 04:43:23 2002 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 g28ChM812920; Fri, 8 Mar 2002 04:43:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07109 Fri, 8 Mar 2002 06:45:30 -0500 (EST) Message-Id: <200203081157.GAA29379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-reqts-01.txt Date: Fri, 08 Mar 2002 06:57:00 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec-NAT Compatibility Requirements Author(s) : B. Aboba Filename : draft-ietf-ipsec-nat-reqts-01.txt Pages : 14 Date : 07-Mar-02 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide tele-commuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by tele-commuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-01.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-ietf-ipsec-nat-reqts-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-01.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: <20020307120020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 8 07:36:11 2002 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 g28FaA823698; Fri, 8 Mar 2002 07:36:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08544 Fri, 8 Mar 2002 09:49:13 -0500 (EST) To: Michael Thomas Cc: "Angelos D. Keromytis" , Jan Vilhuber , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: Choosing between IKEv2 and JFK References: <200203071814.g27IEpUf021438@nyarlathotep.keromytis.org> <15495.61112.901790.504193@thomasm-u1.cisco.com> Date: 08 Mar 2002 10:00:43 -0500 In-Reply-To: <15495.61112.901790.504193@thomasm-u1.cisco.com> Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Huh? The certs are only there for identity. If I > want to have two different SA's so I get differential > queuing treatment, there's nothing that says that I > need two different identities. I just change the > traffic selectors. This isn't any different than > RSVP flow selectors and queuing treatment. No, in reality the certs are there for authorization. It's just that people don'e understand the concept of capabilities, so we have this ad-hoc "identity" cert and map it via some local lookup method to a set of capabilities. You receive an "identity" cert, validate the cert, validate that the message is authentic using this cert, and then you lookup the capabilities of this "identity" to validate the authorization for the requested operation. In terms of different flow selectors, it is perfectly reasonable to say that each flow requires its own certificate specifying the capability of that particular flow. Similarly, you could specify an "identity" that is capable of both flows. The problem with using identity for capability verification is that there is no way of knowing _which_ capability actually applies to any situation. You have to depend on the user requesting the appropriate flow characteristics, but unless there is a real-world cost associated with that choice, what incentive does the user have? For example, if I could use my personal cert to specify a normal connection or a high-QoS connection and the costs to me were the same, why wouldn't I specify the high-QoS connection all the time? OTOH, if there were clearly different certificates for teh two capabilities, then you could restrict access to the different certs. Basically, I'm saying that you are both right -- you are just coming from very different viewpoints. However neither is wrong. > Mike -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 8 07:48:01 2002 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 g28Fm0824661; Fri, 8 Mar 2002 07:48:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08697 Fri, 8 Mar 2002 10:09:51 -0500 (EST) Message-Id: <200203072250.g27MoWUe011938@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Thomas Cc: Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Thu, 07 Mar 2002 14:50:32 PST." <15495.61112.901790.504193@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 17:50:32 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <15495.61112.901790.504193@thomasm-u1.cisco.com>, Michael Thomas wri tes: > > Huh? The certs are only there for identity. If I > want to have two different SA's so I get differential > queuing treatment, there's nothing that says that I > need two different identities. I just change the > traffic selectors. This isn't any different than > RSVP flow selectors and queuing treatment. If you reuse the same certs, then you can simply reuse cached results. Given that, I assumed that different QoS levels corresponded to different credentials. -Angelos From owner-ipsec@lists.tislabs.com Fri Mar 8 07:48:37 2002 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 g28Fma824694; Fri, 8 Mar 2002 07:48:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08706 Fri, 8 Mar 2002 10:10:51 -0500 (EST) Message-Id: <200203072303.g27N3BUe000435@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Thomas Cc: Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Thu, 07 Mar 2002 15:01:26 PST." <15495.61766.480181.108549@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 18:03:11 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Both approaches are valid: you might be using the same credentials, or different credentials, in setting up different QoS streams. In the case of "same credentials", certificate verification can be cached. In the case of "different credentials", the Phase 1/Phase 2 distinction doesn't buy you anything (you have to do a Phase 1 for each different set of credentials). -Angelos In message <15495.61766.480181.108549@thomasm-u1.cisco.com>, Michael Thomas wri tes: > >Disclaimer: I've been scanning this thread very >lightly. If I'm hopelessly misreading this, feel >free to ignore. > >I thought -- maybe wrongly -- that the point of >this threadlet was that if you have multiple SA's >from a single device due to QoS considerations, it >would be advantageous to have some public key >amortization mechanism ala quick mode. I took your >response to be that they'd all require different >credentials anyway, so it wouldn't help in reality. > >Assuming I've got this correct, I disagree: >there's no reason to assume that you wouldn't use >the same credentials in each case since granting >QoS and/or SA's is an authorization issue. The >certs are only providing the identity piece >(normally). As such, being able to amortize the >main mode public operations is a win in that case. > > Mike From owner-ipsec@lists.tislabs.com Fri Mar 8 07:49:00 2002 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 g28Fn0824712; Fri, 8 Mar 2002 07:49:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08694 Fri, 8 Mar 2002 10:09:50 -0500 (EST) Message-Id: <200203072239.g27Md2Ue005653@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Thu, 07 Mar 2002 13:59:49 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 17:39:02 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >Yes. Think about it: If you have load and high priority traffic on the >same SA, and there are not only reordering (and prioritization) of >packets as they leave the box, but also when they enter (and are >processed by) the receiver AND there is prioritization and reordering >happening IN THE NETWORK (assuming QoS ever becomes more prevalent), >then chances are the receiver will see a LOT of the higher priority >packets before he sees any low priority packets. > >hence each high priority packet will advance the replay window, until >finally some low priority packet comes in which is rejected, since the >replay window has moved too far forward due to the high priority >packets. > >Hence: Separate SA's and replay counters. Yes, in that scenario you would need separate SAs. However, I would assume that, in the case of multiple traffic streams of different priorities going over the same IPsec tunnel (*), the sender: a) would request for the ESP traffic the same priority level as the highest priority among the different data streams, and b) would do its own prioritization for packets entering the tunnel (treating the tunnel as a link on its own) The network and the receiver can do prioritization only if: 1) they can decrypt the ESP packets (in which case, there's not issue with the replay window), or 2) the packets are marked appropriately by the sender So the sender has control over QoS in this case. Then again, I'm not a QoS person. (*) I use the term tunnel in a general sense, I don't want to start another holy war about its use and exact semantics, or transport vs. tunnel mode. >> --- huge, monolithic protocols are not pleasant to specify, >> analyze, implement, or debug. On a slightly more philosophical vein, they >> promote both bloat > >What kind of bloat are we talking about? Piling up of not-very-necessary features. >> (see IKEv1) and bad APIs (another source of trouble and >> embarassments). > >Underspecification in a protocol definition leads to bad API's, not a >comprehensive protocol... To begin with, a complex protocol is more likely to be underspecified. And, complicated protocols lead to complicated APIs (because people feel the need to exploit all the features offered by the protocol). >IOS does, I believe. Not an unprotected notify, of course. That hasn't been my experience, with any vendor I've interoperated with (mind you, *my* implementations are not doing any better). >That's because so far there's been much confusion surrounding these >exchanges. If they were clearly spelled out in their use and semantics >(note: well defined protocol specification), this wouldn't be nearly >as confusing. We're finding that it's becoming very important to have >these informational exchanges and are starting to use them more and >more. As far as I can tell, everyone is simply ignoring them (except for a couple of easy-to-understand cases); and, the more complicated the protocol, the harder it is to figure out what the right response is to an error message. Again, not all notifications are bad, just that they are not as useful as people think (and that's IMOE). Cheers, -Angelos From owner-ipsec@lists.tislabs.com Fri Mar 8 08:18:44 2002 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 g28GIi825966; Fri, 8 Mar 2002 08:18:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09006 Fri, 8 Mar 2002 10:39:43 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.56790.927000.46587@gargle.gargle.HOWL> Date: Fri, 8 Mar 2002 10:50:46 -0500 From: Paul Koning To: sfluhrer@cisco.com Cc: nbs@lucent.com, xujia@is.ac.cn, ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 7 March 2002) by Scott Fluhrer: > At 09:28 PM 3/7/02 , Nagendra B.S wrote: > >As per RFC [2401], all fragmented packets should be reassembled before > >applying IPSEC. > > How do you come to that conclusion? The text reads: > > In tunnel mode, AH or ESP is applied to an > IP packet, the payload of which may be a fragmented IP packet. For > example, a security gateway, "bump-in-the-stack" (BITS), or "bump- > in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to > such fragments. > > It would appear to state that if you are using tunnel mode, you can > encrypt fragments. I think the mixup is between encryption and decryption. You can encrypt any IP packet individually -- that includes packets which are fragments. If the network has fragmented packets after IPsec has done its thing, i.e., the outer header indicates fragmentation, then you must reassemble at that level before decrypting. paul From owner-ipsec@lists.tislabs.com Fri Mar 8 09:36:25 2002 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 g28HaP801248; Fri, 8 Mar 2002 09:36:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09570 Fri, 8 Mar 2002 11:42:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 8 Mar 2002 11:52:57 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: RE: NAT Traversal Cc: "'ipsec mailling list'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:15 AM -0800 3/7/02, Chinna N.R. Pellacuru wrote: > >Elswehere the RFC alludes to that, >> noting that any structure associated with the SPI up to the receiver, >> while the transmitter must view the SPI as opaque. Does your proposal >> require that a receiver coordinate with a NAT device in constructing >> an SPI? If so, that arguably violates the SPI model embodied in 2401. >> > >IMHO, a NAT device is not an IPsec device, and the NAT device is not a >receiver of the SPI. The NAT device is only trying to translate ESP >traffic by *looking* at the SPIs in both directions. > >Our scheme suggests that the Quick Mode responder choose to pick a SPI >according to a known alogrithm so that the NAT device can use that extra >information to translate the ESP traffic. The transmitter will still view >the SPI as opaque. The Quick Mode responder chooses to pick its SPI by >using a hash function on the Quick Mode initiator SPI to derive half of >its SPI. This hash function is known to the NAT device, and the NAT device >uses that information to Pair the incoming and outgoing SPIs. > >We do not require all IPsec implementations to do it. We only require >implementations that want to implement our proposal to do so all the time. >All IPsec implementations can do it too. We will not restrict any IPsec >implementation from doing it. The proposal only advices the various IPsec >peers to pick their SPIs in a particular way so that the intermediate NAT >devices can pair the SPIs. This extra information is in no way used by the >IPsec peers themselves. This extra information is only used by the NAT >device. > > chinna Agreed that the NAT devices you are discussing at not IPsec devices. An to the extent that the NAT device is in the same administrative domain as the IPsec receiver who selects the SPI values, then one could argue that it is still a local decision and thus not in conflict with the model of 2401. However, if the NAT device is in a different admin domain, I am less comfortable that SPI selection remains a local matter. Steve From owner-ipsec@lists.tislabs.com Fri Mar 8 09:44:10 2002 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 g28Hi9801498; Fri, 8 Mar 2002 09:44:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09728 Fri, 8 Mar 2002 12:02:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203071949.g27JnEUe003226@nyarlathotep.keromytis.org> References: <200203071949.g27JnEUe003226@nyarlathotep.keromytis.org> Date: Fri, 8 Mar 2002 12:06:44 -0500 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Choosing between IKEv2 and JFK Cc: Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >You don't cache the certificates, you cache the result of the verification of >the certificates. If you received the same set of certificates as an hour ago >(when you established the SA last), and you verified all the signatures then, >you don't need to re-check the signatures. You need to verify the >RSA signature >on the message itself. Angelos, In many cases, caching validated certs is appropriate, because one may have an opportunity to reuse CA certs that were part of the cert path. Steve From owner-ipsec@lists.tislabs.com Fri Mar 8 09:50:57 2002 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 g28Hou801759; Fri, 8 Mar 2002 09:50:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09795 Fri, 8 Mar 2002 12:10:30 -0500 (EST) Message-Id: <200203081710.ADY35684@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 08 Mar 2002 09:16:31 -0800 To: Paul Koning , sfluhrer@cisco.com From: Scott Fluhrer Subject: Re: Problem about reassembly and fragmentation Cc: nbs@lucent.com, xujia@is.ac.cn, ipsec@lists.tislabs.com In-Reply-To: <15496.56790.927000.46587@gargle.gargle.HOWL> References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:50 AM 3/8/02 , Paul Koning wrote: >Excerpt of message (sent 7 March 2002) by Scott Fluhrer: >> At 09:28 PM 3/7/02 , Nagendra B.S wrote: >> >As per RFC [2401], all fragmented packets should be reassembled before >> >applying IPSEC. >> >> How do you come to that conclusion? The text reads: >> >> In tunnel mode, AH or ESP is applied to an >> IP packet, the payload of which may be a fragmented IP packet. For >> example, a security gateway, "bump-in-the-stack" (BITS), or "bump- >> in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to >> such fragments. >> >> It would appear to state that if you are using tunnel mode, you can >> encrypt fragments. > >I think the mixup is between encryption and decryption. You can >encrypt any IP packet individually -- that includes packets which are >fragments. Obnit: you can encrypt fragments in tunnel mode. In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments. And yes, there are IPSec implementations where you could possibly see fragments that need to be encrypted using transport mode. > >If the network has fragmented packets after IPsec has done its thing, >i.e., the outer header indicates fragmentation, then you must >reassemble at that level before decrypting. > > paul > From owner-ipsec@lists.tislabs.com Fri Mar 8 10:36:19 2002 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 g28IaJ804454; Fri, 8 Mar 2002 10:36:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10136 Fri, 8 Mar 2002 12:52:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203081710.ADY35684@mira-sjcm-3.cisco.com> References: <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> Date: Fri, 8 Mar 2002 13:02:38 -0500 To: Scott Fluhrer From: Stephen Kent Subject: Re: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:16 AM -0800 3/8/02, Scott Fluhrer wrote: >At 07:50 AM 3/8/02 , Paul Koning wrote: >>Excerpt of message (sent 7 March 2002) by Scott Fluhrer: >>> At 09:28 PM 3/7/02 , Nagendra B.S wrote: >>> >As per RFC [2401], all fragmented packets should be reassembled before >>> >applying IPSEC. >>> >>> How do you come to that conclusion? The text reads: >>> >>> In tunnel mode, AH or ESP is applied to an >>> IP packet, the payload of which may be a fragmented IP packet. For >>> example, a security gateway, "bump-in-the-stack" (BITS), or "bump- >>> in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to >>> such fragments. >>> >>> It would appear to state that if you are using tunnel mode, you can >>> encrypt fragments. >> >>I think the mixup is between encryption and decryption. You can >>encrypt any IP packet individually -- that includes packets which are >>fragments. > >Obnit: you can encrypt fragments in tunnel mode. In transport mode, >you can only encrypt unfragmented packets, and so you must reassemble >(or drop) if you get fragments. And yes, there are IPSec >implementations where you could possibly see fragments that need to be >encrypted using transport mode. RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name. In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP? Steve From owner-ipsec@lists.tislabs.com Fri Mar 8 10:47:47 2002 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 g28Ilk805676; Fri, 8 Mar 2002 10:47:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10298 Fri, 8 Mar 2002 13:10:01 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4.3.2.7.2.20020307102307.0191ead8@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20020307102307.0191ead8@mira-sjcm-2.cisco.com> Date: Fri, 8 Mar 2002 10:19:54 -0800 To: Cheryl Madson , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: updated requirements document Cc: cmadson@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few of you wanted a non-PDF version. I have put up the HTML that Cheryl sent me at . --Paul Hoffman At 1:30 PM -0800 3/7/02, Cheryl Madson wrote: >Since I didn't make the cutoff, Paul graciously posted the >draft on the vpnc.org web site. > >URL is > > >A couple of sections still aren't written yet; hopefully soon. > >Beware: it's big. In part, since protocol + policy + security requirements >are all together in one spot. [We can talk about how best to subdivide >it later.] > >A couple of you sent me email, which I couldn't find later, so if I missed >your issue, please remind me. > >Please post all comments to the mailing list, so there's an archive of them >somewhere. > >thx - C > > >==================================== >Cheryl Madson >Core IP Engineering; Security and Services >Cisco Systems, Inc. >cmadson@cisco.com From owner-ipsec@lists.tislabs.com Fri Mar 8 10:50:26 2002 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 g28IoQ805728; Fri, 8 Mar 2002 10:50:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10319 Fri, 8 Mar 2002 13:11:41 -0500 (EST) Date: Fri, 8 Mar 2002 10:22:09 -0800 (PST) From: Jan Vilhuber X-Sender: vilhuber@localhost To: "Angelos D. Keromytis" cc: Michael Thomas , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203072303.g27N3BUe000435@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Angelos D. Keromytis wrote: > > Both approaches are valid: you might be using the same credentials, or > different credentials, in setting up different QoS streams. In the case > of "same credentials", certificate verification can be cached. In the case > of "different credentials", the Phase 1/Phase 2 distinction doesn't buy > you anything (you have to do a Phase 1 for each different set of credentials). > Agreed. The 'different credentials' case is irrelevant to this discussion. It's the 'same credentials' case that matters. In which case you still have a few rsa operations to do, and it would be beneficial to amortize them with a phase 2. jan > -Angelos > > In message <15495.61766.480181.108549@thomasm-u1.cisco.com>, Michael Thomas wri > tes: > > > >Disclaimer: I've been scanning this thread very > >lightly. If I'm hopelessly misreading this, feel > >free to ignore. > > > >I thought -- maybe wrongly -- that the point of > >this threadlet was that if you have multiple SA's > >from a single device due to QoS considerations, it > >would be advantageous to have some public key > >amortization mechanism ala quick mode. I took your > >response to be that they'd all require different > >credentials anyway, so it wouldn't help in reality. > > > >Assuming I've got this correct, I disagree: > >there's no reason to assume that you wouldn't use > >the same credentials in each case since granting > >QoS and/or SA's is an authorization issue. The > >certs are only providing the identity piece > >(normally). As such, being able to amortize the > >main mode public operations is a win in that case. > > > > Mike > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Mar 8 11:03:59 2002 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 g28J3x806021; Fri, 8 Mar 2002 11:03:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10418 Fri, 8 Mar 2002 13:21:54 -0500 (EST) Message-Id: <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Mar 2002 10:32:49 -0800 To: Stephen Kent From: Scott Fluhrer Subject: Re: Problem about reassembly and fragmentation Cc: Scott Fluhrer , ipsec@lists.tislabs.com In-Reply-To: References: <200203081710.ADY35684@mira-sjcm-3.cisco.com> <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:02 AM 3/8/2002, Stephen Kent wrote: >At 9:16 AM -0800 3/8/02, Scott Fluhrer wrote: >>At 07:50 AM 3/8/02 , Paul Koning wrote: >>>Excerpt of message (sent 7 March 2002) by Scott Fluhrer: >>>> At 09:28 PM 3/7/02 , Nagendra B.S wrote: >>>> >As per RFC [2401], all fragmented packets should be reassembled before >>>> >applying IPSEC. >>>> >>>> How do you come to that conclusion? The text reads: >>>> >>>> In tunnel mode, AH or ESP is applied to an >>>> IP packet, the payload of which may be a fragmented IP packet. For >>>> example, a security gateway, "bump-in-the-stack" (BITS), or "bump- >>>> in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to >>>> such fragments. >>>> >>>> It would appear to state that if you are using tunnel mode, you can >>>> encrypt fragments. >>> >>>I think the mixup is between encryption and decryption. You can >>>encrypt any IP packet individually -- that includes packets which are >>>fragments. >> >>Obnit: you can encrypt fragments in tunnel mode. In transport mode, >>you can only encrypt unfragmented packets, and so you must reassemble >>(or drop) if you get fragments. And yes, there are IPSec >>implementations where you could possibly see fragments that need to be >>encrypted using transport mode. > >RFC 2401 states that transport mode is to be used only between endpoints, >and that the next layer protocol is typically a transport layer protocol, >apropos the mode name. In what circumstances do you see fragments (hence >another IP header) being encapsulated in transport mode? L2TP? The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point. The BITW itself doesn't have an IP address, and so it borrows the end point's. To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec. And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above... >Steve From owner-ipsec@lists.tislabs.com Fri Mar 8 12:18:40 2002 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 g28KId807472; Fri, 8 Mar 2002 12:18:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11136 Fri, 8 Mar 2002 14:31:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> References: <200203081710.ADY35684@mira-sjcm-3.cisco.com> <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> Date: Fri, 8 Mar 2002 14:44:09 -0500 To: Scott Fluhrer From: Stephen Kent Subject: Re: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1196505838==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1196505838==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote: >>>> >>> >>>Obnit: you can encrypt fragments in tunnel mode. In transport mode, >>>you can only encrypt unfragmented packets, and so you must reassemble >>>(or drop) if you get fragments. And yes, there are IPSec >>>implementations where you could possibly see fragments that need to be >>>encrypted using transport mode. >> >>RFC 2401 states that transport mode is to be used only between >>endpoints, and that the next layer protocol is typically a >>transport layer protocol, apropos the mode name. In what >>circumstances do you see fragments (hence another IP header) being >>encapsulated in transport mode? L2TP? > >The implementation I'm thinking about acts as a BITW in front of a >specific end point (IP address), and intercepts all traffic to/from >the end point, and encrypts/decrypts traffic on behalf of the end >point. The BITW itself doesn't have an IP address, and so it >borrows the end point's. To anything past the BITW, the BITW and >the endpoint appear to be one unit that does (among other things) >IPSec. And so, if the end point sends fragments with itself as the >source IP address, then the BITW may decide to encrypt them, and if >the SA it selects happens to be in transport mode, well, we're in >exactly the scenario I eluded to above... > >>Steve Scott, Note the following from 2401 (Appendix B), with my application of bold text: B.2 Fragmentation If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec. Steve --============_-1196505838==_ma============ Content-Type: text/html; charset="us-ascii" Re: Problem about reassembly and fragmentation
At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote:


Obnit: you can encrypt fragments in tunnel mode.  In transport mode,
you can only encrypt unfragmented packets, and so you must reassemble
(or drop) if you get fragments.  And yes, there are IPSec
implementations where you could possibly see fragments that need to be
encrypted using transport mode.

RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name.  In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP?

The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point.  The BITW itself doesn't have an IP address, and so it borrows the end point's.  To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec.  And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above...
Steve

Scott,

Note the following from 2401 (Appendix B), with my application of bold text:

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an
   IPsec implementation.  Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an
   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
   such fragments.  Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which
   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.

Steve
--============_-1196505838==_ma============-- From owner-ipsec@lists.tislabs.com Fri Mar 8 13:21:14 2002 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 g28LLD809011; Fri, 8 Mar 2002 13:21:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11742 Fri, 8 Mar 2002 15:37:35 -0500 (EST) X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 From: "Joseph Tardo" To: "Paul Koning" , sfluhrer@cisco.com cc: nbs@lucent.com, xujia@is.ac.cn, ipsec@lists.tislabs.com Subject: RE: Problem about reassembly and fragmentation Date: Fri, 8 Mar 2002 12:33:10 -0800 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <15496.56790.927000.46587@gargle.gargle.HOWL> X-WSS-ID: 1097C0793220087-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What if you are supporting port policies? Don't you need the transport header to verify policy on the decrypted fragments? -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning Sent: Friday, March 08, 2002 7:51 AM To: sfluhrer@cisco.com Cc: nbs@lucent.com; xujia@is.ac.cn; ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation Excerpt of message (sent 7 March 2002) by Scott Fluhrer: > At 09:28 PM 3/7/02 , Nagendra B.S wrote: > >As per RFC [2401], all fragmented packets should be reassembled before > >applying IPSEC. > > How do you come to that conclusion? The text reads: > > In tunnel mode, AH or ESP is applied to an > IP packet, the payload of which may be a fragmented IP packet. For > example, a security gateway, "bump-in-the-stack" (BITS), or "bump- > in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to > such fragments. > > It would appear to state that if you are using tunnel mode, you can > encrypt fragments. I think the mixup is between encryption and decryption. You can encrypt any IP packet individually -- that includes packets which are fragments. If the network has fragmented packets after IPsec has done its thing, i.e., the outer header indicates fragmentation, then you must reassemble at that level before decrypting. paul From owner-ipsec@lists.tislabs.com Fri Mar 8 13:21:27 2002 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 g28LLR809024; Fri, 8 Mar 2002 13:21:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11781 Fri, 8 Mar 2002 15:43:08 -0500 (EST) Message-Id: <4.3.2.7.2.20020308125145.035bf400@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Mar 2002 12:54:09 -0800 To: "Joseph Tardo" From: Scott Fluhrer Subject: RE: Problem about reassembly and fragmentation Cc: "Paul Koning" , sfluhrer@cisco.com, nbs@lucent.com, xujia@is.ac.cn, ipsec@lists.tislabs.com In-Reply-To: References: <15496.56790.927000.46587@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:33 PM 3/8/2002, Joseph Tardo wrote: >What if you are supporting port policies? Don't you need the transport >header to verify policy on the decrypted fragments? Well, yes, if your SPD specifies ports, then you will need to find out what the ports are before applying the policy. However, that doesn't apply SPD doesn't specify ports (and sometimes they don't), and even if it does, there are ways short of total reassembly for gaining that information. -- scott From owner-ipsec@lists.tislabs.com Fri Mar 8 15:16:12 2002 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 g28NGB811846; Fri, 8 Mar 2002 15:16:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12568 Fri, 8 Mar 2002 17:22:32 -0500 (EST) Message-Id: <4.3.2.7.2.20020308141911.035c9498@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Mar 2002 14:33:35 -0800 To: Stephen Kent From: Scott Fluhrer Subject: Re: Problem about reassembly and fragmentation Cc: Scott Fluhrer , ipsec@lists.tislabs.com In-Reply-To: References: <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:44 AM 3/8/2002, Stephen Kent wrote:
At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote:

Obnit: you can encrypt fragments in tunnel mode.  In transport mode,
you can only encrypt unfragmented packets, and so you must reassemble
(or drop) if you get fragments.  And yes, there are IPSec
implementations where you could possibly see fragments that need to be
encrypted using transport mode.

RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name.  In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP?

The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point.  The BITW itself doesn't have an IP address, and so it borrows the end point's.  To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec.  And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above...
Steve

Scott,

Note the following from 2401 (Appendix B), with my application of bold text:

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an

   IPsec implementation. Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an

   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to

   such fragments. Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which

   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.



I confess I am slightly confused: I thought I was saying precisely what the highlighted text says.  That is, when I said:

> In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments.

I meant that "if transport mode is applied, then you must reassemble the fragments prior to applying IPSec".  This would appear to be precisely what the RFC says, except that the RFC specifies it only for "these implementations" (by which the RFC doesn't really mean this restriction is limited only to BITS and BITW implementations), and that I added the proviso that dropping it was possible, mostly for completeness.

Just out of curiosity, what did you think I meant?  You're not the only one who raised a question, and so I'd like to know how I was unclear.

--
scott

From owner-ipsec@lists.tislabs.com Fri Mar 8 15:36:22 2002 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 g28NaM812211; Fri, 8 Mar 2002 15:36:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12739 Fri, 8 Mar 2002 17:41:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20020308141911.035c9498@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> <000d01c1c639$7e45be60$1e72788a@ca.alcatel.com> <010c01c1c653$0ba6f1c0$8800a8c0@xujia319> <200203080634.ADY27396@mira-sjcm-3.cisco.com> <200203081710.ADY35684@mira-sjcm-3.cisco.com> <4.3.2.7.2.20020308102455.035a2008@mira-sjcm-3.cisco.com> <4.3.2.7.2.20020308141911.035c9498@mira-sjcm-3.cisco.com> Date: Fri, 8 Mar 2002 17:49:02 -0500 To: Scott Fluhrer From: Stephen Kent Subject: Re: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1196494464==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1196494464==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote: >At 11:44 AM 3/8/2002, Stephen Kent wrote: > >>At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote: >> >>>>> >>>>>Obnit: you can encrypt fragments in tunnel mode. In transport mode, >>>>>you can only encrypt unfragmented packets, and so you must reassemble >>>>>(or drop) if you get fragments. And yes, there are IPSec >>>>>implementations where you could possibly see fragments that need to be >>>>>encrypted using transport mode. >>>>> >>>> >>>>RFC 2401 states that transport mode is to be used only between >>>>endpoints, and that the next layer protocol is typically a >>>>transport layer protocol, apropos the mode name. In what >>>>circumstances do you see fragments (hence another IP header) >>>>being encapsulated in transport mode? L2TP? >>>> >>> >>>The implementation I'm thinking about acts as a BITW in front of a >>>specific end point (IP address), and intercepts all traffic >>>to/from the end point, and encrypts/decrypts traffic on behalf of >>>the end point. The BITW itself doesn't have an IP address, and so >>>it borrows the end point's. To anything past the BITW, the BITW >>>and the endpoint appear to be one unit that does (among other >>>things) IPSec. And so, if the end point sends fragments with >>>itself as the source IP address, then the BITW may decide to >>>encrypt them, and if the SA it selects happens to be in transport >>>mode, well, we're in exactly the scenario I eluded to above... >>> >>>>Steve >>>> >> >>Scott, >> >>Note the following from 2401 (Appendix B), with my application of bold text: >> >>B.2 Fragmentation >> >> If required, IP fragmentation occurs after IPsec processing within an >> IPsec implementation. Thus, transport mode AH or ESP is applied only >> to whole IP datagrams (not to IP fragments). An IP packet to which >> AH or ESP has been applied may itself be fragmented by routers en >> route, and such fragments MUST be reassembled prior to IPsec >> processing at a receiver. In tunnel mode, AH or ESP is applied to an >> IP packet, the payload of which may be a fragmented IP packet. For >> example, a security gateway, "bump-in-the-stack" (BITS), or "bump- >> in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to >> such fragments. Note that BITS or BITW implementations are examples >> of where a host IPsec implementation might receive fragments to which >> tunnel mode is to be applied. However, if transport mode is to be >> applied, then these implementations MUST reassemble the fragments >> prior to applying IPsec. >> > >I confess I am slightly confused: I thought I was saying precisely >what the highlighted text says. That is, when I said: > >> In transport mode, you can only encrypt unfragmented packets, and >>so you must reassemble (or drop) if you get fragments. > >I meant that "if transport mode is applied, then you must reassemble >the fragments prior to applying IPSec". This would appear to be >precisely what the RFC says, except that the RFC specifies it only >for "these implementations" (by which the RFC doesn't really mean >this restriction is limited only to BITS and BITW implementations), >and that I added the proviso that dropping it was possible, mostly >for completeness. > >Just out of curiosity, what did you think I meant? You're not the >only one who raised a question, and so I'd like to know how I was >unclear. > Whoops; I overlooked that part of your comment. We are in agreement here. I would like to push in the direction of not having to accept fragments at a BITW/BITS or SG, using ICMP PMUT message to push back at hosts, so that we could avoid the need to reassemble in any mode (tunnel or transport) and so that one can always apply full selector sets to traffic, not having to worry about the unavailability of releveant fields due to fragmentation. Steve --============_-1196494464==_ma============ Content-Type: text/html; charset="us-ascii" Re: Problem about reassembly and fragmentation
At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote:
At 11:44 AM 3/8/2002, Stephen Kent wrote:
At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote:

Obnit: you can encrypt fragments in tunnel mode.  In transport mode,
you can only encrypt unfragmented packets, and so you must reassemble
(or drop) if you get fragments.  And yes, there are IPSec
implementations where you could possibly see fragments that need to be
encrypted using transport mode.

RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name.  In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP?

The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point.  The BITW itself doesn't have an IP address, and so it borrows the end point's.  To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec.  And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above...
Steve

Scott,

Note the following from 2401 (Appendix B), with my application of bold text:

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an

   IPsec implementation. Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an

   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to

   such fragments. Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which

   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.


I confess I am slightly confused: I thought I was saying precisely what the highlighted text says.  That is, when I said:

> In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments.

I meant that "if transport mode is applied, then you must reassemble the fragments prior to applying IPSec".  This would appear to be precisely what the RFC says, except that the RFC specifies it only for "these implementations" (by which the RFC doesn't really mean this restriction is limited only to BITS and BITW implementations), and that I added the proviso that dropping it was possible, mostly for completeness.
Just out of curiosity, what did you think I meant?  You're not the only one who raised a question, and so I'd like to know how I was unclear.

Whoops; I overlooked that part of your comment. We are in agreement here.

I would like to push in the direction of not having to accept fragments at a BITW/BITS or SG, using ICMP PMUT message to push back at hosts, so that we could avoid the need to reassemble in any mode (tunnel or transport) and so that one can always apply full selector sets to traffic, not having to worry about the unavailability of releveant fields due to fragmentation.

Steve
--============_-1196494464==_ma============-- From owner-ipsec@lists.tislabs.com Fri Mar 8 16:19:01 2002 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 g290J1813003; Fri, 8 Mar 2002 16:19:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13133 Fri, 8 Mar 2002 18:30:54 -0500 (EST) Date: Fri, 8 Mar 2002 15:41:13 -0800 (PST) From: Srinivasa Addepalli To: Derek Atkins cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This seems good to me. Initially, I was thinking of using new port only for ESP. But that has problem of initiating the keep alive from the initiator (upon quick mode is completed) so that NAT session is created for new port in the NAT box. Source port field of UDP carrying quick mode and ESP packets should be same as source port used by phase1 exchange. If that is the case, I don't see any problem whether it is site-to-site connectivity or telecommuter-to-site connectivity. Srini On 6 Mar 2002, Derek Atkins wrote: > Note that you need to keep both the IKE and 'ESPoUDP' connections > alive. If you move 'ESPoUDP' to a different port without moving > the IKE session, you now have two ports that you need to keep open. > > You need to keep IKE open in order to allow notify and rekey messages > through. > > The suggestion has been made to move to keep IKE phase-1 as-is but if > NAT is detected to move both IKE-phase-2 and ESPoUDP to a new port and > reverse the sense of the port, such that ESP traffic requires no extra > overhead (beyond the UDP header) and IKE traffic requires a four-byte > overhead to indicate its IKE. > > Personally I like this idea; it seems to be the best of both worlds. > You negotiate in IKE as normal, detect the presense of NAT as defined > by the NAT-D payloads, and then 'move' the IKE/ESP session to a new > port for ESPoUDP encapsulation. > > -derek > > Srinivasa Addepalli writes: > > > IKE still can use port 500. I am suggesting that ESP/AH use some > > other port xxxx as suggested in 5.2 section of > > draft-ietf-udp-encaps-01.txt. > > > > This will reduce the packet overhead for ESP packets to 8 bytes > > and it works with NAT boxes which already implemented ESP/IKE > > passthrough. > > > > Regards > > Srini > > > > -- > > Srinivasa Rao Addepalli > > Intoto Inc. > > 3160, De La Cruz Blvd #100 > > Santa Clara, CA > > USA > > Ph: 408-844-0480 x317 > > > > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Fri Mar 8 16:46:38 2002 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 g290kb813451; Fri, 8 Mar 2002 16:46:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13425 Fri, 8 Mar 2002 19:07:21 -0500 (EST) Date: Fri, 8 Mar 2002 16:18:53 -0800 (PST) From: Jussi Kukkonen X-X-Sender: kukkonen@dhcp-pool38.sfo.us.ssh.com To: Stephen Kent cc: "ipsec@lists.tislabs.com" Subject: Re: Problem about reassembly and fragmentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 8 Mar 2002, Stephen Kent wrote: > I would like to push in the direction of not having to accept > fragments at a BITW/BITS or SG, using ICMP PMUT message to push back > at hosts, so that we could avoid the need to reassemble in any mode > (tunnel or transport) and so that one can always apply full selector > sets to traffic, not having to worry about the unavailability of > releveant fields due to fragmentation. What is the intented behavior of this IPsec stack when some app sends large (>path mtu) UDP datagrams? How do you avoid fragments? Jussi Kukkonen SSH Communications Security From owner-ipsec@lists.tislabs.com Fri Mar 8 18:17:35 2002 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 g292HY815281; Fri, 8 Mar 2002 18:17:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14188 Fri, 8 Mar 2002 20:36:52 -0500 (EST) Date: Fri, 8 Mar 2002 17:47:15 -0800 (PST) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Derek Atkins cc: Michael Thomas , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 8 Mar 2002, Derek Atkins wrote: > Michael Thomas writes: > > > Huh? The certs are only there for identity. If I > > want to have two different SA's so I get differential > > queuing treatment, there's nothing that says that I > > need two different identities. I just change the > > traffic selectors. This isn't any different than > > RSVP flow selectors and queuing treatment. > > No, in reality the certs are there for authorization. It's just that > people don'e understand the concept of capabilities, so we have this > ad-hoc "identity" cert and map it via some local lookup method to a > set of capabilities. > > You receive an "identity" cert, validate the cert, validate that the > message is authentic using this cert, and then you lookup the > capabilities of this "identity" to validate the authorization for the > requested operation. > > In terms of different flow selectors, it is perfectly reasonable to > say that each flow requires its own certificate specifying the > capability of that particular flow. I finally realized what bothers me about this, which I think is also what angelos was talking about: What you're really saying is that IKE is now essentially doing admission control for QoS based on a cert (attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor IKE's job to perform admission control for QoS. I'm assuming that some other layer already did this (does RSVP do this? Sorry. I don't know much about QoS), and that IKE merely negotiates the tunnel for the new QoS traffic. if it wasn't allowed, the other end will drop the packet, or the local stack (if not hacked) will drop the packet. I think this is especially true in the SGW case. IKE merely needs to be able to negotiate the new SA for this new QoS level, and I would assume (have assumed) that this would happen under the same ID/cert as before. No difference there. Of course this assumes some additional capabilities in Ipsec-selectors, i.e. to be able to include QoS levels in the SA negotiation, but that may be needed whether we use the same or a different cert. If you DID want to do it via a new cert, would that cert have to be built on the fly?! That sounds really rather bad. Voice traffic doesn't need added latency to build and sign a completely new cert. Maybe this is how attribute certs work. I'm willing to listen :) If the information about what you (as identified by your cert) is static, why not build it into the same cert (i.e. jan is allowed low priority and high priority)? You save the information and verify it against the next phase 2. No need to redo a phase 1 (the cert is the same, the authorization is the same). > Similarly, you could specify an > "identity" that is capable of both flows. > > The problem with using identity for capability verification is that > there is no way of knowing _which_ capability actually applies to any > situation. You have to depend on the user requesting the appropriate > flow characteristics, but unless there is a real-world cost associated > with that choice, what incentive does the user have? > > For example, if I could use my personal cert to specify a normal > connection or a high-QoS connection and the costs to me were the same, > why wouldn't I specify the high-QoS connection all the time? Why indeed? Because presumably your ISP or whoever is at the other end will either disallow it, or charge you more. Is this an IKE issue at all? This is a regular QoS admission control problem. > OTOH, if > there were clearly different certificates for teh two capabilities, > then you could restrict access to the different certs. > You COULD, but I'd argue it's not IKE's job (or JFK's or IKEv2)... jan > Basically, I'm saying that you are both right -- you are just coming > from very different viewpoints. However neither is wrong. > > > Mike > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Mar 8 18:17:35 2002 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 g292HY815280; Fri, 8 Mar 2002 18:17:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14177 Fri, 8 Mar 2002 20:36:06 -0500 (EST) Date: Fri, 8 Mar 2002 17:47:01 -0800 (PST) From: Jan Vilhuber X-Sender: vilhuber@localhost To: "Angelos D. Keromytis" cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203072239.g27Md2Ue005653@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 7 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >Yes. Think about it: If you have load and high priority traffic on the > >same SA, and there are not only reordering (and prioritization) of > >packets as they leave the box, but also when they enter (and are > >processed by) the receiver AND there is prioritization and reordering > >happening IN THE NETWORK (assuming QoS ever becomes more prevalent), > >then chances are the receiver will see a LOT of the higher priority > >packets before he sees any low priority packets. > > > >hence each high priority packet will advance the replay window, until > >finally some low priority packet comes in which is rejected, since the > >replay window has moved too far forward due to the high priority > >packets. > > > >Hence: Separate SA's and replay counters. > > Yes, in that scenario you would need separate SAs. > > However, I would assume that, in the case of multiple traffic streams of > different priorities going over the same IPsec tunnel (*), the sender: > > a) would request for the ESP traffic the same priority level as the highest > priority among the different data streams, and But that would kill QoS. Also, I thought the IPsec specs say to copy the inner Tos bits to the outer header. Now you are saying we copy the inner tos bits and map them to the highest of all streams in our ESP tunnel. > b) would do its own prioritization for packets entering the tunnel > (treating the tunnel as a link on its own) > Not sure I get this. I think you'd do this anyway, but the problem is that high priority packets will traverse the network at large faster than low priority traffic. I don't think it's valid to just put all your ESP packets into the highest QoS level.... > The network and the receiver can do prioritization only if: > 1) they can decrypt the ESP packets (in which case, there's not issue with > the replay window), or > 2) the packets are marked appropriately by the sender > > So the sender has control over QoS in this case. Then again, I'm not a QoS > person. > > (*) I use the term tunnel in a general sense, I don't want to start another > holy war about its use and exact semantics, or transport vs. tunnel mode. > :) > >> --- huge, monolithic protocols are not pleasant to specify, > >> analyze, implement, or debug. On a slightly more philosophical vein, they > >> promote both bloat > > > >What kind of bloat are we talking about? > > Piling up of not-very-necessary features. > Like doing QoS' admission control for it? > >> (see IKEv1) and bad APIs (another source of trouble and > >> embarassments). > > > >Underspecification in a protocol definition leads to bad API's, not a > >comprehensive protocol... > > To begin with, a complex protocol is more likely to be underspecified. And, > complicated protocols lead to complicated APIs (because people feel the need to > exploit all the features offered by the protocol). > > >IOS does, I believe. Not an unprotected notify, of course. > > That hasn't been my experience, with any vendor I've interoperated with (mind > you, *my* implementations are not doing any better). > > >That's because so far there's been much confusion surrounding these > >exchanges. If they were clearly spelled out in their use and semantics > >(note: well defined protocol specification), this wouldn't be nearly > >as confusing. We're finding that it's becoming very important to have > >these informational exchanges and are starting to use them more and > >more. > > As far as I can tell, everyone is simply ignoring them (except for a couple of > easy-to-understand cases); As Andrew said, that's mostly because they were not well understood and ambiguous to deploy. We've learned a lot and can actually now specify better messages and semantics to go with them. Just because the situation is currently bad means it's a bad mechanism. jan > and, the more complicated the protocol, the harder > it is to figure out what the right response is to an error message. Again, > not all notifications are bad, just that they are not as useful as people > think (and that's IMOE). > > Cheers, > -Angelos > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sat Mar 9 09:48:22 2002 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 g29HmL816269; Sat, 9 Mar 2002 09:48:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20701 Sat, 9 Mar 2002 11:44:17 -0500 (EST) Message-Id: <200203091652.g29GqRC12133@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Fri, 08 Mar 2002 17:47:15 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 09 Mar 2002 11:52:26 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: Jan> I finally realized what bothers me about this, which I think is also Jan> what angelos was talking about: What you're really saying is that IKE Jan> is now essentially doing admission control for QoS based on a cert Jan> (attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor Jan> IKE's job to perform admission control for QoS. Jan> I'm assuming that some other layer already did this (does RSVP do Jan> this? Sorry. I don't know much about QoS), and that IKE merely Jan> negotiates the tunnel for the new QoS traffic. if it wasn't allowed, Jan> the other end will drop the packet, or the local stack (if not hacked) Jan> will drop the packet. Yes, I do know a lot about about various QoS systems having spent several years designing hardware to do packet classification. Go read the RFCs. Yes, on a security gateway, the piece of hardware that implements the IPsec SPD will be doing admission control for QoS. There are three reasons for this: 1) the form of the database is identical. 2) the hardware is designed to do both already, and why have multiple pieces of hardware? 3) the alternative is that the QoS people whine about how they can not do QoS once the packets are encrypted and could we please reveal pieces of the packet? QoS flows will be based upon SPI# (which conveniently is 16bits + 16bits at a slightly different offset and looks a lot like TCP or UDP port numbers to hardware). Further, odds are that the customer located QoS-enabled security gateway will simply use RSVP to arrange QoS with the ISPs DiffServ enabled "diffedge" border router. RSVP already has selectors for SPI# and has had them since 1996 or so. As stated clearly by others, you can not sort the same IPsec flow into multiple classes of service. The replay windows get in the way. Any argument that you want to avoid traffic analysis is moot - by putting the packets into different flows you are in fact doing the traffic analysis for the bad guys. It would be nice if all traffic of a given QoS could go into the same tunnel. This is not possible with current IKE because you can not negotiate multiple disjoint sets of selectors there. The requirement is that one is able to negotiate multiple tunnels with different contents. We have that already. You have to negotiate a per-port tunnel for each QoS flow. Fragment issues are moot. QoS people already recognize that if you fragment, you are unlikely to get QoS. Who does this affect? NFSv2 and CIFS (SMB) networking. NFSv3 and NFSv4 should be run over TCP anyway. It is hard to name another protocol that doesn't run over TCP and yet has a problem with big packets. (VoIP packets tend to be rather small. Streaming video may present a problem, but streaming video will never work without QoS, so they will adapt, in my opinion) Any fragments therefore go through the "per-host" or "per-network" "best-effort" tunnel anyway. Jan> Of course this assumes some additional capabilities in Jan> Ipsec-selectors, i.e. to be able to include QoS levels in the SA Jan> negotiation, but that may be needed whether we use the same or a Jan> different cert. Not that I can see. It requires that the QoS level be negotiated, but this is an additional "parameter", rather like an cipher algorithm. About the only time I can see different identities being used is in host (not BITS or BITW) implementations, in which case, there are no fragment or classification problems - you keep the SA# in the PCB. >> For example, if I could use my personal cert to specify a normal >> connection or a high-QoS connection and the costs to me were the same, >> why wouldn't I specify the high-QoS connection all the time? Jan> Why indeed? Because presumably your ISP or whoever is at the other end Jan> will either disallow it, or charge you more. Jan> Is this an IKE issue at all? This is a regular QoS admission control Jan> problem. it is a regularl QoS admission problem. It is between the Security Gateway and the ISPs border router. There will be certificates eventually involved, and they may be the same, but it won't be IKE dealing with them. ] 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 iQCVAwUBPIo9xIqHRg3pndX9AQE4HwP9GRS6ouT1VrPfyXI89ed8kHEENi7kETsG xtlY2ADZX1KJLPL/EXhx0Kdcd9zGs05ywkDOxIJtjDnldKD44bbXtC57QE2VQgoS 9bJS4K+qvhevA1QgH2bogLTnwQCS9QX4g+FYcwByWNXOwvSzQVFSTKMWBQz0WUkB fLijdNV2wq8= =AZSK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Mar 9 14:03:41 2002 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 g29M3e825479; Sat, 9 Mar 2002 14:03:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22449 Sat, 9 Mar 2002 16:12:46 -0500 (EST) Message-ID: From: "Prasad, Rajendra" To: "'Stephen Kent'" , Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: RE: Problem about reassembly and fragmentation Date: Sat, 9 Mar 2002 13:09:19 -0800 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C7AE.ADF05410" 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_01C1C7AE.ADF05410 Content-Type: text/plain; charset="ISO-8859-1" As I have understood, Outermost IP header should not have fragments for encryption or decryption. While Encrypting - In transport mode - NO fragments (if fragmented drop it). In tunnel mode, inner IP header may have fragmentation but outer IP header is not. After encrypting the packet you may do fragmentation. While Decrypting- If the packet is fragmented, it should be reassembled first before decryption. Thanks Rajendra Prasad -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, March 08, 2002 2:49 PM To: Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote: At 11:44 AM 3/8/2002, Stephen Kent wrote: At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote: Obnit: you can encrypt fragments in tunnel mode. In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments. And yes, there are IPSec implementations where you could possibly see fragments that need to be encrypted using transport mode. RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name. In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP? The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point. The BITW itself doesn't have an IP address, and so it borrows the end point's. To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec. And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above... Steve Scott, Note the following from 2401 (Appendix B), with my application of bold text: B.2 Fragmentation If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec. I confess I am slightly confused: I thought I was saying precisely what the highlighted text says. That is, when I said: > In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments. I meant that "if transport mode is applied, then you must reassemble the fragments prior to applying IPSec". This would appear to be precisely what the RFC says, except that the RFC specifies it only for "these implementations" (by which the RFC doesn't really mean this restriction is limited only to BITS and BITW implementations), and that I added the proviso that dropping it was possible, mostly for completeness. Just out of curiosity, what did you think I meant? You're not the only one who raised a question, and so I'd like to know how I was unclear. Whoops; I overlooked that part of your comment. We are in agreement here. I would like to push in the direction of not having to accept fragments at a BITW/BITS or SG, using ICMP PMUT message to push back at hosts, so that we could avoid the need to reassemble in any mode (tunnel or transport) and so that one can always apply full selector sets to traffic, not having to worry about the unavailability of releveant fields due to fragmentation. Steve ------_=_NextPart_001_01C1C7AE.ADF05410 Content-Type: text/html; charset="ISO-8859-1" Re: Problem about reassembly and fragmentation
As I have understood, Outermost IP header should not have fragments for encryption or decryption.
 
While Encrypting - In transport mode - NO fragments (if fragmented drop it). In tunnel mode, inner IP header may have fragmentation but outer IP header is not. After encrypting the packet you may do fragmentation.
 
While Decrypting- If the packet is fragmented, it should be reassembled first before decryption.
 
Thanks
Rajendra Prasad
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, March 08, 2002 2:49 PM
To: Scott Fluhrer
Cc: ipsec@lists.tislabs.com
Subject: Re: Problem about reassembly and fragmentation

At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote:
At 11:44 AM 3/8/2002, Stephen Kent wrote:
At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote:

Obnit: you can encrypt fragments in tunnel mode.  In transport mode,
you can only encrypt unfragmented packets, and so you must reassemble
(or drop) if you get fragments.  And yes, there are IPSec
implementations where you could possibly see fragments that need to be
encrypted using transport mode.

RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name.  In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP?

The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point.  The BITW itself doesn't have an IP address, and so it borrows the end point's.  To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec.  And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above...
Steve

Scott,

Note the following from 2401 (Appendix B), with my application of bold text:

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an

   IPsec implementation. Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an

   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to

   such fragments. Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which

   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.


I confess I am slightly confused: I thought I was saying precisely what the highlighted text says.  That is, when I said:

> In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments.

I meant that "if transport mode is applied, then you must reassemble the fragments prior to applying IPSec".  This would appear to be precisely what the RFC says, except that the RFC specifies it only for "these implementations" (by which the RFC doesn't really mean this restriction is limited only to BITS and BITW implementations), and that I added the proviso that dropping it was possible, mostly for completeness.
Just out of curiosity, what did you think I meant?  You're not the only one who raised a question, and so I'd like to know how I was unclear.

Whoops; I overlooked that part of your comment. We are in agreement here.

I would like to push in the direction of not having to accept fragments at a BITW/BITS or SG, using ICMP PMUT message to push back at hosts, so that we could avoid the need to reassemble in any mode (tunnel or transport) and so that one can always apply full selector sets to traffic, not having to worry about the unavailability of releveant fields due to fragmentation.

Steve
------_=_NextPart_001_01C1C7AE.ADF05410-- From owner-ipsec@lists.tislabs.com Sun Mar 10 12:16:36 2002 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 g2AKGZ827307; Sun, 10 Mar 2002 12:16:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29488 Sun, 10 Mar 2002 14:40:24 -0500 (EST) Date: Sun, 10 Mar 2002 11:51:28 -0800 (PST) From: Jan Vilhuber To: Michael Richardson cc: Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203091652.g29GqRC12133@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 Sat, 9 Mar 2002, Michael Richardson wrote: > | Pretty Good Privacy(tm) Version 6.5.8 > | (c) 1999 Network Associates Inc. > | Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc. > | Export of this software may be restricted by the U.S. government. > | > | File is signed. signature not checked. > | Signature made 2002/03/09 16:52 GMT > | key does not meet validity threshold. > | > | WARNING: Because this public key is not certified with a trusted > | signature, it is not known with high confidence that this public key > | actually belongs to: "(KeyID: 0xE99DD5FD)". > > > >>>>> "Jan" == Jan Vilhuber writes: > Jan> I finally realized what bothers me about this, which I think is also > Jan> what angelos was talking about: What you're really saying is that IKE > Jan> is now essentially doing admission control for QoS based on a cert > Jan> (attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor > Jan> IKE's job to perform admission control for QoS. > > Jan> I'm assuming that some other layer already did this (does RSVP do > Jan> this? Sorry. I don't know much about QoS), and that IKE merely > Jan> negotiates the tunnel for the new QoS traffic. if it wasn't allowed, > Jan> the other end will drop the packet, or the local stack (if not hacked) > Jan> will drop the packet. > > Yes, I do know a lot about about various QoS systems having spent several > years designing hardware to do packet classification. Go read the RFCs. > Gah! :) > Yes, on a security gateway, the piece of hardware that implements the IPsec > SPD will be doing admission control for QoS. Just to clarify: I don't care if QoS and IPsec use the same database and possibly interact, but I DO have a problem with basing decision on whether to allow someone a higher level of QoS or not on IKE negotiation. *IF* some external mechanism determined that this user/flow is allowed a higher level of QoS, THEN IKE should negotiate this. IKE should not be the mechanism to answer the question "Is this flow allowed at a higher level of QoS". That question belongs into a different protocol. Not sure if this is clear, but it essentially tells me that you do NOT need separate certs for different levels of QoS, if the user/end-station of the flows are the same. > There are three reasons for this: > 1) the form of the database is identical. > > 2) the hardware is designed to do both already, and why have > multiple pieces of hardware? > > 3) the alternative is that the QoS people whine about how they can > not do QoS once the packets are encrypted and could we please > reveal pieces of the packet? > > QoS flows will be based upon SPI# (which conveniently is 16bits + 16bits at > a slightly different offset and looks a lot like TCP or UDP port numbers to > hardware). > Further, odds are that the customer located QoS-enabled security gateway > will simply use RSVP to arrange QoS with the ISPs DiffServ enabled "diffedge" > border router. RSVP already has selectors for SPI# and has had them since > 1996 or so. > > As stated clearly by others, you can not sort the same IPsec flow into > multiple classes of service. The replay windows get in the way. Any argument > that you want to avoid traffic analysis is moot - by putting the packets into > different flows you are in fact doing the traffic analysis for the bad guys. > > It would be nice if all traffic of a given QoS could go into the same > tunnel. This is not possible with current IKE because you can not negotiate > multiple disjoint sets of selectors there. > > The requirement is that one is able to negotiate multiple tunnels with > different contents. We have that already. You have to negotiate a per-port > tunnel for each QoS flow. Can you ever do different levels of Qos for the same 5-tuple? Would this makse sense? > Fragment issues are moot. QoS people already recognize that if you > fragment, you are unlikely to get QoS. > Who does this affect? NFSv2 and CIFS (SMB) networking. NFSv3 and NFSv4 > should be run over TCP anyway. It is hard to name another protocol that > doesn't run over TCP and yet has a problem with big packets. (VoIP packets > tend to be rather small. Streaming video may present a problem, but streaming > video will never work without QoS, so they will adapt, in my opinion) > > Any fragments therefore go through the "per-host" or "per-network" > "best-effort" tunnel anyway. > > Jan> Of course this assumes some additional capabilities in > Jan> Ipsec-selectors, i.e. to be able to include QoS levels in the SA > Jan> negotiation, but that may be needed whether we use the same or a > Jan> different cert. > > Not that I can see. It requires that the QoS level be negotiated, but this > is an additional "parameter", rather like an cipher algorithm. > That's what I meant. I'm curious if it's needed, though (see previous question). Can a flow (5 tuple) exist in two different levels of QoS? Or would the two flows exist on different ports? > About the only time I can see different identities being used is in host > (not BITS or BITW) implementations, in which case, there are no fragment or > classification problems - you keep the SA# in the PCB. > > >> For example, if I could use my personal cert to specify a normal > >> connection or a high-QoS connection and the costs to me were the same, > >> why wouldn't I specify the high-QoS connection all the time? > > Jan> Why indeed? Because presumably your ISP or whoever is at the other end > Jan> will either disallow it, or charge you more. > > Jan> Is this an IKE issue at all? This is a regular QoS admission control > Jan> problem. > > it is a regularl QoS admission problem. It is between the Security Gateway > and the ISPs border router. There will be certificates eventually involved, > and they may be the same, but it won't be IKE dealing with them. > That's sort of my assertion. Something else did the check whether you (the guy with the certificate) are allowed QoS for this traffic at level X. IKE doesn't (and shouldn't IMHO) answer this question, but should negotiate the tunnel for the different QoS level if instructed to do so (by ipsec or rsvp or whatever...). Now what do you think of Angelos' idea of simply putting the max level of Qos of all your flows onto the ESP tunnel, thereby effectively elevating all low-priority traffic to high priority traffic as far as the outer IP header is concerned? Seems that is counter to what QoS is supposed to do, but I'd like to hear some QoS-savvy opinions on this. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sun Mar 10 12:16:40 2002 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 g2AKGd827315; Sun, 10 Mar 2002 12:16:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29373 Sun, 10 Mar 2002 14:19:00 -0500 (EST) Date: Sun, 10 Mar 2002 11:29:58 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203090341.g293f9Ue000556@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 8 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan Vilhuber wri > tes: > >> > >> a) would request for the ESP traffic the same priority level as the highest > >> priority among the different data streams, and > > > >But that would kill QoS. > > > >Also, I thought the IPsec specs say to copy the inner Tos bits to the > >outer header. Now you are saying we copy the inner tos bits and map > >them to the highest of all streams in our ESP tunnel. > > Yes -- but you also need to do (b). > > >Not sure I get this. I think you'd do this anyway, but the problem is > >that high priority packets will traverse the network at large faster > >than low priority traffic. > > > >I don't think it's valid to just put all your ESP packets into the > >highest QoS level.... > > Sure it is. I'd prefer to hear from QoS people on this. I suspect this is NOT kosher. It would go against the whole point of QoS, i.e. getting high priority traffic across your network faster then low priority traffic. If you cheat and make ALL your traffic into high priority traffic, you might as well not do QoS at all. > What (a) and (b) together do is make sure that your high > priority traffic gets there as you'd like it to, and then you do admission > control at the sender using the same algorithm as the network would use. > You basically treat the ESP tunnel as a single-hop link, and pretend that > the sender is the network. The same trick is sometimes used in modeling > QoS, as I understand it. > Modelling and the real world are very different. You're hiding the QoS from the network here, and that's not valid, IMHO. > >> Piling up of not-very-necessary features. > > > >Like doing QoS' admission control for it? > > It wouldn't be IKE (or IKEv2, or JFK) doing that It is, if you say you need different certs for different levels of Qos.. > -- probably not even > of the IPsec stack itself; in OpenBSD, I'd probably do it via altq. > > I was refering to things like dealing with NATs, legacy authentication, > and dead peer detection. Not that these are useless: but the issues can > be addressed just as well by other protocols, without complicating a > protocol that is already large and complicated (rough linecount of > OpenBSD's isakmpd is 36K lines, excluding crypto libraries), and which > is supposed to be at the core of our security architecture. > > >As Andrew said, that's mostly because they were not well understood > >and ambiguous to deploy. We've learned a lot and can actually now > >specify better messages and semantics to go with them. > > > >Just because the situation is currently bad means it's a bad mechanism. > > I remain doubtful for anything other than the potential debugging > uses of such messages. Error handling has been problematic in most > protocols (and applications, for that matter) --- there's no reason > for unqualified optimism in this case. There's also no reason to throw it out, just because IKEv1 got it wrong. jan > Cheers, > -Angelos > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sun Mar 10 12:55:46 2002 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 g2AKtj827881; Sun, 10 Mar 2002 12:55:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29755 Sun, 10 Mar 2002 15:22:01 -0500 (EST) Date: Sun, 10 Mar 2002 12:33:03 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 10 Mar 2002, Jan Vilhuber wrote: > On Fri, 8 Mar 2002, Angelos D. Keromytis wrote: > > > > > In message , Jan Vilhuber wri > > tes: > > >> > > >> a) would request for the ESP traffic the same priority level as the highest > > >> priority among the different data streams, and > > > > > >But that would kill QoS. > > > > > >Also, I thought the IPsec specs say to copy the inner Tos bits to the > > >outer header. Now you are saying we copy the inner tos bits and map > > >them to the highest of all streams in our ESP tunnel. > > > > Yes -- but you also need to do (b). > > Oh.. I think I get it (sort of): You're saying that *IF* you decided that you *want* to (not SHOULD!) send all flows with different QoS through the same tunnel (by some definition of tunnel ;), then you COULD do it the way you describe. That is a true statement. The caveats are, of course, that chances are this won't be terribly useful, because a) like I mentioned, you're hiding all the internal Tos-bits from the network you're traversing, so your performance will be suboptimal (since you're lifting all low-priority traffic up to high-priority for the 'duration' of the tunnel). The whole reason to do QoS is so that high priority traffic gets preferential treatment. I thought there was an implicit assumption of "preferential treatment as far as possible", i.e. in as much of the network as possible. You'd loose a large chunk of the performance gain that QoS potentially offers you, if you elevate low priority traffic to high-priority traffic for the span of the tunnel. b) the way to prevent everyone from simply using the highest level of QoS (with or without IPsec) is to charge for it. If you pay per level of QoS, (up)lifting all your low-priority bulk traffic to high priority traffic will cost you more, and I bet customers won't find that terribly palatable. Your crypto endpoints MAY be the same place doing admission control, but they may also NOT be (like my IPsec box here at home; if all my esp traffic went at the max-qos over all flows, assuming my ISP did Qos and charged for it (which it doesn't), I'd pay up the wazoo). In theory, you could use the mechanism you describe. And maybe some will, but I bet it won't be wide spread. I also wouldn't want this WG to recommend this approach. I would argue that we don't have to worry about this case, as it doesn't have any implications to IKE (or son of IKE) at all. This is purely a matter of IPsec, not the key exchange. I claim we need to realize that the case where you need multiple SA's, one for each level of QoS (per flow) is going to be MUCH more prevalent (and a single ID or cert is used, since the endpoints are still the same two endpoints), and therefore we need to worry about it, which to ME says: 2 phases (YCMV(*)). BTW: 2401 states "If Inner Hdr is IPv4 (Protocol = 4), copy the TOS.". So while technically you COULD make the outside TOS bits anything you want, this seems like it would go against 2401. Maybe other areas of this 2401 (or other rfc's?) relax the implied rule here? jan (*) Your Conclusions May Vary ;) > > > >> Piling up of not-very-necessary features. > > > > > >Like doing QoS' admission control for it? > > > > It wouldn't be IKE (or IKEv2, or JFK) doing that > > It is, if you say you need different certs for different levels of > Qos.. > > > > -- probably not even > > of the IPsec stack itself; in OpenBSD, I'd probably do it via altq. > > > > I was refering to things like dealing with NATs, legacy authentication, > > and dead peer detection. Not that these are useless: but the issues can > > be addressed just as well by other protocols, without complicating a > > protocol that is already large and complicated (rough linecount of > > OpenBSD's isakmpd is 36K lines, excluding crypto libraries), and which > > is supposed to be at the core of our security architecture. > > > > >As Andrew said, that's mostly because they were not well understood > > >and ambiguous to deploy. We've learned a lot and can actually now > > >specify better messages and semantics to go with them. > > > > > >Just because the situation is currently bad means it's a bad mechanism. > > > > > I remain doubtful for anything other than the potential debugging > > uses of such messages. Error handling has been problematic in most > > protocols (and applications, for that matter) --- there's no reason > > for unqualified optimism in this case. > > There's also no reason to throw it out, just because IKEv1 got it > wrong. > > jan > > > > Cheers, > > -Angelos > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sun Mar 10 12:57:24 2002 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 g2AKvO827917; Sun, 10 Mar 2002 12:57:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29774 Sun, 10 Mar 2002 15:25:01 -0500 (EST) Message-Id: <200203102031.g2AKVZD29880@marajade.sandelman.ottawa.on.ca> To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Sun, 10 Mar 2002 11:51:28 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Mar 2002 15:31:35 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: >> The requirement is that one is able to negotiate multiple tunnels with >> different contents. We have that already. You have to negotiate a >> per-port tunnel for each QoS flow. Jan> Can you ever do different levels of Qos for the same 5-tuple? Would Jan> this makse sense? Sure, of course you can if you add a tuple :-) So you'd be doing QoS based upon two different 6-tuples. Jan> That's sort of my assertion. Something else did the check whether Jan> you (the guy with the certificate) are allowed QoS for this traffic Jan> at level X. IKE doesn't (and shouldn't IMHO) answer this question, Jan> but should negotiate the tunnel for the different QoS level if Jan> instructed to do so (by ipsec or rsvp or whatever...). if you think about encryption as a "quality" of "service", then the SPD is going to say something like: for traffic from v.x.y.z/mask to a.b.c.d/mask on tcp port 25 do ESP-AES-SHA2 with "Telnet"-EF-QoS policy. IKE will have to inform the other end that it is doing this so that the reverse flow can have appropriate QoS applied. (Since the QOS will be based upon proto,dst,SPI# not TCP ports). Jan> Now what do you think of Angelos' idea of simply putting the max Jan> level of Qos of all your flows onto the ESP tunnel, thereby Jan> effectively elevating all low-priority traffic to high priority Jan> traffic as far as the outer IP header is concerned? Seems that is Jan> counter to what QoS is supposed to do, but I'd like to hear some Jan> QoS-savvy opinions on this. You can not have multiple levels of QoS for the same (proto,dst,SPI#). There is simply no point. If you want to do this, then you just negotiate one level of QoS. The cryptographic reason to aggregate traffic is to defeat traffic analysis. Any change in QoS setting at all reveals what is going on. ] 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 iQCVAwUBPIvCpYqHRg3pndX9AQGziQP/fIheE9SteTRA6nppg9TnZ/jD4GStN2UP JzSGfL4FK+J6To3BR9Io21ftrt4bsewZnyc3mEV6UClpTegGGftW/JKUjeaUDLbf iaL+BCqEU6OnTqyfzn7F0ep6Tj9HvYrbR6tcMB4xkXFTB3EH+iYSSxaGw5pm8whn oguTsUyLvjs= =bSBm -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Mar 10 23:05:51 2002 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 g2B75o816473; Sun, 10 Mar 2002 23:05:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02936 Mon, 11 Mar 2002 01:12:47 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com cc: byfraser@cisco.com Reply-to: byfraser@cisco.com, tytso@mit.edu Subject: Call for agenda items Phone: (781) 391-3464 Message-Id: Date: Sun, 10 Mar 2002 23:14:08 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Minneapolis IETF meeting is fast approaching us, so this is a call for agenda items for the upcoming meeting. Please send requests for meeting time to both Barbara and I. We will assume that document editors who updated I-D's for this meeting will want time to talk about their drafts, but a quick note indicating how much time you think will be needed, and what sort of issues you'd like to discuss would be greatly appreciated. - Ted P.S. Due to a family emergency, I may not be able responding quickly to e-mails sent to me during this week, and in the worse case, may be somewhat late arriving at Minneapolis. From owner-ipsec@lists.tislabs.com Mon Mar 11 05:47:32 2002 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 g2BDlV800139; Mon, 11 Mar 2002 05:47:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05105 Mon, 11 Mar 2002 08:00:53 -0500 (EST) Message-Id: <200203082134.g28LYPUe016102@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Kent Cc: Jan Vilhuber , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Fri, 08 Mar 2002 12:06:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 16:34:25 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, yes -- I was simply pointing out that one can *also* cache the result, to avoid re-verification. -Angelos In message , Stephen Kent writes: > > > >> >>You don't cache the certificates, you cache the result of the verification of >>the certificates. If you received the same set of certificates as an hour ago >>(when you established the SA last), and you verified all the signatures then, >>you don't need to re-check the signatures. You need to verify the >>RSA signature >>on the message itself. > >Angelos, > >In many cases, caching validated certs is appropriate, because one >may have an opportunity to reuse CA certs that were part of the cert >path. > >Steve From owner-ipsec@lists.tislabs.com Mon Mar 11 05:47:37 2002 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 g2BDla800162; Mon, 11 Mar 2002 05:47:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05138 Mon, 11 Mar 2002 08:05:52 -0500 (EST) X-Originating-IP: [66.108.204.23] From: "admin" To: Subject: HELP!!! IPSEC Date: Sun, 10 Mar 2002 03:34:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C1C7E4.6AF38660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Mar 2002 08:34:10.0554 (UTC) FILETIME=[59D875A0:01C1C80E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C1C7E4.6AF38660 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, can you please please explain me what the master and session keys = are? I read and read and read again but still not quite understand much. = I assume that i don't have any idea what master and session keys are and = what the difference is between them? Please Help!!!! ------=_NextPart_000_0046_01C1C7E4.6AF38660 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi, can you please please explain me = what the=20 master and session keys are? I read and read and read again but still = not quite=20 understand much. I assume that i don't have any idea what master and = session=20 keys are and what the difference is between them? Please=20 Help!!!! ------=_NextPart_000_0046_01C1C7E4.6AF38660-- From owner-ipsec@lists.tislabs.com Mon Mar 11 05:47:37 2002 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 g2BDla800163; Mon, 11 Mar 2002 05:47:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05116 Mon, 11 Mar 2002 08:01:53 -0500 (EST) Message-Id: <200203090341.g293f9Ue000556@nyarlathotep.keromytis.org> To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Fri, 08 Mar 2002 17:47:01 PST." Date: Fri, 08 Mar 2002 22:41:09 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber wri tes: >> >> a) would request for the ESP traffic the same priority level as the highest >> priority among the different data streams, and > >But that would kill QoS. > >Also, I thought the IPsec specs say to copy the inner Tos bits to the >outer header. Now you are saying we copy the inner tos bits and map >them to the highest of all streams in our ESP tunnel. Yes -- but you also need to do (b). >Not sure I get this. I think you'd do this anyway, but the problem is >that high priority packets will traverse the network at large faster >than low priority traffic. > >I don't think it's valid to just put all your ESP packets into the >highest QoS level.... Sure it is. What (a) and (b) together do is make sure that your high priority traffic gets there as you'd like it to, and then you do admission control at the sender using the same algorithm as the network would use. You basically treat the ESP tunnel as a single-hop link, and pretend that the sender is the network. The same trick is sometimes used in modeling QoS, as I understand it. >> Piling up of not-very-necessary features. > >Like doing QoS' admission control for it? It wouldn't be IKE (or IKEv2, or JFK) doing that -- probably not even of the IPsec stack itself; in OpenBSD, I'd probably do it via altq. I was refering to things like dealing with NATs, legacy authentication, and dead peer detection. Not that these are useless: but the issues can be addressed just as well by other protocols, without complicating a protocol that is already large and complicated (rough linecount of OpenBSD's isakmpd is 36K lines, excluding crypto libraries), and which is supposed to be at the core of our security architecture. >As Andrew said, that's mostly because they were not well understood >and ambiguous to deploy. We've learned a lot and can actually now >specify better messages and semantics to go with them. > >Just because the situation is currently bad means it's a bad mechanism. I remain doubtful for anything other than the potential debugging uses of such messages. Error handling has been problematic in most protocols (and applications, for that matter) --- there's no reason for unqualified optimism in this case. Cheers, -Angelos From owner-ipsec@lists.tislabs.com Mon Mar 11 06:21:25 2002 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 g2BELO801959; Mon, 11 Mar 2002 06:21:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05411 Mon, 11 Mar 2002 08:47:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203082134.g28LYPUe016102@nyarlathotep.keromytis.org> References: <200203082134.g28LYPUe016102@nyarlathotep.keromytis.org> Date: Mon, 11 Mar 2002 08:53:30 -0500 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Choosing between IKEv2 and JFK Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:34 PM -0500 3/8/02, Angelos D. Keromytis wrote: >Steve, yes -- I was simply pointing out that one can *also* cache the >result, to avoid re-verification. >-Angelos OK, the "also" past was not evident to me, hence my message. We're in agreement. Steve From owner-ipsec@lists.tislabs.com Mon Mar 11 06:41:15 2002 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 g2BEfE804648; Mon, 11 Mar 2002 06:41:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05494 Mon, 11 Mar 2002 09:07:01 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 11 Mar 2002 09:11:17 -0500 To: "Prasad, Rajendra" From: Stephen Kent Subject: RE: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1196266122==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1196266122==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:09 PM -0800 3/9/02, Prasad, Rajendra wrote: >As I have understood, Outermost IP header should not have fragments >for encryption or decryption. > >While Encrypting - In transport mode - NO fragments (if fragmented >drop it). In tunnel mode, inner IP header may have fragmentation but >outer IP header is not. After encrypting the packet you may do >fragmentation. > >While Decrypting- If the packet is fragmented, it should be >reassembled first before decryption. Slightly odd wording here, but mostly correct. yes, in transport mode, the packets received by an IPsec implementation for outbound processing ought not be fragments, otherwise the implementation has to assemble them before applying IPsec. In tunnel mode, the IPsec implementation may receive fragments for outbound processing. In either case, the addition of the IPsec headers may require exceed the MTU for the outbound interface, so the "outer" header (the only header for transport mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU and thus an ability to avoid the need to fragment, and perhaps avoid the need to perform reassembly at the receiver, to remove this means of DoS attacks against receivers. Steve --============_-1196266122==_ma============ Content-Type: text/html; charset="us-ascii" RE: Problem about reassembly and fragmentation
At 1:09 PM -0800 3/9/02, Prasad, Rajendra wrote:
As I have understood, Outermost IP header should not have fragments for encryption or decryption.
 
While Encrypting - In transport mode - NO fragments (if fragmented drop it). In tunnel mode, inner IP header may have fragmentation but outer IP header is not. After encrypting the packet you may do fragmentation.
 
While Decrypting- If the packet is fragmented, it should be reassembled first before decryption.

Slightly odd wording here, but mostly correct.  yes, in transport mode, the packets received by an IPsec implementation for outbound processing ought not be fragments, otherwise the implementation has to assemble them before applying IPsec. In tunnel mode, the IPsec implementation may receive fragments for outbound processing.  In either case, the addition of the IPsec headers may require exceed the MTU for the outbound interface, so the "outer" header (the only header for transport mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU and thus an ability to avoid the need to fragment, and perhaps avoid the need to perform reassembly at the receiver, to remove this means of DoS attacks against receivers.

Steve
--============_-1196266122==_ma============-- From owner-ipsec@lists.tislabs.com Mon Mar 11 08:20:35 2002 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 g2BGKZ813378; Mon, 11 Mar 2002 08:20:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05887 Mon, 11 Mar 2002 10:35:43 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15500.53577.189183.312034@thomasm-u1.cisco.com> Date: Mon, 11 Mar 2002 07:46:17 -0800 (PST) To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203072239.g27Md2Ue005653@nyarlathotep.keromytis.org> References: <200203072239.g27Md2Ue005653@nyarlathotep.keromytis.org> 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 Angelos D. Keromytis writes: > > In message , Jan > Vilhuber writes: > > > >Yes. Think about it: If you have load and high priority traffic on the > >same SA, and there are not only reordering (and prioritization) of > >packets as they leave the box, but also when they enter (and are > >processed by) the receiver AND there is prioritization and reordering > >happening IN THE NETWORK (assuming QoS ever becomes more prevalent), > >then chances are the receiver will see a LOT of the higher priority > >packets before he sees any low priority packets. > > > >hence each high priority packet will advance the replay window, until > >finally some low priority packet comes in which is rejected, since the > >replay window has moved too far forward due to the high priority > >packets. > > > >Hence: Separate SA's and replay counters. > > Yes, in that scenario you would need separate SAs. > > However, I would assume that, in the case of multiple traffic streams of > different priorities going over the same IPsec tunnel (*), the sender: > > a) would request for the ESP traffic the same priority level as the highest > priority among the different data streams, and > b) would do its own prioritization for packets entering the tunnel > (treating the tunnel as a link on its own) Would that it were so simple. QoS is not just about strict prioritization. Queuing treatment certainly cares about which packet goes out first, but I don't think you can map, say, an EF per hop behavior into an AF class. In other words, there are multiple dimensions in jitter, loss characteristics, etc, which would give unsatisfactory results if you tried to do that. This is completely aside from the fact it might be extremely wasteful to "upgrade" your least common denominator traffic -- best effort typically -- to your traffic which has tighter jitter/loss characteristics. Indeed, the percentage of EF traffic which can be safely placed on a link is usually less than 20%. Not very good link utilization if that's your "highest" priority. Also: at some level, there is nothing which prevents somebody from creating a SPD entry which does this regardless of whether you think this is useful. I don't think it's arguable that authentication amortization is useful were somebody to do such a thing. Since this is just one data point in a list of reasons why amortization is a Good Thing, it really needs to be weighed as part of that package. My feeling is that DPD, rekeying, etc are pretty compelling reasons in and of themselves. Mike From owner-ipsec@lists.tislabs.com Mon Mar 11 08:34:15 2002 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 g2BGYE814001; Mon, 11 Mar 2002 08:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06006 Mon, 11 Mar 2002 10:56:50 -0500 (EST) Message-Id: <200203111556.AEA17611@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 11 Mar 2002 08:02:43 -0800 To: Stephen Kent , "Prasad, Rajendra" From: Scott Fluhrer Subject: RE: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:11 AM 3/11/02 , Stephen Kent wrote: > > [I]n transport mode, the packets received by an IPsec implementation for > outbound processing ought not be fragments, otherwise the implementation has > to assemble them before applying IPsec. In tunnel mode, the IPsec > implementation may receive fragments for outbound processing. In either > case, the addition of the IPsec headers may require exceed the MTU for the > outbound interface, so the "outer" header (the only header for transport > mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU > and thus an ability to avoid the need to fragment, and perhaps avoid the need > to perform reassembly at the receiver, to remove this means of DoS attacks > against receivers. While I appreciate your trying to allow a security gateway to avoid fragmentation, I doubt that it will always be practical in IPv4. I have seen networks where either: - The end application is too stupid to understand PMTU - There's a firewall between the security gateway and the end system which drops all ICMP messages In either of these cases, PMTU doesn't work. And hence, we're either going to stop supporting those legacy networks, or we're just going to allow security gateways to fragment anyways. -- scott From owner-ipsec@lists.tislabs.com Mon Mar 11 08:57:09 2002 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 g2BGv8815201; Mon, 11 Mar 2002 08:57:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06160 Mon, 11 Mar 2002 11:21:23 -0500 (EST) Message-ID: <3C8CDC20.F31496D@bbn.com> Date: Mon, 11 Mar 2002 11:32:32 -0500 From: David Waitzman Organization: BBN Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Scott Fluhrer Subject: Re: Problem about reassembly and fragmentation References: < <200203111556.AEA17611@mira-sjcm-3.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer wrote: I assume that the following are recurring arguments: > - The end application is too stupid to understand PMTU I would think this only applies in the transmport mode case. The end application shouldn't be the issue -- its OS should take care of this. If the OS is too stupid to have PMTU then it likely won't have IPsec. > - There's a firewall between the security gateway and the end system which > drops all ICMP messages If someone has a broken or misconfigured firewall, then why do we presume it will pass any of the IPsec traffic (ports 500, 50 or 51)? Ex: if someone has some clampled down firewall that only allows initiating tcp/25 outgoing, then it's not going to allow IPsec through either. > In either of these cases, PMTU doesn't work. And hence, we're either going to > stop supporting those legacy networks, or we're just going to allow security > gateways to fragment anyways. Are these old legacy networks with obsolete firewalls and OSs a problem worth solving? Disallowing fragments is a big win, If it can reduce HW costs and time to deployment, as well as reduce DOS risks, then the restriction seems worthwhile. As the Internet moves to more and more tunneling (such as MPLS), the need for PMTU will increase. Go with the flow. -david waitzman  From owner-ipsec@lists.tislabs.com Mon Mar 11 08:58:22 2002 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 g2BGwM815421; Mon, 11 Mar 2002 08:58:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06168 Mon, 11 Mar 2002 11:22:01 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15500.56383.446154.7279@thomasm-u1.cisco.com> Date: Mon, 11 Mar 2002 08:33:03 -0800 (PST) To: Jan Vilhuber Cc: Derek Atkins , Michael Thomas , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: References: 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 Jan Vilhuber writes: > On 8 Mar 2002, Derek Atkins wrote: > > > Michael Thomas writes: > > > > > Huh? The certs are only there for identity. If I > > > want to have two different SA's so I get differential > > > queuing treatment, there's nothing that says that I > > > need two different identities. I just change the > > > traffic selectors. This isn't any different than > > > RSVP flow selectors and queuing treatment. > > > > No, in reality the certs are there for authorization. It's just that > > people don'e understand the concept of capabilities, so we have this > > ad-hoc "identity" cert and map it via some local lookup method to a > > set of capabilities. For IKE in particular, that would be pretty idiomatic (read: non-standard). I agree that there are cert attributes, but IKE to my knowledge doesn't define any standard use of them. > > In terms of different flow selectors, it is perfectly reasonable to > > say that each flow requires its own certificate specifying the > > capability of that particular flow. Fine. The original thread was about whether you would ordinarily do that (re: auth amortization). I find that pretty unpersuasive. > I finally realized what bothers me about this, which I think is also > what angelos was talking about: What you're really saying is that IKE > is now essentially doing admission control for QoS based on a cert > (attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor > IKE's job to perform admission control for QoS. Right. That's RSVP's job. RFC 2752 is your friend. Mike From owner-ipsec@lists.tislabs.com Mon Mar 11 09:01:16 2002 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 g2BH1F815929; Mon, 11 Mar 2002 09:01:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06123 Mon, 11 Mar 2002 11:12:12 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15500.55752.986626.876138@thomasm-u1.cisco.com> Date: Mon, 11 Mar 2002 08:22:32 -0800 (PST) To: Michael Richardson Cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203102031.g2AKVZD29880@marajade.sandelman.ottawa.on.ca> References: <200203102031.g2AKVZD29880@marajade.sandelman.ottawa.on.ca> 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 Michael Richardson writes: > Jan> That's sort of my assertion. Something else did the check whether > Jan> you (the guy with the certificate) are allowed QoS for this traffic > Jan> at level X. IKE doesn't (and shouldn't IMHO) answer this question, > Jan> but should negotiate the tunnel for the different QoS level if > Jan> instructed to do so (by ipsec or rsvp or whatever...). > > if you think about encryption as a "quality" of "service", then the SPD is > going to say something like: > for traffic from v.x.y.z/mask to a.b.c.d/mask on tcp port 25 > do ESP-AES-SHA2 with "Telnet"-EF-QoS policy. > > IKE will have to inform the other end that it is doing this so that the > reverse flow can have appropriate QoS applied. (Since the QOS will be based > upon proto,dst,SPI# not TCP ports). Ugh. I think that layering got sent through the blender here. Let's step back a bit. For a security gateway, IKE is nothing more than a virtual wire establishment protocol. Under normal circumstances, it would just copy the inner DSCP to the outer, and inherit the PHB treatment on its way to the adjacent security gateway. Like any other interface to a wire you'll have policing and potentially admission control. Diffserv/Intserv gives the former, RSVP typically gives the latter. In the non-admission control case, there is no reason for IKE to do anything special. There is need for policing, but that is down in the kernel, not with IKE. For admission control, IKE still has no part, per se -- other than its job as a virtual wire creator. If there's admission control at the virtual wire entry, it works just like any other wire's admission control module. That is, RSVP should work on the virtual wire just like a real one. One twist, however, is that when you signal for a reservation which traverses a security gateway, there may be need to create a virtual wire with the proper characteristics. In the degenerate case, you build a single wire to the adjacent SG, but there may be need to create virtual wires with different characteristics (eg, low delay, etc). For this case, you may need to create a reservation for the bandwidth on the routers along the path (including the SG itself) of the virtual wire. Here, you'd use RSVP to describe the flow and its needed characteristics for the virtual wire itself. Note that this doesn't have anything directly to with the original request. It's just a matter of creating the set of virtual wires which fits the incoming traffic patterns and policies. That is, there isn't necessarily a one-one relationship between the virtual wire's reservation and the incoming traffic. The virtual wire can be dimensioned however the SG wants to dimension it, and in fact would probably want aggregate the incoming flows if large enough. Indeed, it would probably want to use the same sorts of heuristics described in RSVP aggregation (RFC 3175). Also: it is perfectly possible to use RSVP to create dimensioned virtual wires, but the incoming traffic to the SG is pure diffserv. Here the SG polices the incoming traffic, but doesn't perform admission control on it. All in all, I don't see where IKE has any part in this mix. Virtual wires need to be treated just like real wires, with admission control and policing as necessary, and virtual wires can be dimensioned on the fly themselves. Repeat until MTU == 0 :-). Mike From owner-ipsec@lists.tislabs.com Mon Mar 11 09:20:58 2002 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 g2BHKw818284; Mon, 11 Mar 2002 09:20:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06371 Mon, 11 Mar 2002 11:46:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203111556.AEA17611@mira-sjcm-3.cisco.com> References: < <200203111556.AEA17611@mira-sjcm-3.cisco.com> Date: Mon, 11 Mar 2002 11:57:50 -0500 To: Scott Fluhrer From: Stephen Kent Subject: RE: Problem about reassembly and fragmentation Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:02 AM -0800 3/11/02, Scott Fluhrer wrote: >At 06:11 AM 3/11/02 , Stephen Kent wrote: >> >> [I]n transport mode, the packets received by an IPsec implementation for >> outbound processing ought not be fragments, otherwise the implementation has >> to assemble them before applying IPsec. In tunnel mode, the IPsec >> implementation may receive fragments for outbound processing. In either >> case, the addition of the IPsec headers may require exceed the MTU for the >> outbound interface, so the "outer" header (the only header for transport >> mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU >> and thus an ability to avoid the need to fragment, and perhaps >>avoid the need >> to perform reassembly at the receiver, to remove this means of DoS attacks >> against receivers. > > >While I appreciate your trying to allow a security gateway to avoid >fragmentation, I doubt that it will always be practical in IPv4. I have seen >networks where either: > >- The end application is too stupid to understand PMTU >- There's a firewall between the security gateway and the end system which >drops all ICMP messages > >In either of these cases, PMTU doesn't work. And hence, we're either going to >stop supporting those legacy networks, or we're just going to allow security >gateways to fragment anyways. > >-- >scott Scott, I'm surprised that there are many OS instances today (it's not an application issue, right?) that still don't respond to PMTU. As for the firewall problem, there is a complementary issue, firewalls and NAT devices that drop fragments, because they can't look at port fields. We had a report at the last meeting of experience with NAT devices dropping fragments, which was causing problems for the UDP encapsulation strategy. Thus we may have problems in both cases and I'd argue for an approach that emphasizes MTU-based solutions to these problems, and a minimization of fragmentation on both sides of an IPsec implementation. Steve From owner-ipsec@lists.tislabs.com Mon Mar 11 09:21:55 2002 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 g2BHLt818335; Mon, 11 Mar 2002 09:21:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06360 Mon, 11 Mar 2002 11:44:13 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15500.57682.612507.727625@thomasm-u1.cisco.com> Date: Mon, 11 Mar 2002 08:54:42 -0800 (PST) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203091652.g29GqRC12133@marajade.sandelman.ottawa.on.ca> References: <200203091652.g29GqRC12133@marajade.sandelman.ottawa.on.ca> 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 Michael, A few quibbles, probably mostly about terminology. > Yes, I do know a lot about about various QoS systems having spent several > years designing hardware to do packet classification. Go read the RFCs. > > Yes, on a security gateway, the piece of hardware that implements the IPsec > SPD will be doing admission control for QoS. There are three > reasons for this: I'm not quite sure what you mean by "hardware" here. Admission control is typically done in software, whereas policing is often done in hardware (eg, leaky buckets, etc). Admission control is a function of *signaling*, right? Am I correct to assume you mean policing here? > 3) the alternative is that the QoS people whine about how they can > not do QoS once the packets are encrypted and could we please > reveal pieces of the packet? Well, this is a classification issue. Classification, policing and admission control are all different things. How a queuing system comes to know how to classify a particular flow is quite different from admission control which is more of a question of "will you grant me these queuing properties for this amount of traffic?" (eg, the TSPEC). > QoS flows will be based upon SPI# (which conveniently is 16bits + 16bits at > a slightly different offset and looks a lot like TCP or UDP port numbers to > hardware). > Further, odds are that the customer located QoS-enabled security gateway > will simply use RSVP to arrange QoS with the ISPs DiffServ enabled "diffedge" > border router. RSVP already has selectors for SPI# and has had them since > 1996 or so. There's more to it than this. That's *one* way to classify traffic, and only for RSVP. On entry to the tunnel, you can obviously use the DSCP to classify the traffic. Indeed, you can use whatever method you feel like to classify the traffic statically. > As stated clearly by others, you can not sort the same IPsec flow into > multiple classes of service. The replay windows get in the way. Any argument > that you want to avoid traffic analysis is moot - by putting the packets into > different flows you are in fact doing the traffic analysis for the bad guys. I agree with the first statement. I assume the latter is saying that QoS is inherently revealing thus get over it? > Not that I can see. It requires that the QoS level be negotiated, but this > is an additional "parameter", rather like an cipher algorithm. Within IKE??? I don't see it. If not IKE, whose parameter are you talking about here? Mike From owner-ipsec@lists.tislabs.com Mon Mar 11 10:02:43 2002 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 g2BI2g819590; Mon, 11 Mar 2002 10:02:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06600 Mon, 11 Mar 2002 12:25:30 -0500 (EST) Message-ID: <000801c1c91e$d70b04f0$1d0da8c0@channa> From: "Channa" To: Subject: How's IPSEC implementation tested Date: Mon, 11 Mar 2002 22:34:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1C94C.F09A0E10" 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 X-MDRemoteIP: 192.168.13.29 X-Return-Path: channa@mistralsoftware.com X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1C94C.F09A0E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am in the process of developing IPSEC, I wanted to know if there is = IPSEC test suites available for free. We have Win-2000 server with us, = is it possible to test out implementation with the Win-2000 IPSEC, = basically without IKE and with manual keying? if so how do you go about = it? Thanks Shiva ------=_NextPart_000_0005_01C1C94C.F09A0E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am in the process of developing IPSEC, I wanted to know = if there=20 is IPSEC test suites available for free. We have Win-2000 server = with us,=20 is it possible to test out implementation with the Win-2000 IPSEC, = basically=20 without IKE and with manual keying? if so how do you go about it? Thanks Shiva ------=_NextPart_000_0005_01C1C94C.F09A0E10-- From owner-ipsec@lists.tislabs.com Mon Mar 11 10:40:28 2002 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 g2BIeR821106; Mon, 11 Mar 2002 10:40:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06769 Mon, 11 Mar 2002 13:01:17 -0500 (EST) Message-Id: <200203111806.g2BI66612869@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Problem about reassembly and fragmentation In-reply-to: Your message of "Mon, 11 Mar 2002 11:32:32 EST." <3C8CDC20.F31496D@bbn.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Mar 2002 13:06:06 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Waitzman writes: David> Scott Fluhrer wrote: David> I assume that the following are recurring arguments: >> - The end application is too stupid to understand PMTU David> I would think this only applies in the transmport mode case. The David> end application shouldn't be the issue -- its OS should take care David> of this. If the OS is too stupid to have PMTU then it likely won't David> have IPsec. >> - There's a firewall between the security gateway and the end system >> which drops all ICMP messages David> If someone has a broken or misconfigured firewall, then why do we David> presume it will pass any of the IPsec traffic (ports 500, 50 or David> 51)? Ex: if someone has some clampled down firewall that only David> allows initiating tcp/25 outgoing, then it's not going to allow David> IPsec through either. You are assuming a standard VPN scenario. The places where one runs into this are when doing different things. For instance, the road warrior with the policy that *all* traffic goes to HQ (and is thus virus scanned, etc.) looks like the extruded subnet in effect: RW=============GW----Internet----SillyISP----www.example.com tunnel The problem is that SillyISP has turned off all of ICMP, making any attempt by GW to send PMTU ICMPs useless. The same things happens if "tunnel" is in fact a PPPoE connection. Of course SillyISP is too stupid to actually know that they have done this or to even understand it, and "it works" when they test things themselves. >> In either of these cases, PMTU doesn't work. And hence, we're either >> going to stop supporting those legacy networks, or we're just going to >> allow security gateways to fragment anyways. David> Are these old legacy networks with obsolete firewalls and OSs a David> problem worth solving? Disallowing fragments is a big win, If it No, these are modern networks with obsolete operators. In general, I prefer to send PMTU ICMPs, and then encrypt the too large packet, and fragment the resulting ESP. This violates the many specificiations, but it results in things working *and the ICMP is still out there*. The ICMP has to be rate limited, or one can form a kind of "ping laser" if, given A---------SG-A=============SG-B---------B someone does something like: A# ping -s 8192 B because ping tends to send a new packet each time it sees *any* ICMP :-) Also, if encrypted fragments are lost, then they are discarded before we waste crypto bandwidth to decrypting them. (If you fragment and then encrypt, then you waste more crypto bandwidth) ] 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 iQCVAwUBPIzyAoqHRg3pndX9AQFYggQA6OIIdU69YLyTU300CdGctUwL5e3ZrBBv 0sAShfsUND4xzWQD88yGRGSNI1Bi5jmqthueLQsykD/K0ZK+WxqmRA0ey3IKQ0RO 1xjcewNmaRA/undfdXH8hK7sVjyehCFNA6hdUV/Q0HiUq7jAqBIl+gqZn7tsXN/B OlQtCfmtA1s= =f9QR -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Mar 11 10:40:28 2002 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 g2BIeR821107; Mon, 11 Mar 2002 10:40:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06761 Mon, 11 Mar 2002 13:01:03 -0500 (EST) Date: Mon, 11 Mar 2002 10:12:06 -0800 (PST) From: Jan Vilhuber To: Michael Thomas cc: Michael Richardson , Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <15500.55752.986626.876138@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 11 Mar 2002, Michael Thomas wrote: > Michael Richardson writes: > > Jan> That's sort of my assertion. Something else did the check whether > > Jan> you (the guy with the certificate) are allowed QoS for this traffic > > Jan> at level X. IKE doesn't (and shouldn't IMHO) answer this question, > > Jan> but should negotiate the tunnel for the different QoS level if > > Jan> instructed to do so (by ipsec or rsvp or whatever...). > > > > if you think about encryption as a "quality" of "service", then the SPD is > > going to say something like: > > for traffic from v.x.y.z/mask to a.b.c.d/mask on tcp port 25 > > do ESP-AES-SHA2 with "Telnet"-EF-QoS policy. > > > > IKE will have to inform the other end that it is doing this so that the > > reverse flow can have appropriate QoS applied. (Since the QOS will be based > > upon proto,dst,SPI# not TCP ports). > > Ugh. I think that layering got sent through the > blender here. Let's step back a bit. For a > security gateway, IKE is nothing more than a > virtual wire establishment protocol. Under normal > circumstances, it would just copy Correction: *IPsec* does the copying, not IKE. As you say, IKE merely negotiated the parameters of the tunnel for IPsec. > the inner DSCP > to the outer, and inherit the PHB treatment on its > way to the adjacent security gateway. Like any > other interface to a wire you'll have policing and > potentially admission control. Diffserv/Intserv > gives the former, RSVP typically gives the latter. > In the non-admission control case, there is no > reason for IKE to do anything special. There is > need for policing, but that is down in the kernel, > not with IKE. > > For admission control, IKE still has no part, per > se -- other than its job as a virtual wire > creator. If I understood mcr correctly, he's saying the same thing as you, i.e. if you're going to have separate SA's for each QoS-flow, then you must have IKE negotiate it. IKE currently can not negotiate a tunnel with QoS parameters. > If there's admission control at the > virtual wire entry, it works just like any other > wire's admission control module. That is, RSVP > should work on the virtual wire just like a real > one. > > One twist, however, is that when you signal for a > reservation which traverses a security gateway, > there may be need to create a virtual wire with > the proper characteristics. In the degenerate > case, you build a single wire to the adjacent SG, > but there may be need to create virtual wires with > different characteristics (eg, low delay, > etc). For this case, you may need to create a > reservation for the bandwidth on the routers along > the path (including the SG itself) of the virtual > wire. Here, you'd use RSVP to describe the flow > and its needed characteristics for the virtual > wire itself. Note that this doesn't have anything > directly to with the original request. It's just a > matter of creating the set of virtual wires which > fits the incoming traffic patterns and policies. > That is, there isn't necessarily a one-one > relationship between the virtual wire's > reservation and the incoming traffic. The virtual > wire can be dimensioned however the SG wants to > dimension it, and in fact would probably want > aggregate the incoming flows if large enough. > Indeed, it would probably want to use the same > sorts of heuristics described in RSVP aggregation > (RFC 3175). Also: it is perfectly possible to use > RSVP to create dimensioned virtual wires, but the > incoming traffic to the SG is pure diffserv. Here > the SG polices the incoming traffic, but doesn't > perform admission control on it. > > All in all, I don't see where IKE has any part in > this mix. It comes in only in the fact that you may need to negotiate an SA for traffic with certain QoS settings. Whether the user is allowed a higher level of QoS, and underlying packet classification in the forwarding engine is completely separate and obviously not IKE's job. jan > Virtual wires need to be treated just > like real wires, with admission control and > policing as necessary, and virtual wires can be > dimensioned on the fly themselves. Repeat until > MTU == 0 :-). > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Mar 11 11:08:37 2002 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 g2BJ8b822373; Mon, 11 Mar 2002 11:08:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07013 Mon, 11 Mar 2002 13:30:39 -0500 (EST) Date: Mon, 11 Mar 2002 10:41:42 -0800 (PST) From: Jan Vilhuber To: Michael Thomas cc: Michael Richardson , Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <15500.57682.612507.727625@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 11 Mar 2002, Michael Thomas wrote: > > Not that I can see. It requires that the QoS level be negotiated, but this > > is an additional "parameter", rather like an cipher algorithm. > > Within IKE??? I don't see it. If not IKE, whose > parameter are you talking about here? > Instead of negotiating (tunnel from A to B), as you can do now, you'd have to be able to negotiate (tunnel from A to B with tos-bits 010101). IKE currently can't do that. I believe that's what mcr is saying.. Note that (IMO) this says nothing of policing, admission control, etc. It's merely a tunnel we're negotiating. It's up to some local policy manager on the endpoints (not IKE!) to decide whether this is an allowable tunnel for the user (and whether the user/endpoint is allowed to send traffic under Qos-level 010101 to begin with). IKE should care about NONE of those things. IKE gets told "negotiate this tunnel for me" and IKE goes and does it. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Mar 11 11:39:34 2002 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 g2BJdX824716; Mon, 11 Mar 2002 11:39:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07218 Mon, 11 Mar 2002 13:59:20 -0500 (EST) Date: Mon, 11 Mar 2002 19:58:33 +0100 From: =?iso-8859-2?Q?Pawe=B3?= Krawczyk To: Channa Cc: ipsec@lists.tislabs.com Subject: Re: How's IPSEC implementation tested Message-ID: <20020311185833.GA29902@aba.krakow.pl> References: <000801c1c91e$d70b04f0$1d0da8c0@channa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c1c91e$d70b04f0$1d0da8c0@channa> User-Agent: Mutt/1.3.25i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Mar 11, 2002 at 10:34:43PM +0530, Channa wrote: > I am in the process of developing IPSEC, I wanted to know if there is > IPSEC test suites available for free. You can use two remote tests available: http://isakmp-test.ssh.fi/ (SSH Communications) http://ipsec-wit.antd.gov/ (NIST) The latter was not working last week, but I've got reply from NIST saying that it will be operational soon (this week). > We have Win-2000 server with us, is > it possible to test out implementation with the Win-2000 IPSEC, basically > without IKE and with manual keying? if so how do you go about it? AFAIK Windows 2000 IPSec implementation doesn't allow you to setup ESP/AH manually, it has to be done via IKE. I don't know why it's like that, probably some political decision at Microsoft because I was told that it was possible in the early betas. -- Pawel Krawczyk * http://echelon.pl/kravietz/ Krakow, Poland * http://ipsec.pl/ From owner-ipsec@lists.tislabs.com Mon Mar 11 12:46:59 2002 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 g2BKkx827229; Mon, 11 Mar 2002 12:46:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07490 Mon, 11 Mar 2002 14:46:09 -0500 (EST) From: dfox@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A018EAE81@email.quarrytech.com> To: kravietz@aba.krakow.pl, channa@mistralsoftware.com Cc: ipsec@lists.tislabs.com Subject: RE: How's IPSEC implementation tested Date: Mon, 11 Mar 2002 14:57:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pawel, You have the NIST site URL slightly wrong. Try this address: http://ipsec-wit.antd.nist.gov/. I just connected to it without any difficulty. David Fox -----Original Message----- From: Pawel Krawczyk [mailto:kravietz@aba.krakow.pl] Sent: Monday, March 11, 2002 1:59 PM To: Channa Cc: ipsec@lists.tislabs.com Subject: Re: How's IPSEC implementation tested On Mon, Mar 11, 2002 at 10:34:43PM +0530, Channa wrote: > I am in the process of developing IPSEC, I wanted to know if there is > IPSEC test suites available for free. You can use two remote tests available: http://isakmp-test.ssh.fi/ (SSH Communications) http://ipsec-wit.antd.gov/ (NIST) The latter was not working last week, but I've got reply from NIST saying that it will be operational soon (this week). > We have Win-2000 server with us, is > it possible to test out implementation with the Win-2000 IPSEC, basically > without IKE and with manual keying? if so how do you go about it? AFAIK Windows 2000 IPSec implementation doesn't allow you to setup ESP/AH manually, it has to be done via IKE. I don't know why it's like that, probably some political decision at Microsoft because I was told that it was possible in the early betas. -- Pawel Krawczyk * http://echelon.pl/kravietz/ Krakow, Poland * http://ipsec.pl/ From owner-ipsec@lists.tislabs.com Mon Mar 11 13:30:12 2002 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 g2BLUC828293; Mon, 11 Mar 2002 13:30:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07899 Mon, 11 Mar 2002 15:49:04 -0500 (EST) X-VirusChecked: Checked Message-ID: <8B204D152222D51182B70001028841376DAB09@postmaster.cryptek.com> From: "Hu, Shicai" To: Stephen Kent , Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: RE: Problem about reassembly and fragmentation Date: Mon, 11 Mar 2002 16:02:47 -0500 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 PMTU only applies in the case of DF bit set, right? Why some application layer like NFS wants to send very large packets: NFS version 2 can send 8K size per message flow, NFS version 3 can send 32K bytes per message flow. How PMTU can handle this kind of cases? -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, March 11, 2002 11:58 AM To: Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: RE: Problem about reassembly and fragmentation At 8:02 AM -0800 3/11/02, Scott Fluhrer wrote: >At 06:11 AM 3/11/02 , Stephen Kent wrote: >> >> [I]n transport mode, the packets received by an IPsec implementation for >> outbound processing ought not be fragments, otherwise the implementation has >> to assemble them before applying IPsec. In tunnel mode, the IPsec >> implementation may receive fragments for outbound processing. In either >> case, the addition of the IPsec headers may require exceed the MTU for the >> outbound interface, so the "outer" header (the only header for transport >> mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU >> and thus an ability to avoid the need to fragment, and perhaps >>avoid the need >> to perform reassembly at the receiver, to remove this means of DoS attacks >> against receivers. > > >While I appreciate your trying to allow a security gateway to avoid >fragmentation, I doubt that it will always be practical in IPv4. I have seen >networks where either: > >- The end application is too stupid to understand PMTU >- There's a firewall between the security gateway and the end system which >drops all ICMP messages > >In either of these cases, PMTU doesn't work. And hence, we're either going to >stop supporting those legacy networks, or we're just going to allow security >gateways to fragment anyways. > >-- >scott Scott, I'm surprised that there are many OS instances today (it's not an application issue, right?) that still don't respond to PMTU. As for the firewall problem, there is a complementary issue, firewalls and NAT devices that drop fragments, because they can't look at port fields. We had a report at the last meeting of experience with NAT devices dropping fragments, which was causing problems for the UDP encapsulation strategy. Thus we may have problems in both cases and I'd argue for an approach that emphasizes MTU-based solutions to these problems, and a minimization of fragmentation on both sides of an IPsec implementation. Steve From owner-ipsec@lists.tislabs.com Mon Mar 11 15:45:24 2002 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 g2BNjN802176; Mon, 11 Mar 2002 15:45:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08654 Mon, 11 Mar 2002 18:10:49 -0500 (EST) Message-Id: <200203112322.g2BNMD903490@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Mon, 11 Mar 2002 10:41:42 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Mar 2002 18:22:12 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: Jan> On Mon, 11 Mar 2002, Michael Thomas wrote: >> > Not that I can see. It requires that the QoS level be negotiated, but this >> > is an additional "parameter", rather like an cipher algorithm. >> >> Within IKE??? I don't see it. If not IKE, whose >> parameter are you talking about here? >> Jan> Instead of negotiating (tunnel from A to B), as you can do now, you'd Jan> have to be able to negotiate (tunnel from A to B with tos-bits Jan> 010101). IKE currently can't do that. I believe that's what mcr is Jan> saying.. Jan> Note that (IMO) this says nothing of policing, admission control, Jan> etc. It's merely a tunnel we're negotiating. It's up to some local Jan> policy manager on the endpoints (not IKE!) to decide whether this is Jan> an allowable tunnel for the user (and whether the user/endpoint is Jan> allowed to send traffic under Qos-level 010101 to begin with). IKE Jan> should care about NONE of those things. IKE gets told "negotiate this Jan> tunnel for me" and IKE goes and does it. First, I'll ask you guys to go read the diffserv roadmap. There is a device called a "diffedge" device which does admission control at the edge of a diffserv network. There is existing experience within Win2K using RSVP to talk from desktops to the ISP's diffedge device. So, this isn't theoretical (although I have yet to actually see this in production myself). Diffserv codepoints are not, in general, supposed to extend across ASs, so the customer-located VPN box will not benefit at all from setting the DSCP bits. The ISP's edge device will ignore them anyway and reclassify the packets. Now if you assume that both ends of a tunnel are fully configured with all of their policy, then there is no reason for IKE to be involved. The VPN box will already know all of the QoS policy that needs to be created. This is the virtual leased line situation. The problem is when there are end points which either move or are not always connected. Even in the leased line situation, consider the situation of the nightly backup that wants AF on the packets, but since it costs money to keep the AF circuit open, you want to keep it on only when actually needed. Take a remote (home office) node. Might be a broadband PPPoE (thus random outer IP) DSL connected person working at home that has just received a SIP invitation from the corporate PBX and has initiated an RTP call running on some random UDP ports. They have someone informed IPsec and QoS that they want a EF tunnel for the VoIP call. (How this happens is an OS issue. Mine can do the IPsec stuff just fine, except that it doesn't have the QoS yet) Now, IKE is asked to negotiate a tunnel for this UDP port pair. The QoS system uses RSVP to the ISPs edge device, asking for the right AF service for the proto,SPI,dst tuple that IKE picked. (See RFC2205, RFC2207). This gets the forward QoS. Now what about the reverse QoS? How does the corporate gateway have any clue that it the negotiation of a UDP port pair should imply that it then asks for AF service for the packets that it sends? Should the home office box send an RSVP packet to the corporate ISPs edge router? If you think about the trust relationship problem there, then you'll understand why RSVP was thrown away as a useable mechanism for Internet-wide QoS. No, the way to do this is with a attribute in the proposal that essentially asks to do "QoS AF-#6" service for the resulting tunnel. (I regularly attempt to do VoIP over 3DES keyed tunnels. The crypto is neglible impact. The lack of QoS in the middle of the network is what screws us, and we go back to using ma bell). ] 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 iQCVAwUBPI08IoqHRg3pndX9AQF2cgP+Pkgjc4b2SmMNCyHnwzPFcd7jjjLsUlkZ RN/ZujXsQBGYmQgu8xDnvOkULfiB78AmdHYnGl7nJMoQzMBK3BB0rqB4Yrf3oNn0 rjitUxD1gG81xf9QbF3yp/8oTQo34ROCyrDYUbjizI9CNz/kiu4awA4egK1wRgsG 2R3VTjWKH7Y= =HtZL -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Mar 11 15:45:37 2002 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 g2BNja802192; Mon, 11 Mar 2002 15:45:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08405 Mon, 11 Mar 2002 17:40:53 -0500 (EST) From: "Andrew Wenlang Zhu" To: Subject: How to pass AES rounds number through PF_KEY interface Date: Mon, 11 Mar 2002 14:51:57 -0800 Message-ID: <001501c1c94f$59ec6af0$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <496A8683261CD211BF6C0008C733261A018EAE81@email.quarrytech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy all: I am working on implement AES on HPUX IPsec/9000 which uses PF_KEY v2 between kernel and IKE. Since the AES rounds number MAY be negotiated according to the Internet Draft <> , I need to find a way to pass the rounds number from IKE to kernel to install the SA. Unfortunately, I can not find a pre-defined parameter to transfer this number. How do you transfer the AES rounds number in PF_KEY? Thanks --------------------------------------- Andrew Zhu HP Systems Networking Solution Lab IP Security & System Firewall Project Andrew_zhu@hp.com From owner-ipsec@lists.tislabs.com Mon Mar 11 20:43:32 2002 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 g2C4hW409088; Mon, 11 Mar 2002 20:43:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10141 Mon, 11 Mar 2002 22:57:48 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 11 Mar 2002 20:09:27 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Unmatched authentication in IKEv2? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The new draft introduces authentication with preshared secrets. There is nothing in the draft the would preclude one side from authenticating with certificates and the other side authenticating with preshared secrets. Is this intentional, and in what cases would it be a good idea? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 11 20:43:36 2002 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 g2C4ha409101; Mon, 11 Mar 2002 20:43:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10218 Mon, 11 Mar 2002 23:01:16 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 11 Mar 2002 20:12:53 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Lack of error descriptions for Phase 1 in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKEv2 is still very thin on describing what should be done during Phase 1 in case of some pretty typical errors. This means that there will be little interoperability in common situations. If message 1 contains cert-requests and the responder knows that his certs won't chain to any of the stated roots, he should send an INVALID_CERT_AUTHORITY notification in message 2. What else should be in message 2? Section 2.5 says that the payloads must be in the stated order, but it makes no sense to send anything in message 2 other than the error notification payload. If message 2 contains cert-requests and the initiator knows that his certs won't chain to any of the stated roots, he should send an INVALID_CERT_AUTHORITY notification in message 3. What else should be in message 3? According to Appendix B, message 3 should be encrypted and integrity protected; does that seem right for a fatal error such as this? Same two questions for message 1 and 2, except about getting an IKE version number that is higher than what you support. If message 3 has an error such as malformed payload or a cert-chaining failure, what should be in message 4? According to Appendix B, message 4 should be encrypted and integrity protected; does that seem right for a fatal error such as this? If message 4 has an error such as malformed payload or a cert-chaining failure, what should the responder do? - Send a "message 5" (and if so, should it be encrypted?) - Start a Phase 2 so the responder can start an informational exchange, followed by a delete of both the Phase 2 and Phase 1? Same two questions for message 3 and 4, except about getting an IKE version number that is higher than what you support. Section 2.5 says that the notification should be unauthenticated, but Appendix B says it MUST be authenticated. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 11 20:43:37 2002 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 g2C4ha409111; Mon, 11 Mar 2002 20:43:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10107 Mon, 11 Mar 2002 22:55:09 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 11 Mar 2002 20:06:47 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Addresses in traffic selectors in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One of the most common configuration errors found in VPNC conformance testing is that people use the wrong address type in their traffic selectors. There are two ways to specify multiple addresses (ranges and subnets) and three ways to specify a single address (ranges, subnets, and address). This is silly. IKEv2 should have exactly one way to specify either a single or multiple addresses: a range. IKE implementations *could* match the different types to each other (some implementations do that), but there is no reason to force them to. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 11 20:43:42 2002 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 g2C4hf409126; Mon, 11 Mar 2002 20:43:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10123 Mon, 11 Mar 2002 22:57:03 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 11 Mar 2002 20:08:41 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Remove SHOULD for elliptic curve groups in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Elliptic curve groups have barely been tested for interoperability. The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As wonderful as EC cryptography is supposed to be, it is overkill to make it a near-requirement when probably fewer than 10% of implementations today use it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 12 06:08:12 2002 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 g2CE8B401060; Tue, 12 Mar 2002 06:08:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16097 Tue, 12 Mar 2002 08:16:57 -0500 (EST) X-VirusChecked: Checked Message-ID: <8B204D152222D51182B70001028841376DAB29@postmaster.cryptek.com> From: "Parn, William" To: "Hu, Shicai" , Stephen Kent , Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: RE: Problem about reassembly and fragmentation Date: Tue, 12 Mar 2002 08:30:44 -0500 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 Shicai I think the keyword Steve brings up is to minimize where possible fragmentation by using PMTU. There will still be situations (applications) where it is not possible to completely get rid of fragmentation altogether. > -----Original Message----- > From: Hu, Shicai [mailto:shicai@cryptek.com] > Sent: Monday, March 11, 2002 4:03 PM > To: Stephen Kent; Scott Fluhrer > Cc: ipsec@lists.tislabs.com > Subject: RE: Problem about reassembly and fragmentation > > > PMTU only applies in the case of DF bit set, right? > > Why some application layer like NFS wants to send very large > packets: NFS > version 2 can > > send 8K size per message flow, NFS version 3 can send 32K > bytes per message > flow. How PMTU > > can handle this kind of cases? > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, March 11, 2002 11:58 AM > To: Scott Fluhrer > Cc: ipsec@lists.tislabs.com > Subject: RE: Problem about reassembly and fragmentation > > > At 8:02 AM -0800 3/11/02, Scott Fluhrer wrote: > >At 06:11 AM 3/11/02 , Stephen Kent wrote: > >> > >> [I]n transport mode, the packets received by an IPsec > implementation for > >> outbound processing ought not be fragments, otherwise the > implementation > has > >> to assemble them before applying IPsec. In tunnel mode, the IPsec > >> implementation may receive fragments for outbound > processing. In either > >> case, the addition of the IPsec headers may require > exceed the MTU for > the > >> outbound interface, so the "outer" header (the only > header for transport > >> mode) may exhibit fragmentation. I'd like to push for > mandatory use of > PMTU > >> and thus an ability to avoid the need to fragment, and perhaps > >>avoid the need > >> to perform reassembly at the receiver, to remove this means of DoS > attacks > >> against receivers. > > > > > >While I appreciate your trying to allow a security gateway to avoid > >fragmentation, I doubt that it will always be practical in > IPv4. I have > seen > >networks where either: > > > >- The end application is too stupid to understand PMTU > >- There's a firewall between the security gateway and the > end system which > >drops all ICMP messages > > > >In either of these cases, PMTU doesn't work. And hence, > we're either going > to > >stop supporting those legacy networks, or we're just going to allow > security > >gateways to fragment anyways. > > > >-- > >scott > > Scott, > > I'm surprised that there are many OS instances today (it's not an > application issue, right?) that still don't respond to PMTU. > > As for the firewall problem, there is a complementary issue, > firewalls and NAT devices that drop fragments, because they can't > look at port fields. We had a report at the last meeting of > experience with NAT devices dropping fragments, which was causing > problems for the UDP encapsulation strategy. Thus we may have > problems in both cases and I'd argue for an approach that emphasizes > MTU-based solutions to these problems, and a minimization of > fragmentation on both sides of an IPsec implementation. > > Steve > From owner-ipsec@lists.tislabs.com Tue Mar 12 06:08:17 2002 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 g2CE8H401078; Tue, 12 Mar 2002 06:08:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16186 Tue, 12 Mar 2002 08:28:00 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0DC7@MAIL.NetOctave.com> From: Mark Winstead To: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 08:39:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9CB.584474F0" 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_01C1C9CB.584474F0 Content-Type: text/plain; charset="iso-8859-1" Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES? With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63) > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Monday, March 11, 2002 11:09 PM > To: ipsec@lists.tislabs.com > Subject: Remove SHOULD for elliptic curve groups in IKEv2 > > > Elliptic curve groups have barely been tested for interoperability. > The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As > wonderful as EC cryptography is supposed to be, it is overkill to > make it a near-requirement when probably fewer than 10% of > implementations today use it. > > --Paul Hoffman, Director > --VPN Consortium > ------_=_NextPart_001_01C1C9CB.584474F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Remove SHOULD for elliptic curve groups in IKEv2

Today it is fewer than 10%, but can't something close = to that be said, at least recently, for AES?

With AES and its increased key sizes coming, = shouldn't more EC groups be included? some with SHOULD for support of = AES various key sizes and some additional MAYs? I believe consideration = should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, = ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), = sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 = (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), = secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI = 9.63)

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]<= /FONT>
> Sent: Monday, March 11, 2002 11:09 PM
> To: ipsec@lists.tislabs.com
> Subject: Remove SHOULD for elliptic curve = groups in IKEv2
>
>
> Elliptic curve groups have barely been tested = for interoperability.
> The SHOULDs in section 8.3 and 8.4 should be = reduced to MAYs. As
> wonderful as EC cryptography is supposed to be, = it is overkill to
> make it a near-requirement when probably fewer = than 10% of
> implementations today use it.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

------_=_NextPart_001_01C1C9CB.584474F0-- From owner-ipsec@lists.tislabs.com Tue Mar 12 08:00:43 2002 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 g2CG0g409364; Tue, 12 Mar 2002 08:00:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16737 Tue, 12 Mar 2002 10:07:03 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 10:10:38 -0500 Message-ID: <000c01c1c9d8$1267dc80$1e72788a@ca.alcatel.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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't know if should == near requirement as far as crypto algorithms are concerned. After all, Tiger was a should for how many years? Plus, people tend to ignore crypto requirements and implement what they feel like (e.g. wrt DES, Group 1, DSA, El Gamal). The fact is, everybody here plans to support ECDH or at least would like to. I see no problem in being forward looking and making it a should. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Monday, March 11, 2002 11:09 PM > To: ipsec@lists.tislabs.com > Subject: Remove SHOULD for elliptic curve groups in IKEv2 > > > Elliptic curve groups have barely been tested for interoperability. > The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As > wonderful as EC cryptography is supposed to be, it is overkill to > make it a near-requirement when probably fewer than 10% of > implementations today use it. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Mar 12 08:04:28 2002 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 g2CG4R409729; Tue, 12 Mar 2002 08:04:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16817 Tue, 12 Mar 2002 10:22:03 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 12 Mar 2002 10:25:37 -0500 Message-ID: <000d01c1c9da$2a6e9bf0$1e72788a@ca.alcatel.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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with this. There are lots of little pitfalls that I have seen when dealing with subnets: e.g. does 192.168.10.0/24 == 192.168.10.30/24? Not if you use memcmp. What happens if someone receives a QM1 containing subnets and the peer returns a QM2 containing ranges? We would have liked to implement QM using only ranges, but we were forced to convert to subnets whenever possible because some of the other IPsec implementations aren't (or at least weren't at the time) able to handle ranges. There is no advantage to having multiple types in this case, so we should ditch the less generic ones. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Monday, March 11, 2002 11:07 PM > To: ipsec@lists.tislabs.com > Subject: Addresses in traffic selectors in IKEv2 > > > One of the most common configuration errors found in VPNC conformance > testing is that people use the wrong address type in their traffic > selectors. There are two ways to specify multiple addresses (ranges > and subnets) and three ways to specify a single address (ranges, > subnets, and address). This is silly. > > IKEv2 should have exactly one way to specify either a single or > multiple addresses: a range. IKE implementations *could* match the > different types to each other (some implementations do that), but > there is no reason to force them to. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Mar 12 08:38:46 2002 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 g2CGcj411434; Tue, 12 Mar 2002 08:38:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16991 Tue, 12 Mar 2002 10:55:45 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <000c01c1c9d8$1267dc80$1e72788a@ca.alcatel.com> References: <000c01c1c9d8$1267dc80$1e72788a@ca.alcatel.com> Date: Tue, 12 Mar 2002 08:00:48 -0800 To: , From: Paul Hoffman / VPNC Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:10 AM -0500 3/12/02, Andrew Krywaniuk wrote: >I don't know if should == near requirement as far as crypto algorithms are >concerned. After all, Tiger was a should for how many years? Plus, people >tend to ignore crypto requirements and implement what they feel like (e.g. >wrt DES, Group 1, DSA, El Gamal). The fact is, everybody here plans to >support ECDH or at least would like to. I see no problem in being forward >looking and making it a should. In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG has been particularly bad at this, with the TIGER example being an excellent example. The relevant paragraph from RFC 2119 says: >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. The full implications of not doing elliptic curves are not discussed in the IKEv2 document, probably because they are highly debatable. Are elliptic curve calculations faster with acceleration hardware? How can we be sure that they are as secure as RSA? Are there interoperability issues that we don't know about because almost no one has tested them? How easy is it to mis-implement them and not know it? What are the patent issues associated with them? If people think that elliptic curves will become more useful and popular in the future, it is fine to list them in the document as MAY. (If we think they will be the next TIGER or or DES, we should eliminate them, but that doesn't seem to be the case yet.) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 12 09:26:58 2002 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 g2CHQv415663; Tue, 12 Mar 2002 09:26:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17184 Tue, 12 Mar 2002 11:40:25 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699E6@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 08:52:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C9E6.5D8BAB20" 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_000_01C1C9E6.5D8BAB20 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9E6.5D8BAB20" ------_=_NextPart_001_01C1C9E6.5D8BAB20 Content-Type: text/plain; charset="iso-8859-1" I must admit that I am somewhat skeptical as to the argument that anyone using 256 bit AES should be supporting public key mechanisms of equivalent strength. First, the main application I would see for 256 bit AES would be to encrypt private key parameters in PKCS#12 type applications so one would expect to use a stronger symmetric cipher than public cipher. I would expect that most implementations of AES would implement all three cipher strengths as the additional cost of doing so is minimal. The same cannot be said for adding in new public key algorithms. If I did choose to enable 256 bit AES on a system it would not be for fear that someone might break 128 bit AES through brute force, it is more likely that I would be concerned about some new cryptanalytic technique (c.f. differential cryptanalysis) against AES and would want to take advantage of the additional security provided by the extra rounds. The next generation of public key algorithms that I am interested in is public key algorithms that have a high work factor against quantum computing attacks. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 -----Original Message----- From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com] Sent: Tuesday, March 12, 2002 8:40 AM To: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES? With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63) > -----Original Message----- > From: Paul Hoffman / VPNC [ mailto:paul.hoffman@vpnc.org ] > Sent: Monday, March 11, 2002 11:09 PM > To: ipsec@lists.tislabs.com > Subject: Remove SHOULD for elliptic curve groups in IKEv2 > > > Elliptic curve groups have barely been tested for interoperability. > The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As > wonderful as EC cryptography is supposed to be, it is overkill to > make it a near-requirement when probably fewer than 10% of > implementations today use it. > > --Paul Hoffman, Director > --VPN Consortium > ------_=_NextPart_001_01C1C9E6.5D8BAB20 Content-Type: text/html; charset="iso-8859-1" RE: Remove SHOULD for elliptic curve groups in IKEv2
I must admit that I am somewhat skeptical as to the argument that anyone using 256 bit AES should be supporting public key mechanisms of equivalent strength.
 
First, the main application I would see for 256 bit AES would be to encrypt private key parameters in PKCS#12 type applications so one would expect to use a stronger symmetric cipher than public cipher.
 
I would expect that most implementations of AES would implement all three cipher strengths as the additional cost of doing so is minimal. The same cannot be said for adding in new public key algorithms.
 
If I did choose to enable 256 bit AES on a system it would not be for fear that someone might break 128 bit AES through brute force, it is more likely that I would be concerned about some new cryptanalytic technique (c.f. differential cryptanalysis) against AES and would want to take advantage of the additional security provided by the extra rounds.
 
The next generation of public key algorithms that I am interested in is public key algorithms that have a high work factor against quantum computing attacks.
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com]
Sent: Tuesday, March 12, 2002 8:40 AM
To: ipsec@lists.tislabs.com
Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2

Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES?

With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63)

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Monday, March 11, 2002 11:09 PM
> To: ipsec@lists.tislabs.com
> Subject: Remove SHOULD for elliptic curve groups in IKEv2
>
>
> Elliptic curve groups have barely been tested for interoperability.
> The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As
> wonderful as EC cryptography is supposed to be, it is overkill to
> make it a near-requirement when probably fewer than 10% of
> implementations today use it.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

------_=_NextPart_001_01C1C9E6.5D8BAB20-- ------_=_NextPart_000_01C1C9E6.5D8BAB20 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C9E6.5D8BAB20-- From owner-ipsec@lists.tislabs.com Tue Mar 12 09:35:54 2002 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 g2CHZq415969; Tue, 12 Mar 2002 09:35:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17234 Tue, 12 Mar 2002 11:52:31 -0500 (EST) Message-ID: <3C8E353C.5F1A2C16@sonicwall.com> Date: Tue, 12 Mar 2002 09:05:00 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Winstead CC: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DC7@MAIL.NetOctave.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2002 17:05:00.0984 (UTC) FILETIME=[0BC06B80:01C1C9E8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree that AES illuminates the need for EC groups - the MODP exponent/modulus sizes required for longer keys are prohibitive, and EC's are a viable alternative. However, if EC support is not at least a SHOULD, there may be interoperability issues. Scott > Mark Winstead wrote: > > Today it is fewer than 10%, but can't something close to that be said, > at least recently, for AES? > > With AES and its increased key sizes coming, shouldn't more EC groups > be included? some with SHOULD for support of AES various key sizes and > some additional MAYs? I believe consideration should be given to > adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 > (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, > ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, > ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), > secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See > http://www.secg.org/collateral/sec2.pdf or ANSI 9.63) > > > -----Original Message----- > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > Sent: Monday, March 11, 2002 11:09 PM > > To: ipsec@lists.tislabs.com > > Subject: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > Elliptic curve groups have barely been tested for interoperability. > > The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As > > wonderful as EC cryptography is supposed to be, it is overkill to > > make it a near-requirement when probably fewer than 10% of > > implementations today use it. > > > > --Paul Hoffman, Director > > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Tue Mar 12 09:38:52 2002 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 g2CHco416061; Tue, 12 Mar 2002 09:38:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17285 Tue, 12 Mar 2002 11:58:27 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15502.13904.724175.124068@pkoning.dev.equallogic.com> Date: Tue, 12 Mar 2002 12:09:36 -0500 From: Paul Koning To: Mark.Winstead@NetOctave.com Cc: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DC7@MAIL.NetOctave.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mark" == Mark Winstead writes: Mark> Today it is fewer than 10%, but can't something close to that Mark> be said, at least recently, for AES? Mark> With AES and its increased key sizes coming, shouldn't more EC Mark> groups be included? One data point: Even before AES was nailed down, there were chip vendors announcing hardware acceleration support for AES. On the other hand, years after EC came out, hardware accelerator support for it is still somewhere between very rare and nonexistent. I'm inclined to view these data as an indication of the interest level in EC; it supports Paul Hoffman's suggestion. paul From owner-ipsec@lists.tislabs.com Tue Mar 12 10:16:39 2002 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 g2CIGc417951; Tue, 12 Mar 2002 10:16:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17497 Tue, 12 Mar 2002 12:39:10 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Paul Hoffman / VPNC'" , "Andrew Krywaniuk" , Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 12:39:34 -0500 Message-ID: <000901c1c9ec$e20bbf10$1e72788a@ca.alcatel.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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >3. SHOULD This word, or the adjective "RECOMMENDED", mean > that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. The valid reason for ignoring them is that the patent owners seem unwilling to disclose exactly what they own. The implication of ignoring them is that you won't be able to match the preferred security profile of many(?) other implementations. > In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG > has been particularly bad at this, with the TIGER example being an > excellent example. But are the SHOULDs supposed to reflect the current reality or the anticipated reality of when the protocol advances to draft standard? IKEv1 never advanced that far; if it had, we would have had to remove TIGER, or at least reduce it to a MAY. If you weren't able to specify MUST or SHOULD for features that aren't widely implemented yet, then we wouldn't be able to define new protocols. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Tuesday, March 12, 2002 11:01 AM > To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com > Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > > > At 10:10 AM -0500 3/12/02, Andrew Krywaniuk wrote: > >I don't know if should == near requirement as far as crypto > algorithms are > >concerned. After all, Tiger was a should for how many years? > Plus, people > >tend to ignore crypto requirements and implement what they > feel like (e.g. > >wrt DES, Group 1, DSA, El Gamal). The fact is, everybody > here plans to > >support ECDH or at least would like to. I see no problem in > being forward > >looking and making it a should. > > In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG > has been particularly bad at this, with the TIGER example being an > excellent example. > > The relevant paragraph from RFC 2119 says: > > >3. SHOULD This word, or the adjective "RECOMMENDED", mean > that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > The full implications of not doing elliptic curves are not discussed > in the IKEv2 document, probably because they are highly debatable. > Are elliptic curve calculations faster with acceleration hardware? > How can we be sure that they are as secure as RSA? Are there > interoperability issues that we don't know about because almost no > one has tested them? How easy is it to mis-implement them and not > know it? What are the patent issues associated with them? > > If people think that elliptic curves will become more useful and > popular in the future, it is fine to list them in the document as > MAY. (If we think they will be the next TIGER or or DES, we should > eliminate them, but that doesn't seem to be the case yet.) > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Mar 12 10:17:24 2002 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 g2CIHO417981; Tue, 12 Mar 2002 10:17:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17470 Tue, 12 Mar 2002 12:34:05 -0500 (EST) Message-ID: <3C8E6775.747EBA85@storm.ca> Date: Tue, 12 Mar 2002 12:39:17 -0800 From: Sandy Harris X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: How to pass AES rounds number through PF_KEY interface References: <001501c1c94f$59ec6af0$6f690d0f@AZ735043> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Wenlang Zhu wrote: > Since the AES rounds number MAY be negotiated according to the > Internet Draft <> > , If so, methinks the draft should change. In the original Rijndael spec, and I presume in the final AES, the number of rounds depends on key (and, for original Rijndael, block) size, but does not vary other than that. There should never be a need to negotiate or set number of rounds. Set the key size (for AES, block size is fixed at 128) and the number of rounds is determined. I think it's 10, 12, 14 for 128, 192, 256, but I haven't got the spec to hand and am not entirely certain. > I need to find a way to pass the rounds number from IKE to kernel > to install the SA. Unfortunately, I can not > find a pre-defined parameter to transfer this number. > > How do you transfer the AES rounds number in PF_KEY? From owner-ipsec@lists.tislabs.com Tue Mar 12 10:36:27 2002 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 g2CIaQ418748; Tue, 12 Mar 2002 10:36:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17604 Tue, 12 Mar 2002 12:55:31 -0500 (EST) Message-Id: <200203121806.g2CI67gw010758@thunk.East.Sun.COM> From: Bill Sommerfeld To: "Andrew Wenlang Zhu" cc: ipsec@lists.tislabs.com Subject: Re: How to pass AES rounds number through PF_KEY interface In-Reply-To: Your message of "Mon, 11 Mar 2002 14:51:57 PST." <001501c1c94f$59ec6af0$6f690d0f@AZ735043> Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Mar 2002 13:06:07 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > How do you transfer the AES rounds number in PF_KEY? You don't need to; it's implied by the key size. This is one of the few differences between Rijndael and AES -- Rijndael has independant parameters for key size and number of rounds, but AES does not. - Bill From owner-ipsec@lists.tislabs.com Tue Mar 12 10:44:26 2002 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 g2CIiP419050; Tue, 12 Mar 2002 10:44:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17598 Tue, 12 Mar 2002 12:55:25 -0500 (EST) From: "Khaja E. Ahmed" To: "Mark Winstead" , Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 10:05:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C1C9AD.7D6068C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E5D0DC7@MAIL.NetOctave.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C1C9AD.7D6068C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Remove SHOULD for elliptic curve groups in IKEv2Mark, Although AES and EC might both be used in a small percentage of installations, the rates of adoption are quite different. AES is growing and becoming adopted markedly faster than EC, which has been around longer and never saw this rate of adoption. There are other difference, one is royalty free the other involves license fees. Also, AES is the US government's upgrade / replacement for DES and we can predict will be nearly universally used in that segment of the market for sensitive but unclassified information applications. Equal deployment at this moment in time (if that is the case) is not a good reason to make EC support a SHOULD. Anything beyond MAY is not appropriate for EC (IMO). Khaja -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mark Winstead Sent: Tuesday, March 12, 2002 5:40 AM To: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES? With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63) > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Monday, March 11, 2002 11:09 PM > To: ipsec@lists.tislabs.com > Subject: Remove SHOULD for elliptic curve groups in IKEv2 > > > Elliptic curve groups have barely been tested for interoperability. > The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As > wonderful as EC cryptography is supposed to be, it is overkill to > make it a near-requirement when probably fewer than 10% of > implementations today use it. > > --Paul Hoffman, Director > --VPN Consortium > ------=_NextPart_000_005B_01C1C9AD.7D6068C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Remove SHOULD for elliptic curve groups in = IKEv2
Mark,
 
Although AES and EC might both be used in a small percentage of = installations, the rates of adoption are quite different.  AES is = growing=20 and becoming adopted markedly faster than EC, which has been around = longer and=20 never saw this rate of adoption.  There are other difference, = one is=20 royalty free the other involves license fees.  Also, AES = is the US=20 government's upgrade / replacement for DES and we can predict will = be=20 nearly universally used in that segment of the market for sensitive but=20 unclassified information applications.  Equal deployment at this = moment in=20 time (if that is the case) is not a good reason to make EC support a=20 SHOULD.  Anything beyond MAY is not appropriate for EC=20 (IMO).
 
Khaja
-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of Mark Winstead
Sent: Tuesday, March 12, 2002 = 5:40=20 AM
To: ipsec@lists.tislabs.com
Subject: RE: Remove = SHOULD=20 for elliptic curve groups in IKEv2

Today it is fewer than 10%, but can't something = close to that=20 be said, at least recently, for AES?

With AES and its increased key sizes coming, = shouldn't more EC=20 groups be included? some with SHOULD for support of AES various key = sizes and=20 some additional MAYs? I believe consideration should be given to = adding SECG's=20 sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, = ansit283r1),=20 sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 = (13th,=20 ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps = secp256r1=20 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See = http://www.secg.org/coll= ateral/sec2.pdf=20 or ANSI 9.63)

> -----Original Message-----
>=20 From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]=20
> Sent: Monday, March 11, 2002 11:09 PM =
> To: ipsec@lists.tislabs.com

> Subject:=20 Remove SHOULD for elliptic curve groups in IKEv2
>=20
>
> Elliptic = curve=20 groups have barely been tested for interoperability.
> The SHOULDs in section 8.3 and 8.4 should be reduced to = MAYs. As=20

> wonderful as EC cryptography is = supposed to be,=20 it is overkill to
> make it a = near-requirement when=20 probably fewer than 10% of
> = implementations today=20 use it.
>
> = --Paul=20 Hoffman, Director
> --VPN = Consortium=20
>

------=_NextPart_000_005B_01C1C9AD.7D6068C0-- From owner-ipsec@lists.tislabs.com Tue Mar 12 10:51:33 2002 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 g2CIpX419386; Tue, 12 Mar 2002 10:51:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17749 Tue, 12 Mar 2002 13:15:07 -0500 (EST) Date: Tue, 12 Mar 2002 13:26:10 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 In-Reply-To: <000901c1c9ec$e20bbf10$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 12 Mar 2002 andrew.krywaniuk@alcatel.com wrote: > The valid reason for ignoring them is that the patent owners seem unwilling > to disclose exactly what they own. Patents (although not patent applications) are public information, so there should be no question about this, aside from the need to find the relevant patents and interpret the often-obscure verbiage. Of course, it's helpful if the owners are willing to discuss the details. > > In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG > > has been particularly bad at this, with the TIGER example being an > > excellent example. > > But are the SHOULDs supposed to reflect the current reality or the > anticipated reality of when the protocol advances to draft standard? A valid point, but some judgement is called for -- there is a difference between reasonable anticipation and wishful thinking. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 12 10:52:17 2002 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 g2CIqH419490; Tue, 12 Mar 2002 10:52:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17743 Tue, 12 Mar 2002 13:14:31 -0500 (EST) Message-Id: <200203121824.g2CIO3G01945@fatty.lounge.org> To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Your message of "Wed, 06 Mar 2002 16:59:47 PST." <200203070059.g270xlN87810@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1942.1015957443.1@tibernian.com> Date: Tue, 12 Mar 2002 10:24:03 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I respectfully disagree with statement "both protocols are resistant to DoS attacks based on computational loading." Because JFK does not bind the authenticator blob to the initiator it is susceptible to a varient of Simpson's "cookie jar" attack. IKEv2 is not because its "stateless cookie" is bound to the initiator. It would be trivial to fix this problem but I guess the authors do not intend on fixing it since I first brought it up during the SLC IETF with the -00.txt version of JFK and it was not fixed in the -01.txt version. This is a significant difference between the two. Dan. On Wed, 06 Mar 2002 16:59:47 PST you wrote > > DoS PROTECTION and COOKIE EXCHANGE > IKEv2 uses a variable-round-trip handshake, with 4 messages > under normal circumstances and 6 under attack. The extra > two messages are a simple cookie exchange designed to force > the attacker to prove that he has a round-trip to the responsder. > > JFK uses 4 messages in all cases. DoS protection is achieved by > not creating JFK state until message 3 has been read. > > Discussion: > Both protocols are resistant to DoS attacks based on computational > loading. JFK is slightly more network efficient under attack because > it has two fewer messages. However, it is more susceptible to an IP > fragmentation memory consumption attack where the attacker sends a > series of partial messages to consume reassembly buffers, thus > blocking delivery of legitimate fragmented message 3s. If one assumes > a rather intimate relationship between IKEv2 and the TCP stack, IKEv2 > is less susceptible to this attack. From owner-ipsec@lists.tislabs.com Tue Mar 12 10:53:17 2002 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 g2CIrG419658; Tue, 12 Mar 2002 10:53:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17737 Tue, 12 Mar 2002 13:14:23 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0DCC@MAIL.NetOctave.com> From: Mark Winstead To: "'Paul Hoffman / VPNC'" , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Tue, 12 Mar 2002 13:25:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9F3.56ABCC60" 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_01C1C9F3.56ABCC60 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Tuesday, March 12, 2002 11:01 AM > To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com > Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > > > > In the IETF, SHOULDs are supposed to reflect reality. Exactly, the reality. The reality is that to implement AES at full strength, the most credible argument's I have seen suggest better than 3K bits using "classical" MODP for 128 bit key, better than 8K bits for 192, and better than 15K for 256 bits. (I know, one doesn't have to use full equivalent strength key generation, still should key generation be that much weaker?). The reality. The reality is the need for speed is increasing while the need for larger primes for RSA and MODP are increasing. The case was made a few months back in this group that hardware acceleration is reaching its limits in terms of bit size. At the same time, devices with severly limited memory sizes are being put out by commercial interests and some of these need to operate in a secure environment. So, an alternative is needed. I hear objections that ECC doesn't have a bunch of implementations, so it can't be readily acceptable. But one more reality: The reality. The reality is that alternatives to RSA and MODP discrete logs are hard and costly to implement. At least most interests don't want to commit the resources to ECC if the standards aren't there, and now the standards bodies don't want to commit if the implementations aren't there. If not ECC, what? ------_=_NextPart_001_01C1C9F3.56ABCC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Remove SHOULD for elliptic curve groups in IKEv2

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]<= /FONT>
> Sent: Tuesday, March 12, 2002 11:01 AM
> To: andrew.krywaniuk@alcatel.com; = ipsec@lists.tislabs.com
> Subject: RE: Remove SHOULD for elliptic curve = groups in IKEv2
>
>
>
> In the IETF, SHOULDs are supposed to reflect = reality.

Exactly, the reality. The reality is that to = implement AES at full strength, the most credible argument's I have = seen suggest better than 3K bits using "classical" MODP for = 128 bit key, better than 8K bits for 192, and better than 15K for 256 = bits. (I know, one doesn't have to use full equivalent strength key = generation, still should key generation be that much = weaker?).

The reality. The reality is the need for speed is = increasing while the need for larger primes for RSA and MODP are = increasing. The case was made a few months back in this group that = hardware acceleration is reaching its limits in terms of bit size. At = the same time, devices with severly limited memory sizes are being put = out by commercial interests and some of these need to operate in a = secure environment.

So, an alternative is needed. I hear objections that = ECC doesn't have a bunch of implementations, so it can't be readily = acceptable. But one more reality:

The reality. The reality is that alternatives to RSA = and MODP discrete logs are hard and costly to implement. At least most = interests don't want to commit the resources to ECC if the standards = aren't there, and now the standards bodies don't want to commit if the = implementations aren't there.

If not ECC, what?



------_=_NextPart_001_01C1C9F3.56ABCC60-- From owner-ipsec@lists.tislabs.com Tue Mar 12 11:10:01 2002 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 g2CJA0420951; Tue, 12 Mar 2002 11:10:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17832 Tue, 12 Mar 2002 13:30:18 -0500 (EST) To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK References: <200203121824.g2CIO3G01945@fatty.lounge.org> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Mar 2002 10:42:05 -0800 In-Reply-To: Dan Harkins's message of "Tue, 12 Mar 2002 10:24:03 -0800" Message-ID: Lines: 66 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > I respectfully disagree with statement "both protocols are resistant > to DoS attacks based on computational loading." Because JFK does not > bind the authenticator blob to the initiator it is susceptible to a > varient of Simpson's "cookie jar" attack. IKEv2 is not because its > "stateless cookie" is bound to the initiator. > > It would be trivial to fix this problem but I guess the authors do > not intend on fixing it since I first brought it up during the SLC IETF > with the -00.txt version of JFK and it was not fixed in the -01.txt > version. > > This is a significant difference between the two. Dan, I want to apologize to you for not getting back to you earlier. You sent me this comment in private e-mail. I didn't respond immediately because I wanted to take the time to digest it, but then I just got swamped. That said, I'm not sure that I agree with your assessment of this problem. Recall that JFK requires the responder to cache message 4s and simply replay them in response to duplicate message 3s. In an exchange on or around Dec 3, Angelos and I had the following exchange (>> is me and > is Angelos). >> >> The Responder keeps a copy of recently-received Message (3)'s, and >> their corresponding Message (4). Receiving a duplicate (or >> replayed) Message (3) causes the Responder to simply retransmit the >> corresponding Message (4), without creating new state or invoking IPsec. >> >>This suggests that the cache lookup is performed on the entire message 3. >>E.g. >> >> if(msg4=table_lookup(message3,message3_len)){ >> retransmit(msg4); >> } >> else ... >> >>However, this may open the responder to a DoS attack whereby the >>attacker replays copies of message 3 with different encrypted blocks >>(i.e. garbage). The attacker can thereby force a cache miss and force >>the responder to repeatedly compute g^ir while attempting to process >>these messages. This entails no particular computational burden on >>the attacker. >> >>The easiest fix for this is for the responder to use only the >>authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key. >Yes -- sorry, I suppose that wasn't clear in the text; the intent was to >have the authenticator be the key. It seems to me that your attack is isomorphic to the attack I'm describing and the fix is the same: use the authenticator as the cache lookup key. Actually, now that I think of it, it seems like my attack is possible against IKEv2 as well. Doesn't IKEv2 need a similar cache? -Ekr From owner-ipsec@lists.tislabs.com Tue Mar 12 11:22:46 2002 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 g2CJMj422118; Tue, 12 Mar 2002 11:22:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17907 Tue, 12 Mar 2002 13:42:24 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0DCD@MAIL.NetOctave.com> From: Mark Winstead To: "'Sandy Harris'" Cc: ipsec@lists.tislabs.com Subject: RE: How to pass AES rounds number through PF_KEY interface Date: Tue, 12 Mar 2002 13:53:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9F7.421B1220" 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_01C1C9F7.421B1220 Content-Type: text/plain; charset="iso-8859-1" Sandy, You are correct. In the final AES FIPS, rounds are not negotiable -- they depend strictly on key size. And you remembered the round counts correctly. > -----Original Message----- > From: Sandy Harris [mailto:sandy@storm.ca] > Sent: Tuesday, March 12, 2002 3:39 PM > Cc: ipsec@lists.tislabs.com > Subject: Re: How to pass AES rounds number through PF_KEY interface > > > Andrew Wenlang Zhu wrote: > > > Since the AES rounds number MAY be negotiated according to the > > Internet Draft <> > > , > > If so, methinks the draft should change. In the original Rijndael > spec, and I presume in the final AES, the number of rounds depends > on key (and, for original Rijndael, block) size, but does not vary > other than that. > > There should never be a need to negotiate or set number of rounds. > Set the key size (for AES, block size is fixed at 128) and the > number of rounds is determined. > > I think it's 10, 12, 14 for 128, 192, 256, but I haven't got the > spec to hand and am not entirely certain. > > > I need to find a way to pass the rounds number from IKE to kernel > > to install the SA. Unfortunately, I can not > > find a pre-defined parameter to transfer this number. > > > > How do you transfer the AES rounds number in PF_KEY? > ------_=_NextPart_001_01C1C9F7.421B1220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: How to pass AES rounds number through PF_KEY = interface

Sandy,

You are correct. In the final AES FIPS, rounds are = not negotiable -- they depend strictly on key size. And you remembered = the round counts correctly.



> -----Original Message-----
> From: Sandy Harris [mailto:sandy@storm.ca]
> Sent: Tuesday, March 12, 2002 3:39 PM
> Cc: ipsec@lists.tislabs.com
> Subject: Re: How to pass AES rounds number = through PF_KEY interface
>
>
> Andrew Wenlang Zhu wrote:
>
> > Since the AES rounds number MAY be = negotiated according to the
> > Internet Draft <<The AES Cipher = Algorithm and Its Use With IPsec>>
> > = <draft-ietf-ipsec-cipher-aes-cbc-03.txt>,
>
> If so, methinks the draft should change. In the = original Rijndael
> spec, and I presume in the final AES, the = number of rounds depends
> on key (and, for original Rijndael, block) = size, but does not vary
> other than that.
>
> There should never be a need to negotiate or = set number of rounds.
> Set the key size (for AES, block size is fixed = at 128) and the
> number of rounds is determined.
>
> I think it's 10, 12, 14 for 128, 192, 256, but = I haven't got the
> spec to hand and am not entirely certain. =
>
> > I need to find a way to pass the rounds = number from IKE to kernel
> > to install the SA. Unfortunately, I can = not
> > find a pre-defined parameter to transfer = this number.
> >
> > How do you transfer the AES rounds number = in PF_KEY?
>

------_=_NextPart_001_01C1C9F7.421B1220-- From owner-ipsec@lists.tislabs.com Tue Mar 12 12:08:03 2002 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 g2CK82424236; Tue, 12 Mar 2002 12:08:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18162 Tue, 12 Mar 2002 14:26:27 -0500 (EST) From: "Andrew Wenlang Zhu" Cc: Subject: RE: How to pass AES rounds number through PF_KEY interface Date: Tue, 12 Mar 2002 11:37:34 -0800 Message-ID: <001101c1c9fd$5ccb22d0$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C8E6775.747EBA85@storm.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In <> of section 2.5. it reads "Rounds: This variable determines how many times a block is encrypted. While this variable MAY be negotiated, a default value MUST always exist when it is not negotiated. Within IPsec, the AES MUST support 10 rounds, corresponding to the mandatory 128-bit keysize. The AES's default number of rounds is 12 for a 192-bit keysize and 14 for a 256-bit keysize." The Draft do have a default rounds number for each key size. I suggest to get rid of the "MAY" for the Rounds number negotiation because there is no significant benefit in changing rounds number. -- Andrew Zhu >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sandy Harris >Sent: Tuesday, March 12, 2002 12:39 PM >Cc: ipsec@lists.tislabs.com >Subject: Re: How to pass AES rounds number through PF_KEY interface > > >Andrew Wenlang Zhu wrote: > >> Since the AES rounds number MAY be negotiated according to the >> Internet Draft <> >> , > >If so, methinks the draft should change. In the original Rijndael >spec, and I presume in the final AES, the number of rounds depends >on key (and, for original Rijndael, block) size, but does not vary >other than that. > >There should never be a need to negotiate or set number of rounds. >Set the key size (for AES, block size is fixed at 128) and the >number of rounds is determined. > >I think it's 10, 12, 14 for 128, 192, 256, but I haven't got the >spec to hand and am not entirely certain. > >> I need to find a way to pass the rounds number from IKE to kernel >> to install the SA. Unfortunately, I can not >> find a pre-defined parameter to transfer this number. >> >> How do you transfer the AES rounds number in PF_KEY? > From owner-ipsec@lists.tislabs.com Tue Mar 12 12:14:09 2002 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 g2CKE9424572; Tue, 12 Mar 2002 12:14:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18190 Tue, 12 Mar 2002 14:35:01 -0500 (EST) Message-ID: <3C8E5A8F.3000103@alum.mit.edu> Date: Tue, 12 Mar 2002 12:44:16 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <000901c1c9ec$e20bbf10$1e72788a@ca.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk andrew.krywaniuk@alcatel.com wrote: >>>3. SHOULD This word, or the adjective "RECOMMENDED", mean >>> >>that there >> >>> may exist valid reasons in particular circumstances to ignore a >>> particular item, but the full implications must be understood and >>> carefully weighed before choosing a different course. >>> > > The valid reason for ignoring them is that the patent owners seem unwilling > to disclose exactly what they own. The implication of ignoring them is that > you won't be able to match the preferred security profile of many(?) other > implementations. On the other hand, there is published work pre-dating any patent owner's claims, actual or rumored. This is sufficient reason for ignoring them. Hilarie From owner-ipsec@lists.tislabs.com Tue Mar 12 12:53:05 2002 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 g2CKr5426046; Tue, 12 Mar 2002 12:53:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18320 Tue, 12 Mar 2002 15:04:41 -0500 (EST) Message-Id: <200203122016.g2CKFwE02208@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com cc: Mark.Winstead@NetOctave.com, Paul Koning Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 In-reply-to: Your message of "Tue, 12 Mar 2002 12:09:36 EST." <15502.13904.724175.124068@pkoning.dev.equallogic.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Mar 2002 15:15:57 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> One data point: Paul> Even before AES was nailed down, there were chip vendors announcing Paul> hardware acceleration support for AES. Paul> On the other hand, years after EC came out, hardware accelerator Paul> support for it is still somewhere between very rare and nonexistent. Paul> I'm inclined to view these data as an indication of the interest level Paul> in EC; it supports Paul Hoffman's suggestion. My understanding is that there are specific patents (less than a decade old) on hardware accelerated EC. I do not recall who owed them, wasn't HiFn or RSA/Verisign though. ] 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 Mar 12 12:53:06 2002 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 g2CKr6426055; Tue, 12 Mar 2002 12:53:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18398 Tue, 12 Mar 2002 15:11:56 -0500 (EST) Message-ID: <3C8E5E1F.4030000@alum.mit.edu> Date: Tue, 12 Mar 2002 12:59:27 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In my previous note about published work on using elliptic curve groups for cryptography, I did not mean to imply that existing patents are invalid. What I meant to say is that the patents do not cover the basic algorithms, nor do they cover all good implementation methods. There is plenty of early published work covering the ideas. It's not nearly as all-encompassing as the RSA or DH patent situation was. Hilarie From owner-ipsec@lists.tislabs.com Tue Mar 12 13:30:30 2002 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 g2CLUT427009; Tue, 12 Mar 2002 13:30:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18606 Tue, 12 Mar 2002 15:47:22 -0500 (EST) Date: Tue, 12 Mar 2002 16:03:24 -0500 (EST) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: "The Purple Streak (Hilarie Orman)" cc: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 In-Reply-To: <3C8E5E1F.4030000@alum.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: "The Purple Streak (Hilarie Orman)" | In my previous note about published work on using elliptic curve | groups for cryptography, I did not mean to imply that existing | patents are invalid. What I meant to say is that the patents do | not cover the basic algorithms, nor do they cover all good | implementation methods. There is plenty of early published | work covering the ideas. It's not nearly as all-encompassing | as the RSA or DH patent situation was. Is there a clear survey of this that one could trust? I've heard several people say that all the good stuff is patented. I am part of the FreeS/WAN team (as are Michael and Henry). I don't make the decisions, but I do think that EC is interesting. I don't imagine that we'd include implementations covered by patents. We might also reject EC due to lack of confidence -- it hasn't yet had the testing of the modp groups. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Tue Mar 12 14:42:26 2002 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 g2CMgP428857; Tue, 12 Mar 2002 14:42:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18926 Tue, 12 Mar 2002 16:53:41 -0500 (EST) To: "The Purple Streak (Hilarie Orman)" Cc: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <3C8E5E1F.4030000@alum.mit.edu> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Mar 2002 14:05:27 -0800 In-Reply-To: "The Purple Streak's message of "Tue, 12 Mar 2002 12:59:27 -0700" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "The Purple Streak (Hilarie Orman)" writes: > In my previous note about published work on using elliptic curve > groups for cryptography, I did not mean to imply that existing > patents are invalid. What I meant to say is that the patents do > not cover the basic algorithms, nor do they cover all good > implementation methods. There is plenty of early published > work covering the ideas. It's not nearly as all-encompassing > as the RSA or DH patent situation was. Nevertheless, a lot of us find the situation very confusing, because there seem to be a lot of patents of various sorts flying around. What I think would be very helpful here would be if someone (you?) wrote a draft describing a single algorithm with: (1) A description of its patent status (hopefully, with some reference to the techniques having been published prior to patents being filed). (2) Some estimate of its security properties (e.g. an estimate of strength.) (3) Some description of (unencumbered) implementation techniques along with performance numbers for those techniques, perhaps with comparisons to RSA. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Tue Mar 12 16:16:56 2002 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 g2D0Gu401060; Tue, 12 Mar 2002 16:16:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19353 Tue, 12 Mar 2002 18:31:47 -0500 (EST) Message-ID: <3C8E91ED.3020104@alum.mit.edu> Date: Tue, 12 Mar 2002 16:40:29 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: EKR CC: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <3C8E5E1F.4030000@alum.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oakley and IKE and draft-orman-public-key-lengths-05 name the algorithms, the strengths, computational scaling, etc. of ECC for Diffie-Hellman key agreement. Mathematically, the algorithm is DH using point addition in elliptic curve groups over GF[2^n]. Specific implementation techniques may be covered by patents, but see, for example, Fast Key Exchange with Elliptic Curve Systems, in Crypto '95, for details and pseudocode of a non-encumbered method. Hilarie ---- Eric Rescorla wrote: > What I think would be very helpful here would be if someone > (you?) wrote a draft describing a single algorithm with: > > (1) A description of its patent status (hopefully, with > some reference to the techniques having been published > prior to patents being filed). > (2) Some estimate of its security properties (e.g. an estimate > of strength.) > (3) Some description of (unencumbered) implementation techniques > along with performance numbers for those techniques, > perhaps with comparisons to RSA. > > -Ekr > > From owner-ipsec@lists.tislabs.com Tue Mar 12 16:35:06 2002 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 g2D0Z5401415; Tue, 12 Mar 2002 16:35:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19484 Tue, 12 Mar 2002 18:56:14 -0500 (EST) To: "The Purple Streak (Hilarie Orman)" Cc: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <3C8E5E1F.4030000@alum.mit.edu> <3C8E91ED.3020104@alum.mit.edu> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Mar 2002 16:08:00 -0800 In-Reply-To: "The Purple Streak's message of "Tue, 12 Mar 2002 16:40:29 -0700" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "The Purple Streak (Hilarie Orman)" writes: > Oakley and IKE and draft-orman-public-key-lengths-05 name the > algorithms, the strengths, computational scaling, etc. of > ECC for Diffie-Hellman key agreement. Mathematically, > the algorithm is DH using point addition in elliptic curve groups over > GF[2^n]. > > Specific implementation techniques may be covered by patents, but > see, for example, Fast Key Exchange with Elliptic Curve Systems, > in Crypto '95, for details and pseudocode of a non-encumbered method. What I had in mind here, was a draft that collect all of this information in one place so that it could inform this sort of dicussion. The particular paper you refer to, while interesting, unfortunately, is a little difficult to draw direct conclusions from: (1) It doesn't describe the technique you use for performing the DH key agremement you're comparing to. (2) The timings you describe are on such outdated platforms (granted, they weren't outdated at the time) that it's very difficult to compare them with implementations on modern platforms. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Tue Mar 12 17:30:30 2002 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 g2D1UU402650; Tue, 12 Mar 2002 17:30:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19734 Tue, 12 Mar 2002 19:49:13 -0500 (EST) Message-ID: <3C8EA404.8010808@alum.mit.edu> Date: Tue, 12 Mar 2002 17:57:40 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: EKR CC: IP Security List Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <3C8E5E1F.4030000@alum.mit.edu> <3C8E91ED.3020104@alum.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla wrote: > The particular paper you refer to, while interesting, unfortunately, > is a little difficult to draw direct conclusions from: > > (1) It doesn't describe the technique you use for performing > the DH key agremement you're comparing to. It's compared to doing modular exponentiation, i.e., g^x mod p, using apples-to-apples on all implementation aspects outside the core operation. E.g. the exponentiation table precomputation, was the same in base cases. > (2) The timings you describe are on such outdated platforms > (granted, they weren't outdated at the time) that it's very > difficult to compare them with implementations on modern > platforms. Use the ratio of the cycle speeds for a rough measure. It depends on little more than the time to do a multiply. And the time to multiply bignums depends roughly on the square of their lengths. That's why EC makes so much sense as the security requirement increases - the modulus length increases linearly, while modexp increases cubically. The numbers in the '95 paper were near the breakeven point and were trying to match DES security. Today, you need more strength, and EC makes more and more sense, at least in the computational sense of sense. Hilarie From owner-ipsec@lists.tislabs.com Tue Mar 12 17:42:24 2002 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 g2D1gO402900; Tue, 12 Mar 2002 17:42:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19814 Tue, 12 Mar 2002 20:03:45 -0500 (EST) Message-Id: <200203130113.g2D1D9D00446@fatty.lounge.org> To: EKR Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Your message of "12 Mar 2002 10:42:05 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <443.1015981989.1@tibernian.com> Date: Tue, 12 Mar 2002 17:13:09 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 12 Mar 2002 10:42:05 PST you wrote > > That said, I'm not sure that I agree with your assessment of > this problem. Recall that JFK requires the responder to > cache message 4s and simply replay them in response to duplicate > message 3s. But they are not duplicate message 3s. They all have different Ni,g^i pairs and therefore different authenticator blobs. All the Ni,g^i pairs are different, and garbage. I even pointed out that it is not necessary to retain all the Ni,g^i pairs generated as bogus message 1s in order to construct the correct (and unique!) message 3s with the correct Ni,g^i pairs accompanying the authenticator blob that is bound to them. All the message 3s are bogus, all contain unique Ni,g^i pairs and authenticator blobs, all are sent from random IP addresses, and the JFK implementation must exponentiate for each one of them. Caching authenticator blobs and blacklisting the naughty ones will not stop this attack. > In an exchange on or around Dec 3, Angelos and I had the > following exchange (>> is me and > is Angelos). > > >> > >> The Responder keeps a copy of recently-received Message (3)'s, and > >> their corresponding Message (4). Receiving a duplicate (or > >> replayed) Message (3) causes the Responder to simply retransmit the > >> corresponding Message (4), without creating new state or invoking IPsec >. > >> > >>This suggests that the cache lookup is performed on the entire message 3. > >>E.g. > >> > >> if(msg4=table_lookup(message3,message3_len)){ > >> retransmit(msg4); > >> } > >> else ... > >> > >>However, this may open the responder to a DoS attack whereby the > >>attacker replays copies of message 3 with different encrypted blocks > >>(i.e. garbage). The attacker can thereby force a cache miss and force > >>the responder to repeatedly compute g^ir while attempting to process > >>these messages. This entails no particular computational burden on > >>the attacker. > >> > >>The easiest fix for this is for the responder to use only the > >>authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key. > > >Yes -- sorry, I suppose that wasn't clear in the text; the intent was to > >have the authenticator be the key. > > It seems to me that your attack is isomorphic to the attack I'm > describing and the fix is the same: use the authenticator as > the cache lookup key. No because all the authentictors are different for these message 3s that are being flooded to the JFK implementation from random IP addresses. The fix is to include the initiator's IP address in the authenticator blob calculations. > Actually, now that I think of it, it seems like my attack is > possible against IKEv2 as well. Doesn't IKEv2 need a similar > cache? Yes, an IKEv2 implementation should maintain a blacklist or cache of bad "stateless cookies" it has received so as to not continue to exponentiate when it is received again. I think it would be prudent to blacklist IP addresses as well once the attack is discovered. But the attack I described against JFK is not possible against IKEv2. In addition, it is possible to infer the rough location of the attacker with IKEv2. The "stateless cookie" must be returned from the same IP address to which it was sent and if it is not the message will be thrown away without any serious computational burden. If it is returned from the same IP address and the attack is detected (and the cookie is blacklisted) that IP address can be noted. The location of the attacker has been narrowed. With JFK you have no idea. Dan. From owner-ipsec@lists.tislabs.com Tue Mar 12 17:46:09 2002 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 g2D1k9403015; Tue, 12 Mar 2002 17:46:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19931 Tue, 12 Mar 2002 20:12:53 -0500 (EST) To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK References: <200203130113.g2D1D9D00446@fatty.lounge.org> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Mar 2002 17:24:38 -0800 In-Reply-To: Dan Harkins's message of "Tue, 12 Mar 2002 17:13:09 -0800" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > Caching authenticator blobs and blacklisting the naughty ones will not > stop this attack. Right, I see your point. I'd forgotten about the cookie pre-fetch phase. I agree that this attack exists with JFK and not with IKEv2. I'm not sure how serious it really is, but it seems like it would be easy to stop. JFK guys, do you have some reason not to include the initiators IP in the authenticator? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Mar 13 05:16:08 2002 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 g2DDG7425607; Wed, 13 Mar 2002 05:16:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA24546 Wed, 13 Mar 2002 07:15:04 -0500 (EST) Message-ID: From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Wed, 13 Mar 2002 12:27:01 -0000 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 Certicom have been very active in this area. They have a document stating their patents/applications: http://www.secg.org/collateral/certicom_secg_patent.pdf This is better than what they used to say which was along the lines of "we have patents in this area that you might infringe but if you buy a licence from us you'll be ok". Their earliest patent listed above was in 1988 and covers multiplication using base-normal form. There are other patents (by others) covering multiplication with normal basis representation. I did a (general) patent search on "Elliptic Curve" and "Cryptography" and that came up with 114 patents in the last 6 years. Quite apart from various acceleration patents, a number of signature methods are also covered. Again, I am not experienced in interpreting patents either. Chris -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: 12 March 2002 20:16 To: ipsec@lists.tislabs.com Cc: Mark.Winstead@NetOctave.com; Paul Koning Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 >>>>> "Paul" == Paul Koning writes: Paul> One data point: Paul> Even before AES was nailed down, there were chip vendors announcing Paul> hardware acceleration support for AES. Paul> On the other hand, years after EC came out, hardware accelerator Paul> support for it is still somewhere between very rare and nonexistent. Paul> I'm inclined to view these data as an indication of the interest level Paul> in EC; it supports Paul Hoffman's suggestion. My understanding is that there are specific patents (less than a decade old) on hardware accelerated EC. I do not recall who owed them, wasn't HiFn or RSA/Verisign though. ] 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"); [ This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Mar 13 06:33:34 2002 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 g2DEXX401292; Wed, 13 Mar 2002 06:33:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25089 Wed, 13 Mar 2002 08:41:43 -0500 (EST) Date: Tue, 12 Mar 2002 20:40:41 -0500 (EST) From: "Angelos D. Keromytis" Message-Id: <200203130140.g2D1ef1h020911@dynamo.cs.columbia.edu> To: dharkins@tibernian.com, ekr@rtfm.com, ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The reason the IP was not included in the cookie computation is, quite simply, because I forgot to do that right after the meeting. You may recall that I agreed with Dan during my presentation, when he raised the point. I'll just point out that this doesn't affect the security of the protocol --- one could even view this as an implementation-specific choice. -Angelos PS. There's an architectural-uncleanness argument one could make against including network-layer identifiers in a higher-layer protocol; but I think that in the realm of DDoS protection, one has to resort to measures like this. From owner-ipsec@lists.tislabs.com Wed Mar 13 07:54:23 2002 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 g2DFsM405666; Wed, 13 Mar 2002 07:54:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25876 Wed, 13 Mar 2002 10:03:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15503.27889.921468.23416@pkoning.dev.equallogic.com> Date: Wed, 13 Mar 2002 10:14:57 -0500 From: Paul Koning To: ekr@rtfm.com Cc: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <3C8E5E1F.4030000@alum.mit.edu> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Eric" == Eric Rescorla writes: Eric> What I think would be very helpful here would be if someone Eric> (you?) wrote a draft describing a single algorithm with: Eric> (1) A description of its patent status (hopefully, with some Eric> reference to the techniques having been published prior to Eric> patents being filed). (2) Some estimate of its security Eric> properties (e.g. an estimate of strength.) (3) Some Eric> description of (unencumbered) implementation techniques along Eric> with performance numbers for those techniques, perhaps with Eric> comparisons to RSA. Yes, such a thing would be useful. Unfortunately, (1) and (3) involve opinions about patents (their existence, scope, validity, etc.). Since patents are legal documents and those questions are legal questions, any writings about (1) and (3) by engineers or mathematicians should be viewed with extreme scepticism. The reason I say this about (3) is that "unencumbered" is not a property you can easily test. I remember situations where some company at some point years after a technique came into use decided that it could use some more revenue, and tried to stretch some of its existing patents to cover new ground. And even if you have a statement from the inventor of X that he/she will not be filing for any patents on X (as is true for Rijndael), such a statement isn't an absolute guarantee that there won't be patent claims against X from third parties -- now, or perhaps quite a while later -- who say that their patent has claims that cover implementations of X... paul From owner-ipsec@lists.tislabs.com Wed Mar 13 09:43:40 2002 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 g2DHhe412292; Wed, 13 Mar 2002 09:43:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26629 Wed, 13 Mar 2002 11:48:16 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699EF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Henry Spencer'" , IP Security List Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Wed, 13 Mar 2002 09:00:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CAB0.8ADB7EA0" 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_000_01C1CAB0.8ADB7EA0 Content-Type: text/plain; charset="iso-8859-1" > On Tue, 12 Mar 2002 andrew.krywaniuk@alcatel.com wrote: > > The valid reason for ignoring them is that the patent > owners seem unwilling > > to disclose exactly what they own. > > Patents (although not patent applications) are public information, so > there should be no question about this, aside from the need > to find the > relevant patents and interpret the often-obscure verbiage. Of course, > it's helpful if the owners are willing to discuss the details. Patent applications are not public information. I may (or may not) have filled a submarine patent on any of the technology involved in any specification and just not tell you. I don't even have to do any inventing, I could just perjure myself to the patent office then wait till your startup files an IPO and file a lawsuit a couple of days before the launch, unless of course you give me a couple hundred thousand shares. Unfortunately for you, you could not do that without risking violating a patent application that I might have filed. Another risk for academics who file patents on my work is that my current policy is to consider any patent claim that covers work that I have performed previously without reference to my prior art to be a prima-facie case of plagarism and make the appropriate complaint to their university. Alledged owners of alledged patents have on numerous occasions made claims to technologies that are not covered by a patent. We can all remember the famous statement by Jim Bizdos concerning the claim that the Stanford DH patent covered RSA. Phill ------_=_NextPart_000_01C1CAB0.8ADB7EA0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CAB0.8ADB7EA0-- From owner-ipsec@lists.tislabs.com Wed Mar 13 09:46:21 2002 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 g2DHkL412430; Wed, 13 Mar 2002 09:46:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26638 Wed, 13 Mar 2002 11:51:34 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699F0@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'EKR'" , Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Choosing between IKEv2 and JFK Date: Wed, 13 Mar 2002 09:04:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CAB1.1707E4E0" 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_000_01C1CAB1.1707E4E0 Content-Type: text/plain; charset="iso-8859-1" > Dan Harkins writes: > > Caching authenticator blobs and blacklisting the naughty > ones will not > > stop this attack. > Right, I see your point. I'd forgotten about the cookie pre-fetch > phase. > > I agree that this attack exists with JFK and not with IKEv2. I'm not > sure how serious it really is, but it seems like it would be easy to > stop. JFK guys, do you have some reason not to include the initiators > IP in the authenticator? Like including it would destroy NAT interop? If the packet goes through a NAT the initiator does not know the IP address that the packets it sends will have when they arrive. Phill ------_=_NextPart_000_01C1CAB1.1707E4E0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CAB1.1707E4E0-- From owner-ipsec@lists.tislabs.com Wed Mar 13 10:19:11 2002 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 g2DIJB413647; Wed, 13 Mar 2002 10:19:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26918 Wed, 13 Mar 2002 12:35:43 -0500 (EST) Message-Id: <200203131744.g2DHifB00584@fatty.lounge.org> To: "Hallam-Baker, Phillip" Cc: "'EKR'" , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Your message of "Wed, 13 Mar 2002 09:04:08 PST." <2F3EC696EAEED311BB2D009027C3F4F4058699F0@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <581.1016041481.1@tibernian.com> Date: Wed, 13 Mar 2002 09:44:41 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why does the initiator need to know whether his IP address changed? He's getting back an opaque blob which is solely for the responder's use. How that blob was derived is not important to him. He doesn't know HKr either. If a NAT box is between the two parties then the address included in the authenticator blob calculations will be that of the NAT box. This will not "destroy NAT interop." Dan. On Wed, 13 Mar 2002 09:04:08 PST you wrote > > Dan Harkins writes: > > > Caching authenticator blobs and blacklisting the naughty > > ones will not > > > stop this attack. > > Right, I see your point. I'd forgotten about the cookie pre-fetch > > phase. > > > > I agree that this attack exists with JFK and not with IKEv2. I'm not > > sure how serious it really is, but it seems like it would be easy to > > stop. JFK guys, do you have some reason not to include the initiators > > IP in the authenticator? > > Like including it would destroy NAT interop? > > If the packet goes through a NAT the initiator does not know the IP > address that the packets it sends will have when they arrive. > > Phill > From owner-ipsec@lists.tislabs.com Wed Mar 13 10:22:48 2002 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 g2DIMm413810; Wed, 13 Mar 2002 10:22:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26948 Wed, 13 Mar 2002 12:38:17 -0500 (EST) Message-Id: <200203131748.g2DHmngw021839@thunk.East.Sun.COM> From: Bill Sommerfeld To: "Hallam-Baker, Phillip" cc: "'EKR'" , Dan Harkins , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Your message of "Wed, 13 Mar 2002 09:04:08 PST." <2F3EC696EAEED311BB2D009027C3F4F4058699F0@vhqpostal.verisign.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 12:48:48 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If the packet goes through a NAT the initiator does not know the IP > address that the packets it sends will have when they arrive. but the initiator doesn't compute that hash, the responder does -- and it would use the address as seen at the responder, post-NAT. From owner-ipsec@lists.tislabs.com Wed Mar 13 11:39:21 2002 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 g2DJdK418152; Wed, 13 Mar 2002 11:39:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27523 Wed, 13 Mar 2002 13:48:22 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699F1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'sommerfeld@east.sun.com'" , "Hallam-Baker, Phillip" Cc: "'EKR'" , Dan Harkins , ipsec@lists.tislabs.com Subject: RE: Choosing between IKEv2 and JFK Date: Wed, 13 Mar 2002 11:00:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CAC1.635183F0" 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_000_01C1CAC1.635183F0 Content-Type: text/plain; charset="iso-8859-1" Ahh yes, good point... In which case why does the spec need to make any statements about the structure of the blob? if it is opaque to every party except itself what interop requirement can exist? Wouldn't it be best to leave that part of the spec blank allowing implementations to add whatever measures were most useful to them in their particular DoS strategy? Another advantage of this approach is that the less clever stuff we mandate the less risk there is of a patent troll. Don't start with the 'prior art' business, even with prior art it can cost $2 million to fight off a suit. The only case in which prior art is useful is if the patent troll makes a parallel European application and someone notices in time to dump the prior art on them. I think that we should consider patent troll attacks at least as seriously as DoS attacks. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, March 13, 2002 12:49 PM > To: Hallam-Baker, Phillip > Cc: 'EKR'; Dan Harkins; ipsec@lists.tislabs.com > Subject: Re: Choosing between IKEv2 and JFK > > > > If the packet goes through a NAT the initiator does not know the IP > > address that the packets it sends will have when they arrive. > > but the initiator doesn't compute that hash, the responder does -- and > it would use the address as seen at the responder, post-NAT. > ------_=_NextPart_000_01C1CAC1.635183F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CAC1.635183F0-- From owner-ipsec@lists.tislabs.com Wed Mar 13 11:57:15 2002 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 g2DJvF418567; Wed, 13 Mar 2002 11:57:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27630 Wed, 13 Mar 2002 14:11:41 -0500 (EST) Message-Id: <200203131921.g2DJKrr00430@fatty.lounge.org> To: "Hallam-Baker, Phillip" Cc: "'sommerfeld@east.sun.com'" , "'EKR'" , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: Your message of "Wed, 13 Mar 2002 11:00:48 PST." <2F3EC696EAEED311BB2D009027C3F4F4058699F1@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <427.1016047253.1@tibernian.com> Date: Wed, 13 Mar 2002 11:20:53 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It needs to make a statement about the structure of the blob because the protocol is designed to have certain properties and those properties are arrived at by using the blob for certain purposes. A completely opaque blob would only serve as a covert channel. The blob is not "opaque to every party except itself". The blob itself is not a participant in the exchange, there's only an initiator and a responder and the blob is opaque to the initiator not to the responder. A security protocol has to protect itself against DoS attacks. If that entails dictating what goes into the blob then so be it. You can't let fear of patent trolls interfere in engineering good security into a security protocol. Dan. On Wed, 13 Mar 2002 11:00:48 PST you wrote > > Ahh yes, good point... > > In which case why does the spec need to make any statements about the > structure of the blob? if it is opaque to every party except itself what > interop requirement can exist? > > Wouldn't it be best to leave that part of the spec blank allowing > implementations to add whatever measures were most useful to them in their > particular DoS strategy? > > Another advantage of this approach is that the less clever stuff we mandate > the less risk there is of a patent troll. Don't start with the 'prior art' > business, even with prior art it can cost $2 million to fight off a suit. > The only case in which prior art is useful is if the patent troll makes a > parallel European application and someone notices in time to dump the prior > art on them. > > I think that we should consider patent troll attacks at least as seriously > as DoS attacks. > > Phill > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > > Sent: Wednesday, March 13, 2002 12:49 PM > > To: Hallam-Baker, Phillip > > Cc: 'EKR'; Dan Harkins; ipsec@lists.tislabs.com > > Subject: Re: Choosing between IKEv2 and JFK > > > > > > > If the packet goes through a NAT the initiator does not know the IP > > > address that the packets it sends will have when they arrive. > > > > but the initiator doesn't compute that hash, the responder does -- and > > it would use the address as seen at the responder, post-NAT. > > > > > ------_=_NextPart_000_01C1CAC1.635183F0 > Content-Type: application/octet-stream; > name="Phillip Hallam-Baker (E-mail).vcf" > Content-Disposition: attachment; > filename="Phillip Hallam-Baker (E-mail).vcf" > > BEGIN:VCARD > VERSION:2.1 > N:Hallam-Baker;Phillip > FN:Phillip Hallam-Baker (E-mail) > ORG:VeriSign > TITLE:Principal Consultant > TEL;WORK;VOICE:(781) 245-6996 x227 > EMAIL;PREF;INTERNET:hallam@verisign.com > REV:20010214T163732Z > END:VCARD > > ------_=_NextPart_000_01C1CAC1.635183F0-- From owner-ipsec@lists.tislabs.com Wed Mar 13 16:34:23 2002 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 g2E0YN402256; Wed, 13 Mar 2002 16:34:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28812 Wed, 13 Mar 2002 18:37:44 -0500 (EST) Message-ID: <3C8FE569.64245AC8@greendragon.com> Date: Wed, 13 Mar 2002 18:49:35 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: 10 years and no ubiquitous security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 10 years ago this week, we had an IETF meeting in San Diego. 10 years ago on Tuesday, Phil Karn sprawled out across my hotel room bed and drew the packet header that became ESP. (Remember when we were small enough to have hotel room BOFs?) 10 years today, at a lunch meeting, Phil Karn gathered a group of us, and we agreed to pursue IP Security, as "the most important thing missing from the Internet". (Most real work was still done in lunch and dinner BOFs last time I attended IETF, and presumably that tradition continues now.) 10 years ago tomorrow, Brian Lloyd and I had a "rubber hose" lunch meeting with Steve Kent, who as a member of the IAB had refused to allow the PPP WG to publish CHAP in our RFC as an official authentication protocol. (He had previously mandated that we remove all security protocol negotiation.) He backed down, but we had to change the name from "cryptographic" to "challenge". Steve Kent refused to charter the IPSec WG. We had to reform the structure of the IAB (removing Steve Kent) -- which was good for many other reasons, although its efficacy was short-lived. After all these years, ESP itself is remarkably unchanged. (The sequence field is 32 bits instead of 16 bits, but we did that in 1993.) Remember, by 1995 we had multiple interoperable implementations. Roughly 5 years ago, IPSec was supposed to be disbanded, because its work was complete. Instead, somebody named Steve Kent secretly took over the WG editorship (with no consensus, or even WG discussion), and his "appointment" was enforced upon the new "reform" WG Chairs. For 5 more years, IPSec WG has slowly turned out unworkable documents, generating endless and fruitless discussion. Today, IPSec has insignificant deployment, and the WG goeth on forever. ... Should I remind folks that at that same San Diego IETF, JI and Phil and Steve Deering and others of us had a lunch BOF on Mobile-IP? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Wed Mar 13 16:37:09 2002 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 g2E0b9403676; Wed, 13 Mar 2002 16:37:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28904 Wed, 13 Mar 2002 19:02:25 -0500 (EST) Message-ID: <3C8FE999.60605@alum.mit.edu> Date: Wed, 13 Mar 2002 17:06:49 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Elliptic Curve Crypto Info, more than you MAY want to know Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk http://grouper.ieee.org/groups/1363/P1363/letters/Certicom.txt has a number of relevant patents, including hints about pending patents. The most notable for implementators is the one about normal bases. Wei Dai's Crypto++ library has source code for elliptic curves: http://www.eskimo.com/~weidai/cryptlib.html Eric Rosing has written a book on implementing elliptic curve operations: http://www.manning.com/Rosing/ Rosing favors normal bases for implementations, but these are not necessary, see Schroeppel et al., Crypto '95 A good set of links about ECC: http://www.geocities.com/marcjoye/biblio_ell.html#Links A good paper for timings is Software Implementation of Elliptic Curve Cryptography Over Binary Fields Darrel Hankerson, Julio Lopez Hernandez, Alfred Menezes Proceedings of Cryptographic Hardware and Embedded Systems, 2000 This shows timings for a 400 MHz Pentium II using 3 EC's, the smallest one using 163-bit numbers; this corresponds to DH timings using a modulus of about 1400 bits; it would be appropriate for exchanging symmetric keys of about 85 bits. The times for the EC are from 1.6 to 9 msec, depending on various optimizations. Hilarie From owner-ipsec@lists.tislabs.com Thu Mar 14 05:40:42 2002 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 g2EDeg401382; Thu, 14 Mar 2002 05:40:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02230 Thu, 14 Mar 2002 07:53:33 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0DDC@MAIL.NetOctave.com> From: Mark Winstead To: ipsec@lists.tislabs.com Subject: RE: Elliptic Curve Crypto Info, more than you MAY want to know Date: Thu, 14 Mar 2002 08:05:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB58.E0229D50" 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_01C1CB58.E0229D50 Content-Type: text/plain; charset="iso-8859-1" The letter from Certicom is dated from 1998. For an update on patents and details, go to http://patft.uspto.gov/netahtml/search-adv.htm and query on "AN/Certicom". > -----Original Message----- > From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu] > Sent: Wednesday, March 13, 2002 7:07 PM > To: ipsec@lists.tislabs.com > Subject: Elliptic Curve Crypto Info, more than you MAY want to know > > > http://grouper.ieee.org/groups/1363/P1363/letters/Certicom.txt has > a number of relevant patents, including hints about pending patents. > The most notable for implementators is the one about normal bases. > > Wei Dai's Crypto++ library has source code for elliptic curves: > http://www.eskimo.com/~weidai/cryptlib.html > > Eric Rosing has written a book on implementing elliptic curve > operations: http://www.manning.com/Rosing/ > Rosing favors normal bases for implementations, but these > are not necessary, see Schroeppel et al., Crypto '95 > > A good set of links about ECC: > http://www.geocities.com/marcjoye/biblio_ell.html#Links > > A good paper for timings is > Software Implementation of Elliptic Curve Cryptography Over > Binary Fields > Darrel Hankerson, Julio Lopez Hernandez, Alfred Menezes > Proceedings of Cryptographic Hardware and Embedded Systems, 2000 > This shows timings for a 400 MHz Pentium II using 3 EC's, > the smallest one using 163-bit numbers; this corresponds to > DH timings using a modulus of about 1400 bits; it would be > appropriate for exchanging symmetric keys of about 85 bits. > The times for the EC are from 1.6 to 9 msec, depending on > various optimizations. > > Hilarie > ------_=_NextPart_001_01C1CB58.E0229D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Elliptic Curve Crypto Info, more than you MAY want to = know

The letter from Certicom is dated from 1998. For an = update on patents and details, go to http://patft.uspto.gov/netahtml/search-adv.htm

and query on "AN/Certicom".



> -----Original Message-----
> From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu]
> Sent: Wednesday, March 13, 2002 7:07 PM
> To: ipsec@lists.tislabs.com
> Subject: Elliptic Curve Crypto Info, more than = you MAY want to know
>
>
> http://grouper.ieee.org/groups/1363/P1363/letters/Cert= icom.txt has
> a number of relevant patents, including hints = about pending patents.
> The most notable for implementators is the one = about normal bases.
>
> Wei Dai's Crypto++ library has source code for = elliptic curves:
> http://www.eskimo.com/~weidai/cryptlib.html=
>
> Eric Rosing has written a book on implementing = elliptic curve
> operations: http://www.manning.com/Rosing/
> Rosing favors normal bases for implementations, = but these
> are not necessary, see Schroeppel et al., = Crypto '95
>
> A good set of links about ECC:
>   http://www.geocities.com/marcjoye/biblio_ell.html#Link= s
>
> A good paper for timings is
>   Software Implementation of Elliptic = Curve Cryptography Over
>    Binary Fields
>   Darrel Hankerson, Julio Lopez = Hernandez, Alfred Menezes
>   Proceedings of Cryptographic = Hardware and Embedded Systems, 2000
> This shows timings for a 400 MHz Pentium II = using 3 EC's,
> the smallest one using 163-bit numbers; this = corresponds to
> DH timings using a modulus of about 1400 bits; = it would be
> appropriate for exchanging symmetric keys of = about 85 bits.
> The times for the EC are from 1.6 to 9 msec, = depending on
> various optimizations.
>
> Hilarie
>

------_=_NextPart_001_01C1CB58.E0229D50-- From owner-ipsec@lists.tislabs.com Thu Mar 14 05:40:46 2002 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 g2EDej401404; Thu, 14 Mar 2002 05:40:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02263 Thu, 14 Mar 2002 07:54:57 -0500 (EST) Message-ID: <01f901c1cae8$9c774490$0200a8c0@remedy> From: "Andrey Jivsov" To: "Chris Trobridge" , References: Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 Date: Wed, 13 Mar 2002 15:41:34 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 23:43:48.0589 (UTC) FILETIME=[EC20F1D0:01C1CAE8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After playing with one of IKE gateways which implements ECC groups from draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there appear to be no way to interoperate with this box without violating some of patents. The issue here is not a performance, but the fact that IKE implementation must use some of following techniques in order to interpret data in the KE payload or create the same g^xy: 1) point compression, such that only the lowest bit of polynomial representation of x/y is transmitted 2) g^xyc (or xyc * G in EC notation), where c is "cofactor", is used instead of g^xy These techniques are likely to be patented in applications #2 and #5 respectively, listed on the last page of http://www.secg.org/collateral/certicom_secg_patent.pdf: > 2. Methods for point compression. . > 5. Methods to avoid the small subgroup attack. It is possible to avoid patented methods. For 1) there exist more efficient techniques, such as the one proposed by Roger Schlafly on Nov 12 2001 to P1363 mailing list. Similar compression should be made mandatory. For 2) one will use DH without cofactor multiplication (i.e., the shared secret will be exactly g^xy), but use other methods to verify g^x received from the peer. I believe that abovementioned draft should not assume patented formats on the wire and in g^xy, instead it should specify patent-free alternatives. ( This issue has nothing to do with internal representation of EC points or performance. ) ----- Original Message ----- From: "Chris Trobridge" To: Sent: Wednesday, March 13, 2002 4:27 AM Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > Certicom have been very active in this area. > > They have a document stating their patents/applications: > > http://www.secg.org/collateral/certicom_secg_patent.pdf > > This is better than what they used to say which was along the lines of "we > have patents in this area that you might infringe but if you buy a licence > from us you'll be ok". > > Their earliest patent listed above was in 1988 and covers multiplication > using base-normal form. There are other patents (by others) covering > multiplication with normal basis representation. > > I did a (general) patent search on "Elliptic Curve" and "Cryptography" and > that came up with 114 patents in the last 6 years. Quite apart from various > acceleration patents, a number of signature methods are also covered. > > Again, I am not experienced in interpreting patents either. > > Chris > > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: 12 March 2002 20:16 > To: ipsec@lists.tislabs.com > Cc: Mark.Winstead@NetOctave.com; Paul Koning > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > >>>>> "Paul" == Paul Koning writes: > Paul> One data point: > > Paul> Even before AES was nailed down, there were chip vendors > announcing > Paul> hardware acceleration support for AES. > > Paul> On the other hand, years after EC came out, hardware accelerator > Paul> support for it is still somewhere between very rare and > nonexistent. > > Paul> I'm inclined to view these data as an indication of the interest > level > Paul> in EC; it supports Paul Hoffman's suggestion. > > My understanding is that there are specific patents (less than a decade > old) on hardware accelerated EC. I do not recall who owed them, wasn't HiFn > or RSA/Verisign though. > > ] 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 Thu Mar 14 05:40:52 2002 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 g2EDeq401435; Thu, 14 Mar 2002 05:40:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02265 Thu, 14 Mar 2002 07:55:00 -0500 (EST) Cc: "Angelos D. Keromytis" , Jan Vilhuber , ipsec@lists.tislabs.com Message-Id: <200203140026.TAA13816@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Derek Atkins , Michael Thomas Subject: Re: Choosing between IKEv2 and JFK Date: Wed, 13 Mar 2002 19:25:08 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: "Angelos D. Keromytis" , Jan Vilhuber , ipsec@lists.tislabs.com References: <15495.61112.901790.504193@thomasm-u1.cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA29022 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Friday 08 March 2002 10:00, Derek Atkins wrote: > Michael Thomas writes: > > Huh? The certs are only there for identity. > > No, in reality the certs are there for authorization. It's just that > people don'e understand the concept of capabilities, so we have this > ad-hoc "identity" cert and map it via some local lookup method to a > set of capabilities. Conceptually I agree. Practically however, the current PKI (IMHO) offers identity-only (at best). Please correct me if I'm wrong, preferably by citing real-life examples. -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Mar 14 05:41:59 2002 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 g2EDfw401651; Thu, 14 Mar 2002 05:41:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02278 Thu, 14 Mar 2002 07:55:55 -0500 (EST) Message-ID: <030c01c1cb0b$c90129e0$0200a8c0@remedy> From: "Andrey Jivsov" To: "IP Security List" Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 Date: Wed, 13 Mar 2002 19:53:21 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Mar 2002 03:55:35.0061 (UTC) FILETIME=[1849A450:01C1CB0C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After experiments with one of IKE gateways which implements ECC groups from draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there appear to be no way to interoperate with this box without violating some of patents. In order to interoperate with that vendor IKE implementation must use some of following techniques in order to process data in the KE payload or generate the same g^xy: 1) point compression, such that only the lowest bit of polynomial representation of x/y is transmitted 2) xyc * G is used in place of of g^xy, where c is "cofactor" These techniques are likely to be patented in applications #2 and #5 respectively, listed on the last page of http://www.secg.org/collateral/certicom_secg_patent.pdf: > 2. Methods for point compression. ... > 5. Methods to avoid the small subgroup attack. It is possible to avoid patented methods. For 1) there exist more efficient techniques, such as the one proposed by Roger Schlafly on Nov 12 2001 to the P1363 mailing list. Similar compression method should be made mandatory. For 2) one will use DH without cofactor multiplication (i.e., the shared secret will be exactly g^xy) and use other methods to verify g^x received from the peer. It would be beneficial if abovementioned draft had clearly specified patent-free point compression and g^xy. ----- Original Message ----- From: "Chris Trobridge" To: Sent: Wednesday, March 13, 2002 4:27 AM Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > Certicom have been very active in this area. > > They have a document stating their patents/applications: > > http://www.secg.org/collateral/certicom_secg_patent.pdf > > This is better than what they used to say which was along the lines of "we > have patents in this area that you might infringe but if you buy a licence > from us you'll be ok". > > Their earliest patent listed above was in 1988 and covers multiplication > using base-normal form. There are other patents (by others) covering > multiplication with normal basis representation. > > I did a (general) patent search on "Elliptic Curve" and "Cryptography" and > that came up with 114 patents in the last 6 years. Quite apart from various > acceleration patents, a number of signature methods are also covered. > > Again, I am not experienced in interpreting patents either. > > Chris > > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: 12 March 2002 20:16 > To: ipsec@lists.tislabs.com > Cc: Mark.Winstead@NetOctave.com; Paul Koning > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > >>>>> "Paul" == Paul Koning writes: > Paul> One data point: > > Paul> Even before AES was nailed down, there were chip vendors > announcing > Paul> hardware acceleration support for AES. > > Paul> On the other hand, years after EC came out, hardware accelerator > Paul> support for it is still somewhere between very rare and > nonexistent. > > Paul> I'm inclined to view these data as an indication of the interest > level > Paul> in EC; it supports Paul Hoffman's suggestion. > > My understanding is that there are specific patents (less than a decade > old) on hardware accelerated EC. I do not recall who owed them, wasn't HiFn > or RSA/Verisign though. > ... From owner-ipsec@lists.tislabs.com Thu Mar 14 07:24:13 2002 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 g2EFO3408243; Thu, 14 Mar 2002 07:24:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02940 Thu, 14 Mar 2002 09:40:52 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> From: Mark Winstead To: "'Andrey Jivsov'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Thu, 14 Mar 2002 09:52:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB67.DE215140" 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_01C1CB67.DE215140 Content-Type: text/plain; charset="iso-8859-1" That patent statement of Certicom was written in may, 1999. There is one patent granted to Certicom on a mathod to avoid the small subgroup attack in August 1999, but no point compression method or other subgroup attack related one listed on the U.S. government's database (supposedly complete to March 12th 2002). What makes you think that the IKE implementation is using one of Certicom's claimed patent applications? I don't think that lowest order bit of x/y (y/x?) is patentable if it isn't already patented. Hasn't that technique been around since the 80s? > -----Original Message----- > From: Andrey Jivsov [mailto:andrey@brainhub.org] > Sent: Wednesday, March 13, 2002 6:42 PM > To: Chris Trobridge; ipsec@lists.tislabs.com > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > After playing with one of IKE gateways which implements ECC > groups from > draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there > appear to be no > way to interoperate with this box without violating some of patents. > > The issue here is not a performance, but the fact that IKE > implementation > must use some of following techniques in order to interpret > data in the KE > payload or create the same g^xy: > > 1) point compression, such that only the lowest bit of polynomial > representation of x/y is transmitted > 2) g^xyc (or xyc * G in EC notation), where c is > "cofactor", is used > instead of g^xy > > These techniques are likely to be patented in applications #2 and #5 > respectively, listed on the last page of > http://www.secg.org/collateral/certicom_secg_patent.pdf: > > > 2. Methods for point compression. > . > > 5. Methods to avoid the small subgroup attack. > > It is possible to avoid patented methods. > > For 1) there exist more efficient techniques, such as the one > proposed by > Roger Schlafly on Nov 12 2001 to P1363 mailing list. Similar > compression > should be made mandatory. > For 2) one will use DH without cofactor multiplication (i.e., > the shared > secret will be exactly g^xy), but use other methods to verify > g^x received > from the peer. > > I believe that abovementioned draft should not assume > patented formats on > the wire and in g^xy, instead it should specify patent-free > alternatives. > ( This issue has nothing to do with internal representation > of EC points or > performance. ) > > ----- Original Message ----- > From: "Chris Trobridge" > To: > Sent: Wednesday, March 13, 2002 4:27 AM > Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > > > > Certicom have been very active in this area. > > > > They have a document stating their patents/applications: > > > > http://www.secg.org/collateral/certicom_secg_patent.pdf > > > > This is better than what they used to say which was along > the lines of "we > > have patents in this area that you might infringe but if > you buy a licence > > from us you'll be ok". > > > > Their earliest patent listed above was in 1988 and covers > multiplication > > using base-normal form. There are other patents (by > others) covering > > multiplication with normal basis representation. > > > > I did a (general) patent search on "Elliptic Curve" and > "Cryptography" and > > that came up with 114 patents in the last 6 years. Quite > apart from > various > > acceleration patents, a number of signature methods are > also covered. > > > > Again, I am not experienced in interpreting patents either. > > > > Chris > > > > -----Original Message----- > > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > > Sent: 12 March 2002 20:16 > > To: ipsec@lists.tislabs.com > > Cc: Mark.Winstead@NetOctave.com; Paul Koning > > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > > > >>>>> "Paul" == Paul Koning writes: > > Paul> One data point: > > > > Paul> Even before AES was nailed down, there were chip vendors > > announcing > > Paul> hardware acceleration support for AES. > > > > Paul> On the other hand, years after EC came out, > hardware accelerator > > Paul> support for it is still somewhere between very rare and > > nonexistent. > > > > Paul> I'm inclined to view these data as an indication > of the interest > > level > > Paul> in EC; it supports Paul Hoffman's suggestion. > > > > My understanding is that there are specific patents > (less than a decade > > old) on hardware accelerated EC. I do not recall who owed > them, wasn't > HiFn > > or RSA/Verisign though. > > > > ] 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"); > > [ > ... > > ------_=_NextPart_001_01C1CB67.DE215140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Remove SHOULD for elliptic curve groups in IKEv2

That patent statement of Certicom was written in may, = 1999. There is one patent granted to Certicom on a mathod to avoid the = small subgroup attack in August 1999, but no point compression method = or other subgroup attack related one listed on the U.S. government's = database (supposedly complete to March 12th 2002). What makes you think = that the IKE implementation is using one of Certicom's claimed patent = applications?

I don't think that lowest order bit of x/y (y/x?) is = patentable if it isn't already patented. Hasn't that technique been = around since the 80s?



> -----Original Message-----
> From: Andrey Jivsov [mailto:andrey@brainhub.org]
> Sent: Wednesday, March 13, 2002 6:42 PM
> To: Chris Trobridge; = ipsec@lists.tislabs.com
> Subject: Re: Remove SHOULD for elliptic curve = groups in IKEv2
>
>
> After playing with one of IKE gateways which = implements ECC
> groups from
> draft-ietf-ipsec-ike-ecc-groups-03.txt I found = that there
> appear to be no
> way to interoperate with this box without = violating some of patents.
>
> The issue here is not a performance, but the = fact that IKE
> implementation
> must use some of following techniques in order = to interpret
> data in the KE
> payload or create the same g^xy:
>
>      1) point = compression, such that only the lowest bit of polynomial
> representation of x/y is transmitted
>      2) g^xyc (or xyc = * G in EC notation), where c is
> "cofactor", is used
> instead of g^xy
>
> These techniques are likely to be patented in = applications #2 and #5
> respectively, listed on the last page of
> = http://www.secg.org/collateral/certicom_secg_patent.pdf:
>
>      > 2.  = Methods for point compression.
>      .
>      > 5.  = Methods to avoid the small subgroup attack.
>
> It is possible to avoid patented = methods.
>
> For 1) there exist more efficient techniques, = such as the one
> proposed by
> Roger Schlafly on Nov 12 2001 to P1363 mailing = list. Similar
> compression
> should be made mandatory.
> For 2) one will use DH without cofactor = multiplication (i.e.,
> the shared
> secret will be exactly g^xy), but use other = methods to verify
> g^x received
> from the peer.
>
> I believe that abovementioned draft should not = assume
> patented formats on
> the wire and in g^xy, instead it should specify = patent-free
> alternatives.
> ( This issue has nothing to do with internal = representation
> of EC points or
> performance. )
>
> ----- Original Message -----
> From: "Chris Trobridge" = <CTrobridge@baltimore.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Wednesday, March 13, 2002 4:27 AM
> Subject: RE: Remove SHOULD for elliptic curve = groups in IKEv2
>
>
>  > Certicom have been very active in = this area.
>  >
>  > They have a document stating their = patents/applications:
>  >
>  > http://www.secg.org/collateral/certicom_secg_patent.pd= f
>  >
>  > This is better than what they used = to say which was along
> the lines of "we
>  > have patents in this area that you = might infringe but if
> you buy a licence
>  > from us you'll be ok".
>  >
>  > Their earliest patent listed above = was in 1988 and covers
> multiplication
>  > using base-normal form.  There = are other patents (by
> others) covering
>  > multiplication with normal basis = representation.
>  >
>  > I did a (general) patent search on = "Elliptic Curve" and
> "Cryptography" and
>  > that came up with 114 patents in the = last 6 years.  Quite
> apart from
> various
>  > acceleration patents, a number of = signature methods are
> also covered.
>  >
>  > Again, I am not experienced in = interpreting patents either.
>  >
>  > Chris
>  >
>  > -----Original Message-----
>  > From: Michael Richardson [mailto:mcr@sandelman.ottawa.o= n.ca]
>  > Sent: 12 March 2002 20:16
>  > To: ipsec@lists.tislabs.com
>  > Cc: Mark.Winstead@NetOctave.com; = Paul Koning
>  > Subject: Re: Remove SHOULD for = elliptic curve groups in IKEv2
>  >
>  >
>  >
>  > >>>>> = "Paul" =3D=3D Paul Koning <pkoning@equallogic.com> = writes:
>  >     Paul> One = data point:
>  >
>  >     Paul> = Even before AES was nailed down, there were chip vendors
>  > announcing
>  >     Paul> = hardware acceleration support for AES.
>  >
>  >     Paul> On = the other hand, years after EC came out,
> hardware accelerator
>  >     Paul> = support for it is still somewhere between very rare and
>  > nonexistent.
>  >
>  >     Paul> I'm = inclined to view these data as an indication
> of the interest
>  > level
>  >     Paul> in = EC; it supports Paul Hoffman's suggestion.
>  >
>  >   My understanding is that = there are specific patents
> (less than a decade
>  > old) on hardware accelerated EC. I = do not recall who owed
> them, wasn't
> HiFn
>  > or RSA/Verisign though.
>  >
>  > = ]       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");
>  > [
> ...
>
>

------_=_NextPart_001_01C1CB67.DE215140-- From owner-ipsec@lists.tislabs.com Thu Mar 14 07:45:36 2002 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 g2EFjZ408819; Thu, 14 Mar 2002 07:45:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03100 Thu, 14 Mar 2002 10:04:28 -0500 (EST) Message-Id: <5.1.0.14.0.20020314093901.01d35008@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 09:50:45 -0500 To: "Hallam-Baker, Phillip" , "'Henry Spencer'" , IP Security List From: David Jablon Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058699EF@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:00 AM 3/13/2002 -0800, Hallam-Baker, Phillip wrote: >Patent applications are not public information. I may (or may not) >have filled a submarine patent on any of the technology involved >in any specification and just not tell you. I believe EPO patents are published at a fixed point some months after filing, and at least some US patent applications too, (see http://www.uspto.gov/patft/index.html) I think this means that at least in some parts of the world cannot be reached by a "submarine". From owner-ipsec@lists.tislabs.com Thu Mar 14 07:55:33 2002 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 g2EFtW409742; Thu, 14 Mar 2002 07:55:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03238 Thu, 14 Mar 2002 10:18:21 -0500 (EST) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: William Allen Simpson Cc: ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security Date: Thu, 14 Mar 2002 10:29:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB6C.F7E2B1A0" 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_01C1CB6C.F7E2B1A0 Content-Type: text/plain; charset="iso-8859-1" Hello Mr. Simpson, I am not quite sure what was the point of your "10 year" memo, but it was entertaining. You may have had some valuable information for us but it was sidetracked swerving into and over Steve Kent. I am relatively new to the IETF so I carry no political baggage one way or the other. However, I must say that in my observations and conversations with Mr. Kent, I find him to be an extremely talented and technically astute individual. Further, he has, in my opinion, a very professional and articulate style when addressing technical issues within the WGs. He presents in a clear manner that can be understood by the audience in a non-offensive manner. I think that if more participants adopted these characteristics and qualities, the IETF process would deliver Internet benefits much more efficiently. Should you have constructive comments that can help make things run more smoothly in the WGs, you would indeed further the cause of Internet Security delivered more quickly to the user community. Best regards, Dennis Beard -----Original Message----- From: William Allen Simpson [mailto:wsimpson@greendragon.com] Sent: Wednesday, March 13, 2002 6:50 PM To: ietf@ietf.org Cc: ipsec@lists.tislabs.com Subject: 10 years and no ubiquitous security 10 years ago this week, we had an IETF meeting in San Diego. 10 years ago on Tuesday, Phil Karn sprawled out across my hotel room bed and drew the packet header that became ESP. (Remember when we were small enough to have hotel room BOFs?) 10 years today, at a lunch meeting, Phil Karn gathered a group of us, and we agreed to pursue IP Security, as "the most important thing missing from the Internet". (Most real work was still done in lunch and dinner BOFs last time I attended IETF, and presumably that tradition continues now.) 10 years ago tomorrow, Brian Lloyd and I had a "rubber hose" lunch meeting with Steve Kent, who as a member of the IAB had refused to allow the PPP WG to publish CHAP in our RFC as an official authentication protocol. (He had previously mandated that we remove all security protocol negotiation.) He backed down, but we had to change the name from "cryptographic" to "challenge". Steve Kent refused to charter the IPSec WG. We had to reform the structure of the IAB (removing Steve Kent) -- which was good for many other reasons, although its efficacy was short-lived. After all these years, ESP itself is remarkably unchanged. (The sequence field is 32 bits instead of 16 bits, but we did that in 1993.) Remember, by 1995 we had multiple interoperable implementations. Roughly 5 years ago, IPSec was supposed to be disbanded, because its work was complete. Instead, somebody named Steve Kent secretly took over the WG editorship (with no consensus, or even WG discussion), and his "appointment" was enforced upon the new "reform" WG Chairs. For 5 more years, IPSec WG has slowly turned out unworkable documents, generating endless and fruitless discussion. Today, IPSec has insignificant deployment, and the WG goeth on forever. ... Should I remind folks that at that same San Diego IETF, JI and Phil and Steve Deering and others of us had a lunch BOF on Mobile-IP? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ------_=_NextPart_001_01C1CB6C.F7E2B1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 10 years and no ubiquitous security

Hello Mr. Simpson,

I am not quite sure what was the point of your = "10 year" memo, but it was entertaining.  You may have = had some valuable information for us but it was sidetracked swerving = into and over Steve Kent.  I am relatively new to the IETF so I = carry no political baggage one way or the other.  However, I must = say that in my observations and conversations with Mr. Kent, I find him = to be an extremely talented and technically astute individual.  = Further, he has, in my opinion, a very professional and articulate = style when addressing technical issues within the WGs.  He = presents in a clear manner that can be understood by the audience in a = non-offensive manner.  I think that if more participants adopted = these characteristics and qualities, the IETF process would deliver = Internet benefits much more efficiently.

Should you have constructive comments that can help = make things run more smoothly in the WGs, you would indeed further the = cause of Internet Security delivered more quickly to the user = community.

Best regards,

Dennis Beard

-----Original Message-----
From: William Allen Simpson [mailto:wsimpson@greendragon.com= ]
Sent: Wednesday, March 13, 2002 6:50 PM
To: ietf@ietf.org
Cc: ipsec@lists.tislabs.com
Subject: 10 years and no ubiquitous security


10 years ago this week, we had an IETF meeting in San = Diego.

10 years ago on Tuesday, Phil Karn sprawled out = across my hotel room bed
and drew the packet header that became ESP.  = (Remember when we were
small enough to have hotel room BOFs?) 

10 years today, at a lunch meeting, Phil Karn = gathered a group of us,
and we agreed to pursue IP Security, as "the = most important thing
missing from the Internet".  (Most real = work was still done in lunch and
dinner BOFs last time I attended IETF, and = presumably that tradition
continues now.)

10 years ago tomorrow, Brian Lloyd and I had a = "rubber hose" lunch
meeting with Steve Kent, who as a member of the IAB = had refused to allow
the PPP WG to publish CHAP in our RFC as an official = authentication
protocol.  (He had previously mandated that we = remove all security
protocol negotiation.)  He backed down, but we = had to change the name
from "cryptographic" to = "challenge".

Steve Kent refused to charter the IPSec WG.  We = had to reform the
structure of the IAB (removing Steve Kent) -- which = was good for many
other reasons, although its efficacy was = short-lived.

After all these years, ESP itself is remarkably = unchanged.  (The
sequence field is 32 bits instead of 16 bits, but we = did that in 1993.) 
Remember, by 1995 we had multiple interoperable = implementations.

Roughly 5 years ago, IPSec was supposed to be = disbanded, because its
work was complete.  Instead, somebody named = Steve Kent secretly took
over the WG editorship (with no consensus, or even = WG discussion), and
his "appointment" was enforced upon the = new "reform" WG Chairs.

For 5 more years, IPSec WG has slowly turned out = unworkable documents,
generating endless and fruitless discussion.

Today, IPSec has insignificant deployment, and the WG = goeth on forever.

...

Should I remind folks that at that same San Diego = IETF, JI and Phil and
Steve Deering and others of us had a lunch BOF on = Mobile-IP?
--
William Allen Simpson
    Key fingerprint =3D  17 40 = 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

------_=_NextPart_001_01C1CB6C.F7E2B1A0-- From owner-ipsec@lists.tislabs.com Thu Mar 14 08:05:25 2002 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 g2EG5P410814; Thu, 14 Mar 2002 08:05:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03337 Thu, 14 Mar 2002 10:27:31 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699FA@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Mark Winstead'" , "'Andrey Jivsov'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Thu, 14 Mar 2002 07:39:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CB6E.7F8EF180" 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_000_01C1CB6E.7F8EF180 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB6E.7F8EF180" ------_=_NextPart_001_01C1CB6E.7F8EF180 Content-Type: text/plain; charset="iso-8859-1" It is impossible to find out whether anyone have filled a claim in this area. What we can and must do if ECC is to be used is to send Certicom an official letter of enquiry. If Certicom responds that they have not or they will license the patent RF the spec can proceed. I am still waiting for someone to provide a good reason for making ECC more than a MAY. The key length argument is fatuous. Concern about brute force attack is not a good reason to use the longer key lengths, the additional encryption rounds are. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 -----Original Message----- From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com] Sent: Thursday, March 14, 2002 9:53 AM To: 'Andrey Jivsov'; Chris Trobridge; ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 That patent statement of Certicom was written in may, 1999. There is one patent granted to Certicom on a mathod to avoid the small subgroup attack in August 1999, but no point compression method or other subgroup attack related one listed on the U.S. government's database (supposedly complete to March 12th 2002). What makes you think that the IKE implementation is using one of Certicom's claimed patent applications? I don't think that lowest order bit of x/y (y/x?) is patentable if it isn't already patented. Hasn't that technique been around since the 80s? > -----Original Message----- > From: Andrey Jivsov [ mailto:andrey@brainhub.org ] > Sent: Wednesday, March 13, 2002 6:42 PM > To: Chris Trobridge; ipsec@lists.tislabs.com > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > After playing with one of IKE gateways which implements ECC > groups from > draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there > appear to be no > way to interoperate with this box without violating some of patents. > > The issue here is not a performance, but the fact that IKE > implementation > must use some of following techniques in order to interpret > data in the KE > payload or create the same g^xy: > > 1) point compression, such that only the lowest bit of polynomial > representation of x/y is transmitted > 2) g^xyc (or xyc * G in EC notation), where c is > "cofactor", is used > instead of g^xy > > These techniques are likely to be patented in applications #2 and #5 > respectively, listed on the last page of > http://www.secg.org/collateral/certicom_secg_patent.pdf: > > > 2. Methods for point compression. > . > > 5. Methods to avoid the small subgroup attack. > > It is possible to avoid patented methods. > > For 1) there exist more efficient techniques, such as the one > proposed by > Roger Schlafly on Nov 12 2001 to P1363 mailing list. Similar > compression > should be made mandatory. > For 2) one will use DH without cofactor multiplication (i.e., > the shared > secret will be exactly g^xy), but use other methods to verify > g^x received > from the peer. > > I believe that abovementioned draft should not assume > patented formats on > the wire and in g^xy, instead it should specify patent-free > alternatives. > ( This issue has nothing to do with internal representation > of EC points or > performance. ) > > ----- Original Message ----- > From: "Chris Trobridge" > To: > Sent: Wednesday, March 13, 2002 4:27 AM > Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > > > > Certicom have been very active in this area. > > > > They have a document stating their patents/applications: > > > > http://www.secg.org/collateral/certicom_secg_patent.pdf > > > > This is better than what they used to say which was along > the lines of "we > > have patents in this area that you might infringe but if > you buy a licence > > from us you'll be ok". > > > > Their earliest patent listed above was in 1988 and covers > multiplication > > using base-normal form. There are other patents (by > others) covering > > multiplication with normal basis representation. > > > > I did a (general) patent search on "Elliptic Curve" and > "Cryptography" and > > that came up with 114 patents in the last 6 years. Quite > apart from > various > > acceleration patents, a number of signature methods are > also covered. > > > > Again, I am not experienced in interpreting patents either. > > > > Chris > > > > -----Original Message----- > > From: Michael Richardson [ mailto:mcr@sandelman.ottawa.on.ca ] > > Sent: 12 March 2002 20:16 > > To: ipsec@lists.tislabs.com > > Cc: Mark.Winstead@NetOctave.com; Paul Koning > > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > > > >>>>> "Paul" == Paul Koning writes: > > Paul> One data point: > > > > Paul> Even before AES was nailed down, there were chip vendors > > announcing > > Paul> hardware acceleration support for AES. > > > > Paul> On the other hand, years after EC came out, > hardware accelerator > > Paul> support for it is still somewhere between very rare and > > nonexistent. > > > > Paul> I'm inclined to view these data as an indication > of the interest > > level > > Paul> in EC; it supports Paul Hoffman's suggestion. > > > > My understanding is that there are specific patents > (less than a decade > > old) on hardware accelerated EC. I do not recall who owed > them, wasn't > HiFn > > or RSA/Verisign though. > > > > ] 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"); > > [ > ... > > ------_=_NextPart_001_01C1CB6E.7F8EF180 Content-Type: text/html; charset="iso-8859-1" RE: Remove SHOULD for elliptic curve groups in IKEv2
It is impossible to find out whether anyone have filled a claim in this area.
 
What we can and must do if ECC is to be used is to send Certicom an official letter of enquiry. If Certicom responds that they have not or they will license the patent RF the spec can proceed.
 
 
I am still waiting for someone to provide a good reason for making ECC more than a MAY. The key length argument is fatuous. Concern about brute force attack is not a good reason to use the longer key lengths, the additional encryption rounds are.
 
 
    Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com]
Sent: Thursday, March 14, 2002 9:53 AM
To: 'Andrey Jivsov'; Chris Trobridge; ipsec@lists.tislabs.com
Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2

That patent statement of Certicom was written in may, 1999. There is one patent granted to Certicom on a mathod to avoid the small subgroup attack in August 1999, but no point compression method or other subgroup attack related one listed on the U.S. government's database (supposedly complete to March 12th 2002). What makes you think that the IKE implementation is using one of Certicom's claimed patent applications?

I don't think that lowest order bit of x/y (y/x?) is patentable if it isn't already patented. Hasn't that technique been around since the 80s?



> -----Original Message-----
> From: Andrey Jivsov [mailto:andrey@brainhub.org]
> Sent: Wednesday, March 13, 2002 6:42 PM
> To: Chris Trobridge; ipsec@lists.tislabs.com
> Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2
>
>
> After playing with one of IKE gateways which implements ECC
> groups from
> draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there
> appear to be no
> way to interoperate with this box without violating some of patents.
>
> The issue here is not a performance, but the fact that IKE
> implementation
> must use some of following techniques in order to interpret
> data in the KE
> payload or create the same g^xy:
>
>      1) point compression, such that only the lowest bit of polynomial
> representation of x/y is transmitted
>      2) g^xyc (or xyc * G in EC notation), where c is
> "cofactor", is used
> instead of g^xy
>
> These techniques are likely to be patented in applications #2 and #5
> respectively, listed on the last page of
> http://www.secg.org/collateral/certicom_secg_patent.pdf:
>
>      > 2.  Methods for point compression.
>      .
>      > 5.  Methods to avoid the small subgroup attack.
>
> It is possible to avoid patented methods.
>
> For 1) there exist more efficient techniques, such as the one
> proposed by
> Roger Schlafly on Nov 12 2001 to P1363 mailing list. Similar
> compression
> should be made mandatory.
> For 2) one will use DH without cofactor multiplication (i.e.,
> the shared
> secret will be exactly g^xy), but use other methods to verify
> g^x received
> from the peer.
>
> I believe that abovementioned draft should not assume
> patented formats on
> the wire and in g^xy, instead it should specify patent-free
> alternatives.
> ( This issue has nothing to do with internal representation
> of EC points or
> performance. )
>
> ----- Original Message -----
> From: "Chris Trobridge" <CTrobridge@baltimore.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Wednesday, March 13, 2002 4:27 AM
> Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2
>
>
>  > Certicom have been very active in this area.
>  >
>  > They have a document stating their patents/applications:
>  >
>  > http://www.secg.org/collateral/certicom_secg_patent.pdf
>  >
>  > This is better than what they used to say which was along
> the lines of "we
>  > have patents in this area that you might infringe but if
> you buy a licence
>  > from us you'll be ok".
>  >
>  > Their earliest patent listed above was in 1988 and covers
> multiplication
>  > using base-normal form.  There are other patents (by
> others) covering
>  > multiplication with normal basis representation.
>  >
>  > I did a (general) patent search on "Elliptic Curve" and
> "Cryptography" and
>  > that came up with 114 patents in the last 6 years.  Quite
> apart from
> various
>  > acceleration patents, a number of signature methods are
> also covered.
>  >
>  > Again, I am not experienced in interpreting patents either.
>  >
>  > Chris
>  >
>  > -----Original Message-----
>  > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
>  > Sent: 12 March 2002 20:16
>  > To: ipsec@lists.tislabs.com
>  > Cc: Mark.Winstead@NetOctave.com; Paul Koning
>  > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2
>  >
>  >
>  >
>  > >>>>> "Paul" == Paul Koning <pkoning@equallogic.com> writes:
>  >     Paul> One data point:
>  >
>  >     Paul> Even before AES was nailed down, there were chip vendors
>  > announcing
>  >     Paul> hardware acceleration support for AES.
>  >
>  >     Paul> On the other hand, years after EC came out,
> hardware accelerator
>  >     Paul> support for it is still somewhere between very rare and
>  > nonexistent.
>  >
>  >     Paul> I'm inclined to view these data as an indication
> of the interest
>  > level
>  >     Paul> in EC; it supports Paul Hoffman's suggestion.
>  >
>  >   My understanding is that there are specific patents
> (less than a decade
>  > old) on hardware accelerated EC. I do not recall who owed
> them, wasn't
> HiFn
>  > or RSA/Verisign though.
>  >
>  > ]       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");
>  > [
> ...
>
>

------_=_NextPart_001_01C1CB6E.7F8EF180-- ------_=_NextPart_000_01C1CB6E.7F8EF180 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CB6E.7F8EF180-- From owner-ipsec@lists.tislabs.com Thu Mar 14 09:15:10 2002 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 g2EHF8415567; Thu, 14 Mar 2002 09:15:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03909 Thu, 14 Mar 2002 11:36:57 -0500 (EST) Message-ID: <3C90FD0F.A4508C74@storm.ca> Date: Thu, 14 Mar 2002 11:42:07 -0800 From: Sandy Harris X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Dennis Beard wrote: > > Hello Mr. Simpson, > > I am not quite sure what was the point of your "10 year" memo, Perhaps just to highlight that something in the process is broken? 10 years and we haven't got this stuff fully deployed yet. Hell, you could argue about whether we've even got it completely designed and properly specified. (I'd say "Yes, but...".) Compare this to the web, which is about 12 years old. If it had developed equally slowly, we'd stiil be using Gopher and quite a few well-known companies, products, job titles, etc. would not exist. Methinks security (e.g. IPsec) is as important as accessibility (e.g. http), both to businesses and to end users. We really need ubiquitous IPsec, and we don't seem to be getting it, despite assorted valiant efforts. > but ... Steve Kent. ... Not worth discuusing unless you know a lot more of the history than I do, or want to. > Should you have constructive comments that can help make things run > more smoothly in the WGs, you would indeed further the cause of > Internet Security delivered more quickly to the user community. A quick check shows Simpson listed as author, co-author or editor for 30 or so RFCs. Methinks he's paid his dues, and his comments should be taken as constructive, even when they are harsh. From owner-ipsec@lists.tislabs.com Thu Mar 14 09:18:28 2002 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 g2EHIL415926; Thu, 14 Mar 2002 09:18:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03938 Thu, 14 Mar 2002 11:39:17 -0500 (EST) Reply-To: From: =?iso-8859-1?Q?Josu_de_Andr=E9s_Urraca?= To: Subject: IPSec Date: Thu, 14 Mar 2002 17:48:52 +0100 Message-ID: <000201c1cb78$200fb960$71028bd5@jdeandres> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Does exist any document containing the IPSec protocol as it? Thank you very much. Regards, Josu From owner-ipsec@lists.tislabs.com Thu Mar 14 10:08:26 2002 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 g2EI8P417344; Thu, 14 Mar 2002 10:08:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04189 Thu, 14 Mar 2002 12:28:38 -0500 (EST) Message-ID: <3C90E0B7.991B792F@sonicwall.com> Date: Thu, 14 Mar 2002 09:41:11 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Mark Winstead'" , "'Andrey Jivsov'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <2F3EC696EAEED311BB2D009027C3F4F4058699FA@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2002 17:41:11.0179 (UTC) FILETIME=[6E1D65B0:01C1CB7F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Phill, I'm not a cryptographer, so bear with me. > "Hallam-Baker, Phillip" wrote: >I am still waiting for someone to provide a good reason for making ECC > more than a MAY. The key length argument is fatuous. Concern about > brute force attack is not a good reason to use the longer key lengths, > the additional encryption rounds are. I can think of two reasons to use ECC: 1) It reduces the computational overhead of the DH computation for IKE and IPsec tunnels. This is valuable today on either a high-end box supporting bazillions of tunnels, or on a computationally constrained device where MODP might take 2-3 minutes. This is true for DES, 3DES, or AES key lengths. 2) It reduces computational overhead of the computation for longer key lengths when compared to MODP calculations, if one actually desires a bit-strength comparable to key length (and so, would use much longer moduli/exponents if MODP were used instead). This belief is based upon the notion that to provide keys which are not susceptible to anything short of brute strength attack, we need to use longer moduli/exponents for MODP. You seem to be saying that (2) is invalid. If this is what you mean to say, can you explain why this is so? Thanks, Scott From owner-ipsec@lists.tislabs.com Thu Mar 14 10:21:17 2002 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 g2EILG417978; Thu, 14 Mar 2002 10:21:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04261 Thu, 14 Mar 2002 12:40:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15504.57739.485760.409703@pkoning.dev.equallogic.com> Date: Thu, 14 Mar 2002 12:44:43 -0500 From: Paul Koning To: ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security References: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dennis" == Dennis Beard writes: Dennis> Hello Mr. Simpson, I am not quite sure what was the point of Dennis> your "10 year" memo, but it was entertaining. You may have Dennis> had some valuable information for us but it was sidetracked Dennis> swerving into and over Steve Kent. ... Well said. It is conceivable that W.A.Simpson has created useful technical contributions in the past. Then again, I don't remember any in IPsec, at least not in many years. And if he desired to destroy utterly whatever credibility he may have left, that note was certainly a good way to achieve it. It may or may not be true that "Today, IPSec has insignificant deployment". If true, it's not clear why. Certainly Simpson gives no clue that he might have an opinion on what the reason might be. (I have my own opinions, based on the observation that in 40 years only one protocol has made significant inroads, by offering a partial solution packaged with web browsers.) I know people working to make IP security ubiquitous. Simpson is not one of them. I'll go back to listening to people who are actually contributing things of merit. paul From owner-ipsec@lists.tislabs.com Thu Mar 14 10:21:42 2002 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 g2EILg418003; Thu, 14 Mar 2002 10:21:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04281 Thu, 14 Mar 2002 12:41:46 -0500 (EST) Message-ID: <3C90E0EE.6020004@alum.mit.edu> Date: Thu, 14 Mar 2002 10:42:06 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Winstead CC: "'Andrey Jivsov'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Through P1363, Certicom's intentions to patent point compression have been public for some time. The observation that point compression is possible has been around for some years, there are several ways to choose the meaning of the bit that encodes the second coordinate. It's not at all clear that IKE's method infringes Certicom's, to my actual knowledge. I don't understand the claim about the co-factor. How is it that you claim the computation cannot be done with it? Hilarie Mark Winstead wrote: > That patent statement of Certicom was written in may, 1999. There is one > patent granted to Certicom on a mathod to avoid the small subgroup > attack in August 1999, but no point compression method or other subgroup > attack related one listed on the U.S. government's database (supposedly > complete to March 12th 2002). What makes you think that the IKE > implementation is using one of Certicom's claimed patent applications? > > I don't think that lowest order bit of x/y (y/x?) is patentable if it > isn't already patented. Hasn't that technique been around since the 80s? > > > > > -----Original Message----- > > From: Andrey Jivsov [mailto:andrey@brainhub.org] > > Sent: Wednesday, March 13, 2002 6:42 PM > > To: Chris Trobridge; ipsec@lists.tislabs.com > > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > After playing with one of IKE gateways which implements ECC > > groups from > > draft-ietf-ipsec-ike-ecc-groups-03.txt I found that there > > appear to be no > > way to interoperate with this box without violating some of patents. > > > > The issue here is not a performance, but the fact that IKE > > implementation > > must use some of following techniques in order to interpret > > data in the KE > > payload or create the same g^xy: > > > > 1) point compression, such that only the lowest bit of polynomial > > representation of x/y is transmitted > > 2) g^xyc (or xyc * G in EC notation), where c is > > "cofactor", is used > > instead of g^xy > > > > These techniques are likely to be patented in applications #2 and #5 > > respectively, listed on the last page of > > http://www.secg.org/collateral/certicom_secg_patent.pdf: > > > > > 2. Methods for point compression. > > . > > > 5. Methods to avoid the small subgroup attack. > > > > It is possible to avoid patented methods. > > > > For 1) there exist more efficient techniques, such as the one > > proposed by > > Roger Schlafly on Nov 12 2001 to P1363 mailing list. Similar > > compression > > should be made mandatory. > > For 2) one will use DH without cofactor multiplication (i.e., > > the shared > > secret will be exactly g^xy), but use other methods to verify > > g^x received > > from the peer. > > > > I believe that abovementioned draft should not assume > > patented formats on > > the wire and in g^xy, instead it should specify patent-free > > alternatives. > > ( This issue has nothing to do with internal representation > > of EC points or > > performance. ) > > > > ----- Original Message ----- > > From: "Chris Trobridge" > > To: > > Sent: Wednesday, March 13, 2002 4:27 AM > > Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > > Certicom have been very active in this area. > > > > > > They have a document stating their patents/applications: > > > > > > http://www.secg.org/collateral/certicom_secg_patent.pdf > > > > > > This is better than what they used to say which was along > > the lines of "we > > > have patents in this area that you might infringe but if > > you buy a licence > > > from us you'll be ok". > > > > > > Their earliest patent listed above was in 1988 and covers > > multiplication > > > using base-normal form. There are other patents (by > > others) covering > > > multiplication with normal basis representation. > > > > > > I did a (general) patent search on "Elliptic Curve" and > > "Cryptography" and > > > that came up with 114 patents in the last 6 years. Quite > > apart from > > various > > > acceleration patents, a number of signature methods are > > also covered. > > > > > > Again, I am not experienced in interpreting patents either. > > > > > > Chris > > > > > > -----Original Message----- > > > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > > > Sent: 12 March 2002 20:16 > > > To: ipsec@lists.tislabs.com > > > Cc: Mark.Winstead@NetOctave.com; Paul Koning > > > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > > > > > > > > > > >>>>> "Paul" == Paul Koning writes: > > > Paul> One data point: > > > > > > Paul> Even before AES was nailed down, there were chip vendors > > > announcing > > > Paul> hardware acceleration support for AES. > > > > > > Paul> On the other hand, years after EC came out, > > hardware accelerator > > > Paul> support for it is still somewhere between very rare and > > > nonexistent. > > > > > > Paul> I'm inclined to view these data as an indication > > of the interest > > > level > > > Paul> in EC; it supports Paul Hoffman's suggestion. > > > > > > My understanding is that there are specific patents > > (less than a decade > > > old) on hardware accelerated EC. I do not recall who owed > > them, wasn't > > HiFn > > > or RSA/Verisign though. > > > > > > ] 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 Thu Mar 14 10:45:57 2002 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 g2EIju418584; Thu, 14 Mar 2002 10:45:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04461 Thu, 14 Mar 2002 13:10:34 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A00@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Scott G. Kelly'" , "Hallam-Baker, Phillip" Cc: "'Mark Winstead'" , "'Andrey Jivsov'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2 Date: Thu, 14 Mar 2002 10:22:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CB85.4241C520" 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_000_01C1CB85.4241C520 Content-Type: text/plain; charset="iso-8859-1" The basic assumption that EC is based on is that it is harder to cryptanalyse EC parameters than modular parameters of the same length. The problem is that this assumption may not be valid. EC is a pretty new field and interest in EC algorithms has been pretty sparse. We have several centuries of experience with modular arithmetic however. People are still comming up with fundamental theorems in the EC space such as the 'Fermats Last theorem' proof that demonstrated all Elliptic curves are Modular. What if someone can convert one to the other in acceptable time for the classes of EC we use in crypto? Len Addleman has been cautioning folk against using EC for several years. I strongly suspect he is working on the topic again after he showed that hyper eliptic curves are no stronger than those in 2D. While I don't have a major problem with using EC in place of 1024 bit RSA for performance, but performance alone is unlikely to persuade the group that the algorthms are SHOULD and not MAY. I do have a major problem with people using EC in place of RSA or DSA for higher levels of security. That is the justification being made for their inclusion as SHOULD instead of MAY. I find the argument on that score to be less than compelling. If you are using 256 bit AES the computational issues of 2048 bit RSA should be irrelevant to you and the computational issues of 3072 or 4096 should not be a major issue. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@SonicWALL.com] > Sent: Thursday, March 14, 2002 12:41 PM > To: Hallam-Baker, Phillip > Cc: 'Mark Winstead'; 'Andrey Jivsov'; Chris Trobridge; > ipsec@lists.tislabs.com > Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 > > > Hi Phill, > > I'm not a cryptographer, so bear with me. > > > "Hallam-Baker, Phillip" wrote: > > >I am still waiting for someone to provide a good reason for > making ECC > > more than a MAY. The key length argument is fatuous. Concern about > > brute force attack is not a good reason to use the longer > key lengths, > > the additional encryption rounds are. > > I can think of two reasons to use ECC: > > 1) It reduces the computational overhead of the DH computation for IKE > and IPsec tunnels. This is valuable today on either a high-end box > supporting bazillions of tunnels, or on a computationally constrained > device where MODP might take 2-3 minutes. This is true for > DES, 3DES, or > AES key lengths. > > 2) It reduces computational overhead of the computation for longer key > lengths when compared to MODP calculations, if one actually desires a > bit-strength comparable to key length (and so, would use much longer > moduli/exponents if MODP were used instead). This belief is based upon > the notion that to provide keys which are not susceptible to anything > short of brute strength attack, we need to use longer moduli/exponents > for MODP. > > You seem to be saying that (2) is invalid. If this is what you mean to > say, can you explain why this is so? > > Thanks, > > Scott > ------_=_NextPart_000_01C1CB85.4241C520 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CB85.4241C520-- From owner-ipsec@lists.tislabs.com Thu Mar 14 11:15:10 2002 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 g2EJF8420164; Thu, 14 Mar 2002 11:15:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04653 Thu, 14 Mar 2002 13:37:23 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A02@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Sandy Harris'" , ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security Date: Thu, 14 Mar 2002 10:49:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CB89.0B0BDF10" 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_000_01C1CB89.0B0BDF10 Content-Type: text/plain; charset="iso-8859-1" >> I am not quite sure what was the point of your "10 year" memo, Obviously the writer is not familliar with USENet or Slashdot and does not know the vicarious thrill of reading a well written troll. > Compare this to the web, which is about 12 years old. If it had > developed equally slowly, we'd stiil be using Gopher and quite > a few well-known companies, products, job titles, etc. would not > exist. Deployment of the Web was much easier because it required only single ended adoption. It was possible to install a Web server without any administrative privs, it was possible to install a Web browser without any administrative privs. IPSEC is by necessity double ended adoption which is very much slower to deploy. Plus the hard issue for IPSEC was not the packet format, it was the keying issue which was in turn held up by the patent encumbrances. >> but ... Steve Kent. ... Is personally responsible for all the failures of the IETF, the IESG and the IAB. I have it on good authority that he was also personaly responsible for the West Palm Beach 'Butterfly Ballot', the design of the electoral voting machine chad and thus GWB making him personaly and directly responsible for all global events of any significance since the founding of the republic, possibly earlier... I personally disagree with the above statement as it would appear to somewhat overstate the role of Steve in geo-political affairs. As it would happen Steve and I appear to be sharing a black helicopter to the next meeting of the New World Order. Phill ------_=_NextPart_000_01C1CB89.0B0BDF10 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CB89.0B0BDF10-- From owner-ipsec@lists.tislabs.com Thu Mar 14 11:43:03 2002 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 g2EJh2422263; Thu, 14 Mar 2002 11:43:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04852 Thu, 14 Mar 2002 13:56:45 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 14 Mar 2002 11:08:07 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Remove private-use values from IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Private-use values for payloads, attributes, and so on lead to lack of interoperability and are not needed. The only time private-use numbers should be used is for limited testing experimental changes to IKE, but such testing can just as easily be done using vendor-id payloads. For example, a message with a particular vendor ID payload could mean "ignore the encryption algorithm specified in the SA payload and use WhizzyAlg-128 instead." The IETF has a long history of problems with private-use anything. Because implementations often get out of the laboratory, there are often value clashes. Worse yet, there often demands that, because so many people are using private value xyz to mean the abc feature, we should not give abc a regular value when it becomes an RFC, we should keep using xyz (or at least say in the RFC that xyz is equivalent to the new number). Real testing of new algorithms (as compared to the more common "early implementation") is rare, and when it happens, it is quite easy to control with vendor ID payloads. Note that, if private-use payload types are forbidden, there is no longer any use for the critical bit. In that case, the critical bit should be removed from IKEv2 in order to make the protocol simpler. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 11:43:03 2002 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 g2EJh2422264; Thu, 14 Mar 2002 11:43:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04851 Thu, 14 Mar 2002 13:56:44 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 14 Mar 2002 11:05:46 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Remove little-used algorithms from IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The early goals of the successor-to-IKE work was to make it simpler and more interoperable. Continuing to list values for algorithms that are rarely used or do not have good interoperabilty, or both, goes against both of those goals. Some should be removed because they have security properties that are so similar to other algorithms that are more used that they add nothing to the security of IPsec; they were added "because we could" but at the expense of interoperability and simplicity. Some of the algorithms, such as single DES, should be removed simply because they are a bad idea for security. The following lists show the algorithms should be removed from the IKEv2 spec. Those marked with an asterisk should be removed from IKEv2. Encryption algorithms: RESERVED 0 * ENCR_DES_IV64 1 (RFC1827) * ENCR_DES 2 (RFC2405) ENCR_3DES 3 (RFC2451) * ENCR_RC5 4 (RFC2451) * ENCR_IDEA 5 (RFC2451) ENCR_CAST 6 (RFC2451) * ENCR_BLOWFISH 7 (RFC2451) * ENCR_3IDEA 8 (RFC2451) * ENCR_DES_IV32 9 * ENCR_RC4 10 ENCR_NULL 11 (RFC2410) ENCR_AES_128 12 Pseudo-random Functions: RESERVED 0 PRF_HMAC_MD5 1 (RFC2104) PRF_HMAC_SHA 2 (RFC2104) * PRF_HMAC_TIGER 3 (RFC2104) Integrity: AUTH_HMAC_MD5 1 (RFC2403) AUTH_HMAC_SHA 2 (RFC2404) * AUTH_DES_MAC 3 * AUTH_KPDK_MD5 4 (RFC1826) In the same vein, all certificate formats other than #4 (X.509 Certificate - Signature) should be deprecated as well. "PKCS #7 wrapped X.509 certificate" is particularly bad given that there is no standard for how to "wrap" a certificate. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 12:54:06 2002 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 g2EKs6423862; Thu, 14 Mar 2002 12:54:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05443 Thu, 14 Mar 2002 15:06:52 -0500 (EST) Message-ID: <048501c1cb92$b748cd70$0200a8c0@remedy> From: "Andrey Jivsov" To: "The Purple Streak \(Hilarie Orman\)" , "Mark Winstead" Cc: "Chris Trobridge" , References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> <3C90E0EE.6020004@alum.mit.edu> Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 Date: Thu, 14 Mar 2002 11:59:14 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Mar 2002 20:01:25.0259 (UTC) FILETIME=[054C1DB0:01C1CB93] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Through P1363, Certicom's intentions to patent point compression have > been public for some time. The observation that point compression > is possible has been around for some years, there are several ways to > choose the meaning of the bit that encodes the second coordinate. > It's not at all clear that IKE's method infringes Certicom's, to my > actual knowledge. >From patent 6,141,420, claim 32: 32. A method according to claim 30 wherein said algebraic curve is an elliptic curve of the form y.sup.2 +xy=x.sup.3 +ax.sup.2 +b and said other coordinate is determined by solving a quadratic equation to provide two possible values of said other coordinate, said identifying information indicating the appropriate one of said values. last bit of (y/x) would qualify for "identifying information". Many people said that this claim is invalid, but claim is there along with others (33,36,37). > I don't understand the claim about the co-factor. How is it that > you claim the computation cannot be done with it? It can be done, but if one peer uses xyc * G in place of "g^xy" then you must use it as well, after somehow guessing that the peer is using it. If xyc * G is patented, you cannot support ECC groups without patent violation. The solutions are either to disallow cofactor multiplication in the shared secret, or make sure it is not patented and then document what is the meaning of g^xy for ECC, since it is logical to assume that "g^xy" is xy * G. From owner-ipsec@lists.tislabs.com Thu Mar 14 12:57:55 2002 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 g2EKvs423951; Thu, 14 Mar 2002 12:57:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05584 Thu, 14 Mar 2002 15:19:55 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Remove little-used algorithms from IKEv2 Date: Thu, 14 Mar 2002 12:32:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CB97.5EB27B20" 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_000_01C1CB97.5EB27B20 Content-Type: text/plain; charset="iso-8859-1" Any reason for keeping the MD5 algorithms given their somewhat compromised status? MD5 and SHA are pretty close and share the same internal structure so I don't think we can really justify MD5 as a fallback to SHA-1, particularly in the light of the Dobbertin results. We should anticipate that the AES based SHA-2 algorithms will appear in due course so it is not as if there would only be one algorithm Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, March 14, 2002 2:06 PM > To: ipsec@lists.tislabs.com > Subject: Remove little-used algorithms from IKEv2 > > > The early goals of the successor-to-IKE work was to make it simpler > and more interoperable. Continuing to list values for algorithms that > are rarely used or do not have good interoperabilty, or both, goes > against both of those goals. Some should be removed because they have > security properties that are so similar to other algorithms that are > more used that they add nothing to the security of IPsec; they were > added "because we could" but at the expense of interoperability and > simplicity. Some of the algorithms, such as single DES, should be > removed simply because they are a bad idea for security. > > The following lists show the algorithms should be removed from the > IKEv2 spec. Those marked with an asterisk should be removed from > IKEv2. > > Encryption algorithms: > RESERVED 0 > * ENCR_DES_IV64 1 (RFC1827) > * ENCR_DES 2 (RFC2405) > ENCR_3DES 3 (RFC2451) > * ENCR_RC5 4 (RFC2451) > * ENCR_IDEA 5 (RFC2451) > ENCR_CAST 6 (RFC2451) > * ENCR_BLOWFISH 7 (RFC2451) > * ENCR_3IDEA 8 (RFC2451) > * ENCR_DES_IV32 9 > * ENCR_RC4 10 > ENCR_NULL 11 (RFC2410) > ENCR_AES_128 12 > > Pseudo-random Functions: > RESERVED 0 > PRF_HMAC_MD5 1 (RFC2104) > PRF_HMAC_SHA 2 (RFC2104) > * PRF_HMAC_TIGER 3 (RFC2104) > > Integrity: > AUTH_HMAC_MD5 1 (RFC2403) > AUTH_HMAC_SHA 2 (RFC2404) > * AUTH_DES_MAC 3 > * AUTH_KPDK_MD5 4 (RFC1826) > > In the same vein, all certificate formats other than #4 (X.509 > Certificate - Signature) should be deprecated as well. "PKCS #7 > wrapped X.509 certificate" is particularly bad given that there is no > standard for how to "wrap" a certificate. > > --Paul Hoffman, Director > --VPN Consortium > ------_=_NextPart_000_01C1CB97.5EB27B20 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CB97.5EB27B20-- From owner-ipsec@lists.tislabs.com Thu Mar 14 13:27:43 2002 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 g2ELRg424666; Thu, 14 Mar 2002 13:27:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05883 Thu, 14 Mar 2002 15:51:39 -0500 (EST) Date: Thu, 14 Mar 2002 16:02:44 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: Remove little-used algorithms from IKEv2 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Mar 2002, Hallam-Baker, Phillip wrote: > MD5 and SHA are pretty close and share the same internal structure so I > don't think we can really justify MD5 as a fallback to SHA-1, particularly > in the light of the Dobbertin results. Remember that the Dobbertin results appear to be inapplicable to HMAC-MD5, serious though they are for plain MD5. One consideration that matters to some people is that MD5 was not designed by the NSA. (Saying that this shouldn't matter to them won't make it so.) This is one place where even FreeS/WAN, which generally is big on "one good solution, not a choice among ten", offers both. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 14 13:54:47 2002 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 g2ELsk425333; Thu, 14 Mar 2002 13:54:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06040 Thu, 14 Mar 2002 16:11:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15505.5298.749714.629549@pkoning.dev.equallogic.com> Date: Thu, 14 Mar 2002 16:22:58 -0500 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Remove little-used algorithms from IKEv2 References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> writes: >> The early goals of the successor-to-IKE work was to make it >> simpler and more interoperable. Continuing to list values for >> algorithms that are rarely used or do not have good >> interoperabilty, or both, goes against both of those goals. ... >> The following lists show the algorithms should be removed from the >> IKEv2 spec. Those marked with an asterisk should be removed from >> IKEv2. I agree with your list. In fact, I'd add a * to one more: ENCR_CAST. paul From owner-ipsec@lists.tislabs.com Thu Mar 14 14:08:28 2002 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 g2EM8S425562; Thu, 14 Mar 2002 14:08:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06232 Thu, 14 Mar 2002 16:33:29 -0500 (EST) X-VirusChecked: Checked Message-ID: <8B204D152222D51182B70001028841376DAD41@postmaster.cryptek.com> From: "Hu, Shicai" To: ipsec@lists.tislabs.com Cc: "wsimpson@GreenDragon.com" , > Subject: ICMP Security Failure Message? Date: Thu, 14 Mar 2002 16:03:48 -0500 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 2521: ICMP Security Failure Message Category: Experimental (What does a category of "experimental" mean? Does IETF assign somebody to do some experiment on this RFC document?) I am wondering that is this "ICMP Security Failure Message" may be sent after IPSec (Either IKE message or ESP message) message failed? Thanks a lot. From owner-ipsec@lists.tislabs.com Thu Mar 14 14:11:20 2002 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 g2EMBJ425669; Thu, 14 Mar 2002 14:11:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06272 Thu, 14 Mar 2002 16:36:35 -0500 (EST) Message-ID: <3C911A9B.1080408@isi.edu> Date: Thu, 14 Mar 2002 13:48:11 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Sandy Harris CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> <3C90FD0F.A4508C74@storm.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy Harris wrote: >>Dennis Beard wrote: >> >>Hello Mr. Simpson, >> >>I am not quite sure what was the point of your "10 year" memo, >> > > Perhaps just to highlight that something in the process is broken? > 10 years and we haven't got this stuff fully deployed yet. > > Hell, you could argue about whether we've even got it completely > designed and properly specified. (I'd say "Yes, but...".) > > Compare this to the web, which is about 12 years old. If it had > developed equally slowly, we'd stiil be using Gopher and quite > a few well-known companies, products, job titles, etc. would not > exist. Don't forget about SGML. And Hypercard. And others. The web didn't occur overnight; it was a multi-decade evolution. While I hope this isn't the case with IPsec, it's unfair to hold it to a nonexistent 'overnight' success metric. Joe From owner-ipsec@lists.tislabs.com Thu Mar 14 14:19:50 2002 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 g2EMJn425934; Thu, 14 Mar 2002 14:19:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06356 Thu, 14 Mar 2002 16:42:14 -0500 (EST) Message-Id: <200203142153.g2ELrtDq022893@kebe.east.sun.com> Subject: Re: Remove little-used algorithms from IKEv2 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> from "Hallam-Baker, Phillip" at "Mar 14, 2002 12:32:33 pm" To: "Hallam-Baker, Phillip" Date: Thu, 14 Mar 2002 16:53:55 -0500 (EST) 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 > Any reason for keeping the MD5 algorithms given their somewhat compromised > status? > > MD5 and SHA are pretty close and share the same internal structure so I > don't think we can really justify MD5 as a fallback to SHA-1, particularly > in the light of the Dobbertin results. Hmmm, I thought HMAC prevented these problems. Here's a note from a w3c list that forwards a conversation between Dobbertin and IPsec list regular Hugo Krawczyk: http://lists.w3.org/Archives/Public/ietf-tls/1996AprJun/0111.html MD5 is a far better peformer than SHA-1 - especially if you work around MD5's poor assumptions that all-the-world's-an-Intel. > We should anticipate that the AES based SHA-2 algorithms will appear in due > course so it is not as if there would only be one algorithm Now _this_ is a better point, but removing MD5 from IKE based on just Dobbertin is not sufficient, IMHO. Also, these proposed removals are for IKE only, not for AH/ESP, correct? HMAC-MD5 is still quite sufficient for packet integrity, and like I said, it smokes compared with SHA. Perhaps we should be looking at UMAC for future AH/ESP secure hashes? Dan From owner-ipsec@lists.tislabs.com Thu Mar 14 14:21:11 2002 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 g2EMLA425975; Thu, 14 Mar 2002 14:21:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06329 Thu, 14 Mar 2002 16:41:18 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> Date: Thu, 14 Mar 2002 13:50:37 -0800 To: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Remove little-used algorithms from IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:32 PM -0800 3/14/02, Hallam-Baker, Phillip wrote: >Any reason for keeping the MD5 algorithms given their somewhat compromised >status? Yes, two. - As I understand the argument, the "somewhat" is exactly that: there is no known break for real-world use, but there is a strong suspicion that a break could happen. - We want it in there in case of a catastrophic failure of SHA-1 and the related bigger SHAs. >MD5 and SHA are pretty close and share the same internal structure so I >don't think we can really justify MD5 as a fallback to SHA-1, particularly >in the light of the Dobbertin results. I'm happy to add MD5 to the list of "only there because we could" if folks agree with your analysis. >We should anticipate that the AES based SHA-2 algorithms will appear in due >course so it is not as if there would only be one algorithm If those have the same failure relationship to SHA-1 as MD5 does, the argument becomes circular. It is good practice to have a well-understood fallback in case of catastrophic failure. MD5 has a huge amount of implementation experience behind it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 14:23:00 2002 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 g2EMMx426025; Thu, 14 Mar 2002 14:22:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06335 Thu, 14 Mar 2002 16:41:23 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15505.5298.749714.629549@pkoning.dev.equallogic.com> References: <15505.5298.749714.629549@pkoning.dev.equallogic.com> Date: Thu, 14 Mar 2002 13:52:49 -0800 To: Paul Koning From: Paul Hoffman / VPNC Subject: Re: Remove little-used algorithms from IKEv2 Cc: 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 -0500 3/14/02, Paul Koning wrote: >I agree with your list. In fact, I'd add a * to one more: ENCR_CAST. That's OK with me. I left it on the list because I saw people do interop tests 18 months ago, and they said it worked first time. On the other hand, we now have AES, so having a backup to TripleDES (or whatever the English word for the thing that is backed up by TripleDES) is not an issue. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 14:34:21 2002 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 g2EMYK426205; Thu, 14 Mar 2002 14:34:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06545 Thu, 14 Mar 2002 17:00:19 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A0A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Paul Hoffman / VPNC'" , "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: RE: Remove little-used algorithms from IKEv2 Date: Thu, 14 Mar 2002 14:12:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CBA5.63534B10" 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_000_01C1CBA5.63534B10 Content-Type: text/plain; charset="iso-8859-1" > - As I understand the argument, the "somewhat" is exactly that: there > is no known break for real-world use, but there is a strong suspicion > that a break could happen. > > - We want it in there in case of a catastrophic failure of SHA-1 and > the related bigger SHAs. SHA-1 and MD5 are both variants of MD4 that share the same design approach with the addition of extra rounds. SHA-1 also has an initial expansion stage that was added at a later date that appears to have been introduced to defend against the attack Dobbertin discovered recently. In short, if SHA-1 is broken it ia almost certain that MD5 will have been broken. To answer Henry's point about MD5 not being designed by the NSA, well the same pretty much applies to SHA-1. The only NSA input that could be detected was the expansion fix. > If those have the same failure relationship to SHA-1 as MD5 does, the > argument becomes circular. My understanding is that the SHA-2 algorithms are going to be something completely different with no architectural ties to the MD4 scheme. Last I tracked it the discussion appeared to be centered on hashing modes for AES. The performance issue does sound like it could be a reasonable justification, particularly for HMAC-MD5. However there is the counter argument that for most applications DES is perfectly adequate and three times faster than 3DES. Incidentally, any reason why CAST remains on the list? Also in his JFK talk Steve Bellovin made some comments about 3DES still being subject to problems in certain block modes that mean you want to do rekeys at intervals of 2^(56/2)= 2^28 blocks due to the fact that you are using the same 64 byte value to mask each of the 3 DES keys so you will start to double encipher under the same key quite quickly (and in some cipher modes detectably). I don't think we can kill off 3DES, but there should probably be some pretty strong 'don't use this' type advice. Phill ------_=_NextPart_000_01C1CBA5.63534B10 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CBA5.63534B10-- From owner-ipsec@lists.tislabs.com Thu Mar 14 14:38:22 2002 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 g2EMcL426295; Thu, 14 Mar 2002 14:38:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06594 Thu, 14 Mar 2002 17:04:46 -0500 (EST) Message-Id: <200203142214.g2EME3x00484@fatty.lounge.org> To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Remove private-use values from IKEv2 In-Reply-To: Your message of "Thu, 14 Mar 2002 11:08:07 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <481.1016144042.1@tibernian.com> Date: Thu, 14 Mar 2002 14:14:02 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the whole reason for private use values was to roll out new algorithms then dictating a vendor ID payload to say "replace this attribute with that attribute" would make them unnecessary. But that is not the whole reason. Vendor ID payloads are used to identify a like implementation and when two like implementations discover each other they can use the private use values to refer to new capabilities, not merely a new twist on an existing capability. New capabilities are things like a tunnel discovery protocol, a policy download capability, and new techniques at authentication. These do not fit nicely into the "replace this with that" model you are suggesting. Also the critical bit is useful even without private use numbers. It is unreasonable to assume a nationwide flag day to upgrade everyone to new bits that include use of a new payload with an IANA-assigned value. Using the critical bit will allow existing implementations that do not know about this new IANA-assigned payload to safely ignore it or properly discard the message containing the unknown payload. Finally, interoperability problems using private use values is a symptom of a problem. We should fix the problem, not the symptom. Dan. On Thu, 14 Mar 2002 11:08:07 PST you wrote > Private-use values for payloads, attributes, and so on lead to lack > of interoperability and are not needed. The only time private-use > numbers should be used is for limited testing experimental changes to > IKE, but such testing can just as easily be done using vendor-id > payloads. For example, a message with a particular vendor ID payload > could mean "ignore the encryption algorithm specified in the SA > payload and use WhizzyAlg-128 instead." > > The IETF has a long history of problems with private-use anything. > Because implementations often get out of the laboratory, there are > often value clashes. Worse yet, there often demands that, because so > many people are using private value xyz to mean the abc feature, we > should not give abc a regular value when it becomes an RFC, we should > keep using xyz (or at least say in the RFC that xyz is equivalent to > the new number). > > Real testing of new algorithms (as compared to the more common "early > implementation") is rare, and when it happens, it is quite easy to > control with vendor ID payloads. > > Note that, if private-use payload types are forbidden, there is no > longer any use for the critical bit. In that case, the critical bit > should be removed from IKEv2 in order to make the protocol simpler. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 15:17:54 2002 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 g2ENHr427030; Thu, 14 Mar 2002 15:17:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06919 Thu, 14 Mar 2002 17:41:02 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200203142214.g2EME3x00484@fatty.lounge.org> References: <200203142214.g2EME3x00484@fatty.lounge.org> Date: Thu, 14 Mar 2002 14:52:40 -0800 To: Dan Harkins From: Paul Hoffman / VPNC Subject: Re: Remove private-use values from IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:14 PM -0800 3/14/02, Dan Harkins wrote: > Vendor ID payloads are used to identify a like implementation and >when two like implementations discover each other they can use the >private use values to refer to new capabilities, not merely a new >twist on an existing capability. They can, but they don't have to: they can also use additional Vendor ID payloads or parts of the Vendor ID payload that got them synched up. > New capabilities are things like a tunnel discovery protocol, a >policy download capability, and new techniques at authentication. >These do not fit nicely into the "replace this with that" model >you are suggesting. Right: they can be done *in* the Vendor ID payload itself. > Also the critical bit is useful even without private use numbers. It >is unreasonable to assume a nationwide flag day to upgrade everyone to >new bits that include use of a new payload with an IANA-assigned value. >Using the critical bit will allow existing implementations that do not >know about this new IANA-assigned payload to safely ignore it or properly >discard the message containing the unknown payload. And that can be handled other ways as well, such as different numbers for security-critical payloads. Allowing an implementation to decide "I'm saying this is security-critical" instead of the IPsec WG deciding whether or not it is security-critical is a bad design and is sure to lead to interop problems. > Finally, interoperability problems using private use values is a >symptom of a problem. We should fix the problem, not the symptom. Please say more! --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 15:18:58 2002 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 g2ENIw427055; Thu, 14 Mar 2002 15:18:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06895 Thu, 14 Mar 2002 17:34:00 -0500 (EST) Date: Thu, 14 Mar 2002 14:45:10 -0800 (PST) From: Jan Vilhuber To: Dan Harkins cc: Paul Hoffman / VPNC , Subject: Re: Remove private-use values from IKEv2 In-Reply-To: <200203142214.g2EME3x00484@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Mar 2002, Dan Harkins wrote: > If the whole reason for private use values was to roll out new > algorithms then dictating a vendor ID payload to say "replace this > attribute with that attribute" would make them unnecessary. But > that is not the whole reason. > > Vendor ID payloads are used to identify a like implementation and > when two like implementations discover each other they can use the > private use values to refer to new capabilities, not merely a new > twist on an existing capability. > If you add some TLV type encoding into your vendor-id, then you could do the same thing as with a private-range number, couldn't you? I think the biggest issue we've seen is when you wind up with two different vendors trying to use each others' vendor-id's (say one company buys the other), and now the private ranges may conflict. If you hide the private range INSIDE the vendor-id, this can't happen, and I suspect will be just as powerful. This would be much closer to how radius does vendor-specific attributes, i.e. there a SINGLE vendor-id type (like in IKE) which has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [3]. String The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. Radius recommends just using more radius headers in the STRING field (but now you get to control the field in your own TLV's. While using the 'SMI Network Management Private Enterprise Code' may be equivalent to the hash as indicated in the ISAKMP rfc, it just strikes me as a bit more deterministic. I could go either way, though. Encoding the inside of the vendor-id as TLV's (of whatever form you like) seems like it could solve the same problem as the private range values, and be much more resilient to overlap when companies merge. In other words, I don't think we loose any flexibility or power. > New capabilities are things like a tunnel discovery protocol, a > policy download capability, and new techniques at authentication. > These do not fit nicely into the "replace this with that" model > you are suggesting. > > Also the critical bit is useful even without private use numbers. It > is unreasonable to assume a nationwide flag day to upgrade everyone to > new bits that include use of a new payload with an IANA-assigned value. > Using the critical bit will allow existing implementations that do not > know about this new IANA-assigned payload to safely ignore it or properly > discard the message containing the unknown payload. > Wouldn't it be better to use the minor-version number for this? Of course then we'd have to come up with verbiage that says what to do with unknown payloads (ignore and fail? Ignore and continue? Crash and reload?)... jan > Finally, interoperability problems using private use values is a > symptom of a problem. We should fix the problem, not the symptom. > > Dan. > > On Thu, 14 Mar 2002 11:08:07 PST you wrote > > Private-use values for payloads, attributes, and so on lead to lack > > of interoperability and are not needed. The only time private-use > > numbers should be used is for limited testing experimental changes to > > IKE, but such testing can just as easily be done using vendor-id > > payloads. For example, a message with a particular vendor ID payload > > could mean "ignore the encryption algorithm specified in the SA > > payload and use WhizzyAlg-128 instead." > > > > The IETF has a long history of problems with private-use anything. > > Because implementations often get out of the laboratory, there are > > often value clashes. Worse yet, there often demands that, because so > > many people are using private value xyz to mean the abc feature, we > > should not give abc a regular value when it becomes an RFC, we should > > keep using xyz (or at least say in the RFC that xyz is equivalent to > > the new number). > > > > Real testing of new algorithms (as compared to the more common "early > > implementation") is rare, and when it happens, it is quite easy to > > control with vendor ID payloads. > > > > Note that, if private-use payload types are forbidden, there is no > > longer any use for the critical bit. In that case, the critical bit > > should be removed from IKEv2 in order to make the protocol simpler. > > > > --Paul Hoffman, Director > > --VPN Consortium > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 14 15:21:22 2002 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 g2ENLL427113; Thu, 14 Mar 2002 15:21:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06940 Thu, 14 Mar 2002 17:47:46 -0500 (EST) Message-ID: <3C91287B.4070900@alum.mit.edu> Date: Thu, 14 Mar 2002 15:47:23 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrey Jivsov CC: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> <3C90E0EE.6020004@alum.mit.edu> <048501c1cb92$b748cd70$0200a8c0@remedy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For point compression, the claim seems quite broad, flying in the face of prior art, as you note that others have noted. Your explanation of co-factors with ECC sheds no light on the matter for me. I'll note as an aside that because IKE requires Sophie-Germain primes, this is note an issue for modexp groups, either. Hilarie Andrey Jivsov wrote: > > Through P1363, Certicom's intentions to patent point compression have > > been public for some time. The observation that point compression > > is possible has been around for some years, there are several ways to > > choose the meaning of the bit that encodes the second coordinate. > > It's not at all clear that IKE's method infringes Certicom's, to my > > actual knowledge. > > >From patent 6,141,420, claim 32: > > 32. A method according to claim 30 wherein said algebraic curve is an > elliptic curve of the form y.sup.2 +xy=x.sup.3 +ax.sup.2 +b and said other > coordinate is determined by solving a quadratic equation to provide two > possible values of said other coordinate, said identifying information > indicating the appropriate one of said values. > > last bit of (y/x) would qualify for "identifying information". Many people > said that this claim is invalid, but claim is there along with others > (33,36,37). > > > I don't understand the claim about the co-factor. How is it that > > you claim the computation cannot be done with it? > > It can be done, but if one peer uses xyc * G in place of "g^xy" then you > must use it as well, after somehow guessing that the peer is using it. If > xyc * G is patented, you cannot support ECC groups without patent violation. > The solutions are either to disallow cofactor multiplication in the shared > secret, or make sure it is not patented and then document what is the > meaning of g^xy for ECC, since it is logical to assume that "g^xy" is xy * > G. > > > > From owner-ipsec@lists.tislabs.com Thu Mar 14 15:27:55 2002 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 g2ENRs427226; Thu, 14 Mar 2002 15:27:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06964 Thu, 14 Mar 2002 17:51:55 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , Subject: RE: Remove private-use values from IKEv2 Date: Thu, 14 Mar 2002 17:55:35 -0500 Message-ID: <001301c1cbab$5af730c0$1e72788a@ca.alcatel.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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I'm going to disagree with this. I don't think you have fully thought this through from the perspective of an implementer. A typical software implementation of IKE is going to contain a statement resembling: enum { ENCR_DES_IV64=1, ENCR_DES=2, ENCR_3DES=3, ENCR_IDEA=4, ENCR_CAST=5, ENCR_BLOWFISH=6, ... ENCR_MY_EXPERIMENTAL_ALG=123456 } When dealing with private values, it is far more useful to the programmer to be able to define a unique id for each algorithm and read what is in the packet, rather than figuring it our from some multi-variable heuristics. Also, the vendor id has so far been used mostly to advertise capabilities, and not to make actual decisions. e.g: - The NAT-T vid means "I am capable of NAT traversal should we detect a NAT," not "I want to do NAT traversal." - The XAuth v6 vid means "If we do XAuth, it should be version 6," not "I want to do XAuth." The fact that there is a private range means that experimental protocols shouldn't conflict with the IANA-controlled range. The two exceptions have been much discussed and the authors were duly chastised. (And there would be less chance of a value clash in the private range if people would choose random values, rather than always starting at the beginning of the private range.) Also, I fail to see how vendor ids will obviate the need for the critical bit. Let's say that you want to test the NAT-T solution. How do you add the NAT-D payload to the message if there were no private payload ids? Would you interpret the vendor id to mean that the second SA payload in the message should be interpreted as a NAT-D? Seems silly, doesn't it. Probably, you would just choose a number from the high end of the IANA range that is unlikely to be officially assigned any time soon, in which case you basically have a private range again. Finally, some IETF'ers seem to believe that early adoption and/or use of proprietary features is evil, and that this justifies designing protocols which are resistant to any attempt to improve or extend them. I should point out that the IETF has does not have this kind of legal authority over the way its protocols are used, and there is clearly no consensus that any forms of proprietary vendor extension is a bad thing. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Thursday, March 14, 2002 2:08 PM > To: ipsec@lists.tislabs.com > Subject: Remove private-use values from IKEv2 > > > Private-use values for payloads, attributes, and so on lead to lack > of interoperability and are not needed. The only time private-use > numbers should be used is for limited testing experimental changes to > IKE, but such testing can just as easily be done using vendor-id > payloads. For example, a message with a particular vendor ID payload > could mean "ignore the encryption algorithm specified in the SA > payload and use WhizzyAlg-128 instead." > > The IETF has a long history of problems with private-use anything. > Because implementations often get out of the laboratory, there are > often value clashes. Worse yet, there often demands that, because so > many people are using private value xyz to mean the abc feature, we > should not give abc a regular value when it becomes an RFC, we should > keep using xyz (or at least say in the RFC that xyz is equivalent to > the new number). > > Real testing of new algorithms (as compared to the more common "early > implementation") is rare, and when it happens, it is quite easy to > control with vendor ID payloads. > > Note that, if private-use payload types are forbidden, there is no > longer any use for the critical bit. In that case, the critical bit > should be removed from IKEv2 in order to make the protocol simpler. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu Mar 14 16:08:06 2002 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 g2F085428108; Thu, 14 Mar 2002 16:08:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07239 Thu, 14 Mar 2002 18:32:59 -0500 (EST) Message-Id: <200203142342.g2ENgHx00742@fatty.lounge.org> To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Remove private-use values from IKEv2 In-Reply-To: Your message of "Thu, 14 Mar 2002 14:52:40 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <739.1016149336.1@tibernian.com> Date: Thu, 14 Mar 2002 15:42:17 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Mar 2002 14:52:40 PST you wrote > At 2:14 PM -0800 3/14/02, Dan Harkins wrote: > > New capabilities are things like a tunnel discovery protocol, a > >policy download capability, and new techniques at authentication. > >These do not fit nicely into the "replace this with that" model > >you are suggesting. > > Right: they can be done *in* the Vendor ID payload itself. How can you do a tunnel discovery protocol *in* a vendor ID payload? > > Also the critical bit is useful even without private use numbers. It > >is unreasonable to assume a nationwide flag day to upgrade everyone to > >new bits that include use of a new payload with an IANA-assigned value. > >Using the critical bit will allow existing implementations that do not > >know about this new IANA-assigned payload to safely ignore it or properly > >discard the message containing the unknown payload. > > And that can be handled other ways as well, such as different numbers > for security-critical payloads. Allowing an implementation to decide > "I'm saying this is security-critical" instead of the IPsec WG > deciding whether or not it is security-critical is a bad design and > is sure to lead to interop problems. > > > Finally, interoperability problems using private use values is a > >symptom of a problem. We should fix the problem, not the symptom. > > Please say more! The only reason to try to test interoperability of implementations using private use values is because the thing they are doing with private use values cannot be done in a standard fashion and that thing is important enough that multi-vendor interoperability is important. But if it is that important then why don't we come up with a standard way to do it? Politics is one. Bureaucracy and WG inertia is another (that it takes longer for the WG to decide something than for huge companies to go through two complete product cycles is sad). If a solution to a problem that people are demanding a solution to is either politically forbidden or only likely to to come out in 3-5 years then vendors are going to bypass the process. Taking away private use values because people are misusing them (how to standardize something outside of the standardization process) will only cause the workarounds they devise to be more novel and problematic. We should fix the problem that is causing them to misuse the private use values in the first place. Dan. From owner-ipsec@lists.tislabs.com Thu Mar 14 17:21:28 2002 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 g2F1LS429457; Thu, 14 Mar 2002 17:21:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07732 Thu, 14 Mar 2002 19:40:57 -0500 (EST) Message-ID: <3C9142DB.3000805@alum.mit.edu> Date: Thu, 14 Mar 2002 17:39:55 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrey Jivsov CC: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> <3C90E0EE.6020004@alum.mit.edu> <048501c1cb92$b748cd70$0200a8c0@remedy> <3C91287B.4070900@alum.mit.edu> <061301c1cbb6$de4b0770$0200a8c0@remedy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The co-factor should not affect interoperability. What is it about the IKE state that caused a failure? For the modp case, you do not need to do any cofactor checks with IKE. Assuming you use a good random number generator, the probability of choosing a value in the tiny subgroup is negligable. It is less likely than choosing a DES weak key. Furthermore, the IKE generator will always be a square, thus protecting low order bits. Hilarie Andrey Jivsov wrote: >>Your explanation of co-factors with ECC sheds no light on the matter >>for me. >> > > Here is how I understand IKE implementing ECC DH should work. > > Initiator generates secret scalar x, calculates x*G and sends it to the > responder in KE. > Responder generates secret scalar y, calculates y*G and sends it to the > initiator in KE. > Both peers calculate x*y*G and use it in place of "g^xy" for SKEYID_xxx > generation. > > '*' here is a scalar multiplication. > > As it turns out, one well-known vendor interpreted "g^xy" as x*y*c*G. In > this case cofactor multiplication changes the IKE state so that two > implementations cannot interoperate. In addition, I mentioned before my > concerns about patent(s) for cofactor multiplication. > > >> I'll note as an aside that because IKE requires Sophie-Germain >>primes, this is note an issue for modexp groups, either. >> > > This is a good analogy. I would like to see g^xy is interpreted the same way > as it is interpreted for MODP groups, i.e. without cofactor multiplication > in g^xy. > > For MODP cofactor is always 2. This allows implementation to store constant > value 2^(MOPD_prime-1)/2 for each MOPD_prime and then memcmp() received g^x > with this value. If implementation checks for small g^x and g^xy, this > covers the small subgroup attack for any MODP group. > > For ECC Koblitz groups cofactor is 4, but similar checks can be performed. > > > > From owner-ipsec@lists.tislabs.com Thu Mar 14 17:38:16 2002 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 g2F1cF429684; Thu, 14 Mar 2002 17:38:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07898 Thu, 14 Mar 2002 20:02:47 -0500 (EST) To: "Hallam-Baker, Phillip" Cc: "'Sandy Harris'" , ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <2F3EC696EAEED311BB2D009027C3F4F405869A02@vhqpostal.verisign.com> From: Derek Atkins Date: 14 Mar 2002 20:14:30 -0500 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A02@vhqpostal.verisign.com> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hallam-Baker, Phillip" writes: > As it would happen Steve and I appear to be sharing a black > helicopter to the next meeting of the New World Order. Ahh, so YOU'RE the creep that booked that chopper before I could... At least I know where you live! ;) See you at the meeting... Salud! > Phill -derek -- 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 Mar 14 17:43:59 2002 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 g2F1hw429793; Thu, 14 Mar 2002 17:43:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07935 Thu, 14 Mar 2002 20:07:28 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Remove little-used algorithms from IKEv2 References: From: Derek Atkins Date: 14 Mar 2002 20:19:12 -0500 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > In the same vein, all certificate formats other than #4 (X.509 > Certificate - Signature) should be deprecated as well. "PKCS #7 > wrapped X.509 certificate" is particularly bad given that there is no > standard for how to "wrap" a certificate. I'm not sure I agree with the first statement here. I'm willing to be convinced, but I think PGP certificates and maybe raw RSA keys are both reasonable as well. > --Paul Hoffman, Director > --VPN Consortium -derek -- 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 Mar 14 20:51:09 2002 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 g2F4p8406809; Thu, 14 Mar 2002 20:51:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08755 Thu, 14 Mar 2002 23:05:17 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 14 Mar 2002 20:16:54 -0800 To: Derek Atkins From: Paul Hoffman / VPNC Subject: Re: Remove little-used algorithms from IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:19 PM -0500 3/14/02, Derek Atkins wrote: >Paul Hoffman / VPNC writes: > >> In the same vein, all certificate formats other than #4 (X.509 >> Certificate - Signature) should be deprecated as well. "PKCS #7 >> wrapped X.509 certificate" is particularly bad given that there is no >> standard for how to "wrap" a certificate. > >I'm not sure I agree with the first statement here. I'm willing to be >convinced, but I think PGP certificates and maybe raw RSA keys are >both reasonable as well. PGP certificates seem to be in permanent experimental state with no customer demand for them. The same is true for bare RSA keys. Yes, there are probably some people who want them, but there are some people who might want any of the features we are removing. PGP certs don't have any better security features than PKIX certs, and bare RSA keys have fewer security features that PKIX certs. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 20:51:09 2002 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 g2F4p8406810; Thu, 14 Mar 2002 20:51:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08770 Thu, 14 Mar 2002 23:11:56 -0500 (EST) Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Message-ID: <3C9176B6.23706837@lucent.com> Date: Thu, 14 Mar 2002 23:21:10 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Paul Hoffman / VPNC Original-CC: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Remove little-used algorithms from IKEv2 References: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > >Any reason for keeping the MD5 algorithms > > - We want it in there in case of a catastrophic failure of SHA-1 and > the related bigger SHAs. Considering how close internally MD5 and SHA-1 are - I'd expect that any real "catastrophic" failure of one will affect the other... > It is good practice to have a well-understood fallback in case of > catastrophic failure. See above. > MD5 has a huge amount of implementation experience behind it. Why is this of importance...? -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 14 20:51:26 2002 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 g2F4pQ406837; Thu, 14 Mar 2002 20:51:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08811 Thu, 14 Mar 2002 23:19:58 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3C9176B6.23706837@lucent.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> <3C9176B6.23706837@lucent.com> Date: Thu, 14 Mar 2002 20:31:29 -0800 To: Uri Blumenthal From: Paul Hoffman / VPNC Subject: Re: Remove little-used algorithms from IKEv2 Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:21 PM -0500 3/14/02, Uri Blumenthal wrote: >Considering how close internally MD5 and SHA-1 are - I'd expect >that any real "catastrophic" failure of one will affect the >other... I hear a theme here. :-) OK, if that is true, then it is fine to remove MD5 as long as there is at least one other unrelated hash algorithm that can be widely implemented in an interoperable fashion. > > MD5 has a huge amount of implementation experience behind it. > >Why is this of importance...? Because falling back to an algorithm for which there is bad interoperability is bad. It does not serve the IPsec users. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 20:54:27 2002 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 g2F4sQ406884; Thu, 14 Mar 2002 20:54:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08790 Thu, 14 Mar 2002 23:16:08 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200203142342.g2ENgHx00742@fatty.lounge.org> References: <200203142342.g2ENgHx00742@fatty.lounge.org> Date: Thu, 14 Mar 2002 20:26:58 -0800 To: Dan Harkins From: Paul Hoffman / VPNC Subject: Re: Remove private-use values from IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:42 PM -0800 3/14/02, Dan Harkins wrote: >How can you do a tunnel discovery protocol *in* a vendor ID payload? Like Jan said, using the first part as the ID and the rest of the payload as a TLV list (or ASN.1 or whatever). >The only reason to try to test interoperability of implementations using >private use values is because the thing they are doing with private use >values cannot be done in a standard fashion and that thing is important >enough that multi-vendor interoperability is important. > >But if it is that important then why don't we come up with a standard way >to do it? Politics is one. Bureaucracy and WG inertia is another (that >it takes longer for the WG to decide something than for huge companies >to go through two complete product cycles is sad). > >If a solution to a problem that people are demanding a solution to is >either politically forbidden or only likely to to come out in 3-5 years >then vendors are going to bypass the process. > >Taking away private use values because people are misusing them (how to >standardize something outside of the standardization process) will only >cause the workarounds they devise to be more novel and problematic. We >should fix the problem that is causing them to misuse the private use >values in the first place. We completely agree here. Any you have already covered it in Section 10.3: new payload numbers are allocated when getting an RFC published, not by waiting around for the WG. That is the right way to do things, particularly because at some point this WG is supposed to shut down. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 14 21:06:08 2002 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 g2F568407079; Thu, 14 Mar 2002 21:06:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08916 Thu, 14 Mar 2002 23:34:06 -0500 (EST) Date: Thu, 14 Mar 2002 23:45:02 -0500 (EST) From: Henry Spencer To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Remove little-used algorithms from IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Mar 2002, Paul Hoffman / VPNC wrote: > >...I think PGP certificates and maybe raw RSA keys are > >both reasonable as well. > > ...and bare RSA keys have fewer security features that PKIX certs. Some think that having fewer features is an advantage, not a problem. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 14 23:11:25 2002 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 g2F7BO412646; Thu, 14 Mar 2002 23:11:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA10035 Fri, 15 Mar 2002 01:31:49 -0500 (EST) Date: Thu, 14 Mar 2002 22:43:00 -0800 (PST) From: Jan Vilhuber To: Paul Hoffman / VPNC cc: Dan Harkins , Subject: Re: Remove private-use values from IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Mar 2002, Paul Hoffman / VPNC wrote: > At 3:42 PM -0800 3/14/02, Dan Harkins wrote: > >How can you do a tunnel discovery protocol *in* a vendor ID payload? > > Like Jan said, using the first part as the ID and the rest of the > payload as a TLV list (or ASN.1 or whatever). > Turns out that doesn't cover all the bases, though. I'll see if I can come up with a way to cover all the other bases as well (Just sent Dan an email). I don't want to LOOSE functionality in this process (at least not much). I'm not at all for impairing the ability for people to experiment. jan > >The only reason to try to test interoperability of implementations using > >private use values is because the thing they are doing with private use > >values cannot be done in a standard fashion and that thing is important > >enough that multi-vendor interoperability is important. > > > >But if it is that important then why don't we come up with a standard way > >to do it? Politics is one. Bureaucracy and WG inertia is another (that > >it takes longer for the WG to decide something than for huge companies > >to go through two complete product cycles is sad). > > > >If a solution to a problem that people are demanding a solution to is > >either politically forbidden or only likely to to come out in 3-5 years > >then vendors are going to bypass the process. > > > >Taking away private use values because people are misusing them (how to > >standardize something outside of the standardization process) will only > >cause the workarounds they devise to be more novel and problematic. We > >should fix the problem that is causing them to misuse the private use > >values in the first place. > > We completely agree here. Any you have already covered it in Section > 10.3: new payload numbers are allocated when getting an RFC > published, not by waiting around for the WG. That is the right way to > do things, particularly because at some point this WG is supposed to > shut down. > > --Paul Hoffman, Director > --VPN Consortium > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Mar 14 23:14:07 2002 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 g2F7E7413494; Thu, 14 Mar 2002 23:14:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA10085 Fri, 15 Mar 2002 01:40:00 -0500 (EST) Message-Id: <200203150649.g2F6nL301084@fatty.lounge.org> To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Remove private-use values from IKEv2 In-Reply-To: Your message of "Thu, 14 Mar 2002 20:26:58 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1081.1016174961.1@tibernian.com> Date: Thu, 14 Mar 2002 22:49:21 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On: Thu, 14 Mar 2002 20:26:58 PST you wrote > At 3:42 PM -0800 3/14/02, Dan Harkins wrote: > >How can you do a tunnel discovery protocol *in* a vendor ID payload? > > Like Jan said, using the first part as the ID and the rest of the > payload as a TLV list (or ASN.1 or whatever). That will give you a new attribute or some new information to use in the already existing protocol (that is already well-defined). It will not allow you to do things that require, for instance, new exchange types. > >The only reason to try to test interoperability of implementations using > >private use values is because the thing they are doing with private use > >values cannot be done in a standard fashion and that thing is important > >enough that multi-vendor interoperability is important. > > > >But if it is that important then why don't we come up with a standard way > >to do it? Politics is one. Bureaucracy and WG inertia is another (that > >it takes longer for the WG to decide something than for huge companies > >to go through two complete product cycles is sad). > > > >If a solution to a problem that people are demanding a solution to is > >either politically forbidden or only likely to to come out in 3-5 years > >then vendors are going to bypass the process. > > > >Taking away private use values because people are misusing them (how to > >standardize something outside of the standardization process) will only > >cause the workarounds they devise to be more novel and problematic. We > >should fix the problem that is causing them to misuse the private use > >values in the first place. > > We completely agree here. Any you have already covered it in Section > 10.3: new payload numbers are allocated when getting an RFC > published, not by waiting around for the WG. That is the right way to > do things, particularly because at some point this WG is supposed to > shut down. 10.3 deals with payloads. Private use values exist for more than payloads. And I don't believe that the problems I mentioned will necessarily go away when the IPsec WG does. There are currently deployed and widely used implementations which use vendor ID and private use values (not just payloads!) with IKE to do things that are chartered to be solved by the IPSRA and IPSP WGs. Not only that but IANA Considerations are not always followed by IANA! Internet Drafts have obtained IANA assigned numbers in violation of section 11.4 of RFC2409. And there are other I-Ds that have had IANA assign numbers to them for new algorithms and authentication methods. A dangerous practice since I-Ds expire every 6 months. Go check out http://www.iana.org/assignments/ipsec-registry and see hom many names appear instead of RFC numbers under the "reference" column. Some of these may be needed so the question is why aren't they RFCs? For others you should ask yourself if IKEv2 had assigned those numbers itself whether you would've put an (*) next to them for recommended removal. Do we really need two each of EC groups for GF[2^163] and GF[2^283] and GF[2^409] and GF[2^571]? How much interoperability have you seen with with SHA2-384? More than with Tiger? Dan. From owner-ipsec@lists.tislabs.com Fri Mar 15 06:17:41 2002 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 g2FEHe424495; Fri, 15 Mar 2002 06:17:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13275 Fri, 15 Mar 2002 08:34:05 -0500 (EST) Message-ID: <061301c1cbb6$de4b0770$0200a8c0@remedy> From: "Andrey Jivsov" To: "The Purple Streak \(Hilarie Orman\)" Cc: References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> <3C90E0EE.6020004@alum.mit.edu> <048501c1cb92$b748cd70$0200a8c0@remedy> <3C91287B.4070900@alum.mit.edu> Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 Date: Thu, 14 Mar 2002 16:18:01 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 15 Mar 2002 00:20:12.0025 (UTC) FILETIME=[2BF89690:01C1CBB7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Your explanation of co-factors with ECC sheds no light on the matter > for me. Here is how I understand IKE implementing ECC DH should work. Initiator generates secret scalar x, calculates x*G and sends it to the responder in KE. Responder generates secret scalar y, calculates y*G and sends it to the initiator in KE. Both peers calculate x*y*G and use it in place of "g^xy" for SKEYID_xxx generation. '*' here is a scalar multiplication. As it turns out, one well-known vendor interpreted "g^xy" as x*y*c*G. In this case cofactor multiplication changes the IKE state so that two implementations cannot interoperate. In addition, I mentioned before my concerns about patent(s) for cofactor multiplication. > I'll note as an aside that because IKE requires Sophie-Germain > primes, this is note an issue for modexp groups, either. This is a good analogy. I would like to see g^xy is interpreted the same way as it is interpreted for MODP groups, i.e. without cofactor multiplication in g^xy. For MODP cofactor is always 2. This allows implementation to store constant value 2^(MOPD_prime-1)/2 for each MOPD_prime and then memcmp() received g^x with this value. If implementation checks for small g^x and g^xy, this covers the small subgroup attack for any MODP group. For ECC Koblitz groups cofactor is 4, but similar checks can be performed. From owner-ipsec@lists.tislabs.com Fri Mar 15 06:17:42 2002 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 g2FEHf424509; Fri, 15 Mar 2002 06:17:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13274 Fri, 15 Mar 2002 08:34:05 -0500 (EST) Date: Thu, 14 Mar 2002 18:08:34 -0500 Subject: Re: 10 years and no ubiquitous security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf@ietf.org, ipsec@lists.tislabs.com To: William Allen Simpson From: RJ Atkinson In-Reply-To: <3C8FE569.64245AC8@greendragon.com> Message-Id: <68945B5D-37A0-11D6-BDCA-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, March 13, 2002, at 06:49 , William Allen Simpson wrote: > 10 years ago on Tuesday, Phil Karn sprawled out across my hotel > room bed and drew the packet header that became ESP. Actually, that packet header wasn't directly related to ESP, though there aren't but so many ways a security encapsulation can be framed. The SP3 spec, published by NIST more than 10 years ago, was the direct predecessor to ESP. This was noted in RFC-1827, I believe. Credit is due to the (mostly DoD sponsored) group that came up with SP3 long ago. I didn't happen to be at that ad-hoc meeting in San Diego, so I wasn't influenced by it -- and I'm the one who wrote the ESP spec in the early 90s, initially inside the IPng WG as an individual contribution. I decline to comment on the other portions of your posting. Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Fri Mar 15 06:39:26 2002 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 g2FEdQ428027; Fri, 15 Mar 2002 06:39:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13632 Fri, 15 Mar 2002 09:04:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15506.522.496821.516359@pkoning.dev.equallogic.com> Date: Fri, 15 Mar 2002 09:15:38 -0500 From: Paul Koning To: danmcd@east.sun.com Cc: ipsec@lists.tislabs.com Subject: Re: Remove little-used algorithms from IKEv2 References: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com> <200203142153.g2ELrtDq022893@kebe.east.sun.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan McDonald writes: Dan> MD5 is a far better peformer than SHA-1 - especially if you work Dan> around MD5's poor assumptions that all-the-world's-an-Intel. I found it to be about 15% faster than SHA-1, and that on a big endian machine. That number makes sense given the structure of the two algorithms. So, somewhat better, yes. "Far better", no. In hardware implementations, the two tend to be pretty close, and usually faster than the encryption transform so it doesn't matter which you chose as far as performance goes. paul From owner-ipsec@lists.tislabs.com Fri Mar 15 07:38:48 2002 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 g2FFcm429464; Fri, 15 Mar 2002 07:38:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14008 Fri, 15 Mar 2002 09:55:55 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A0F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: RE: Remove little-used algorithms from IKEv2 Date: Fri, 15 Mar 2002 07:08:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CC33.45B73EC0" 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_000_01C1CC33.45B73EC0 Content-Type: text/plain; charset="iso-8859-1" The raw keys are actually very useful since they can be used with an XKMS service for validation. Essentially they become an index to the information bound to them. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Thursday, March 14, 2002 8:19 PM > To: Paul Hoffman / VPNC > Cc: ipsec@lists.tislabs.com > Subject: Re: Remove little-used algorithms from IKEv2 > > > Paul Hoffman / VPNC writes: > > > In the same vein, all certificate formats other than #4 (X.509 > > Certificate - Signature) should be deprecated as well. "PKCS #7 > > wrapped X.509 certificate" is particularly bad given that > there is no > > standard for how to "wrap" a certificate. > > I'm not sure I agree with the first statement here. I'm willing to be > convinced, but I think PGP certificates and maybe raw RSA keys are > both reasonable as well. > > > --Paul Hoffman, Director > > --VPN Consortium > > -derek > > -- > 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 > ------_=_NextPart_000_01C1CC33.45B73EC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1CC33.45B73EC0-- From owner-ipsec@lists.tislabs.com Fri Mar 15 08:21:25 2002 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 g2FGLO402712; Fri, 15 Mar 2002 08:21:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14346 Fri, 15 Mar 2002 10:42:33 -0500 (EST) X-VirusChecked: Checked Message-ID: <8B204D152222D51182B70001028841376DAD93@postmaster.cryptek.com> From: "Hu, Shicai" To: "wsimpson@GreenDragon.com" , > Cc: ipsec@lists.tislabs.com, "," , > Subject: RFC 2521 Date: Fri, 15 Mar 2002 10:41:42 -0500 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 I am working on BITW implementation of IPSec. In some cases, the host behind the IPSec device requires the IPSec device sends a security failures message back to the host whenever IKE or ESP process fails. Is RFC 2521 suppose to provide some guidance or standard to handle this kind of situation? Thanks Shicai Hu Cryptek From owner-ipsec@lists.tislabs.com Fri Mar 15 08:50:23 2002 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 g2FGoN403558; Fri, 15 Mar 2002 08:50:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14586 Fri, 15 Mar 2002 11:13:29 -0500 (EST) Message-ID: <04e701c1cc3e$3b61ac20$36c02ca1@cisco.com> From: "Stephane Beaulieu" To: , "Paul Hoffman / VPNC" References: Subject: Re: Remove little-used algorithms from IKEv2 Date: Fri, 15 Mar 2002 11:26:59 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The early goals of the successor-to-IKE work was to make it simpler > and more interoperable. Continuing to list values for algorithms that > are rarely used or do not have good interoperabilty, or both, goes > against both of those goals. Some should be removed because they have > security properties that are so similar to other algorithms that are > more used that they add nothing to the security of IPsec; they were > added "because we could" but at the expense of interoperability and > simplicity. Some of the algorithms, such as single DES, should be > removed simply because they are a bad idea for security. > > The following lists show the algorithms should be removed from the > IKEv2 spec. Those marked with an asterisk should be removed from > IKEv2. > > Encryption algorithms: > RESERVED 0 > * ENCR_DES_IV64 1 (RFC1827) > * ENCR_DES 2 (RFC2405) > ENCR_3DES 3 (RFC2451) > * ENCR_RC5 4 (RFC2451) > * ENCR_IDEA 5 (RFC2451) > ENCR_CAST 6 (RFC2451) > * ENCR_BLOWFISH 7 (RFC2451) > * ENCR_3IDEA 8 (RFC2451) > * ENCR_DES_IV32 9 > * ENCR_RC4 10 > ENCR_NULL 11 (RFC2410) > ENCR_AES_128 12 I don't think that encr. alg. and hmac alg. are problems of interoperability. As long as everyone implements the MUSTs, everything should be fine. There will always be multiple ciphers offered of which you need to pick one, so the code will exist no matter how many choices there are. I'm not saying that it's not OK to remove those that aren't actually used.... I'm just saying that having more than 3 choices does not affect interoperability (unless of course an implementation can't handle proposals with 200 ciphers in them :) Having said that. I have encountered a situation where some customer (in Europe?) was not allowed to use any other cipher other than IDEA. Can't remember why? Anyone know of a good reason why we can't get rid of IDEA? > > Pseudo-random Functions: > RESERVED 0 > PRF_HMAC_MD5 1 (RFC2104) > PRF_HMAC_SHA 2 (RFC2104) > * PRF_HMAC_TIGER 3 (RFC2104) > > Integrity: > AUTH_HMAC_MD5 1 (RFC2403) > AUTH_HMAC_SHA 2 (RFC2404) > * AUTH_DES_MAC 3 > * AUTH_KPDK_MD5 4 (RFC1826) > > In the same vein, all certificate formats other than #4 (X.509 > Certificate - Signature) should be deprecated as well. "PKCS #7 > wrapped X.509 certificate" is particularly bad given that there is no > standard for how to "wrap" a certificate. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Mar 15 08:53:49 2002 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 g2FGrm403641; Fri, 15 Mar 2002 08:53:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14649 Fri, 15 Mar 2002 11:17:18 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A0F@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869A0F@vhqpostal.verisign.com> Date: Fri, 15 Mar 2002 08:28:25 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Remove little-used algorithms from IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:08 AM -0800 3/15/02, Hallam-Baker, Phillip wrote: >The raw keys are actually very useful since they can be used with an XKMS >service for validation. Essentially they become an index to the information >bound to them. Please review the subject line of this thread. We are talking about IKEv2 here, not XMKS. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Mar 15 09:01:39 2002 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 g2FH1c403865; Fri, 15 Mar 2002 09:01:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14734 Fri, 15 Mar 2002 11:27:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <8B204D152222D51182B70001028841376DAD93@postmaster.cryptek.com> References: <8B204D152222D51182B70001028841376DAD93@postmaster.cryptek.com> Date: Fri, 15 Mar 2002 11:35:31 -0500 To: "Hu, Shicai" From: Stephen Kent Subject: Re: RFC 2521 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:41 AM -0500 3/15/02, Hu, Shicai wrote: >I am working on BITW implementation of IPSec. In some cases, the host behind >the IPSec device requires the IPSec device sends a >security failures message back to the host whenever IKE or ESP process >fails. Is RFC 2521 suppose to provide some guidance or standard >to handle this kind of situation? > >Thanks > > >Shicai Hu >Cryptek The standards do not specify a means for providing this info, but one could reasonably use an ICMP Destination Unreachable, with a suitable error code. I think there have been some recent proposals for new error codes that might be applicable here. Steve From owner-ipsec@lists.tislabs.com Fri Mar 15 11:38:04 2002 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 g2FJc3411527; Fri, 15 Mar 2002 11:38:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16016 Fri, 15 Mar 2002 13:56:57 -0500 (EST) Message-Id: <200203151908.g2FJ8V44019311@kebe.east.sun.com> Subject: Re: Remove little-used algorithms from IKEv2 In-Reply-To: <15506.522.496821.516359@pkoning.dev.equallogic.com> from Paul Koning at "Mar 15, 2002 09:15:38 am" To: Paul Koning Date: Fri, 15 Mar 2002 14:08:31 -0500 (EST) 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 > I found it to be about 15% faster than SHA-1, and that on a big endian > machine. OTOH, if your big-endian machine can dance the little-endian dance better, you get noticeable speedup. The UltraSPARC-tuned MD5 is 30% faster than the non-UltraSPARC-tuned MD5. Using your 15% improvement as a base... M is MD5 S is SHA-1 M' is tuned MD5 M = 0.85S M' = 0.70M M' / 0.70 = 0.85S M' = 0.70 * 0.85S M' = 0.59S If you want to see what I mean precisely, utter this on a sun4m (e.g. SPARC 20) machine running Solaris 7 or later: dis -F MD5Transform /kernel/misc/md5 and utter this on a sun4u (e.g. any UltraSPARC box) dis -F MD5Transform /platform/sun4u/kernel/misc/md5 and note the instruction count savings. > That number makes sense given the structure of the two > algorithms. So, somewhat better, yes. "Far better", no. See my math above for SW and dancing the little-endian dance. > In hardware implementations, the two tend to be pretty close, and > usually faster than the encryption transform so it doesn't matter > which you chose as far as performance goes. Now _this_ I'll buy. Dan From owner-ipsec@lists.tislabs.com Fri Mar 15 11:38:12 2002 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 g2FJcC411559; Fri, 15 Mar 2002 11:38:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15995 Fri, 15 Mar 2002 13:53:14 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3C924543.472EBE78@lucent.com> Date: Fri, 15 Mar 2002 14:02:27 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "The Purple Streak (Hilarie Orman)" Original-CC: ipsec@lists.tislabs.com Subject: Re: Remove SHOULD for elliptic curve groups in IKEv2 References: <49B96FCC784BC54F9675A6B558C3464E5D0DDE@MAIL.NetOctave.com> <3C90E0EE.6020004@alum.mit.edu> <048501c1cb92$b748cd70$0200a8c0@remedy> <3C91287B.4070900@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "The Purple Streak (Hilarie Orman)" wrote: > For point compression, the claim seems quite broad, flying in the face > of prior art, as you note that others have noted. While you seem correct - who'd want to go to court to fight this patent? -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Fri Mar 15 12:44:33 2002 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 g2FKiW414065; Fri, 15 Mar 2002 12:44:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16522 Fri, 15 Mar 2002 15:03:38 -0500 (EST) Message-ID: <3C92525A.8020907@alum.mit.edu> Date: Fri, 15 Mar 2002 12:58:18 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IETF falls into comicbook mode as April 1 approaches. Mild-mannered S. Kent is in reality SuperNoSecMan. He adds the essential anti-replay counter to IPsec protocols and, ... causes people to NOT adopt them? He is a superb document editor and reviewer, and this makes security worse? He has demonstrated years of dedication to the IETF security area, develops BGP security methods, and this is only fuel to fire of his evil? He has such power over time and space that he alone creates security vacuums, causing 30 years of computer and network security research and development to be abandoned (except for this one tiny corner he inexplicably missed in SSL). There's not a single other relevant factor in this whole story, only SuperNoSecMan and his long shadow. But for the fact that Bill Simpson fancies himself a piece of kryptonite, Kent would reign supreme. Next week: Kent reverses HMAC by causing the earth to rotate backwards. Hilarie From owner-ipsec@lists.tislabs.com Fri Mar 15 14:39:53 2002 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 g2FMdr416540; Fri, 15 Mar 2002 14:39:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17213 Fri, 15 Mar 2002 17:01:26 -0500 (EST) Message-Id: <200203151743.g2FHhl200188@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Remove private-use values from IKEv2 In-reply-to: Your message of "Thu, 14 Mar 2002 14:45:10 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Mar 2002 11:42:31 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The desire to do TLV inside the vendor ID payload is a mistake. If TLV is desired, then I would recommend that SOI do away with vendor ID payloads as a way to establish private use space. While the idea is sound, it is not well understood. Instead adopt a number encoding scheme for *ALL* numbers like that which Simpson did for PPP. Every number should have a potential for a vendor number and value in it. ] 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 Fri Mar 15 18:01:09 2002 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 g2G219420384; Fri, 15 Mar 2002 18:01:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18466 Fri, 15 Mar 2002 20:14:25 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <3C8FE569.64245AC8@greendragon.com> In-reply-to: wsimpson's message of "Wed, 13 Mar 2002 18:49:35 -0500". <3C8FE569.64245AC8@greendragon.com> From: Harald Koch MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25725.1016241953.1@elisabeth.cfrq.net> Date: Fri, 15 Mar 2002 20:25:53 -0500 Message-ID: <25727.1016241953@elisabeth.cfrq.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Today, IPSec has insignificant deployment, and the WG goeth on forever. > > ... > > Should I remind folks that at that same San Diego IETF, JI and Phil and > Steve Deering and others of us had a lunch BOF on Mobile-IP? You're not the only one who was "around back then". I think most of us remember the world slightly differently from you. Whatever. People still can't get basic DNS deployment right, and that's quite a bit older than IPsec or Mobile-IP. (I deployed my first nameserver 14 years ago). Unfortunately, standards are irrelevant without ubiquitous deployment of software that is (reasonably) easy to use; it hasn't been a inter-geek-net for a long time. Look at SSH; it *still* isn't completely standardized, but it is much easier to use (and more important, deploy) than IPsec. On the other hand, there's pkix; heavily documented and standardised, but hideously difficult to deploy and use. Of course, IPsec doesn't solve many problems, either, but that's an entirely separate debate. -- Harald Koch "It takes a child to raze a village." -Michael T. Fry From owner-ipsec@lists.tislabs.com Fri Mar 15 18:01:13 2002 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 g2G21D420398; Fri, 15 Mar 2002 18:01:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18568 Fri, 15 Mar 2002 20:25:01 -0500 (EST) Date: Fri, 15 Mar 2002 20:35:55 -0500 From: Ran Canetti Message-Id: <200203160135.UAA22350@ornavella.watson.ibm.com> To: ekr@rtfm.com, ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Looking back at the note that started this thread, it seems that Eric corretly identified the main differences between the two protocols. In a nutshell, the JFK approach prefers a lean and simple protocol, that is easier to code, deploy, and analyze, at the price of somewhat limited functionality. IKEv2 maintains more of the functionality of IKEv1, at the price of additional complexity. No protocol totally dominates the other. There are scenarios where each protocol fares better than the other. Anyway, when deciding between the two protocols for the next generation of IKE, it may be good to keep in mind that IKEv1 will most probably be around for a while (if not for good), living side-by-side with the next generation. Thus, it may be beneficial to have a next generation protocol that best matches the scenarios that IKEv1 doesnt. Here it seems to me that JFK provides a good complement to IKEv1: If you want algorithm negotiation, two-phase structure, pre-shared key mode (and are willing to pay the price) then use IKEv1. If you want a leaner protocol and your particular application does not require these funtions then use JFK. Ran > From: Eric Rescorla > > INTRODUCTION > The WG milestones say that we're supposed to select an IKE-replacement > protocol design in April so it's probably time to start thinking > about this now. Although neither of the leading contenders is > completely nailed down, the direction they're heading is clear > enough that we should be able to pick a winner at MSP or shortly > thereafter. > > In the interest of reaching a decision, here are my top 5 differences > between IKEv2 and JFK. I attempt to discuss each issue a bit but I'm > not taking sides here, just trying to elucidate the relevant > differences in a single document. > > (1) Algorithm Negotiation > (2) 2-phase handshake > (3) Management messages > (4) Non-public-key authentication > (5) DoS protection > > Note that I've deliberately not mentioned the cryptographic core, for > two reasons: > > (1) The cores are actually quite similar. > (2) Both groups seem perfectly willing to adapt a different > core if that's what the WG group wants. (In fact, JFKr adopts > SIGMA's core). > > In my view, the important differences between JFK and IKEv2 are in the > stuff that surrounds the cryptographic core, rather than the core > itself. > > > ALGORITHM NEGOTIATION > IKEv2 follows a fairly traditional approach to algorithm negotiation. > The initiator offers the algorithms he's happy with and the > responder selects among them. This is the same general approach > used by TLS. > > JFK uses two different approaches, one for negotiating protection > of the rest of the handshake and one for the IPsec traffic to be > protected. The handshake protection algorithms are not negotiated--the > responder simply chooses and the initiator can take it or leave it > (with the exception of the DH group, which is proposed by the > responder and chosen by the initiator). The traffic protection > negotiation is conceptually similar to that of IKEv2, with some > simplifications: namely that it uses cipher suites instead of > proposals and has a simplified traffic selector model. The former was > proposed (but rejected) by the IKEv2 authors. > > Discussion: > I'm not sure how relevant this difference is in practice. There's been > a lot of discussion of JFK not negotiating, but that really only > applies to the handshake-protection algorithms. SA algorithms are > negotiated in JFK, just as in IKEv2, albeit with a rather simpler > negotiation model. It would be easy to graft IKEv2's negotiation model > onto JFK (especially since JFK's negotiation is somewhat > underspecified in the spec), or alternately, to simplify IKEv2's > negotiation so it looks more like JFK's. [0] > > > 2-PHASE HANDSHAKE > [This section refers only to keying material establishment. > The next section discusses the use of phase II for management > traffic.] > IKEv2 uses the same two-phase approach as IKE. The peers first > negotiate an SA for protecting the rest of the handshake (the IKE SA) > and then negotiate a second SA for protecting traffic. The idea > here is that you might want to use different SAs for different > traffic flows but don't want to perform a new DH exchange for > each SA establishment. Once you have the "IKE SA" established > you can use that to create other SAs for individual traffic flows. > In order to minimize round trips, you can establish a single > traffic SA at the same time as you establish the IKE SA. > > JFK does not have two phases. If you want multiple SAs you do > multiple JFK handshakes. The rationale is as follows. > > We also feel that JFK is efficient enough that avoiding the overhead > of a full key exchange is not required. Rather than add new SAs > to an existing Phase I SA, we suggest that a full JFK exchange > be initiated instead. We note that the client can also choose > to reuse its exponential, it if wishes to trade perfect forward > secrecy for computation time. > > Discussion: > This ultimately comes down to performance: is it too expensive to > perform a new exchange for each traffic flow or not? Although JFK is > lighter weight than IKEv2, the reduced complexity is largely in > protocol processing, not cryptography. Extensive experience with SSL > performance tuning suggests that the vast majority of the time in both > JFK and IKEv2 will be in the cryptographic computations, which are > essentially identical. > > The question, then, is whether IPsec implementations need to > negotiate a lot of different SAs for any given set of peers or > not. In principle this is an empirical question, but I don't > know if we have enough deployment experience to decide one way > or the other. > > > MANAGEMENT TRAFFIC > Aside from child SA creation, IKEv2 allows a number of other > messages to be transmitted in Phase II, using the IKE SA. These > messages are primarily for management purposes including: > > (1) Dead peer detection > (2) Rekeying > (3) Deletion > > JFK doesn't have a Phase II and uses separate and somewhat ad > hoc mechanisms for each of these: > > (1) Dead peer detection is done with pings. > (2) Rekeying and deletion are both done via a new > SA exchange (you delete by offering a zero lifetime). > > Discussion: > The right approach really depends on how much is going to be done in > the Phase II exchange. Any individual one of these tasks can be > performed by other mechanisms (though JFK SA deletion is > clumsy). However, if we want all three features, it may be better to > simply write them into the protocol rather than develop ad hoc > techniques for each one. > > > NON PUBLIC-KEY AUTHENTICATION > IKEv2 supports both public key authentication and shared-key based > authentication. > > JFK supports only public key authentication, with the expectation that > they will be supported via some outboard protocol. > > Discussion: > As we've seen from mailing list traffic, this is an incredibly > controversial issue. Despite our best efforts to the contrary, > legacy authentication systems which support/use shared keys > aren't going away any time soon and I'm not sure that there's > any point in standing athwart history yelling "Stop". > > > DoS PROTECTION and COOKIE EXCHANGE > IKEv2 uses a variable-round-trip handshake, with 4 messages > under normal circumstances and 6 under attack. The extra > two messages are a simple cookie exchange designed to force > the attacker to prove that he has a round-trip to the responsder. > > JFK uses 4 messages in all cases. DoS protection is achieved by > not creating JFK state until message 3 has been read. > > Discussion: > Both protocols are resistant to DoS attacks based on computational > loading. JFK is slightly more network efficient under attack because > it has two fewer messages. However, it is more susceptible to an IP > fragmentation memory consumption attack where the attacker sends a > series of partial messages to consume reassembly buffers, thus > blocking delivery of legitimate fragmented message 3s. If one assumes > a rather intimate relationship between IKEv2 and the TCP stack, IKEv2 > is less susceptible to this attack. > > > FINAL COMMENTS > Although neither IKEv2 nor JFK is completely finished, I think it's > clear enough what direction they're following to choose which protocol > we're going to pursue. I've attempted to list what I consider to > be the major technical (as opposed to stylistic) differences between > the two protocols. If people feel that I've missed some important > difference, please point it out and I'll try to cover that as well. > > -Ekr > > > > [0] Incidentally, why does JFK have two different sets of algorithms? It > seems like life would be simpler if the algorithms used for traffic > protection were the same as those used for the handshake. I suppose > one might complain if the SA negotiated message integrity only but > I can't see that peers who don't care about confidentiality care about > identity protection. > > From owner-ipsec@lists.tislabs.com Sat Mar 16 00:01:32 2002 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 g2G81V408887; Sat, 16 Mar 2002 00:01:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA20693 Sat, 16 Mar 2002 02:11:35 -0500 (EST) Message-ID: <001101c1ccbb$5c8d4f80$eb551ad4@natasha> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Harald Koch" Cc: References: <3C8FE569.64245AC8@greendragon.com> <25727.1016241953@elisabeth.cfrq.net> Subject: Re: 10 years and no ubiquitous security Date: Sat, 16 Mar 2002 10:22:35 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C1CCD4.7D990D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C1CCD4.7D990D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi looking at your comments, it is true that standards without real = implementation is only a document. However there is always in = engineering the first mile problem and the last mile problem. Per say we = need standards to go beyond. I would say that the early pioneers of = IPsec did something and no one should say it is not countable Ahmed Adas ----- Original Message -----=20 From: Harald Koch=20 To: ipsec@lists.tislabs.com=20 Sent: Saturday, March 16, 2002 4:25 AM Subject: Re: 10 years and no ubiquitous security=20 > Today, IPSec has insignificant deployment, and the WG goeth on = forever. >=20 > ... >=20 > Should I remind folks that at that same San Diego IETF, JI and Phil = and=20 > Steve Deering and others of us had a lunch BOF on Mobile-IP? You're not the only one who was "around back then". I think most of us remember the world slightly differently from you. Whatever. People still can't get basic DNS deployment right, and that's quite a bit older than IPsec or Mobile-IP. (I deployed my first nameserver 14 years ago). Unfortunately, standards are irrelevant without ubiquitous deployment = of software that is (reasonably) easy to use; it hasn't been a inter-geek-net for a long time. Look at SSH; it *still* isn't completely standardized, but it is much easier to use (and more important, deploy) than IPsec. On the other hand, there's pkix; heavily documented and standardised, but hideously difficult to deploy and use. Of course, IPsec doesn't solve many problems, either, but that's an entirely separate debate. --=20 Harald Koch "It takes a child to raze a village." -Michael T. Fry ------=_NextPart_000_000E_01C1CCD4.7D990D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
looking at your comments, it is true = that standards=20 without real implementation is only a document. However there is = always in=20 engineering the first mile problem and the last mile problem. Per say we = need=20 standards to go beyond. I would say that the early pioneers of IPsec did = something and no one should say it is not countable
 
Ahmed Adas
----- Original Message -----
From:=20 Harald Koch =
Sent: Saturday, March 16, 2002 = 4:25=20 AM
Subject: Re: 10 years and no = ubiquitous=20 security

> Today, IPSec has insignificant deployment, and the = WG=20 goeth on forever.
>
> ...
>
> Should I = remind folks=20 that at that same San Diego IETF, JI and Phil and
> Steve = Deering and=20 others of us had a lunch BOF on Mobile-IP?

You're not the only = one who=20 was "around back then". I think most of us
remember the world = slightly=20 differently from you. Whatever.

People still can't get basic = DNS=20 deployment right, and that's quite a
bit older than IPsec or = Mobile-IP. (I=20 deployed my first nameserver 14
years ago).

Unfortunately, = standards=20 are irrelevant without ubiquitous deployment of
software that is=20 (reasonably) easy to use; it hasn't been a
inter-geek-net for a = long=20 time.

Look at SSH; it *still* isn't completely standardized, = but it is=20 much
easier to use (and more important, deploy) than IPsec. On the=20 other
hand, there's pkix; heavily documented and standardised, but=20 hideously
difficult to deploy and use.

Of course, IPsec = doesn't=20 solve many problems, either, but that's an
entirely separate = debate.=20 <ducking>

--
Harald Koch     = <chk@pobox.com>

"It takes a = child to=20 raze a village."
-Michael T. Fry
------=_NextPart_000_000E_01C1CCD4.7D990D40-- From owner-ipsec@lists.tislabs.com Sat Mar 16 00:31:32 2002 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 g2G8VW412596; Sat, 16 Mar 2002 00:31:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA20969 Sat, 16 Mar 2002 02:57:10 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: Comment on draft-ike-implementation regarding nonce size Date: Sat, 16 Mar 2002 03:00:33 -0500 Message-ID: <000301c1ccc0$a78653b0$1e72788a@ca.alcatel.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 In-reply-to: <200203151743.g2FHhl200188@marajade.sandelman.ottawa.on.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nonce size is another characteristic that is neither negotiated nor announced but that the two ends must somehow be able to agree on. Our software accepts anything between 8 and 256, and defaults to 16. These numbers were chosen rather arbitrarily, but we have seen no interoperability failures here. I don't understand your assertion that the two sides need to agree on the nonce size. There is nothing in the protocol which says that the size of the Ni and Nr must match. On the other hand, I agree that IKEv1 does remain curiously silent on how big the nonce ought to be. Our code is notorious for stress-testing others with our 40 byte nonces. I have done my own investigation and I have come to the following conclusions: It does no good for the nonce too be bigger than the keymat you need to generate. If you need a 128 bit key for encryption and a 128 bit key for authentication, then a 32 byte nonce is the maximum -- 16 if you trust the peer's RNG. (If you don't trust your own RNG, then you can generate a large nonce and hash it down to 32 bytes.) Even this is overkill; if you trust your PRF, you can go as low as k*n^2, where n is the number of keys you want to generate from the DH key and k is your safety margin. Since a key size of > 256 is inconceivable at this point, there is no particular reason why IKE needs to support > 64 byte nonces. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Sat Mar 16 10:16:32 2002 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 g2GIGV423325; Sat, 16 Mar 2002 10:16:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23806 Sat, 16 Mar 2002 11:33:40 -0500 (EST) Date: Sat, 16 Mar 2002 11:44:46 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Comment on draft-ike-implementation regarding nonce size In-Reply-To: <000301c1ccc0$a78653b0$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 16 Mar 2002, Andrew Krywaniuk wrote: > I don't understand your assertion that the two sides need to agree on the > nonce size. There is nothing in the protocol which says that the size of the > Ni and Nr must match. Poor phrasing, of a last-minute addition to the draft: the issue is not that the two nonces have to be the same size, but that each side has to be willing to accept the other's nonce size, and there is no specification for allowable range. I'll change this for the next rev. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Mar 16 14:03:49 2002 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 g2GM3m429054; Sat, 16 Mar 2002 14:03:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25097 Sat, 16 Mar 2002 15:43:36 -0500 (EST) Date: Sat, 16 Mar 2002 15:54:42 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203160135.UAA22350@ornavella.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 15 Mar 2002, Ran Canetti wrote: > Anyway, when deciding between the two protocols for the next generation of > IKE, it may be good to keep in mind that IKEv1 will most probably be around > for a while (if not for good), living side-by-side with the next generation. > Thus, it may be beneficial to have a next generation protocol that best > matches the scenarios that IKEv1 doesnt... That depends on whether we think of the new protocol as a supplement to IKEv1, or as something that will slowly replace it. I don't believe there would be nearly this level of interest in adding yet another keying protocol *beside* IKEv1. The intent is definitely to *replace* IKEv1. The fact that there will inevitably be a lengthy transition period should not be confused with an intention for the two to coexist indefinitely. Therefore, if a particular candidate is poor at handling some scenarios that IKEv1 handles well, that *is* definitely a point against it. Perhaps not a fatal flaw, depending on details, but definitely a disadvantage. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Mar 16 14:07:36 2002 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 g2GM7Z429107; Sat, 16 Mar 2002 14:07:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25141 Sat, 16 Mar 2002 15:52:49 -0500 (EST) Message-Id: <200203162102.g2GL2NX06078@fatty.lounge.org> To: Henry Spencer Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Comment on draft-ike-implementation regarding nonce size In-Reply-To: Your message of "Sat, 16 Mar 2002 11:44:46 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6075.1016312543.1@tibernian.com> Date: Sat, 16 Mar 2002 13:02:23 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 16 Mar 2002 11:44:46 EST you wrote > On Sat, 16 Mar 2002, Andrew Krywaniuk wrote: > > I don't understand your assertion that the two sides need to agree on the > > nonce size. There is nothing in the protocol which says that the size of th >e > > Ni and Nr must match. > > Poor phrasing, of a last-minute addition to the draft: the issue is not > that the two nonces have to be the same size, but that each side has to be > willing to accept the other's nonce size, and there is no specification > for allowable range. I'll change this for the next rev. The specification for allowable range is in section 5 of RFC2409. Dan. From owner-ipsec@lists.tislabs.com Sat Mar 16 14:38:28 2002 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 g2GMcR400164; Sat, 16 Mar 2002 14:38:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25262 Sat, 16 Mar 2002 16:17:21 -0500 (EST) Date: Sat, 16 Mar 2002 16:28:27 -0500 (EST) From: Henry Spencer To: Dan Harkins cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Comment on draft-ike-implementation regarding nonce size In-Reply-To: <200203162102.g2GL2NX06078@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 16 Mar 2002, Dan Harkins wrote: > The specification for allowable range is in section 5 of RFC2409. Wups, like I said, last-minute addition... although Andrew's comment about 40-byte nonces being a stress test suggests that a lot of people haven't taken that 8-256 range very seriously. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Mar 16 18:13:56 2002 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 g2H2Du404458; Sat, 16 Mar 2002 18:13:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26594 Sat, 16 Mar 2002 19:50:44 -0500 (EST) Message-ID: <3C93EACC.4615C1E6@greendragon.com> Date: Sat, 16 Mar 2002 20:01:08 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <68945B5D-37A0-11D6-BDCA-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RJ Atkinson wrote: > > On Wednesday, March 13, 2002, at 06:49 , William Allen Simpson wrote: > > 10 years ago on Tuesday, Phil Karn sprawled out across my hotel > > room bed and drew the packet header that became ESP. > > Actually, that packet header wasn't directly related to ESP, > though there aren't but so many ways a security encapsulation > can be framed. > I don't know why you want to denigrate the efforts of long-time IETF participants such as Phil Karn, JI, Perry Metzger and myself, but I just took a bit of time to review the WG meeting minutes. ... > The SP3 spec, published by NIST more than 10 years ago, was the > direct predecessor to ESP. Paul Lambert (an early co-chair) was a big proponent of SP3. Even when we thought we had "rough consensus", Paul would present SP3 yet again! We rejected it every time (at least 3 times). We finally put the matter to rest at Toronto, where the minutes record: "The problems with SP3 include a difficult to read specification, unnecessary fields in the clear header (very minor problem), and closely tied to ISO TP (makes support of TCP and other Internet protocol [sic] slightly harder.)" "Few of these implementations interoperate (a feature?)" You should understand, when the WG is making comments like "failure to interoperate is a feature", that means "wow, what a ***** protocol." (substitute your favorite explicative.) Even Rob Glenn of NIST wasn't advocating SP3! > This was noted in RFC-1827, I believe. We don't usually quibble with your acknowledgments section, or what you felt "influenced" you. > ... I didn't happen to be at that ad-hoc meeting > in San Diego, so I wasn't influenced by it No, but you were at the meetings where swIPe was demonstrated -- ACTUALLY DEMONSTRATED -- and where the the packet headers were discussed. And you also acknowledge "the proposed swIPe security protocol"! So, it would seem your message is rather disingenuous. > and I'm the one > who wrote the ESP spec in the early 90s, initially inside the > IPng WG as an individual contribution. > I believe I have a copy of that early draft. It would be hard to tell whether it is based on SP3, as it is remarkably devoid of packet formats. But "SP3" is not mentioned. Anyway, as recorded in the minutes, I'm the one who wrote the early "requirements draft" for the packet header (circa 1993), and I can testify SP3 **wasn't** an influence.... I'll note that Steve Deering's viewgraphs for Amsterdam (July 1993) specify that SIP Security will be based on "recent IPSec work". Those same viewgraphs document that I already had an implementation, in a KA9Q base -- that would be with Karn's swIPe implementation. Were you there? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Sat Mar 16 18:19:14 2002 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 g2H2JE404561; Sat, 16 Mar 2002 18:19:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26723 Sat, 16 Mar 2002 20:05:33 -0500 (EST) Message-ID: <3C93EEA3.28833ABD@greendragon.com> Date: Sat, 16 Mar 2002 20:17:32 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <0D7FC1D8D861D511AEA70002A52CE5E601A77519@zcard0ke.ca.nortel.com> <3C92525A.8020907@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "The Purple Streak (Hilarie Orman)" wrote: > Mild-mannered S. Kent is in reality SuperNoSecMan. He adds > the essential anti-replay counter to IPsec protocols and, ... > causes people to NOT adopt them? Actually, of course, Steve Kent did not add the counter. It was in swIPe, from the beginning. It was in my drafts, from the beginning. It was certain members of the WG who insisted we didn't need the counter. At least one has admitted he was wrong. Are you ever going to admit you were? Anyway, when we published the first set of RFCs, I carefully documented the need for a Replay Protection sequence number in 1995: "Internet Security Transform Enhancements" This was in the old IETF tradition of posting minority positions when the main WG disagrees. Perhaps you missed reading it? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Sat Mar 16 18:36:11 2002 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 g2H2aB405194; Sat, 16 Mar 2002 18:36:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26798 Sat, 16 Mar 2002 20:17:04 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15507.61778.626238.127131@ryijy.hel.fi.ssh.com> Date: Sun, 17 Mar 2002 03:28:50 +0200 From: Tero Kivinen To: canetti@watson.ibm.com (Ran Canetti), ekr@rtfm.com, ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK References: <200203160135.UAA22350@ornavella.watson.ibm.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 12 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk canetti@watson.ibm.com (Ran Canetti) writes: > Anyway, when deciding between the two protocols for the next generation of > IKE, it may be good to keep in mind that IKEv1 will most probably be around > for a while (if not for good), living side-by-side with the next generation. How long the IKEv1 will live depends quite a lot of the replacement protocol. If the replacement protocol is going to be somewhat similar and offers same functionality than IKEv1 then I think IKEv1 will die much sooner, i.e after both ends have been updated to the next generation protocol they will use that and the IKEv1 functionality can be disabled. Later it will propably be optional "old" compatibility option that is disabled by default and finally removed from the products. If the replacement protocol does not offer things that IKEv1 currently offers and which people actually use, then IKEv1 will stay forever (or at least as long as those features are used). This means that instead of having one small protocol we have one small protocol plus IKEv1 and we must keep the IKEv1 there much longer, because we do not offer same functionality with the newer protocol. > Thus, it may be beneficial to have a next generation protocol that best > matches the scenarios that IKEv1 doesnt. I disagree. I think we want to phase IKEv1 out as soon as possible, meaning that we do want to have protocol that is implementation preserving, and that will can act as a replacement of the IKEv1 from the day one (i.e there is no reason to run IKEv1 if both ends support new version). > Here it seems to me that JFK provides a good complement to IKEv1: If > you want algorithm negotiation, two-phase structure, pre-shared key > mode (and are willing to pay the price) then use IKEv1. Meaning that quite a lot of people keep running IKEv1, and if this seems to be acceptable for you, then why are we doing anything at all? > If you want a leaner protocol and your particular > application does not require these funtions then use JFK. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Mar 16 19:04:39 2002 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 g2H34d405620; Sat, 16 Mar 2002 19:04:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26930 Sat, 16 Mar 2002 20:41:49 -0500 (EST) Message-ID: <000f01c1cd56$7b654340$92f4220a@amer.cisco.com> From: "Scott Fanning" To: "Tero Kivinen" , "Ran Canetti" , , References: <200203160135.UAA22350@ornavella.watson.ibm.com> <15507.61778.626238.127131@ryijy.hel.fi.ssh.com> Subject: Re: Choosing between IKEv2 and JFK Date: Sat, 16 Mar 2002 17:53:05 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This really just brings up the point that if we focus on the requirements, ensure that it aligns to what the user community wants and the WG agrees to them, then, I suspect the march towards IKEv2 will be focused and done effectively in a short period of time. Maybe during this IETF, we can get some general agreement to the requirements, so we can focus on fulfilling them. My 2 cents (I hope of the common variety) Scott ----- Original Message ----- From: "Tero Kivinen" To: "Ran Canetti" ; ; Sent: Saturday, March 16, 2002 5:28 PM Subject: Re: Choosing between IKEv2 and JFK > canetti@watson.ibm.com (Ran Canetti) writes: > > Anyway, when deciding between the two protocols for the next generation of > > IKE, it may be good to keep in mind that IKEv1 will most probably be around > > for a while (if not for good), living side-by-side with the next generation. > > How long the IKEv1 will live depends quite a lot of the replacement > protocol. If the replacement protocol is going to be somewhat similar > and offers same functionality than IKEv1 then I think IKEv1 will die > much sooner, i.e after both ends have been updated to the next > generation protocol they will use that and the IKEv1 functionality can > be disabled. Later it will propably be optional "old" compatibility > option that is disabled by default and finally removed from the > products. > > If the replacement protocol does not offer things that IKEv1 currently > offers and which people actually use, then IKEv1 will stay forever (or > at least as long as those features are used). This means that instead > of having one small protocol we have one small protocol plus IKEv1 and > we must keep the IKEv1 there much longer, because we do not offer same > functionality with the newer protocol. > > > Thus, it may be beneficial to have a next generation protocol that best > > matches the scenarios that IKEv1 doesnt. > > I disagree. I think we want to phase IKEv1 out as soon as possible, > meaning that we do want to have protocol that is implementation > preserving, and that will can act as a replacement of the IKEv1 from > the day one (i.e there is no reason to run IKEv1 if both ends support > new version). > > > Here it seems to me that JFK provides a good complement to IKEv1: If > > you want algorithm negotiation, two-phase structure, pre-shared key > > mode (and are willing to pay the price) then use IKEv1. > > Meaning that quite a lot of people keep running IKEv1, and if this > seems to be acceptable for you, then why are we doing anything at all? > > > If you want a leaner protocol and your particular > > application does not require these funtions then use JFK. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Mar 16 20:16:25 2002 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 g2H4GP407130; Sat, 16 Mar 2002 20:16:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27465 Sat, 16 Mar 2002 21:56:44 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3C940813.F1C91530@lucent.com> Date: Sat, 16 Mar 2002 22:05:55 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ran Canetti Original-CC: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK References: <200203160135.UAA22350@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran Canetti wrote: > In a nutshell, the JFK approach prefers a lean and simple protocol, that is > easier to code, deploy, and analyze, at the price of somewhat limited > functionality. IKEv2 maintains more of the functionality of IKEv1, at the > price of additional complexity........... > There are scenarios where each protocol fares better than the other. Precisely. > Anyway, when deciding between the two protocols for the next generation of > IKE, it may be good to keep in mind that IKEv1 will most probably be around > for a while (if not for good), living side-by-side with the next generation. The stated goal was to come up with a protocol to REPLACE the existing IKE, rather than to supplement it. > Thus, it may be beneficial to have a next generation protocol that best > matches the scenarios that IKEv1 doesnt. Not UNLESS this next generation protocol ALSO best matches the scenarios that IKEv1 does [and that turned out useful :-]. For the above reason. [And if people think that those "unmatched" scenarios are necessary.] > Here it seems to me that JFK provides a good complement to IKEv1.... Ran, but we weren't seeking a complement! Rather a replacement. -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Sun Mar 17 11:10:17 2002 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 g2HJAG411093; Sun, 17 Mar 2002 11:10:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01938 Sun, 17 Mar 2002 13:20:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1CDE2.169E36D8" Subject: RE: Choosing between IKEv2 and JFK Date: Sun, 17 Mar 2002 10:32:26 -0800 Message-ID: <7B8824D690092B4B90B0EF4674750A650231DB68@USEXCH3.us.sonicwall.com> X-MS-TNEF-Correlator: <7B8824D690092B4B90B0EF4674750A650231DB68@USEXCH3.us.sonicwall.com> Thread-Topic: Choosing between IKEv2 and JFK Thread-Index: AcHNWhDZmClf3hpQQCS2mLNN2Z2V4AAh+6Nn From: "Scott Kelly" To: "Tero Kivinen" , "Ran Canetti" , , Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CDE2.169E36D8 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well said - I agree with Tero. Scott -----Original Message----- From: Tero Kivinen Sent: Sat 3/16/2002 5:28 PM To: Ran Canetti; ekr@rtfm.com; ipsec@lists.tislabs.com Cc:=09 Subject: Re: Choosing between IKEv2 and JFK canetti@watson.ibm.com (Ran Canetti) writes: > Anyway, when deciding between the two protocols for the next generation of > IKE, it may be good to keep in mind that IKEv1 will most probably be around > for a while (if not for good), living side-by-side with the next generation.=20 How long the IKEv1 will live depends quite a lot of the replacement protocol. If the replacement protocol is going to be somewhat similar and offers same functionality than IKEv1 then I think IKEv1 will die much sooner, i.e after both ends have been updated to the next generation protocol they will use that and the IKEv1 functionality can be disabled. Later it will propably be optional "old" compatibility option that is disabled by default and finally removed from the products. If the replacement protocol does not offer things that IKEv1 currently offers and which people actually use, then IKEv1 will stay forever (or at least as long as those features are used). This means that instead of having one small protocol we have one small protocol plus IKEv1 and we must keep the IKEv1 there much longer, because we do not offer same functionality with the newer protocol.=20 > Thus, it may be beneficial to have a next generation protocol that best=20 > matches the scenarios that IKEv1 doesnt. I disagree. I think we want to phase IKEv1 out as soon as possible, meaning that we do want to have protocol that is implementation preserving, and that will can act as a replacement of the IKEv1 from the day one (i.e there is no reason to run IKEv1 if both ends support new version). > Here it seems to me that JFK provides a good complement to IKEv1: If > you want algorithm negotiation, two-phase structure, pre-shared key > mode (and are willing to pay the price) then use IKEv1. Meaning that quite a lot of people keep running IKEv1, and if this seems to be acceptable for you, then why are we doing anything at all? > If you want a leaner protocol and your particular=20 > application does not require these funtions then use JFK. --=20 kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ------_=_NextPart_001_01C1CDE2.169E36D8 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhwSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAIwAAAFJFOiBDaG9vc2luZyBiZXR3 ZWVuIElLRXYyIGFuZCBKRksAJAsBBYADAA4AAADSBwMAEQAKACAAGgAAADEBASCAAwAOAAAA0gcD ABEACgAgABoAAAAxAQEJgAEAIQAAADI5RkE3MEZERTU5QkZBNDI5NTNCNzlGQkQ2NDE3QjNEAG8H AQOQBgAcDQAANgAAAAMANgAAAAAAQAA5ANg2nhbizcEBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcA AQAAADkAAABjPVVTO2E9IDtwPVNvbmljV0FMTCwgSW5jLjtsPVVTRVhDSDMtMDIwMzE3MTgzMjI2 Wi0zMzYyOQAAAAAeAEkAAQAAACMAAABSZTogQ2hvb3NpbmcgYmV0d2VlbiBJS0V2MiBhbmQgSkZL AABAAE4AADVNF1PNwQEeAFoAAQAAAA0AAABUZXJvIEtpdmluZW4AAAAAAgFbAAEAAAA5AAAAAAAA AIErH6S+oxAZnW4A3QEPVAIAAAAAVGVybyBLaXZpbmVuAFNNVFAAa2l2aW5lbkBzc2guZmkAAAAA AgFcAAEAAAAUAAAAU01UUDpLSVZJTkVOQFNTSC5GSQAeAF0AAQAAAA0AAABUZXJvIEtpdmluZW4A AAAAAgFeAAEAAAA5AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAVGVybyBLaXZpbmVuAFNNVFAA a2l2aW5lbkBzc2guZmkAAAAAAgFfAAEAAAAUAAAAU01UUDpLSVZJTkVOQFNTSC5GSQAeAGYAAQAA AAUAAABTTVRQAAAAAB4AZwABAAAADwAAAGtpdmluZW5Ac3NoLmZpAAAeAGgAAQAAAAUAAABTTVRQ AAAAAB4AaQABAAAADwAAAGtpdmluZW5Ac3NoLmZpAAAeAHAAAQAAAB8AAABDaG9vc2luZyBiZXR3 ZWVuIElLRXYyIGFuZCBKRksAAAIBcQABAAAAGwAAAAHBzVoQ2ZgpX94aUEAktpizTdmdleAAIfuj ZwAeAHQAAQAAADMAAABSYW4gQ2FuZXR0aTsgZWtyQHJ0Zm0uY29tOyBpcHNlY0BsaXN0cy50aXNs YWJzLmNvbQAAHgAaDAEAAAAMAAAAU2NvdHQgS2VsbHkAHgAdDgEAAAAfAAAAQ2hvb3NpbmcgYmV0 d2VlbiBJS0V2MiBhbmQgSkZLAAACAQkQAQAAALEGAACtBgAAiQsAAExaRnVTvtClAwAKAHJjcGcx MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBXFGVsAyBzC3BkIC1Q IEkgYQnCIAPwdMhoIFQEkG8uCqIKhL0KgFMFoAJAHtoe1C0hAvpPBRBnC4AHQAXQB5AdQKxnZSED HtRGA2E6DILhHnMgS2l2C4AJ8B81HQnwdCNEBhAFQDMvMRQ2LwHQMBRANToykDggUE0e1FRvI0Qa UgORQwBwFCB0aTsgIGVrckAAIW0uHQWgbShABSAUEGNAbFEEAHRzLiggcwtgYmcp4CjxHtRDYyNE HzV1jGJqBZAk9VJlOhIgCGhvbwCQbmcgYo0UIHcJ4R2gS0V2FECjAHAdcEpGSx7aYyfkFEB3JXBz AiAuaWLpKNMgKCeZKR4gBRAOsJZzI0Ae4z4QwG55MCD0eSweIGgt4QWBHWAtWi8eUB4QLbAj0HAD YHRv/xeRBCACEAXANMIkMA7RIjAVJDByJXBpAiAgb2avMmYuETNAHkAgAMB5LYFPNqAtIB1wNXAg awngcPspMAOgbQuAOSET4AVALhK+MR4hHREEYCnANTJiAaB+bDijCsAIYC6AMmY14mH3M1EDEB4Q KAaQNlAfsDXT/TjyKTNAKaAkES1wAJABAPAtYnktP5IeJDYvMGHzK4Ue1EhvB+AXsC1hNMKvOpk/ IR4QAQBwCfBkBCD8cXUyET1hF7AFQDdgNLPzGCALUWNlB4ACMB7UNUb9QeBJRe81NykwBCA48C1S /zlBOMEwUAeAM2AlcQCQOfDdC2ByHtQucjdgZgSQBCD/HUAHgDXQPIAsQDchB0AeQP84oDpBLfQ6 0DTBLfE0sQuA1ms6ijPwZR7UbRrQHmDvMFACIASQODEuPDEBgBKBfwbgHlFEwxPgRGEtkC3hdfxw ZCVwCYA5MkC2HtQ2ue9JJzTBOKA683UUEDo0LnL/Q1hNDC+hHtQ4wTPwHUACYPsJgEHgTFOBBcA4 UTrzNUFPCrA75VtwTUQgIgbwZN4iWQADcAqwKCBiAxBNof8e1FwUOjRJsVnWLYA4oAEB6GF1bFc0 ZiGSO/EYIL8EYERgYIEDYTSyRvdkGtDPKdEe2kf/SQlkbweRPjLbTENO82cEIDpJYwhwGCD/AjA7 8F3VTFQucj2RUMFEsOdbcD3BANB0dWDTVsEzQN9OlDqoKcA4kTXhZURgBcDeKAWwS6UFQD3AYTth baD/QvRt4R5QLTBM4W2QajAYIN9o4RggVrI+4EHgVD2gBCDfB4AGIl6kAIAOsGE8pUXR/1KxLVJR ER0wAMBbJElULcD/UqRyr1sxCkAEIDqULnEe1P9z0VCgO2E5c0NYNMFvkVCj/0MCUTItkC+gVsJz 0WWQZdn/TLIe1E0MQGktwAXAR1ge2v8ywHAwVsA4Oi2QJDBgoDPQ/yGxOUFSsz1wNm5VmSVxLZD3 O2EyZgDAdBPQB5E0wgTw/wnwCsA3IGbbZZICMGMMWcN/CcJH0U71c9EwIEjxOUFwfxPgVtE6lAhg bcNQ8m3ScPctMACQWhEsUEVwkUoDOlL/eeSIhlKzgixJsQdwadFGsv83A0b2B5AEkD9CM0BXVIxC /zsCL6FqAm3SPXBkSkXVV9X/A2Ee1DTCU3A4oHRSPfBRgf94NEmxPjBGMW2gXnKWQTyA9zqFPgFS GHNTUIqwACAe1H188SBsgQCQAiBwAH38SPeVw0sRCeBtZtEj0EzROkP/LrE1MiQQAQCSIjjzXQKO 5N85MjqTLOBj0DJmeQhgiHT3B0A48DIBaDDwJDA48Cgg9zcDatE1EC2JBCnAlwBqIf8YIDNAj/FA ABPhU6E5cF3F/4OxBHExAC5yb4I68koFCrD3TcKNgg3gZTHQTpNWwjqT/x7LIeCLyUUdaaU5c5cB i9PvOpOQlD4BTwFzHtSbdzwi/mNGkAUwWgI105+xatUzYN84oKUDefItUgBweWaDHcD5oCJsP338 Y9GfuG1yNtH/SRgucp+xfTEKwCggZ6BLcf2DR2GYkCmgL6A3E2WXGCD/RRFvkTTBbsI8gDcShDOn FK8usR7FIQArhWskBEAEEExoLmCgHzVTSBIhbX9QoAMAtkQGQmehTaK9b2hBAkBwOi8vd77wLgW6 9C+7WElQU0VD+x5wLSBsunAFQMEfve+++RcpQ7+VHtp9xYAAAAAeADUQAQAAAEQAAAA8N0I4ODI0 RDY5MDA5MkI0QjkwQjBFRjQ2NzQ3NTBBNjUwMjMxREI2OEBVU0VYQ0gzLnVzLnNvbmljd2FsbC5j b20+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAUgAAAFIARQAl ADMAQQAgAEMAaABvAG8AcwBpAG4AZwAgAGIAZQB0AHcAZQBlAG4AIABJAEsARQB2ADIAIABhAG4A ZAAgAEoARgBLAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMMDSaP/hzcEBQAAIMEDApxbizcEBAwDe P+QEAAADAPE/CQAAAB4A+D8BAAAADAAAAFNjb3R0IEtlbGx5AAIB+T8BAAAAVAAAAAAAAADcp0DI wEIQGrS5CAArL+GCAQAAAAAAAAAvTz1TT05JQ1dBTEwsIElOQy4vT1U9U09OSUNXQUxML0NOPVJF Q0lQSUVOVFMvQ049U0tFTExZAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB +z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAA AAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABwAAAFNLRUxMWQAAHgAxQAEAAAAHAAAA U0tFTExZAAAeADJAAQAAAA8AAABraXZpbmVuQHNzaC5maQAAHgAzQAEAAAAPAAAAa2l2aW5lbkBz c2guZmkAAB4AOEABAAAABwAAAFNLRUxMWQAAHgA5QAEAAAACAAAALgAAAAsAKQAAAAAACwAjAAAA AAADAAYQUkypqgMABxBpBwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAFdFTExTQUlELUlB R1JFRVdJVEhURVJPU0NPVFQtLS0tLU9SSUdJTkFMTUVTU0FHRS0tLS0tRlJPTTpURVJPS0lWSU5F TlNFTlQ6U0FUMy8xNi8yMDAyNToyOFBNVE86UkFOQ0EAAAAAAgF/AAEAAABEAAAAPDdCODgyNEQ2 OTAwOTJCNEI5MEIwRUY0Njc0NzUwQTY1MDIzMURCNjhAVVNFWENIMy51cy5zb25pY3dhbGwuY29t PgC4yw== ------_=_NextPart_001_01C1CDE2.169E36D8-- From owner-ipsec@lists.tislabs.com Sun Mar 17 13:45:31 2002 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 g2HLjU415502; Sun, 17 Mar 2002 13:45:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02610 Sun, 17 Mar 2002 16:08:08 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Hu, Shicai" Cc: ipsec@lists.tislabs.com Subject: Re: ICMP Security Failure Message? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 15:19:53 -0600 Message-Id: <20020317211954.E520A7B4B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <8B204D152222D51182B70001028841376DAD41@postmaster.cryptek.com>, "Hu , Shicai" writes: >RFC 2521: ICMP Security Failure Message >Category: Experimental >(What does a category of "experimental" mean? Does IETF assign somebody to >do some experiment on this RFC document?) > See section 4.2.1 of RFC 2026. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Mar 18 08:58:39 2002 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 g2IGwd429224; Mon, 18 Mar 2002 08:58:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07829 Mon, 18 Mar 2002 11:06:55 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: William Allen Simpson Cc: ietf@ietf.org, ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 2002 10:18:33 -0600 Message-Id: <20020318161833.084837B4B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3C93EEA3.28833ABD@greendragon.com>, William Allen Simpson writes: >"The Purple Streak (Hilarie Orman)" wrote: >> Mild-mannered S. Kent is in reality SuperNoSecMan. He adds >> the essential anti-replay counter to IPsec protocols and, ... >> causes people to NOT adopt them? > >Actually, of course, Steve Kent did not add the counter. It was in >swIPe, from the beginning. It was in my drafts, from the beginning. > >It was certain members of the WG who insisted we didn't need the >counter. At least one has admitted he was wrong. Are you ever going to >admit you were? > >Anyway, when we published the first set of RFCs, I carefully documented >the need for a Replay Protection sequence number in 1995: > "Internet Security Transform Enhancements" > Right. The only copy I could find was from 1996, but I don't think that that difference is important. (http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt) The problem with it -- and the reason I had objected to sequence numbers -- is that it never justified *why* they were necessary, beyond rather minor DoS prevention. It simply said "replay protection provides cryptographically secure at-most-once datagram delivery." But there was no analysis of why one would want that. The same is true of the swIPe paper and I-D -- there was no analysis beyond saying "replay protection". When attacks on confidentiality were developed that exploited the lack of replay prevention, I changed my mind and strongly supported sequence numbers. The difference is that there was then a reason. For what it's worth, Kent applauded the restoration of the counter -- he knew it was necessary. But Bill, I'm trying to understand what your point is. We can't force people to use security. IPsec is standard in most major business operating systems (Win2K, Solaris, *BSD, etc.) and available for for Linux. There are hardware solutions -- I have a small IPsec box with me in Minneapolis. But except for VPN scenarios, most people choose not to use it. I think there's a lesson there, but I fail to see how Steve Kent or any of the other players in the history of IPsec are at all at fault. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Mar 18 08:58:43 2002 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 g2IGwg429237; Mon, 18 Mar 2002 08:58:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07803 Mon, 18 Mar 2002 11:05:25 -0500 (EST) Message-Id: <5.1.0.14.0.20020317130516.00af52e8@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Mar 2002 13:12:59 -0800 To: William Allen Simpson From: Brian Lloyd Subject: Re: 10 years and no ubiquitous security Cc: ietf@ietf.org, ipsec@lists.tislabs.com In-Reply-To: <3C8FE569.64245AC8@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:49 PM 3/13/2002, William Allen Simpson wrote: >10 years ago tomorrow, Brian Lloyd and I had a "rubber hose" lunch >meeting with Steve Kent, who as a member of the IAB had refused to allow >the PPP WG to publish CHAP in our RFC as an official authentication >protocol. (He had previously mandated that we remove all security >protocol negotiation.) He backed down, but we had to change the name >from "cryptographic" to "challenge". Well, I am not sure it was a "rubber hose" lunch although I do remember being annoyed. As I recall Steve pointed out that CHAP was not strong by cryptographic authentication standards and he did not want to attach a seal-of-approval on that basis. As I recall, I argued that the alternative then in use was clear-text passwords and asked if he felt that CHAP was superior to that. He did and agreed to sign-off on CHAP on that basis. I understood that he wanted good cryptographic authentication but we finally agreed that anything better than passwords was a good thing to have. I am not entirely sure that I would blame the failure to adopt a coherent set of security standards entirely on Steve Kent. Brian Lloyd brian@lloyd.com +1.530.676.1113 - voice +1.360.838.9669 - fax From owner-ipsec@lists.tislabs.com Mon Mar 18 08:58:46 2002 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 g2IGwk429248; Mon, 18 Mar 2002 08:58:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08211 Mon, 18 Mar 2002 11:23:13 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3D8F@NS-CA> From: Michael Choung Shieh To: "'ipsec@lists.tislabs.com '" Subject: Is JFK DOS proof when PFS is required? Date: Mon, 18 Mar 2002 08:34:01 -0800 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 The second message of JFKi and JFKr requires DH operation: JFKi: Message 2, R->I: Ni, Nr, g^r, GRPINFOr, IDr, SIG{r}(g^r, GRPINFOr), HMAC{HKr}(Ni, Nr, g^i, g^r) JKTr: Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKr}(Ni, Nr, g^r) Although the authors lessen the fact by introducing "forward secrecy interval". However, when PFS is required, the responder will need to generate g^r (and SIG() in JFKi) for every ike message 1 from any sources thus subject to DOS attack. Without PFS, once the DH is compromised, multiple tunnels across multiple peers are compromised, since Ni and Nr are sent in clear. This will be a major problem when implementing the protocol. Michael Shieh From owner-ipsec@lists.tislabs.com Mon Mar 18 09:01:39 2002 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 g2IH1c429357; Mon, 18 Mar 2002 09:01:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07765 Mon, 18 Mar 2002 11:03:25 -0500 (EST) Message-Id: <200203170326.g2H3QOUe013450@nyarlathotep.keromytis.org> To: Uri Blumenthal Cc: Ran Canetti , ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-reply-to: Your message of "Sat, 16 Mar 2002 22:05:55 EST." <3C940813.F1C91530@lucent.com> Date: Sat, 16 Mar 2002 22:26:24 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There seems to be a misconception that we need IKEv1 or a design very similar to it to do the things people consider useful. As far as I can tell, these things include (but are probably not limited to): - IPSRA kinds of things - dead peer detection - error messages - SA deletion The latter is in fact provided by JFK; extensive informational messages are needed only if there are many potential reasons for protocol failure (JFK does provide for some --- we just haven't defined 30-odd different error codes, since they are not needed); as for remote tunnel configuration and dead peer detection, my feeling is that they are both somewhat fuzzy issues and that they are not necessary to include in the core protocol -- they can just as easily be implemented as supplemental *application* protocols. This allows for much simpler implementations and better replaceability of such components. After all, we don't want to be changing the protocol every so often --- I would argue that, ideally, we don't want to be changing the implementations all that often either. -Angelos From owner-ipsec@lists.tislabs.com Mon Mar 18 10:48:19 2002 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 g2IImI405337; Mon, 18 Mar 2002 10:48:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09127 Mon, 18 Mar 2002 13:09:09 -0500 (EST) To: "Steven M. Bellovin" cc: William Allen Simpson , ietf@ietf.org, ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security In-reply-to: Your message of "Mon, 18 Mar 2002 10:18:33 -0600." <20020318161833.084837B4B@berkshire.research.att.com> Date: Tue, 19 Mar 2002 03:33:18 +1000 Message-ID: <14175.1016472798@durian.apnic.net> From: George Michaelson X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But Bill, I'm trying to understand what your point is. We can't force > people to use security. IPsec is standard in most major business > operating systems (Win2K, Solaris, *BSD, etc.) and available for for > Linux. There are hardware solutions -- I have a small IPsec box with > me in Minneapolis. But except for VPN scenarios, most people choose > not to use it. I think there's a lesson there, but I fail to see how > Steve Kent or any of the other players in the history of IPsec are at > all at fault. > > --Steve Bellovin, http://www.research.att.com/~smb I would like to comment on the other issue in this paragraph, about why IPSEC deployment might lack vigour. I set up VPN over IPSEC on a national academic network with 40mbit backbone and 10/100 mbit site linkspeeds. the best end-to-end performance I could get was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP. Stuff like pMTU end-to-end is absolutely vital to make non-aware clients and servers cope with encapsulated protocols. I have also played with the client side code, and found that UDP protocols like Windows SMB do not work well on noisy/long-delay links. THis repeats the experience of encapsulated LAT some of us ex-DECheads remember: you can't fix bad protocol experiences by wrapping them in better protocols if the end-to-end behaviour depends on the badness (eg timer dependencies) Please don't get me wrong: I use IPSEC, I like IPSEC, but I have to recognize that off the beaten track, or for some (very useful) contexts it turns out not to work as well as we'd like, for reasons probably not to do with IPSEC per se, but the general state of the network. When you factor in that most of the 'simple' things can be done equally well in SSH, or by less clued people using non-secured tunnels, it gets harder to do a sell on IPSEC. which is a shame, because I really like IP layer abstracted methods, and the idea of generic infrastructure rather than applications-level point solutions. cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3858 3100 | Australia Fax: +61 7 3858 3199 | http://www.apnic.net From owner-ipsec@lists.tislabs.com Mon Mar 18 10:48:19 2002 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 g2IImI405336; Mon, 18 Mar 2002 10:48:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09111 Mon, 18 Mar 2002 13:08:08 -0500 (EST) Date: Mon, 18 Mar 2002 12:19:50 -0500 Subject: Re: 10 years and no ubiquitous security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf@ietf.org, ipsec@lists.tislabs.com To: William Allen Simpson From: RJ Atkinson In-Reply-To: <3C93EACC.4615C1E6@greendragon.com> Message-Id: <5AB467CC-3A94-11D6-84DB-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote: >> ... I didn't happen to be at that ad-hoc meeting >> in San Diego, so I wasn't influenced by it > > No, but you were at the meetings where swIPe was demonstrated -- > ACTUALLY DEMONSTRATED -- and where the the packet headers were > discussed. > > And you also acknowledge "the proposed swIPe security protocol"! > > So, it would seem your message is rather disingenuous. We had ESP up and running MUCH MUCH earlier than you seem to think. And the swIPe documents describe something with visible differences from the ESP that resulted in RFC-1827. Your atttempt to rewrite history is noted, but neither appreciated nor accurate. Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Mon Mar 18 11:08:24 2002 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 g2IJ8O406003; Mon, 18 Mar 2002 11:08:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09468 Mon, 18 Mar 2002 13:32:33 -0500 (EST) Message-ID: <3C9634D5.C2FF8339@greendragon.com> Date: Mon, 18 Mar 2002 13:44:10 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <5AB467CC-3A94-11D6-84DB-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RJ Atkinson wrote: > > On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote: > >> ... I didn't happen to be at that ad-hoc meeting > >> in San Diego, so I wasn't influenced by it > > > > No, but you were at the meetings where swIPe was demonstrated -- > > ACTUALLY DEMONSTRATED -- and where the the packet headers were > > discussed. > > > We had ESP up and running MUCH MUCH earlier than you seem > to think. Ran, you are listed in the proceedings of July 1992 as having attended the IPSec BOF. Did you have an SP3 implementation at that time? If so, why didn't you demonstrate it? > And the swIPe documents describe something with > visible differences from the ESP that resulted in RFC-1827. > The ESP in RFC-1827 has one and only one field: +-------------+--------------------+------------+---------------------+ | Security Association Identifier (SPI), 32 bits | +=============+====================+============+=====================+ (A field that *I* named, Security Parameters Index ("SPI"), which *you* mis-typed, for the record!) That, amazingly enough, bears no resemblence to what-so-ever to SP3, but is exactly what was implemented for the version of swIPe that I was using. > > And you also acknowledge "the proposed swIPe security protocol"! > > > > So, it would seem your message is rather disingenuous. > > Your atttempt to rewrite history is noted, but neither appreciated > nor accurate. > You cannot even keep your lies straight when the documents are readily available on-line. Your acknowlegments read: Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol.... Ran, you are a disgrace to the profession. I refuse to comment further on your posts. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Mon Mar 18 11:10:42 2002 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 g2IJAf406078; Mon, 18 Mar 2002 11:10:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09508 Mon, 18 Mar 2002 13:36:36 -0500 (EST) Message-Id: <200203181848.g2IImMor017853@kebe.east.sun.com> Subject: Re: 10 years and no ubiquitous security In-Reply-To: <14175.1016472798@durian.apnic.net> from George Michaelson at "Mar 19, 2002 03:33:18 am" To: George Michaelson Date: Mon, 18 Mar 2002 13:48:22 -0500 (EST) CC: ietf@ietf.org, 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 > I set up VPN over IPSEC on a national academic network with 40mbit backbone > and 10/100 mbit site linkspeeds. the best end-to-end performance I could get > was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP. You should try (again?) a more modern implementation. > Stuff like pMTU end-to-end is absolutely vital to make non-aware clients > and servers cope with encapsulated protocols. Agreed. Many of us _do_ understand these issues. Dan From owner-ipsec@lists.tislabs.com Mon Mar 18 11:13:31 2002 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 g2IJDU406167; Mon, 18 Mar 2002 11:13:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09542 Mon, 18 Mar 2002 13:40:17 -0500 (EST) From: "Khaja E. Ahmed" To: "Tero Kivinen" , "Ran Canetti" , , Subject: RE: Choosing between IKEv2 and JFK Date: Mon, 18 Mar 2002 10:49:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <15507.61778.626238.127131@ryijy.hel.fi.ssh.com> importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Anyway, when deciding between the two protocols for the next > generation of > > IKE, it may be good to keep in mind that IKEv1 will most > probably be around > > for a while (if not for good), living side-by-side with the > next generation. > > How long the IKEv1 will live depends quite a lot of the replacement > protocol. If the replacement protocol is going to be somewhat similar > and offers same functionality than IKEv1 then I think IKEv1 will die > much sooner, i.e after both ends have been updated to the next > generation protocol they will use that and the IKEv1 functionality can > be disabled. Later it will propably be optional "old" compatibility > option that is disabled by default and finally removed from the > products. > > If the replacement protocol does not offer things that IKEv1 currently > offers and which people actually use, then IKEv1 will stay forever (or > at least as long as those features are used). This means that instead > of having one small protocol we have one small protocol plus IKEv1 and > we must keep the IKEv1 there much longer, because we do not offer same > functionality with the newer protocol. I am not sure that this holds true in all cases and more importantly I am not sure how we would ensure that the outcome would be as you predict. It would be pain to support both IKEv1 and IKEv2 in a product both from a product development perspective and from produce deployment and administration perspective. I bring this up because I find myself regularly forced to deal with deficient protocol immortality. Six years after arrival of SSL 3.0, which does everything that 2.0 did and does it better SSL 2.0 is still around, we are still trying to support it because it is enabled by default in most products, many OEMs want it just because they are not sure if someone may want it. Worse yet, at least one site (Schwab.com) *requires* that you connect to it with SSL 2.0 and does *not* work if SSL 2.0 support is disabled in a browser. Clearly, this WG can not prohibit using deprecated/obsolete protocols and modes but can we do something to facilitate or hasten the demise of 'replaced' protocols? Khaja From owner-ipsec@lists.tislabs.com Mon Mar 18 12:44:54 2002 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 g2IKis410337; Mon, 18 Mar 2002 12:44:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10042 Mon, 18 Mar 2002 15:05:50 -0500 (EST) Message-ID: <3C964A5C.2FBBBF12@greendragon.com> Date: Mon, 18 Mar 2002 15:16:12 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <20020318161833.084837B4B@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <3C93EEA3.28833ABD@greendragon.com>, William Allen Simpson writes: > Right. The only copy I could find was from 1996, but I don't think > that that difference is important. > (http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt) Remember, the WG chair objected to my drafts being draft-ietf-ipsec-, and so they were reissued in 1996 as draft-simpson-, restarting at -00. To the middle of your message, why is it a problem that we were so brilliant that we prevented a threat before somebody else documented the attack? We are engineers, not cryptanalysts. It seemed obvious. Anyway, _you_ had the integrity to admit you were wrong. Thanks! (I just wasn't sure I should mention your name in a negative context.) > ... But except for VPN scenarios, most people choose > not to use it. I think there's a lesson there, but I fail to see how > Steve Kent or any of the other players in the history of IPsec are at > all at fault. > Because the so-called "standard" is hard to understand, hard to implement, hard to install, and hard to use -- and now verified to have security failures, some of which I documented at least 6 years ago. Other than that? As you may remember, Photuris was designed to start itself automatically, without significant user intervention. (Somebody else just noticed the ICMP Security Failures messages.) Another of the things I used to do: have an Operational Considerations section in my drafts. Anything with a lot of configuration and dependencies has too many points of failure. But I'm so disgusted with Ran denying that other people did any work, or that he knew about it, that I'm hoping the thread will end. Surely, the secretariate mistyped that string in 1992 (on page 363). Oh well, it's not the first time I've caught him in a lie.... The point was made: we've been delayed and obfuscated into oblivion. The WG has been spinning its wheels for a decade. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Mon Mar 18 15:09:49 2002 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 g2IN9m413696; Mon, 18 Mar 2002 15:09:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10935 Mon, 18 Mar 2002 17:35:34 -0500 (EST) Date: Mon, 18 Mar 2002 17:45:19 -0500 (EST) From: Henry Spencer To: "Angelos D. Keromytis" cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK In-Reply-To: <200203170326.g2H3QOUe013450@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 16 Mar 2002, Angelos D. Keromytis wrote: > ...as for remote tunnel configuration and dead > peer detection, my feeling is that they are both somewhat fuzzy issues and > that they are not necessary to include in the core protocol -- they can just > as easily be implemented as supplemental *application* protocols. This allows > for much simpler implementations and better replaceability of such components. I agree when it comes to the configuration stuff, but some way of checking whether a peer is alive and still knows about current SAs -- without incurring the overhead of renegotiation -- is highly desirable. This cannot, in general, be done with application-level protocols: IPsec tunnels don't necessarily carry gateway-to-gateway traffic. I note that the latest JFK draft tries to weasel out of this by saying "well, if you want to do that, insist on being a special case"... but this is an important requirement, and having to choose between interoperability and being able to test for a black hole is -- to put it bluntly -- a wretched design botch. The capability to do such a test needs to be a standard facility, reliably present. Whether it is done using a phase-1 connection in the manner of IKE is not important... but the son-of-IKE specification must describe how to do it and must expicitly insist that all implementations provide it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 18 15:10:03 2002 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 g2INA3413716; Mon, 18 Mar 2002 15:10:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10801 Mon, 18 Mar 2002 17:14:52 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3D93@NS-CA> From: Michael Choung Shieh To: "'Khaja E. Ahmed '" , "'Tero Kivinen '" , "'Ran Canetti '" , "'ekr@rtfm.com '" , "'ipsec@lists.tislabs.com '" Subject: RE: Choosing between IKEv2 and JFK Date: Mon, 18 Mar 2002 14:25:14 -0800 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 I think it's different problem. in case of SSL, 3.0 can support all 2.0 features but the users just choose not to upgrade. However, if IKEv2 cannot support widely-used features in v1, then users are forced to use IKEv1 (even IKEv2 has other great features). They won't be able to upgrade without changing their current practice, which is the most difficult part for a new protocol to get acceptance. Michael Shieh -----Original Message----- From: Khaja E. Ahmed To: Tero Kivinen; Ran Canetti; ekr@rtfm.com; ipsec@lists.tislabs.com Sent: 3/18/02 10:49 AM Subject: RE: Choosing between IKEv2 and JFK > > Anyway, when deciding between the two protocols for the next > generation of > > IKE, it may be good to keep in mind that IKEv1 will most > probably be around > > for a while (if not for good), living side-by-side with the > next generation. > > How long the IKEv1 will live depends quite a lot of the replacement > protocol. If the replacement protocol is going to be somewhat similar > and offers same functionality than IKEv1 then I think IKEv1 will die > much sooner, i.e after both ends have been updated to the next > generation protocol they will use that and the IKEv1 functionality can > be disabled. Later it will propably be optional "old" compatibility > option that is disabled by default and finally removed from the > products. > > If the replacement protocol does not offer things that IKEv1 currently > offers and which people actually use, then IKEv1 will stay forever (or > at least as long as those features are used). This means that instead > of having one small protocol we have one small protocol plus IKEv1 and > we must keep the IKEv1 there much longer, because we do not offer same > functionality with the newer protocol. I am not sure that this holds true in all cases and more importantly I am not sure how we would ensure that the outcome would be as you predict. It would be pain to support both IKEv1 and IKEv2 in a product both from a product development perspective and from produce deployment and administration perspective. I bring this up because I find myself regularly forced to deal with deficient protocol immortality. Six years after arrival of SSL 3.0, which does everything that 2.0 did and does it better SSL 2.0 is still around, we are still trying to support it because it is enabled by default in most products, many OEMs want it just because they are not sure if someone may want it. Worse yet, at least one site (Schwab.com) *requires* that you connect to it with SSL 2.0 and does *not* work if SSL 2.0 support is disabled in a browser. Clearly, this WG can not prohibit using deprecated/obsolete protocols and modes but can we do something to facilitate or hasten the demise of 'replaced' protocols? Khaja From owner-ipsec@lists.tislabs.com Mon Mar 18 15:23:51 2002 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 g2INNo414061; Mon, 18 Mar 2002 15:23:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11032 Mon, 18 Mar 2002 17:50:07 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <000d01c1c9da$2a6e9bf0$1e72788a@ca.alcatel.com> References: <000d01c1c9da$2a6e9bf0$1e72788a@ca.alcatel.com> Date: Mon, 18 Mar 2002 15:36:15 -0500 To: From: Stephen Kent Subject: RE: Addresses in traffic selectors in IKEv2 Cc: "'Paul Hoffman / VPNC'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:25 AM -0500 3/12/02, Andrew Krywaniuk wrote: >I agree with this. There are lots of little pitfalls that I have seen when >dealing with subnets: > >e.g. does 192.168.10.0/24 == 192.168.10.30/24? Not if you use memcmp. > >What happens if someone receives a QM1 containing subnets and the peer >returns a QM2 containing ranges? > >We would have liked to implement QM using only ranges, but we were forced to >convert to subnets whenever possible because some of the other IPsec >implementations aren't (or at least weren't at the time) able to handle >ranges. > >There is no advantage to having multiple types in this case, so we should >ditch the less generic ones. > Paul makes a good point. Ranges can be used to express what masks can express and so we should probably do away with masks. We should also prohibit trivial ranges that define a single address. We are adding enumerated lists for all selector types, and that should replace the singleton selector values. Any more suggestions for reducing ambiguity in expressing selectors? Steve From owner-ipsec@lists.tislabs.com Mon Mar 18 16:05:19 2002 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 g2J05I415171; Mon, 18 Mar 2002 16:05:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11276 Mon, 18 Mar 2002 18:29:33 -0500 (EST) Delivered-To: alias-sactivex:com-jcb@SACTIVEX.COM X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Message-ID: <3C9634D5.C2FF8339@greendragon.com> Date: Mon, 18 Mar 2002 13:44:10 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security References: <5AB467CC-3A94-11D6-84DB-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2002 21:36:26.0848 (UTC) FILETIME=[F55C8E00:01C1CEC4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RJ Atkinson wrote: > > On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote: > >> ... I didn't happen to be at that ad-hoc meeting > >> in San Diego, so I wasn't influenced by it > > > > No, but you were at the meetings where swIPe was demonstrated -- > > ACTUALLY DEMONSTRATED -- and where the the packet headers were > > discussed. > > > We had ESP up and running MUCH MUCH earlier than you seem > to think. Ran, you are listed in the proceedings of July 1992 as having attended the IPSec BOF. Did you have an SP3 implementation at that time? If so, why didn't you demonstrate it? > And the swIPe documents describe something with > visible differences from the ESP that resulted in RFC-1827. > The ESP in RFC-1827 has one and only one field: +-------------+--------------------+------------+---------------------+ | Security Association Identifier (SPI), 32 bits | +=============+====================+============+=====================+ (A field that *I* named, Security Parameters Index ("SPI"), which *you* mis-typed, for the record!) That, amazingly enough, bears no resemblence to what-so-ever to SP3, but is exactly what was implemented for the version of swIPe that I was using. > > And you also acknowledge "the proposed swIPe security protocol"! > > > > So, it would seem your message is rather disingenuous. > > Your atttempt to rewrite history is noted, but neither appreciated > nor accurate. > You cannot even keep your lies straight when the documents are readily available on-line. Your acknowlegments read: Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol.... Ran, you are a disgrace to the profession. I refuse to comment further on your posts. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Mon Mar 18 16:24:47 2002 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 g2J0Ok415684; Mon, 18 Mar 2002 16:24:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11362 Mon, 18 Mar 2002 18:52:07 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" Subject: Bake-Off Results from Espoo Date: Mon, 18 Mar 2002 16:00:57 -0800 Message-ID: <001601c1ced9$25b182e0$c7d0fea9@vesta> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Is there any written record of the results from the last bake-off? E.g., a list of problems encountered, etc. Thanks. Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Mon Mar 18 16:55:27 2002 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 g2J0tQ416275; Mon, 18 Mar 2002 16:55:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11521 Mon, 18 Mar 2002 19:22:43 -0500 (EST) Date: Mon, 18 Mar 2002 19:33:58 -0500 (EST) From: Henry Spencer To: "Joseph D. Harwood" cc: Ipsec Subject: Re: Bake-Off Results from Espoo In-Reply-To: <001601c1ced9$25b182e0$c7d0fea9@vesta> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 18 Mar 2002, Joseph D. Harwood wrote: > Is there any written record of the results from the last bake-off? E.g., a > list of problems encountered, etc. Thanks. It has generally been the policy of the bakeoffs that results are not published, to keep the bakeoffs cooperative rather than competitive. They're primarily for the benefit of the attending implementors. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 18 17:13:44 2002 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 g2J1Dh416620; Mon, 18 Mar 2002 17:13:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11577 Mon, 18 Mar 2002 19:36:38 -0500 (EST) From: "Joseph D. Harwood" To: "Henry Spencer" Cc: "Ipsec" Subject: RE: Bake-Off Results from Espoo Date: Mon, 18 Mar 2002 16:45:25 -0800 Message-ID: <001701c1cedf$5c02c9c0$c7d0fea9@vesta> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Thank you for your feedback. It may be of value for a summary of the problems encountered to be made available to everyone, without providing any information on the specific companies or products which encountered the problems. I would be happy to write this summary. If anyone would like to provide me with a list of problems they are aware of that were encountered during the bake-off, I'll summarize them in a document and provide it to this list. I will not include any references to companies, products or people, and I'll keep the source of all information confidential. If anyone would like, we can exchange an NDA first. Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 18, 2002 4:34 PM > To: Joseph D. Harwood > Cc: Ipsec > Subject: Re: Bake-Off Results from Espoo > > > On Mon, 18 Mar 2002, Joseph D. Harwood wrote: > > Is there any written record of the results from the last > bake-off? E.g., a > > list of problems encountered, etc. Thanks. > > It has generally been the policy of the bakeoffs that results are not > published, to keep the bakeoffs cooperative rather than competitive. > They're primarily for the benefit of the attending implementors. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Mar 18 17:47:09 2002 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 g2J1l8417354; Mon, 18 Mar 2002 17:47:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11804 Mon, 18 Mar 2002 20:12:54 -0500 (EST) Message-Id: <3.0.3.32.20020318172621.0156e448@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 18 Mar 2002 17:26:21 -0800 To: "Steven M. Bellovin" , William Allen Simpson From: Alex Alten Subject: Re: 10 years and no ubiquitous security Cc: ietf@ietf.org, ipsec@lists.tislabs.com In-Reply-To: <20020318161833.084837B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:18 AM 3/18/2002 -0600, Steven M. Bellovin wrote: >In message <3C93EEA3.28833ABD@greendragon.com>, William Allen Simpson writes: >>"The Purple Streak (Hilarie Orman)" wrote: ... > >But Bill, I'm trying to understand what your point is. We can't force >people to use security. IPsec is standard in most major business >operating systems (Win2K, Solaris, *BSD, etc.) and available for for >Linux. There are hardware solutions -- I have a small IPsec box with >me in Minneapolis. But except for VPN scenarios, most people choose >not to use it. I think there's a lesson there, but I fail to see how >Steve Kent or any of the other players in the history of IPsec are at >all at fault. > At last call call several years ago I detailed my misgivings about the design. However since so many talented people had already put years of work into it I also wrote that the market must decide its fate. It seems to have decided, IPsec has settled into a fairly modest VPN market niche ($200M/yr revenues or so?). It is not turned on by (or not available on) at least 99% of the Internet hosts. I guess the $64 question is whither do we go now with IPsec? 1. Do we do significant surgery on it and muddle on? 2. Do we stop working on it and start over with a fresh design? (Besides VPN what other pressing problem needs a solution?) 3. Do we give up? (Or at least be satisfied with a VPN only solution.) I'm a little amazed that IPsec has had as much success as it has had to date. I've seen so many other secure IETF protocols die much more quickly; SNMPSEC, PEM, SHTTP, etc. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Mar 18 17:47:10 2002 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 g2J1l9417363; Mon, 18 Mar 2002 17:47:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11816 Mon, 18 Mar 2002 20:15:10 -0500 (EST) Message-ID: <3C704AAE.20726500@alum.mit.edu> Date: Sun, 17 Feb 2002 17:28:30 -0700 From: "The Purple Streak (Hilarie Orman)" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Allen Simpson said: It was certain members of the WG who insisted we didn't need the counter. At least one has admitted he was wrong. Are you ever going to admit you were? I didn't realize that a call for admission had been previously issued. Sure, I was wrong. It was a surprise to me that protocols are not monotonic wrt non-security requirements when security is layered onto them. Hilarie From owner-ipsec@lists.tislabs.com Mon Mar 18 17:54:35 2002 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 g2J1sZ417521; Mon, 18 Mar 2002 17:54:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11828 Mon, 18 Mar 2002 20:17:49 -0500 (EST) Date: Mon, 18 Mar 2002 17:30:29 -0800 (PST) Message-Id: <200203190130.RAA03604@potomac.incog.com> From: Mike Ditto To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 18 Mar 2002 15:36:15 -0500) Subject: Re: Addresses in traffic selectors in IKEv2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >There is no advantage to having multiple types in this case, so we should > >ditch the less generic ones. > > Paul makes a good point. > > Ranges can be used to express what masks can express and so we should > probably do away with masks. We should also prohibit trivial ranges > that define a single address. I disagree; that seems to miss Paul's point. Ranges are necessary and sufficient, and an address set should be composed of a list of ranges. (I sugggest that "address set" is the superior term rather than range, list, "multiple addresses" or other often used terms for this concept -- a set is unordered, possibly empty, and can not have duplicate members.) One can define a normal form of address set representation comprising zero or more mutually discontiguous ranges listed in increasing numerical order. The normal form can be memcmp-compared for equivalence, or binary searched for membership. -=] Mike [=- Sun Microsystems Solaris Security Technologies From owner-ipsec@lists.tislabs.com Mon Mar 18 20:35:56 2002 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 g2J4Zt421340; Mon, 18 Mar 2002 20:35:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12552 Mon, 18 Mar 2002 22:47:52 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3D98@NS-CA> From: Michael Choung Shieh To: "'Alex Alten'" , "Steven M. Bellovin" , William Allen Simpson Cc: ietf@ietf.org, ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security Date: Mon, 18 Mar 2002 19:56:57 -0800 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 FYI. Dedicated VPN HW Hits $1.3 Billion as shown at http://www.infonetics.com/resources/quarterly_worldwide_market_share_forecas ts_4q01.htm It has a sizeable installation out there, though it does have some large deployment issues. Michael Shieh -----Original Message----- From: Alex Alten [mailto:Alten@attbi.com] Sent: Monday, March 18, 2002 5:26 PM To: Steven M. Bellovin; William Allen Simpson Cc: ietf@ietf.org; ipsec@lists.tislabs.com Subject: Re: 10 years and no ubiquitous security [... skip...] It seems to have decided, IPsec has settled into a fairly modest VPN market niche ($200M/yr revenues or so?). It is not turned on by (or not available on) at least 99% of the Internet hosts. [... skip....] - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Mar 18 21:19:23 2002 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 g2J5JN422085; Mon, 18 Mar 2002 21:19:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12815 Mon, 18 Mar 2002 23:43:56 -0500 (EST) Message-Id: <3.0.3.32.20020318205723.013a5b00@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 18 Mar 2002 20:57:23 -0800 To: Michael Choung Shieh , "Steven M. Bellovin" , William Allen Simpson From: Alex Alten Subject: RE: 10 years and no ubiquitous security Cc: ietf@ietf.org, ipsec@lists.tislabs.com In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3D98@NS-CA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sigh. I knew I shouldn't have put a dollar figure in my response. Michael you have to take those reports with a grain of salt, dollar amounts tend to be meaningless. At the risk of getting nailed here's how I did my math. Red Creek last year shipped about 1% of the hw IPsec VPN boxes worldwide. They were bought for about $10M (if I remember correctly). Thus implicitly valuing all the firms, divisions of firms, etc., at about $1B. Generally speaking in a growth industry you pay about 5x revenues. So this means the industry last year probably had about $200M in revenues. I may be off a bit, maybe its $300M, but that's about how much money is being paid by real customers per year. It's not a huge market, at least not based on my back-of- the-envelope calculations. If I'm wrong then I'm sure one of your marketing guys can correct me with more accurate numbers. - Alex At 07:56 PM 3/18/2002 -0800, Michael Choung Shieh wrote: > >FYI. Dedicated VPN HW Hits $1.3 Billion as shown at >http://www.infonetics.com/resources/quarterly_worldwide_market_share_forecas >ts_4q01.htm It has a sizeable installation out there, though it does have >some large deployment issues. > >Michael Shieh > >-----Original Message----- >From: Alex Alten [mailto:Alten@attbi.com] >Sent: Monday, March 18, 2002 5:26 PM >To: Steven M. Bellovin; William Allen Simpson >Cc: ietf@ietf.org; ipsec@lists.tislabs.com >Subject: Re: 10 years and no ubiquitous security > >[... skip...] > > It seems to have decided, IPsec has settled into a fairly modest >VPN market niche ($200M/yr revenues or so?). It is not turned on by >(or not available on) at least 99% of the Internet hosts. > >[... skip....] > >- Alex > > >-- > >Alex Alten >Alten@ATTBI.com > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Mar 18 21:30:28 2002 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 g2J5US422289; Mon, 18 Mar 2002 21:30:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12928 Mon, 18 Mar 2002 23:54:35 -0500 (EST) Date: Tue, 19 Mar 2002 07:06:09 +0200 Message-Id: <200203190506.HAA00626@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: andrew.krywaniuk@alcatel.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 18 Mar 2002 15:36:15 -0500) Subject: Re: Addresses in traffic selectors in IKEv2 References: <000d01c1c9da$2a6e9bf0$1e72788a@ca.alcatel.com> 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 > From: Stephen Kent > Ranges can be used to express what masks can express and so we should > probably do away with masks. We should also prohibit trivial ranges > that define a single address. Or more uniform, express all in ranges, including single address. > We are adding enumerated lists for all selector types, and that > should replace the singleton selector values. > > Any more suggestions for reducing ambiguity in expressing selectors? Everyone seems to ignore my previous comment about TS: they should not been as SPD selectors, but SAD information instead. SPD selectors are not needed for any IKE, the SAD values are. As to other suggestions: can your TS handle connection specific SA's? For that you need both src and dst ports. I repeat my earlier example: if you want connection specific SA's for all of your SMTP connections to a specific mail server, you can write a policy dst=mailserveraddress, remote-port=25 -> SA-requirements where, SA-requirements include the bit of information that each connection is to have a different SA, and thus the port information from the matched packets is passed to the IKE. And IKE needs a way to pass this info over while negotiating the SAs. I assumed TS was representing this information set. If not, what payload will do it then? Note the on server side the policy line is naturally expressed local-port=25 -> SA-requirements Note, that SPD selectors do not match. It would be pointless to transfer them. From owner-ipsec@lists.tislabs.com Mon Mar 18 21:54:47 2002 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 g2J5sk422822; Mon, 18 Mar 2002 21:54:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13130 Tue, 19 Mar 2002 00:20:35 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3D9C@NS-CA> From: Michael Choung Shieh To: "'Alex Alten'" , Michael Choung Shieh , "Steven M. Bellovin" , William Allen Simpson Cc: ietf@ietf.org, ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security Date: Mon, 18 Mar 2002 21:28:14 -0800 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 well, the stock market is very volatile so it won't be good for the reference. If you use my company for calculation, you probably think VPN has bigger market than Routers does ;-) my company makes integrated firewall & vpn box and revenue last year is 85M. we only have small market shares comparing to those big companies. So the market for IPsec is definitely much bigger than 300M. What I see here is IPsec does have its fault but users are using it because it does solve some of their problems. As long as we keep improving it then it will expand to new applications and get wider deployment. It's getting more fun these days cause more and more applications try to use it. iSCSI is an example. Michael -----Original Message----- From: Alex Alten [mailto:Alten@attbi.com] Sent: Monday, March 18, 2002 8:57 PM To: Michael Choung Shieh; Steven M. Bellovin; William Allen Simpson Cc: ietf@ietf.org; ipsec@lists.tislabs.com Subject: RE: 10 years and no ubiquitous security Sigh. I knew I shouldn't have put a dollar figure in my response. Michael you have to take those reports with a grain of salt, dollar amounts tend to be meaningless. At the risk of getting nailed here's how I did my math. Red Creek last year shipped about 1% of the hw IPsec VPN boxes worldwide. They were bought for about $10M (if I remember correctly). Thus implicitly valuing all the firms, divisions of firms, etc., at about $1B. Generally speaking in a growth industry you pay about 5x revenues. So this means the industry last year probably had about $200M in revenues. I may be off a bit, maybe its $300M, but that's about how much money is being paid by real customers per year. It's not a huge market, at least not based on my back-of- the-envelope calculations. If I'm wrong then I'm sure one of your marketing guys can correct me with more accurate numbers. - Alex At 07:56 PM 3/18/2002 -0800, Michael Choung Shieh wrote: > >FYI. Dedicated VPN HW Hits $1.3 Billion as shown at >http://www.infonetics.com/resources/quarterly_worldwide_market_share_foreca s >ts_4q01.htm It has a sizeable installation out there, though it does have >some large deployment issues. > >Michael Shieh > >-----Original Message----- >From: Alex Alten [mailto:Alten@attbi.com] >Sent: Monday, March 18, 2002 5:26 PM >To: Steven M. Bellovin; William Allen Simpson >Cc: ietf@ietf.org; ipsec@lists.tislabs.com >Subject: Re: 10 years and no ubiquitous security > >[... skip...] > > It seems to have decided, IPsec has settled into a fairly modest >VPN market niche ($200M/yr revenues or so?). It is not turned on by >(or not available on) at least 99% of the Internet hosts. > >[... skip....] > >- Alex > > >-- > >Alex Alten >Alten@ATTBI.com > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Mar 18 22:14:28 2002 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 g2J6ER423376; Mon, 18 Mar 2002 22:14:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13240 Tue, 19 Mar 2002 00:40:26 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.53773.622902.281848@ryijy.hel.fi.ssh.com> Date: Tue, 19 Mar 2002 07:52:13 +0200 From: Tero Kivinen To: "Henry Spencer" CC: jharwood@vesta-corp.com, ipsec@lists.tislabs.com Subject: Re: Bake-Off Results from Espoo References: <001701c1cedf$5c02c9c0$c7d0fea9@vesta> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jharwood@vesta-corp.com ("Joseph D. Harwood") writes: > It may be of value for a summary of the problems encountered to be made > available to everyone, without providing any information on the specific > companies or products which encountered the problems. I would be happy to > write this summary. If anyone would like to provide me with a list of The url to the summary has already been posted to the list. See http://www.sandelman.ottawa.on.ca/ipsec/2001/08/msg00385.html for more information. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 19 05:00:53 2002 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 g2JD0r407574; Tue, 19 Mar 2002 05:00:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15035 Tue, 19 Mar 2002 07:09:01 -0500 (EST) From: dracca@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A014D4237@email.quarrytech.com> To: msa@burp.tkv.asdf.org, kent@bbn.com Cc: andrew.krywaniuk@alcatel.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 19 Mar 2002 07:20:14 -0500 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 Have you ever tried to implement a range using a CAM-based lookup engine for policy matching? Masks are easy - (arbitrary) ranges are most definitely not. If you're going to do away with something, get rid of the range. At the risk of stirring the pot a bit more, since I was neither in Mr. Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the year was), I might ask, who thought up this range thing, and why was it thought to be a good idea, anyway? regards -----Original Message----- From: Markku Savela [mailto:msa@burp.tkv.asdf.org] Sent: Tuesday, March 19, 2002 12:06 AM To: kent@bbn.com Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 > From: Stephen Kent > Ranges can be used to express what masks can express and so we should > probably do away with masks. We should also prohibit trivial ranges > that define a single address. Or more uniform, express all in ranges, including single address. > We are adding enumerated lists for all selector types, and that > should replace the singleton selector values. > > Any more suggestions for reducing ambiguity in expressing selectors? Everyone seems to ignore my previous comment about TS: they should not been as SPD selectors, but SAD information instead. SPD selectors are not needed for any IKE, the SAD values are. As to other suggestions: can your TS handle connection specific SA's? For that you need both src and dst ports. I repeat my earlier example: if you want connection specific SA's for all of your SMTP connections to a specific mail server, you can write a policy dst=mailserveraddress, remote-port=25 -> SA-requirements where, SA-requirements include the bit of information that each connection is to have a different SA, and thus the port information from the matched packets is passed to the IKE. And IKE needs a way to pass this info over while negotiating the SAs. I assumed TS was representing this information set. If not, what payload will do it then? Note the on server side the policy line is naturally expressed local-port=25 -> SA-requirements Note, that SPD selectors do not match. It would be pointless to transfer them. From owner-ipsec@lists.tislabs.com Tue Mar 19 06:33:27 2002 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 g2JEXQ411849; Tue, 19 Mar 2002 06:33:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15661 Tue, 19 Mar 2002 08:47:49 -0500 (EST) Message-ID: From: Chris Trobridge To: dracca@quarrytech.com, msa@burp.tkv.asdf.org, kent@bbn.com Cc: andrew.krywaniuk@alcatel.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 19 Mar 2002 13:59:50 -0000 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 We took the same approach as Markku mentioned. We allow the user to specify individual addresses, subnets or ranges, but implementation only sees ranges. Looking up using CAM is hard whatever, due to the SPD ordering and multiple fields. We haven't implemented a hardware CAM yet but the plan is to use the CAM to cache SPD look-up results, rather than implement the whole SPD as a CAM. Chris -----Original Message----- From: dracca@quarrytech.com [mailto:dracca@quarrytech.com] Sent: 19 March 2002 12:20 To: msa@burp.tkv.asdf.org; kent@bbn.com Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: RE: Addresses in traffic selectors in IKEv2 Have you ever tried to implement a range using a CAM-based lookup engine for policy matching? Masks are easy - (arbitrary) ranges are most definitely not. If you're going to do away with something, get rid of the range. At the risk of stirring the pot a bit more, since I was neither in Mr. Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the year was), I might ask, who thought up this range thing, and why was it thought to be a good idea, anyway? regards -----Original Message----- From: Markku Savela [mailto:msa@burp.tkv.asdf.org] Sent: Tuesday, March 19, 2002 12:06 AM To: kent@bbn.com Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 > From: Stephen Kent > Ranges can be used to express what masks can express and so we should > probably do away with masks. We should also prohibit trivial ranges > that define a single address. Or more uniform, express all in ranges, including single address. > We are adding enumerated lists for all selector types, and that > should replace the singleton selector values. > > Any more suggestions for reducing ambiguity in expressing selectors? Everyone seems to ignore my previous comment about TS: they should not been as SPD selectors, but SAD information instead. SPD selectors are not needed for any IKE, the SAD values are. As to other suggestions: can your TS handle connection specific SA's? For that you need both src and dst ports. I repeat my earlier example: if you want connection specific SA's for all of your SMTP connections to a specific mail server, you can write a policy dst=mailserveraddress, remote-port=25 -> SA-requirements where, SA-requirements include the bit of information that each connection is to have a different SA, and thus the port information from the matched packets is passed to the IKE. And IKE needs a way to pass this info over while negotiating the SAs. I assumed TS was representing this information set. If not, what payload will do it then? Note the on server side the policy line is naturally expressed local-port=25 -> SA-requirements Note, that SPD selectors do not match. It would be pointless to transfer them. This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Mar 19 08:05:55 2002 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 g2JG5s417495; Tue, 19 Mar 2002 08:05:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16200 Tue, 19 Mar 2002 10:21:06 -0500 (EST) From: "Casey Carr" To: , , Cc: , , Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 19 Mar 2002 10:30:58 -0500 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: <496A8683261CD211BF6C0008C733261A014D4237@email.quarrytech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I second the motion to get rid of ranges. We are not supporting ranges in our implementation for this same reason. Casey -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dracca@quarrytech.com Sent: Tuesday, March 19, 2002 7:20 AM To: msa@burp.tkv.asdf.org; kent@bbn.com Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: RE: Addresses in traffic selectors in IKEv2 Have you ever tried to implement a range using a CAM-based lookup engine for policy matching? Masks are easy - (arbitrary) ranges are most definitely not. If you're going to do away with something, get rid of the range. At the risk of stirring the pot a bit more, since I was neither in Mr. Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the year was), I might ask, who thought up this range thing, and why was it thought to be a good idea, anyway? regards -----Original Message----- From: Markku Savela [mailto:msa@burp.tkv.asdf.org] Sent: Tuesday, March 19, 2002 12:06 AM To: kent@bbn.com Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 > From: Stephen Kent > Ranges can be used to express what masks can express and so we should > probably do away with masks. We should also prohibit trivial ranges > that define a single address. Or more uniform, express all in ranges, including single address. > We are adding enumerated lists for all selector types, and that > should replace the singleton selector values. > > Any more suggestions for reducing ambiguity in expressing selectors? Everyone seems to ignore my previous comment about TS: they should not been as SPD selectors, but SAD information instead. SPD selectors are not needed for any IKE, the SAD values are. As to other suggestions: can your TS handle connection specific SA's? For that you need both src and dst ports. I repeat my earlier example: if you want connection specific SA's for all of your SMTP connections to a specific mail server, you can write a policy dst=mailserveraddress, remote-port=25 -> SA-requirements where, SA-requirements include the bit of information that each connection is to have a different SA, and thus the port information from the matched packets is passed to the IKE. And IKE needs a way to pass this info over while negotiating the SAs. I assumed TS was representing this information set. If not, what payload will do it then? Note the on server side the policy line is naturally expressed local-port=25 -> SA-requirements Note, that SPD selectors do not match. It would be pointless to transfer them. From owner-ipsec@lists.tislabs.com Tue Mar 19 08:14:24 2002 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 g2JGEO418079; Tue, 19 Mar 2002 08:14:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16294 Tue, 19 Mar 2002 10:35:53 -0500 (EST) To: "Casey Carr" Cc: , , , , , Subject: Re: Addresses in traffic selectors in IKEv2 References: From: Derek Atkins Date: 19 Mar 2002 10:44:39 -0500 In-Reply-To: Message-ID: Lines: 91 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem is that with a mask you cannot specify as specific a set of addresses as you can with a range? For example, how would you specify the set of addresses from, say, 18.101.1.3-18.101.1.9 (inclusive) using a mask? -derek "Casey Carr" writes: > I second the motion to get rid of ranges. We are not supporting ranges in > our implementation for this same reason. > > Casey > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dracca@quarrytech.com > Sent: Tuesday, March 19, 2002 7:20 AM > To: msa@burp.tkv.asdf.org; kent@bbn.com > Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; > ipsec@lists.tislabs.com > Subject: RE: Addresses in traffic selectors in IKEv2 > > > Have you ever tried to implement a range using a CAM-based lookup engine for > policy matching? Masks are easy - (arbitrary) ranges are most definitely > not. If you're going to do away with something, get rid of the range. At > the risk of stirring the pot a bit more, since I was neither in Mr. > Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the > year was), I might ask, who thought up this range thing, and why was it > thought to be a good idea, anyway? > > regards > > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, March 19, 2002 12:06 AM > To: kent@bbn.com > Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; > ipsec@lists.tislabs.com > Subject: Re: Addresses in traffic selectors in IKEv2 > > > > From: Stephen Kent > > > Ranges can be used to express what masks can express and so we should > > probably do away with masks. We should also prohibit trivial ranges > > that define a single address. > > Or more uniform, express all in ranges, including single address. > > > We are adding enumerated lists for all selector types, and that > > should replace the singleton selector values. > > > > Any more suggestions for reducing ambiguity in expressing selectors? > > Everyone seems to ignore my previous comment about TS: they should not > been as SPD selectors, but SAD information instead. > > SPD selectors are not needed for any IKE, the SAD values are. > > As to other suggestions: can your TS handle connection specific SA's? > For that you need both src and dst ports. > > I repeat my earlier example: if you want connection specific SA's for > all of your SMTP connections to a specific mail server, you can write > a policy > > dst=mailserveraddress, remote-port=25 -> SA-requirements > > where, SA-requirements include the bit of information that each > connection is to have a different SA, and thus the port information > from the matched packets is passed to the IKE. And IKE needs a way to > pass this info over while negotiating the SAs. I assumed TS was > representing this information set. If not, what payload will do it > then? > > Note the on server side the policy line is naturally expressed > > local-port=25 -> SA-requirements > > > Note, that SPD selectors do not match. It would be pointless to > transfer them. > -- 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 Mar 19 08:20:02 2002 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 g2JGK2418701; Tue, 19 Mar 2002 08:20:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16321 Tue, 19 Mar 2002 10:38:16 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200203190130.RAA03604@potomac.incog.com> References: <200203190130.RAA03604@potomac.incog.com> Date: Tue, 19 Mar 2002 09:49:49 -0600 To: Mike Ditto , kent@bbn.com From: Paul Hoffman / VPNC Subject: Re: Addresses in traffic selectors in IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:30 PM -0800 3/18/02, Mike Ditto wrote: > > >There is no advantage to having multiple types in this case, so we should >> >ditch the less generic ones. > > >> Paul makes a good point. >> >> Ranges can be used to express what masks can express and so we should >> probably do away with masks. We should also prohibit trivial ranges >> that define a single address. > >I disagree; that seems to miss Paul's point. Ranges are necessary and >sufficient, and an address set should be composed of a list of ranges. Mike is correct: what I propose is that we use ranges *only* so that there is not two ways to express the same thing. If there are two ways to express the same thing, we lose interoperability. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 19 09:44:02 2002 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 g2JHi1425088; Tue, 19 Mar 2002 09:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16764 Tue, 19 Mar 2002 11:52:16 -0500 (EST) Date: Tue, 19 Mar 2002 12:04:40 -0500 From: Richard Guy Briggs To: Derek Atkins Cc: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 Message-ID: <20020319120440.R14603@grendel.conscoop.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from warlord@mit.edu on Tue, Mar 19, 2002 at 10:44:39AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Mar 19, 2002 at 10:44:39AM -0500, Derek Atkins wrote: > The problem is that with a mask you cannot specify as specific a set > of addresses as you can with a range? The same could be said for the inverse. > For example, how would you specify the set of addresses from, say, > 18.101.1.3-18.101.1.9 (inclusive) using a mask? To play the devil's advocate, how would you specify the set of addresses in 192.168.1.0/255.255.255.1 (yes, that mask is not contiguous, but it is still a mask...) That is a pretty specific set. > -derek > > "Casey Carr" writes: > > > I second the motion to get rid of ranges. We are not supporting ranges in > > our implementation for this same reason. > > > > Casey > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From owner-ipsec@lists.tislabs.com Tue Mar 19 09:44:04 2002 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 g2JHi3425104; Tue, 19 Mar 2002 09:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16831 Tue, 19 Mar 2002 12:06:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15511.29369.786000.114161@gargle.gargle.HOWL> Date: Tue, 19 Mar 2002 12:17:45 -0500 From: Paul Koning To: angelos@cs.columbia.edu Cc: ipsec@lists.tislabs.com Subject: Re: Choosing between IKEv2 and JFK References: <3C940813.F1C91530@lucent.com> <200203170326.g2H3QOUe013450@nyarlathotep.keromytis.org> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 16 March 2002) by Angelos D. Keromytis: > > There seems to be a misconception that we need IKEv1 or a design very similar > to it to do the things people consider useful. I don't remember such a statement. What I remember is statements that son-of-IKE needs to support the set of IKEv1 capabilities that are found generally useful or important. Whether the design looks like, or is based on, IKEv1, is an independent decision that doesn't necessarily affect the capabilities of son-of-IKE. paul From owner-ipsec@lists.tislabs.com Tue Mar 19 09:44:12 2002 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 g2JHiC425137; Tue, 19 Mar 2002 09:44:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16817 Tue, 19 Mar 2002 12:04:58 -0500 (EST) From: Charles Lynn To: "Casey Carr" Cc: , , "" , , Subject: Re: RE: Addresses in traffic selectors in IKEv2 In-Reply-To: Message-Id: <20020319171619.C74BB16484@wolfe.bbn.com> Date: Tue, 19 Mar 2002 12:16:19 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Casey, This question is for all the folks who take issue with ranges, not just you. > We are not supporting ranges in our implementation for this same reason. Since there is an easily implemented 1-to-1 mapping between a range and the set of prefixes that represent the same range, why is supporting ranges (in the protocol exchanges) a problem? If an admin needs to express a range, I think it would be more concise in the protocol, and probably in the SPD, and also less prone to admin typo syndrome to say a.b.c.d-e.f.g.h than to have the admin type in all the corresponding prefixes. Granted one would then have a one-to-many mapping between SPD/SAD and one's CAM; the alternative would be multiple SPD/SAD entries pointing a single CAM entry -- seems like that would take more memory than one SPD/SAD and a list. Can someone point out what points I an overlooking? Charlie From owner-ipsec@lists.tislabs.com Tue Mar 19 09:45:27 2002 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 g2JHjR425321; Tue, 19 Mar 2002 09:45:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16777 Tue, 19 Mar 2002 11:57:30 -0500 (EST) Message-ID: <3C9770A2.BD74ADA3@bbn.com> Date: Tue, 19 Mar 2002 12:08:50 -0500 From: David Waitzman Organization: BBN Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 References: <200203190130.RAA03604@potomac.incog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We recommend against ranges and for masks for two reasons: - ranges are less natural to network administrators; they tend to work more with IP prefixes (masks) when handling configuration tasks; IP prefixes also tend to reflect the sub-topology of a local network, while ranges don't. (However, ranges are more flexible, and *don't* bind you to subnet topology, so they're also useful, especially for things like web farms.) - (as stated already) arbitrary ranges don't compile into ternary CAMs very well, especially if there are multiple range-based selectors in a policy or SAD entry; in the worst case, it uses 2*(log2 rangeSize)-1 entries per range; if multiple ranges are found in the same selector, you need the *product* of the number of CAM entries for each field, in total. (Don't expect this happens much in the real world, though.) IP prefixes (or other mask/value entries) only require a single CAM entry. -david waitzman BBN Technologies Internetwork Research Department From owner-ipsec@lists.tislabs.com Tue Mar 19 09:57:01 2002 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 g2JHv0425648; Tue, 19 Mar 2002 09:57:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16986 Tue, 19 Mar 2002 12:17:37 -0500 (EST) From: dracca@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A014D423D@email.quarrytech.com> To: warlord@mit.edu, kcarr@nc.rr.com Cc: dracca@quarrytech.com, msa@burp.tkv.asdf.org, kent@bbn.com, andrew.krywaniuk@alcatel.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 19 Mar 2002 12:28:52 -0500 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 Any range can be covered by a set of one or more masks, of course. These would suffice for your example: IP Start Address: 18.101.1.3 (0x12650103) IP End Address: 18.101.1.9 (0x12650109) Classifier Address Range -------------------- --------------------------------- 18.101.1.3/32 18.101.1.3 -> 18.101.1.3 18.101.1.4/30 18.101.1.4 -> 18.101.1.7 18.101.1.8/31 18.101.1.8 -> 18.101.1.9 Total Classifiers: 3 This can get very expensive when your rules live directly in a CAM (more so if both source and destination address are expressed as ranges and you have to take the cross-product of the two sets). In our case, the effort involved in address range expansion + multiplication lead to a whole load of complexity for what I would consider to be a feature of minimal convenience. On the other hand, I could be wrong in thinking that it is not common place to run across a set of machines that a.) have a common requirement for a specific security policy, and b.) happen to be numbered in such an orderly fashion that a range would be apropos. -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Tuesday, March 19, 2002 10:45 AM To: Casey Carr Cc: dracca@quarrytech.com; msa@burp.tkv.asdf.org; kent@bbn.com; andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 The problem is that with a mask you cannot specify as specific a set of addresses as you can with a range? For example, how would you specify the set of addresses from, say, 18.101.1.3-18.101.1.9 (inclusive) using a mask? -derek "Casey Carr" writes: > I second the motion to get rid of ranges. We are not supporting ranges in > our implementation for this same reason. > > Casey > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dracca@quarrytech.com > Sent: Tuesday, March 19, 2002 7:20 AM > To: msa@burp.tkv.asdf.org; kent@bbn.com > Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; > ipsec@lists.tislabs.com > Subject: RE: Addresses in traffic selectors in IKEv2 > > > Have you ever tried to implement a range using a CAM-based lookup engine for > policy matching? Masks are easy - (arbitrary) ranges are most definitely > not. If you're going to do away with something, get rid of the range. At > the risk of stirring the pot a bit more, since I was neither in Mr. > Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the > year was), I might ask, who thought up this range thing, and why was it > thought to be a good idea, anyway? > > regards > > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, March 19, 2002 12:06 AM > To: kent@bbn.com > Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org; > ipsec@lists.tislabs.com > Subject: Re: Addresses in traffic selectors in IKEv2 > > > > From: Stephen Kent > > > Ranges can be used to express what masks can express and so we should > > probably do away with masks. We should also prohibit trivial ranges > > that define a single address. > > Or more uniform, express all in ranges, including single address. > > > We are adding enumerated lists for all selector types, and that > > should replace the singleton selector values. > > > > Any more suggestions for reducing ambiguity in expressing selectors? > > Everyone seems to ignore my previous comment about TS: they should not > been as SPD selectors, but SAD information instead. > > SPD selectors are not needed for any IKE, the SAD values are. > > As to other suggestions: can your TS handle connection specific SA's? > For that you need both src and dst ports. > > I repeat my earlier example: if you want connection specific SA's for > all of your SMTP connections to a specific mail server, you can write > a policy > > dst=mailserveraddress, remote-port=25 -> SA-requirements > > where, SA-requirements include the bit of information that each > connection is to have a different SA, and thus the port information > from the matched packets is passed to the IKE. And IKE needs a way to > pass this info over while negotiating the SAs. I assumed TS was > representing this information set. If not, what payload will do it > then? > > Note the on server side the policy line is naturally expressed > > local-port=25 -> SA-requirements > > > Note, that SPD selectors do not match. It would be pointless to > transfer them. > -- 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 Mar 19 10:27:28 2002 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 g2JIRR426526; Tue, 19 Mar 2002 10:27:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17141 Tue, 19 Mar 2002 12:48:46 -0500 (EST) Date: Tue, 19 Mar 2002 20:00:32 +0200 Message-Id: <200203191800.UAA01482@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: (message from Chris Trobridge on Tue, 19 Mar 2002 13:59:50 -0000) Subject: Re: Addresses in traffic selectors in IKEv2 References: 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 > From: Chris Trobridge > > We took the same approach as Markku mentioned. We allow the user to > specify individual addresses, subnets or ranges, but implementation > only sees ranges. Actually I don't prefer ranges, I only implemented address/mask. What I was trying to say, choose one: either ranges only or address/mask, but not both. The SPD policy selectors will consist following components - IP protocol number (8 bits) - src address 128 bits (IPv6/IPv4) - dst address 128 bits ( -"-) - source port 16 bits - destination port 16 bits and for IPv6 scoped architecture, we need at least locally - destination scope identifier (32 bits) - source scope identifies (32) and private addition - ICMP type and code (16 bits) -------- total selector bits 376 bits! It just gets pretty messy if some of these can be expressed as ranges. You have to compare each field separately. It's much simpler if you don't implement ranges, then you can just construct the 376 bits and compare under mask. Now above was all for SPD side. The traffic selector in IKE payload (IMHO) is supposed to describe "qualifiers" for the negotiated SA. Scope identifiers are local issue, so they don't need to be included. Pretty much all of the rest is needed. It's okay to use ranges here, as masks are easy to translate into ranges. It should be noted, that address ranges are not needed (or meaningful) with transport mode SA's. Again, I wish to express the difference between SPD selector and SAD "qualifier", for example VPN tunnel dst=company/x -> "SA spec for SG" Now if you want communications to all hosts within "company/x" to use same sa, you specify "company/x" (=range) in traffic selector. If you want each host behind the SG to get own SA, you specify individual address in traffic selecter. Again, this choice is part of the "SA spec for SG". Again, SPD entry is same for both variations. From owner-ipsec@lists.tislabs.com Tue Mar 19 10:43:12 2002 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 g2JIhB427358; Tue, 19 Mar 2002 10:43:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17264 Tue, 19 Mar 2002 13:04:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15511.32828.539107.799107@thomasm-u1.cisco.com> Date: Tue, 19 Mar 2002 10:15:24 -0800 (PST) To: David Waitzman Cc: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 In-Reply-To: <3C9770A2.BD74ADA3@bbn.com> References: <200203190130.RAA03604@potomac.incog.com> <3C9770A2.BD74ADA3@bbn.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 Isn't this just a presentation issue? That is, you could allow net admins to input things as subnets, but under the hood, it converts things to ranges for IKE. I'd think the TCAM issue would be similar: if people mainly use the selectors on subnet boundaries, it wouldn't have an effect on TCAM consumption, right? Assuming that you allow for ranges anyway, I don't really see what the upside is. Mike David Waitzman writes: > > We recommend against ranges and for masks for two reasons: > > - ranges are less natural to network administrators; they tend to > work more with IP prefixes (masks) when handling configuration > tasks; IP prefixes also tend to reflect the sub-topology of a local > network, while ranges don't. (However, ranges are more flexible, > and *don't* bind you to subnet topology, so they're also useful, > especially for things like web farms.) > > - (as stated already) arbitrary ranges don't compile into ternary > CAMs very well, especially if there are multiple range-based > selectors in a policy or SAD entry; in the worst case, it uses > 2*(log2 rangeSize)-1 entries per range; if multiple ranges are > found in the same selector, you need the *product* of the number of > CAM entries for each field, in total. (Don't expect this happens > much in the real world, though.) IP prefixes (or other mask/value > entries) only require a single CAM entry. > > -david waitzman > BBN Technologies Internetwork Research Department From owner-ipsec@lists.tislabs.com Tue Mar 19 13:07:45 2002 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 g2JL7i403044; Tue, 19 Mar 2002 13:07:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18130 Tue, 19 Mar 2002 15:12:03 -0500 (EST) Reply-To: From: "Jeremy Rodriguez" To: Subject: unsubscribe jrodriguez@intellinet-tech.com Date: Tue, 19 Mar 2002 14:49:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200203191800.UAA01482@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela Sent: Tuesday, March 19, 2002 1:01 PM To: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 > From: Chris Trobridge > > We took the same approach as Markku mentioned. We allow the user to > specify individual addresses, subnets or ranges, but implementation > only sees ranges. Actually I don't prefer ranges, I only implemented address/mask. What I was trying to say, choose one: either ranges only or address/mask, but not both. The SPD policy selectors will consist following components - IP protocol number (8 bits) - src address 128 bits (IPv6/IPv4) - dst address 128 bits ( -"-) - source port 16 bits - destination port 16 bits and for IPv6 scoped architecture, we need at least locally - destination scope identifier (32 bits) - source scope identifies (32) and private addition - ICMP type and code (16 bits) -------- total selector bits 376 bits! It just gets pretty messy if some of these can be expressed as ranges. You have to compare each field separately. It's much simpler if you don't implement ranges, then you can just construct the 376 bits and compare under mask. Now above was all for SPD side. The traffic selector in IKE payload (IMHO) is supposed to describe "qualifiers" for the negotiated SA. Scope identifiers are local issue, so they don't need to be included. Pretty much all of the rest is needed. It's okay to use ranges here, as masks are easy to translate into ranges. It should be noted, that address ranges are not needed (or meaningful) with transport mode SA's. Again, I wish to express the difference between SPD selector and SAD "qualifier", for example VPN tunnel dst=company/x -> "SA spec for SG" Now if you want communications to all hosts within "company/x" to use same sa, you specify "company/x" (=range) in traffic selector. If you want each host behind the SG to get own SA, you specify individual address in traffic selecter. Again, this choice is part of the "SA spec for SG". Again, SPD entry is same for both variations. From owner-ipsec@lists.tislabs.com Tue Mar 19 13:07:47 2002 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 g2JL7k403056; Tue, 19 Mar 2002 13:07:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18198 Tue, 19 Mar 2002 15:21:11 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DA5@NS-CA> From: Michael Choung Shieh To: "'Markku Savela'" , ipsec@lists.tislabs.com Subject: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Date: Tue, 19 Mar 2002 12:31:24 -0800 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 I will propose to remove TS entirely so we don't need to worry about IP subnet vs. range any more. There are encountered numerous problems when puting proxy_id in IKEv1 (it's improved when using TS in IKEv2 but the fundamental problem is not solved). The basic problem I see is we try to put SPD inside key managemnt protocol, which has lots of problems when dynamic routing is implemented. I see the purposes of proxy_id (or TS) are 1. the index to find the sa when there are multiple IPsect tunnels. 2. indicate the SPD associate with the sa 3. a mechanism to detect misconfigured SPD in IKE instead of quietly rejected later. RFC2401 says there are SPD selectors associated with each SA. However, it should be local implemenation issue to bind them together. Puting SPD in IKE is just dulplicating effort in key managment protocol without much benefit. The general problems are: 1. Users want to limit their tunnel traffic by "services", eg. FTP, DNS, AOL, UUCP. However, many "services" have differnet control and data plane and use multiple protocols and ports. For example, FTP takes port 20 and port 21. Stateful firewall will even smarter to only open a single source port for port 21. another example is DNS may use TCP or UDP. Bearing all the knowledge into IKE is overkilled and without actual benefit. 2. puting SPD in form of TS won't simplify your SPD implementation. SPD still need to know all the complexity for each services. You still check every packet comes out of tunels against SPD, no matter what TS you received before. 3. I was almost convinced that puting SPD in IKE can detect the misconfiguration. However, This has introduced many troubles when I try to run dynamic routing and others (listed below) over tunnels. If admin misconfigure their firewall, the traffic will be dropped silently (or log for potential attack) and they need to find out the reason. I think the same logic applies to ipsec traffic as well. key mgmt protocol shouldn't bear the responsibility to detect mis-configure SPD. 4. There are lots of issues when running dynamic routing over tunnel since it's difficult to figure out what the TS should be. 5. If you run NAT before tunnel and the nating address is from one of multiple ip pools, it's difficult to figure out what the TS should be. Giving the difficulty to do TS right, I would propose to use a simple ID (e.g. sequence number) to identity the tunnel and leave all complexity of SPD out of IKE. Michael Shieh -----Original Message----- From: Markku Savela [mailto:msa@burp.tkv.asdf.org] Sent: Tuesday, March 19, 2002 10:01 AM To: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 > From: Chris Trobridge > > We took the same approach as Markku mentioned. We allow the user to > specify individual addresses, subnets or ranges, but implementation > only sees ranges. Actually I don't prefer ranges, I only implemented address/mask. What I was trying to say, choose one: either ranges only or address/mask, but not both. The SPD policy selectors will consist following components - IP protocol number (8 bits) - src address 128 bits (IPv6/IPv4) - dst address 128 bits ( -"-) - source port 16 bits - destination port 16 bits and for IPv6 scoped architecture, we need at least locally - destination scope identifier (32 bits) - source scope identifies (32) and private addition - ICMP type and code (16 bits) -------- total selector bits 376 bits! It just gets pretty messy if some of these can be expressed as ranges. You have to compare each field separately. It's much simpler if you don't implement ranges, then you can just construct the 376 bits and compare under mask. Now above was all for SPD side. The traffic selector in IKE payload (IMHO) is supposed to describe "qualifiers" for the negotiated SA. Scope identifiers are local issue, so they don't need to be included. Pretty much all of the rest is needed. It's okay to use ranges here, as masks are easy to translate into ranges. It should be noted, that address ranges are not needed (or meaningful) with transport mode SA's. Again, I wish to express the difference between SPD selector and SAD "qualifier", for example VPN tunnel dst=company/x -> "SA spec for SG" Now if you want communications to all hosts within "company/x" to use same sa, you specify "company/x" (=range) in traffic selector. If you want each host behind the SG to get own SA, you specify individual address in traffic selecter. Again, this choice is part of the "SA spec for SG". Again, SPD entry is same for both variations. From owner-ipsec@lists.tislabs.com Tue Mar 19 13:20:25 2002 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 g2JLKO403379; Tue, 19 Mar 2002 13:20:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18318 Tue, 19 Mar 2002 15:35:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <200203191800.UAA01482@burp.tkv.asdf.org> References: <200203191800.UAA01482@burp.tkv.asdf.org> Date: Tue, 19 Mar 2002 15:44:27 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: Addresses in traffic selectors in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, This has been a helpful message exchange, as I think there is a clear desire to move to a uniform way of negotiating values for all selectors, and the list of ranges (allowing for trivial ranges) does just that. Steve Bellovin reminded me that JFK proposes this approach and I think it is an excellent one. This approach encompasses what could be expressed via masks, a single value, or a list of individual values. As others have noted, it may be preferable for a management interface to allow other forms of data entry, e.g., masks, but what we're talking about is what will appear in the SPD model and in IKE exchanges. Also recall that the SPD model does not say how one must implement the functionality, just what the required functionality is. Thus it's OK for a management interface to provide a mask capability that is translated into a range representation internally. I am aware of several IPsec implementations that offer management interfaces that map well into the SPD functional requirements even though they do not translate the SPD description directly. Finally, re use of CAMs in high speed hardware, I think it was useful to observe that one can represent all of these forms of selector values via (ternary) CAM entries, but not necessarily on a one-to-one basis. Going forward, I plan to use a model for 2401bis that assumes use of de-correlated SPD entries, which is consistent with use of a ternary CAM for processing. Again, the processing model is not proscriptive from an implementation perspective, but it does establish functional requirements. Some folks have noted that allowing ranges and multiple discrete values for selectors associated with a single SA will eat up CAM entries faster. That's true, but the motivation for including these sorts of multi-valued selectors is to address real world requirements. We used to have analogous requirements in 2401, prior to publication, but we removed them at the last minute to accommodate limitations in IKE v1. I've been told by several vendors that this is a feature that clients have asked for, which reinforces the notion that it is appropriate to include in 2401bis. The goal here is to allow a security administrator/user to cause all traffic directed to a peer IPsec device, and that meets certain syntactic criteria, to be mapped to a single SA. This is desirable to avoid creation of additional SAs when not otherwise desired by the administrator/user. Steve From owner-ipsec@lists.tislabs.com Tue Mar 19 13:29:51 2002 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 g2JLTo403662; Tue, 19 Mar 2002 13:29:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18386 Tue, 19 Mar 2002 15:51:04 -0500 (EST) Message-Id: <200203192102.g2JL2Rf02428@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Addresses in traffic selectors in IKEv2 In-reply-to: Your message of "Tue, 19 Mar 2002 12:08:50 EST." <3C9770A2.BD74ADA3@bbn.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Mar 2002 15:02:26 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "David" == David Waitzman writes: David> We recommend against ranges and for masks for two reasons: David> - ranges are less natural to network administrators; they tend to David> work more with IP prefixes (masks) when handling configuration David> tasks; IP prefixes also tend to reflect the sub-topology of a local David> network, while ranges don't. (However, ranges are more flexible, David> and *don't* bind you to subnet topology, so they're also useful, David> especially for things like web farms.) This is a red-herring argument. If netmasks are more natural, then the user interface can present netmasks for the naive admin. Ranges are the more general object, and we are talking about protocols, not user interfaces. David> - (as stated already) arbitrary ranges don't compile into ternary David> CAMs very well, especially if there are multiple range-based David> selectors in a policy or SAD entry; in the worst case, it uses Nor, btw, do port ranges, IPv6 addresses, or ordered SPD entries. If you expect to put your SPD literally into a CAM, then you are going to lose period. Use your CAM as a per-flow forwarding cache (and you can even buy binary CAMs). There are many other vendors of classification hardware that do not have this problem, btw. David> 2*(log2 rangeSize)-1 entries per range; if multiple ranges are David> found in the same selector, you need the *product* of the number of David> CAM entries for each field, in total. (Don't expect this happens David> much in the real world, though.) IP prefixes (or other mask/value David> entries) only require a single CAM entry. So, do not support unaligned ranges. But that is your implementation, not the key negotiation protocol. ] 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 Mar 19 14:28:54 2002 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 g2JMSj405068; Tue, 19 Mar 2002 14:28:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18605 Tue, 19 Mar 2002 16:26:52 -0500 (EST) Date: Tue, 19 Mar 2002 23:38:28 +0200 Message-Id: <200203192138.XAA02024@burp.tkv.asdf.org> From: Markku Savela To: mshieh@netscreen.com CC: ipsec@lists.tislabs.com In-reply-to: <9D048F4A422CD411A56500B0D0209C5B028F3DA5@NS-CA> (message from Michael Choung Shieh on Tue, 19 Mar 2002 12:31:24 -0800) Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) References: <9D048F4A422CD411A56500B0D0209C5B028F3DA5@NS-CA> 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 > From: Michael Choung Shieh > > I will propose to remove TS entirely so we don't need to worry about IP > subnet vs. range any more. Well, not remove, but undestand clearly the separataion between SPD selectors SAD parameters for SA. Some "selector like" parameters are needed for SA, so that connection or protocol specific SA's are possible in transport mode. For Security gateway use, some address ranges (or masks) might be be useful. For me, sufficient parameters in TS for one-directional SA really would be (where 0 indicates wild card, any) - protocol: 0 or specific value - source port: 0 or specific value - destination port: 0 or specic value - source address: 0 or specific value For SG SA, you may need something that was called "proxy" in PFKEY, and that might need to support masked address or address range. IKEv1 almost had all these fields, but implementations used them "wrong" in my view, trying to pass SPD selectors in them instead... But, if people are willing to put more general values for future, like ranges, it's ok too. I do think multiple address ranges is already overkill, please don't do that (thats just too much to hang on SA and match...) However, if I just could get the IKEv2 designers to see this minor distinction between SPD stuff and SAD stuff, and treat TS as SAD stuff, it seems almost perfect as defined. :-) -- Markku Savela From owner-ipsec@lists.tislabs.com Tue Mar 19 14:46:35 2002 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 g2JMkT405408; Tue, 19 Mar 2002 14:46:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18836 Tue, 19 Mar 2002 17:05:48 -0500 (EST) Date: Tue, 19 Mar 2002 17:16:58 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) In-Reply-To: <200203192138.XAA02024@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Mar 2002, Markku Savela wrote: > However, if I just could get the IKEv2 designers to see this minor > distinction between SPD stuff and SAD stuff, and treat TS as SAD > stuff, it seems almost perfect as defined. :-) The problem with this "minor distinction" is that it ignores the way IKE is actually used. People don't want a separate protocol, especially one that hasn't been designed yet, to do SPD setup. They want to do the whole job of connection setup with IKE, and to get that they are even willing to settle for a fairly simple subset of SPD functionality. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 19 15:32:18 2002 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 g2JNWD406471; Tue, 19 Mar 2002 15:32:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19052 Tue, 19 Mar 2002 17:40:13 -0500 (EST) Date: Tue, 19 Mar 2002 14:53:09 -0800 (PST) Message-Id: <200203192253.OAA04042@potomac.incog.com> From: Mike Ditto To: mshieh@netscreen.com CC: msa@burp.tkv.asdf.org, ipsec@lists.tislabs.com In-reply-to: <9D048F4A422CD411A56500B0D0209C5B028F3DA5@NS-CA> (message from Michael Choung Shieh on Tue, 19 Mar 2002 12:31:24 -0800) Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Choung Shieh wrote: > I will propose to remove TS entirely so we don't need to worry about IP > subnet vs. range any more. > > There are encountered numerous problems when puting proxy_id in IKEv1 (it's > improved when using TS in IKEv2 but the fundamental problem is not solved). > The basic problem I see is we try to put SPD inside key managemnt protocol, > which has lots of problems when dynamic routing is implemented. I agree with this. Traffic selection is more complex and implementation-specific than can be expressed in a reasonable negotiation protocol. It would be nice if the key management protocol could protect against mismatched traffic policies at the ends, but it doesn't seem to actually work in general. Michael Choung Shieh expressed the issues well, but I'll give another example. Host A running IPsec from vendor X supports a service called "H.323", and security gateway B running firewall software from vendor Y supports a service called "NetMeeting". These two implementations of slightly different things have a compatible subset that will allow the end users' traffic through, but how do these two gateways tell each other what traffic selectors to use? The concept of "a network service" doesn't always translate into a few numbers in IP header fields. -=] Mike [=- Sun Microsystems Solaris Security Technologies From owner-ipsec@lists.tislabs.com Tue Mar 19 15:43:02 2002 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 g2JNgv406733; Tue, 19 Mar 2002 15:43:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19107 Tue, 19 Mar 2002 17:51:40 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Draft ipsec agendas Phone: (781) 391-3464 Message-Id: Date: Tue, 19 Mar 2002 18:03:21 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk These are **DRAFT** ipsec agendas. If people have any comments about them, please let me know. Thanks!! - Ted wg_date="Wednesday, March 20, 2002" wg_starttime="1530" wg_endtime="1730" wg_place="Salon D" do_header title="Agenda Bashing" presentor="Ts'o" time=5 do_event title="AES Cipher document(s)" presentor="Herbert / Frankel" time=10 do_event title="CBC Oracle attack" presentor="Eric Rescorla" time=10 do_event title="New versions of ESP/AH" presentor="Steve Kent" time=15 do_event title="IANA and IPSEC registry issues" presentor="Paul Hoffman" time=5 do_event title="NAT Traversal -- Issues and where we are" presentor="Brian Swander" time=20 do_event title="Transport-mode IPsec" presentor="Joe Touch" time=10 do_event do_newpage title="Son-of-Ike Requirements document" presentor="Cheryl Madson" time=15 do_event title="Miscellaneous SOI requirements" presentor="Paul Hoffman" time=15 do_event title="draft-ietf-ipsec-properties-01.txt" presentor="Andrew Krywaniuk" time=15 do_event end_document ---------------------------------------------------------- wg_date="Thursday, March 21, 2002" wg_starttime="900" wg_endtime="1130" wg_place="Salon A" do_header title="Introduction to IKE-JFK decision-making" presentor="Ted Tso" time=10 do_event title="IKEv2 update" presentor="Radia" time=15 do_event title="JFK Update" presentor="Angelos" time=15 do_event title="Comparison of IKEv2, JFK, and requirements" presentor="Charlie Kaufman" time=15 do_event title="Open Mike time --- IKE/JFK decision" presentor="" time=45 do_event end_document From owner-ipsec@lists.tislabs.com Tue Mar 19 16:00:28 2002 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 g2K00M407347; Tue, 19 Mar 2002 16:00:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19275 Tue, 19 Mar 2002 18:16:48 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DA9@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" , IP Security List Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in I KEv 2) Date: Tue, 19 Mar 2002 15:26:52 -0800 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 I don't think TS is able to setup SPD, or to enforce security policy. It's really indicate the configured SPD of the sa. If SPD is simple then there is no problem to put it in TS. However, once SPD gets complex (or include dynamic factor), it's so tedious to parse and analyze them. especially the only purpose of it is an index and an warning of mis-configuration for SPD. If two parties agree to have one 3DES/SHA1 SA as tunnel id 1 and another AES/MD5 SA as tunnel id 2. They can just setup SPD of (FTP,HTTP) to tunnel 1, (SMTP,TELNET) to tunnel 2. If it's mis-configured, the traffic won't go through (instead of IKE fails). Another example is the popular "policy/address grouping" features. If you config 2 policy group each has 2 sources address and 3 dst address, it's total 12 sa in IKEv1. it would be 2 sa with 6 TS payload each in IKEv2. It can be just simplified to have 2 sa with id 1 & 2, instead of trying to matching 2 out-of-order TS chaining. Michael Shieh -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Tuesday, March 19, 2002 2:17 PM To: IP Security List Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) On Tue, 19 Mar 2002, Markku Savela wrote: > However, if I just could get the IKEv2 designers to see this minor > distinction between SPD stuff and SAD stuff, and treat TS as SAD > stuff, it seems almost perfect as defined. :-) The problem with this "minor distinction" is that it ignores the way IKE is actually used. People don't want a separate protocol, especially one that hasn't been designed yet, to do SPD setup. They want to do the whole job of connection setup with IKE, and to get that they are even willing to settle for a fairly simple subset of SPD functionality. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 19 17:33:46 2002 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 g2K1Xb409720; Tue, 19 Mar 2002 17:33:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19610 Tue, 19 Mar 2002 19:27:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message Subject: RE: Draft ipsec agendas Date: Tue, 19 Mar 2002 16:35:34 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D0146A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Draft ipsec agendas thread-index: AcHPnR+aPzRo4EK+SQeX2knlmCZWpAABtCbQ From: "William Dixon" To: "Theodore Ts'o" , Cc: X-OriginalArrivalTime: 20 Mar 2002 00:35:31.0846 (UTC) FILETIME=[244AE260:01C1CFA7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of the recent IP Storage using IPsec discussion ? I'm happy to squeeze in where someone finishes early. I mainly want to poll the audience of implementers to see what IPsec GW implementation can accept and run an IPSec tunnel SA for a single or aggregate of TCP connections at 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Possible Quick Mode proposal of an IP storage initiator to IPSec GW: Src IP = initiator real IP Dst IP = target real IP (the target is behind the gateway, not the GW IP itself) Protocol = TCP Src Port = * or Dst Port = wellknown (e.g. 3260 for iSCSI) The polling of vendors is important to determine if the target community can achieve their goal of bolting on a commercial IPsec security gateway in front of a (single or group of) IP storage target(s), perhaps find those that could be used for interop testing in 3 months. I am still thinking transport mode is more appropriate choice for securing IP Storage TCP connections, but nevertheless, we should determine if IPsec GWs vendors can deal with a tunnel like this, and what the tunnel mode alternative is if they can't. Interested folks can see latest draft, but I don't think this version made cutoff for submission and isn't current with yesterday's discussion yet. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Thx, Wm From owner-ipsec@lists.tislabs.com Tue Mar 19 18:34:21 2002 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 g2K2YF411005; Tue, 19 Mar 2002 18:34:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20113 Tue, 19 Mar 2002 20:40:46 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DAD@NS-CA> From: Michael Choung Shieh To: "'William Dixon'" , "Theodore Ts'o" , ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Date: Tue, 19 Mar 2002 17:51:39 -0800 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 William, I cannot open the link of the draft. For performance reason, I would prefer tunnel mode since it requires fewer operation, and we only support tunnel mode. Our current products can support upto 350Mb/s for single TCP session and 1Gb/b for aggregate sessions. I think many vendors can do more than 100Mb/s these days. Michael Shieh -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Tuesday, March 19, 2002 4:36 PM To: Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of the recent IP Storage using IPsec discussion ? I'm happy to squeeze in where someone finishes early. I mainly want to poll the audience of implementers to see what IPsec GW implementation can accept and run an IPSec tunnel SA for a single or aggregate of TCP connections at 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Possible Quick Mode proposal of an IP storage initiator to IPSec GW: Src IP = initiator real IP Dst IP = target real IP (the target is behind the gateway, not the GW IP itself) Protocol = TCP Src Port = * or Dst Port = wellknown (e.g. 3260 for iSCSI) The polling of vendors is important to determine if the target community can achieve their goal of bolting on a commercial IPsec security gateway in front of a (single or group of) IP storage target(s), perhaps find those that could be used for interop testing in 3 months. I am still thinking transport mode is more appropriate choice for securing IP Storage TCP connections, but nevertheless, we should determine if IPsec GWs vendors can deal with a tunnel like this, and what the tunnel mode alternative is if they can't. Interested folks can see latest draft, but I don't think this version made cutoff for submission and isn't current with yesterday's discussion yet. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Thx, Wm From owner-ipsec@lists.tislabs.com Tue Mar 19 18:44:59 2002 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 g2K2is411273; Tue, 19 Mar 2002 18:44:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20227 Tue, 19 Mar 2002 20:57:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message Subject: IP Storage over IPsec tunnel mode w/IPsec GWs Date: Tue, 19 Mar 2002 18:05:14 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D0146C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IP Storage over IPsec tunnel mode w/IPsec GWs thread-index: AcHPsWhVqfzesMbCSH+juFnx9fLpoQAATsag From: "William Dixon" To: "Michael Choung Shieh" , "Theodore Ts'o" , Cc: X-OriginalArrivalTime: 20 Mar 2002 02:05:12.0291 (UTC) FILETIME=[AB49A330:01C1CFB3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Maybe I should ask if any IPSec GW vendors see a problem with their tunnel implementation supporting this scenario ? Note this only really applies to this scenario: InitiatorHBA ===TCP inside IPsec tunnel===> IPsecGW ----TCP--> target When IP storage deployments use the following GW-to-GW scenario, then it's purely an IPsec GW interop issue, and nothing an IPS/IPsec integrated solution needs to interop. InitiatorHBA --- TCP --->IPsecGW ====IPsec Tunnel===== IPsecWG ---TCP--->Target Sorry for the broken link. I found the Feb 27th version of the draft did get submitted and is posted on the IP Storage WG page: http://www.ietf.org/html.charters/ips-charter.html Latest security draft, Feb 27th: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-11.txt -----Original Message----- From: Michael Choung Shieh [mailto:mshieh@netscreen.com] Sent: Tuesday, March 19, 2002 5:52 PM To: William Dixon; Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas William, I cannot open the link of the draft. For performance reason, I would prefer tunnel mode since it requires fewer operation, and we only support tunnel mode. Our current products can support upto 350Mb/s for single TCP session and 1Gb/b for aggregate sessions. I think many vendors can do more than 100Mb/s these days. Michael Shieh -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Tuesday, March 19, 2002 4:36 PM To: Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of the recent IP Storage using IPsec discussion ? I'm happy to squeeze in where someone finishes early. I mainly want to poll the audience of implementers to see what IPsec GW implementation can accept and run an IPSec tunnel SA for a single or aggregate of TCP connections at 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Possible Quick Mode proposal of an IP storage initiator to IPSec GW: Src IP = initiator real IP Dst IP = target real IP (the target is behind the gateway, not the GW IP itself) Protocol = TCP Src Port = * or Dst Port = wellknown (e.g. 3260 for iSCSI) The polling of vendors is important to determine if the target community can achieve their goal of bolting on a commercial IPsec security gateway in front of a (single or group of) IP storage target(s), perhaps find those that could be used for interop testing in 3 months. I am still thinking transport mode is more appropriate choice for securing IP Storage TCP connections, but nevertheless, we should determine if IPsec GWs vendors can deal with a tunnel like this, and what the tunnel mode alternative is if they can't. Interested folks can see latest draft, but I don't think this version made cutoff for submission and isn't current with yesterday's discussion yet. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Thx, Wm From owner-ipsec@lists.tislabs.com Tue Mar 19 22:03:37 2002 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 g2K63V415132; Tue, 19 Mar 2002 22:03:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21239 Wed, 20 Mar 2002 00:01:25 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB1@NS-CA> From: Michael Choung Shieh To: "'William Dixon'" , "Theodore Ts'o" , ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Date: Tue, 19 Mar 2002 21:12:17 -0800 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 Oop, I made a mistake on our product performance. It's 250Mb/s for single vpn session and 600Mb/s for aggregated vpn session, as stated in our marketing literature. Michael Shieh -----Original Message----- From: Michael Choung Shieh [mailto:mshieh@netscreen.com] Sent: Tuesday, March 19, 2002 5:52 PM To: 'William Dixon'; Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas William, I cannot open the link of the draft. For performance reason, I would prefer tunnel mode since it requires fewer operation, and we only support tunnel mode. Our current products can support upto 350Mb/s for single TCP session and 1Gb/b for aggregate sessions. I think many vendors can do more than 100Mb/s these days. Michael Shieh -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Tuesday, March 19, 2002 4:36 PM To: Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of the recent IP Storage using IPsec discussion ? I'm happy to squeeze in where someone finishes early. I mainly want to poll the audience of implementers to see what IPsec GW implementation can accept and run an IPSec tunnel SA for a single or aggregate of TCP connections at 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Possible Quick Mode proposal of an IP storage initiator to IPSec GW: Src IP = initiator real IP Dst IP = target real IP (the target is behind the gateway, not the GW IP itself) Protocol = TCP Src Port = * or Dst Port = wellknown (e.g. 3260 for iSCSI) The polling of vendors is important to determine if the target community can achieve their goal of bolting on a commercial IPsec security gateway in front of a (single or group of) IP storage target(s), perhaps find those that could be used for interop testing in 3 months. I am still thinking transport mode is more appropriate choice for securing IP Storage TCP connections, but nevertheless, we should determine if IPsec GWs vendors can deal with a tunnel like this, and what the tunnel mode alternative is if they can't. Interested folks can see latest draft, but I don't think this version made cutoff for submission and isn't current with yesterday's discussion yet. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Thx, Wm From owner-ipsec@lists.tislabs.com Wed Mar 20 00:28:43 2002 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 g2K8Sb402859; Wed, 20 Mar 2002 00:28:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA22028 Wed, 20 Mar 2002 02:29:57 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Addresses in traffic selectors in IKEv2 Date: Tue, 19 Mar 2002 18:40:29 -0500 Message-ID: <000001c1cfe1$99303870$0fb63fa6@ca.alcatel.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 Importance: Normal In-Reply-To: <15511.32828.539107.799107@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Exactly. No one is suggesting that your user interface has to map exactly to what you send on the wire. In fact, you are perfectly free to have your policy code reject any selectors which are not expressable as a subnet. As for which format is optimal, how many people do you think actually use selectors like *.*.*.7 as opposed to 1.2.3.[8-56]? How many IKE implementations do you think would even accept a selector like *.*.*.7? Admittedly, it is always possible to convert a range to a list of subnets, but it is much harder to do the opposite. Say that you prefer your code to use ranges. Using the earlier example: IP Start Address: 18.101.1.3 (0x12650103) IP End Address: 18.101.1.9 (0x12650109) Classifier Address Range -------------------- --------------------------------- 18.101.1.3/32 18.101.1.3 -> 18.101.1.3 18.101.1.4/30 18.101.1.4 -> 18.101.1.7 18.101.1.8/31 18.101.1.8 -> 18.101.1.9 Total Classifiers: 3 The code to convert this range into a list of subnets is straight-forward. The code to parse a list of subnets and look for candidates to merge into ranges is not. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Thomas > Sent: Tuesday, March 19, 2002 1:15 PM > To: David Waitzman > Cc: ipsec@lists.tislabs.com > Subject: Re: Addresses in traffic selectors in IKEv2 > > > > Isn't this just a presentation issue? That is, you > could allow net admins to input things as subnets, > but under the hood, it converts things to ranges > for IKE. I'd think the TCAM issue would be > similar: if people mainly use the selectors on > subnet boundaries, it wouldn't have an effect on > TCAM consumption, right? Assuming that you allow > for ranges anyway, I don't really see what the > upside is. > > Mike > > > David Waitzman writes: > > > > We recommend against ranges and for masks for two reasons: > > > > - ranges are less natural to network administrators; they tend to > > work more with IP prefixes (masks) when handling configuration > > tasks; IP prefixes also tend to reflect the > sub-topology of a local > > network, while ranges don't. (However, ranges are more > flexible, > > and *don't* bind you to subnet topology, so they're also useful, > > especially for things like web farms.) > > > > - (as stated already) arbitrary ranges don't compile into ternary > > CAMs very well, especially if there are multiple range-based > > selectors in a policy or SAD entry; in the worst case, it uses > > 2*(log2 rangeSize)-1 entries per range; if multiple ranges are > > found in the same selector, you need the *product* of > the number of > > CAM entries for each field, in total. (Don't expect > this happens > > much in the real world, though.) IP prefixes (or other > mask/value > > entries) only require a single CAM entry. > > > > -david waitzman > > BBN Technologies Internetwork Research Department > From owner-ipsec@lists.tislabs.com Wed Mar 20 01:18:19 2002 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 g2K9ID411632; Wed, 20 Mar 2002 01:18:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22349 Wed, 20 Mar 2002 03:31:41 -0500 (EST) Message-ID: From: "Ishola, Yemi" To: "'ipsec@lists.tislabs.com'" Subject: FW: unsubscribe yemi.ishola@cnh.com Date: Wed, 20 Mar 2002 01:41:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFE2.AADC5710" 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_01C1CFE2.AADC5710 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C1CFE2.AADC5710 Content-Type: text/html; charset="iso-8859-1" FW: unsubscribe yemi.ishola@cnh.com ------_=_NextPart_001_01C1CFE2.AADC5710-- From owner-ipsec@lists.tislabs.com Wed Mar 20 08:17:21 2002 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 g2KGHK418308; Wed, 20 Mar 2002 08:17:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24367 Wed, 20 Mar 2002 10:16:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1D023.EDE49454" Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Date: Wed, 20 Mar 2002 07:28:47 -0800 Message-ID: <7B8824D690092B4B90B0EF4674750A650231DB77@USEXCH3.us.sonicwall.com> X-MS-TNEF-Correlator: <7B8824D690092B4B90B0EF4674750A650231DB77@USEXCH3.us.sonicwall.com> Thread-Topic: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Thread-Index: AcHPoXFL04U6kLdAT8qQryMtZrlJZAAgBMVY From: "Scott Kelly" To: "Michael Choung Shieh" , "'Henry Spencer'" , "IP Security List" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D023.EDE49454 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael, Comments inline below... Michael Choung Shieh wrote: > I don't think TS is able to setup SPD, or to enforce security policy. It's > really indicate the configured SPD of the sa. If SPD is simple then there > is no problem to put it in TS. However, once SPD gets complex (or include > dynamic factor), it's so tedious to parse and analyze them. especially the > only purpose of it is an index and an warning of mis-configuration for SPD. I agree that traffic selectors are not meant to be used for SPD setup, but I disagree with the statement regarding policy enforcement. Upon receiving selectors, I think an implementation should verify that these do not run afoul of configured policy (in the SPD), i.e. I think they directly relate to policy enforcement. Their purpose is more than to provide an index or a warning of misconfiguration. The two SGW's may be in different domains of control. This means they may have different policies. The purpose of ID payloads is to indicate what traffic type(s) the other end would like to place in the SA. > If two parties agree to have one 3DES/SHA1 SA as tunnel id 1 and another > AES/MD5 SA as tunnel id 2. They can just setup SPD of (FTP,HTTP) to tunnel > 1, (SMTP,TELNET) to tunnel 2. If it's mis-configured, the traffic won't go > through (instead of IKE fails). This seems to assume that either the SGWs are in the same domain of control, or that they have agreed in advance to associate certain IDs with certain selector aggregates. This is not scalable, and almost certainly precludes the notion of "opportunistic" SA setup. > Another example is the popular "policy/address grouping" features. If you > config 2 policy group each has 2 sources address and 3 dst address, it's > total 12 sa in IKEv1. it would be 2 sa with 6 TS payload each in IKEv2. It > can be just simplified to have 2 sa with id 1 & 2, instead of trying to > matching 2 out-of-order TS chaining. I think the ability to aggregate the IDs into one SA (pair), as proposed for IKEv2, is a significant improvement over v1. Yes, it is more complex than single ID payloads, but the payoff is in reduced overall overhead for the SGWs. In enterprise VPN deployments, it is very common to encounter multiple subnets behind each SGW, and the current need to negotiate one SA pair per subnet pair is a limiting factor in tunnel capacity. This proposal resolves this issue. Scott =20 ------_=_NextPart_001_01C1D023.EDE49454 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjEPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEASAAAAFJFOiByZW1vdmUgVFMgZnJv bSBJS0V2MiAoUkU6IEFkZHJlc3NlcyBpbiB0cmFmZmljIHNlbGVjdG9ycyBpbiBJS0V2IDIpAF0X AQWAAwAOAAAA0gcDABQABwAcAC8AAwBFAQEggAMADgAAANIHAwAUAAcAHAAvAAMARQEBCYABACEA AABCNkM3OTc5M0Q1MjlGNTRCQTc2RkUyMTFGMzVERjE2OABHBwEDkAYATA4AADYAAAADADYAAAAA AEAAOQBUlOTtI9DBAR4APQABAAAABQAAAFJFOiAAAAAAAgFHAAEAAAA5AAAAYz1VUzthPSA7cD1T b25pY1dBTEwsIEluYy47bD1VU0VYQ0gzLTAyMDMyMDE1Mjg0N1otNTExMzAAAAAAHgBJAAEAAABI AAAAUkU6IHJlbW92ZSBUUyBmcm9tIElLRXYyIChSRTogQWRkcmVzc2VzIGluIHRyYWZmaWMgc2Vs ZWN0b3JzIGluIElLRXYgMikAQABOAABGrIydz8EBHgBaAAEAAAAVAAAATWljaGFlbCBDaG91bmcg U2hpZWgAAAAAAgFbAAEAAABHAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAATWljaGFlbCBDaG91 bmcgU2hpZWgAU01UUABtc2hpZWhAbmV0c2NyZWVuLmNvbQAAAgFcAAEAAAAaAAAAU01UUDpNU0hJ RUhATkVUU0NSRUVOLkNPTQAAAB4AXQABAAAAFQAAAE1pY2hhZWwgQ2hvdW5nIFNoaWVoAAAAAAIB XgABAAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE1pY2hhZWwgQ2hvdW5nIFNoaWVoAFNN VFAAbXNoaWVoQG5ldHNjcmVlbi5jb20AAAIBXwABAAAAGgAAAFNNVFA6TVNISUVIQE5FVFNDUkVF Ti5DT00AAAAeAGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAAFQAAAG1zaGllaEBuZXRzY3JlZW4u Y29tAAAAAB4AaAABAAAABQAAAFNNVFAAAAAAHgBpAAEAAAAVAAAAbXNoaWVoQG5ldHNjcmVlbi5j b20AAAAAHgBwAAEAAABEAAAAcmVtb3ZlIFRTIGZyb20gSUtFdjIgKFJFOiBBZGRyZXNzZXMgaW4g dHJhZmZpYyBzZWxlY3RvcnMgaW4gSUtFdiAyKQACAXEAAQAAABsAAAABwc+hcUvThTqQt0BPypCv Iy1muUlkACAExVgAHgB0AAEAAAAiAAAAJ0hlbnJ5IFNwZW5jZXInOyBJUCBTZWN1cml0eSBMaXN0 AAAAHgAaDAEAAAAMAAAAU2NvdHQgS2VsbHkAHgAdDgEAAABEAAAAcmVtb3ZlIFRTIGZyb20gSUtF djIgKFJFOiBBZGRyZXNzZXMgaW4gdHJhZmZpYyBzZWxlY3RvcnMgaW4gSUtFdiAyKQACAQkQAQAA AOMGAADfBgAACQsAAExaRnUo0pUSAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP 8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREi DGBjAFAzCwkBZDM2FlALpiBIjmkF0A3gE+BlbCwKovcKhAqACFBtB4ACMAQgC4AibAuAZSBiHXBv d14uH7Adqh0lEiBoCGBuimcGAGgIkGggdwNgBQ6wOh2kPiBJIGQVAiAnBUB0IaBuayBWVAXwBAAg AaBsH0B0JG8gFBF1cAYAUEQ8LCAFsSRhCfACEHJjCx9AFBBjCHF0eSBwIwbwDeB5LiAiwHQnbnMi VhggB0BsJpALgGR9DeBhDrAjQR9ABaAlsGleZwhwCYAk4iUwZijzc75hJxIqQCnyI+EAkG0LUL8o 4wOgKQEYICJWI+FuJHCWcANgJCFtJFJwdQVALyZwHuEjoScRSB+QZXbbBJAlIW4l8SnyZxQgBCBj BaArsnggKAWxC4BjBwpAAQAiVmR5bmFtmQ3gIGYA0CRgciklIP8mcCdgJIAkcA6wKJAIYAQgPy4C E/IkACiANNEHQHl67SjjbScRB5BwBZAHMShB3ykBIlYCIChBLjByJrA0sf8qMS5yI/EDoChxMOE0 5CHgnwrAAwAhYSoxMoBzLSlGfyjANAADoCXBJOIf2yLQYf8JwiNBKMAjQDswASAykRQQ/yQwMuIj 8RggLUEFQAeAAHD3IzEkcB9gIDQgKcE7pSSE/SUgYi5BItEEAD0EA/AjUN8qVAGQDrAekifxZwsR OhLvJrQllh6SJxBVJrADoBgg+SXwaXY6Ej43JSAi0CNUrzjSK7IekjtEcyExbCnQ/y9hBpA2oj2C KRA0sSLwPwP+ciFQJAACEEjAKiIpSUQVniguoSkCJPEzIi5lJxDfRvYpASaQKJBFoXQoQRgg3wtg KNItYUQvJxBUKRBOkP83tyPhBGA+4T1hLDEtY0Xw9wEAOMgFsWE5zTrLUNMjQOJ3JHBTR1czcQDA JpD/P+EuoSiQASAscT+BIvAAwP8LgAQgSzQ9sAbwUNJR0j9h/zQxTkJW4hPgL2BXeSazCJC2c1Xk N8lJKhAKsHkXsNxhZB7RNDMod3c9eiaA8TYwKHMpKPMiECxhJZHvKdBWUEjCHxBrT2QLYCXx/UyW QR/bIrEqQVZRCrE7UD8HkT0FJHBaowIgH0AzRIBFUy9TSEExYqG/JAA0MSFQHzADIFMQIGZQFzTk YGMiVkFl8U1ENX1mbzInEVDxJpAosAOgag80IAVAJJcqIihGVFD4LEhUbFBgATOxZuMiViIxJSAo U01sUVRF8ExORVRsyWozKvEzU386igmAJSApAj22VlAjEmfObyJWI1ADYHVnIdBMgc9C0CgQKdBc 8ktFMrEDEH9f8B/bWWMUEC3QNDNmoHP+dQeAPVRF0GBzTMNWkD60/0yVKqB28VgkWJklJEmFWoXv PQMp0C6hXaB2AHAl8XaE/m82USjRJfAAIHmiXSAEIP9CQ322PjY88QnBQ5AOsFwD/yPhLSNrQSiw C2AkISUgNOP+bARgazF9tTeSRaExglnzxz8CO2IqMSJvcCawACDnIVAEADtQYyJpMiSTYt32QWfk JZB4MnArwl3iXEJXhNBIwArBIia0L12gZO8YIAQRCcAIYHA6EYWgV7DvKMApoVwBKuJ5CGAiVilE /2owT6aKIyWQANAh0BPgBCB/FEAzoAhwJfAj8Ym1NOIz/yLgazGJpTM0cqciEAdAZ2DPjkFUEH4C dHB2MScRLnHvYQQ/4ZHDQkM2I6JdVY2k+5IVb6N0i9cDkT/haxQror8GkAiQKdBlFpOIZ0MmajD3 MzFzyD2weToSJGAiVgDAnnQT0DoSFEAIYHQtKjD/nGALIBKBI7ET0QuAOhE8Hf9N1yQBAxAmcnaC f+Yo834y7wuAJGFlkmZxKAqwTpAzIf9moS2BN/JARJVzMzEj8SuB/mcDAD3xP3IroVLhQxSlEfsF wJJyWQeQMzJRxzCWUlP/AJAhYCQxXSlBNIhjVvAqMPc4UR7SJ/FkGtApwaWSKCH/pYMpEHQBO6J3 5k2RA6AeoY8EkC2ABAAfQFZQTiLg+mULUG8GwB6iplYvYWqx/x5xO3ElcwWgIVCtQTpwSMD3O1Ar wnbQYh8wHsEfYCNh/5TVVoGB1CkDCHBX0x8wl9T/HzBygDtQKMKhZaHiJqASgf+xZLV0o8MfEDKA O1AhYTLE/2IzZuQosAqwNlAmgFlFooT/kYGJ0QbwL2BZ8oCzdtBNgH0dqlMFoAJAHaQnIB2kfQG9 gAAeADUQAQAAAEQAAAA8N0I4ODI0RDY5MDA5MkI0QjkwQjBFRjQ2NzQ3NTBBNjUwMjMxREI3N0BV U0VYQ0gzLnVzLnNvbmljd2FsbC5jb20+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQ AQAAAB8A8xABAAAAoAAAAFIARQAlADMAQQAgAHIAZQBtAG8AdgBlACAAVABTACAAZgByAG8AbQAg AEkASwBFAHYAMgAgACgAUgBFACUAMwBBACAAQQBkAGQAcgBlAHMAcwBlAHMAIABpAG4AIAB0AHIA YQBmAGYAaQBjACAAcwBlAGwAZQBjAHQAbwByAHMAIABpAG4AIABJAEsARQB2ACAAMgApAC4ARQBN AEwAAAALAPYQAAAAAEAABzCy3GGEIdDBAUAACDBEp/ftI9DBAQMA3j/kBAAAAwDxPwkAAAAeAPg/ AQAAAAwAAABTY290dCBLZWxseQACAfk/AQAAAFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAA AAAAL089U09OSUNXQUxMLCBJTkMuL09VPVNPTklDV0FMTC9DTj1SRUNJUElFTlRTL0NOPVNLRUxM WQAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdA yMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAA AwAeQAAAAAAeADBAAQAAAAcAAABTS0VMTFkAAB4AMUABAAAABwAAAFNLRUxMWQAAHgAyQAEAAAAV AAAAbXNoaWVoQG5ldHNjcmVlbi5jb20AAAAAHgAzQAEAAAAVAAAAbXNoaWVoQG5ldHNjcmVlbi5j b20AAAAAHgA4QAEAAAAHAAAAU0tFTExZAAAeADlAAQAAAAIAAAAuAAAACwApAAAAAAALACMAAAAA AAMABhBMDOHLAwAHEHkHAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASElNSUNIQUVMLENP TU1FTlRTSU5MSU5FQkVMT1dNSUNIQUVMQ0hPVU5HU0hJRUhXUk9URTpJRE9OVFRISU5LVFNJU0FC TEVUT1NFVFVQU1BELE9SVE9FTkZPUkNFU0VDVVJJVAAAAAACAX8AAQAAAEQAAAA8N0I4ODI0RDY5 MDA5MkI0QjkwQjBFRjQ2NzQ3NTBBNjUwMjMxREI3N0BVU0VYQ0gzLnVzLnNvbmljd2FsbC5jb20+ AN4P ------_=_NextPart_001_01C1D023.EDE49454-- From owner-ipsec@lists.tislabs.com Wed Mar 20 08:25:34 2002 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 g2KGPX418651; Wed, 20 Mar 2002 08:25:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24481 Wed, 20 Mar 2002 10:37:55 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Wed, 20 Mar 2002 08:49:02 -0700 From: "Umasankar Mukkara" To: Subject: auth 5412fca8 subscribe ipsec mumasankar@novell.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From owner-ipsec@lists.tislabs.com Wed Mar 20 08:59:44 2002 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 g2KGxh426050; Wed, 20 Mar 2002 08:59:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24650 Wed, 20 Mar 2002 11:11:38 -0500 (EST) Message-Id: <200203201622.g2KGM8gw011868@thunk.East.Sun.COM> From: Bill Sommerfeld To: "IP Security List" Subject: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 07:28:47 PST." <7B8824D690092B4B90B0EF4674750A650231DB77@USEXCH3.us.sonicwall.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 20 Mar 2002 11:22:08 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The purpose of traffic selectors is *not* to modify the SPD, but rather to allow policy compatibility (or lack thereof) to be discovered sooner rather than later. While this is completely irrelevant for centrally-provisioned VPN's, it's extremely important for opportunistic use of IPsec between systems under heterogenous administration. I'd rather not see IPsec limited to VPN's, and as such strongly support the continued presence of traffic selectors in the protocol. - Bill (a solaris ipsec implementor) From owner-ipsec@lists.tislabs.com Wed Mar 20 09:32:44 2002 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 g2KHWh401665; Wed, 20 Mar 2002 09:32:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24872 Wed, 20 Mar 2002 11:47:15 -0500 (EST) Date: Wed, 20 Mar 2002 11:59:01 -0500 From: Theodore Tso To: William Dixon Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com, iscsi-security@external.cisco.com Subject: Re: Draft ipsec agendas Message-ID: <20020320115901.A1078@thunk.org> References: <2E33960095B58E40A4D3345AB9F65EC105D0146A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D0146A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from wdixon@windows.microsoft.com on Tue, Mar 19, 2002 at 04:35:34PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Mar 19, 2002 at 04:35:34PM -0800, William Dixon wrote: > Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of > the recent IP Storage using IPsec discussion ? I'm happy to squeeze in > where someone finishes early. I mainly want to poll the audience of > implementers to see what IPsec GW implementation can accept and run an > IPSec tunnel SA for a single or aggregate of TCP connections at > 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Sure, that would be fine. I'll give you 5 minutes on the agenda. - Ted From owner-ipsec@lists.tislabs.com Wed Mar 20 11:59:01 2002 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 g2KJx1407364; Wed, 20 Mar 2002 11:59:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25761 Wed, 20 Mar 2002 14:13:49 -0500 (EST) Message-ID: <005801c1d044$8ac8e620$05004c0a@rmohan> From: "Rajesh Mohan" To: , "IP Security List" References: <200203201622.g2KGM8gw011868@thunk.East.Sun.COM> Subject: Re: Don't remove TS from IKEv2 Date: Wed, 20 Mar 2002 11:22:14 -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 > The purpose of traffic selectors is *not* to modify the SPD, but > rather to allow policy compatibility (or lack thereof) to be > discovered sooner rather than later. > We cannot really negotiate traffic selectors through IKE. The only message we will probably get is "NO PROPOSAL CHOSEN". At IPSec layer, TS serves as a simple traffic filter firewall. By removing TS completely, we can integrate firewall & vpn better and the policy enforcer is as good as your firewall. For people without firewall solution, adding traffic filter should be no big deal. my 2 cents, -Rajesh M > While this is completely irrelevant for centrally-provisioned VPN's, > it's extremely important for opportunistic use of IPsec between > systems under heterogenous administration. > > I'd rather not see IPsec limited to VPN's, and as such strongly > support the continued presence of traffic selectors in the protocol. > > - Bill > (a solaris ipsec implementor) > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 20 11:59:03 2002 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 g2KJx2407379; Wed, 20 Mar 2002 11:59:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25718 Wed, 20 Mar 2002 14:09:44 -0500 (EST) Message-ID: <20020320184531.72512.qmail@web12208.mail.yahoo.com> Date: Wed, 20 Mar 2002 10:45:31 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: analysis of the Fluhrer attack and some experiments To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We did an analysis of the preconditions of exploiting the Fluhrer attack, and also did some practical attack tests. We hope this will be useful for feedback for the WG work. The paper can be found at: http://www.hut.fi/~svaarala/espiv.pdf We'd appreciate feedback on the paper and the attack. Best regards, -Sami -- Sami Vaarala Senior System Architect Netseal __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Mar 20 11:59:09 2002 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 g2KJx8407401; Wed, 20 Mar 2002 11:59:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25693 Wed, 20 Mar 2002 14:06:55 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB3@NS-CA> From: Michael Choung Shieh To: "'Scott Kelly'" , Michael Choung Shieh , "'Henry Spencer'" , IP Security List Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in I KEv 2) Date: Wed, 20 Mar 2002 11:17:23 -0800 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 my comment inserted, > -----Original Message----- > From: Scott Kelly [mailto:skelly@SonicWALL.com] > Sent: Wednesday, March 20, 2002 7:29 AM > To: Michael Choung Shieh; 'Henry Spencer'; IP Security List > Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic > selectors in > IKEv 2) > > > Hi Michael, > > Comments inline below... > > Michael Choung Shieh wrote: > > I don't think TS is able to setup SPD, or to enforce > security policy. It's > > really indicate the configured SPD of the sa. If SPD is > simple then there > > is no problem to put it in TS. However, once SPD gets > complex (or include > > dynamic factor), it's so tedious to parse and analyze them. > especially the > > only purpose of it is an index and an warning of > mis-configuration for SPD. > > I agree that traffic selectors are not meant to be used for > SPD setup, but I disagree with the statement regarding policy > enforcement. Upon receiving selectors, I think an > implementation should verify that these do not run afoul of > configured policy (in the SPD), i.e. I think they directly > relate to policy enforcement. Their purpose is more than to > provide an index or a warning of misconfiguration. The two > SGW's may be in different domains of control. This means they > may have different policies. The purpose of ID payloads is to > indicate what traffic type(s) the other end would like to > place in the SA. > ID payload only "indicate" what type of traffic come out of tunnel, but it cannot enforce what comes out of it. The receiving side still needs to check every single packet to verify it > > If two parties agree to have one 3DES/SHA1 SA as tunnel id > 1 and another > > AES/MD5 SA as tunnel id 2. They can just setup SPD of > (FTP,HTTP) to tunnel > > 1, (SMTP,TELNET) to tunnel 2. If it's mis-configured, the > traffic won't go > > through (instead of IKE fails). > > This seems to assume that either the SGWs are in the same > domain of control, or that they have agreed in advance to > associate certain IDs with certain selector aggregates. This > is not scalable, and almost certainly precludes the notion of > "opportunistic" SA setup. > Acturally the two parties need to get some kind of agreement before tunnels establish. Even using TS they must be agreed in advance so they won't get totally mis-matched. Agree on a single id (or name) probably is simpler than on TS. I am not sure if "opportunistic" is really useful in real world. Users want tunnel up and works, instead of "let's try it, it's good if it works, and it's ok if it doesn't work". We need to define a protocol to advocate the most interoperability but not counting on the content of TS (or any payloads) to have best chance to create tunnels. > > Another example is the popular "policy/address grouping" > features. If you > > config 2 policy group each has 2 sources address and 3 dst > address, it's > > total 12 sa in IKEv1. it would be 2 sa with 6 TS payload > each in IKEv2. It > > can be just simplified to have 2 sa with id 1 & 2, instead > of trying to > > matching 2 out-of-order TS chaining. > > I think the ability to aggregate the IDs into one SA (pair), > as proposed for IKEv2, is a significant improvement over v1. > Yes, it is more complex than single ID payloads, but the > payoff is in reduced overall overhead for the SGWs. In > enterprise VPN deployments, it is very common to encounter > multiple subnets behind each SGW, and the current need to > negotiate one SA pair per subnet pair is a limiting factor in > tunnel capacity. This proposal resolves this issue. > TS is definitely big improvement over proxy-id. I agree it solves lots of problems in IKEv1. However, it's not good enough to solve those scenarios with dynamic nature (routing or dynamic NAT). Today's solution is to try the best to aggregate all known traffic or just put 0/0 to allow all, but the solution is totally defeat the purpose of TS. Michael Shieh > Scott > > From owner-ipsec@lists.tislabs.com Wed Mar 20 12:00:26 2002 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 g2KK0Q407595; Wed, 20 Mar 2002 12:00:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25792 Wed, 20 Mar 2002 14:19:12 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB4@NS-CA> From: Michael Choung Shieh To: "'sommerfeld@east.sun.com'" , IP Security List Subject: RE: Don't remove TS from IKEv2 Date: Wed, 20 Mar 2002 11:30:06 -0800 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 I would say agree on a simple id or name is easier than on a complex selector under heterogenous adminstration. Like my another email mentions, as I am not sure if opportunistic ipsec really works in real world. However, if you talk about the opportunity to get tunnel up and running, using an id may have much bigger chance than comparing TS payload. I agree TS will allow policy compatibility to be discovered earlier. However, it's too tedious to make TS right in dynamic routing and NAT. I also wonder if a key managment protocol should bear the responsibility to check SPD configuration. TS can be an optional payload in IKE so it MAY provide additional warning to the admin. However, it shouldn't affect the creation of tunnel. Michael Shieh > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, March 20, 2002 8:22 AM > To: IP Security List > Subject: Don't remove TS from IKEv2 > > > The purpose of traffic selectors is *not* to modify the SPD, but > rather to allow policy compatibility (or lack thereof) to be > discovered sooner rather than later. > > While this is completely irrelevant for centrally-provisioned VPN's, > it's extremely important for opportunistic use of IPsec between > systems under heterogenous administration. > > I'd rather not see IPsec limited to VPN's, and as such strongly > support the continued presence of traffic selectors in the protocol. > > - Bill > (a solaris ipsec implementor) > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 20 12:01:34 2002 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 g2KK1Y407763; Wed, 20 Mar 2002 12:01:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25798 Wed, 20 Mar 2002 14:19:48 -0500 (EST) Message-ID: <20020320193138.16230.qmail@web12204.mail.yahoo.com> Date: Wed, 20 Mar 2002 11:31:38 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: Analysis and some experiments of Fluhrer's ESP IV attack (re-post) To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (I'm not sure whether my previous mail reached the list, sorry for the repost). We did some analysis of the preconditions of Fluhrer's ESP IV attack, and also did a few practical attack tests. The paper and other stuff (related to the course we did the paper for) is at: http://www.hut.fi/~svaarala/espiv.pdf http://www.hut.fi/~svaarala/hakkeri2002/index.html We'd appreciate any feedback. Best regards, -Sami -- Sami Vaarala Senior System Architect Netseal __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Mar 20 12:21:02 2002 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 g2KKL1408510; Wed, 20 Mar 2002 12:21:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25930 Wed, 20 Mar 2002 14:38:16 -0500 (EST) Date: Wed, 20 Mar 2002 13:49:31 -0600 (CST) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Rajesh Mohan cc: sommerfeld@east.sun.com, IP Security List Subject: Re: Don't remove TS from IKEv2 In-Reply-To: <005801c1d044$8ac8e620$05004c0a@rmohan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill's point, I think, is that in the absence of a well-defined and widely deployed policy distribution protocol, the TS payloads provide a simple and effective way of making sure that your traffic will in fact be accepted by the peer. Otherwise, your chances of creating black-hole tunnels increases dramatically. I'm for keeping TS payloads. jan On Wed, 20 Mar 2002, Rajesh Mohan wrote: > > The purpose of traffic selectors is *not* to modify the SPD, but > > rather to allow policy compatibility (or lack thereof) to be > > discovered sooner rather than later. > > > > We cannot really negotiate traffic selectors through IKE. The only message > we will probably get is "NO PROPOSAL CHOSEN". At IPSec layer, TS serves as a > simple traffic filter firewall. > > By removing TS completely, we can integrate firewall & vpn better and the > policy enforcer is as good as your firewall. For people without firewall > solution, adding traffic filter should be no big deal. > > my 2 cents, > -Rajesh M > > > > > > > > > While this is completely irrelevant for centrally-provisioned VPN's, > > it's extremely important for opportunistic use of IPsec between > > systems under heterogenous administration. > > > > I'd rather not see IPsec limited to VPN's, and as such strongly > > support the continued presence of traffic selectors in the protocol. > > > > - Bill > > (a solaris ipsec implementor) > > > > > > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Mar 20 12:26:57 2002 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 g2KKQv408939; Wed, 20 Mar 2002 12:26:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25962 Wed, 20 Mar 2002 14:46:10 -0500 (EST) Message-Id: <200203201956.g2KJudgw013467@thunk.East.Sun.COM> From: Bill Sommerfeld To: Michael Choung Shieh cc: IP Security List Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 11:30:06 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DB4@NS-CA> Reply-to: sommerfeld@east.sun.com Date: Wed, 20 Mar 2002 14:56:39 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I would say agree on a simple id or name is easier than on a complex > selector under heterogenous adminstration. That doesn't solve the problem. A name says *who* I'm talking to. The TS selectors specify the *scope* of the SA's that are being negotiated (i.e., address only, or 5-tuple, or ..). - Bill From owner-ipsec@lists.tislabs.com Wed Mar 20 12:53:43 2002 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 g2KKrh410614; Wed, 20 Mar 2002 12:53:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26152 Wed, 20 Mar 2002 15:07:59 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB5@NS-CA> From: Michael Choung Shieh To: "'sommerfeld@east.sun.com'" Cc: IP Security List Subject: RE: Don't remove TS from IKEv2 Date: Wed, 20 Mar 2002 12:18:50 -0800 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 An id or name (I mean phase 2 sa id, not phase 1) can represent the "scope", either it's a single address, or the combination of 10 adresses and 5 subnets and 6 ranges and 3 sevices. Besides, how do you decide if tunnel can be created if the "scopes" are a little different, or must be exact matched? How about it's dynamic scope? It's better to take it out of IKE or put it as optional. Michael Shieh > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, March 20, 2002 11:57 AM > To: Michael Choung Shieh > Cc: IP Security List > Subject: Re: Don't remove TS from IKEv2 > > > > I would say agree on a simple id or name is easier than on a complex > > selector under heterogenous adminstration. > > That doesn't solve the problem. > > A name says *who* I'm talking to. > > The TS selectors specify the *scope* of the SA's that are being > negotiated (i.e., address only, or 5-tuple, or ..). > > - Bill > From owner-ipsec@lists.tislabs.com Wed Mar 20 13:09:00 2002 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 g2KL8x410943; Wed, 20 Mar 2002 13:09:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26259 Wed, 20 Mar 2002 15:18:29 -0500 (EST) Message-Id: <200203202028.g2KKSpgw013737@thunk.East.Sun.COM> From: Bill Sommerfeld To: Michael Choung Shieh cc: "'sommerfeld@east.sun.com'" , IP Security List Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 12:18:50 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DB5@NS-CA> Reply-to: sommerfeld@east.sun.com Date: Wed, 20 Mar 2002 15:28:51 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Besides, how do you decide if tunnel can be created two words: "transport mode" From owner-ipsec@lists.tislabs.com Wed Mar 20 13:21:41 2002 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 g2KLLe411197; Wed, 20 Mar 2002 13:21:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26418 Wed, 20 Mar 2002 15:39:08 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB6@NS-CA> From: Michael Choung Shieh To: "'Jan Vilhuber'" , Rajesh Mohan Cc: sommerfeld@east.sun.com, IP Security List Subject: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Wed, 20 Mar 2002 12:49:42 -0800 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 It's only effective for simpler case. how do you define a FTP-ONLY TS? The list can drag on and on for DNS, AOL, and any new services/protocols. I would say to put it as optional will have the advantage you say and simplify the protocol. I think I need to change the subject to "move TS as optional" now. Another advantage is, especially in heterogenous admin case, one admin can just change his own incoming security policy without waiting another admin's approval. If you want to block out your extranet to access your accounting server, you can just block the access, without shuting down the whole tunnel, or wait your peer to change it. Michael Shieh > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Wednesday, March 20, 2002 11:50 AM > To: Rajesh Mohan > Cc: sommerfeld@east.sun.com; IP Security List > Subject: Re: Don't remove TS from IKEv2 > > > Bill's point, I think, is that in the absence of a well-defined and > widely deployed policy distribution protocol, the TS payloads provide > a simple and effective way of making sure that your traffic will in > fact be accepted by the peer. Otherwise, your chances of creating > black-hole tunnels increases dramatically. > > I'm for keeping TS payloads. > > jan > > > On Wed, 20 Mar 2002, Rajesh Mohan wrote: > > > > The purpose of traffic selectors is *not* to modify the SPD, but > > > rather to allow policy compatibility (or lack thereof) to be > > > discovered sooner rather than later. > > > > > > > We cannot really negotiate traffic selectors through IKE. > The only message > > we will probably get is "NO PROPOSAL CHOSEN". At IPSec > layer, TS serves as a > > simple traffic filter firewall. > > > > By removing TS completely, we can integrate firewall & vpn > better and the > > policy enforcer is as good as your firewall. For people > without firewall > > solution, adding traffic filter should be no big deal. > > > > my 2 cents, > > -Rajesh M > > > > > > > > > > > > > > > > > While this is completely irrelevant for > centrally-provisioned VPN's, > > > it's extremely important for opportunistic use of IPsec between > > > systems under heterogenous administration. > > > > > > I'd rather not see IPsec limited to VPN's, and as such strongly > > > support the continued presence of traffic selectors in > the protocol. > > > > > > - Bill > > > (a solaris ipsec implementor) > > > > > > > > > > > > > > > > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ipsec@lists.tislabs.com Wed Mar 20 14:54:35 2002 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 g2KMsY413451; Wed, 20 Mar 2002 14:54:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27141 Wed, 20 Mar 2002 17:11:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1D05D.E4CB0EA0" Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Date: Wed, 20 Mar 2002 14:23:43 -0800 Message-ID: <7B8824D690092B4B90B0EF4674750A650231DB7B@USEXCH3.us.sonicwall.com> X-MS-TNEF-Correlator: <7B8824D690092B4B90B0EF4674750A650231DB7B@USEXCH3.us.sonicwall.com> Thread-Topic: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Thread-Index: AcHPoXFL04U6kLdAT8qQryMtZrlJZAAgBMVYAAHS7hAADFWs/g== From: "Scott Kelly" To: "Michael Choung Shieh" , "Michael Choung Shieh" , "'Henry Spencer'" , "IP Security List" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D05D.E4CB0EA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael, Comments inline below, but I significantly trimmed the text. I don't think we actually disagree on all that much, but it's often difficult to convey complex thoughts in email. I'll try to clarify my position. Michael Choung Shieh wrote: > my comment inserted, >=20 > > I agree that traffic selectors are not meant to be used for=20 > > SPD setup, but I disagree with the statement regarding policy=20 > > enforcement. Upon receiving selectors, I think an=20 > > implementation should verify that these do not run afoul of=20 > > configured policy (in the SPD), i.e. I think they directly=20 > > relate to policy enforcement. Their purpose is more than to=20 > > provide an index or a warning of misconfiguration. The two=20 > > SGW's may be in different domains of control. This means they=20 > > may have different policies. The purpose of ID payloads is to=20 > > indicate what traffic type(s) the other end would like to=20 > > place in the SA. >=20 > ID payload only "indicate" what type of traffic come out of tunnel, but it > cannot enforce what comes out of it. The receiving side still needs to=20 > check every single packet to verify it Right, but if the other end's TS values don't match local policy to begin with, then the tunnel should not be established, right? > > This seems to assume that either the SGWs are in the same=20 > > domain of control, or that they have agreed in advance to=20 > > associate certain IDs with certain selector aggregates. This=20 > > is not scalable, and almost certainly precludes the notion of=20 > > "opportunistic" SA setup. > Acturally the two parties need to get some kind of agreement before tunnels > establish. Even using TS they must be agreed in advance so they won't get=20 > totally mis-matched. Agree on a single id (or name) probably is simpler=20 > than on TS. Since the proposed IKEv2 allows the responder to select a subset of the TS payloads, agreement is more likely. In some cases, the initiator will know with a high degree of certainty exactly what selectors are appropriate (e.g. when a tunnel is to be negotiated to protect a particular session, such as FTP), and in such cases, the initiator could pass exact TS values. The responder could, in such cases, have wildcard selectors for the source in its policy, with identity-based access control decisions being tied to successful IKE authentication. This scales very nicely. > I am not sure if "opportunistic" is really useful in real world. Users want > tunnel up and works, instead of "let's try it, it's good if it works, and > it's ok if it doesn't work". We need to define a protocol to advocate the=20 > most interoperability but not counting on the content of TS (or any > payloads) to have best chance to create tunnels. Yes, I agree that (typically) users will either want security or they won't. However, if IPsec actually proliferates, then it is conceivable that users will want to bring up connections with destinations with which they've never conversed before. In these cases, it is difficult to require that everyone know the other ends TS values in advance, and that they agree on special "meta" TS values. It just doesn't scale. On the other hand, I can see where such local meta TS values would be both simpler and useful within a single-vendor, single-admin-domain solution. This could be implemented using a privately defined payloads. > > I think the ability to aggregate the IDs into one SA (pair),=20 > > as proposed for IKEv2, is a significant improvement over v1.=20 > > Yes, it is more complex than single ID payloads, but the=20 > > payoff is in reduced overall overhead for the SGWs. In=20 > > enterprise VPN deployments, it is very common to encounter=20 > > multiple subnets behind each SGW, and the current need to=20 > > negotiate one SA pair per subnet pair is a limiting factor in=20 > > tunnel capacity. This proposal resolves this issue. >=20 > TS is definitely big improvement over proxy-id. I agree it solves lots of=20 > problems in IKEv1. However, it's not good enough to solve those scenarios=20 > with dynamic nature (routing or dynamic NAT). Today's solution is to try=20 > the best to aggregate all known traffic or just put 0/0 to allow all, but=20 > the solution is totally defeat the purpose of TS. I agree that there are scenarios for which the current proposals don't quite work. Previous posts (including yours) have mentioned the problem with dynamic protocols such as FTP, H.323, etc., where we have no way to statefully select TS values on the fly. I'd really like to see a standard solution to this problem. However, I don't see how elimininating TS support will resolve this. Please elaborate on what you have in mind. Thanks, Scott ------_=_NextPart_001_01C1D05D.E4CB0EA0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii8WAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEASAAAAFJFOiByZW1vdmUgVFMgZnJv bSBJS0V2MiAoUkU6IEFkZHJlc3NlcyBpbiB0cmFmZmljIHNlbGVjdG9ycyBpbiBJS0V2IDIpAF0X AQWAAwAOAAAA0gcDABQADgAXACsAAwBDAQEggAMADgAAANIHAwAUAA4AFwAuAAMARgEBCYABACEA AAA3Mzg3Njg1M0Q0ODc4RTRDQjRERDVDODRCRUExRUVGMQBmBwEDkAYA7BIAADYAAAADADYAAAAA AEAAOQCgDsvkXdDBAR4APQABAAAABQAAAFJFOiAAAAAAAgFHAAEAAAA5AAAAYz1VUzthPSA7cD1T b25pY1dBTEwsIEluYy47bD1VU0VYQ0gzLTAyMDMyMDIyMjM0M1otNTYxMzAAAAAAHgBJAAEAAABI AAAAUkU6IHJlbW92ZSBUUyBmcm9tIElLRXYyIChSRTogQWRkcmVzc2VzIGluIHRyYWZmaWMgc2Vs ZWN0b3JzIGluIElLRXYgMikAQABOADD799xD0MEBHgBaAAEAAAAVAAAATWljaGFlbCBDaG91bmcg U2hpZWgAAAAAAgFbAAEAAABHAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAATWljaGFlbCBDaG91 bmcgU2hpZWgAU01UUABtc2hpZWhAbmV0c2NyZWVuLmNvbQAAAgFcAAEAAAAaAAAAU01UUDpNU0hJ RUhATkVUU0NSRUVOLkNPTQAAAB4AXQABAAAAFQAAAE1pY2hhZWwgQ2hvdW5nIFNoaWVoAAAAAAIB XgABAAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE1pY2hhZWwgQ2hvdW5nIFNoaWVoAFNN VFAAbXNoaWVoQG5ldHNjcmVlbi5jb20AAAIBXwABAAAAGgAAAFNNVFA6TVNISUVIQE5FVFNDUkVF Ti5DT00AAAAeAGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAAFQAAAG1zaGllaEBuZXRzY3JlZW4u Y29tAAAAAB4AaAABAAAABQAAAFNNVFAAAAAAHgBpAAEAAAAVAAAAbXNoaWVoQG5ldHNjcmVlbi5j b20AAAAAHgBwAAEAAABEAAAAcmVtb3ZlIFRTIGZyb20gSUtFdjIgKFJFOiBBZGRyZXNzZXMgaW4g dHJhZmZpYyBzZWxlY3RvcnMgaW4gSUtFdiAyKQACAXEAAQAAACUAAAABwc+hcUvThTqQt0BPypCv Iy1muUlkACAExVgAAdLuEAAMVaz+AAAAHgB0AAEAAABFAAAAU2NvdHQgS2VsbHk7IE1pY2hhZWwg Q2hvdW5nIFNoaWVoOyAnSGVucnkgU3BlbmNlcic7IElQIFNlY3VyaXR5IExpc3QAAAAAHgAaDAEA AAAMAAAAU2NvdHQgS2VsbHkAHgAdDgEAAABEAAAAcmVtb3ZlIFRTIGZyb20gSUtFdjIgKFJFOiBB ZGRyZXNzZXMgaW4gdHJhZmZpYyBzZWxlY3RvcnMgaW4gSUtFdiAyKQACAQkQAQAAAFELAABNCwAA pBQAAExaRnXsBKxfAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUH shElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkB ZDM2FlALpiBIjmkF0A3gE+BlbCwKovcKhAqACFBtB4ACMAQgC4AibAuAZSBiHXBvd0osH1B1BUBJ IACQZw0DAGYN4ABwdGx5INZ0BRAegWQhAGgfQA6y6i4gAWQCICcFQCGQC4CYayB3H0AA0HR1B0DV IOFkBABhCcIgAiAjMKsjkCGBYQVAbRrQaB+06Gl0JwQgbwGACfAjwZMBIA3gdWwikW8gBaDYbnZl IPAFoG0LUA7AkyGBCGBnaB7DIGUAwOsDECIRJySiciDxJyELYEsGgSDwbSDwcG8AkHR6aQIgLh2q HSUSIChBbuZnBgAiwGVoIwADYA6w+jodpD4qkiexHpIe4RQQ/wAgCYAdlS4wLdYuMCAQJAT7JNMh EGEmkiAgHXAFkCcQZxQAIzAYICBuLZAlEGXnILEnAh9gIHUUECFwAhBjCtQwVFNQRDHxI2Bw3x+2 I9cD8CGQIYNzAZAOsPsusxggZwsRC4As8CrQHxDeYyDwMBgJ8DQxYzeDIhCeVSrQA6AYIDngaXY4 Qv8yBx+wIBAitAOSMCcHcCfh3x6SJPArISAgKEFsIXAncL8qUzE0IaAUECJBMtNyLNB/IzACECbQ JgEwCSdBIIBndwhwIWE4hSgowSGSNREp8R+waS5lIhIitCGRI7L/OrEg0jAYGCALYA6wJwI4hf05 m1QhoETgKsAIcCrRH0B/BAAlEAWwMRNC8ScgMBhw/wNgOwABADxyC4ABACgQBbG+YSMACsADACzh QOFtBAAvQbY940fDIQB3SapTR/5XJeEAwCDwM7EowSZyBJD/LsIiUCkBBjFA4SdBIRAG8P9HwkjC MzEEIESDMBhPEhPg7ydwT6k4gwiQc010SEZA4ZZJNTAKsHkXsGFkHtFfUiFJqksRIJFGQXcxSnTA eXBlKHMpIYMtkH8hoAXACfAhcE3gPnIfEGu/RlNJyQtgOeAoskMTQStVXy/2LdZV+CRRIOEiV7Yi /1g1WSFA0jGGJ7EkQR/hYKL/LNAfMB2AJXUt1iChMuI5lf9YNGFSJfFhtCXAIhBNgzq5/0qiN0AD EAMgHzAJgFbLE9D7BZAi8GU+sSDwAJAs4Cfwf1YRaKAUICcCPrVi1h2kUr8gQCiAJWVgsVmqJeFU BfC+dgdAClAEICJUAMB0E9C9WsBvIKADIDiFM4NnKMH/NrIfsCGRQvRiFD42MuIzsX8HkAGRHxA+ QC9hN9Broj+/XXwuMFGTFBAo8FbDYQQQ/nVhcSTTOuBZ40MTTsAyhP9C5SPwYXEwGFBUUMkfsAWx fz8mU1UkAyFwKMFWcG2gbv9cIUmbdYFu4AcwRkE54AAg/3kSVfAEIDazfcYyBjDBCcH/OAAOsFTT SME8uQQgMuIE8PsHQHKhZR+wAHAhcAdABGD/N0B9tiDhSmAFkApAAQBSI8cy0j4CQOsib3Aq0AAg 9yzQBAArEGNf4FzANUQrW/0uMEEjUTGQI5Ihk03hCrHvKxAHkWdiJwJnaeF9QGFx/mtLEUDSJAMu sx9gNDFxBu8EIDlxcoZloUUncAOgM+D/OEJtcUSDJSCDITOxez+K0f9EdE3gInKKoi3WJxABkCOS 3UxxLW5zCYBloUEkF2kmd0qgQsAFsW54AVlwSmFi/3KhapF00T1TNFhJQyRhbXD9K1tTC4B8IlUS A2BIciFw/ElLjiAUQCOBH5CEdBggPnM6cQSBJwIyBJRydWL/FBFgkyGhbXFWJoKBi8dIxv9a0iDg IhE+IWFiIKAUEDvRfyGSC4ArASTwBbED8CSha/8y4AfgNrNLoCLAKHAiQDfw3yQjUOF91FkQKOB4 I0Eg4XtYQzIMYYYwmcEHIUZBKP1D0GciEFhAJkFLoHElVrT7M7EfMGeE4TdhilNKYQ6w/5xjiaMm wQrBoKEAkAIgH7CHdaBuoXWAIEZUUEOB/4KifyKrgqCPf6IFoD5yCrD/BBGkc21oTXSbWK5jQ5Gs rPtTc6HRZCCgCyAx+TQyNwP/CGFcJCXABCA4hB+wNrNKofMCMCXAeS2WEDPyANA54P8EEVEFoyFU oKsSBCAfYDhC74nRilOrcbciZkCxmkEjMP8f4HChhsFNJ3TCbvEHkWjj3wMAOeCfwV19IzBtgbRC Ef9sMoYeSMEYICODM+G54ijB28ACWmFyPoBloVUvIX5hvzNCknFxNDWAgpPBYWs70f8vAQ6wXtK+ sSfwJdIpsiXA/0ORJdKo0ARwbDIlwMOGgqH/LdYlxCLwxkQiUAeQInLDkvoiZaFXqJKKRAEBHyKq Ef8tgW7gt8F1UnvgbuFGQiGh/y3XgxKkIQSQhiAEkAGgAxD/tmEfwzLirmG2QUwSQvRRAt8uwkDh bXGVQgBweS3WVib/WXEnIFNzH2CDIklRfCQFAG8zMEZCjNQrW1mtQjC7KP9ZESCRI5FZcDPhwhJn InZF/8JDFBAmwAUQpEGz9JFVIhDeSB+QaNJDkVXRUNixIzj/SmEfEE/hgEJwdcZxSMEnQf860oJC JMTXScJDM4IFECzh/8MhJ0EfMCNQuEM2s4RRzxHfPeN+ZVhAHTFEcydTkR8w/z6xJzQUASFwjFSf 4z90rRXn3RQmexggcXVE4XXlaOL/AiCLEaIyWZttWnuogoR6SO8kB5twuAFvASIHgAGQX+D1r3lJ BUBqj2LIpruzK1v+T0L0WdRJUXMRIBAgoXTi/6cyMrGrc27U7QJtaVp0M7H/BuA20ZamgqLAdTay e6JpJX4tjjEiUNqR9qVWcExwbv4teOV9QApAuwmuZE9SPWb/IWGOdMrC3cEOsCOiymOuov9WRIed MJJEJyMwzeV1Un/2vyGDfkKkIScg6CKHESgKsP9E4EOBfIqZqDQymkNDkTKBPyAqPUJKcTeEBXES kHYx/yIQhXjVY90USPMnuPGSaUT/VfkftMw60YMmEGVhKKMYIf8a0CFhBfIkkgXyIaBe0bPmP3by n+M4+s1hpnHlMVZQ9k6jIT1wbxRwHqLltmjj/y6Cz2InIBigztOW+S4xJtH+aT1xnKIfMB7BH2Ai wSFw/zMwbqFOsermfaHY4FADiib/hXiotwEWAaIqwBLhFEQY9O8EIx8QTHDPE2YjQTRBKMH/hXhx JfLQaaG2YVF1mbRvAf+bUVRwJ3BSIgvCdZHvVl1e/21x5gLKYiXA+/LN4CzwBT/9SmF4toBKoGWh MLbGcR6F/5rAtRFA6ZXiPYEoo5pCBlH/2inH0jLixfMScGUQowGb8v8eknDRSIJMkBJwqrC4QIDY veEEeZWBMdHhob5iKM2AD/kBTBI0UCu2TkFUKf9losYQTyDH4fjWVqXFIpco/9Kl/4sM4qIiQvFY pTRB7kPjSEDWYDAvMHVDmrKakv9r5DAKLtyStMpR09GZZFVY/5gt1btZ4o+x8jIqVw2y4nd/Fkcd 1m325yFYEsOhQ+BQ/wwgSpBlELUixCCA0ELRhCL/ZnLoENjgWWFTcxCyuEEW8n+ZhCZiK1zK5nTR q4hr4EgwLjMyM2vg8yBjLv+1ofIT2lBTZIHAS7Fvg3KBv9AAueHAQZwlbXjPZWafw/4nFwDABVrW 8cKUgY2AV8D/swMu5i+SHZUmYtoZ/kBuFP/xwnGg6JCcMBqxhpDhoo6k/3WghjOhxB5lHuM+gbNg rSH/TrHN0H+wGFRkVEBBQKS00f/4IZOw73qAoMJQw8GYW/nACnRqy31XMAAAAB4ANRABAAAARAAA ADw3Qjg4MjRENjkwMDkyQjRCOTBCMEVGNDY3NDc1MEE2NTAyMzFEQjdCQFVTRVhDSDMudXMuc29u aWN3YWxsLmNvbT4AHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAACg AAAAUgBFACUAMwBBACAAcgBlAG0AbwB2AGUAIABUAFMAIABmAHIAbwBtACAASQBLAEUAdgAyACAA KABSAEUAJQAzAEEAIABBAGQAZAByAGUAcwBzAGUAcwAgAGkAbgAgAHQAcgBhAGYAZgBpAGMAIABz AGUAbABlAGMAdABvAHIAcwAgAGkAbgAgAEkASwBFAHYAIAAyACkALgBFAE0ATAAAAAsA9hAAAAAA QAAHMJ5GyCZa0MEBQAAIMHT9fOZd0MEBAwDeP+QEAAADAPE/CQAAAB4A+D8BAAAADAAAAFNjb3R0 IEtlbGx5AAIB+T8BAAAAVAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1TT05JQ1dB TEwsIElOQy4vT1U9U09OSUNXQUxML0NOPVJFQ0lQSUVOVFMvQ049U0tFTExZAB4A+j8BAAAAFQAA AFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEAB AAAABwAAAFNLRUxMWQAAHgAxQAEAAAAHAAAAU0tFTExZAAAeADJAAQAAABUAAABtc2hpZWhAbmV0 c2NyZWVuLmNvbQAAAAAeADNAAQAAABUAAABtc2hpZWhAbmV0c2NyZWVuLmNvbQAAAAAeADhAAQAA AAcAAABTS0VMTFkAAB4AOUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEAFaX8UDAAcQ RQ4AAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISU1JQ0hBRUwsQ09NTUVOVFNJTkxJTkVC RUxPVyxCVVRJU0lHTklGSUNBTlRMWVRSSU1NRURUSEVURVhUSURPTlRUSElOS1dFQUNUVUFMTFlE SVNBR1JFRU9OQUxMVEhBVE1VAAAAAAIBfwABAAAARAAAADw3Qjg4MjRENjkwMDkyQjRCOTBCMEVG NDY3NDc1MEE2NTAyMzFEQjdCQFVTRVhDSDMudXMuc29uaWN3YWxsLmNvbT4A8EE= ------_=_NextPart_001_01C1D05D.E4CB0EA0-- From owner-ipsec@lists.tislabs.com Wed Mar 20 15:06:02 2002 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 g2KN61413760; Wed, 20 Mar 2002 15:06:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27248 Wed, 20 Mar 2002 17:28:24 -0500 (EST) Date: Wed, 20 Mar 2002 14:41:16 -0800 (PST) Message-Id: <200203202241.OAA04551@potomac.incog.com> From: Mike Ditto To: sommerfeld@east.sun.com CC: mshieh@netscreen.com, ipsec@lists.tislabs.com In-reply-to: <200203202028.g2KKSpgw013737@thunk.East.Sun.COM> (message from Bill Sommerfeld on Wed, 20 Mar 2002 15:28:51 -0500) Subject: Re: Don't remove TS from IKEv2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Besides, how do you decide if tunnel can be created > > two words: > > "transport mode" I'm sure Michael meant tunnel in the generic sense, not in the encapsulation sense. The point is that SOI should negotiate keys and SAs, but since each endpoint already has a policy that it must apply on every packet anyway, we don't need key management also to give policy refinements. Additionally, no existing or proposed traffic selector notation can describe all commonly used services. -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Mar 20 15:24:29 2002 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 g2KNOT414128; Wed, 20 Mar 2002 15:24:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27463 Wed, 20 Mar 2002 17:45:37 -0500 (EST) Message-Id: <200203202256.g2KMu2gw014831@thunk.East.Sun.COM> From: Bill Sommerfeld To: Mike Ditto cc: sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 14:41:16 PST." <200203202241.OAA04551@potomac.incog.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 20 Mar 2002 17:56:02 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The point is that SOI should negotiate keys and SAs, but since each > endpoint already has a policy that it must apply on every packet > anyway, we don't need key management also to give policy > refinements. As I've explained repeatedly, this is true only when there is centrally provisioned policy. > Additionally, no existing or proposed traffic > selector notation can describe all commonly used services. That's setting a rather high bar, isn't it? The use of SA's at transport-connection granularity in conjunction with looser-grained policy will work for a very large proportion of services, and works today in Sun's implementation. - Bill From owner-ipsec@lists.tislabs.com Wed Mar 20 15:40:07 2002 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 g2KNe6414476; Wed, 20 Mar 2002 15:40:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27576 Wed, 20 Mar 2002 18:00:56 -0500 (EST) To: Mike Ditto Cc: sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 References: <200203202241.OAA04551@potomac.incog.com> From: Derek Atkins Date: 20 Mar 2002 18:12:41 -0500 In-Reply-To: <200203202241.OAA04551@potomac.incog.com> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, The issue here is that you don't want to create an SA that will end in a black hole. If you create an "opportunistic" SA with someone you've never heard of before, you need to know what your peer will accept over the SA. If your peer will only accept, e.g. packets to tcp/80, then you know you shouldn't send anything else. This keeps you from creating a black hole. -derek Mike Ditto writes: > > > Besides, how do you decide if tunnel can be created > > > > two words: > > > > "transport mode" > > I'm sure Michael meant tunnel in the generic sense, not in the > encapsulation sense. The point is that SOI should negotiate keys and > SAs, but since each endpoint already has a policy that it must apply > on every packet anyway, we don't need key management also to give > policy refinements. Additionally, no existing or proposed traffic > selector notation can describe all commonly used services. > > -=] Mike [=- -- 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 Mar 20 16:06:20 2002 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 g2L06K414994; Wed, 20 Mar 2002 16:06:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27711 Wed, 20 Mar 2002 18:23:19 -0500 (EST) Date: Wed, 20 Mar 2002 15:36:17 -0800 (PST) Message-Id: <200203202336.PAA04579@potomac.incog.com> From: Mike Ditto To: warlord@mit.edu CC: sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com In-reply-to: (message from Derek Atkins on 20 Mar 2002 18:12:41 -0500) Subject: Re: Don't remove TS from IKEv2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > The issue here is that you don't want to create an SA that will > end in a black hole. If you create an "opportunistic" SA with > someone you've never heard of before, you need to know what your > peer will accept over the SA. If your peer will only accept, > e.g. packets to tcp/80, then you know you shouldn't send anything > else. This keeps you from creating a black hole. I see, but I don't see that this is useful. If it's my intention to negotiate a tunnel with you and then send through it packets that you won't accept, there is no reason to treat that differently than if I just sent the unacceptable packets to you outside of the tunnel. Drop the packets or send an ICMP error. In addition to believing that the feature is not useful, I also believe that it is not possible to do in general. Either alone is reason enough to drop it; I think both together clinch it. :-) -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Mar 20 16:52:22 2002 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 g2L0qL415936; Wed, 20 Mar 2002 16:52:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27972 Wed, 20 Mar 2002 19:08:30 -0500 (EST) Date: Wed, 20 Mar 2002 16:18:09 -0800 (PST) Message-Id: <200203210018.QAA04593@potomac.incog.com> From: Mike Ditto To: sommerfeld@east.sun.com CC: mshieh@netscreen.com, ipsec@lists.tislabs.com In-reply-to: <200203202256.g2KMu2gw014831@thunk.East.Sun.COM> (message from Bill Sommerfeld on Wed, 20 Mar 2002 17:56:02 -0500) Subject: Re: Don't remove TS from IKEv2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > The point is that SOI should negotiate keys and SAs, but since each > > endpoint already has a policy that it must apply on every packet > > anyway, we don't need key management also to give policy > > refinements. > > As I've explained repeatedly, this is true only when there is > centrally provisioned policy. I don't think I understand this. Why does it matter where the policy comes from? Each endpoint knows what traffic it is willing to accept and send on a given SA. Knowing in advance what your peer will or won't accept isn't necessary, because the peer will let you know if you violate its policy. Telling your peer in advance what you will or won't accept isn't helpful, because you still have to check to make sure that the peer doesn't violate your policy. Perhaps you're saying that centrally provisioned policy is another way of avoiding mismatched policies, and traffic selector negotiation is trying to solve the problem when there is no centrally provisioned policy. I claim that traffic selectors don't solve any real problem, no matter how policy is derived. > > Additionally, no existing or proposed traffic > > selector notation can describe all commonly used services. > > That's setting a rather high bar, isn't it? I don't think so. > The use of SA's at transport-connection granularity in conjunction > with looser-grained policy will work for a very large proportion of > services, and works today in Sun's implementation. The question is: Does the more complicated protocol make it work better than it would otherwise? -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Mar 20 17:23:10 2002 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 g2L1N9416369; Wed, 20 Mar 2002 17:23:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28169 Wed, 20 Mar 2002 19:38:31 -0500 (EST) Message-Id: <200203210045.g2L0jo000403@fatty.lounge.org> To: Michael Choung Shieh Cc: ipsec@lists.tislabs.com Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) In-Reply-To: Your message of "Tue, 19 Mar 2002 12:31:24 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DA5@NS-CA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <400.1016671550.1@tibernian.com> Date: Wed, 20 Mar 2002 16:45:50 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Mar 2002 12:31:24 PST you wrote > > RFC2401 says there are SPD selectors associated with each SA. However, it > should be local implemenation issue to bind them together. Puting SPD in > IKE is just dulplicating effort in key managment protocol without much > benefit. Yes but there is no SA to bind to the selector. The TS payloads give an indication on how to do such binding at SA creation time. Without passing this information all you can say is, "I want to do IPsec with you". The Initiator binds the selector to the SA which caused the whole negotiation in the first place and the Responder does what? Panic, reboot (I ask only half in jest)? Best guess? Choose one at random? Wait until some packets arrive and then choose? What if he doesn't like what he sees when he does? Tear down the SA or wait until he finds another thing he might like? How long should he wait? > Giving the difficulty to do TS right, I would propose to use a simple ID > (e.g. sequence number) to identity the tunnel and leave all complexity of > SPD out of IKE. And then we need some new protocol to do "simple ID (e.g. sequence number)" to "tunnel" matching-- not a good idea. Or we just assume that everyone has been preconfigured with this information-- not a good assumption. It's not that difficult. If you are the Responder you check your local SPD to see whether the TS payloads are wholly contained by what you have (i.e. they match or are a complete subset of the range, or if you're doing address/mask you can ask yourself if your SPD entry was a routing table entry whether you'd route that TS payload unambiguously through it). If it is not then you send back the subset that is wholly contained. If that subset is NULL you send back a rejection. Dan. From owner-ipsec@lists.tislabs.com Wed Mar 20 17:29:34 2002 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 g2L1TX416472; Wed, 20 Mar 2002 17:29:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28231 Wed, 20 Mar 2002 19:48:03 -0500 (EST) Message-Id: <200203210057.g2L0vQ000472@fatty.lounge.org> To: Mike Ditto Cc: warlord@mit.edu, sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 15:36:17 PST." <200203202336.PAA04579@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <469.1016672246.1@tibernian.com> Date: Wed, 20 Mar 2002 16:57:26 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002 15:36:17 PST you wrote > Derek Atkins wrote: > > The issue here is that you don't want to create an SA that will > > end in a black hole. If you create an "opportunistic" SA with > > someone you've never heard of before, you need to know what your > > peer will accept over the SA. If your peer will only accept, > > e.g. packets to tcp/80, then you know you shouldn't send anything > > else. This keeps you from creating a black hole. > > I see, but I don't see that this is useful. If it's my intention to > negotiate a tunnel with you and then send through it packets that you > won't accept, there is no reason to treat that differently than if I > just sent the unacceptable packets to you outside of the tunnel. Drop > the packets or send an ICMP error. If I knew that was your intention I wouldn't establish the SAs with you in the first place. Assuming you're not doing that, then how do you know what the problem is when packets do not flow? You want to send a wider variety of packets to me protected by this SA than I want to accept from you. With the TS payloads you we can know this and we can know the entire subset of what you want to send and what I'll accept. > In addition to believing that the feature is not useful, I also > believe that it is not possible to do in general. Either alone is > reason enough to drop it; I think both together clinch it. :-) If what you are saying was true I'd agree but I believe it is both useful and possible to do. Useful because I have been on the receiving end of a report from the field with the specificity of "the pings stopped" and it was just this capability that was used to figure out why. Possible to do because I've done it. Dan. From owner-ipsec@lists.tislabs.com Wed Mar 20 17:46:46 2002 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 g2L1kj416793; Wed, 20 Mar 2002 17:46:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28353 Wed, 20 Mar 2002 20:05:00 -0500 (EST) Date: Wed, 20 Mar 2002 17:17:58 -0800 (PST) Message-Id: <200203210117.RAA04642@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: warlord@mit.edu, sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com In-reply-to: <200203210057.g2L0vQ000472@fatty.lounge.org> (message from Dan Harkins on Wed, 20 Mar 2002 16:57:26 -0800) Subject: Re: Don't remove TS from IKEv2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If what you are saying was true I'd agree but I believe it is both useful > and possible to do. Useful because I have been on the receiving end of > a report from the field with the specificity of "the pings stopped" and > it was just this capability that was used to figure out why. Possible to > do because I've done it. I think it would be just as easy to diagnose that situation if you got an ICMP message with an appropriate reason code. Maybe even easier, because the user would get an error message from the ping program saying "traffic denied by security policy" instead of calling you for help. (And yes, I think there should be some new ICMP codes defined for this sort of thing, but even the existing codes could make the above situation clear.) This is is a problem that can be solved generally as an IPsec issue, it doesn't have to be solved by each key management protocol. And if the service was something less trivial than "ping" you probably wouldn't have been able to get as far as you did, because either the tunnel wouldn't have been established at all (because the initiator's selectors, wide enough to allow the potential range of traffic the service entails, would be rejected by the responder) or because the service would just silently fail (because the initiator's selectors, narrow enough to be accepted by the responder, didn't include all of the traffic that the service entails). -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Mar 20 18:03:44 2002 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 g2L23i417045; Wed, 20 Mar 2002 18:03:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28506 Wed, 20 Mar 2002 20:24:41 -0500 (EST) Message-Id: <200203210135.g2L1Z9gw015896@thunk.East.Sun.COM> From: Bill Sommerfeld To: Mike Ditto cc: warlord@mit.edu, sommerfeld@east.sun.com, mshieh@netscreen.com, ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 15:36:17 PST." <200203202336.PAA04579@potomac.incog.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 20 Mar 2002 20:35:09 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In addition to believing that the feature is not useful, I also > believe that it is not possible to do in general. Either alone is > reason enough to drop it; I think both together clinch it. :-) Funny, I think (a) it's useful for some communities, and (b) I implemented it in Solaris (using phase 2 "identities" in IKEv1, which are the rough equivalent of the TS fields), so clearly you must be using an unusual definition of "not possible". - Bill From owner-ipsec@lists.tislabs.com Wed Mar 20 18:47:53 2002 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 g2L2lq418085; Wed, 20 Mar 2002 18:47:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28830 Wed, 20 Mar 2002 21:09:39 -0500 (EST) Message-Id: <200203210219.g2L2JD000809@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 17:17:58 PST." <200203210117.RAA04642@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <806.1016677153.1@tibernian.com> Date: Wed, 20 Mar 2002 18:19:13 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002 17:17:58 PST you wrote > This is is a problem that can be solved generally as an IPsec issue, > it doesn't have to be solved by each key management protocol. It is being solved as an IPsec issue. And no one said each key management protocol has to solve it, just the one used by IPsec. Dan. From owner-ipsec@lists.tislabs.com Wed Mar 20 19:06:07 2002 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 g2L366418431; Wed, 20 Mar 2002 19:06:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29016 Wed, 20 Mar 2002 21:29:29 -0500 (EST) To: Dan Harkins Cc: Mike Ditto , ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 References: <200203210219.g2L2JD000809@fatty.lounge.org> From: Derek Atkins Date: 20 Mar 2002 21:41:18 -0500 In-Reply-To: <200203210219.g2L2JD000809@fatty.lounge.org> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > It is being solved as an IPsec issue. And no one said each key management > protocol has to solve it, just the one used by IPsec. I should note (with my KINK chair hat on) that there _are_ multiple key management protocols used by IPsec. However, KINK plans to re-use IKE phase-2, so we get to use your Traffic Selectors for free. :) > Dan. -derek -- 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 Mar 20 20:15:45 2002 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 g2L4Fi419763; Wed, 20 Mar 2002 20:15:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29489 Wed, 20 Mar 2002 22:30:53 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DB8@NS-CA> From: Michael Choung Shieh To: "'Dan Harkins'" , Mike Ditto Cc: warlord@mit.edu, sommerfeld@east.sun.com, Michael Choung Shieh , ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Wed, 20 Mar 2002 19:41:38 -0800 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 TS does detect mis-config for simple scanario. However, it falls short on more complex cases: 1. FTP, DNS, H323. (btw, can someone show me what the correct TS should be for FTP and H323? I still don't know how to do it correctly even for FTP) 2. dynamic routing. 3. NAT from several pools (or determined by routing) 4. change inbound local security policy without shuting down whole tunnel or wait for peer's approval. These are all customer request features. right now I can only put 0 in proxy_id (and future TS) and screw up my tunnel. If TS payload can only support simple scenario, and only provide the benefit of misconfig detection, then we should put it optional (so one can detect misconfig if they want). It was pointed out the responder can have wider TS to do opportunitic sa. The problem of it is it only works for client-server case and fails in peer-to-peer case. Even in client-server scenario, most likely the server (responder) has smaller range of TS (it probably only allows FTP). The client probably doesn't care the TS at all. I will be happy to hear a use case of it. Michael Shieh > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Wednesday, March 20, 2002 4:57 PM > To: Mike Ditto > Cc: warlord@mit.edu; sommerfeld@east.sun.com; mshieh@netscreen.com; > ipsec@lists.tislabs.com > Subject: Re: Don't remove TS from IKEv2 > > > On Wed, 20 Mar 2002 15:36:17 PST you wrote > > Derek Atkins wrote: > > > The issue here is that you don't want to create an SA that will > > > end in a black hole. If you create an "opportunistic" SA with > > > someone you've never heard of before, you need to know what your > > > peer will accept over the SA. If your peer will only accept, > > > e.g. packets to tcp/80, then you know you shouldn't send anything > > > else. This keeps you from creating a black hole. > > > > I see, but I don't see that this is useful. If it's my intention to > > negotiate a tunnel with you and then send through it > packets that you > > won't accept, there is no reason to treat that differently than if I > > just sent the unacceptable packets to you outside of the > tunnel. Drop > > the packets or send an ICMP error. > > If I knew that was your intention I wouldn't establish the > SAs with you > in the first place. Assuming you're not doing that, then how > do you know > what the problem is when packets do not flow? You want to send a wider > variety of packets to me protected by this SA than I want to > accept from > you. With the TS payloads you we can know this and we can know the > entire subset of what you want to send and what I'll accept. > > > In addition to believing that the feature is not useful, I also > > believe that it is not possible to do in general. Either alone is > > reason enough to drop it; I think both together clinch it. :-) > > If what you are saying was true I'd agree but I believe it is > both useful > and possible to do. Useful because I have been on the receiving end of > a report from the field with the specificity of "the pings > stopped" and > it was just this capability that was used to figure out why. > Possible to > do because I've done it. > > Dan. > > > From owner-ipsec@lists.tislabs.com Thu Mar 21 02:01:26 2002 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 g2LA1Q422186; Thu, 21 Mar 2002 02:01:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01425 Thu, 21 Mar 2002 04:06:33 -0500 (EST) From: cdemar@ebsdr.com Message-Id: Date: Thu, 21 Mar 2002 9:16:34 +0000 To: ipsec@lists.tislabs.com Subject: pre-shared key v RSA encryption or RSA signature authentication modes MIME-version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: TFS Secure Messaging /450000152/450849044/450240081/450350008/ X-Mailer: Version 4.7 Build 103 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear ipsec-list, I just have a quick question for which I could not find any answers yet. Can someone tell whether the security strength of pre-shared key IKE authentication mode has been proven weaker than RSA-enc or RSA-sig IKE authentication mode ? Links would be much appreciated ... Many thanks, Claudine -----Original Message----- From: mshieh@netscreen.com [mailto:mshieh@netscreen.com] Sent: Wednesday, March 20, 2002 7:20 AM To: wdixon@windows.microsoft.com; tytso@mit.edu; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Oop, I made a mistake on our product performance. It's 250Mb/s for single vpn session and 600Mb/s for aggregated vpn session, as stated in our marketing literature. Michael Shieh -----Original Message----- From: Michael Choung Shieh [mailto:mshieh@netscreen.com] Sent: Tuesday, March 19, 2002 5:52 PM To: 'William Dixon'; Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas William, I cannot open the link of the draft. For performance reason, I would prefer tunnel mode since it requires fewer operation, and we only support tunnel mode. Our current products can support upto 350Mb/s for single TCP session and 1Gb/b for aggregate sessions. I think many vendors can do more than 100Mb/s these days. Michael Shieh -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Tuesday, March 19, 2002 4:36 PM To: Theodore Ts'o; ipsec@lists.tislabs.com Cc: iscsi-security@external.cisco.com Subject: RE: Draft ipsec agendas Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of the recent IP Storage using IPsec discussion ? I'm happy to squeeze in where someone finishes early. I mainly want to poll the audience of implementers to see what IPsec GW implementation can accept and run an IPSec tunnel SA for a single or aggregate of TCP connections at 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: Possible Quick Mode proposal of an IP storage initiator to IPSec GW: Src IP = initiator real IP Dst IP = target real IP (the target is behind the gateway, not the GW IP itself) Protocol = TCP Src Port = * or Dst Port = wellknown (e.g. 3260 for iSCSI) The polling of vendors is important to determine if the target community can achieve their goal of bolting on a commercial IPsec security gateway in front of a (single or group of) IP storage target(s), perhaps find those that could be used for interop testing in 3 months. I am still thinking transport mode is more appropriate choice for securing IP Storage TCP connections, but nevertheless, we should determine if IPsec GWs vendors can deal with a tunnel like this, and what the tunnel mode alternative is if they can't. Interested folks can see latest draft, but I don't think this version made cutoff for submission and isn't current with yesterday's discussion yet. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Thx, Wm From owner-ipsec@lists.tislabs.com Thu Mar 21 02:09:53 2002 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 g2LA9r422945; Thu, 21 Mar 2002 02:09:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01551 Thu, 21 Mar 2002 04:31:09 -0500 (EST) Message-ID: <3C99AB48.230D4CD4@6wind.com> Date: Thu, 21 Mar 2002 10:43:36 +0100 From: Christophe Gouault Organization: 6WIND X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: IPsec Subject: divergent interpretations of IKE/IPsec - interop issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, During interoperability tests on several IKE/IPsec implementations, we discovered different interpretations of the IKEv1 or IPsec specification. Let's consider the following transform: (1) [IP][data] ==(IPsec)==> [IP][AH][ESP][encrypted IP+data] To negociate such transform as IKE-initiator, (2) some implementations send a QM proposal of AH_transport + ESP_tunnel (6WIND, KAME, OpenBSD...) (3) some other implementations send a QM proposal of AH_tunnel + ESP_tunnel (FreeS/WAN, Cisco...) If initiator and responder use different interpretations, the negociation fails most of the time. These two different interpretations consequently lead to non-interoperable implementations. IMHO only ESP is in tunnel mode in this transform, as opposed to AH which is in transport mode. But some implementors seem to consider that mode applies globally to the transform (AH+ESP). Are (2) and (3) valid representations of transform (1) ? /christophe From owner-ipsec@lists.tislabs.com Thu Mar 21 03:46:44 2002 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 g2LBkh401357; Thu, 21 Mar 2002 03:46:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02118 Thu, 21 Mar 2002 06:04:51 -0500 (EST) Message-Id: <200203211114.g2LBEI001816@fatty.lounge.org> To: Michael Choung Shieh Cc: ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Wed, 20 Mar 2002 19:41:38 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DB8@NS-CA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1813.1016709258.1@tibernian.com> Date: Thu, 21 Mar 2002 03:14:18 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002 19:41:38 PST you wrote > > TS does detect mis-config for simple scanario. However, it falls short on > more complex cases: > > 1. FTP, DNS, H323. (btw, can someone show me what the correct TS should be > for FTP and H323? I still don't know how to do it correctly even for FTP) > 2. dynamic routing. > 3. NAT from several pools (or determined by routing) > 4. change inbound local security policy without shuting down whole tunnel or > wait for peer's approval. Whatever was in the your SPD that matched the packet that caused the negotiation to happen in the first place. That should be what your TS payloads represent. > These are all customer request features. right now I can only put 0 in > proxy_id (and future TS) and screw up my tunnel. I'm assuming you are able to populate your SPD correctly (since this discussion is not to change the representation of selectors). If your SPD can somehow be properly configured to allow NAT from different pools or H.323 to be IPsec protected it should not be too difficult to do this either. Whatever got sent up with the "acquire" (a PF_KEY term but you should have a symantically equivalent function) is what you use. Dan. From owner-ipsec@lists.tislabs.com Thu Mar 21 05:48:17 2002 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 g2LDmG407411; Thu, 21 Mar 2002 05:48:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02814 Thu, 21 Mar 2002 08:00:34 -0500 (EST) Message-Id: <5.1.0.14.0.20020321124319.038df140@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 12:57:44 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-Reply-To: <3C99AB48.230D4CD4@6wind.com> 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 GAA02335 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:43 21.03.2002 +0100, you wrote: >Hello, > >During interoperability tests on several IKE/IPsec implementations, we >discovered different interpretations of the IKEv1 or IPsec >specification. > >Let's consider the following transform: > >(1) [IP][data] ==(IPsec)==> [IP][AH][ESP][encrypted IP+data] > >To negociate such transform as IKE-initiator, >(2) some implementations send a QM proposal of AH_transport + ESP_tunnel > (6WIND, KAME, OpenBSD...) >(3) some other implementations send a QM proposal of AH_tunnel + > ESP_tunnel (FreeS/WAN, Cisco...) > >If initiator and responder use different interpretations, the >negociation fails most of the time. >These two different interpretations consequently lead to >non-interoperable implementations. > >IMHO only ESP is in tunnel mode in this transform, as opposed to AH >which is in transport mode. But some implementors seem to consider that >mode applies globally to the transform (AH+ESP). > >Are (2) and (3) valid representations of transform (1) ? > >/christophe The past few interops I've been to have addressed this issue over and over again. The agreement was that (3) is correct. Some software may accept type (2) proposals are well, if they are responder. But sending type (2) QM proposals is not allowed. The basic idea is that the attributes should be consistent over protocols. You have the same lifetime for AH and ESP, you have the same PFS setting, and you should have the same tunnel/transport setting. A more interesting issue is IPCOMP. We send PFS info and lifetimes for IPCOMP as well, just to make it consistent. Not everybody does that... J–rn Sierwald From owner-ipsec@lists.tislabs.com Thu Mar 21 05:48:17 2002 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 g2LDmG407413; Thu, 21 Mar 2002 05:48:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02796 Thu, 21 Mar 2002 07:59:33 -0500 (EST) Message-ID: <000701c1d0d9$cf43eb20$4969fea9@amanda2> From: "Prof. Ahmed A. A. Adas" To: Cc: References: Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Date: Thu, 21 Mar 2002 16:10:35 +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 Disposition-Notification-To: "Prof. Ahmed A. A. Adas" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi As a researcher in cryptosystems and protocols, I would say that RSA-sig IKE is much more powerful unless someone is using quantum computing attacks, which are not feasible in the near future. Ahmed Adas, member IETF,ACM, IEEE alaadas@kaau.edu.sa ----- Original Message ----- From: To: Sent: 21 ????, 2002 12:16 ? Subject: pre-shared key v RSA encryption or RSA signature authentication modes > Dear ipsec-list, > > I just have a quick question for which I could not find any answers yet. > Can someone tell whether the security strength of pre-shared key IKE > authentication mode has been proven weaker than RSA-enc or RSA-sig IKE > authentication mode ? > Links would be much appreciated ... > > Many thanks, > > Claudine > > -----Original Message----- > From: mshieh@netscreen.com [mailto:mshieh@netscreen.com] > Sent: Wednesday, March 20, 2002 7:20 AM > To: wdixon@windows.microsoft.com; tytso@mit.edu; ipsec@lists.tislabs.com > Cc: iscsi-security@external.cisco.com > Subject: RE: Draft ipsec agendas > > > Oop, I made a mistake on our product performance. It's 250Mb/s for single > vpn session and 600Mb/s for aggregated vpn session, as stated in our > marketing literature. > > Michael Shieh > > -----Original Message----- > From: Michael Choung Shieh [mailto:mshieh@netscreen.com] > Sent: Tuesday, March 19, 2002 5:52 PM > To: 'William Dixon'; Theodore Ts'o; ipsec@lists.tislabs.com > Cc: iscsi-security@external.cisco.com > Subject: RE: Draft ipsec agendas > > > William, > > I cannot open the link of the draft. > > For performance reason, I would prefer tunnel mode since it requires fewer > operation, and we only support tunnel mode. > > Our current products can support upto 350Mb/s for single TCP session and > 1Gb/b for aggregate sessions. I think many vendors can do more than 100Mb/s > these days. > > Michael Shieh > > -----Original Message----- > From: William Dixon [mailto:wdixon@windows.microsoft.com] > Sent: Tuesday, March 19, 2002 4:36 PM > To: Theodore Ts'o; ipsec@lists.tislabs.com > Cc: iscsi-security@external.cisco.com > Subject: RE: Draft ipsec agendas > > > Ted, is there 2 or 3 minutes to update the IPsec WG on one outcome of > the recent IP Storage using IPsec discussion ? I'm happy to squeeze in > where someone finishes early. I mainly want to poll the audience of > implementers to see what IPsec GW implementation can accept and run an > IPSec tunnel SA for a single or aggregate of TCP connections at > 100Mbits/sec & 1Gbit/sec 3DES/SHA1 for the following selector: > > Possible Quick Mode proposal of an IP storage initiator to IPSec GW: > > Src IP = initiator real IP > Dst IP = target real IP (the target is behind the gateway, not the GW IP > itself) > Protocol = TCP > Src Port = * or > Dst Port = wellknown (e.g. 3260 for iSCSI) > > The polling of vendors is important to determine if the target community > can achieve their goal of bolting on a commercial IPsec security gateway > in front of a (single or group of) IP storage target(s), perhaps find > those that could be used for interop testing in 3 months. > > I am still thinking transport mode is more appropriate choice for > securing IP Storage TCP connections, but nevertheless, we should > determine if IPsec GWs vendors can deal with a tunnel like this, and > what the tunnel mode alternative is if they can't. > > Interested folks can see latest draft, but I don't think this version > made cutoff for submission and isn't current with yesterday's discussion > yet. > http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt > > Thx, > Wm > > From owner-ipsec@lists.tislabs.com Thu Mar 21 07:27:16 2002 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 g2LFRG414743; Thu, 21 Mar 2002 07:27:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03620 Thu, 21 Mar 2002 09:40:59 -0500 (EST) Message-ID: <20020321145249.5118.qmail@web12208.mail.yahoo.com> Date: Thu, 21 Mar 2002 06:52:49 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: Re: divergent interpretations of IKE/IPsec - interop issues To: Joern Sierwald , ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.0.20020321124319.038df140@dfintra.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern, --- Joern Sierwald wrote: > >(1) [IP][data] ==(IPsec)==> [IP][AH][ESP][encrypted IP+data] > > > >To negociate such transform as IKE-initiator, > >(2) some implementations send a QM proposal of AH_transport + ESP_tunnel > > (6WIND, KAME, OpenBSD...) > >(3) some other implementations send a QM proposal of AH_tunnel + > > ESP_tunnel (FreeS/WAN, Cisco...) > > The past few interops I've been to have addressed this issue over and over > again. > The agreement was that (3) is correct. > > Some software may accept type (2) proposals are well, if they are responder. > But sending type (2) QM proposals is not allowed. This is one of the things that should go into any documents clarifying how to implement IKEv1, and there are a lot of other issues like this, such as: - the order of ESP & AH in the proposal (and are you allowed to reverse it in a response), - don't use multiple SA payloads in QM, - don't use commit in phase 1, - don't send redundant id payloads in phase 2 (some implementations choke), - don't send ranges or masks that cover only a single address (some implementations will not recognize them as such) - the nonce size issue - you can choose cookies randomly, no benefit from using a stateless computation as indicated by the specs - how to write retransmission code, what are the relevant parameters (timeouts, number of attempts, etc) - what sort of cert req / cert payloads to send - etc. What new implementors would need, imho, is a document that specifies (1) what parts of IKE you need to implement, (2) what you definitely should not implement because it will be a waste of your time, and (3) the broken features that have been deployed (such as sending AH tunnel when you mean AH transport ;-) Best regards, -Sami __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Mar 21 07:27:22 2002 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 g2LFRL414754; Thu, 21 Mar 2002 07:27:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03651 Thu, 21 Mar 2002 09:44:43 -0500 (EST) Message-Id: <200203211456.g2LEuQm00762@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Reply-To: mcr@freeswan.org Subject: advice on cooking IPsec happy certificates sought Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Mar 2002 08:56:26 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For the IETF53 IPsec over wireless effort (http://www.sandelman.ottawa.on.ca/SSW/ietf/secwlan) I made a pkix format certificate version of the FreeSWAN public key for people can not take public keys from DNS. Some people complained that I didn't have the right subjectAltName IP extension in the certificate. The certificate was produced with a slightly hacked OpenSSL. If there people out there that know what incantations are necessary to make OpenSSL more IPsec happy, can you contact me privately? Thank you. ] 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 Thu Mar 21 07:32:17 2002 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 g2LFWH414908; Thu, 21 Mar 2002 07:32:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03784 Thu, 21 Mar 2002 09:58:13 -0500 (EST) Message-Id: <200203211509.g2LF9t700900@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-reply-to: Your message of "Wed, 20 Mar 2002 19:41:38 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DB8@NS-CA> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Mar 2002 09:09:55 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael Choung Shieh writes: Michael> TS does detect mis-config for simple scanario. However, it falls short on Michael> more complex cases: Michael> 1. FTP, DNS, H323. (btw, can someone show me what the correct TS should be Michael> for FTP and H323? I still don't know how to do it correctly even for FTP) Yes, IKEv1 does not. We are talking about requirements for the future. Clearly this is something we need to fix. Michael> 2. dynamic routing. You mean you want to use TS 0.0.0.0/0 -> 0.0.0.0/0 ? Michael> 3. NAT from several pools (or determined by routing) ??? what has that got to do with anything. They are either IP addresses or not. Michael> 4. change inbound local security policy without shuting down whole tunnel or Michael> wait for peer's approval. Requirement for IKEv2. Michael> These are all customer request features. right now I can only put 0 in Michael> proxy_id (and future TS) and screw up my tunnel. None of these correspond to a requirement to get rid of TS. Michael> It was pointed out the responder can have wider TS to do opportunitic sa. Michael> The problem of it is it only works for client-server case and fails in Michael> peer-to-peer case. Even in client-server scenario, most likely the server Have you really tried it? BTW: Please turn off your silly vacation message, it is broken. ] 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 iQCVAwUBPJn3wYqHRg3pndX9AQHy7wP9HkeFcDVBtdhwNFGEXQ/DfPIUnpZCryha 43HJcL2gIZaKlRI/sZVqxVNcmqKb97dVtj/LR9JOx8RJZeueB7Qvr+LRa2cAap+5 KT+DRmjpa3FhD8wPbiSaJh9IKtSEjzQq/whygwOb18/Wxz2Nqz4RuyJI2Ap1Jff7 Vvp/mPGevuU= =cSji -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 21 08:51:12 2002 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 g2LGpB419228; Thu, 21 Mar 2002 08:51:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04195 Thu, 21 Mar 2002 10:58:28 -0500 (EST) Cc: cdemar@ebsdr.com, ipsec@lists.tislabs.com Message-ID: <3C9A0555.F8F7354A@lucent.com> Date: Thu, 21 Mar 2002 11:07:49 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Prof. Ahmed A. A. Adas" Original-CC: cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Prof. Ahmed A. A. Adas" wrote: > As a researcher in cryptosystems and protocols, I would say that RSA-sig IKE > is much more powerful unless someone is using quantum computing attacks, > which are not feasible in the near future. It is comparing apples with oranges. The conclusion appears incorrect, and way too generalizing [without due justification]. Please explain - based on what is, say 2048-bit RSA-sig stronger than, say 256-bit key-based AES-XCBC-MAC signature? What is your criteria? What attacks are you considering? What is your model? -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 08:57:29 2002 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 g2LGvT419501; Thu, 21 Mar 2002 08:57:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04336 Thu, 21 Mar 2002 11:18:02 -0500 (EST) Message-Id: <200203211629.g2LGTgV01865@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-reply-to: Your message of "Thu, 21 Mar 2002 06:52:49 PST." <20020321145249.5118.qmail@web12208.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Mar 2002 10:28:27 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sami" == Sami Vaarala writes: Sami> What new implementors would need, imho, is a document that Sami> specifies a BCP. Sami> (1) what parts of IKE you need to implement, Sami> (2) what you definitely should not implement because it will Sami> be a waste of your time, and Sami> (3) the broken features that have been deployed (such as Sami> sending AH tunnel when you mean AH transport ;-) Sami> Best regards, Please read draft-spencer-ipsec-ike-implementation-02.txt It has proposed to make this a WG BCP, but there is some discussion as to whether this is a good idea at this time. ] 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 Thu Mar 21 08:59:29 2002 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 g2LGxT419614; Thu, 21 Mar 2002 08:59:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04382 Thu, 21 Mar 2002 11:24:45 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B01F297F0@NS-CA> From: Gregory Lebovitz To: ipsec@lists.tislabs.com Subject: Bake-Off Anyone? Date: Thu, 21 Mar 2002 08:35:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0F6.703DB8F0" 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_01C1D0F6.703DB8F0 Content-Type: text/plain; charset="iso-8859-1" Per today's comments... Anyone for a next Bake-Off? Cheryl, you mentioned Anita would handle it again?? ------_=_NextPart_001_01C1D0F6.703DB8F0 Content-Type: text/html; charset="iso-8859-1"
Per today's comments...
Anyone for a next Bake-Off? Cheryl, you mentioned Anita would handle it again??
------_=_NextPart_001_01C1D0F6.703DB8F0-- From owner-ipsec@lists.tislabs.com Thu Mar 21 09:01:24 2002 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 g2LH1N419804; Thu, 21 Mar 2002 09:01:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04365 Thu, 21 Mar 2002 11:24:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DB5@NS-CA> References: <9D048F4A422CD411A56500B0D0209C5B028F3DB5@NS-CA> Date: Thu, 21 Mar 2002 10:14:55 -0500 To: Michael Choung Shieh From: Stephen Kent Subject: RE: Don't remove TS from IKEv2 Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:18 PM -0800 3/20/02, Michael Choung Shieh wrote: >An id or name (I mean phase 2 sa id, not phase 1) can represent the "scope", >either it's a single address, or the combination of 10 adresses and 5 >subnets and 6 ranges and 3 sevices. Not sure what you mean by this comment. The names defined in 2401 as selectors were intended only for symbolic replacements for individual IP addresses, where the specific addresses are instantiated when the SA is established. Thus, for example, an IKE responder could have an SPD entry with the name of an individual, to support a mobile user. When the user connects from the Internet, he presents a certificate with a name that matches the SPD entry. Assuming the certificate is appropriately validated, the responder should create a transient SPD entry (or, in the new model, an SPD cache entry) that takes the original SPD entry and substitutes the IP address for the name. There was never an intent that the name forms be used in any selector other than the IP addresses. I admit that 2401 did not do a good job of explaining this, but we plan to clarify in the rev of 2401. Steve From owner-ipsec@lists.tislabs.com Thu Mar 21 09:06:38 2002 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 g2LH6c419993; Thu, 21 Mar 2002 09:06:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04428 Thu, 21 Mar 2002 11:28:08 -0500 (EST) To: Uri Blumenthal Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> From: Derek Atkins Date: 21 Mar 2002 11:39:55 -0500 In-Reply-To: <3C9A0555.F8F7354A@lucent.com> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The fact that most users wont have a shared secret with 256 bits of entropy? I suspect that most shared secrets are probably in the 64-80 bits of entropy at the highest, and probably much lower than that. Based on the lack of entropy in shared secrets, I believe RSA sigs to be much stronger due to the better entropy in the key. -derek Uri Blumenthal writes: > "Prof. Ahmed A. A. Adas" wrote: > > As a researcher in cryptosystems and protocols, I would say that RSA-sig IKE > > is much more powerful unless someone is using quantum computing attacks, > > which are not feasible in the near future. > > It is comparing apples with oranges. The conclusion appears > incorrect, > and way too generalizing [without due justification]. > > Please explain - based on what is, say 2048-bit RSA-sig stronger than, > say 256-bit key-based AES-XCBC-MAC signature? What is your criteria? > What attacks are you considering? What is your model? > -- > Regards, > Uri > -=-=-=<>=-=- > -- 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 Mar 21 09:22:43 2002 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 g2LHMg420783; Thu, 21 Mar 2002 09:22:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04589 Thu, 21 Mar 2002 11:47:11 -0500 (EST) Message-ID: <20020321165901.1507.qmail@web12206.mail.yahoo.com> Date: Thu, 21 Mar 2002 08:59:01 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: Re: divergent interpretations of IKE/IPsec - interop issues To: Michael Richardson , ipsec@lists.tislabs.com In-Reply-To: <200203211629.g2LGTgV01865@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, > Please read draft-spencer-ipsec-ike-implementation-02.txt > It has proposed to make this a WG BCP, but there is some discussion as to > whether this is a good idea at this time. I've read the draft, and I liked the content. However, I don't think it addresses all the issues that an implementor faces, especially the details of processing individual messages. One way forward would be to extend this document with more details, and make it less FreeS/WAN specific. -Sami __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Mar 21 09:46:40 2002 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 g2LHke424103; Thu, 21 Mar 2002 09:46:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04697 Thu, 21 Mar 2002 11:56:46 -0500 (EST) Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Message-ID: <3C9A12DF.142CD892@lucent.com> Date: Thu, 21 Mar 2002 12:05:35 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Derek Atkins Original-CC: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > The fact that most users wont have a shared secret > with 256 bits of entropy? A good point. However: > I suspect that most shared secrets are probably in the 64-80 > bits of entropy at the highest, and probably much lower than > that. A good point, certainly. But I don't see all that much in common between, say, Unix passwords and IPsec pre-shared keys. IPsec implementations I'm aware of, don't take an ASCII password, but require a reasonably long key. Plus, a few years ago I saw a strength comparison table, that listed relative strength of PK and symmetric key length. Can you help me finding that one? It compares symmetric, RSA, EC, and [if memory serves me] DSA-El-Gamal. For example, my shared secrets are 128-bit long. Granted, not 256 bits, but still stronger than a typical RSA sig of 1024 bits (assording to that table as I remember)... > Based on the lack of entropy in shared secrets, I believe RSA sigs > to be much stronger due to the better entropy in the key. Again, this sounds misleading. It's not "shared secrets" that lack entropy. It's a certain type of shared secrets - derived from [more or less short] passwords, that lacks entropy. Not enough justification to "condemn" the whole symmetric key approach, especially since the original question was about IPsec authentication (as I read it). -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 09:46:48 2002 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 g2LHkl424119; Thu, 21 Mar 2002 09:46:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04657 Thu, 21 Mar 2002 11:53:52 -0500 (EST) Message-ID: <20020321170542.17735.qmail@web12203.mail.yahoo.com> Date: Thu, 21 Mar 2002 09:05:42 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: Re: divergent interpretations of IKE/IPsec - interop issues To: Michael Richardson , ipsec@lists.tislabs.com In-Reply-To: <200203211629.g2LGTgV01865@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, > Sami> What new implementors would need, imho, is a document that > Sami> specifies > > a BCP. BCP is one alternative. But instead of having the implementor first read three specs that don't really make sense, and then read a BCP that says "ignore the specs, do this instead", it might be worthwhile to consider "re-specifying" IKEv1. Such re-specification could combine the three documents, and also contain the clarifications that all implementors need to know anyway. -Sami __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Mar 21 09:52:41 2002 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 g2LHqe424387; Thu, 21 Mar 2002 09:52:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04883 Thu, 21 Mar 2002 12:15:33 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3C9A174A.6E692AAA@lucent.com> Date: Thu, 21 Mar 2002 12:24:26 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: cdemar@ebsdr.com Original-CC: ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk cdemar@ebsdr.com wrote: > The fact is that IKE-phase1 exchanges compile different material whether we > are doing pre-shared-key or RSA-enc.............. > > The question is: Is the authentication in IKE MainMode stronger when > using RSA-enc than when using preshared-key ??? No it is not. -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 09:55:26 2002 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 g2LHtP424500; Thu, 21 Mar 2002 09:55:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04808 Thu, 21 Mar 2002 12:07:41 -0500 (EST) From: cdemar@ebsdr.com Message-Id: Date: Thu, 21 Mar 2002 17:19:08 +0000 To: uri@lucent.com Cc: ipsec@lists.tislabs.com Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes MIME-version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: TFS Secure Messaging /450000152/450849044/450240081/450350008/ X-Mailer: Version 4.7 Build 103 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, Thanks for the answers ... Uri is actually right that I'm searching for a comparison between RSa-enc and pre-shared key in the scope of IKE authentication. I'm not trying to compare asymm v symm algorithms. The fact is that IKE-phase1 exchanges compile different material whether we are doing pre-shared-key or RSA-enc. The first exchanges of IKE main mode are also different whether we use preshared-key or RSA-enc. This generated material (SKEY_ID), SKEYID_d, SKEYID_e,SKEYID_a are different and used differently whether we use RSA-enc or preshared-key. The question is: Is the authentication in IKE MainMode stronger when using RSA-enc than when using preshared-key ??? And I don't this has anything to do with the strength of RSA-enc v symmetric algo ... Any pointers are welcome, Many thanks, Claudine -----Original Message----- From: uri@lucent.com [mailto:uri@lucent.com] Sent: Thursday, March 21, 2002 5:09 PM To: warlord@mit.edu Cc: alaadas@kaau.edu.sa; Demar, Claudine; ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Derek Atkins wrote: > The fact that most users wont have a shared secret > with 256 bits of entropy? A good point. However: > I suspect that most shared secrets are probably in the 64-80 > bits of entropy at the highest, and probably much lower than > that. A good point, certainly. But I don't see all that much in common between, say, Unix passwords and IPsec pre-shared keys. IPsec implementations I'm aware of, don't take an ASCII password, but require a reasonably long key. Plus, a few years ago I saw a strength comparison table, that listed relative strength of PK and symmetric key length. Can you help me finding that one? It compares symmetric, RSA, EC, and [if memory serves me] DSA-El-Gamal. For example, my shared secrets are 128-bit long. Granted, not 256 bits, but still stronger than a typical RSA sig of 1024 bits (assording to that table as I remember)... > Based on the lack of entropy in shared secrets, I believe RSA sigs > to be much stronger due to the better entropy in the key. Again, this sounds misleading. It's not "shared secrets" that lack entropy. It's a certain type of shared secrets - derived from [more or less short] passwords, that lacks entropy. Not enough justification to "condemn" the whole symmetric key approach, especially since the original question was about IPsec authentication (as I read it). -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 09:57:37 2002 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 g2LHva424554; Thu, 21 Mar 2002 09:57:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04837 Thu, 21 Mar 2002 12:12:09 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DBB@NS-CA> From: Michael Choung Shieh To: "'Derek Atkins'" , Uri Blumenthal Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: RE: pre-shared key v RSA encryption or RSA signature authenticati on modes Date: Thu, 21 Mar 2002 09:22:31 -0800 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 I don't think the protocol itself has the limitation on the length of preshare key. so the answer shouldn't be RSA-sig is stronger, but preshare key could allow users to use weaker entropy. Michael > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Thursday, March 21, 2002 8:40 AM > To: Uri Blumenthal > Cc: Prof. Ahmed A. A. Adas; cdemar@ebsdr.com; ipsec@lists.tislabs.com > Subject: Re: pre-shared key v RSA encryption or RSA signature > authentication modes > > > The fact that most users wont have a shared secret with 256 bits of > entropy? I suspect that most shared secrets are probably in the 64-80 > bits of entropy at the highest, and probably much lower than that. > > Based on the lack of entropy in shared secrets, I believe RSA sigs > to be much stronger due to the better entropy in the key. > > -derek > > Uri Blumenthal writes: > > > "Prof. Ahmed A. A. Adas" wrote: > > > As a researcher in cryptosystems and protocols, I would > say that RSA-sig IKE > > > is much more powerful unless someone is using quantum > computing attacks, > > > which are not feasible in the near future. > > > > It is comparing apples with oranges. The conclusion appears > > incorrect, > > and way too generalizing [without due justification]. > > > > Please explain - based on what is, say 2048-bit RSA-sig > stronger than, > > say 256-bit key-based AES-XCBC-MAC signature? What is your criteria? > > What attacks are you considering? What is your model? > > -- > > Regards, > > Uri > > -=-=-=<>=-=- > > > > -- > 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 Mar 21 09:57:41 2002 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 g2LHvf424568; Thu, 21 Mar 2002 09:57:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04807 Thu, 21 Mar 2002 12:07:41 -0500 (EST) To: David Jablon Cc: Uri Blumenthal , "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <3C9A0555.F8F7354A@lucent.com> <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> <5.1.0.14.0.20020321120852.00aee680@pop.theworld.com> From: Derek Atkins Date: 21 Mar 2002 12:19:27 -0500 In-Reply-To: <5.1.0.14.0.20020321120852.00aee680@pop.theworld.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, the low entropy of shared secrets is due to the fact that most of them are derived from short or weak passwords. If you have a 128-256 bit random key for a shared secret, you have the problem of transmitting that secret confidentially between the hosts. If you use RSA, then all you need is integrity across the distribution channel. -derek David Jablon writes: > Derek, > > Is the limited entropy of the shared secret due to the fact that > it is simply a hash of a password? If so, then perhaps the current > simplistic shared-secret key protocol is not such a good fit for these > common shared-secret password applications. > > -- David > > At 11:39 AM 3/21/2002 -0500, Derek Atkins wrote: > >The fact that most users wont have a shared secret with 256 bits of > >entropy? I suspect that most shared secrets are probably in the 64-80 > >bits of entropy at the highest, and probably much lower than that. > > -- 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 Mar 21 09:58:46 2002 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 g2LHwe424591; Thu, 21 Mar 2002 09:58:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04852 Thu, 21 Mar 2002 12:12:58 -0500 (EST) Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Message-ID: <3C9A16A9.74DBE896@lucent.com> Date: Thu, 21 Mar 2002 12:21:45 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Derek Atkins Original-CC: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> <3C9A12DF.142CD892@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > Uri Blumenthal writes: > > Plus, a few years ago I saw a strength comparison table, > > that listed relative strength of PK and symmetric key length. > > Can you help me finding that one? It compares symmetric, > > RSA, EC, and [if memory serves me] DSA-El-Gamal. > > There is Hilary's document.. Is that what you mean? No, it was an analysis done by (I believe) Johnson, Menezes and some other folks. Probably at Certicom... What Hilary's doc are you refering to? -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 09:59:26 2002 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 g2LHxI424613; Thu, 21 Mar 2002 09:59:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04763 Thu, 21 Mar 2002 12:04:07 -0500 (EST) To: Uri Blumenthal Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> <3C9A12DF.142CD892@lucent.com> From: Derek Atkins Date: 21 Mar 2002 12:15:56 -0500 In-Reply-To: <3C9A12DF.142CD892@lucent.com> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > Plus, a few years ago I saw a strength comparison table, > that listed relative strength of PK and symmetric key length. > Can you help me finding that one? It compares symmetric, > RSA, EC, and [if memory serves me] DSA-El-Gamal. There is Hilary's document.. Is that what you mean? -derek -- 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 Mar 21 09:59:38 2002 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 g2LHxU424629; Thu, 21 Mar 2002 09:59:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04894 Thu, 21 Mar 2002 12:15:54 -0500 (EST) From: "Rajesh Mohan" To: Subject: RE: Don't remove TS from IKEv2 Date: Thu, 21 Mar 2002 09:24:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <200203211509.g2LF9t700900@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk By making TS payloads mandatory, we are missing a powerful feature. I guess, the current discussion is to make TS optional. Just like 0.0.0.0/0 means tunnel all traffic, we want to something where we could say tunnel based on some default policy. This can be done by not sending any TS payload. The side that does not send TS payload says that he will tunneling packets based on his local default policy. The side that accepts a SA without TS payload tunnels packets based on his local policy which was made after coming to a understanding with the other end. This would make implementing policies such as "authenticate only H.323" and "encrypt FTP". I don't think we can do this with the selectors we have now. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Thursday, March 21, 2002 7:10 AM > To: ipsec@lists.tislabs.com > Subject: Re: Don't remove TS from IKEv2 > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Michael" == Michael Choung Shieh writes: > Michael> TS does detect mis-config for simple scanario. > However, it falls short on > Michael> more complex cases: > > Michael> 1. FTP, DNS, H323. (btw, can someone show me what > the correct TS should be > Michael> for FTP and H323? I still don't know how to do it > correctly even for FTP) > > Yes, IKEv1 does not. > We are talking about requirements for the future. Clearly this > is something > we need to fix. > > Michael> 2. dynamic routing. > > You mean you want to use TS 0.0.0.0/0 -> 0.0.0.0/0 ? > > Michael> 3. NAT from several pools (or determined by routing) > > ??? what has that got to do with anything. They are either IP > addresses or not. > > Michael> 4. change inbound local security policy without > shuting down whole tunnel or > Michael> wait for peer's approval. > > Requirement for IKEv2. > > Michael> These are all customer request features. right now > I can only put 0 in > Michael> proxy_id (and future TS) and screw up my tunnel. > > None of these correspond to a requirement to get rid of TS. > > Michael> It was pointed out the responder can have wider TS > to do opportunitic sa. > Michael> The problem of it is it only works for client-server > case and fails in > Michael> peer-to-peer case. Even in client-server scenario, > most likely the server > > Have you really tried it? > > BTW: Please turn off your silly vacation message, it is broken. > > ] 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 > > iQCVAwUBPJn3wYqHRg3pndX9AQHy7wP9HkeFcDVBtdhwNFGEXQ/DfPIUnpZCryha > 43HJcL2gIZaKlRI/sZVqxVNcmqKb97dVtj/LR9JOx8RJZeueB7Qvr+LRa2cAap+5 > KT+DRmjpa3FhD8wPbiSaJh9IKtSEjzQq/whygwOb18/Wxz2Nqz4RuyJI2Ap1Jff7 > Vvp/mPGevuU= > =cSji > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 21 10:04:02 2002 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 g2LI41424854; Thu, 21 Mar 2002 10:04:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04969 Thu, 21 Mar 2002 12:22:57 -0500 (EST) Cc: "'Derek Atkins'" , "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Message-ID: <3C9A1904.2B81564A@lucent.com> Date: Thu, 21 Mar 2002 12:31:48 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Michael Choung Shieh Original-CC: "'Derek Atkins'" , "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes References: <9D048F4A422CD411A56500B0D0209C5B028F3DBB@NS-CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Choung Shieh wrote: > I don't think the protocol itself has the limitation on the length of > preshare key. so the answer shouldn't be RSA-sig is stronger, but preshare > key could allow users to use weaker entropy. And even then - entropy for what? It has no bearing on the resulting SA parameters... Attacking it won't be an option for a long time... [Of course the assumption is - people won't put their passwords as IKE pre-shared keys. I ahven't seen such fools yet, but anything is possible - even keeping your RSA private key on a public host in an available place.] But my original point stands: a "normal" 128-bit symmetric key is "stronger" than a "normal" 1024-bit RSA key. In practice, such a key usually is generated ONCE [in a long time] on a per-host-pair basis, from something like /dev/random on Linux, typed in once, and is there for quite a long time. RSA (and other PK) makes it EASIER to administer the keys. Much easier. But not stronger. -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Mar 21 10:13:24 2002 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 g2LIDN425233; Thu, 21 Mar 2002 10:13:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05063 Thu, 21 Mar 2002 12:36:46 -0500 (EST) From: "Rajesh Mohan" To: "Derek Atkins" , "Uri Blumenthal" Cc: "Prof. Ahmed A. A. Adas" , , Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Date: Thu, 21 Mar 2002 09:45:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk bits of entropy at the highest, and probably much lower than that. > > Based on the lack of entropy in shared secrets, I believe RSA sigs > to be much stronger due to the better entropy in the key. > Centrally managed boxes typically get their shared secret from a management station which is generated using RNG. So, entropy of those keys are as good as RSA sigs. And typically, centrally managed boxes send these keys through some encrypted channel (eg SSL) to these boxes which may make it look bad. > -derek > > Uri Blumenthal writes: > > > "Prof. Ahmed A. A. Adas" wrote: > > > As a researcher in cryptosystems and protocols, I would say > that RSA-sig IKE > > > is much more powerful unless someone is using quantum > computing attacks, > > > which are not feasible in the near future. > > > > It is comparing apples with oranges. The conclusion appears > > incorrect, > > and way too generalizing [without due justification]. > > > > Please explain - based on what is, say 2048-bit RSA-sig stronger than, > > say 256-bit key-based AES-XCBC-MAC signature? What is your criteria? > > What attacks are you considering? What is your model? > > -- > > Regards, > > Uri > > -=-=-=<>=-=- > > > > -- > 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 Mar 21 10:18:16 2002 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 g2LIIF425350; Thu, 21 Mar 2002 10:18:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05132 Thu, 21 Mar 2002 12:44:10 -0500 (EST) Message-Id: <5.1.0.14.2.20020321125430.044242e0@mail.nwc.com> X-Sender: mfratto@mail.nwc.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 12:55:20 -0500 To: ipsec@lists.tislabs.com From: Mike Fratto Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes In-Reply-To: <3C9A12DF.142CD892@lucent.com> References: <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:05 PM 3/21/2002 -0500, Uri Blumenthal wrote: >A good point, certainly. But I don't see all that much in >common between, say, Unix passwords and IPsec pre-shared >keys. > >IPsec implementations I'm aware of, don't take an ASCII >password, but require a reasonably long key. Nearly all commercial IPsec implementations allow users to enter in ASCII passwords as preshared keys and none of them enforce or even have mechanisms to enforce complicated preshared keys. A few implementations (Avaya, was VPNet, comes to mind) will generate long complicated preshared keys for the user. But even then a user can manually enter a simple preshared key and shoot themselves in the foot. mike _______________________________ Mike Fratto Senior Technology Editor Network Computing 001 Machinery Hall Syracuse, NY 13244 _______________________________ From owner-ipsec@lists.tislabs.com Thu Mar 21 11:03:25 2002 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 g2LJ3J427001; Thu, 21 Mar 2002 11:03:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05460 Thu, 21 Mar 2002 13:20:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15514.10009.716428.128355@pkoning.dev.equallogic.com> Date: Thu, 21 Mar 2002 13:31:53 -0500 From: Paul Koning To: joern@f-secure.com Cc: ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues References: <3C99AB48.230D4CD4@6wind.com> <5.1.0.14.0.20020321124319.038df140@dfintra.f-secure.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joern" == Joern Sierwald writes: Joern> At 10:43 21.03.2002 +0100, you wrote: >> Hello, >> >> During interoperability tests on several IKE/IPsec >> implementations, we discovered different interpretations of the >> IKEv1 or IPsec specification. >> >> Let's consider the following transform: >> >> (1) [IP][data] ==(IPsec)==> [IP][AH][ESP][encrypted IP+data] >> >> To negociate such transform as IKE-initiator, (2) some >> implementations send a QM proposal of AH_transport + ESP_tunnel >> (6WIND, KAME, OpenBSD...) (3) some other implementations send a >> QM proposal of AH_tunnel + ESP_tunnel (FreeS/WAN, Cisco...) >> >> If initiator and responder use different interpretations, the >> negociation fails most of the time. These two different >> interpretations consequently lead to non-interoperable >> implementations. >> >> IMHO only ESP is in tunnel mode in this transform, as opposed to >> AH which is in transport mode. But some implementors seem to >> consider that mode applies globally to the transform (AH+ESP). >> >> Are (2) and (3) valid representations of transform (1) ? >> >> /christophe Joern> The past few interops I've been to have addressed this issue Joern> over and over again. The agreement was that (3) is correct. Joern> Some software may accept type (2) proposals are well, if they Joern> are responder. But sending type (2) QM proposals is not Joern> allowed. Joern> The basic idea is that the attributes should be consistent Joern> over protocols. You have the same lifetime for AH and ESP, Joern> you have the same PFS setting, and you should have the same Joern> tunnel/transport setting. Interesting. I thought it was the other way around (i.e., (2) is correct) but I'm rusty. So the consequence is that there is no way to request the following encapsulation: [IP][AH][IP][ESP][encrypted IP+data] in a single negotiation. Yet another fine reason to let ESP do the whole job by itself... :-) paul From owner-ipsec@lists.tislabs.com Thu Mar 21 11:33:09 2002 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 g2LJX8428256; Thu, 21 Mar 2002 11:33:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05698 Thu, 21 Mar 2002 13:55:25 -0500 (EST) From: "sankar ramamoorthi" To: "Scott Kelly" , "Michael Choung Shieh" , "Michael Choung Shieh" , "'Henry Spencer'" , "IP Security List" Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) Date: Thu, 21 Mar 2002 11:08:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0086_01C1D0C8.AFC7D470" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <7B8824D690092B4B90B0EF4674750A650231DB7B@USEXCH3.us.sonicwall.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C1D0C8.AFC7D470 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit > > TS is definitely big improvement over proxy-id. I agree it > solves lots of > > problems in IKEv1. However, it's not good enough to solve > those scenarios > > with dynamic nature (routing or dynamic NAT). Today's solution > is to try > > the best to aggregate all known traffic or just put 0/0 to > allow all, but > > the solution is totally defeat the purpose of TS. > > I agree that there are scenarios for which the current proposals > don't quite work. Previous posts (including yours) have mentioned > the problem with dynamic protocols such as FTP, H.323, etc., > where we have no way to statefully select TS values on the fly. One way this could be done - use wildcard selectors in SPD policy - initiator provides specifc values for IDii during QM - responder provides specific values for IDrr during QM (This would require IKE to provide the ability to modify during QM time) - make dynamic entries in SA and the end of QM - provide ability to change selector information after the SA is established using an authenticated notification. A requirment of this sort is already in cheryl's requirements document. The above scheme can handle dynamic protocols nicely. > I'd really like to see a standard solution to this problem. Yes - a standard solution to the problem would be nice. I think with little tweaks to what we already have the problem is solvable. > However, I don't see how elimininating TS support will resolve > this. Please elaborate on what you have in mind. > > Thanks, > > Scott > > ------=_NextPart_000_0086_01C1D0C8.AFC7D470 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgoTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAwAVAAsABwAAAAQABwEB A5AGANgDAAAdAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAABEAAAAcmVtb3ZlIFRTIGZyb20gSUtFdjIgKFJFOiBBZGRyZXNzZXMgaW4gdHJh ZmZpYyBzZWxlY3RvcnMgaW4gSUtFdiAyKQACAXEAAQAAACoAAAABwc+hcUvThTqQt0BPypCvIy1m uUlkACAExVgAAdLuEAAMVaz+ACwCGCAAAAIBHQwBAAAAFgAAAFNNVFA6U0FOS0FSQE5FWFNJLkNP TQAAAAsAAQ4AAAAAQAAGDgBi8ZML0cEBAgEKDgEAAAAYAAAAAAAAAN0fYNC6KDhPlErS2yqUDErC gAAAHgBCEAEAAABEAAAAPDdCODgyNEQ2OTAwOTJCNEI5MEIwRUY0Njc0NzUwQTY1MDIzMURCN0JA VVNFWENIMy51cy5zb25pY3dhbGwuY29tPgALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA AAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAAH1uAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwANgAggBgAA AAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA PIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUA AAAAAAADAFiACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAf4AIIAYAAAAAAMAAAAAAAABG AAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAA3R9g0LooOE+UStLbKpQMSgIB+g8BAAAAEAAAAN0fYNC6 KDhPlErS2yqUDEoCAfsPAQAAAJgAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAA AAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHNhbmthclxM b2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2su cHN0AAMA/g8FAAAAAwANNP03AAACAX8AAQAAADAAAAA8RElFUEpFRUtBUE1FRUtFRUxHR0NHRUJH RUJBQS5zYW5rYXJAbmV4c2kuY29tPgADwQ== ------=_NextPart_000_0086_01C1D0C8.AFC7D470-- From owner-ipsec@lists.tislabs.com Thu Mar 21 12:02:34 2002 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 g2LK2X429952; Thu, 21 Mar 2002 12:02:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05905 Thu, 21 Mar 2002 14:18:07 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E04652A5D@CORPMX14> To: ipsec@lists.tislabs.com Subject: QoS considerations Date: Thu, 21 Mar 2002 14:28:50 -0500 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 > I'd prefer to hear from QoS people on this. I guess I count as one of the "QoS people" (e.g., I'm one of the authors of a number of diffserv RFCs), even if it did take me a while to catch up to the email on this topic. The place to start is RFC 2983, which (among other things) takes up the issue of QoS differentiation vs. IPsec replay windows for diffserv. Quoting from Section 4.1: If reordering-based [QoS] differentiation is desired within such tunnels [e.g., IPsec], multiple parallel tunnels between the same endpoints should be used. [text in square brackets added for clarity in this post] In other words, a separate SA (and specifically a separate replay window) should be used for each of the QoS levels among which QoS reordering is desired/allowed between the tunnel endpoints. Early in this discussion, an assumption showed up that a sender [tunnel ingress node]: a) would request for the ESP traffic the same priority level as the highest priority among the different data streams, This is in about the same category as an assumption that an IPsec implementation would encrypt all IP traffic passing through it -- this depends on the problem one is trying to solve and the network environment in which one is trying to solve it. While there are situations in which it is appropriate, there are also situations in which it is clearly not appropriate. Similarly, the assertion that "IKE is nothing more than a virtual wire establishment protocol" is also sometimes appropriate for thinking about QoS, and sometimes not -- see RFC 2983 for a more comprehensive discussion. There are situations in which it's appropriate to perform QoS traffic conditioning within a tunnel and have the results visible beyond the egress. QoS negotiation via IKE is also sometimes appropriate. For a single-direction SA (as is the case for IKEv1), QoS negotiation is not necessary for diffserv; the sender applies the appropriate DSCP marking/traffic conditioning and that's that. For a bidirectional SA pair (as IKEv2 proposes), obtaining consistent QoS in both directions is often desirable and negotiation can help. For diffserv, PHBIDs should be negotiated (see RFC 3140), not DSCPs. A worked example of DSCP negotiation for a similar bidirectional scenario can be found in L2TP - see draft-ietf-l2tpext-ds-05.txt for details and some text than can probably be reused. IPsec currently makes QoS for tunnels somewhat difficult, as RFC 2401 requires copying the DSCP from the inner header to the outer header on tunnel ingress, and discarding it at tunnel egress, even if it's been changed. This is overly severe, and I believe/hope that it will be made more flexible in the new version of RFC 2401. See RFC 2983 for a longer explanation of what the QoS folks would like to see, but a quick summary is: - Copy inner DSCP to outer DSCP on ingress, but allow traffic conditioning on the outer header (e.g., to set the DSCP to some fixed value) afterwards if desired/appropriate. - On egress allow static selection (per SA) whether to use the inner or outer DSCP on traffic emerging from the tunnel. Allowing use of the outer DSCP does raise additional security concerns - these are discussed in the Security Considerations sections of RFC 2983 (as well as 2474 and 2475). Finally, RSVP is also in the "sometimes appropriate" category - by now, this theme should be clear. RSVP is a useful tool in some situations, but it doesn't handle admission control by itself, and one cannot count on it always being available or appropriate to use. Relying on RSVP as the only solution to providing QoS will result in not being able to support QoS in many network environments. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Mar 21 12:12:59 2002 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 g2LKCw400962; Thu, 21 Mar 2002 12:12:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06028 Thu, 21 Mar 2002 14:31:25 -0500 (EST) Message-Id: <5.1.0.14.0.20020321120852.00aee680@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 12:14:40 -0500 To: Derek Atkins , Uri Blumenthal From: David Jablon Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Cc: "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com In-Reply-To: References: <3C9A0555.F8F7354A@lucent.com> <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Is the limited entropy of the shared secret due to the fact that it is simply a hash of a password? If so, then perhaps the current simplistic shared-secret key protocol is not such a good fit for these common shared-secret password applications. -- David At 11:39 AM 3/21/2002 -0500, Derek Atkins wrote: >The fact that most users wont have a shared secret with 256 bits of >entropy? I suspect that most shared secrets are probably in the 64-80 >bits of entropy at the highest, and probably much lower than that. From owner-ipsec@lists.tislabs.com Thu Mar 21 12:13:04 2002 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 g2LKD3400983; Thu, 21 Mar 2002 12:13:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06029 Thu, 21 Mar 2002 14:31:26 -0500 (EST) Message-Id: <5.1.0.14.0.20020321131749.01efb120@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 13:37:03 -0500 To: Derek Atkins From: David Jablon Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Cc: Uri Blumenthal , "Prof. Ahmed A. A. Adas" , cdemar@ebsdr.com, ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20020321120852.00aee680@pop.theworld.com> <3C9A0555.F8F7354A@lucent.com> <000701c1d0d9$cf43eb20$4969fea9@amanda2> <3C9A0555.F8F7354A@lucent.com> <5.1.0.14.0.20020321120852.00aee680@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If what you say is true, then the current shared-secret protocol for IKE seems like a very bad mismatch for applications that require use of shared-secret passwords or other man-handled keying material. -- David At 12:19 PM 3/21/2002 -0500, Derek Atkins wrote: >Yes, the low entropy of shared secrets is due to the fact >that most of them are derived from short or weak passwords. >If you have a 128-256 bit random key for a shared secret, you >have the problem of transmitting that secret confidentially >between the hosts. If you use RSA, then all you need is >integrity across the distribution channel. > >-derek > >David Jablon writes: > > > Derek, > > > > Is the limited entropy of the shared secret due to the fact that > > it is simply a hash of a password? If so, then perhaps the current > > simplistic shared-secret key protocol is not such a good fit for these > > common shared-secret password applications. > > > > -- David > > > > At 11:39 AM 3/21/2002 -0500, Derek Atkins wrote: > > >The fact that most users wont have a shared secret with 256 bits of > > >entropy? I suspect that most shared secrets are probably in the 64-80 > > >bits of entropy at the highest, and probably much lower than that. > > > > > >-- > 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 Mar 21 12:13:10 2002 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 g2LKD9401013; Thu, 21 Mar 2002 12:13:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06004 Thu, 21 Mar 2002 14:30:25 -0500 (EST) Message-Id: <5.1.0.14.0.20020321174138.03ef9958@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 17:49:40 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes In-Reply-To: <000701c1d0d9$cf43eb20$4969fea9@amanda2> References: 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 LAA04464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:10 21.03.2002 +0300, you wrote: > > Dear ipsec-list, > > > > I just have a quick question for which I could not find any answers yet. > > Can someone tell whether the security strength of pre-shared key IKE > > authentication mode has been proven weaker than RSA-enc or RSA-sig IKE > > authentication mode ? > > Links would be much appreciated ... > > > > Many thanks, > > > > Claudine > > Well. the big plus with RSA is that RSA keys are generated mostly in a correct way. What I mean is, there is randomness in them and they are long enough. pre-shared keys are often not. Most software on the market do not use bit strings for the PSK, but ASCII strings. And there is no minimum length requirement. That means you can use a dictionary attack or an exhaustive search. If the GW doesn't notice the load and the number of failed Phase 1 connections, you might get authenticated. So. If you use PSKs with 128 bits or more (just to print a number here) of randomness in them, there is nothing really wrong with it. But in real life...... (This doesn't really answer your question. I'm aware.) J–rn Sierwald From owner-ipsec@lists.tislabs.com Thu Mar 21 12:19:26 2002 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 g2LKJP401860; Thu, 21 Mar 2002 12:19:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06149 Thu, 21 Mar 2002 14:41:37 -0500 (EST) Message-ID: <3C9A3A35.3060704@isi.edu> Date: Thu, 21 Mar 2002 11:53:25 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020320 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Black_David@emc.com CC: ipsec@lists.tislabs.com Subject: Re: QoS considerations References: <277DD60FB639D511AC0400B0D068B71E04652A5D@CORPMX14> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080106090403060108030209" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms080106090403060108030209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > IPsec currently makes QoS for tunnels somewhat difficult, as > RFC 2401 requires copying the DSCP from the inner header > to the outer header on tunnel ingress, and discarding it > at tunnel egress, even if it's been changed. This is > overly severe, and I believe/hope that it will be made more > flexible in the new version of RFC 2401. I can understand why this should be revisited, but it also requires a revision of RFC 2003. RFC 2401 already specifies some incompatible rules (e.g. for DF flag processing) that are in conflict with IPIP encapsulation as standardized in RFC 2003. (See draft-touch-ipsec-vpn-03.txt.) It may be useful to update 2401 and 2003 together. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms080106090403060108030209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMyMTE5NTMyNVowIwYJKoZIhvcNAQkEMRYEFHFnjD6YIkTNIAJcFpa8xS1Mj6JrMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAYbDFYVuhaYAL/lDTPsjQuM+dxDP6FPZsWUY6TGCbLYedjsSxmmbN0v58RzRBfOfIc ICZOEqVNOa3W8jroGC09VSiI7e9SJwykeYSjDIoZ/iwpYoV89A8sakww+TScMUb4j6GDfo4h 9OvIs2OG1aSJ2hjSGKxctNKq+X/TWiSN6QAAAAAAAA== --------------ms080106090403060108030209-- From owner-ipsec@lists.tislabs.com Thu Mar 21 12:57:46 2002 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 g2LKvi402904; Thu, 21 Mar 2002 12:57:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06399 Thu, 21 Mar 2002 15:18:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <3C9A3A35.3060704@isi.edu> References: <277DD60FB639D511AC0400B0D068B71E04652A5D@CORPMX14> <3C9A3A35.3060704@isi.edu> Date: Thu, 21 Mar 2002 15:26:13 -0500 To: Lars Eggert From: Stephen Kent Subject: Re: QoS considerations Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:53 AM -0800 3/21/02, Lars Eggert wrote: >Black_David@emc.com wrote: >>IPsec currently makes QoS for tunnels somewhat difficult, as >>RFC 2401 requires copying the DSCP from the inner header >>to the outer header on tunnel ingress, and discarding it at tunnel >>egress, even if it's been changed. This is >>overly severe, and I believe/hope that it will be made more >>flexible in the new version of RFC 2401. > >I can understand why this should be revisited, but it also requires >a revision of RFC 2003. RFC 2401 already specifies some incompatible >rules (e.g. for DF flag processing) that are in conflict with IPIP >encapsulation as standardized in RFC 2003. (See >draft-touch-ipsec-vpn-03.txt.) It may be useful to update 2401 and >2003 together. > >Lars >-- we already anticipate updating 2401 to describe appropriate ECN handling. I also anticipate closer alignment with 2003; there has been a view that tunnel mode was intentionally different from IP-in-IP tunneling. I don't hold that view is necessarily true in all respects; tunnel mode is different in terms of offering certain controls to a security administrator to manage covert channels (which would not normally be an issue) and in ensuring that the receiver examines the right portions of the received packet re access controls. to the extent that there are no adverse security implications, IP-in-IP processing should be applicable in IPsec. Steve From owner-ipsec@lists.tislabs.com Thu Mar 21 13:05:45 2002 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 g2LL5j403091; Thu, 21 Mar 2002 13:05:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06464 Thu, 21 Mar 2002 15:27:09 -0500 (EST) Message-ID: <3C9A44E4.7060302@isi.edu> Date: Thu, 21 Mar 2002 12:39:00 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020320 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: QoS considerations References: <277DD60FB639D511AC0400B0D068B71E04652A5D@CORPMX14> <3C9A3A35.3060704@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040902090005040900050803" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040902090005040900050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: >> I can understand why this should be revisited, but it also requires a >> revision of RFC 2003. RFC 2401 already specifies some incompatible >> rules (e.g. for DF flag processing) that are in conflict with IPIP >> encapsulation as standardized in RFC 2003. (See >> draft-touch-ipsec-vpn-03.txt.) It may be useful to update 2401 and >> 2003 together. > > we already anticipate updating 2401 to describe appropriate ECN > handling. I also anticipate closer alignment with 2003; there has been a > view that tunnel mode was intentionally different from IP-in-IP > tunneling. I don't hold that view is necessarily true in all respects; > tunnel mode is different in terms of offering certain controls to a > security administrator to manage covert channels (which would not > normally be an issue) and in ensuring that the receiver examines the > right portions of the received packet re access controls. to the extent > that there are no adverse security implications, IP-in-IP processing > should be applicable in IPsec. I fully agree that additional restrictions on IPIP tunnels may be required when they are secured via IPsec, exactly for the reasons you mentioned. Since IPIP encapsulation is standardized in 2003, we must make sure that these extra mechanisms don't conflict with the existing standard. Some of them may tuen out useful for non-secured IPIP tunnels, and should maybe go into a revision of 2003 instead. (I'd really like to see 2401bis point off to 2003/2003bis for most tunneling aspects.) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040902090005040900050803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDMyMTIwMzkwMFowIwYJKoZIhvcNAQkEMRYEFKBQyf3TuOtc5enH9tU2ATFyombwMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCBTcACXA9zNZx+HMPNHKV1ytg+FXVJ/YwO9OT5Y6Hp+HJDJtTWLrvDfvbIWn23gIBh UL1m7EVw8Ey5d7Wq2JOQExJEDu4pygke1rKyrAToXGjOXCvwXmWBBgjW93ddDZWzoJ+HerS3 xnl/ZiK1j+2gJXbC1QoDw1Pb8bJytke0XQAAAAAAAA== --------------ms040902090005040900050803-- From owner-ipsec@lists.tislabs.com Thu Mar 21 13:14:42 2002 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 g2LLEg403397; Thu, 21 Mar 2002 13:14:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06525 Thu, 21 Mar 2002 15:30:21 -0500 (EST) Message-Id: <200203212040.g2LKekM05741@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-reply-to: Your message of "Thu, 21 Mar 2002 09:05:42 PST." <20020321170542.17735.qmail@web12203.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Mar 2002 14:40:45 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sami" == Sami Vaarala writes: Sami> BCP is one alternative. But instead of having the implementor first Sami> read three specs that don't really make sense, and then read a BCP Sami> that says "ignore the specs, do this instead", it might be worthwhile Sami> to consider "re-specifying" IKEv1. Such re-specification could Sami> combine Sami> the three documents, and also contain the clarifications that all Sami> implementors need to know anyway. I actually would have liked us to do this and then attempt to rev IKE. This was shot down a year ago as a waste of time :-) I believe that Andrew Krywaniuk has proposed to do precisely what you suggest. I also agree that the Spencer draft would benefit from complementary viewpoints - we would welcome such input. If all of the text is pasted into Andrew's document... that's cool too. ] 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 iQCVAwUBPJpFS4qHRg3pndX9AQEUVAQA7HW2dBn/AYZ47PewrAH/3skcWvklusWS e8OB9RxIuWOkwdNLbTfUJ4MKL2Fhd1nvkaclcUj5LMy1dxXEZ55A1CV5Hps2sm2g NC1yesQQ3rSMm8iHzQOHe3Tco+/JSBXadiLbH7hqB4g1swHb57/or8uwJfjly0Tf VkBK+04B3Ic= =xGOu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 21 14:09:37 2002 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 g2LM9a406305; Thu, 21 Mar 2002 14:09:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07157 Thu, 21 Mar 2002 16:26:17 -0500 (EST) Date: Thu, 21 Mar 2002 16:36:57 -0500 (EST) From: Henry Spencer To: silvere@iki.fi cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-Reply-To: <20020321165901.1507.qmail@web12206.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 21 Mar 2002, Sami Vaarala wrote: > > ...draft-spencer-ipsec-ike-implementation-02.txt.. > > I've read the draft, and I liked the content. However, I don't think > it addresses all the issues that an implementor faces, especially the > details of processing individual messages. One way forward would be > to extend this document with more details, and make it less FreeS/WAN > specific. It's currently FreeS/WAN-specific mostly because that's the data we had. Some things aren't addressed because we have no data on them, others just because we never thought of discussing them. We already mention a few things we learned from other people rather than experiencing them directly; we'd be happy to add more such words of wisdom, with or without explicit credit as people prefer. Input would be welcome, especially detailed input -- saying "you ought to discuss X" is helpful, but it's much more helpful to say "X is a problem, the obvious solutions XA and XB don't work because of Y, but XC seems to work with everyone if you take precaution Z". Some of this information is already present in places like mailing-list archives, but digging through them in search of such gems is impossibly time-consuming. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 21 14:55:14 2002 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 g2LMtE408154; Thu, 21 Mar 2002 14:55:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07519 Thu, 21 Mar 2002 17:16:39 -0500 (EST) Date: Thu, 21 Mar 2002 17:29:19 -0500 From: Richard Guy Briggs To: Paul Koning Cc: joern@f-secure.com, ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues Message-ID: <20020321172919.C4482@grendel.conscoop.ottawa.on.ca> References: <3C99AB48.230D4CD4@6wind.com> <5.1.0.14.0.20020321124319.038df140@dfintra.f-secure.com> <15514.10009.716428.128355@pkoning.dev.equallogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15514.10009.716428.128355@pkoning.dev.equallogic.com>; from pkoning@equallogic.com on Thu, Mar 21, 2002 at 01:31:53PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Mar 21, 2002 at 01:31:53PM -0500, Paul Koning wrote: > >>>>> "Joern" == Joern Sierwald writes: > Joern> At 10:43 21.03.2002 +0100, you wrote: > >> Hello, > >> > >> During interoperability tests on several IKE/IPsec > >> implementations, we discovered different interpretations of the > >> IKEv1 or IPsec specification. > >> > >> Let's consider the following transform: > >> > >> (1) [IP][data] ==(IPsec)==> [IP][AH][ESP][encrypted IP+data] > >> > >> To negociate such transform as IKE-initiator, (2) some > >> implementations send a QM proposal of AH_transport + ESP_tunnel > >> (6WIND, KAME, OpenBSD...) (3) some other implementations send a > >> QM proposal of AH_tunnel + ESP_tunnel (FreeS/WAN, Cisco...) > >> > >> If initiator and responder use different interpretations, the > >> negociation fails most of the time. These two different > >> interpretations consequently lead to non-interoperable > >> implementations. > >> > >> IMHO only ESP is in tunnel mode in this transform, as opposed to > >> AH which is in transport mode. But some implementors seem to > >> consider that mode applies globally to the transform (AH+ESP). > >> > >> Are (2) and (3) valid representations of transform (1) ? > >> > >> /christophe > > Joern> The past few interops I've been to have addressed this issue > Joern> over and over again. The agreement was that (3) is correct. > > Joern> Some software may accept type (2) proposals are well, if they > Joern> are responder. But sending type (2) QM proposals is not > Joern> allowed. > > Joern> The basic idea is that the attributes should be consistent > Joern> over protocols. You have the same lifetime for AH and ESP, > Joern> you have the same PFS setting, and you should have the same > Joern> tunnel/transport setting. > > Interesting. I thought it was the other way around (i.e., (2) is > correct) but I'm rusty. > > So the consequence is that there is no way to request the following > encapsulation: > [IP][AH][IP][ESP][encrypted IP+data] > in a single negotiation. Why would you do that unless you intentionally were nesting tunnels? This would really infuriate those advocating transport mode only... What you have listed *can* be done with nested tunnels because in that case, all three IP headers could be different pairs of addresses. This, of course, creates a security issue because of the unauthenticated ESP header. > Yet another fine reason to let ESP do the whole job by itself... :-) > > paul slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From owner-ipsec@lists.tislabs.com Thu Mar 21 15:01:18 2002 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 g2LN1H408316; Thu, 21 Mar 2002 15:01:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07638 Thu, 21 Mar 2002 17:23:20 -0500 (EST) Message-ID: <20020321223512.86615.qmail@web12201.mail.yahoo.com> Date: Thu, 21 Mar 2002 14:35:12 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: Re: divergent interpretations of IKE/IPsec - interop issues To: Henry Spencer , silvere@iki.fi Cc: Michael Richardson , ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, --- Henry Spencer wrote: >[...] > Input would be welcome, especially detailed input -- saying "you ought to > discuss X" is helpful, but it's much more helpful to say "X is a problem, > the obvious solutions XA and XB don't work because of Y, but XC seems to > work with everyone if you take precaution Z". Some of this information is > already present in places like mailing-list archives, but digging through > them in search of such gems is impossibly time-consuming. I agree. Here is some input off the top off my head. If there is an effort to write something down along these lines, I'll be happy to contribute text. (Most of these have already been discussed and I might recall some of them wrong; my apologies if this is the case.) Don't use multiple SA payloads in QM - Most implementations don't support them. - Do them only if you know the other end supports them. Don't use the commit bit in phase 1 - It serves no purpose. When you see a commit bit, start sending commit bit yourself - "sticky" commit - There were other opinions on this? Never send redundant ID payloads in phase 2 - Especially, don't send them in transport mode; some implementations choke. Always send the simplest matching ID payload in phase 2 - Don't send a range or a mask if you have a single address; some implementations choke. - Maybe it should be specified that you should always send ID payloads when negotiating tunnel mode? If so, the previous issue should be changed to "never send ID payloads in phase 2 when doing transport". Use nonce size X, because Y. - There was some rationale on the list already on this. The text in RFCs about cookies is misleading. Just choose them randomly, that is OK. - There is no statelessness in IKEv1, and no need to spend cycles in anything more complicated than just picking them randomly. The IKEv1 retransmission algorithm - Including the "grace time" after completion of the exchange, during which you will retransmit the last message if receive dups. - Values for the various counters The order of ESP and AH in the proposal - Don't trust the order; although there is an order, it is actually a set of proposals. - Always send in order XYZ (I prefer ESP followed by AH, some otherwise). - The semantic is always the same (ESP inside AH) - If IPcomp involved, IPcomp, ESP, AH. The use of tunnel vs. transport mode attribute - If you receive at least one tunnel mode attribute in the entire SA payload, assume it's a tunnel mode negotiation; otherwise transport. - But always send the tunnel mode attributes as you are supposed to. (But what are you supposed to do? Send IP AH ESP IP data as ESP tunnel, AH tunnel? ESP tunnel, AH transport? I don't care, as long as there is one way that is written down somewhere :) You cannot mix tunnel and transport mode in phase 2 - Even though the syntax allows this, it doesn't make sense. Don't do it. Better advice on attribute encoding - Earlier, some implementations choked on attribute length 3, for instance. - Always send attributes using short encoding if possible. - Otherwise send using four bytes if possible. - Do not send larger than four byte attributes if at all possible. Tero and others have given good text about use of cert/cert req payloads on the list in the past. I would personally like to see pseudocode of how to handle the SA payloads. In particular: - How to generate phase 1 SA offer - How to respond to one - How to check that the response is actually a subset of the offer - How to generate phase 2 SA offset - How to respond to one - How to check that the response is actually a subset of the offer I would also like to see the relevant IPsec scenarios and packets corresponding to them spelled out. I.e., setting up tunnel mode ESP+AH, what the payloads should look like. That would clear up a number of uncertainties. -Sami __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Mar 21 15:13:13 2002 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 g2LNDC408595; Thu, 21 Mar 2002 15:13:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07694 Thu, 21 Mar 2002 17:30:33 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC0@NS-CA> From: Michael Choung Shieh To: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Thu, 21 Mar 2002 14:40:42 -0800 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 > > Michael> It was pointed out the responder can have wider > TS to do opportunitic sa. > Michael> The problem of it is it only works for > client-server case and fails in > Michael> peer-to-peer case. Even in client-server > scenario, most likely the server > > Have you really tried it? > No. But I believe for peer-to-peer (each side can be either initiator or responder) the proxy-id or TS must be exact matched. am I wrong? Michael Shieh From owner-ipsec@lists.tislabs.com Thu Mar 21 15:14:21 2002 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 g2LNEL408649; Thu, 21 Mar 2002 15:14:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07725 Thu, 21 Mar 2002 17:33:46 -0500 (EST) Date: Fri, 22 Mar 2002 00:45:37 +0200 Message-Id: <200203212245.AAA05528@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Tue, 19 Mar 2002 15:44:27 -0500) Subject: Re: Addresses in traffic selectors in IKEv2 References: <200203191800.UAA01482@burp.tkv.asdf.org> 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 Maybe I finally after 3 years realised part of the problem I have communicating my ideas: apparently I've had "dynamic selectors" from the beginning, and thought others had also. Apparently not? What I mean, for example I can have policy remote=10.0.0.1, remote_port=25 -> SA would generate traffic selector for SA negotiation as follows protocol : * remote_address: 10.0.0.1 local_address : * remote_port : 25 local_port : * Now, when talked about connection specific SA's, my policy has a special flags to indicate this remote=10.0.0.1, remote_port=25 -> SA [specific ports, addresses] then this is actually a shorthand notation for "static policy" remote=10.0.0.1, local_port=1, remote_port=25 -> SA1 remote=10.0.0.1, local_port=2, remote_port=25 -> SA2 remote=10.0.0.1, local_port=3, remote_port=25 -> SA3 ... ... remote=10.0.0.1, local_port=65534, remote_port=25 -> SA65534 remote=10.0.0.1, local_port=65535, remote_port=25 -> SA635535 and thus when a connection is opened, one possible traffic selector will be protocol : * remote_address: 10.0.0.1 local_address : * remote_port : 25 local_port : 34568 ================================= The TS contains the information from this "static policy"? TS also defines the granularity of SA's. How much complexity is really needed for the TS? I there really more needed except protocol : any or specific remote_port: any or specific local_port : any or specific proxy_addr : any, specific, range You may need another "proxy_addr", if you want to automatically negotiate the SA to the other direction. To explain, how proxy comes into play with tunnel mode (assuming my side is host): remote=10.0.0.0/8 -> SG-SA1 would get TS protocol: * remote_port: * local_port: * local_proxy_addr: * (or N/A) remote_proxy_addr: 10.0.0.0/8 however, again with dynamic policy remote=10.0.0.0/8 -> SG-SA [host specific] is actually remote=10.0.0.1 -> SG-SA1 remote=10.0.0.2 -> SG-SA2 remote=10.0.0.3 -> SG-SG2 ... and an example of TS in this case would be protocol: * remote_port: * local_port: * local_proxy_addr: * (or N/A) remote_proxy_addr: 10.0.2.3 ================== What this leads? You can't really just look a the actual policy selectors on some implementation. They are implementation specific. Perhaps the "static selector" is something more deterministic? From owner-ipsec@lists.tislabs.com Thu Mar 21 15:19:39 2002 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 g2LNJd408776; Thu, 21 Mar 2002 15:19:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07832 Thu, 21 Mar 2002 17:44:15 -0500 (EST) Message-Id: <200203212254.g2LMsfgw025185@thunk.East.Sun.COM> From: Bill Sommerfeld To: Michael Choung Shieh cc: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Thu, 21 Mar 2002 14:40:42 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DC0@NS-CA> Reply-to: sommerfeld@east.sun.com Date: Thu, 21 Mar 2002 17:54:41 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > No. But I believe for peer-to-peer (each side can be either initiator or > responder) the proxy-id or TS must be exact matched. am I wrong? There's no fundamental reason why this has to be the case, and I believe that TS can be defined such that an exact match is not necessary. - Bill From owner-ipsec@lists.tislabs.com Thu Mar 21 16:07:44 2002 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 g2M07i409752; Thu, 21 Mar 2002 16:07:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08206 Thu, 21 Mar 2002 18:29:26 -0500 (EST) Date: Fri, 22 Mar 2002 01:41:17 +0200 Message-Id: <200203212341.BAA05674@burp.tkv.asdf.org> From: Markku Savela To: silvere@iki.fi CC: henry@spsystems.net, silvere@iki.fi, mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com In-reply-to: <20020321223512.86615.qmail@web12201.mail.yahoo.com> (message from Sami Vaarala on Thu, 21 Mar 2002 14:35:12 -0800 (PST)) Subject: Re: divergent interpretations of IKE/IPsec - interop issues References: <20020321223512.86615.qmail@web12201.mail.yahoo.com> 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 > The order of ESP and AH in the proposal > - Don't trust the order; although there is an order, it is actually > a set of proposals. > - Always send in order XYZ (I prefer ESP followed by AH, some > otherwise). > - The semantic is always the same (ESP inside AH) > - If IPcomp involved, IPcomp, ESP, AH. This and some other entries just show that IKE should not do bundles. Creates unnecessary combinatory complexties. It should negotiate a single SA at time (or to optimize, all SA's, but it should not care about their order), it does not matter. The policy checks in kernel will take care of bundle requirements. From owner-ipsec@lists.tislabs.com Thu Mar 21 16:26:24 2002 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 g2M0QN410313; Thu, 21 Mar 2002 16:26:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08355 Thu, 21 Mar 2002 18:44:40 -0500 (EST) Date: Thu, 21 Mar 2002 18:55:50 -0500 (EST) From: Henry Spencer To: Markku Savela cc: silvere@iki.fi, mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-Reply-To: <200203212341.BAA05674@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 22 Mar 2002, Markku Savela wrote: > > The order of ESP and AH in the proposal... > > This and some other entries just show that IKE should not do > bundles. Creates unnecessary combinatory complexties. No, it says that IKE should not do bundles without good reason. There is a cost, but there are also benefits. Setting up a connection requires negotiating bundles, not SAs. If IKE does not do the bundling, something else must -- manual bundle setup is in general unacceptable. Please point to the RFC that defines the something else. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 21 21:34:44 2002 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 g2M5Yh416103; Thu, 21 Mar 2002 21:34:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10785 Thu, 21 Mar 2002 23:51:09 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC4@NS-CA> From: Michael Choung Shieh To: "'sommerfeld@east.sun.com'" , Michael Choung Shieh Cc: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Thu, 21 Mar 2002 21:00:54 -0800 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 TS (so is SPD) is not exact match in peer-to-peer, then traffic may be silently rejected after IKE is up. This totally defeats the MAIN purpose of TS. then what good is TS? Michael > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Thursday, March 21, 2002 2:55 PM > To: Michael Choung Shieh > Cc: 'Michael Richardson'; ipsec@lists.tislabs.com > Subject: Re: Don't remove TS from IKEv2 > > > > No. But I believe for peer-to-peer (each side can be > either initiator or > > responder) the proxy-id or TS must be exact matched. am I wrong? > > There's no fundamental reason why this has to be the case, and I > believe that TS can be defined such that an exact match is not > necessary. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Mar 21 21:34:46 2002 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 g2M5Yj416114; Thu, 21 Mar 2002 21:34:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10581 Thu, 21 Mar 2002 23:29:49 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC3@NS-CA> From: Michael Choung Shieh To: "'Dan Harkins'" Cc: ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Thu, 21 Mar 2002 20:40:43 -0800 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 It seems easy that we can just transform the SPD to TS and done. Unforetunely, if the SPD is comlex, it's not easy to populate SPD consistently. My rationals: 1. IKE must bear the complex SPD in TS. 2. IKE interoperability is affected by imcompatible service definition, and the various ways vendors transform SPD to TS. (and users cannot fix it by adding additional SP) 3. it doesn't work if users intend to have asymetric SPD, or change local SPD. 4. cannot support dynamic routing. and, if after go through so many troubles to transform SPD to TS and the only benefit is to detect mis-config SPD, I would suggest to put it as optional. Puting it as optional can detect mis-configuration whenever it's needed, and there is no security impact. Here I show some scenarios that populate SPD to TS is not tedious, it may not work at all. a. a popular grouping features supported by many vendors source (S1 & S2 & S3), destination (D1 & D2), service (FTP & DNS) to use VPN It will generate 3 x 2 x 4 = 24 TS payloads. (FTP = TCP port 20 & 21, DNS = TCP & UDP port DNS) so both sides need to transform these SPD to 24 TS. Upon receive the chain of TS, sort it out and compare. This is the easiest scenario since it can be done, just tedious (which I am fine as long as it can get right). b. If vendor B transform FTP and DNS to TS in different way (FTP=TCP port 21, DNS=TCP port DNS). then IKE won't work. These two are well-known so we can probably document it. However, how about all other applications out there? H323? Now IKE becomes a tool to check the interoperability of "service" (SPD) among vendors. so the definition of "app service" (spd) and the method of transform complex spd to TS must be standardized before IKE can work. Besides, the difference on SPD may not a problem. without zone transfer, DNS on UDP port 53 may work just fine. c. a good example for asymetic SPD is the "opportunistic sa". if SPD of A is TELNET, SPD of B is ANY. when A initiate IKE to B, IKE is up and telnet go through. However, after IKE is up, non-telnet traffic cannot come from B to A. I think it totally defeat the purpose of TS, but people seems fine with it. Another problem is we cannot change inbound SPD without totally shuting down tunnel. If there are 500 remote users out there and admin wants to change inbound policy (eg. remove one server from spd), he needs to change all users' SPD before he can change tunnel setting. d. if the ipsec gateway has 2 interfaces which connect to different routers. traffic from router 1 (from interface 1) go to tunnel 1 and traffic from router 2 (from interface 2) go to tunnel 2. Now even set TS as 0/0 won't work. Reason is simple - SPD may include interface as an attribute so the 5-tuple TS won't work. sorry for the lengthy messages. I just want to show puting the knowledge of SPD in IKE is not an good idea. We have enough interoperability in IKE, why bother to test the interoperability of SPD in IKE. Michael Shieh > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Thursday, March 21, 2002 3:14 AM > To: Michael Choung Shieh > Cc: ipsec@lists.tislabs.com > Subject: Re: Don't remove TS from IKEv2 > > > On Wed, 20 Mar 2002 19:41:38 PST you wrote > > > > TS does detect mis-config for simple scanario. However, it > falls short on > > more complex cases: > > > > 1. FTP, DNS, H323. (btw, can someone show me what the > correct TS should be > > for FTP and H323? I still don't know how to do it > correctly even for FTP) > > 2. dynamic routing. > > 3. NAT from several pools (or determined by routing) > > 4. change inbound local security policy without shuting > down whole tunnel or > > wait for peer's approval. > > Whatever was in the your SPD that matched the packet that caused the > negotiation to happen in the first place. That should be what your TS > payloads represent. > > > These are all customer request features. right now I can > only put 0 in > > proxy_id (and future TS) and screw up my tunnel. > > I'm assuming you are able to populate your SPD correctly (since this > discussion is not to change the representation of selectors). > If your SPD > can somehow be properly configured to allow NAT from > different pools or > H.323 to be IPsec protected it should not be too difficult to do this > either. Whatever got sent up with the "acquire" (a PF_KEY term but you > should have a symantically equivalent function) is what you use. > > Dan. > From owner-ipsec@lists.tislabs.com Thu Mar 21 21:37:07 2002 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 g2M5b6416169; Thu, 21 Mar 2002 21:37:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10828 Thu, 21 Mar 2002 23:57:07 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC5@NS-CA> From: Michael Choung Shieh To: "'Stephen Kent'" Cc: IP Security List Subject: RE: Don't remove TS from IKEv2 Date: Thu, 21 Mar 2002 21:07:58 -0800 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 I just means a selector may be the combination of "10 adresses and 5 subnets and 6 ranges and 3 sevices". The argument in this (long) thread is to propose to use id or name to replace TS and put TS as optional, not selector. Michael > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, March 21, 2002 7:15 AM > To: Michael Choung Shieh > Cc: IP Security List > Subject: RE: Don't remove TS from IKEv2 > > > At 12:18 PM -0800 3/20/02, Michael Choung Shieh wrote: > >An id or name (I mean phase 2 sa id, not phase 1) can > represent the "scope", > >either it's a single address, or the combination of 10 adresses and 5 > >subnets and 6 ranges and 3 sevices. > > Not sure what you mean by this comment. The names defined in 2401 as > selectors were intended only for symbolic replacements for individual > IP addresses, where the specific addresses are instantiated when the > SA is established. Thus, for example, an IKE responder could have an > SPD entry with the name of an individual, to support a mobile user. > When the user connects from the Internet, he presents a certificate > with a name that matches the SPD entry. Assuming the certificate is > appropriately validated, the responder should create a transient SPD > entry (or, in the new model, an SPD cache entry) that takes the > original SPD entry and substitutes the IP address for the name. There > was never an intent that the name forms be used in any selector other > than the IP addresses. I admit that 2401 did not do a good job of > explaining this, but we plan to clarify in the rev of 2401. > > Steve > From owner-ipsec@lists.tislabs.com Fri Mar 22 01:43:09 2002 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 g2M9h8415421; Fri, 22 Mar 2002 01:43:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12591 Fri, 22 Mar 2002 03:48:27 -0500 (EST) From: "sankar ramamoorthi" To: "Michael Choung Shieh" , "'Dan Harkins'" Cc: Subject: RE: Don't remove TS from IKEv2 Date: Fri, 22 Mar 2002 01:01:03 -0800 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DC3@NS-CA> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, IMHO, I feel that TS are absolutely required and not having them will lead to lot of interoperablity problems. I also feel that IKEV2 definition of TS is rich and goes a long way to solve the problems listed. Some additional things that would be nice to have in ikev2 are o allow TSes to be modified by either initiator or responder o allow TS to be changed after the ipsec SA is established. This could be achieved using authenticated and reliable notification. comments inline, -- sankar -- > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Choung Shieh > Sent: Thursday, March 21, 2002 8:41 PM > To: 'Dan Harkins' > Cc: ipsec@lists.tislabs.com > Subject: RE: Don't remove TS from IKEv2 > > > > It seems easy that we can just transform the SPD to TS and done. > Unforetunely, if the SPD is comlex, it's not easy to populate SPD > consistently. > > My rationals: > > 1. IKE must bear the complex SPD in TS. Yes - that seem to be best way for interoperable operation. Also TSes clearly indicate how each side wants the traffic to be restricted. > > 2. IKE interoperability is affected by imcompatible service > definition, and > the various ways vendors transform SPD to TS. (and users cannot fix it by > adding additional SP) > At least looking at the TSes negotiated we can find out how a peer is transforming SPD to TS. Not having it requires out-of-band means to determine what the tunnel is negotiated for. > 3. it doesn't work if users intend to have asymetric SPD, or change local > SPD. This problem can be addressed by enhancing IKE to allow changing a selector after ipsec SA is established. > > 4. cannot support dynamic routing. > > and, if after go through so many troubles to transform SPD to TS and the > only benefit is to detect mis-config SPD, I would suggest to put it as > optional. Puting it as optional can detect mis-configuration > whenever it's > needed, and there is no security impact. > > > > Here I show some scenarios that populate SPD to TS is not tedious, it may > not work at all. > > a. a popular grouping features supported by many vendors > source (S1 & S2 & S3), destination (D1 & D2), service (FTP & DNS) to > use VPN > It will generate 3 x 2 x 4 = 24 TS payloads. (FTP = TCP port 20 & > 21, DNS = TCP & UDP port DNS) > so both sides need to transform these SPD to 24 TS. Upon receive > the chain of TS, sort it out and compare. > This is the easiest scenario since it can be done, just > tedious (which I > am fine as long as it can get right). > > > b. If vendor B transform FTP and DNS to TS in different way (FTP=TCP port > 21, DNS=TCP port DNS). then IKE won't work. These two are > well-known so we > can probably document it. However, how about all other applications out > there? H323? Now IKE becomes a tool to check the interoperability of > "service" (SPD) among vendors. You seem to be making a case for having TS. In the absence of TS, the two parties can have different interpretations and end up with varying TSes as you describe. Worst, in the absence of TS each side may not be aware the other side's interpretation which seems to be a bigger problem to me. > > so the definition of "app service" (spd) and the method of transform > complex spd to TS must be standardized before IKE can work. not necessarily. Having a list of TSes and allowing for the TSes to be changed during and after QM negotiation allows ipsec traffic to flow even if one side's interpretation is more stringent than the other one's traffic flow is just restricted - looking at the TS negotiated, clearly indicates what the interpretation was. Having just an 'app service' identity requires standarization of what the service means for IKE to work in an interoperable way. > > Besides, the difference on SPD may not a problem. without zone > transfer, DNS on UDP port 53 may work just fine. > > c. a good example for asymetic SPD is the "opportunistic sa". > if SPD of A > is TELNET, SPD of B is ANY. when A initiate IKE to B, IKE is up > and telnet > go through. However, after IKE is up, non-telnet traffic cannot > come from B > to A. I think it totally defeat the purpose of TS, but people seems fine > with it. > > Another problem is we cannot change inbound SPD without totally > shuting down tunnel. If there are 500 remote users out there and admin > wants to change inbound policy (eg. remove one server from spd), > he needs to > change all users' SPD before he can change tunnel setting. This problem can be circumvented if we allow for the possiblity for TS to be changed after the SA is established (using authenticated notification messages). > > d. if the ipsec gateway has 2 interfaces which connect to > different routers. > traffic from router 1 (from interface 1) go to tunnel 1 and traffic from > router 2 (from interface 2) go to tunnel 2. Now even set TS as 0/0 won't > work. Reason is simple - SPD may include interface as an attribute so the > 5-tuple TS won't work. missing the point on this one. How is it related to IKE? > > > sorry for the lengthy messages. I just want to show puting the > knowledge of > SPD in IKE is not an good idea. We have enough interoperability > in IKE, why > bother to test the interoperability of SPD in IKE. Not having TS or having policy id for TS actually limits interoperbility. It seems to work well and allows for a richer definition of TS only when both ipsec peers interpret the id in the same manner. That calls for a lot more standarization work, which is beyond the scope of IKE. > > Michael Shieh > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > Sent: Thursday, March 21, 2002 3:14 AM > > To: Michael Choung Shieh > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Don't remove TS from IKEv2 > > > > > > On Wed, 20 Mar 2002 19:41:38 PST you wrote > > > > > > TS does detect mis-config for simple scanario. However, it > > falls short on > > > more complex cases: > > > > > > 1. FTP, DNS, H323. (btw, can someone show me what the > > correct TS should be > > > for FTP and H323? I still don't know how to do it > > correctly even for FTP) > > > 2. dynamic routing. > > > 3. NAT from several pools (or determined by routing) > > > 4. change inbound local security policy without shuting > > down whole tunnel or > > > wait for peer's approval. > > > > Whatever was in the your SPD that matched the packet that caused the > > negotiation to happen in the first place. That should be what your TS > > payloads represent. > > > > > These are all customer request features. right now I can > > only put 0 in > > > proxy_id (and future TS) and screw up my tunnel. > > > > I'm assuming you are able to populate your SPD correctly (since this > > discussion is not to change the representation of selectors). > > If your SPD > > can somehow be properly configured to allow NAT from > > different pools or > > H.323 to be IPsec protected it should not be too difficult to do this > > either. Whatever got sent up with the "acquire" (a PF_KEY term but you > > should have a symantically equivalent function) is what you use. > > > > Dan. > > From owner-ipsec@lists.tislabs.com Fri Mar 22 06:48:04 2002 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 g2MEm4407571; Fri, 22 Mar 2002 06:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15205 Fri, 22 Mar 2002 08:56:41 -0500 (EST) From: jbuyck@club-internet.fr To: ipsec@lists.tislabs.com Subject: Difference between RSA enc. and RSA Sig Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 22 Mar 2002 10:00:51 +0100 (CET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA12597 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. I test IPSec with certificate authentification on CISCO router and I wonder what is the difference between RSA Sig and RSA Enc option ? I know that RSA Sig is the default option to negociate IPSec tunnel based on certificate but what is exactly RSA Enc ? Very thanks. JB From owner-ipsec@lists.tislabs.com Fri Mar 22 06:48:04 2002 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 g2MEm4407570; Fri, 22 Mar 2002 06:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15123 Fri, 22 Mar 2002 08:48:35 -0500 (EST) Message-ID: <91A311FF6A85D3118DDF0060080C3D8202065BC3@lat3721.rd.francetelecom.fr> From: BUYCK Jacky FTRD/DMI/CAE To: ipsec@lists.tislabs.com Subject: Main difference between RSA Sig and RSA Enc. Date: Fri, 22 Mar 2002 14:36:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a8067ae1-3d08-11d6-b1e9-00508b69ab48" 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. ------=_NextPartTM-000-a8067ae1-3d08-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1A6.9A5FCAF0" ------_=_NextPart_001_01C1D1A6.9A5FCAF0 Content-Type: text/plain; charset="iso-8859-1" Hi. I work on IPSec tunnel under CISCO routers platform and I wonder what is the difference between the tw oauthentification method name : - RSA Sig - RSA Enc I know that RSA Sig is the default method to negociate IPSec tunnel using X509 certificate but I wonder what is RSA Enc. Anyone can give me some hints ? Thansk J.B ------_=_NextPart_001_01C1D1A6.9A5FCAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Main difference between RSA Sig and RSA Enc.

Hi.
I work on IPSec tunnel under CISCO = routers platform and I wonder what is the difference between the tw = oauthentification method name :

        - RSA Sig
        - RSA Enc

I know that RSA Sig is the default = method to negociate IPSec tunnel using X509 certificate but I wonder = what is RSA Enc.

Anyone can give me some hints ?
Thansk


J.B

------_=_NextPart_001_01C1D1A6.9A5FCAF0-- ------=_NextPartTM-000-a8067ae1-3d08-11d6-b1e9-00508b69ab48-- From owner-ipsec@lists.tislabs.com Fri Mar 22 08:38:17 2002 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 g2MGcG412566; Fri, 22 Mar 2002 08:38:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16137 Fri, 22 Mar 2002 10:48:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DC5@NS-CA> References: <9D048F4A422CD411A56500B0D0209C5B028F3DC5@NS-CA> Date: Fri, 22 Mar 2002 10:51:47 -0500 To: Michael Choung Shieh From: Stephen Kent Subject: RE: Don't remove TS from IKEv2 Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:07 PM -0800 3/21/02, Michael Choung Shieh wrote: >I just means a selector may be the combination of "10 adresses and 5 subnets >and 6 ranges and 3 sevices". The argument in this (long) thread is to >propose to use id or name to replace TS and put TS as optional, not >selector. > >Michael > Oh, that was not clear from the words you used. In that case, I can't complain that you are misinterpreting the existing SPD design, but I will argue that this is a bad idea :-). We already agree that two IPsec peers may have trouble coordinating SPD entries in order to achieve consistent expressions of access control policies. We are working on ways to reduce ambiguity in the expression of such policies when the intent is compatible. Putting in symbolic identifiers creates a whole new set of opportunities for mismatches, by adding in a layer of naming. I do not see how this helps address the fundamental problem. Steve From owner-ipsec@lists.tislabs.com Fri Mar 22 08:41:38 2002 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 g2MGfb412655; Fri, 22 Mar 2002 08:41:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16182 Fri, 22 Mar 2002 10:53:39 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC6@NS-CA> From: Michael Choung Shieh To: "'sankar ramamoorthi'" , Michael Choung Shieh , "'Dan Harkins'" Cc: ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Fri, 22 Mar 2002 08:04:30 -0800 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 SPD (so is TS) may be different from 1. misconfig 2. intended asymetric SPD (example in previous email) 3. different interpretation of applicatiion services among vendors when mismatched TS is found, IKE won't know which one it is. so a. fail IKE and don't support (2) b. IKE suceed. when data traffic is rejected, check SPD (or log for negotiated TS as Sankar suggested). current practice is (a). I am suggesting (b). more comments inline. Michael Shieh > -----Original Message----- > From: sankar ramamoorthi [mailto:sankar@nexsi.com] > > [ .... skip ......] > > > > d. if the ipsec gateway has 2 interfaces which connect to > > different routers. > > traffic from router 1 (from interface 1) go to tunnel 1 and > traffic from > > router 2 (from interface 2) go to tunnel 2. Now even set > TS as 0/0 won't > > work. Reason is simple - SPD may include interface as an > attribute so the > > 5-tuple TS won't work. > > missing the point on this one. How is it related to IKE? if users want 2 tunnels between gateway A and B. B is a multihome gateway connected to 2 routers as mentioned above. To create 2 tunnels between A and B, B should send TS as(0.0.0.0/0, interface 1) for tunnel 1 and (0.0.0.0/0, interface 2) for tunnel 2. current TS format cannot support it. one might argument that he can put more stringent subnet instead of (0.0.0.0/0). However, it means when routing changes beyond original TS, tunnel will be down until both sides changes their tunnel setup. Why users want to do 2 tunnels? a good reason is to prevent oracle attack. > > > > > > sorry for the lengthy messages. I just want to show puting the > > knowledge of > > SPD in IKE is not an good idea. We have enough interoperability > > in IKE, why > > bother to test the interoperability of SPD in IKE. > > Not having TS or having policy id for TS actually limits > interoperbility. > It seems to work well and allows for a richer definition of TS > only when both ipsec peers interpret the id in the same manner. > That calls for a lot more standarization work, The "sa id" is local agreement between 2 endpoints (along with tunnel creation agreement). There is no need for standardization. > which is beyond the scope of IKE. I think the interoperability and definition of application services among vendors is also beyond the scope of IKE. Unfortunely, IKE is doing it through TS. should we put it as optional? > From owner-ipsec@lists.tislabs.com Fri Mar 22 08:53:30 2002 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 g2MGrU413137; Fri, 22 Mar 2002 08:53:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16256 Fri, 22 Mar 2002 10:58:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DC3@NS-CA> References: <9D048F4A422CD411A56500B0D0209C5B028F3DC3@NS-CA> Date: Fri, 22 Mar 2002 11:06:38 -0500 To: Michael Choung Shieh From: Stephen Kent Subject: RE: Don't remove TS from IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:40 PM -0800 3/21/02, Michael Choung Shieh wrote: > > >Here I show some scenarios that populate SPD to TS is not tedious, it may >not work at all. > >a. a popular grouping features supported by many vendors > source (S1 & S2 & S3), destination (D1 & D2), service (FTP & DNS) to >use VPN > It will generate 3 x 2 x 4 = 24 TS payloads. (FTP = TCP port 20 & >21, DNS = TCP & UDP port DNS) > so both sides need to transform these SPD to 24 TS. Upon receive >the chain of TS, sort it out and compare. > This is the easiest scenario since it can be done, just tedious (which I >am fine as long as it can get right). The new proposals for how to express TS's would allow all this traffic to be mapped to a single SA, if that is the intent. One cannot do that now. Also, your terminology here seems to be a bit off. 2401 does not describe support for multiple individual values for a selector in an SPD entry. We intend to make this a requirement going forward. If one provides a management interface that presents this view, there is a potential problem that arises from the mismatch between what can be expressed in the SPD and what IKE can negotiate, something we tried to avoid. >b. If vendor B transform FTP and DNS to TS in different way (FTP=TCP port >21, DNS=TCP port DNS). then IKE won't work. These two are well-known so we >can probably document it. However, how about all other applications out >there? H323? Now IKE becomes a tool to check the interoperability of >"service" (SPD) among vendors. > > so the definition of "app service" (spd) and the method of transform >complex spd to TS must be standardized before IKE can work. > > Besides, the difference on SPD may not a problem. without zone >transfer, DNS on UDP port 53 may work just fine. I think what you are describing is again a mismatch between what one can express in the SPD vs. what IKE can negotiate. It should be a goal of our current efforts to close this gap as we improve the expressiveness of the SPD and sone of IKE. > c. a good example for asymetic SPD is the "opportunistic sa". if SPD of A >is TELNET, SPD of B is ANY. when A initiate IKE to B, IKE is up and telnet >go through. However, after IKE is up, non-telnet traffic cannot come from B >to A. I think it totally defeat the purpose of TS, but people seems fine >with it. This example seems to be incomplete. SPDs have independent, directional entries. A could be authorizing outbound Telnet connections, but rejecting inbound Telnet connections. If so, then asymmetric SPD entries for A&B might correctly express the intent of each site. It's not clear from your example what the intent was, so it's not clear that you have cited a real problem. > Another problem is we cannot change inbound SPD without totally >shuting down tunnel. If there are 500 remote users out there and admin >wants to change inbound policy (eg. remove one server from spd), he needs to >change all users' SPD before he can change tunnel setting. Where in 2401 do you find the basis for this requirement, as opposed to an implementation choice in a specific product? >d. if the ipsec gateway has 2 interfaces which connect to different routers. >traffic from router 1 (from interface 1) go to tunnel 1 and traffic from >router 2 (from interface 2) go to tunnel 2. Now even set TS as 0/0 won't >work. Reason is simple - SPD may include interface as an attribute so the >5-tuple TS won't work. I'm afraid the example is too terse for me to understand. But, since we are also working on revisions to 2401 that will deal with the question of when routing is performed relative to IPsec processing, we may be able to address issues of this sort going forward. Steve From owner-ipsec@lists.tislabs.com Fri Mar 22 09:14:46 2002 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 g2MHEk413785; Fri, 22 Mar 2002 09:14:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16552 Fri, 22 Mar 2002 11:33:54 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DC7@NS-CA> From: Michael Choung Shieh To: "'Stephen Kent'" Cc: ipsec@lists.tislabs.com Subject: RE: Don't remove TS from IKEv2 Date: Fri, 22 Mar 2002 08:44:42 -0800 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 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > > [skip] > > > Another problem is we cannot change inbound SPD without totally > >shuting down tunnel. If there are 500 remote users out > there and admin > >wants to change inbound policy (eg. remove one server from > spd), he needs to > >change all users' SPD before he can change tunnel setting. > > Where in 2401 do you find the basis for this requirement, as opposed > to an implementation choice in a specific product? > if the inbound policy of a tunnel is to allow all user to access 10.0.0.0/16 and admin want to change it to 10.0.0.0/24, he cannot just change the SPD of the gateway because IKE will check SPD through TS payload and fails. Tunnel will be down until all users' SPD get updated. Michael From owner-ipsec@lists.tislabs.com Fri Mar 22 09:31:18 2002 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 g2MHVH415284; Fri, 22 Mar 2002 09:31:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16654 Fri, 22 Mar 2002 11:48:08 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DC7@NS-CA> References: <9D048F4A422CD411A56500B0D0209C5B028F3DC7@NS-CA> Date: Fri, 22 Mar 2002 11:59:05 -0500 To: Michael Choung Shieh From: Stephen Kent Subject: RE: Don't remove TS from IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:44 AM -0800 3/22/02, Michael Choung Shieh wrote: > > -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> >> [skip] >> >> > Another problem is we cannot change inbound SPD without totally >> >shuting down tunnel. If there are 500 remote users out >> there and admin >> >wants to change inbound policy (eg. remove one server from >> spd), he needs to >> >change all users' SPD before he can change tunnel setting. >> >> Where in 2401 do you find the basis for this requirement, as opposed >> to an implementation choice in a specific product? >> > >if the inbound policy of a tunnel is to allow all user to access 10.0.0.0/16 >and admin want to change it to 10.0.0.0/24, he cannot just change the SPD of >the gateway because IKE will check SPD through TS payload and fails. Tunnel >will be down until all users' SPD get updated. > >Michael yes, if you want to change the security policy for an active tunnel, then you do need to tear it down and establish a new one. if, as I believe you propose, you make a purely local change, then you may begin dropping packets that previously were OK for the tunnel. creating a black hole is hardly a recommended way to advertise a policy change. Steve From owner-ipsec@lists.tislabs.com Fri Mar 22 09:33:07 2002 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 g2MHX6415604; Fri, 22 Mar 2002 09:33:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16744 Fri, 22 Mar 2002 11:56:32 -0500 (EST) Message-Id: <200203221707.g2MH6qT00621@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: QoS considerations In-reply-to: Your message of "Thu, 21 Mar 2002 14:28:50 EST." <277DD60FB639D511AC0400B0D068B71E04652A5D@CORPMX14> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Mar 2002 11:06:48 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I think that you have an excellent summary of the discussion so far, thank you. Your points about negotiating PHBid's is well taken. (Note that PHB = Per-Hop Behaviour, not Pointy Haired Boss) My concern with using RFC2983 when it comes to typical VPN and end-to-end deployments is that I'm really not clear what a host/gateway is supposed to do to signal the desired QoS. Specifically, when the boxes are customer located rather than located at the ISP (a la PPVPN). My understand of DiffServ is that DSCPs are really enterprise specific. So, there really isn't anything I can put in my packets to get the resulting PHB that I want. My opinion is that the only useful model is therefore RFC2998. This essentially says to use RSVP to signal the QoS for the resulting ESP packets that are generated. This signal travels to the first edge routing of the diffserv cloud [called the "diffedge" device in 2998] (and I would imagine no further), causing the edge router of the ISP to enact some admission control based upon (dest, proto, SPI#) [see RFC2207]. The packet is then admited to the proper diffserv queue and has the appropriate DSCP stamped on it. Note that there is nothing that gateway itself puts on the packet to pick the resulting DSCP (unless there is diffserv within the customer enterprise, which seems rather doubtful to me for some time). The only communication is via choice of different (dest, proto, SPI#) for different flows. So that implies actually negotiating multiple tunnels. >>>>> "Black" == Black David writes: Black> Finally, RSVP is also in the "sometimes appropriate" category Black> - by now, this theme should be clear. RSVP is a useful tool Black> in some situations, but it doesn't handle admission control Black> by itself, and one cannot count on it always being available To clarify this statement - RSVP just signals the desire for admission control. Black> or appropriate to use. Relying on RSVP as the only solution Black> to providing QoS will result in not being able to support Black> QoS in many network environments. I'm sure that this is true. (I've seen RSVP in operation myself, and I do not know anyone personally that has ever deployed it) What other options are there? One concern is when/if we define an attribute to describe the desired QoS on the SA bundle-pair being created is that the two ends may in fact have to use different (locally configured) mechanisms. ] 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 iQCVAwUBPJpYxoqHRg3pndX9AQHyNQP+Pxpy4rqpF6b1tgBKuMXUTdDvtqYGL+kh H4SFJGE33xI1JdFnCMmswy46FCEWiGpq4owf9BtMBLjMsPCAXiQ+Tl1aXgcZmVRQ hwZ9bknVoQtV4c2ImHNJgz3J2pc7xPEfgplDtWklUXOtwSXmDldIJZrllNQ99oz4 ykY0vlLxB3M= =YcH8 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 22 10:33:11 2002 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 g2MIX2418735; Fri, 22 Mar 2002 10:33:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17177 Fri, 22 Mar 2002 12:47:26 -0500 (EST) From: annelies.van_moffaert@alcatel.be To: ipsec@lists.tislabs.com Date: Fri, 22 Mar 2002 18:58:46 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 18:58:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I cleared my emails too enthousiastically so I don't have the exact question anymore but I saw this morning that somebody asked for a document that compares RSA, ECC and DSA. Maybe the following links could be useful. Kind regards, Lies. D.B. Johnson, A. Menezes, http://www.certicom.ca/research/wecdsa.html M.J.B. Robshaw and Yiqun Lisa Yin, http://www.rsasecurity.com/rsalabs/ecc/elliptic_curve.html From owner-ipsec@lists.tislabs.com Fri Mar 22 10:36:39 2002 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 g2MIaZ418876; Fri, 22 Mar 2002 10:36:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17326 Fri, 22 Mar 2002 12:58:01 -0500 (EST) Date: Fri, 22 Mar 2002 20:09:11 +0200 Message-Id: <200203221809.UAA06591@burp.tkv.asdf.org> From: Markku Savela To: henry@spsystems.net CC: silvere@iki.fi, mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Thu, 21 Mar 2002 18:55:50 -0500 (EST)) Subject: Re: divergent interpretations of IKE/IPsec - interop issues References: 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 > > This and some other entries just show that IKE should not do > > bundles. Creates unnecessary combinatory complexties. > > No, it says that IKE should not do bundles without good reason. There is > a cost, but there are also benefits. Setting up a connection requires > negotiating bundles, not SAs. If IKE does not do the bundling, something > else must -- manual bundle setup is in general unacceptable. Please point > to the RFC that defines the something else. IKE does not need to do the bundles. They are handled through the policy and SPD (as per RFC 2401). As I keep saying, there no good reason for IKE to do any policy checking. The kernel side which implements the RFC-2401 must do it anyway. So far, the *only* even barely good reason for IKE policy checking that has been presented here, is "black hole detection". But, I claim IKE is wrong place to detect this anyway. The correct place to detect a mismashed policy, is the kernel side IPSEC, and there is a very clear and definite place for it: When a IPSEC packet arrives, has ESP and/or AH, which decode correctly, and packet passes the replay checks, then you have a policy mismatch, if that packet and the applied SA's do not match the policy! At that point, IPSEC is supposed to log some event, and drop packet. It could also generate, *for example*, a PFKEY message which would contain the SA(s) and selector fields from the packet. Now, a IKE (or whatever key management) sees this message, it can check whether it has an open phase I session with the culprit. My suggestion: IKEv2 includes a notify message for reporting a policy mismatch (black hole). (which is generated from the kernel mismatch report). This method catches also black holes which are caused by other end sending stuff using wrong SA (even if SA negotiated for some other selectors). Also, the advantage is that there is only ONE entity interpreting the policy data base (and not the kernel and IKE separately). To me the above seems like clean architecture, it has an enourmously simplifying effect on IKE phase 2 negotiations. You only need consider each SA indipendently. No worries about ordering, no worries whether SA is tunnel or not. From owner-ipsec@lists.tislabs.com Fri Mar 22 10:44:24 2002 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 g2MIiO419367; Fri, 22 Mar 2002 10:44:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17450 Fri, 22 Mar 2002 13:08:18 -0500 (EST) Date: Fri, 22 Mar 2002 13:19:37 -0500 (EST) From: Henry Spencer To: Markku Savela cc: silvere@iki.fi, mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-Reply-To: <200203221809.UAA06591@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 22 Mar 2002, Markku Savela wrote: > > No, it says that IKE should not do bundles without good reason. There is > > a cost, but there are also benefits. Setting up a connection requires > > negotiating bundles, not SAs. If IKE does not do the bundling, something > > else must... > > IKE does not need to do the bundles. They are handled through the > policy and SPD (as per RFC 2401). How does "policy and SPD" determine, for example, whether authentication can be done via ESP or must be done via AH, or whether compression should be done? These are matters which must be negotiated -- they can't be decided unilaterally, because the two ends may have different preferences even if their sets of permissible choices do overlap. Your references to "policy and SPD" always sound to me like saying "it's somebody else's problem". Well, but *whose*? In real life, people use IKE quite extensively to negotiate these things. We cannot take such functions out of IKE unless there is a replacement available to do them... and why have two protocols when one suffices? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 22 12:09:42 2002 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 g2MK9g422235; Fri, 22 Mar 2002 12:09:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18158 Fri, 22 Mar 2002 14:24:15 -0500 (EST) Date: Fri, 22 Mar 2002 14:35:36 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Don't remove TS from IKEv2 In-Reply-To: <200203201622.g2KGM8gw011868@thunk.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002, Bill Sommerfeld wrote: > The purpose of traffic selectors is *not* to modify the SPD, but > rather to allow policy compatibility (or lack thereof) to be > discovered sooner rather than later. I agree with Bill's basic point -- he and I are on the same side of this particular debate -- but for slightly different reasons. The IPsec "SPD" is rather poorly named. It's a distinctly low-level concept, precisely dictating details of packet handling. In some implementations (such as FreeS/WAN), the SPD is dynamic, not static, with SPD entries set up and torn down as tunnels come and go, based on IKE negotiations constrained by policy specifications at a much higher level of abstraction. (As a non-traffic-selector example, the SPD says whether encrypted ESP packets should be authenticated using ESP authentication, or using a separate AH SA. Our high-level policy says that we prefer ESP authentication but will accept AH+ESP as an alternative. The SPD entry can't even be set up until IKE has negotiated which form the connection will use. This is important; one reason why we interoperate with almost all other IPsec implementations is precisely that we are willing to postpone such decisions until we see what the other end wants/needs.) So yes, traffic selectors really *can* modify the SPD. And it's useful. For Opportunistic Encryption (draft-richardson-ipsec-opportunistic-03.txt) in particular, we are willing to negotiate with a security gateway on behalf of someone behind him with no prearrangement whatsoever; this cannot be made to work unless the gateway tells us who he is representing. (In fact, it's annoying that we get this information so late in an IKE negotiation.) Something like traffic selectors is absolutely vital here, because we have no a priori information at all. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 22 12:19:20 2002 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 g2MKJJ423752; Fri, 22 Mar 2002 12:19:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18387 Fri, 22 Mar 2002 14:45:45 -0500 (EST) Date: Fri, 22 Mar 2002 14:57:05 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: IP Security List Subject: RE: remove TS from IKEv2 (RE: Addresses in traffic selectors in I KEv 2) In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DB3@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002, Michael Choung Shieh wrote: > Acturally the two parties need to get some kind of agreement before tunnels > establish. Not necessarily; see draft-richardson-ipsec-opportunistic-03.txt. > I am not sure if "opportunistic" is really useful in real world. Users want > tunnel up and works... For VPN users, that's true. Not all IPsec users are VPN users. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 22 12:20:03 2002 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 g2MKK2423858; Fri, 22 Mar 2002 12:20:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18406 Fri, 22 Mar 2002 14:47:00 -0500 (EST) Date: Fri, 22 Mar 2002 14:58:19 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: IP Security List Subject: RE: Don't remove TS from IKEv2 In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DB4@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002, Michael Choung Shieh wrote: > I would say agree on a simple id or name is easier than on a complex > selector under heterogenous adminstration. But then you must agree on what the name means. You have not solved the problem, only postponed it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 22 12:20:28 2002 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 g2MKKR423877; Fri, 22 Mar 2002 12:20:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18444 Fri, 22 Mar 2002 14:49:38 -0500 (EST) Date: Fri, 22 Mar 2002 15:00:58 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: IP Security List Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DB6@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Mar 2002, Michael Choung Shieh wrote: > It's only effective for simpler case. Simple cases are very important. > would say to put it as optional will have the advantage you say and simplify > the protocol... Any optional feature is one more decision that can be made differently by different implementors, breaking interoperability. Not a good idea. Moreover, that *doesn't* simplify the protocol. Indeed, it complicates it, because now all analysis must consider two different cases (TS and no-TS). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 22 18:45:44 2002 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 g2N2jh401313; Fri, 22 Mar 2002 18:45:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21146 Fri, 22 Mar 2002 20:52:47 -0500 (EST) From: "Rajesh Mohan" To: "Henry Spencer" , "Michael Choung Shieh" Cc: "IP Security List" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Fri, 22 Mar 2002 18:01:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Any optional feature is one more decision that can be made differently by > different implementors, breaking interoperability. Not a good idea. > > Moreover, that *doesn't* simplify the protocol. Indeed, it > complicates it, > because now all analysis must consider two different cases (TS and no-TS). > I do not agree that no-TS feature will break interoperability. It really depends on how we define interoperability. When two gateways negotiate to not use TS, then the two gateways are said to interoperate as long as they establish an SA and are able to decrypt a packet that is encrypted. *** They have chosen to use a policy enforcer outside IPSec ***. So, traffic not flowing because of misconfigured policy enforcer should not concern this group. We do not need no-TS feature if IKEv2 can solve all cases. Can we configure IKEv2 such that between the same pair of host we have "ESP null for H.323" and "ESP for FTP"? If the draft cannot cover this case, then no-TS feature will be useful where it is needed. There are environments where people can trust all traffic through a tunnel. It can be used in those cases. We can have a firewall rule to encrypt all traffic going through some interface or accept only encrypted traffic through some interface. In a dynamic routing environment, this may be useful. People will find ways to use VPN if you do not make TS mandatory. With no-TS feature, we will have more port based VPNs. Making it optional does not hurt anyone. It will help us use VPNs in new ways. From owner-ipsec@lists.tislabs.com Fri Mar 22 22:50:37 2002 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 g2N6ob405146; Fri, 22 Mar 2002 22:50:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA22648 Sat, 23 Mar 2002 00:42:30 -0500 (EST) Message-Id: <200203230350.g2N3oWD00779@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: divergent interpretations of IKE/IPsec - interop issues In-reply-to: Your message of "Fri, 22 Mar 2002 01:41:17 +0200." <200203212341.BAA05674@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Mar 2002 22:50:32 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Markku" == Markku Savela writes: >> The order of ESP and AH in the proposal >> - Don't trust the order; although there is an order, it is actually >> a set of proposals. >> - Always send in order XYZ (I prefer ESP followed by AH, some >> otherwise). >> - The semantic is always the same (ESP inside AH) >> - If IPcomp involved, IPcomp, ESP, AH. Markku> This and some other entries just show that IKE should not do Markku> bundles. Creates unnecessary combinatory complexties. Markku> It should negotiate a single SA at time (or to optimize, all Markku> SA's, but it should not care about their order), it does not Markku> matter. The policy checks in kernel will take care of bundle Markku> requirements. Assuming that the policy checks in the kernel are in fact the same at both sides. IKEv1 is not a policy negotiation protocol. This is bad, but it is. BUT, in a BCP, we document WHAT IS, not what we'd like. Please do NOT muddy the waters by mixing threads. Please see next message under the title: "Policy requirements in Son-Of-IKE" ] 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 iQCVAwUBPJv7hYqHRg3pndX9AQGK7gP/ZVMslV47X3Dv6hy8SXF3kdyZbDhL0bij TCfp8AoSSzXY5/HQXp+ax179Eop22P0ajZaFrOHL0n8ocGuNRnh5MdtZ+RGqQfVR asVqwnYAqAfqWMvyCWBfcJGbfCbhJZCgSQ1tfAgMamPcCrfkFbF8p5mikzKYRQFn IBwsXuVyoX0= =cmKj -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 22 22:50:43 2002 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 g2N6oh405158; Fri, 22 Mar 2002 22:50:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA22649 Sat, 23 Mar 2002 00:42:30 -0500 (EST) Message-Id: <200203230414.g2N4ELU01017@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Policy requirements in Son-Of-IKE Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Mar 2002 23:14:20 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- IKEv1 is a policy agreement protocol. It does not negotiate. There are two ways that we can do with this. 1) we can remove all policy from SOI. 2) we can improve policy so that we can negotiate in SOI. There are good arguments for both paths. I strongly believe that we must decide this very soon. If we go with path #1, then we must have a policy discovery and agreement protocol. This was supposed to be solved by IPSP WG, but IPSP got forced into doing this Policy Schema/PIB stuff. IPSP is only now starting on this. If the IPSEC WG wants to go route #1, then we MUST complete the IPSP WG on the same schedule. IPSRA work will have to be redone as well. (The PIB stuff doesn't help at all for inter-domain stuff, and I do not think it even helps for road-warrior/gateway. Maybe I'm wrong. ) If we go with path #2, then we need policy negotiation in SOI. I'm not convinced that this will be rich enough to do the kinds of things that SPP could do, but it MUST at least satisfy the VPN, remote access needs. It is likely that it will satisfy Opportunistic Encryption needs as well. A method to deal with protocols like FTP (i.e. IRC, H323, SIP/AVP, etc.) should be included in the requirements. (Some gateway discovery protocol like SPP, TED, etc. will still have value. A different form of OE can also be created with this kind of thing) Again, we have to decide on the path to take. This is not a debate about the proposals - it is clear to me that the protocol folks will cope. Cheryl's 01 draft suggests improving policy (#2). I think that most of the WG is siding with this. Not all. It would helpful if those who are in favour of #1 would: 1) write drafts (not emails) explaining their view of the world. 2) review the scenarios in the SOI requirements draft and explain how these things can be done. 3) join and help review the IPSP work. ] 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"); [ PS: I'm a bit upset that any time was spent on presentations on Thursday morning. We should have spent the high bandwidth time in the small room on discussion about these things. I guess I should have read the agenda with more thought and objected to it. I wonder if an official interim meeting in late April would have value. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPJwBGoqHRg3pndX9AQGz5QP/bBfLsR0H+wZIrxkUOTD5AO37KZdJ76LN BOwAeV9FaY/8HzMCI+Njiex7Md4dCOTgzYGtNYtv3rtBKyrcxQSyh762fjsSVQBJ IurdScYVYX/XL9sho9cjJYSJSSwGRtbvIoHC9QPnDYwF+if6bv1Nbe5jpkWnRLjd OGguY1YqdQg= =NNjD -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Mar 23 01:05:38 2002 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 g2N95c425952; Sat, 23 Mar 2002 01:05:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23788 Sat, 23 Mar 2002 03:19:50 -0500 (EST) Date: Sat, 23 Mar 2002 10:31:15 +0200 Message-Id: <200203230831.KAA07606@burp.tkv.asdf.org> From: Markku Savela To: mcr@sandelman.ottawa.on.ca CC: ipsec@lists.tislabs.com In-reply-to: <200203230350.g2N3oWD00779@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Fri, 22 Mar 2002 22:50:32 -0500) Subject: Re: divergent interpretations of IKE/IPsec - interop issues References: <200203230350.g2N3oWD00779@marajade.sandelman.ottawa.on.ca> 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 > IKEv1 is not a policy negotiation protocol. This is bad, but it is. > BUT, in a BCP, we document WHAT IS, not what we'd like. > Please do NOT muddy the waters by mixing threads. I'm only trying to get people to realize the following fact: (1) If you implement RFC-2401, then (2) there is no need for any policy checks in key negotiation, it can accept any proposed SA, if it can do the proposed algorithms and the protocol (AH, ESP or IPCOMP). Above takes care of the security. What remains, is just to find solutions to real world error situations, for example mismatched policies. For detecting blackhole (mismatched) I already outlined a solution, that does not need key management to know about policies, and which covers all cases, instead of just those that can be detected at key negotiation (e.g. sending packets over correctly negotiated, but wrong SA). Obviously, there appears to be some confusion about what "policy" actually is. The way I understand policy, there is no way IKE should be able to change it. If I specify in policy that packets MUST be protected by ESP using 3DES and SHA1 or MD5, then that's it. No way I would allow other end change those, like changing 3DES to DES! If I wanted that, I would say so in my policy like "use 3DES or DES and SHA1 or MD5". The IKE can then pick/negotiate the combination for the SA (I do not consider that part as "negotiating policy"). From owner-ipsec@lists.tislabs.com Sat Mar 23 01:05:58 2002 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 g2N95v425994; Sat, 23 Mar 2002 01:05:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23874 Sat, 23 Mar 2002 03:32:35 -0500 (EST) Date: Sat, 23 Mar 2002 10:43:12 +0200 Message-Id: <200203230843.KAA07620@burp.tkv.asdf.org> From: Markku Savela To: mcr@sandelman.ottawa.on.ca CC: ipsec@lists.tislabs.com In-reply-to: <200203230350.g2N3oWD00779@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Fri, 22 Mar 2002 22:50:32 -0500) Subject: Re: divergent interpretations of IKE/IPsec - interop issues [should be Policy requirements in Son-Of-IKE] References: <200203230350.g2N3oWD00779@marajade.sandelman.ottawa.on.ca> <200203230414.g2N4ELU01017@marajade.sandelman.ottawa.on.ca> 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 And sorry, yes, I should have posted my answer to another thread! From owner-ipsec@lists.tislabs.com Sun Mar 24 09:37:10 2002 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 g2OHbA415656; Sun, 24 Mar 2002 09:37:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05542 Sun, 24 Mar 2002 11:57:03 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Date: Sun, 24 Mar 2002 12:00:57 -0500 Message-ID: <005001c1d355$786a7c50$1e72788a@ca.alcatel.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 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ask a politically incorrect question like that on a list like this and you are bound to get a lot of FUD-type replies. Of course PK crypto has the advantage of scalability, but that's not the question you asked. Some people replied already, but here's a more presise response. The fact is, you can get any arbitrary strength you want with either asymm or symm algorithms by increasing the keylength. If you want a basis for comparing their strengths, you could compare the speed of the algorithms for equivalent crypto strength (which is not as silly as it seems, since you are always trading off crypto strength for speed). In that case, you could say that pre-shared secrets are stronger than public keys. (I don't know of any fundamental difference between the strength of PK encryption and PK signatures for authentication. ) Also, pre-shared secrets have an additional advantage for authentication, which is that you cannot mount a pure offline attack against them. In order to get some data for a brute force attack, you must first impersonate the responder in an active attack against the initiator. With public keys, you can conduct a purely offline attack. Of course, the strength of the authentication will still be limited by the amount of entropy in the secret. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of cdemar@ebsdr.com > Sent: Thursday, March 21, 2002 12:19 PM > To: uri@lucent.com > Cc: ipsec@lists.tislabs.com > Subject: RE: pre-shared key v RSA encryption or RSA signature > authentication modes > > > All, > > Thanks for the answers ... Uri is actually right that I'm > searching for a > comparison between RSa-enc and pre-shared key in the scope of IKE > authentication. I'm not trying to compare asymm v symm algorithms. > The fact is that IKE-phase1 exchanges compile different > material whether we > are doing pre-shared-key or RSA-enc. The first exchanges of > IKE main mode are > also different whether we use preshared-key or RSA-enc. This > generated > material (SKEY_ID), SKEYID_d, SKEYID_e,SKEYID_a are different > and used > differently whether we use RSA-enc or preshared-key. The > question is: Is the > authentication in IKE MainMode stronger when using RSA-enc > than when using > preshared-key ??? > And I don't this has anything to do with the strength of > RSA-enc v symmetric > algo ... > Any pointers are welcome, > Many thanks, > > Claudine > > -----Original Message----- > From: uri@lucent.com [mailto:uri@lucent.com] > Sent: Thursday, March 21, 2002 5:09 PM > To: warlord@mit.edu > Cc: alaadas@kaau.edu.sa; Demar, Claudine; ipsec@lists.tislabs.com > Subject: Re: pre-shared key v RSA encryption or RSA > signature authentication > modes > > Derek Atkins wrote: > > The fact that most users wont have a shared secret > > with 256 bits of entropy? A good point. However: > > > I suspect that most shared secrets are probably in the 64-80 > > bits of entropy at the highest, and probably much lower than > > that. > > A good point, certainly. But I don't see all that much in > common between, say, Unix passwords and IPsec pre-shared > keys. > > IPsec implementations I'm aware of, don't take an ASCII > password, but require a reasonably long key. > > Plus, a few years ago I saw a strength comparison table, > that listed relative strength of PK and symmetric key length. > Can you help me finding that one? It compares symmetric, > RSA, EC, and [if memory serves me] DSA-El-Gamal. > For example, my shared secrets are 128-bit long. Granted, > not 256 bits, but still stronger than a typical RSA sig > of 1024 bits (assording to that table as I remember)... > > > Based on the lack of entropy in shared secrets, I believe RSA sigs > > to be much stronger due to the better entropy in the key. > > Again, this sounds misleading. It's not "shared secrets" that lack > entropy. It's a certain type of shared secrets - derived from > [more or less > short] passwords, that lacks entropy. Not enough > justification to "condemn" > the whole symmetric > key approach, especially since the original question > was about IPsec authentication (as I read it). > -- > Regards, > Uri > -=-=-=<>=-=- > > > From owner-ipsec@lists.tislabs.com Sun Mar 24 09:37:16 2002 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 g2OHbF415669; Sun, 24 Mar 2002 09:37:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05567 Sun, 24 Mar 2002 11:58:45 -0500 (EST) From: "sankar ramamoorthi" To: "Michael Richardson" , Subject: RE: Policy requirements in Son-Of-IKE Date: Sun, 24 Mar 2002 09:11:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200203230414.g2N4ELU01017@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Friday, March 22, 2002 8:14 PM > To: ipsec@lists.tislabs.com > Subject: Policy requirements in Son-Of-IKE > > > -----BEGIN PGP SIGNED MESSAGE----- > > > IKEv1 is a policy agreement protocol. It does not negotiate. > > There are two ways that we can do with this. > 1) we can remove all policy from SOI. > 2) we can improve policy so that we can negotiate in SOI. > > There are good arguments for both paths. I strongly believe that we must > decide this very soon. > > If we go with path #1, then we must have a policy discovery and agreement > protocol. This was supposed to be solved by IPSP WG, but IPSP got > forced into > doing this Policy Schema/PIB stuff. IPSP is only now starting on > this. If the > IPSEC WG wants to go route #1, then we MUST complete the IPSP WG > on the same > schedule. IPSRA work will have to be redone as well. just for completeness..(personally not in favor of the approach). some of the emails in the discussion thread also indicated a desire to completely delink policy from IKE and make it part of the local fw or other subsystem implementation. In this case the mismatched SAs are detected not during SA establishment, but during runtime. This approach requires standardized ways in ipsec to report to the peer about the mismatch (to avoid blackhole problems). -- sankar -- From owner-ipsec@lists.tislabs.com Sun Mar 24 09:37:20 2002 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 g2OHbJ415693; Sun, 24 Mar 2002 09:37:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05319 Sun, 24 Mar 2002 11:20:58 -0500 (EST) Message-ID: <20020324163249.97139.qmail@web21308.mail.yahoo.com> Date: Sun, 24 Mar 2002 08:32:49 -0800 (PST) From: SatishK Amara Subject: SKEYSEED in IKEv2 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1531561896-1016987569=:94733" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-1531561896-1016987569=:94733 Content-Type: text/plain; charset=us-ascii Hi, I am just wondering what is the reason for SKEYSEED in IKEv2 is based on only Nounce and DH parameters. In IKEv1 it is calculated differently depending upon preshared keys, signatures or public key encryption. In case of preshared key in IKEv1 by doing so we can protect the identities of both parties from active attack. But this is not possible in IKEv2 ... --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1531561896-1016987569=:94733 Content-Type: text/html; charset=us-ascii

Hi,

   I am just wondering what is the reason for SKEYSEED in IKEv2 is based on only Nounce and DH parameters. In IKEv1 it is calculated differently depending upon preshared keys, signatures or public key encryption. In case of preshared key in IKEv1 by doing so we can protect the identities of both parties from active attack. But this is not possible in IKEv2 ...

 

 



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1531561896-1016987569=:94733-- From owner-ipsec@lists.tislabs.com Sun Mar 24 10:59:56 2002 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 g2OIxu419995; Sun, 24 Mar 2002 10:59:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05922 Sun, 24 Mar 2002 13:19:43 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'SatishK Amara'" , Subject: RE: SKEYSEED in IKEv2 Date: Sun, 24 Mar 2002 13:21:53 -0500 Message-ID: <005901c1d360$c7072560$1e72788a@ca.alcatel.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 In-reply-to: <20020324163249.97139.qmail@web21308.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I am just wondering what is the reason for SKEYSEED in > IKEv2 is based on only Nounce and DH parameters. In IKEv1 it > is calculated differently depending upon preshared keys, > signatures or public key encryption. In case of preshared key > in IKEv1 by doing so we can protect the identities of both > parties from active attack. But this is not possible in IKEv2 ... Your assumption is incorrrect. In IKEv1, the preshared key mode contained a special optimization in order to make the key subjectively "better" (because the attacker could not derive the session key even if he could crack the DH -- he would also have to crack the preshared key). This is an additional security measure that it not present in the PK signatures mode of IKE. However, this feature has several drawbacks: - When using main mode, the identity of the intitiator must be implicit from the IP. - When the initiator is a roaming client, the identity must be sent in the clear (because it acts as an index for the key lookup). - When the preshared key is wrong, the responder cannot send a meaninful error message. So as you can see, contrary to your suggestion, this feature of IKEv1 actually makes identity protection quite impossible when using pre-shared keys, since the identity must either be sent on the wire or it must be implicit from the key. A third option is to use a global pre-shared key, in which you get the perverse situtation where you have identity protection but you can't trust the id because it is too easy to forge. If, for whatever reason, you absolutely need identity protection of the initiator against an active attack, your best bet would be to implement a private extension in which the id is changed on each successive login. For example, you could make a session-based id by hashing an unpredictable string together with a nonce or counter. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Sun Mar 24 14:32:31 2002 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 g2OMWU425163; Sun, 24 Mar 2002 14:32:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07163 Sun, 24 Mar 2002 16:40:59 -0500 (EST) Message-ID: <20020324215256.35209.qmail@web21304.mail.yahoo.com> Date: Sun, 24 Mar 2002 13:52:56 -0800 (PST) From: SatishK Amara Subject: RE: SKEYSEED in IKEv2 To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com In-Reply-To: <005901c1d360$c7072560$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1974771108-1017006776=:98261" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-1974771108-1017006776=:98261 Content-Type: text/plain; charset=us-ascii Andrew, In IKEv2 I think identity protection can be provided by having an optional key-id field in message1 to identify the preshared key. If the optinal key-id field is present then the shared secret will be based on DH and preshared key. Any thoughts ... Andrew Krywaniuk wrote: > I am just wondering what is the reason for SKEYSEED in > IKEv2 is based on only Nounce and DH parameters. In IKEv1 it > is calculated differently depending upon preshared keys, > signatures or public key encryption. In case of preshared key > in IKEv1 by doing so we can protect the identities of both > parties from active attack. But this is not possible in IKEv2 ... Your assumption is incorrrect. In IKEv1, the preshared key mode contained a special optimization in order to make the key subjectively "better" (because the attacker could not derive the session key even if he could crack the DH -- he would also have to crack the preshared key). This is an additional security measure that it not present in the PK signatures mode of IKE. However, this feature has several drawbacks: - When using main mode, the identity of the intitiator must be implicit from the IP. - When the initiator is a roaming client, the identity must be sent in the clear (because it acts as an index for the key lookup). - When the preshared key is wrong, the responder cannot send a meaninful error message. So as you can see, contrary to your suggestion, this feature of IKEv1 actually makes identity protection quite impossible when using pre-shared keys, since the identity must either be sent on the wire or it must be implicit from the key. A third option is to use a global pre-shared key, in which you get the perverse situtation where you have identity protection but you can't trust the id because it is too easy to forge. If, for whatever reason, you absolutely need identity protection of the initiator against an active attack, your best bet would be to implement a private extension in which the id is changed on each successive login. For example, you could make a session-based id by hashing an unpredictable string together with a nonce or counter. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1974771108-1017006776=:98261 Content-Type: text/html; charset=us-ascii

Andrew,

In IKEv2 I think identity protection can be provided by having an optional key-id field in

message1 to identify the preshared key.  If the optinal key-id field is present then the

shared secret will be based on DH and preshared key.  Any thoughts ...

 

 

  Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> wrote:

> I am just wondering what is the reason for SKEYSEED in
> IKEv2 is based on only Nounce and DH parameters. In IKEv1 it
> is calculated differently depending upon preshared keys,
> signatures or public key encryption. In case of preshared key
> in IKEv1 by doing so we can protect the identities of both
> parties from active attack. But this is not possible in IKEv2 ...

Your assumption is incorrrect.

In IKEv1, the preshared key mode contained a special optimization in order
to make the key subjectively "better" (because the attacker could not derive
the session key even if he could crack the DH -- he would also have to crack
the preshared key). This is an additional security measure that it not
present in the PK signatures mode of IKE.

However, this feature has several drawbacks:

- When using main mode, the identity of ! the intitiator must be implicit from
the IP.
- When the initiator is a roaming client, the identity must be sent in the
clear (because it acts as an index for the key lookup).
- When the preshared key is wrong, the responder cannot send a meaninful
error message.

So as you can see, contrary to your suggestion, this feature of IKEv1
actually makes identity protection quite impossible when using pre-shared
keys, since the identity must either be sent on the wire or it must be
implicit from the key. A third option is to use a global pre-shared key, in
which you get the perverse situtation where you have identity protection but
you can't trust the id because it is too easy to forge.

If, for whatever reason, you absolutely need identity protection of the
initiator against an active attack, your best bet would be to implement a
private extension in which the id is changed on each successive login. For
example, you could make a ses! sion-based id by hashing an unpredictable
string together with a nonce or counter.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1974771108-1017006776=:98261-- From owner-ipsec@lists.tislabs.com Sun Mar 24 16:40:37 2002 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 g2P0eb427221; Sun, 24 Mar 2002 16:40:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07879 Sun, 24 Mar 2002 18:46:42 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E02937627@CORPMX14> To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: RE: QoS considerations Date: Sun, 24 Mar 2002 18:57:43 -0500 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 > My concern with using RFC2983 when it comes to typical VPN and end-to-end > deployments is that I'm really not clear what a host/gateway is supposed to > do to signal the desired QoS. Specifically, when the boxes are customer > located rather than located at the ISP (a la PPVPN). > > My understand of DiffServ is that DSCPs are really enterprise specific. > So, there really isn't anything I can put in my packets to get the resulting > PHB that I want. My opinion is that the only useful model is therefore > RFC2998. > > This essentially says to use RSVP to signal the QoS for the resulting > ESP packets that are generated. This signal travels to the first edge routing > of the diffserv cloud [called the "diffedge" device in 2998] (and I would > imagine no further), causing the edge router of the ISP to enact some > admission control based upon (dest, proto, SPI#) [see RFC2207]. > The packet is then admited to the proper diffserv queue and has the > appropriate DSCP stamped on it. This causes the ISP's edge router to have to classify traffic based on SPI#. That's an example of microflow classification, and a rather unusual one. An alternative model would be to apply the DSCPs that the ISP is expecting at the customer's VPN gateway that is facing the ISP; the ISP then classifies traffic based on DSCP and conducts admission control on the basis of that classification. Both solutions require the signaling to pass from the VPN gateway to the ISP, and are subject to failure if it doesn't (e.g., something in between discards RSVP traffic or decides to rewrite the DSCPs because it can). If IPsec is running end-to-end, so the IPsec implementations are on hosts attached to a customer network rather than on an ISP-facing VPN gateway, things get more complicated, and RFC 2998 is certainly one approach to a solution. Another is to use whatever's appropriate for the customer network and have an ISP-facing device reclassify the traffic and apply the DSCPs as appropriate for the customer's policy for usage of the ISP. This can be made to work even if the customer network is based on IP precedence, as there are multiple possible DSCPs for each IP Precedence level - these would have meaning for the ISP-facing traffic reclassifier even if the customer's routers ignored them - see Section 4.2 of RFC 2474 for more details. > One concern is when/if we define an attribute to describe the desired QoS > on the SA bundle-pair being created is that the two ends may in fact have to > use different (locally configured) mechanisms. Yes ... and you thought security policy was complicated ;-). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Sun Mar 24 21:22:21 2002 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 g2P5ML404308; Sun, 24 Mar 2002 21:22:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09465 Sun, 24 Mar 2002 23:28:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Sun, 24 Mar 2002 20:40:09 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Discussion of the IANA IPsec registries Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the IETF meeting last week, there was a brief discussion about a revision to the IANA registries for IPsec. Briefly, there are a few holes in the IANA registries and they should probably be combined so that IPsec implementors can find all the values more easily. There are also a few bugs in the registries that should be fixed. See for a proposal for the new registry and information on a mailing list to discuss it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 25 08:56:37 2002 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 g2PGub410238; Mon, 25 Mar 2002 08:56:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13676 Mon, 25 Mar 2002 11:04:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <005001c1d355$786a7c50$1e72788a@ca.alcatel.com> References: <005001c1d355$786a7c50$1e72788a@ca.alcatel.com> Date: Mon, 25 Mar 2002 11:08:07 -0500 To: From: Stephen Kent Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:00 PM -0500 3/24/02, Andrew Krywaniuk wrote: >Ask a politically incorrect question like that on a list like this and you >are bound to get a lot of FUD-type replies. Of course PK crypto has the >advantage of scalability, but that's not the question you asked. Some people >replied already, but here's a more presise response. > >The fact is, you can get any arbitrary strength you want with either asymm >or symm algorithms by increasing the keylength. If you want a basis for >comparing their strengths, you could compare the speed of the algorithms for >equivalent crypto strength (which is not as silly as it seems, since you are >always trading off crypto strength for speed). In that case, you could say >that pre-shared secrets are stronger than public keys. (I don't know of any >fundamental difference between the strength of PK encryption and PK >signatures for authentication. ) > >Also, pre-shared secrets have an additional advantage for authentication, >which is that you cannot mount a pure offline attack against them. In order >to get some data for a brute force attack, you must first impersonate the >responder in an active attack against the initiator. With public keys, you >can conduct a purely offline attack. Of course, the strength of the >authentication will still be limited by the amount of entropy in the secret. > >Andrew I'm glad you mentioned what I consider to be a significant downside of pre-shared secrets, although we come to very different conclusions. It is not too hard to imagine an attack in which the initiator connects to the wrong address, e.g., via some form of DNS attack, and the fake responder collects the initiator's secret, then drops the connection. This seems like such a serious concern that it argues very strongly against pre-shared secrets vs. public keys. Note that using public keys. e.g., in self-signed certs, does not suffer from this problem. Steve From owner-ipsec@lists.tislabs.com Mon Mar 25 10:07:33 2002 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 g2PI7X414857; Mon, 25 Mar 2002 10:07:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14212 Mon, 25 Mar 2002 12:22:40 -0500 (EST) Date: Mon, 25 Mar 2002 12:34:05 -0500 (EST) From: Henry Spencer To: Rajesh Mohan cc: IP Security List Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 22 Mar 2002, Rajesh Mohan wrote: > > Any optional feature is one more decision that can be made differently by > > different implementors, breaking interoperability. Not a good idea. > > I do not agree that no-TS feature will break interoperability. It really > depends on how we define interoperability. When two gateways negotiate to > not use TS... The normal definition of an optional feature is one that need not be implemented at all. Life being what it is, that means some people will not implement it, and others will insist on it being present, thus breaking interoperability. > We do not need no-TS feature if IKEv2 can solve all cases. Can we configure > IKEv2 such that between the same pair of host we have "ESP null for H.323" > and "ESP for FTP"? If the draft cannot cover this case, then no-TS feature > will be useful where it is needed. That's not "no TS", that's a case where the TS needs some way (a name?) to refer to traffic restrictions prearranged by other means. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 10:07:42 2002 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 g2PI7g414894; Mon, 25 Mar 2002 10:07:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14234 Mon, 25 Mar 2002 12:23:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203251709.MAA16171@nwmail.wh.lucent.com> References: <005001c1d355$786a7c50$1e72788a@ca.alcatel.com> <200203251709.MAA16171@nwmail.wh.lucent.com> Date: Mon, 25 Mar 2002 12:26:51 -0500 To: uri@bell-labs.com From: Stephen Kent Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:06 PM -0500 3/25/02, Uri Blumenthal wrote: >On Monday 25 March 2002 11:08, Stephen Kent wrote: >> I'm glad you mentioned what I consider to be a significant downside >> of pre-shared secrets, although we come to very different >> conclusions. It is not too hard to imagine an attack in which the >> initiator connects to the wrong address, e.g., via some form of DNS >> attack, and the fake responder collects the initiator's secret, then >> drops the connection. > >I thought this authentication method is YEARS gone? A-la HTTP Basic >Authentication? > >Isn't practically everybody today using some form of challenge-response >auth with pre-shared secrets? [real-life examples would be helpful.] >-- There have been messages posted to the list that suggest otherwise, but it would be useful to get some data points. Steve From owner-ipsec@lists.tislabs.com Mon Mar 25 10:34:24 2002 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 g2PIYO416250; Mon, 25 Mar 2002 10:34:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14529 Mon, 25 Mar 2002 13:00:03 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DD3@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" , IP Security List Subject: RE: Don't remove TS from IKEv2 Date: Mon, 25 Mar 2002 10:10:17 -0800 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 It seems to me the model of "Opportunistic Encryption" is only applicable to client-server, not peer-to-peer scenario. It also has blackhole problem when data traffic is initiated from server side. The other problem is, under client server scenario, usually server is protecting more valuable information so it has stricter SPD than clients. -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, March 22, 2002 11:36 AM To: IP Security List Subject: Re: Don't remove TS from IKEv2 On Wed, 20 Mar 2002, Bill Sommerfeld wrote: > The purpose of traffic selectors is *not* to modify the SPD, but > rather to allow policy compatibility (or lack thereof) to be > discovered sooner rather than later. I agree with Bill's basic point -- he and I are on the same side of this particular debate -- but for slightly different reasons. The IPsec "SPD" is rather poorly named. It's a distinctly low-level concept, precisely dictating details of packet handling. In some implementations (such as FreeS/WAN), the SPD is dynamic, not static, with SPD entries set up and torn down as tunnels come and go, based on IKE negotiations constrained by policy specifications at a much higher level of abstraction. (As a non-traffic-selector example, the SPD says whether encrypted ESP packets should be authenticated using ESP authentication, or using a separate AH SA. Our high-level policy says that we prefer ESP authentication but will accept AH+ESP as an alternative. The SPD entry can't even be set up until IKE has negotiated which form the connection will use. This is important; one reason why we interoperate with almost all other IPsec implementations is precisely that we are willing to postpone such decisions until we see what the other end wants/needs.) So yes, traffic selectors really *can* modify the SPD. And it's useful. For Opportunistic Encryption (draft-richardson-ipsec-opportunistic-03.txt) in particular, we are willing to negotiate with a security gateway on behalf of someone behind him with no prearrangement whatsoever; this cannot be made to work unless the gateway tells us who he is representing. (In fact, it's annoying that we get this information so late in an IKE negotiation.) Something like traffic selectors is absolutely vital here, because we have no a priori information at all. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 10:53:56 2002 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 g2PIrt417211; Mon, 25 Mar 2002 10:53:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14670 Mon, 25 Mar 2002 13:13:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 25 Mar 2002 13:22:46 -0500 To: "Rajesh Mohan" From: Stephen Kent Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Cc: "IP Security List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:01 PM -0800 3/22/02, Rajesh Mohan wrote: > > >> Any optional feature is one more decision that can be made differently by >> different implementors, breaking interoperability. Not a good idea. >> >> Moreover, that *doesn't* simplify the protocol. Indeed, it >> complicates it, >> because now all analysis must consider two different cases (TS and no-TS). >> > >I do not agree that no-TS feature will break interoperability. It really >depends on how we define interoperability. When two gateways negotiate to >not use TS, then the two gateways are said to interoperate as long as they >establish an SA and are able to decrypt a packet that is encrypted. *** They >have chosen to use a policy enforcer outside IPSec ***. So, traffic not >flowing because of misconfigured policy enforcer should not concern this >group. > >We do not need no-TS feature if IKEv2 can solve all cases. Can we configure >IKEv2 such that between the same pair of host we have "ESP null for H.323" >and "ESP for FTP"? If the draft cannot cover this case, then no-TS feature >will be useful where it is needed. > >There are environments where people can trust all traffic through a tunnel. >It can be used in those cases. We can have a firewall rule to encrypt all >traffic going through some interface or accept only encrypted traffic >through some interface. In a dynamic routing environment, this may be >useful. People will find ways to use VPN if you do not make TS mandatory. >With no-TS feature, we will have more port based VPNs. Making it optional >does not hurt anyone. It will help us use VPNs in new ways. it is important to remember that in developing a standard we try to accommodate a broad range of anticipated users, but we do not do so optimally. Making transmission of traffic selector info optional adds complexity to the system, because a compliant system has to be able to deal with this data, and to be able to deal with it's absence. I don't doubt that some folks might like to use some non-IPsec mechanism to achieve the same effect, but do we want to add complexity to the system in order to accommodate this set of prospective users? Steve From owner-ipsec@lists.tislabs.com Mon Mar 25 11:36:57 2002 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 g2PJau419164; Mon, 25 Mar 2002 11:36:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14871 Mon, 25 Mar 2002 13:50:11 -0500 (EST) Message-Id: <200203251859.g2PIxgK00752@fatty.lounge.org> To: "Rajesh Mohan" Cc: "IP Security List" Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Fri, 22 Mar 2002 18:01:10 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <749.1017082782.1@tibernian.com> Date: Mon, 25 Mar 2002 10:59:42 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 22 Mar 2002 18:01:10 PST you wrote > > We do not need no-TS feature if IKEv2 can solve all cases. Can we configure > IKEv2 such that between the same pair of host we have "ESP null for H.323" > and "ESP for FTP"? If the draft cannot cover this case, then no-TS feature > will be useful where it is needed. IKEv2 is not configured to express that, the SPD is. Can you configure the SPD to express "ESP for FTP" or "ESP null for H.323"? If you can then that representation in the SPD is passed to IKEv2 when a packet matches that rule and no SA exists. If you cannot then this is not an IKEv2 issue. Dan. From owner-ipsec@lists.tislabs.com Mon Mar 25 11:53:15 2002 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 g2PJrE419564; Mon, 25 Mar 2002 11:53:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15083 Mon, 25 Mar 2002 14:18:03 -0500 (EST) Date: Mon, 25 Mar 2002 14:29:25 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: IP Security List Subject: opportunistic (was RE: Don't remove TS from IKEv2) In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DD3@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 25 Mar 2002, Michael Choung Shieh wrote: > It seems to me the model of "Opportunistic Encryption" is only applicable to > client-server, not peer-to-peer scenario. Why? Please explain. The words "client" and "server" do not appear in the spec, last I looked, and it certainly works peer-to-peer -- we're using it that way experimentally. > It also has blackhole problem > when data traffic is initiated from server side. Why? Please explain. The protocol is symmetrical; there is no "client" or "server" distinction made. > The other problem is, under client server scenario, usually server is > protecting more valuable information so it has stricter SPD than clients. How is this relevant? Opportunistic encryption is intended to protect communication that now goes out in cleartext; it is *not* just another kind of VPN. There is no particular trust relationship between the two ends, and no reason why an incoming packet over an OE tunnel is trusted any more than a packet which arrives from the rest of the Internet. Information which is protected from general Internet access should be protected from access via OE tunnels too. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 11:53:37 2002 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 g2PJra419579; Mon, 25 Mar 2002 11:53:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15127 Mon, 25 Mar 2002 14:21:11 -0500 (EST) Date: Mon, 25 Mar 2002 14:32:37 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: <200203251859.g2PIxgK00752@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 25 Mar 2002, Dan Harkins wrote: > IKEv2 is not configured to express that, the SPD is. Can you configure the > SPD to express "ESP for FTP" or "ESP null for H.323"? If you can then that > representation in the SPD is passed to IKEv2 when a packet matches that rule > and no SA exists... Well, remember that the SPD machinery can have local extensions -- the RFCs specify minimum functionality only. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 12:18:33 2002 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 g2PKIX420913; Mon, 25 Mar 2002 12:18:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15309 Mon, 25 Mar 2002 14:43:23 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DD5@NS-CA> From: Michael Choung Shieh To: "'Dan Harkins'" , Rajesh Mohan Cc: IP Security List Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Mon, 25 Mar 2002 11:54:18 -0800 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 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Monday, March 25, 2002 11:00 AM > To: Rajesh Mohan > Cc: IP Security List > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote > > > > We do not need no-TS feature if IKEv2 can solve all cases. > Can we configure > > IKEv2 such that between the same pair of host we have "ESP > null for H.323" > > and "ESP for FTP"? If the draft cannot cover this case, > then no-TS feature > > will be useful where it is needed. > > IKEv2 is not configured to express that, the SPD is. Can you > configure the > SPD to express "ESP for FTP" or "ESP null for H.323"? If you > can then that > representation in the SPD is passed to IKEv2 when a packet > matches that rule > and no SA exists. If you cannot then this is not an IKEv2 issue. > > Dan. > It IS an IKEv2 issue when SPD is converted to TS and TS is used in IKEv2. Everyone MUST have a standard way to say what is "FTP" or "H323". The representation of SPD and the conversion of SPD to TS must be standardized to achieve IKE interoperability. Michael Shieh From owner-ipsec@lists.tislabs.com Mon Mar 25 12:31:58 2002 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 g2PKVv421572; Mon, 25 Mar 2002 12:31:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15406 Mon, 25 Mar 2002 14:56:58 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-Id: <200203251709.MAA16171@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Stephen Kent , Subject: Re: pre-shared key v RSA encryption or RSA signature authentication modes Date: Mon, 25 Mar 2002 12:06:28 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: References: <005001c1d355$786a7c50$1e72788a@ca.alcatel.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA14046 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Monday 25 March 2002 11:08, Stephen Kent wrote: > I'm glad you mentioned what I consider to be a significant downside > of pre-shared secrets, although we come to very different > conclusions. It is not too hard to imagine an attack in which the > initiator connects to the wrong address, e.g., via some form of DNS > attack, and the fake responder collects the initiator's secret, then > drops the connection. I thought this authentication method is YEARS gone? A-la HTTP Basic Authentication? Isn't practically everybody today using some form of challenge-response auth with pre-shared secrets? [real-life examples would be helpful.] -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon Mar 25 13:02:19 2002 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 g2PL2I423607; Mon, 25 Mar 2002 13:02:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15555 Mon, 25 Mar 2002 15:18:19 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Date: Mon, 25 Mar 2002 15:22:03 -0500 Message-ID: <002201c1d43a$bb9ffaa0$1e72788a@ca.alcatel.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 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm glad you mentioned what I consider to be a significant downside > of pre-shared secrets, although we come to very different > conclusions. It is not too hard to imagine an attack in which the > initiator connects to the wrong address, e.g., via some form of DNS > attack, and the fake responder collects the initiator's secret, then > drops the connection. This seems like such a serious concern that it > argues very strongly against pre-shared secrets vs. public keys. Note > that using public keys. e.g., in self-signed certs, does not suffer > from this problem. Steve, I don't understand your comment. Obviously, I'm only talking about IKE pre-shared secrets, in which the bogus responder only collects an HMAC of the shared secret and some session data. Now, which is harder: cracking an RSA key or reversing an HMAC? Again, it depends on the key lengths involved, but HMAC provides more security per bit. Your attack wouldn't work unless the initiator was using a weak secret that could be cracked by brute force. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Monday, March 25, 2002 11:08 AM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: pre-shared key v RSA encryption or RSA signature > authentication modes > > > At 12:00 PM -0500 3/24/02, Andrew Krywaniuk wrote: > >Ask a politically incorrect question like that on a list > like this and you > >are bound to get a lot of FUD-type replies. Of course PK > crypto has the > >advantage of scalability, but that's not the question you > asked. Some people > >replied already, but here's a more presise response. > > > >The fact is, you can get any arbitrary strength you want > with either asymm > >or symm algorithms by increasing the keylength. If you want > a basis for > >comparing their strengths, you could compare the speed of > the algorithms for > >equivalent crypto strength (which is not as silly as it > seems, since you are > >always trading off crypto strength for speed). In that case, > you could say > >that pre-shared secrets are stronger than public keys. (I > don't know of any > >fundamental difference between the strength of PK encryption and PK > >signatures for authentication. ) > > > >Also, pre-shared secrets have an additional advantage for > authentication, > >which is that you cannot mount a pure offline attack against > them. In order > >to get some data for a brute force attack, you must first > impersonate the > >responder in an active attack against the initiator. With > public keys, you > >can conduct a purely offline attack. Of course, the strength of the > >authentication will still be limited by the amount of > entropy in the secret. > > > >Andrew > From owner-ipsec@lists.tislabs.com Mon Mar 25 13:05:48 2002 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 g2PL5l423702; Mon, 25 Mar 2002 13:05:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15649 Mon, 25 Mar 2002 15:32:20 -0500 (EST) From: "sankar ramamoorthi" To: "Dan Harkins" , "Rajesh Mohan" Cc: "IP Security List" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Mon, 25 Mar 2002 12:44:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200203251859.g2PIxgK00752@fatty.lounge.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Monday, March 25, 2002 11:00 AM > To: Rajesh Mohan > Cc: IP Security List > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote > > > > We do not need no-TS feature if IKEv2 can solve all cases. Can > we configure > > IKEv2 such that between the same pair of host we have "ESP null > for H.323" > > and "ESP for FTP"? If the draft cannot cover this case, then > no-TS feature > > will be useful where it is needed. > > IKEv2 is not configured to express that, the SPD is. Can you configure the > SPD to express "ESP for FTP" or "ESP null for H.323"? If you can then that > representation in the SPD is passed to IKEv2 when a packet > matches that rule > and no SA exists. If you cannot then this is not an IKEv2 issue. Isn't SPD configuration a local matter? If so, the policy to represent the requirement 'ESP for FTP' or 'ESP null for H.323' can be expressed in any number of ways - even just as strings 'ESP for FTP' or 'ESP null for H.323'. However SA is negotiated and therefore need to be expressed in a more precise manner. I think the need to support dynamic protocols like H.323 is a geuine one or is it? It is more of a requirements issue. If we agree that ipsec SA should have granalurity to support such services as H.323 (which may have some selectors changing dynamically) then the above stated problem is an ikev2 issue. If we agree it is a genuine requirement, I would prefer a solution that maintains TS. -- sankar -- > > Dan. > From owner-ipsec@lists.tislabs.com Mon Mar 25 13:11:43 2002 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 g2PLBh423900; Mon, 25 Mar 2002 13:11:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15666 Mon, 25 Mar 2002 15:33:19 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'SatishK Amara'" Cc: Subject: RE: SKEYSEED in IKEv2 Date: Mon, 25 Mar 2002 15:37:00 -0500 Message-ID: <002401c1d43c$d1a25e90$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <20020324215256.35209.qmail@web21304.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Satish, The reason for not using a fixed key-id is that the key-id then becomes an "identity equivalent". So once the attacker figures out that u234352934=kumar_amara@yahoo.com, he can find out when you are logging on no matter what IP you use. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara Sent: Sunday, March 24, 2002 4:53 PM To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: SKEYSEED in IKEv2 Andrew, In IKEv2 I think identity protection can be provided by having an optional key-id field in message1 to identify the preshared key. If the optinal key-id field is present then the shared secret will be based on DH and preshared key. Any thoughts ... Andrew Krywaniuk wrote: > I am just wondering what is the reason for SKEYSEED in > IKEv2 is based on only Nounce and DH parameters. In IKEv1 it > is calculated differently depending upon preshared keys, > signatures or public key encryption. In case of preshared key > in IKEv1 by doing so we can protect the identities of both > parties from active attack. But this is not possible in IKEv2 ... Your assumption is incorrrect. In IKEv1, the preshared key mode contained a special optimization in order to make the key subjectively "better" (because the attacker could not derive the session key even if he could crack the DH -- he would also have to crack the preshared key). This is an additional security measure that it not present in the PK signatures mode of IKE. However, this feature has several drawbacks: - When using main mode, the identity of the intitiator must be implicit from the IP. - When the initiator is a roaming client, the identity must be sent in the clear (because it acts as an index for the key lookup). - When the preshared key is wrong, the responder cannot send a meaninful error message. So as you can see, contrary to your suggestion, this feature of IKEv1 actually makes identity protection quite impossible when using pre-shared keys, since the identity must either be sent on the wire or it must be implicit from the key. A third option is to use a global pre-shared key, in which you get the perverse situtation where you have identity protection but you can't trust the id because it is too easy to forge. If, for whatever reason, you absolutely need identity protection of the initiator against an active attack, your best bet would be to implement a private extension in which the id is changed on each successive login. For example, you could make a session-based id by hashing an unpredictable string together with a nonce or counter. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® From owner-ipsec@lists.tislabs.com Mon Mar 25 13:24:32 2002 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 g2PLOW424151; Mon, 25 Mar 2002 13:24:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15797 Mon, 25 Mar 2002 15:49:41 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: 1,342,532,544 combinations of algorithms Date: Mon, 25 Mar 2002 15:53:28 -0500 Message-ID: <002c01c1d43f$1e6d43f0$1e72788a@ca.alcatel.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 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the IETF and on this list, I have heard security experts complain about how many possible combinations of algorithms there are. This has never seemed like a big concern to me because most people would not implement every permutation of algorithms in a separate file (I say most people because I know at least one person who did, but they have been duly chastised). Does anyone have any examples of security failures that resulted from people using some previously untested combination of algorithms? Also, what type of bug was it? (If it's just a buffer overflow, then I think that's just symptomatic of bad coding overall.) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Monday, March 25, 2002 11:08 AM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: pre-shared key v RSA encryption or RSA signature > authentication modes > > > At 12:00 PM -0500 3/24/02, Andrew Krywaniuk wrote: > >Ask a politically incorrect question like that on a list > like this and you > >are bound to get a lot of FUD-type replies. Of course PK > crypto has the > >advantage of scalability, but that's not the question you > asked. Some people > >replied already, but here's a more presise response. > > > >The fact is, you can get any arbitrary strength you want > with either asymm > >or symm algorithms by increasing the keylength. If you want > a basis for > >comparing their strengths, you could compare the speed of > the algorithms for > >equivalent crypto strength (which is not as silly as it > seems, since you are > >always trading off crypto strength for speed). In that case, > you could say > >that pre-shared secrets are stronger than public keys. (I > don't know of any > >fundamental difference between the strength of PK encryption and PK > >signatures for authentication. ) > > > >Also, pre-shared secrets have an additional advantage for > authentication, > >which is that you cannot mount a pure offline attack against > them. In order > >to get some data for a brute force attack, you must first > impersonate the > >responder in an active attack against the initiator. With > public keys, you > >can conduct a purely offline attack. Of course, the strength of the > >authentication will still be limited by the amount of > entropy in the secret. > > > >Andrew > > I'm glad you mentioned what I consider to be a significant downside > of pre-shared secrets, although we come to very different > conclusions. It is not too hard to imagine an attack in which the > initiator connects to the wrong address, e.g., via some form of DNS > attack, and the fake responder collects the initiator's secret, then > drops the connection. This seems like such a serious concern that it > argues very strongly against pre-shared secrets vs. public keys. Note > that using public keys. e.g., in self-signed certs, does not suffer > from this problem. > > Steve > From owner-ipsec@lists.tislabs.com Mon Mar 25 14:14:10 2002 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 g2PMEA425475; Mon, 25 Mar 2002 14:14:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16148 Mon, 25 Mar 2002 16:35:35 -0500 (EST) Date: Mon, 25 Mar 2002 23:47:31 +0200 Message-Id: <200203252147.XAA23579@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <200203230414.g2N4ELU01017@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Fri, 22 Mar 2002 23:14:20 -0500) Subject: Re: Policy requirements in Son-Of-IKE References: <200203230414.g2N4ELU01017@marajade.sandelman.ottawa.on.ca> 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 > There are two ways that we can do with this. > 1) we can remove all policy from SOI. > 2) we can improve policy so that we can negotiate in SOI. Naturally I'm for (1) [with caveat, that "policy" appears to be understood differently by different implementors]. First, a repeat the fact: (1) If you implement RFC-2401, then (2) there is no need for any policy checks in key negotiation, it can accept any proposed SA, if it can do the proposed algorithms and the protocol (AH, ESP or IPCOMP). However, this does not imply that TS (or something like it), is not required. Key negotiation must include some qualifiers for the SA. If there are none, then each host pair can have only one SA pair between them. Say we have policies on host A (and equivalent policy on host B): remote=X, protocol=UDP -> SA1: ESP(3DES,SHA1) remote=X, protocol=ICMP -> SA2: ESP(3DES,SHA1) If both SA's are negotiated from A, without any TS-like information, the host B can not have any idea which SA is to be associated with UDP and which with ICMP (and thus cannot check the policy as required by RFC-2401). Thus, TS-like thing is required. The open question is: what gets included. I'm quite happy with the original RFC-2401 set of capabilies. Do we really need anything more complex? - protocol (wild or specific) - local port (wild or specific) - remote port (wild or specific) Then for tunnel mode, I'm a bit uncertain. Should it be possiblie to "granularize" SA with two subnets if SA is between two SG's Subnet A -- SG ----- SG --- Subnet C / \ Subnet B --+ +-- Subnet D e.g is it necessary, for example, to be able to specify 4 distinct SA's between SG's? SA1 (A,C) SA2 (A,D) SA3 (B,C) SA4 (B,D) If so, then we need both local and remote "proxy" infomation for SA. Proxy information is one of any/none, specific address, subnet or address range? HOWEVER: Whatever is defined for the parameter that granularises SA, then *EVERYONE* must implement this set. There cannot be any optional variations. ------------------ IKEv1 negotiated implicitly another symmetric SA, by just assuming that policies are symmetric. This is rather ugly assumption. I would prefer a definite solution as follows: Additional optional payload is added, which contain the relevant selector values from the packet that triggered the negotiation (note: TS does not have enough information, when it has wild cards and ranges). The presense of this payload indicates that the other side can negotiate additional SA to the other direction (and this payload makes it actually possible, even if policies are not symmetric!). From owner-ipsec@lists.tislabs.com Mon Mar 25 14:26:26 2002 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 g2PMQP426160; Mon, 25 Mar 2002 14:26:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16256 Mon, 25 Mar 2002 16:49:27 -0500 (EST) Message-Id: <200203252158.g2PLwhK01048@fatty.lounge.org> To: Michael Choung Shieh Cc: Rajesh Mohan , IP Security List Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Mon, 25 Mar 2002 11:54:18 PST." <9D048F4A422CD411A56500B0D0209C5B028F3DD5@NS-CA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1045.1017093523.1@tibernian.com> Date: Mon, 25 Mar 2002 13:58:43 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The SPD is an ordered list of selectors that define a set of IP traffic to which a particular security policy is applied. RFC2401 is specific about what a selector is. Can you define "FTP" or "H.323" using a ordered list of RFC2401-defined selectors? If so please tell me how. If not then please tell me why you think IKEv2 should be able to express something that you are not able to configure in the first place? Dan. On Mon, 25 Mar 2002 11:54:18 PST you wrote > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > Sent: Monday, March 25, 2002 11:00 AM > > To: Rajesh Mohan > > Cc: IP Security List > > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote > > > > > > We do not need no-TS feature if IKEv2 can solve all cases. > > Can we configure > > > IKEv2 such that between the same pair of host we have "ESP > > null for H.323" > > > and "ESP for FTP"? If the draft cannot cover this case, > > then no-TS feature > > > will be useful where it is needed. > > > > IKEv2 is not configured to express that, the SPD is. Can you > > configure the > > SPD to express "ESP for FTP" or "ESP null for H.323"? If you > > can then that > > representation in the SPD is passed to IKEv2 when a packet > > matches that rule > > and no SA exists. If you cannot then this is not an IKEv2 issue. > > > > Dan. > > > > It IS an IKEv2 issue when SPD is converted to TS and TS is used in IKEv2. > Everyone MUST have a standard way to say what is "FTP" or "H323". The > representation of SPD and the conversion of SPD to TS must be standardized > to achieve IKE interoperability. > > Michael Shieh From owner-ipsec@lists.tislabs.com Mon Mar 25 14:37:31 2002 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 g2PMbV426423; Mon, 25 Mar 2002 14:37:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16375 Mon, 25 Mar 2002 17:03:18 -0500 (EST) Message-ID: <046501c1d44a$d1a31980$34c02ca1@cisco.com> From: "Stephane Beaulieu" To: , References: <002c01c1d43f$1e6d43f0$1e72788a@ca.alcatel.com> Subject: Re: 1,342,532,544 combinations of algorithms Date: Mon, 25 Mar 2002 17:17:14 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > At the IETF and on this list, I have heard security experts complain about > how many possible combinations of algorithms there are. This has never > seemed like a big concern to me because most people would not implement > every permutation of algorithms in a separate file (I say most people > because I know at least one person who did, but they have been duly > chastised). > > Does anyone have any examples of security failures that resulted from people > using some previously untested combination of algorithms? Also, what type of > bug was it? (If it's just a buffer overflow, then I think that's just > symptomatic of bad coding overall.) I personally don't buy the complexity argument (but then again... it appears I never do :). I think the desire to reduce the permutations stems more from a testing (box (and not module) testing that is). However, I think as long as we focus on testing the MUSTS (AES, 3DES, SHA, MD5), then the testing matrix becomes much smaller. Even more so, if you remove AH. Regardless of how SOI negotiates the algorithms, they'll still be implemented the same modularity they have today (at least hopefully). After all, a good implementor knows that in order to build a complex system you're better off to design small abstract modules that are easy to test individually rather than the large AH-MD5_ESP-3DES-SHA1_IPCOMP-LZS_TRANSPORT_MODE.c module. Whether we should negotiate them as modules, or suites is a different issue, but modularity is always easier to build on.... > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > > Sent: Monday, March 25, 2002 11:08 AM > > To: andrew.krywaniuk@alcatel.com > > Cc: ipsec@lists.tislabs.com > > Subject: RE: pre-shared key v RSA encryption or RSA signature > > authentication modes > > > > > > At 12:00 PM -0500 3/24/02, Andrew Krywaniuk wrote: > > >Ask a politically incorrect question like that on a list > > like this and you > > >are bound to get a lot of FUD-type replies. Of course PK > > crypto has the > > >advantage of scalability, but that's not the question you > > asked. Some people > > >replied already, but here's a more presise response. > > > > > >The fact is, you can get any arbitrary strength you want > > with either asymm > > >or symm algorithms by increasing the keylength. If you want > > a basis for > > >comparing their strengths, you could compare the speed of > > the algorithms for > > >equivalent crypto strength (which is not as silly as it > > seems, since you are > > >always trading off crypto strength for speed). In that case, > > you could say > > >that pre-shared secrets are stronger than public keys. (I > > don't know of any > > >fundamental difference between the strength of PK encryption and PK > > >signatures for authentication. ) > > > > > >Also, pre-shared secrets have an additional advantage for > > authentication, > > >which is that you cannot mount a pure offline attack against > > them. In order > > >to get some data for a brute force attack, you must first > > impersonate the > > >responder in an active attack against the initiator. With > > public keys, you > > >can conduct a purely offline attack. Of course, the strength of the > > >authentication will still be limited by the amount of > > entropy in the secret. > > > > > >Andrew > > > > I'm glad you mentioned what I consider to be a significant downside > > of pre-shared secrets, although we come to very different > > conclusions. It is not too hard to imagine an attack in which the > > initiator connects to the wrong address, e.g., via some form of DNS > > attack, and the fake responder collects the initiator's secret, then > > drops the connection. This seems like such a serious concern that it > > argues very strongly against pre-shared secrets vs. public keys. Note > > that using public keys. e.g., in self-signed certs, does not suffer > > from this problem. > > > > Steve > > > From owner-ipsec@lists.tislabs.com Mon Mar 25 15:07:29 2002 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 g2PN7T427182; Mon, 25 Mar 2002 15:07:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16574 Mon, 25 Mar 2002 17:33:05 -0500 (EST) Message-ID: <3C9FA89A.2C9B0461@sonicwall.com> Date: Mon, 25 Mar 2002 14:45:46 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: uri@bell-labs.com, ipsec@lists.tislabs.com Subject: Re: pre-shared key v RSA encryption or RSA signatureauthentication modes References: <005001c1d355$786a7c50$1e72788a@ca.alcatel.com> <200203251709.MAA16171@nwmail.wh.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2002 22:45:46.0740 (UTC) FILETIME=[CDBDF340:01C1D44E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Comments below... Stephen Kent wrote: > > At 12:06 PM -0500 3/25/02, Uri Blumenthal wrote: > >On Monday 25 March 2002 11:08, Stephen Kent wrote: > >> I'm glad you mentioned what I consider to be a significant downside > >> of pre-shared secrets, although we come to very different > >> conclusions. It is not too hard to imagine an attack in which the > >> initiator connects to the wrong address, e.g., via some form of DNS > >> attack, and the fake responder collects the initiator's secret, then > >> drops the connection. > > > >I thought this authentication method is YEARS gone? A-la HTTP Basic > >Authentication? > > > >Isn't practically everybody today using some form of challenge-response > >auth with pre-shared secrets? [real-life examples would be helpful.] > >-- > > There have been messages posted to the list that suggest otherwise, > but it would be useful to get some data points. > > Steve There are (at least) two answers to this, depending on the scenario being discussed. For remote access, there are many deployments which use pre-shared secrets and a challenge-rsp together (a la xauth). Note that these psk's are often (though not necessarily) shared among multiple users, with some sort of "key id" being used to select the appropriate psk at the sgw. It has been long recognized by the ipsec community that this is insecure, yet there are some deployments using this mechanism. Regarding the use of pre-shared secrets for site-to-site VPN's where both SGW's have fixed IP addresses, I know of a significant number of deployments which rely upon this mechanism, rather than certificates. In these cases, no challenge/rsp is used. However, there is typically a unique PSK for each SGW pair. Scott From owner-ipsec@lists.tislabs.com Mon Mar 25 15:09:42 2002 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 g2PN9f427372; Mon, 25 Mar 2002 15:09:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16615 Mon, 25 Mar 2002 17:35:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15519.43238.200000.467846@gargle.gargle.HOWL> Date: Mon, 25 Mar 2002 17:47:02 -0500 From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: Re: 1,342,532,544 combinations of algorithms References: <002c01c1d43f$1e6d43f0$1e72788a@ca.alcatel.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 25 March 2002) by Andrew Krywaniuk: > At the IETF and on this list, I have heard security experts complain about > how many possible combinations of algorithms there are. This has never > seemed like a big concern to me because most people would not implement > every permutation of algorithms in a separate file (I say most people > because I know at least one person who did, but they have been duly > chastised). I guess this is surprising to some, but there are legitimate reasons for implementing each permutation separately. If you are doing a very highly optimized software implementation, one thing you'd want to do is make only a single pass over the buffer. The other thing you may want to do is to avoid function call overhead. If you combine these two goals, you end up with code that looks like this: for (;;) { // fetch some more bytes // feed them to the encryption transform // feed them to the authentication transform } and you have one of these for each encrypt/auth transform pair that you support. For sensible implementations, that number isn't very large (null/DES/3DES times MD5/SHA1). If you started adding lots of other transforms, this would definitely get ugly. And yes, I realize that the function call overhead may be trivial compared to the overhead of DES, so arguably this coding style is taking things too far... paul From owner-ipsec@lists.tislabs.com Mon Mar 25 16:06:38 2002 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 g2Q06c429008; Mon, 25 Mar 2002 16:06:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16994 Mon, 25 Mar 2002 18:31:10 -0500 (EST) Date: Mon, 25 Mar 2002 15:42:35 -0800 (PST) From: Jan Vilhuber To: Michael Richardson cc: Subject: Re: Policy requirements in Son-Of-IKE In-Reply-To: <200203230414.g2N4ELU01017@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, 22 Mar 2002, Michael Richardson wrote: > > IKEv1 is a policy agreement protocol. It does not negotiate. > > There are two ways that we can do with this. > 1) we can remove all policy from SOI. > 2) we can improve policy so that we can negotiate in SOI. > > There are good arguments for both paths. I strongly believe that we must > decide this very soon. > > If we go with path #1, then we must have a policy discovery and agreement > protocol. This was supposed to be solved by IPSP WG, but IPSP got forced into > doing this Policy Schema/PIB stuff. IPSP is only now starting on this. If the > IPSEC WG wants to go route #1, then we MUST complete the IPSP WG on the same > schedule. IPSRA work will have to be redone as well. > > (The PIB stuff doesn't help at all for inter-domain stuff, and I do not think > it even helps for road-warrior/gateway. Maybe I'm wrong. ) > > If we go with path #2, then we need policy negotiation in SOI. At the last IETF, Pyda Srisuresh presented a draft he wrote (and I contributed to) in the IPSP working group. We tried to float this in the IPsec WG as well, I believe. It seems neither group was interested. I've placed the expired draft here, in case anyone's interested: http://www.employees.org/~vilhuber/draft-srisuresh-ike-policy-extensions-01.txt I don't think it's QUITE what you're looking for, but maybe there's some decent ideas there we can incorporate at some point. jan > I'm not > convinced that this will be rich enough to do the kinds of things that SPP > could do, but it MUST at least satisfy the VPN, remote access needs. It is > likely that it will satisfy Opportunistic Encryption needs as well. > > A method to deal with protocols like FTP (i.e. IRC, H323, SIP/AVP, etc.) > should be included in the requirements. > > (Some gateway discovery protocol like SPP, TED, etc. will still have > value. A different form of OE can also be created with this kind of thing) > > Again, we have to decide on the path to take. This is not a debate about > the proposals - it is clear to me that the protocol folks will cope. > > Cheryl's 01 draft suggests improving policy (#2). > > I think that most of the WG is siding with this. Not all. > It would helpful if those who are in favour of #1 would: > 1) write drafts (not emails) explaining their view of the world. > > 2) review the scenarios in the SOI requirements draft and explain how > these things can be done. > > 3) join and help review the IPSP work. > > > ] 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"); [ > > > > PS: I'm a bit upset that any time was spent on presentations on Thursday > morning. We should have spent the high bandwidth time in the small room > on discussion about these things. > > I guess I should have read the agenda with more thought and objected to it. > I wonder if an official interim meeting in late April would have value. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Mar 25 16:28:44 2002 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 g2Q0Si429599; Mon, 25 Mar 2002 16:28:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17148 Mon, 25 Mar 2002 18:49:59 -0500 (EST) Date: Mon, 25 Mar 2002 19:01:04 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv 2) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Reference correction: I said draft-richardson-ipsec-opportunistic-03.txt, that should have been -06. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 16:38:38 2002 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 g2Q0cc429773; Mon, 25 Mar 2002 16:38:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17179 Mon, 25 Mar 2002 18:55:39 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3DD9@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" Cc: IP Security List Subject: RE: opportunistic (was RE: Don't remove TS from IKEv2) Date: Mon, 25 Mar 2002 16:06:03 -0800 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 comments inline. > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 25, 2002 11:29 AM > To: Michael Choung Shieh > Cc: IP Security List > Subject: opportunistic (was RE: Don't remove TS from IKEv2) > > > On Mon, 25 Mar 2002, Michael Choung Shieh wrote: > > It seems to me the model of "Opportunistic Encryption" is > only applicable to > > client-server, not peer-to-peer scenario. > > Why? Please explain. The words "client" and "server" do not > appear in > the spec, last I looked, and it certainly works peer-to-peer -- we're > using it that way experimentally. > Ok. It's my misunderstanding. > > It also has blackhole problem > > when data traffic is initiated from server side. > > Why? Please explain. The protocol is symmetrical; there is > no "client" > or "server" distinction made. > If initiator's policy is from/to <10.0.0.0/24> and responder's policy is from/to <10.0.0.0/16>. IKE will succeed but traffic from 10.0.1.1 (behind responder) will be dropped. > > The other problem is, under client server scenario, usually > server is > > protecting more valuable information so it has stricter SPD > than clients. > > How is this relevant? Opportunistic encryption is intended to protect > communication that now goes out in cleartext; it is *not* just another > kind of VPN. There is no particular trust relationship > between the two ends, I see. It's a different problem domain. > and no reason why an incoming packet over an OE tunnel is trusted > any more than a packet which arrives from the rest of the Internet. > Information which is protected from general Internet access should be > protected from access via OE tunnels too. > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Mar 25 16:53:59 2002 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 g2Q0rw400186; Mon, 25 Mar 2002 16:53:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17360 Mon, 25 Mar 2002 19:21:28 -0500 (EST) Message-Id: <200203260031.g2Q0Vuss007100@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Koning cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: 1,342,532,544 combinations of algorithms In-Reply-To: Your message of "Mon, 25 Mar 2002 17:47:02 EST." <15519.43238.200000.467846@gargle.gargle.HOWL> Reply-to: sommerfeld@east.sun.com Date: Mon, 25 Mar 2002 19:31:56 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > And yes, I realize that the function call overhead may be trivial > compared to the overhead of DES, so arguably this coding style is > taking things too far... When I've gone down this particular rathole, I've found that optimizations of this form make a bigger difference than you might expect at first, particularly if you want to squeeze the last 5% or 10% of performance out of a system. Some of it may come down to "memory is slow" issues. In one case, at a previous job, eliminating a data copy and tuning up the byte swaps in an md5 implementation on a big-endian risc system made a noticeable improvement in performance. [Upon arrival at my current job, I discovered my new coworkers had discovered the same thing independantly.] - Bill From owner-ipsec@lists.tislabs.com Mon Mar 25 17:14:29 2002 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 g2Q1ET400678; Mon, 25 Mar 2002 17:14:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17464 Mon, 25 Mar 2002 19:34:27 -0500 (EST) Message-Id: <200203260044.g2Q0itss007239@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: Don't remove TS from IKEv2 In-Reply-To: Your message of "Fri, 22 Mar 2002 14:35:36 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 25 Mar 2002 19:44:55 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The IPsec "SPD" is rather poorly named. It's a distinctly low-level > concept, precisely dictating details of packet handling. In some > implementations (such as FreeS/WAN), the SPD is dynamic, not static, with > SPD entries set up and torn down as tunnels come and go, based on IKE > negotiations constrained by policy specifications at a much higher level > of abstraction. So, here's where our implementation differs. Our SPD is somewhat more flexible, allowing a single policy rule to specify multiple alternatives. It's not dynamic. When we set up SA's, we verify that the SA matches something in the SPD but we don't modify the SPD at that time. Instead, we have an additional concept of "policy latching" -- we lock down the SA attributes used at the time a transport connection is established. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 25 18:38:18 2002 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 g2Q2cI402563; Mon, 25 Mar 2002 18:38:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18170 Mon, 25 Mar 2002 21:04:19 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Mon, 25 Mar 2002 19:42:34 -0500 Message-ID: <001201c1d45f$1f3f7a80$1e72788a@ca.alcatel.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 In-reply-to: <200203252158.g2PLwhK01048@fatty.lounge.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I remember it, Jan and Pyda's draft does suggest that you can add these as dynamic SPD rules after you know the eventual port number. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Monday, March 25, 2002 4:59 PM > To: Michael Choung Shieh > Cc: Rajesh Mohan; IP Security List > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > The SPD is an ordered list of selectors that define a set > of IP traffic > to which a particular security policy is applied. RFC2401 is specific > about what a selector is. Can you define "FTP" or "H.323" > using a ordered > list of RFC2401-defined selectors? If so please tell me how. > If not then > please tell me why you think IKEv2 should be able to express something > that you are not able to configure in the first place? > > Dan. > > On Mon, 25 Mar 2002 11:54:18 PST you wrote > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > > Sent: Monday, March 25, 2002 11:00 AM > > > To: Rajesh Mohan > > > Cc: IP Security List > > > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote > > > > > > > > We do not need no-TS feature if IKEv2 can solve all cases. > > > Can we configure > > > > IKEv2 such that between the same pair of host we have "ESP > > > null for H.323" > > > > and "ESP for FTP"? If the draft cannot cover this case, > > > then no-TS feature > > > > will be useful where it is needed. > > > > > > IKEv2 is not configured to express that, the SPD is. Can you > > > configure the > > > SPD to express "ESP for FTP" or "ESP null for H.323"? If you > > > can then that > > > representation in the SPD is passed to IKEv2 when a packet > > > matches that rule > > > and no SA exists. If you cannot then this is not an IKEv2 issue. > > > > > > Dan. > > > > > > > It IS an IKEv2 issue when SPD is converted to TS and TS is > used in IKEv2. > > Everyone MUST have a standard way to say what is "FTP" or > "H323". The > > representation of SPD and the conversion of SPD to TS must > be standardized > > to achieve IKE interoperability. > > > > Michael Shieh > From owner-ipsec@lists.tislabs.com Mon Mar 25 18:38:22 2002 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 g2Q2cL402575; Mon, 25 Mar 2002 18:38:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18127 Mon, 25 Mar 2002 21:00:12 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Koning'" Cc: Subject: RE: 1,342,532,544 combinations of algorithms Date: Mon, 25 Mar 2002 19:21:56 -0500 Message-ID: <001101c1d45c$3e491060$1e72788a@ca.alcatel.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 In-reply-to: <15519.43238.200000.467846@gargle.gargle.HOWL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > and you have one of these for each encrypt/auth transform pair that > you support. For sensible implementations, that number isn't very > large (null/DES/3DES times MD5/SHA1). If you started adding lots of > other transforms, this would definitely get ugly. Yes, that is a legitimate reason for combining the encrypt + auth operations into a single file. But obviously, you would want to have a very limited number of these, and any other permutation of algorithms would hit the fall-though case. (In the case I mentioned before, the programmer decided to implement *EVERY* permutation of algorithms/modes as a separate file.) But I think the motivation of the 1,342,532,544 combinations of algorithms complaint is that many of these combinations will never be tested. If you implement 4 specific combinations of algorithms as optimized cases then presumably you will test these permutations very thoroughly. But how many of the other 1,342,532,540 combinations do you have to test in order to be confident that the generic case is working correctly? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com] > Sent: Monday, March 25, 2002 5:47 PM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: Re: 1,342,532,544 combinations of algorithms > > > Excerpt of message (sent 25 March 2002) by Andrew Krywaniuk: > > At the IETF and on this list, I have heard security experts > complain about > > how many possible combinations of algorithms there are. > This has never > > seemed like a big concern to me because most people would > not implement > > every permutation of algorithms in a separate file (I say > most people > > because I know at least one person who did, but they have been duly > > chastised). > > I guess this is surprising to some, but there are legitimate reasons > for implementing each permutation separately. > > If you are doing a very highly optimized software implementation, one > thing you'd want to do is make only a single pass over the buffer. > The other thing you may want to do is to avoid function call overhead. > > If you combine these two goals, you end up with code that looks like > this: > for (;;) > { > // fetch some more bytes > // feed them to the encryption transform > // feed them to the authentication transform > } > and you have one of these for each encrypt/auth transform pair that > you support. For sensible implementations, that number isn't very > large (null/DES/3DES times MD5/SHA1). If you started adding lots of > other transforms, this would definitely get ugly. > > And yes, I realize that the function call overhead may be trivial > compared to the overhead of DES, so arguably this coding style is > taking things too far... > > paul > From owner-ipsec@lists.tislabs.com Mon Mar 25 19:46:31 2002 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 g2Q3kV404081; Mon, 25 Mar 2002 19:46:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18612 Mon, 25 Mar 2002 22:09:15 -0500 (EST) Date: Mon, 25 Mar 2002 22:20:29 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: IP Security List Subject: RE: opportunistic (was RE: Don't remove TS from IKEv2) In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3DD9@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 25 Mar 2002, Michael Choung Shieh wrote: > > > It also has blackhole problem > > > when data traffic is initiated from server side. > > Why? Please explain. The protocol is symmetrical... > > If initiator's policy is from/to <10.0.0.0/24> and responder's policy > is from/to <10.0.0.0/16>. IKE will succeed... Uh, no it won't, because of the much-despised traffic selectors (or rather their IKEv1 equivalents). OE negotiates a tunnel for the exact hosts that will be communicating, so no mismatch is possible, assuming that both ends are actually checking to make sure that what's requested is allowed. Oh, and in the absence of special arrangements, OE doesn't work for private addresses, since they won't have public DNS entries. OE is not, repeat *not*, repeat *NOT*, just another way to do VPNs. It's for public networks, not private networks. IPsec is not just VPNs. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 25 19:49:45 2002 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 g2Q3ni404142; Mon, 25 Mar 2002 19:49:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18681 Mon, 25 Mar 2002 22:18:34 -0500 (EST) Date: Mon, 25 Mar 2002 19:30:00 -0800 (PST) From: Jan Vilhuber To: Andrew Krywaniuk cc: "'Dan Harkins'" , "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: <001201c1d45f$1f3f7a80$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I posted a link to it earlier. It's worth noting that during the presenation Pyda presented two different ways that the policy could get updated on both ends: - In IKE (which is what the draft talks about), but changing IKE is BAD. - In some as yet unspecified IPSP protocol (and we again have the problem that someone else pointed out: that doesn't exist yet :) So as each endpoint learns new policy (a new dynamic port), it *somehow* (i.e. via IKE or an external protocol) tells the other end to add or remove policy from the SA. A pre-cursor to this draft (that I was hashing out with some l2tp folks) had speculated on using specifiers like 'L2TP' or 'FTP' or "H.323" (IANA assigned, of course ;) in IKE. That's essentially the same thing as in the draft though, except the draft is more general. Note that this mechanism would really require a 2-phase protocol. I really wouldn't want to do an RSA calculation each time we have to add or delete policy from our SA... jan On Mon, 25 Mar 2002, Andrew Krywaniuk wrote: > As I remember it, Jan and Pyda's draft does suggest that you can add these > as dynamic SPD rules after you know the eventual port number. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > Sent: Monday, March 25, 2002 4:59 PM > > To: Michael Choung Shieh > > Cc: Rajesh Mohan; IP Security List > > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > The SPD is an ordered list of selectors that define a set > > of IP traffic > > to which a particular security policy is applied. RFC2401 is specific > > about what a selector is. Can you define "FTP" or "H.323" > > using a ordered > > list of RFC2401-defined selectors? If so please tell me how. > > If not then > > please tell me why you think IKEv2 should be able to express something > > that you are not able to configure in the first place? > > > > Dan. > > > > On Mon, 25 Mar 2002 11:54:18 PST you wrote > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > > > Sent: Monday, March 25, 2002 11:00 AM > > > > To: Rajesh Mohan > > > > Cc: IP Security List > > > > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > > > > > > > On Fri, 22 Mar 2002 18:01:10 PST you wrote > > > > > > > > > > We do not need no-TS feature if IKEv2 can solve all cases. > > > > Can we configure > > > > > IKEv2 such that between the same pair of host we have "ESP > > > > null for H.323" > > > > > and "ESP for FTP"? If the draft cannot cover this case, > > > > then no-TS feature > > > > > will be useful where it is needed. > > > > > > > > IKEv2 is not configured to express that, the SPD is. Can you > > > > configure the > > > > SPD to express "ESP for FTP" or "ESP null for H.323"? If you > > > > can then that > > > > representation in the SPD is passed to IKEv2 when a packet > > > > matches that rule > > > > and no SA exists. If you cannot then this is not an IKEv2 issue. > > > > > > > > Dan. > > > > > > > > > > It IS an IKEv2 issue when SPD is converted to TS and TS is > > used in IKEv2. > > > Everyone MUST have a standard way to say what is "FTP" or > > "H323". The > > > representation of SPD and the conversion of SPD to TS must > > be standardized > > > to achieve IKE interoperability. > > > > > > Michael Shieh > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 06:26:20 2002 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 g2QEQJ424656; Tue, 26 Mar 2002 06:26:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22153 Tue, 26 Mar 2002 08:29:35 -0500 (EST) From: haowell@263.net MIME-Version: 1.0 Message-ID: <3CA012CD.000018.19114@mta3> Date: Tue, 26 Mar 2002 14:18:53 +0800 (CST) To: ipsec@lists.tislabs.com Subject: =?gb2312?B?aXBzZWMgcnVubmluZyBidXQgcGx1dG8gJiBLTElQUyBub3QgcnVubmluZw==?= X-Priority: 3 X-Originating-IP: [202.104.108.163] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear list: I have some problem as following: #ipsec setup --status IPSec running but... no Pluto running! KLIPS module is not loaded! #ipsec whack --status whack: Pluto is not running (no "/var/run/pluto.ctl") what should i do to make it running correct? From owner-ipsec@lists.tislabs.com Tue Mar 26 09:31:46 2002 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 g2QHVj407492; Tue, 26 Mar 2002 09:31:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23094 Tue, 26 Mar 2002 11:30:40 -0500 (EST) Message-ID: <20020326164237.11685.qmail@web21310.mail.yahoo.com> Date: Tue, 26 Mar 2002 08:42:37 -0800 (PST) From: SatishK Amara Subject: RE: SKEYSEED in IKEv2 To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com In-Reply-To: <000401c1d44c$e60513e0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-949951596-1017160957=:9942" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-949951596-1017160957=:9942 Content-Type: text/plain; charset=us-ascii Hi Andew, The binding may not be implicit in all cases. Please refer the attached document. The preshared key is generated in distributed way. Alice identity is known to keying agent (AAA) and she was given preshared key. Bob doesn't know what is Alice preshared key but he can generate it based on key-id. In that case I think it is necessary to send Alice identity ... Satish Andrew Krywaniuk wrote: Hi Satish, I read Appendix A of the spec you sent me. Yes, you are correct that you can guard against an active attack to obtain the initiator's identity if you use a frequently chaning key_id. I didn't mention this before, because most people who have talked about using the key_id in the past were advocating a static key_id. You are correct that IKEv2 does not address this issue, but if you want to be resistant to this attack then maybe what you should do is to just not have the initiator send the identity at all, since it should be implicit from the key_id (and the responder is supposed to know what the binding is). Andrew------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. -----Original Message----- From: SatishK Amara [mailto:kumar_amara@yahoo.com] Sent: Monday, March 25, 2002 5:02 PM To: andrew.krywaniuk@alcatel.com Subject: RE: SKEYSEED in IKEv2 Andrew, Please find the attachment for 3GPP2 Wireless IP Standard. The standard proposes a method to dynamically configure preshared keys and use key-id to identify the preshared key. The preshared key will be changed freqently and so key-id .... Satish Andrew Krywaniuk wrote: Satish, The reason for not using a fixed key-id is that the key-id then becomes an "identity equivalent". So once the attacker figures out that u234352934=kumar_amara@yahoo.com, he can find out when you are logging on no matter what IP you use. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara Sent: Sunday, March 24, 2002 4:53 PM To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: SKEYSEED in IKEv2 Andrew, In IKEv2 I think identity protection can be provided by having an optional key-id field in message1 to identify the presha! red key. If the optinal key-id fie ld is present then the shared secret will be based on DH and preshared key. Any thoughts ... Andrew Krywaniuk wrote: > I am just wondering what is the reason for SKEYSEED in > IKEv2 is based on only Nounce and DH parameters. In IKEv1 it > is calculated differently depending upon preshared keys, > signatures or public key encryption. In case of preshared key > in IKEv1 by doing so we can protect the identities of both > parties from active attack. But this is not possible in IKEv2 ... Your assumption is incorrrect. In IKEv1, the preshared key mode contained a special optimization in order to make the key subjectively "better" (because the attacker could not derive the session key even if he could crack the DH -- he would also have to crack the preshared key). This is an additional security measure that it not present in the PK signatures mode of IKE. However, this f! eature has several drawbacks: < BR>- When using main mode, the identity of the intitiator must be implicit from the IP. - When the initiator is a roaming client, the identity must be sent in the clear (because it acts as an index for the key lookup). - When the preshared key is wrong, the responder cannot send a meaninful error message. So as you can see, contrary to your suggestion, this feature of IKEv1 actually makes identity protection quite impossible when using pre-shared keys, since the identity must either be sent on the wire or it must be implicit from the key. A third option is to use a global pre-shared key, in which you get the perverse situtation where you have identity protection but you can't trust the id because it is too easy to forge. If, for whatever reason, you absolutely need identity protection of the initiator against an active attack, your best bet would be to implement a private extension in which the id is changed on each successiv! e login. For example, you could make a session-based id by hashing an unpredictable string together with a nonce or counter. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-949951596-1017160957=:9942 Content-Type: text/html; charset=us-ascii

Hi Andew,

The binding may not be implicit in all cases. Please refer the attached document. The preshared key is generated in distributed way. Alice identity is known to keying agent (AAA) and she was given preshared key. Bob doesn't know what is Alice preshared key but he can generate it based on key-id. In that case I think it is necessary to send Alice identity ...

Satish

  Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> wrote:

Hi Satish,
 
I read Appendix A of the spec you sent me. Yes, you are correct that you can guard against an active attack to obtain the initiator's identity if you use a frequently chaning key_id. I didn't mention this before, because most people who have talked about using the key_id in the past were advocating a static key_id.
 
You are correct that IKEv2 does not address this issue, but if you want to be resistant to this attack then maybe what you should do is to just not have the initiator send the identity at all, since it should be implicit from the key_id (and the responder is supposed to know what the binding is).
 
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
 
-----Original Message-----
From: SatishK Amara [mailto:kumar_amara@yahoo.com]
Sent: Monday, March 25, 2002 5:02 PM
To: andrew.krywaniuk@alcatel.com
Subject: RE: SKEYSEED in IKEv2

Andrew,

       Please find the attachment for 3GPP2 Wireless IP Standard. The standard proposes a method to dynamically configure preshared keys and use key-id to identify the preshared key. The preshared key will be changed freqently and so key-id ....

Satish

  Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> wrote:

Satish,

The reason for not using a fixed key-id is that the key-id then becomes an
"identity equivalent". So once the attacker figures out that
u234352934=kumar_amara@yahoo.com, he can find out when you are logging on no
matter what IP you use.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On
Behalf Of SatishK Amara
Sent: Sunday, March 24, 2002 4:53 PM
To: andrew.krywaniuk@alcatel.com
Cc: ipsec@lists.tislabs.com
Subject: RE: SKEYSEED in IKEv2


Andrew,
In IKEv2 I think identity protection can be provided by having an optional
key-id field in
message1 to identify the presha! ! red key. If the optinal key-id fie ld is
present then the
shared secret will be based on DH and preshared key. Any thoughts ...

Andrew Krywaniuk wrote:
> I am just wondering what is the reason for SKEYSEED in
> IKEv2 is based on only Nounce and DH parameters. In IKEv1 it
> is calculated differently depending upon preshared keys,
> signatures or public key encryption. In case of preshared key
> in IKEv1 by doing so we can protect the identities of both
> parties from active attack. But this is not possible in IKEv2 ...

Your assumption is incorrrect.

In IKEv1, the preshared key mode contained a special optimization in order
to make the key subjectively "better" (because the attacker could not derive
the session key even if he could crack the DH -- he would also have to crack
the preshared key). This is an additional security measure that it not
present in the PK signatures mo! de of IKE.

However, this f! eature has several drawbacks:
< BR>- When using main mode, the identity of the intitiator must be implicit from
the IP.
- When the initiator is a roaming client, the identity must be sent in the
clear (because it acts as an index for the key lookup).
- When the preshared key is wrong, the responder cannot send a meaninful
error message.

So as you can see, contrary to your suggestion, this feature of IKEv1
actually makes identity protection quite impossible when using pre-shared
keys, since the identity must either be sent on the wire or it must be
implicit from the key. A third option is to use a global pre-shared key, in
which you get the perverse situtation where you have identity protection but
you can't trust the id because it is too easy to forge.

If, for whatever reason, you absolutely need identity protection of the
initiator against an active attack, your best bet would be to imp! lement a
private extension in which the id is changed on each successiv! e login. For
example, you could make a session-based id by hashing an unpredictable
string together with a nonce or counter.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.






Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-949951596-1017160957=:9942-- From owner-ipsec@lists.tislabs.com Tue Mar 26 11:04:07 2002 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 g2QJ46413374; Tue, 26 Mar 2002 11:04:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23571 Tue, 26 Mar 2002 13:00:01 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 26 Mar 2002 13:07:16 -0500 From: "Mike Farnham" To: Subject: New Member Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA23568 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all - First off, I am new to the list. My name is Mike Farnham and I work in the ISD/Network Services division for a local county Government in Florida. We're working with the Shiva Lanrover and I want to ask if there are any good resources for using IPSec with the Shiva ? I have been searching all over the place, but thought this might be a good place to really get some useful information. Thanks in advance. Mike Mike Farnham - CNM / DCT ISD - Network Services Manatee County Government - http://www.co.manatee.fl.us 1112 Manatee Avenue West (941) 749-3075 Fax (941) 749-3086 mike.farnham@co.manatee.fl.us From owner-ipsec@lists.tislabs.com Tue Mar 26 11:05:32 2002 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 g2QJ5W413420; Tue, 26 Mar 2002 11:05:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23707 Tue, 26 Mar 2002 13:28:55 -0500 (EST) From: "sankar ramamoorthi" To: "Jan Vilhuber" , "Andrew Krywaniuk" Cc: "'Dan Harkins'" , "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Tue, 26 Mar 2002 10:39:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Monday, March 25, 2002 7:30 PM > To: Andrew Krywaniuk > Cc: 'Dan Harkins'; 'IP Security List' > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > Yes, I posted a link to it earlier. > > It's worth noting that during the presenation Pyda presented two > different ways that the policy could get updated on both ends: > > - In IKE (which is what the draft talks about), but changing IKE is BAD. > - In some as yet unspecified IPSP protocol (and we again have the > problem that someone else pointed out: that doesn't exist yet :) > > So as each endpoint learns new policy (a new dynamic port), it > *somehow* (i.e. via IKE or an external protocol) tells the other end > to add or remove policy from the SA. Are dynamic protocols a requirement for ikev2? There have no comments to that regard. Assuming that they are.. One concern I have with the proposed approaches is the additional latency between discovery of the dynamic information and updating the peer with the dynamic information. Using any of the proposed mechanisms (via IKE or external protocol), the latency may be unacceptably high for some type of traffic. Another alternative worth considering is to do policy change inband to ipsec traffic. After all, if a secure a channel has already been established with the peer, why not use the same channel for updating the selector information? -- sankar -- From owner-ipsec@lists.tislabs.com Tue Mar 26 11:11:34 2002 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 g2QJBX413615; Tue, 26 Mar 2002 11:11:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23744 Tue, 26 Mar 2002 13:36:15 -0500 (EST) Date: Tue, 26 Mar 2002 10:47:41 -0800 (PST) From: Jan Vilhuber To: sankar ramamoorthi cc: Andrew Krywaniuk , "'Dan Harkins'" , "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Mar 2002, sankar ramamoorthi wrote: > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > Sent: Monday, March 25, 2002 7:30 PM > > To: Andrew Krywaniuk > > Cc: 'Dan Harkins'; 'IP Security List' > > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > Yes, I posted a link to it earlier. > > > > It's worth noting that during the presenation Pyda presented two > > different ways that the policy could get updated on both ends: > > > > - In IKE (which is what the draft talks about), but changing IKE is BAD. > > - In some as yet unspecified IPSP protocol (and we again have the > > problem that someone else pointed out: that doesn't exist yet :) > > > > So as each endpoint learns new policy (a new dynamic port), it > > *somehow* (i.e. via IKE or an external protocol) tells the other end > > to add or remove policy from the SA. > > Are dynamic protocols a requirement for ikev2? > There have no comments to that regard. > That's true. I think they are/should be. I'll ask Cheryl to add this to the requirements document. It's a fact that these protocols exist, and based on the discussion so far, it seems a fact that people want to protect them. The SCTP draft that Angelos wrote also comes to mind. > Assuming that they are.. > > One concern I have with the proposed approaches is the additional > latency between discovery of the dynamic information and updating the > peer with the dynamic information. Using any of the proposed mechanisms > (via IKE or external protocol), the latency may be unacceptably high > for some type of traffic. > As I mentioned, a prior idea was to negotiate descriptors that say 'L2TP', rather than some port information. You'd have to provide an API to higher layers (say L2TP) to add and remove policy from a given SA. This assumes that L2TP *on both ends* can determine precisely the same additions and subtractions from the traffic selectors. Based on conversations I had with some l2tp folks, this seems to be the case for l2tp. Maybe this is true for ftp and h.323 as well. That way, no exchange (in IKE or IPSEC) needs to happen. It all happens via the higher layer protocol, which tells their corresponding IPsec stacks about it. For gateways (i.e. where the IPsec stack is not on the same box as the ftp program, for example), this seems a bit harder, and NAT-like traffic inspection would need to happen. Yuck. But code for that exists already as well... So maybe this is feasible. > Another alternative worth considering is to do policy change > inband to ipsec traffic. After all, if a secure a channel has > already been established with the peer, why not use the same channel > for updating the selector information? > That would require changes to IPsec that I would really not even want to propose. The IPsec tunnel is for data traffic. Are you proposing yet another protocol which runs inside an IPsec tunnel? Why bother? You'd have the same latency. Maybe I'm misunderstanding. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 12:31:03 2002 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 g2QKV2416248; Tue, 26 Mar 2002 12:31:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24090 Tue, 26 Mar 2002 14:51:53 -0500 (EST) Date: Tue, 26 Mar 2002 22:03:48 +0200 Message-Id: <200203262003.WAA24804@burp.tkv.asdf.org> From: Markku Savela To: sankar@nexsi.com CC: ipsec@lists.tislabs.com In-reply-to: Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) References: 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 > From: "sankar ramamoorthi" > Another alternative worth considering is to do policy change > inband to ipsec traffic. NO! NO! You cannot change policy from IKE. There is some serious misunderstanding about what policy is. In my view policy can never be changed as a result of IKE negotiation. That would be a huge security hole. Surely you are not suggesting something like if, I have selector -> require ESP with 3DES IKE negotiation could change this into selector -> allow data in clear !!! Apparently other people include into policy what I would just consider SA parameters (which look like selectors). These parameters are used to distinguish different SA's between same nodes. This is related to text "4.4.1 The Security Policy Database (SPD)" ----------------- .... For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector. And in "4.4.3 Security Association Database (SAD)" .... For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA ... ----------------------- That is, the negotiated values are put into SA, not into SPD. There is *NOTHING* in IKE negotiation that needs to be put into SPD! From owner-ipsec@lists.tislabs.com Tue Mar 26 13:03:48 2002 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 g2QL3l417799; Tue, 26 Mar 2002 13:03:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24244 Tue, 26 Mar 2002 15:19:58 -0500 (EST) Message-Id: <200203262030.g2QKUHss022403@thunk.east.sun.com> From: Bill Sommerfeld To: Markku Savela cc: sankar@nexsi.com, ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Tue, 26 Mar 2002 22:03:48 +0200." <200203262003.WAA24804@burp.tkv.asdf.org> Reply-to: sommerfeld@east.sun.com Date: Tue, 26 Mar 2002 15:30:17 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Surely you are not suggesting something like if, I have > > selector -> require ESP with 3DES > > IKE negotiation could change this into > > selector -> allow data in clear or, almost as bad: -> allow ESP with crackable crypto. - Bill From owner-ipsec@lists.tislabs.com Tue Mar 26 13:57:53 2002 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 g2QLvrm20240; Tue, 26 Mar 2002 13:57:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24557 Tue, 26 Mar 2002 16:21:04 -0500 (EST) Date: Tue, 26 Mar 2002 13:32:30 -0800 (PST) From: Jan Vilhuber To: Michael Richardson cc: Subject: Re: Policy requirements in Son-Of-IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Fri, 22 Mar 2002, Michael Richardson wrote: > > > > > PS: I'm a bit upset that any time was spent on presentations on Thursday > > morning. We should have spent the high bandwidth time in the small room > > on discussion about these things. > > > > I guess I should have read the agenda with more thought and objected to it. > > I wonder if an official interim meeting in late April would have value. > > I missed this in the first reading of this mail. As you know, I fully agree. I don't know the politics around interim meetings, but given that we made absolutely NO forward progress in the last two meetings, I would consider some interim meeting valuable IF we can have a goal to the meeting (which is not just 'give five presentations and go home). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 14:01:21 2002 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 g2QM1Km20318; Tue, 26 Mar 2002 14:01:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24607 Tue, 26 Mar 2002 16:28:06 -0500 (EST) Message-ID: <3CA0EAE4.1340BB35@sonicwall.com> Date: Tue, 26 Mar 2002 13:40:52 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela CC: sankar@nexsi.com, ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) References: <200203262003.WAA24804@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2002 21:40:51.0271 (UTC) FILETIME=[E6464D70:01C1D50E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Marrku, Comments below... Markku Savela wrote: > > > From: "sankar ramamoorthi" > > > Another alternative worth considering is to do policy change > > inband to ipsec traffic. > > NO! NO! You cannot change policy from IKE. > > There is some serious misunderstanding about what policy is. > > In my view policy can never be changed as a result of IKE > negotiation. That would be a huge security hole. > > Surely you are not suggesting something like if, I have > > selector -> require ESP with 3DES > > IKE negotiation could change this into > > selector -> allow data in clear > I don't think anyone is suggesting that policy be changed by IKE. The problem being addressed is that for some protocols (e.g. FTP), you cannot know all of the associated selectors a priori, as some selectors are chosen dynamically during the protocol transaction. This means that to permit these within IPsec, you have to open up a whole range of selectors. For example, to permit FTP, you have to open up TCP from any port to any port. The way many of us have gotten around this is to open up the tunnel, but use stateful inspection (outside of IPsec) to regulate what actually goes through. However, this is not standard, so we have no guarantee of interoperability in multivendor environments. When people have referred to changing or updating policy within this thread, what (I think) they refer to is the ability to dynamically update the selectors associated with a given SA based upon current protocol state (which might better be referred to as changing the SAD rather than the SPD). For example, it would be nice to have a rule which permits FTP explicitly, without opening all TCP ports. Such a rule would have to allow for dynamically updating the SA selectors based on the content of the PORT command within FTP, i.e. it would have to rely on stateful protocol monitoring. Currently, no such support is standardized. The question is, should we be trying to solve this here, and if so, how can it be done? Obviously, any solution has implications for the SPD first (as we need a way to represent such dynamic selectors there), and in IKE second, as there would be some associated TS payload(s). Scott From owner-ipsec@lists.tislabs.com Tue Mar 26 14:14:49 2002 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 g2QMEmm20775; Tue, 26 Mar 2002 14:14:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24712 Tue, 26 Mar 2002 16:43:12 -0500 (EST) Message-ID: <3CA0EE6E.6A22F5D0@sonicwall.com> Date: Tue, 26 Mar 2002 13:55:58 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Policy requirements in Son-Of-IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2002 21:55:40.0666 (UTC) FILETIME=[F86535A0:01C1D510] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I meant to send a response to this as well, as I forgot to complain after the SLC meeting. To travel all that way to meet face to face, and then to not have time to actually discuss things in detail, seems to defeat the purpose. Interim meeting or no, I cast a vote for scheduling more discussion (open mike?) time at working group meetings. If we need 3 slots, then we need 3 slots. Scott Jan Vilhuber wrote: > > > On Fri, 22 Mar 2002, Michael Richardson wrote: > > > > > > > > PS: I'm a bit upset that any time was spent on presentations on Thursday > > > morning. We should have spent the high bandwidth time in the small room > > > on discussion about these things. > > > > > > I guess I should have read the agenda with more thought and objected to it. > > > I wonder if an official interim meeting in late April would have value. > > > > > I missed this in the first reading of this mail. > > As you know, I fully agree. I don't know the politics around interim > meetings, but given that we made absolutely NO forward progress in the > last two meetings, I would consider some interim meeting valuable IF > we can have a goal to the meeting (which is not just 'give five > presentations and go home). > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 15:09:07 2002 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 g2QN96m22045; Tue, 26 Mar 2002 15:09:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24984 Tue, 26 Mar 2002 17:27:00 -0500 (EST) Date: Tue, 26 Mar 2002 14:38:26 -0800 (PST) From: Jan Vilhuber To: Sankar Ramamoorthi cc: Andrew Krywaniuk , Dan Harkins , IP Security List Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote: > > > Another alternative worth considering is to do policy change > > > inband to ipsec traffic. After all, if a secure a channel has > > > already been established with the peer, why not use the same channel > > > for updating the selector information? > > > > > > > That would require changes to IPsec that I would really not even want > > to propose. The IPsec tunnel is for data traffic. Are you proposing > > yet another protocol which runs inside an IPsec tunnel? Why bother? > > You'd have the same latency. Maybe I'm misunderstanding. > > Having an inband way (yes - that may require ipsec tunnel to > be accepting control traffic in addition to data traffic) allows the > possiblity of piggybacking control information along with data > within the ipsec tunnel. To me, that seems to be most efficient > way to indicate to the other side about the change in ipsec selectors. > The control channel can be put to other uses as well.. > I must really be missing something, but that really sounds like an inappropriate use of IPsec. This would essentially require changes to everyone's IPsec stacks (especially the 'piggybacking' part), some of which may reside in hardware. Let's try to keep the protocols separate. If you think that IKE isn't the best place to do this, I would argue that ipsec is an even worse place to do this. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 15:09:13 2002 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 g2QN9Dm22057; Tue, 26 Mar 2002 15:09:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24993 Tue, 26 Mar 2002 17:28:34 -0500 (EST) From: "Catherine A. Meadows" Date: Tue, 26 Mar 2002 17:38:32 -0500 (EST) Message-Id: <200203262238.RAA12281@liverwurst.fw5540.net> To: vilhuber@cisco.com, skelly@SonicWALL.com Subject: Possible Interim Meeting, was Re: Policy requirements in Son-Of-IKE Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree; I have also been frustrated at the last two meetings. I would to follow up on this to say that perhaps we need to plan to make more focused and interactive discussion possible as well. The trouble with open mike when a group gets this large, and has so many issues to cover, is that it is very hard to follow up on what someone said four or five or eight comments back. This is especially true, of course, when the amount of time allotted is so brief as at last week's IETF, but I think it would have been a problem even if we had had a lot more time. If we do have an interim meeting, and if it looks like it will be large, I wonder if it would be possible to organize things differently, e.g. have people split into discussion groups to discuss specific topics, and then to present their results to the group at large, with time for comments. Or maybe the WG chairs could identify what seem to be the major issues and schedule open mike so that specific portions of the open mike time are set aside to discuss specific issues. Or maybe somebody has some other ideas/experience for managing discussion in a group of this size. Cathy Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 phone: +1-202-767-3490 fax: +1-202-404-7942 > > From: "Scott G. Kelly" > > I meant to send a response to this as well, as I forgot to complain > after the SLC meeting. To travel all that way to meet face to face, and > then to not have time to actually discuss things in detail, seems to > defeat the purpose. Interim meeting or no, I cast a vote for scheduling > more discussion (open mike?) time at working group meetings. If we need > 3 slots, then we need 3 slots. > > Scott > > Jan Vilhuber wrote: > > > > > On Fri, 22 Mar 2002, Michael Richardson wrote: > > > > > > > > > > > PS: I'm a bit upset that any time was spent on presentations on Thursday > > > > morning. We should have spent the high bandwidth time in the small room > > > > on discussion about these things. > > > > > > > > I guess I should have read the agenda with more thought and objected to it. > > > > I wonder if an official interim meeting in late April would have value. > > > > > > > > I missed this in the first reading of this mail. > > > > As you know, I fully agree. I don't know the politics around interim > > meetings, but given that we made absolutely NO forward progress in the > > last two meetings, I would consider some interim meeting valuable IF > > we can have a goal to the meeting (which is not just 'give five > > presentations and go home). > > > > jan > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Tue Mar 26 15:36:39 2002 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 g2QNacm22775; Tue, 26 Mar 2002 15:36:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25212 Tue, 26 Mar 2002 17:57:19 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Jan Vilhuber'" , "'Sankar Ramamoorthi'" Cc: "Andrew Krywaniuk" , "'Dan Harkins'" , "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Tue, 26 Mar 2002 18:01:07 -0500 Message-ID: <001901c1d51a$1e25e330$1e72788a@ca.alcatel.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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't necessarily have any objections to doing this through an IPsec tunnel, but it should at least be a specialized control channel tunnel rather than having it mixed in with IPsec-tunneled data. I would suggest that the transport mode connection between two gateways be considered a control channel, but it seems that the L2TP people have already subsumed this SA for their purposes. So it should probably be a port-specific SA on which the IPSP protocol would run. This solution, in turn, necessitates a 2-phase approach in order to negotiate the IPsec control channel. An alternative is to create an ISAKMP message for this, which is what most people would have done before the great complexity crisis of '99. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, March 26, 2002 5:38 PM > To: Sankar Ramamoorthi > Cc: Andrew Krywaniuk; Dan Harkins; IP Security List > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote: > > > > Another alternative worth considering is to do policy change > > > > inband to ipsec traffic. After all, if a secure a channel has > > > > already been established with the peer, why not use the > same channel > > > > for updating the selector information? > > > > > > > > > > That would require changes to IPsec that I would really > not even want > > > to propose. The IPsec tunnel is for data traffic. Are you > proposing > > > yet another protocol which runs inside an IPsec tunnel? > Why bother? > > > You'd have the same latency. Maybe I'm misunderstanding. > > > > Having an inband way (yes - that may require ipsec tunnel to > > be accepting control traffic in addition to data traffic) allows the > > possiblity of piggybacking control information along with data > > within the ipsec tunnel. To me, that seems to be most efficient > > way to indicate to the other side about the change in ipsec > selectors. > > The control channel can be put to other uses as well.. > > > > I must really be missing something, but that really sounds like an > inappropriate use of IPsec. This would essentially require changes to > everyone's IPsec stacks (especially the 'piggybacking' part), some of > which may reside in hardware. > > Let's try to keep the protocols separate. If you think that IKE isn't > the best place to do this, I would argue that ipsec is an even worse > place to do this. > > jan > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ipsec@lists.tislabs.com Tue Mar 26 15:44:33 2002 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 g2QNiXm22911; Tue, 26 Mar 2002 15:44:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25290 Tue, 26 Mar 2002 18:04:22 -0500 (EST) Date: Tue, 26 Mar 2002 15:15:48 -0800 (PST) From: Jan Vilhuber To: cc: "'Sankar Ramamoorthi'" , Andrew Krywaniuk , "'Dan Harkins'" , "'IP Security List'" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: <001901c1d51a$1e25e330$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Mar 2002 andrew.krywaniuk@alcatel.com wrote: > I don't necessarily have any objections to doing this through an IPsec > tunnel, but it should at least be a specialized control channel tunnel > rather than having it mixed in with IPsec-tunneled data. I would suggest > that the transport mode connection between two gateways be considered a > control channel, but it seems that the L2TP people have already subsumed > this SA for their purposes. So it should probably be a port-specific SA on > which the IPSP protocol would run. This solution, in turn, necessitates a > 2-phase approach in order to negotiate the IPsec control channel. And if we need to devise a completely new protocol for this mythical management channel, then why not simply use the one that already exists (like you say below): IKE (or ISAKMP messages). jan > An > alternative is to create an ISAKMP message for this, which is what most > people would have done before the great complexity crisis of '99. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Tuesday, March 26, 2002 5:38 PM > > To: Sankar Ramamoorthi > > Cc: Andrew Krywaniuk; Dan Harkins; IP Security List > > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote: > > > > > Another alternative worth considering is to do policy change > > > > > inband to ipsec traffic. After all, if a secure a channel has > > > > > already been established with the peer, why not use the > > same channel > > > > > for updating the selector information? > > > > > > > > > > > > > That would require changes to IPsec that I would really > > not even want > > > > to propose. The IPsec tunnel is for data traffic. Are you > > proposing > > > > yet another protocol which runs inside an IPsec tunnel? > > Why bother? > > > > You'd have the same latency. Maybe I'm misunderstanding. > > > > > > Having an inband way (yes - that may require ipsec tunnel to > > > be accepting control traffic in addition to data traffic) allows the > > > possiblity of piggybacking control information along with data > > > within the ipsec tunnel. To me, that seems to be most efficient > > > way to indicate to the other side about the change in ipsec > > selectors. > > > The control channel can be put to other uses as well.. > > > > > > > I must really be missing something, but that really sounds like an > > inappropriate use of IPsec. This would essentially require changes to > > everyone's IPsec stacks (especially the 'piggybacking' part), some of > > which may reside in hardware. > > > > Let's try to keep the protocols separate. If you think that IKE isn't > > the best place to do this, I would argue that ipsec is an even worse > > place to do this. > > > > jan > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 16:16:25 2002 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 g2R0GPm23641; Tue, 26 Mar 2002 16:16:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25468 Tue, 26 Mar 2002 18:35:26 -0500 (EST) Message-ID: <3CA10898.20904@alum.mit.edu> Date: Tue, 26 Mar 2002 16:47:36 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) References: <200203262003.WAA24804@burp.tkv.asdf.org> <3CA0EAE4.1340BB35@sonicwall.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly wrote: > When people have referred to changing or updating policy within this > thread, what (I think) they refer to is the ability to dynamically > update the selectors associated with a given SA based upon current > protocol state (which might better be referred to as changing the SAD > rather than the SPD). For example, it would be nice to have a rule which > permits FTP explicitly, without opening all TCP ports. Such a rule would > have to allow for dynamically updating the SA selectors based on the > content of the PORT command within FTP, i.e. it would have to rely on > stateful protocol monitoring. Currently, no such support is > standardized. > > The question is, should we be trying to solve this here, and if so, how > can it be done? Obviously, any solution has implications for the SPD > first (as we need a way to represent such dynamic selectors there), and > in IKE second, as there would be some associated TS payload(s). > > Scott I've found this use of the term "policy" confusing as well, but I've become accustomed to using a generalized notion. In the generic meaning of policy, an SA represents a piece of policy, a rule, and changing anything about an SA constitutes a policy change. IKE is a key exchange protocol, not a policy manipulation protocol. I.e., if it doesn't involve the key, don't use IKE. What I'd suggest instead is to define the requirements for SA, SAD, and SPD manipulation and use that as the start of a security policy protocol. That is one of the goals of the IPSP group, and help with the requirements is definitely needed. We have evidence from user protocols and routing showing the difficulty of the current IPsec methods. It seems time to divide and conquer. Hilarie From owner-ipsec@lists.tislabs.com Tue Mar 26 16:58:44 2002 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 g2R0whm24548; Tue, 26 Mar 2002 16:58:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25680 Tue, 26 Mar 2002 19:17:55 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 26 Mar 2002 16:29:50 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Do we actually need dynamic ports? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:47 AM -0800 3/26/02, Jan Vilhuber wrote: >On Tue, 26 Mar 2002, sankar ramamoorthi wrote: > > Are dynamic protocols a requirement for ikev2? >> There have no comments to that regard. >> > >That's true. I think they are/should be. I'll ask Cheryl to add this >to the requirements document. Why is this a requirement? Has the lack of dynamic ports significantly hurt IKEv1? If so, what other protocol did the folks who required dynamic ports use? This sounds a lot like a rat-hole that will have next to no chance of interoperating and will not help many users. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 26 17:11:23 2002 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 g2R1BNm24823; Tue, 26 Mar 2002 17:11:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25761 Tue, 26 Mar 2002 19:35:11 -0500 (EST) Message-ID: <3CA116BE.87C6D249@sonicwall.com> Date: Tue, 26 Mar 2002 16:47:58 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "The Purple Streak (Hilarie Orman)" CC: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) References: <200203262003.WAA24804@burp.tkv.asdf.org> <3CA0EAE4.1340BB35@sonicwall.com> <3CA10898.20904@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2002 00:47:40.0373 (UTC) FILETIME=[FF6B8850:01C1D528] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Hilarie, Comments inline below... "The Purple Streak (Hilarie Orman)" wrote: > I've found this use of the term "policy" confusing as well, but > I've become accustomed to using a generalized notion. In the generic > meaning of policy, an SA represents a piece of policy, a rule, > and changing anything about an SA constitutes a policy change. I might go a bit further, and say that the SA represents a policy instantiation: a particular instance of a policy as applied to a particular class or set of traffic. Of course, this implies that I view the policy as being spelled out in the SPD, and the instances as being spelled out in the SAD, which sounds different than your view, based on your comments above. In any event, if the desired policy is to permit all FTP traffic between two hosts to traverse a tunnel, and we cannot know the ports associated with the data channel until after the session starts, are we changing policy by dynamically associating the correct ports with the tunnel once we know them? I don't think we're actually changing it; rather, I think we are fulfilling it, assuming that we have provided a mechanism for expressing such a policy in the SPD. This is very much like using a name as a selector (e.g. a DN), and then associating numeric selectors with the tunnel once the user is authenticated (i.e. once they are known). And this would require no further protocol exchange, beyond the ability to express the corresponding TS values in IKE. > IKE is a key exchange protocol, not a policy manipulation protocol. > I.e., if it doesn't involve the key, don't use IKE. I appreciate the sentiment here, but I think people rightfully see IKE as more than just a key exchange protocol, since it is an instance of the Internet Security Association and Key Management Protocol. This seems to imply that it should be used for SA management, along with key exchange, and in fact, it is. I'm not sure at this point if I agree or disagree with the need for a separate IPSP protocol for the functionality we are discussing in this thread, but wanted to make this point nonetheless. > What I'd suggest instead is to define the requirements for SA, SAD, and > SPD manipulation and use that as the start of a security policy > protocol. That is one of the goals of the IPSP group, and help with > the requirements is definitely needed. We have evidence from user > protocols and routing showing the difficulty of the current IPsec > methods. It seems time to divide and conquer. Scott From owner-ipsec@lists.tislabs.com Tue Mar 26 17:18:20 2002 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 g2R1IJm24985; Tue, 26 Mar 2002 17:18:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25804 Tue, 26 Mar 2002 19:39:58 -0500 (EST) Date: Tue, 26 Mar 2002 16:53:08 -0800 (PST) Message-Id: <200203270053.QAA06819@potomac.incog.com> From: Mike Ditto To: ipsec@lists.tislabs.com In-reply-to: Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some have proposed adding a way to redefine (broaden) an existing SA's selectors with an additional exchange. This does solve the problem that the current TS mechanisms are not capable of expressing all commonly used services. But it's going even further down the complexity road. "sankar ramamoorthi" wrote: > One concern I have with the proposed approaches is the additional > latency between discovery of the dynamic information and updating the > peer with the dynamic information. Using any of the proposed mechanisms > (via IKE or external protocol), the latency may be unacceptably high > for some type of traffic. This is why I advocate that the protocol for broadening a tunnel's traffic selectors consist of simply sending the packet that you want to send. This already has to be checked by the recipient for conformance to its policy, so let it be an implicit request to "broaden" the tunnel. No latency. > Another alternative worth considering is to do policy change > inband to ipsec traffic. After all, if a secure a channel has > already been established with the peer, why not use the same channel > for updating the selector information? Right, and you don't even need a new protocol for the request (just send an actual packet), or for positive responses (implied). You only need to define the error messages sent to reject the request. I think a few new ICMP codes would meet that need. There is of course the problem of choosing an appropriate SA in the reverse direction for the error response. Jan Vilhuber wrote: > A pre-cursor to this draft (that I was hashing out with some l2tp > folks) had speculated on using specifiers like 'L2TP' or 'FTP' or > "H.323" (IANA assigned, of course ;) in IKE. The problem with that is that it's hard enough to codify and implement those bletcherous protocols so that they work at all; much less trying to then figure out what to write in an RFC to describe their traffic pattern so that you can reference that in an IANA assignment for a token like "H.323". That's why I gave my example of one vendor implementing "NetMeeting" and another vendor implementing "H.323". They aren't the same protocol, but if the applications work...that's good enough. The grotesque details of what packets are or aren't part of a particular service should be left to the policy IMPLEMENTATION and out of key management. -=] Mike [=- From owner-ipsec@lists.tislabs.com Tue Mar 26 17:25:43 2002 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 g2R1Pgm25126; Tue, 26 Mar 2002 17:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25941 Tue, 26 Mar 2002 19:53:58 -0500 (EST) Date: Tue, 26 Mar 2002 17:05:24 -0800 (PST) From: Jan Vilhuber To: Paul Hoffman / VPNC cc: Subject: Re: Do we actually need dynamic ports? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote: > At 10:47 AM -0800 3/26/02, Jan Vilhuber wrote: > >On Tue, 26 Mar 2002, sankar ramamoorthi wrote: > > > Are dynamic protocols a requirement for ikev2? > >> There have no comments to that regard. > >> > > > >That's true. I think they are/should be. I'll ask Cheryl to add this > >to the requirements document. > > Why is this a requirement? Has the lack of dynamic ports > significantly hurt IKEv1? If so, what other protocol did the folks > who required dynamic ports use? > There is no other protocol they COULD use. The workaround, as Scott Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do stateful filtering on both ends, which is not interoperable. If you don't do stateful inspection, you simply keep all ports open and pass more traffic than you were hoping for, which is also suboptimal. In L2tp's case, the port-moving and ip-address moving feature that prompted this discussion (internally here at cisco) hasn't been really rolled out yet. Once they do, I expect this issue will be raised again. For SCTP, I refer you to angelos' draft on ike and sctp... > This sounds a lot like a rat-hole that will have next to no chance of > interoperating and will not help many users. > I think it WILL help many users. The ability to do dynamic port additions (or even dynamic address additions) will make configurations simpler (try 'ftp' instead of 'port 21 and whatever else ftp negotiates'), and will not impact interoperability. I think it's fairly well defined in both angelos' draft for sctp and Pyda Srisuresh's draft (of which I'm coauthor). This is not brain-surgery. Given that ip telephony is being used more and more, and given that h.323 is the mechanism (or one of them?) I'd say this is important. Whether it needs to happen in IKE, or, as Hillarie suggested, as part of some as yet unspecified protocol in IPSP is up for discussion, but the problem must be addressed. Problem with doing it via IPSP is that (as someone else pointed out) said IPSP protocol would need to be done before SOI can become an RFC. I'd prefer not to make such a linking, since I don't think this is overly complex... Opinions vary (obviously.. this is ipsec afterall). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 26 19:05:12 2002 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 g2R35Bm27297; Tue, 26 Mar 2002 19:05:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26632 Tue, 26 Mar 2002 21:24:08 -0500 (EST) Message-Id: <200203270233.g2R2XYQ01734@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Tue, 26 Mar 2002 16:53:08 PST." <200203270053.QAA06819@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1731.1017196414.1@tibernian.com> Date: Tue, 26 Mar 2002 18:33:34 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Mar 2002 16:53:08 PST you wrote > > This is why I advocate that the protocol for broadening a tunnel's > traffic selectors consist of simply sending the packet that you want to > send. This already has to be checked by the recipient for conformance > to its policy, so let it be an implicit request to "broaden" the tunnel. > No latency. If the selectors that defined your particular SPD entry allowed this received packet already then no "broadening" would be necessary. The TS mechanism will ensure that the largest intersection of selectors between the two parties will already be assigned to the established SA. A new packet that required "broadening a tunnel's traffic selectors" would BY DEFINITION be dropped on the other side so there is no point in sending it under protection of that SA in the first place. The problem is that certain protocols float ports and it is not possible to know what ports will be used by that particular protocol when defining the ordered list of selectors in your SPD. Your proposal solves problem that does not exist and does not solve the problem that does. If we choose to just do away with the TS payloads (as you suggest) then we have no standard way of agreeing on anything. What would happen is that two boxes would be correctly configured to protect FOO (some protocol) but because the definition of how to implement protection of FOO is left to the imagination of those implementing IPsec the two boxes might not interoperate. Having two boxes be correctly configured (according to their own UI) and still not interoperate is not something we should we working towards. Dan. From owner-ipsec@lists.tislabs.com Tue Mar 26 19:46:03 2002 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 g2R3k3m28046; Tue, 26 Mar 2002 19:46:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26904 Tue, 26 Mar 2002 22:09:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200203262003.WAA24804@burp.tkv.asdf.org> References: <200203262003.WAA24804@burp.tkv.asdf.org> Date: Tue, 26 Mar 2002 21:52:15 -0500 To: Markku Savela From: Stephen Kent Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Cc: sankar@nexsi.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:03 PM +0200 3/26/02, Markku Savela wrote: > > From: "sankar ramamoorthi" > >> Another alternative worth considering is to do policy change >> inband to ipsec traffic. > >NO! NO! You cannot change policy from IKE. > >There is some serious misunderstanding about what policy is. > >In my view policy can never be changed as a result of IKE >negotiation. That would be a huge security hole. > >Surely you are not suggesting something like if, I have > > selector -> require ESP with 3DES > >IKE negotiation could change this into > > selector -> allow data in clear > >!!! > >Apparently other people include into policy what I would just consider >SA parameters (which look like selectors). These parameters are used >to distinguish different SA's between same nodes. > >This is related to text "4.4.1 The Security Policy Database (SPD)" > >----------------- > .... For each selector, the policy entry specifies how > to derive the corresponding values for a new Security Association > Database (SAD, see Section 4.4.3) entry from those in the SPD and the > packet (Note that at present, ranges are only supported for IP > addresses; but wildcarding can be expressed for all selectors): > > a. use the value in the packet itself -- This will limit use > of the SA to those packets which have this packet's value > for the selector even if the selector for the policy entry > has a range of allowed values or a wildcard for this > selector. > > b. use the value associated with the policy entry -- If this > were to be just a single value, then there would be no > difference between (b) and (a). However, if the allowed > values for the selector are a range (for IP addresses) or > wildcard, then in the case of a range,(b) would enable use > of the SA by any packet with a selector value within the > range not just by packets with the selector value of the > packet that triggered the creation of the SA. In the case > of a wildcard, (b) would allow use of the SA by packets > with any value for this selector. > >And in "4.4.3 Security Association Database (SAD)" > > .... > For each of the selectors defined in Section 4.4.2, the SA entry in > the SAD MUST contain the value or values which were negotiated at the > time the SA was created. For the sender, these values are used to > decide whether a given SA is appropriate for use with an outbound > packet. This is part of checking to see if there is an existing SA > ... >----------------------- > >That is, the negotiated values are put into SA, not into SPD. There is >*NOTHING* in IKE negotiation that needs to be put into SPD! As the author of this text, let me try to clarify a few things: - the term "policy" is used in many ways by many folks. high level security policy is usually expressed in natural language and thus is not suitable as a basis for automated enforcement in security technology. low level security policy is directly enforceable by such technology, and that is what the SPD represents. One could imagine an intermediate form of policy expression, which may be (I'm not sure) what IPSP addresses. in any case, I think the use of the term "policy" is appropriate for what the SPD does. - the symbolic selector values that are permitted in the SPD are intended to represent IP address selectors, with the intent that they be transformed into transient SPD entries, as well as SAD entries, as a side effect of the IKE exchanges. It's clear that symbolic values cannot be directly matched against packet headers, yet 2401 mandates checking against such headers for both outbound and inbound SA traffic. In the rev of 2401 we will introduce the notion of an SPD cache, and using that model, we will do a better job of describing how a symbolic value in an SPD entry is transformed into an SPD cache entry, rather than talking about a transient or temporary SPD entry. I think this will clarify what we envisioned. - since the above example does involve (under the current 2401 description) dynamic modification of the SPD, I would not argue that such modification is prohibited by 2401. IPSP has discussed dynamic modification of the SPD as a result of a policy negotiation, so that notion is embraced by others as well. I would like to see a way to deal with these sorts of protocols as we progress, in a fashion consistent with the revised 2401 model we're developing, and I solicit suggestions on how to do this. Steve From owner-ipsec@lists.tislabs.com Tue Mar 26 21:18:22 2002 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 g2R5ILm29521; Tue, 26 Mar 2002 21:18:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA27352 Tue, 26 Mar 2002 23:31:30 -0500 (EST) Message-Id: <200203270442.g2R4g8u00871@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Possible Interim Meeting, was Re: Policy requirements in Son-Of-IKE In-reply-to: Your message of "Tue, 26 Mar 2002 17:38:32 EST." <200203262238.RAA12281@liverwurst.fw5540.net> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Mar 2002 23:42:07 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Catherine" == Catherine A Meadows writes: Catherine> If we do have an interim meeting, and if it looks like it will be large, Catherine> I wonder if it would be possible to organize things differently, e.g. have Catherine> people split into discussion groups to discuss specific topics, and then Catherine> to present their results to the group at large, with time for comments. Catherine> Or maybe the WG chairs could identify what seem to be the major issues and Catherine> schedule Well, the discussion groups are a good idea. There is nothing to prevent us from doing this at IETF WG meetings as well. ] 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 Mar 27 00:29:00 2002 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 g2R8T0m17406; Wed, 27 Mar 2002 00:29:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA28324 Wed, 27 Mar 2002 02:18:13 -0500 (EST) Message-ID: <000a01c1d561$20f118e0$0202a8c0@aikuchi> From: "m" To: Subject: SSH Sentinal to FreeSwan1.96 Help Date: Wed, 27 Mar 2002 16:59:27 +0930 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1D5B0.C1703040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1D5B0.C1703040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have a Redhat Linux 2.4.9-31 kernal with FreeSwan 1.96 as a = firewall/NAT box to the internet. Eth1 to the adsl, eth0 to the internal = LAN. I also have a WinMe(192.168.2.2) client running SSH Sentinal 1.2.3.=20 I built a VPN connection to the firewall(192.168.2.1) When I do a diagnostics/or Rule enable, it connects and authenticates = just fine. I can see the IPSEC packets using Windump and tcpdump. Both = on the ipsec0 and eth0. Both ipsec and SSH claim the tunnel is built and = happy.=20 Problem being once the VPN says its up. I cannt ping the firewall, or = www.yahoo.com or anybody else or pass any other form of traffic, SMTP, = HTTP etc.... I can run windump, ping from the firewall and see the packets hit the = WinBox but the firewall sees no replies!. When I ping from the winbox I = can see the packets go out and return but the winbox sees no replies. = They both state request timeout. Windows seems to be a black hole for = packets. Once they hit the VPN interface they disappear. I figured it = had to be a pre or post ipsec routing policy in SSH Sentinal, but all = the rules state ALLOW ALL from/to ANY.=20 I basically want to secure the LAN and still surf the net. BTW I have this setup(encrypted point to firewall) with my Dell laptop = running an MA401 wireless card and Linux 7.2/FreeSwan and it works = perfectly through the wireless to the firewall through to the net! So I = know it can be done, it's just windowz being difficult... My SSH Sentinal VPN Setup. I also tried it as a Secured Connection, and = the authentication fails...weird... GW host: 192.168.2.1 IP Address 0.0.0.0 SN Mask 0.0.0.0 and all the standard proposal configs: 3des, mainmode, tunnel, modp = 1024. here is my Freeswan config. (Yes i know the password is small and = stupid, I will change it as soon as I can get this stuff to work) Left = is my winbox, right is my firewall. # cat /etc/ipsec.secrets 192.168.2.1 192.168.2.2 : PSK "hi" cat /etc/ipsec.conf # /etc/ipsec.conf - FreeS/WAN IPsec configuration file # basic configuration config setup interfaces=3D"ipsec0=3Deth0" klipsdebug=3Dnone plutodebug=3Dnone plutoload=3D%search plutostart=3D%search uniqueids=3Dyes conn %default authby=3Dsecret conn laptop left=3D192.168.2.2 right=3D192.168.2.1 rightsubnet=3D0.0.0.0/0 auto=3Dadd pfs=3Dyes compress=3Dno thanx for the help! Mark ------=_NextPart_000_0007_01C1D5B0.C1703040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have a Redhat Linux 2.4.9-31 kernal = with FreeSwan=20 1.96 as a firewall/NAT box to the internet. Eth1 to the adsl, eth0 = to the=20 internal LAN.
I also have a WinMe(192.168.2.2) client = running SSH=20 Sentinal 1.2.3.
I built a VPN connection to the=20 firewall(192.168.2.1)
When I do a diagnostics/or Rule = enable, it=20 connects and authenticates just fine. I can see the IPSEC packets using = Windump=20 and tcpdump. Both on the ipsec0 and eth0. Both ipsec and SSH claim the = tunnel is=20 built and happy.
 
Problem being once the VPN says its up. = I cannt=20 ping the firewall, or www.yahoo.com = or=20 anybody else or pass any other form of traffic, SMTP, HTTP = etc....
I can run windump, ping from the = firewall and see=20 the packets hit the WinBox but the firewall sees no replies!. When I = ping from=20 the winbox I can see the packets go out and return but the winbox sees = no=20 replies. They both state request timeout. Windows seems to be = a black=20 hole for packets. Once they hit the VPN interface they disappear. I = figured it=20 had to be a pre or post ipsec routing policy in SSH Sentinal, but all = the rules=20 state ALLOW ALL from/to ANY.
I basically want to secure the LAN and = still surf=20 the net.
 
BTW I have this setup(encrypted point = to=20 firewall) with my Dell laptop running an MA401 wireless = card and Linux=20 7.2/FreeSwan and it works perfectly through the wireless to the firewall = through=20 to the net! So I know it can be done, it's just windowz being=20 difficult...
 
 
My SSH Sentinal VPN Setup. I also tried = it as a=20 Secured Connection, and the authentication fails...weird...
GW host: 192.168.2.1
IP Address 0.0.0.0
SN Mask 0.0.0.0
 
and all the standard proposal configs: = 3des,=20 mainmode, tunnel, modp 1024.
 
here is my Freeswan config. (Yes i know = the=20 password is small and stupid, I will change it as soon as I can get this = stuff=20 to work)  Left is my winbox, right is my firewall.
 
# cat /etc/ipsec.secrets
192.168.2.1 = 192.168.2.2=20 : PSK "hi"
cat /etc/ipsec.conf
# = /etc/ipsec.conf -=20 FreeS/WAN IPsec configuration file
 
# basic configuration
config=20 setup
       =20 interfaces=3D"ipsec0=3Deth0"
       = ; klipsdebug=3Dnone
       =20 plutodebug=3Dnone
       =20 plutoload=3D%search
       =20 plutostart=3D%search
       =20 uniqueids=3Dyes

conn=20 %default
       =20 authby=3Dsecret
 
conn=20 laptop
       =20 left=3D192.168.2.2
       =20 right=3D192.168.2.1
       =20 rightsubnet=3D0.0.0.0/0
       =20 auto=3Dadd
       =20 pfs=3Dyes
       =20 compress=3Dno
 
 
thanx for the help!
Mark
 
------=_NextPart_000_0007_01C1D5B0.C1703040-- From owner-ipsec@lists.tislabs.com Wed Mar 27 06:32:04 2002 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 g2REW3m17773; Wed, 27 Mar 2002 06:32:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00915 Wed, 27 Mar 2002 08:32:04 -0500 (EST) Message-Id: <5.1.0.14.0.20020327082908.00a66d90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Mar 2002 08:47:35 -0500 To: ipsec@lists.tislabs.com From: Melinda Shore Subject: Requirements process suggestions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The requirements process doesn't seem to be going very well, which isn't that surprising - requirements documents are hard to do. I think it might be possible to have the son-of-IKE requirements through WG last call before Yokohama by applying some discipline, if that's what the working group wants. In particular, it's impossible to develop a good requirements document by evaluating it in terms of whether or not it presents a harmonious, pleasing whole. It's got to be taken apart and put back together again. What I've found to be effective (but a lot of work) is: 1) take the requirements document, turn it into a numbered list of crisp, declarative sentences 2) make a quick first pass through the list and identify items on which there's already consensus either to keep or to drop. If there's any - *any* - disagreement about anything, it goes on the "unresolved" list. 3) Someone needs to keep track of all three categories and make that information public - you can use a web page, a database, bugzilla, etc. 4) the chairs need to work the unresolved list. That means every few days put a small number of the unresolved items (say, 2-4) out to the mailing list and try to come to consensus on them. If it becomes impossible to reach a decision on something, move on and come back to it later. The answer may fall out of later discussions of other items 5) as new requirements come up (and they will), add them to the unresolved list 6) when everything's resolved, turn it back into a requirements document and return to usual working methods I've found that the only thing that requires face-to-face interaction is item 2 - doing it on the mailing list is too slow. However, given the 30-day-notice requirement for interim meetings waiting for an interim meeting may take too long, too, and perhaps instead everything could go on the unresolved list. It's a lot of work for the chairs since they have to actively manage the process, both in getting the items out there and in determining consensus. The process also isn't much fun for anybody, but it will get the document finished within a reasonable amount of time and it will guarantee that every requirement receives its due consideration. Melinda From owner-ipsec@lists.tislabs.com Wed Mar 27 06:47:21 2002 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 g2RElKm18963; Wed, 27 Mar 2002 06:47:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01261 Wed, 27 Mar 2002 09:03:53 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Mar 2002 14:18:48 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVFDDhmTvUKPpJRC+F2cryfauNiA== From: "Sankar Ramamoorthi" To: "Jan Vilhuber" Cc: "Andrew Krywaniuk" , "Dan Harkins" , "IP Security List" X-OriginalArrivalTime: 26 Mar 2002 22:18:44.0445 (UTC) FILETIME=[313120D0:01C1D514] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA24863 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, March 26, 2002 10:48 AM > To: Sankar Ramamoorthi > Cc: Andrew Krywaniuk; 'Dan Harkins'; 'IP Security List' > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On Tue, 26 Mar 2002, sankar ramamoorthi wrote: > > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > > Sent: Monday, March 25, 2002 7:30 PM > > > To: Andrew Krywaniuk > > > Cc: 'Dan Harkins'; 'IP Security List' > > > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > > > > Yes, I posted a link to it earlier. > > > > > > It's worth noting that during the presenation Pyda presented two > > > different ways that the policy could get updated on both ends: > > > > > > - In IKE (which is what the draft talks about), but > changing IKE is BAD. > > > - In some as yet unspecified IPSP protocol (and we again have the > > > problem that someone else pointed out: that doesn't exist yet :) > > > > > > So as each endpoint learns new policy (a new dynamic port), it > > > *somehow* (i.e. via IKE or an external protocol) tells > the other end > > > to add or remove policy from the SA. > > > > Are dynamic protocols a requirement for ikev2? > > There have no comments to that regard. > > > > That's true. I think they are/should be. I'll ask Cheryl to add this > to the requirements document. > > It's a fact that these protocols exist, and based on the discussion so > far, it seems a fact that people want to protect them. The SCTP draft > that Angelos wrote also comes to mind. > > > > Assuming that they are.. > > > > One concern I have with the proposed approaches is the additional > > latency between discovery of the dynamic information and > updating the > > peer with the dynamic information. Using any of the > proposed mechanisms > > (via IKE or external protocol), the latency may be unacceptably high > > for some type of traffic. > > > > As I mentioned, a prior idea was to negotiate descriptors that say > 'L2TP', rather than some port information. You'd have to provide an > API to higher layers (say L2TP) to add and remove policy from a given > SA. This assumes that L2TP *on both ends* can determine precisely the > same additions and subtractions from the traffic selectors. Based on > conversations I had with some l2tp folks, this seems to be the case > for l2tp. Maybe this is true for ftp and h.323 as well. That way, no > exchange (in IKE or IPSEC) needs to happen. It all happens via the > higher layer protocol, which tells their corresponding IPsec stacks > about it. > > For gateways (i.e. where the IPsec stack is not on the same box as the > ftp program, for example), this seems a bit harder, and NAT-like > traffic inspection would need to happen. Yuck. But code for that > exists already as well... So maybe this is feasible. yes - that is how many gateways detect the dynamic information. However using an external protocol to convey the information to peer will introduce additional latency. > > > Another alternative worth considering is to do policy change > > inband to ipsec traffic. After all, if a secure a channel has > > already been established with the peer, why not use the same channel > > for updating the selector information? > > > > That would require changes to IPsec that I would really not even want > to propose. The IPsec tunnel is for data traffic. Are you proposing > yet another protocol which runs inside an IPsec tunnel? Why bother? > You'd have the same latency. Maybe I'm misunderstanding. Having an inband way (yes - that may require ipsec tunnel to be accepting control traffic in addition to data traffic) allows the possiblity of piggybacking control information along with data within the ipsec tunnel. To me, that seems to be most efficient way to indicate to the other side about the change in ipsec selectors. The control channel can be put to other uses as well.. -- sankar -- > > jan > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > > From owner-ipsec@lists.tislabs.com Wed Mar 27 06:47:21 2002 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 g2RElLm18965; Wed, 27 Mar 2002 06:47:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01265 Wed, 27 Mar 2002 09:03:58 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Mar 2002 15:28:27 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVFo4AIGDI/HcaRu6L62T2jMKIjgABS8QQ From: "Sankar Ramamoorthi" To: "Jan Vilhuber" Cc: "Andrew Krywaniuk" , "Dan Harkins" , "IP Security List" X-OriginalArrivalTime: 26 Mar 2002 23:28:24.0033 (UTC) FILETIME=[EC6BA510:01C1D51D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA25361 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, March 26, 2002 2:38 PM > To: Sankar Ramamoorthi > Cc: Andrew Krywaniuk; Dan Harkins; IP Security List > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote: > > > > Another alternative worth considering is to do policy change > > > > inband to ipsec traffic. After all, if a secure a channel has > > > > already been established with the peer, why not use the > same channel > > > > for updating the selector information? > > > > > > > > > > That would require changes to IPsec that I would really > not even want > > > to propose. The IPsec tunnel is for data traffic. Are you > proposing > > > yet another protocol which runs inside an IPsec tunnel? > Why bother? > > > You'd have the same latency. Maybe I'm misunderstanding. > > > > Having an inband way (yes - that may require ipsec tunnel to > > be accepting control traffic in addition to data traffic) allows the > > possiblity of piggybacking control information along with data > > within the ipsec tunnel. To me, that seems to be most efficient > > way to indicate to the other side about the change in ipsec > selectors. > > The control channel can be put to other uses as well.. > > > > I must really be missing something, but that really sounds like an > inappropriate use of IPsec. This would essentially require changes to > everyone's IPsec stacks (especially the 'piggybacking' part), some of > which may reside in hardware. I agree that we should minimize/avoid changes to ipsec protocol since many people have it implemented in hardware - but does that make it immune to enhancement/changes? > > Let's try to keep the protocols separate. If you think that IKE isn't > the best place to do this, I would argue that ipsec is an even worse > place to do this. I would recommend that any proposed solution for the SA selector update take latency considerations into account. -- sankar -- > > jan > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Wed Mar 27 06:47:25 2002 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 g2RElPm18997; Wed, 27 Mar 2002 06:47:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01298 Wed, 27 Mar 2002 09:04:58 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Mar 2002 18:09:24 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVGsieF9Uro1TFTcqEYWucnOOlWQAFIUVw From: "Sankar Ramamoorthi" To: , "Jan Vilhuber" Cc: "Andrew Krywaniuk" , "Dan Harkins" , "IP Security List" X-OriginalArrivalTime: 27 Mar 2002 02:09:25.0409 (UTC) FILETIME=[6B0CA110:01C1D534] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA26486 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: andrew.krywaniuk@alcatel.com > [mailto:andrew.krywaniuk@alcatel.com] > Sent: Tuesday, March 26, 2002 3:01 PM > To: 'Jan Vilhuber'; Sankar Ramamoorthi > Cc: Andrew Krywaniuk; 'Dan Harkins'; 'IP Security List' > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > I don't necessarily have any objections to doing this through an IPsec > tunnel, but it should at least be a specialized control channel tunnel > rather than having it mixed in with IPsec-tunneled data. As you point out having a specialized ipsec control channel is equivalent to another isakmp message or some other protocol. The advantages of sending control messages in-band to an ipsec SA are 1) Control messages are authenticated and replay protected in the same manner as data packet - hence have the security property. 2) If necessary, control messages can piggyack data, thereby avoiding latency issues. For example if the ipsec selector needs to be broadend, the sender encapsulates the esp data packet in a control packet indicating the required selector change. The peer on receiving it will acknowledge the selector-change using another control packet(may or may not piggyback data along with it). The sender continues to send the data in encapsulated form till it receives the acknowledgement from the peer. 3) Control messages are inband and specific to the SA of interest. Since the control message follows the same path as data path, it could serve as a better way to check the health of the ipsec SA. -- sankar -- > I would suggest > that the transport mode connection between two gateways be > considered a > control channel, but it seems that the L2TP people have > already subsumed > this SA for their purposes. So it should probably be a > port-specific SA on > which the IPSP protocol would run. This solution, in turn, > necessitates a > 2-phase approach in order to negotiate the IPsec control channel. An > alternative is to create an ISAKMP message for this, which is > what most > people would have done before the great complexity crisis of '99. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > From owner-ipsec@lists.tislabs.com Wed Mar 27 06:47:43 2002 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 g2RElgm19058; Wed, 27 Mar 2002 06:47:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01260 Wed, 27 Mar 2002 09:03:53 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Mar 2002 14:03:50 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVDlevgzCHFqJ9Rl6om9NT6fB2UwAA4z5g From: "Sankar Ramamoorthi" To: "Scott G. Kelly" , "Markku Savela" Cc: X-OriginalArrivalTime: 26 Mar 2002 22:03:46.0272 (UTC) FILETIME=[19D6CE00:01C1D512] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA24805 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, Thanks for the clarification. Yes, I was implying changing the selector only - not the crypto policy. -- sankar -- > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@sonicwall.com] > Sent: Tuesday, March 26, 2002 1:41 PM > To: Markku Savela > Cc: Sankar Ramamoorthi; ipsec@lists.tislabs.com > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > Hi Marrku, > > Comments below... > > Markku Savela wrote: > > > > > From: "sankar ramamoorthi" > > > > > Another alternative worth considering is to do policy change > > > inband to ipsec traffic. > > > > NO! NO! You cannot change policy from IKE. > > > > There is some serious misunderstanding about what policy is. > > > > In my view policy can never be changed as a result of IKE > > negotiation. That would be a huge security hole. > > > > Surely you are not suggesting something like if, I have > > > > selector -> require ESP with 3DES > > > > IKE negotiation could change this into > > > > selector -> allow data in clear > > > > > I don't think anyone is suggesting that policy be changed by IKE. The > problem being addressed is that for some protocols (e.g. FTP), you > cannot know all of the associated selectors a priori, as some > selectors > are chosen dynamically during the protocol transaction. This > means that > to permit these within IPsec, you have to open up a whole range of > selectors. For example, to permit FTP, you have to open up > TCP from any > port to any port. The way many of us have gotten around this > is to open > up the tunnel, but use stateful inspection (outside of IPsec) to > regulate what actually goes through. However, this is not standard, so > we have no guarantee of interoperability in multivendor environments. > > When people have referred to changing or updating policy within this > thread, what (I think) they refer to is the ability to dynamically > update the selectors associated with a given SA based upon current > protocol state (which might better be referred to as changing the SAD > rather than the SPD). For example, it would be nice to have a > rule which > permits FTP explicitly, without opening all TCP ports. Such a > rule would > have to allow for dynamically updating the SA selectors based on the > content of the PORT command within FTP, i.e. it would have to rely on > stateful protocol monitoring. Currently, no such support is > standardized. > > The question is, should we be trying to solve this here, and > if so, how > can it be done? Obviously, any solution has implications for the SPD > first (as we need a way to represent such dynamic selectors > there), and > in IKE second, as there would be some associated TS payload(s). > > Scott > From owner-ipsec@lists.tislabs.com Wed Mar 27 06:48:30 2002 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 g2REmTm19212; Wed, 27 Mar 2002 06:48:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01296 Wed, 27 Mar 2002 09:04:54 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Mar 2002 20:10:49 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVGsieF9Uro1TFTcqEYWucnOOlWQAKktZg From: "Sankar Ramamoorthi" To: , "Jan Vilhuber" Cc: "Dan Harkins" , "IP Security List" X-OriginalArrivalTime: 27 Mar 2002 04:10:50.0432 (UTC) FILETIME=[6142EC00:01C1D545] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA27210 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My previous mail bounced. I am not if the mail made it to the list. Pardon me if you receive the mail twice. Resending the mail. > -----Original Message----- > From: andrew.krywaniuk@alcatel.com > [mailto:andrew.krywaniuk@alcatel.com] > Sent: Tuesday, March 26, 2002 3:01 PM > To: 'Jan Vilhuber'; Sankar Ramamoorthi > Cc: Andrew Krywaniuk; 'Dan Harkins'; 'IP Security List' > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > I don't necessarily have any objections to doing this through an IPsec > tunnel, but it should at least be a specialized control channel tunnel > rather than having it mixed in with IPsec-tunneled data. As you point out having a specialized ipsec control channel is equivalent to another isakmp message or some other protocol. The advantages of sending control messages in-band to an ipsec SA are 1) Control messages are authenticated and replay protected in the same manner as data packet - hence have the security property. 2) If necessary, control messages can piggyack data, thereby avoiding latency issues. For example if the ipsec selector needs to be broadend, the sender encapsulates the esp data packet in a control packet indicating the required selector change. The peer on receiving it will ack/nack the selector-change using another control packet(may or may not piggyback data along with it). The sender continues to send the data in encapsulated form till it receives the acknowledgement from the peer. 3) Control messages are inband and specific to the SA of interest. Since the control message follows the same path as data path, it could serve as a better way to check the health of the ipsec SA. -- sankar -- > I would suggest > that the transport mode connection between two gateways be > considered a > control channel, but it seems that the L2TP people have > already subsumed > this SA for their purposes. So it should probably be a > port-specific SA on > which the IPSP protocol would run. This solution, in turn, > necessitates a > 2-phase approach in order to negotiate the IPsec control channel. An > alternative is to create an ISAKMP message for this, which is > what most > people would have done before the great complexity crisis of '99. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Tuesday, March 26, 2002 5:38 PM > > To: Sankar Ramamoorthi > > Cc: Andrew Krywaniuk; Dan Harkins; IP Security List > > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) > > > > > > On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote: > > > > > Another alternative worth considering is to do policy change > > > > > inband to ipsec traffic. After all, if a secure a channel has > > > > > already been established with the peer, why not use the > > same channel > > > > > for updating the selector information? > > > > > > > > > > > > > That would require changes to IPsec that I would really > > not even want > > > > to propose. The IPsec tunnel is for data traffic. Are you > > proposing > > > > yet another protocol which runs inside an IPsec tunnel? > > Why bother? > > > > You'd have the same latency. Maybe I'm misunderstanding. > > > > > > Having an inband way (yes - that may require ipsec tunnel to > > > be accepting control traffic in addition to data traffic) > allows the > > > possiblity of piggybacking control information along with data > > > within the ipsec tunnel. To me, that seems to be most efficient > > > way to indicate to the other side about the change in ipsec > > selectors. > > > The control channel can be put to other uses as well.. > > > > > > > I must really be missing something, but that really sounds like an > > inappropriate use of IPsec. This would essentially require > changes to > > everyone's IPsec stacks (especially the 'piggybacking' > part), some of > > which may reside in hardware. > > > > Let's try to keep the protocols separate. If you think that > IKE isn't > > the best place to do this, I would argue that ipsec is an even worse > > place to do this. > > > > jan > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > From owner-ipsec@lists.tislabs.com Wed Mar 27 08:11:04 2002 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 g2RGB3m25995; Wed, 27 Mar 2002 08:11:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01888 Wed, 27 Mar 2002 10:32:38 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 27 Mar 2002 07:44:29 -0800 To: Jan Vilhuber From: Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:05 PM -0800 3/26/02, Jan Vilhuber wrote: >On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote: > > > Why is this a requirement? Has the lack of dynamic ports >> significantly hurt IKEv1? If so, what other protocol did the folks >> who required dynamic ports use? >> > >There is no other protocol they COULD use. And yet they exist today. This argues against dynamic ports being a requirement (although they could still be useful). > The workaround, as Scott >Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do >stateful filtering on both ends, which is not interoperable. If you >don't do stateful inspection, you simply keep all ports open and pass >more traffic than you were hoping for, which is also suboptimal. It is suboptimal, but it works today. Adding dynamic ports to IKE would certainly not simplify it or make it more understandable to end users. > > This sounds a lot like a rat-hole that will have next to no chance of >> interoperating and will not help many users. >> > >I think it WILL help many users. The ability to do dynamic port >additions (or even dynamic address additions) will make configurations >simpler (try 'ftp' instead of 'port 21 and whatever else ftp >negotiates'), and will not impact interoperability. Those aren't the options. The options are "FTP" or "all ports". "All ports" is understandable. > I think it's >fairly well defined in both angelos' draft for sctp and Pyda >Srisuresh's draft (of which I'm coauthor). This is not brain-surgery. Well, it is scary enough for this working group to have avoided it so far. >Given that ip telephony is being used more and more, and given that >h.323 is the mechanism (or one of them?) I'd say this is important. Important for some customers who only trust their communicating parties to use selected ports, yes. A requirement for all users, no. >Whether it needs to happen in IKE, or, as Hillarie suggested, as part >of some as yet unspecified protocol in IPSP is up for discussion, but >the problem must be addressed. Addressing it outside of IKE allows the parties who actually need it to use it, but those who don't need it and don't want to deal with the additional administration to ignore it. >Problem with doing it via IPSP is that (as someone else pointed out) >said IPSP protocol would need to be done before SOI can become an >RFC. I'd prefer not to make such a linking, since I don't think this >is overly complex... Opinions vary (obviously.. this is ipsec afterall). But does it have to be part of the key negotiation at all? This sounds like stuff that is done *after* key negotiation. If so, there is no linkage to SOI at all. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 27 09:30:56 2002 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 g2RHUtm29165; Wed, 27 Mar 2002 09:30:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02293 Wed, 27 Mar 2002 11:35:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15521.63350.373675.210058@pkoning.dev.equallogic.com> Date: Wed, 27 Mar 2002 11:46:46 -0500 From: Paul Koning To: Sankar.Ramamoorthi@nexsi.com Cc: ipsec@lists.tislabs.com Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sankar" == Sankar Ramamoorthi writes: Sankar> Having an inband way (yes - that may require ipsec tunnel to Sankar> be accepting control traffic in addition to data traffic) Sankar> allows the possiblity of piggybacking control information Sankar> along with data within the ipsec tunnel. To me, that seems to Sankar> be most efficient way to indicate to the other side about the Sankar> change in ipsec selectors. The control channel can be put to Sankar> other uses as well.. I may be reading too much into this, but this thread frightens me. Separating the control plane from the data plane is a well established design approach. It's universally applied in telecom, where high reliability is crucial. It's an essential design principle to achieve very high performance. The control channel messages have to be bound to the data channel they apply to. That's *all* that's needed for things to work. Yes, you can do that binding by embedding the control messages into the data channel, but only at the expense of making the high performance data plane implementation more difficult. It's much better to keep it separate and make the binding explicit. (IKE does that. So do protocols like ATM, or IP routing.) A somewhat different argument is the reuse of mechanisms. IKEv1 has SAs but they are a bit different from IPsec SAs, so the protection assurances do not directly carry over. It's a reasonable idea to use the same mechanisms rather than just "similar" mechanisms to protect control plane traffic. But the control plane SAs should remain separate from the data SAs. paul From owner-ipsec@lists.tislabs.com Wed Mar 27 09:47:46 2002 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 g2RHlkm29984; Wed, 27 Mar 2002 09:47:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02605 Wed, 27 Mar 2002 12:10:33 -0500 (EST) Date: Wed, 27 Mar 2002 09:21:55 -0800 (PST) From: Jan Vilhuber To: Paul Hoffman / VPNC cc: Subject: Re: Do we actually need dynamic ports? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 27 Mar 2002, Paul Hoffman / VPNC wrote: > At 5:05 PM -0800 3/26/02, Jan Vilhuber wrote: > >On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote: > > > > > Why is this a requirement? Has the lack of dynamic ports > >> significantly hurt IKEv1? If so, what other protocol did the folks > >> who required dynamic ports use? > >> > > > >There is no other protocol they COULD use. > > And yet they exist today. This argues against dynamic ports being a > requirement (although they could still be useful). > > > The workaround, as Scott > >Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do > >stateful filtering on both ends, which is not interoperable. If you > >don't do stateful inspection, you simply keep all ports open and pass > >more traffic than you were hoping for, which is also suboptimal. > > It is suboptimal, but it works today. > I hardly call that working. It's a hole in your security policy. Customers are forced to do this because of a short-coming in the protocol. I hardly call it workable. > Adding dynamic ports to IKE would certainly not simplify it or make > it more understandable to end users. > > > > This sounds a lot like a rat-hole that will have next to no chance of > >> interoperating and will not help many users. > >> > > > >I think it WILL help many users. The ability to do dynamic port > >additions (or even dynamic address additions) will make configurations > >simpler (try 'ftp' instead of 'port 21 and whatever else ftp > >negotiates'), and will not impact interoperability. > > Those aren't the options. The options are "FTP" or "all ports". "All > ports" is understandable. > Yes, but may not be what the local security policy OUGHT to be. It's too wide. > > I think it's > >fairly well defined in both angelos' draft for sctp and Pyda > >Srisuresh's draft (of which I'm coauthor). This is not brain-surgery. > > Well, it is scary enough for this working group to have avoided it so far. > All due to the moratorium on changes to IKE. > >Given that ip telephony is being used more and more, and given that > >h.323 is the mechanism (or one of them?) I'd say this is important. > > Important for some customers who only trust their communicating > parties to use selected ports, yes. A requirement for all users, no. > > >Whether it needs to happen in IKE, or, as Hillarie suggested, as part > >of some as yet unspecified protocol in IPSP is up for discussion, but > >the problem must be addressed. > > Addressing it outside of IKE allows the parties who actually need it > to use it, but those who don't need it and don't want to deal with > the additional administration to ignore it. > > >Problem with doing it via IPSP is that (as someone else pointed out) > >said IPSP protocol would need to be done before SOI can become an > >RFC. I'd prefer not to make such a linking, since I don't think this > >is overly complex... Opinions vary (obviously.. this is ipsec afterall). > > But does it have to be part of the key negotiation at all? This > sounds like stuff that is done *after* key negotiation. If so, there > is no linkage to SOI at all. > This is no different than creating a second SA, I suppose. You want traffic for the FTP data channel? Create a new SA for it. Alternatively, and this is what Pyda's and my draft does, pass an indicator that identifies the previous SA, and ADD to it. Saves memory, at almost no additional cost. I really don't see the problem here. We're taking the 'dumb down IKE' a BIT too far, I think. Is IKE a key management protocol? Or a key agreement protocol? To me it's a key management protocol. We can make SOI a key agreement protocol (as JFK suggests), but then we also need to come up with a management protocol on top of it. That doesn't exist yet, whereas a completely workable management protocol already exists in IKEv1 and improved in IKEv2. jan > --Paul Hoffman, Director > --VPN Consortium > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Mar 27 10:37:26 2002 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 g2RIbQm02910; Wed, 27 Mar 2002 10:37:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02740 Wed, 27 Mar 2002 12:32:50 -0500 (EST) Message-Id: <200203271744.g2RHiDs00914@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Requirements process suggestions In-reply-to: Your message of "Wed, 27 Mar 2002 08:47:35 EST." <5.1.0.14.0.20020327082908.00a66d90@localhost> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 27 Mar 2002 12:44:12 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Melinda" == Melinda Shore writes: Melinda> The requirements process doesn't seem to be going very well, Melinda> which isn't that surprising - requirements documents are hard Melinda> to do. I think it might be possible to have the son-of-IKE Melinda> requirements through WG last call before Yokohama Melinda> by applying some discipline, if that's what the working group Melinda> wants. Melinda> In particular, it's impossible to develop a good requirements Melinda> document by evaluating it in terms of whether or not it presents Melinda> a harmonious, pleasing whole. It's got to be taken apart and Melinda> put back together again. What I've found to be effective (but Melinda> a lot of work) is: Melinda> 1) take the requirements document, turn it into a numbered Melinda> list of crisp, declarative sentences Melinda> 2) make a quick first pass through the list and identify items Melinda> on which there's already consensus either to keep or to Melinda> drop. If there's any - *any* - disagreement about anything, Melinda> it goes on the "unresolved" list. Yes, I agree with this process. Make three lists: a) requirement is in scope (no debate) b) requirement is out of scope (it may never be discussed again) c) requirement is eligble for debate. Melinda> I've found that the only thing that requires face-to-face interaction Melinda> is item 2 - doing it on the mailing list is too slow. However, given Melinda> the 30-day-notice requirement for interim meetings waiting for an Melinda> interim meeting may take too long, too, and perhaps instead everything Melinda> could go on the unresolved list. It's a lot of work for the chairs We should start on the mailing list anyway. I am willing to keep track of the list. ] 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 Mar 27 11:45:49 2002 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 g2RJjnm06284; Wed, 27 Mar 2002 11:45:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03218 Wed, 27 Mar 2002 13:58:43 -0500 (EST) Date: Wed, 27 Mar 2002 21:10:34 +0200 Message-Id: <200203271910.VAA26163@burp.tkv.asdf.org> From: Markku Savela To: vilhuber@cisco.com CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: (message from Jan Vilhuber on Wed, 27 Mar 2002 09:21:55 -0800 (PST)) Subject: Re: Do we actually need dynamic ports? References: 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 > From: Jan Vilhuber > > Those aren't the options. The options are "FTP" or "all ports". "All > > ports" is understandable. > > > > Yes, but may not be what the local security policy OUGHT to be. It's > too wide. But, the question is: how is this widening going to happen? If it is some message which IKE receives from the other side "add this port to this SA", then we effectively have "all ports open". Say I have policy remote_port=21 -> FTP_SA remote_port=111 -> RPC_SA now I connect to some site with FTP, and this hostile site "widens" the FTP SA to allow traffic with port=111. Now, this other random site suddently has full access to my RPC stuff... Not GOOD! If there is any widening, it must be happening under control of my host (and even then there is a difficulty of verifying that this automatic widening does not open up any other holes...). => I'm still of opinion that any automatic messing with policy selectors or policy specifications is dangerous. At least, if you do that, you have to convince that operation does not open any security holes in any situation. From owner-ipsec@lists.tislabs.com Wed Mar 27 13:09:42 2002 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 g2RL9gm09041; Wed, 27 Mar 2002 13:09:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03786 Wed, 27 Mar 2002 15:24:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15522.11560.281000.964150@gargle.gargle.HOWL> Date: Wed, 27 Mar 2002 15:35:52 -0500 From: Paul Koning To: Sankar.Ramamoorthi@nexsi.com Cc: ipsec@lists.tislabs.com Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 27 March 2002) by Sankar Ramamoorthi: > >It's much better to keep it > >separate and make the binding explicit. (IKE does that. So do > >protocols like ATM, or IP routing.) > > Agreed. However it would still have been useful to leave some > room in the ESP header for conveying information about the session. What for? Is there information about the session that the *data plane* machinery needs to know about? I can think of none. > >A somewhat different argument is the reuse of mechanisms. IKEv1 has > >SAs but they are a bit different from IPsec SAs, so the protection > >assurances do not directly carry over. It's a reasonable idea to use > >the same mechanisms rather than just "similar" mechanisms to protect > >control plane traffic. But the control plane SAs should remain > >separate from the data SAs. > > Intresting ideas. If ESP had a flag field, it could be used to > identify a control channel - use the same keying material and SPI > as the data channel yet maintain the SAs separate. You misunderstood my suggestion. What I described requires NO change in ESP. I meant only to suggest that son-of-IKE could use the ESP packet formats and algorithms. In essence, SOI ends up running over an ESP transport mode (presumably) connection. But that requires no changes to ESP at all; it simply happens to be that some of the currently active SAs are protecting user data, and some are protecting SOI control traffic -- to ESP that makes no difference and it requires no change in any ESP hardware or fastpath software. Also, credit where it belongs: I was paraphrasing a proposal in the ikev2 draft. paul From owner-ipsec@lists.tislabs.com Wed Mar 27 13:13:01 2002 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 g2RLD1m09100; Wed, 27 Mar 2002 13:13:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03957 Wed, 27 Mar 2002 15:36:24 -0500 (EST) Message-Id: <4.3.2.7.2.20020327123547.0600be88@mira-sjcm-4.cisco.com> X-Sender: cmadson@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Mar 2002 12:47:54 -0800 To: Michael Richardson From: Cheryl Madson Subject: Re: Requirements process suggestions Cc: ipsec@lists.tislabs.com In-Reply-To: <200203271744.g2RHiDs00914@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good ideas. One plea: can we start with the scenarios? They should be key in helping to drive the itemized requirements list. We can't afford another "accommodate a subset of the scenarios and shoehorn in later the stuff we forgot". As I said in MSP, the WG needs to determine the following: (a) do the listed scenarios (admittedly some of them not all that well fleshed-out) the ones we want to be the list of core scenarios for SOI? What needs to be added? What needs to be removed? The core scenarios represent the things that *must* be accommodated by SOI and its companion protocols. If a scenario is in the list, and we don't meet it's needs, we've failed. [And we also don't want to expend a lot of excess energy on scenarios that the WG doesn't feel are important.] (b) I attempted a model to represent the key needs for each scenario. Is the model reasonable? Sufficient? (c) Look at the scenarios themselves. What's missing? What's incorrect? I desperately need help in fleshing out the mobile ip/wireless and IPv6 scenarios (v6 isn't simply a larger address; we need to start becoming more intelligent in addressing that problem space). I am hearing from certain folks that IPsec is a poor fit for these problem spaces; if so, now's the chance to influence future design. [In other words, those who care need to put some skin in the game...] When we make reasonable forward progress on the scenarios, I'll feel more comfortable about discussing the requirement line items... thx - C At 09:44 AM 3/27/2002, Michael Richardson wrote: > >>>>> "Melinda" == Melinda Shore writes: > Melinda> The requirements process doesn't seem to be going very well, > Melinda> which isn't that surprising - requirements documents are hard > Melinda> to do. I think it might be possible to have the son-of-IKE > Melinda> requirements through WG last call before Yokohama > Melinda> by applying some discipline, if that's what the working group > Melinda> wants. > > Melinda> In particular, it's impossible to develop a good requirements > Melinda> document by evaluating it in terms of whether or not it presents > Melinda> a harmonious, pleasing whole. It's got to be taken apart and > Melinda> put back together again. What I've found to be effective (but > Melinda> a lot of work) is: > > Melinda> 1) take the requirements document, turn it into a numbered > Melinda> list of crisp, declarative sentences > Melinda> 2) make a quick first pass through the list and identify items > Melinda> on which there's already consensus either to keep or to > Melinda> drop. If there's any - *any* - disagreement about anything, > Melinda> it goes on the "unresolved" list. > > Yes, I agree with this process. Make three lists: > a) requirement is in scope (no debate) > b) requirement is out of scope (it may never be discussed again) > c) requirement is eligble for debate. > > Melinda> I've found that the only thing that requires face-to-face > interaction > Melinda> is item 2 - doing it on the mailing list is too > slow. However, given > Melinda> the 30-day-notice requirement for interim meetings waiting > for an > Melinda> interim meeting may take too long, too, and perhaps instead > everything > Melinda> could go on the unresolved list. It's a lot of work for the > chairs > > We should start on the mailing list anyway. > > I am willing to keep track of the list. > >] 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"); [ ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Wed Mar 27 13:51:40 2002 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 g2RLpdm10944; Wed, 27 Mar 2002 13:51:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04151 Wed, 27 Mar 2002 16:14:19 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Mar 2002 12:20:07 -0800 Message-ID: Thread-Topic: Move TS to optional (RE: Don't remove TS from IKEv2) Thread-Index: AcHVulwUo8lW8fNwRg2Txtgod35K4QAEUxFg From: "Sankar Ramamoorthi" To: "Paul Koning" Cc: X-OriginalArrivalTime: 27 Mar 2002 20:20:08.0177 (UTC) FILETIME=[C9FA8E10:01C1D5CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA03745 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>>> "Sankar" == Sankar Ramamoorthi writes: > > Sankar> Having an inband way (yes - that may require ipsec tunnel to > Sankar> be accepting control traffic in addition to data traffic) > Sankar> allows the possiblity of piggybacking control information > Sankar> along with data within the ipsec tunnel. To me, that seems to > Sankar> be most efficient way to indicate to the other side about the > Sankar> change in ipsec selectors. The control channel can be put to > Sankar> other uses as well.. > >I may be reading too much into this, but this thread frightens me. > >Separating the control plane from the data plane is a well established >design approach. It's universally applied in telecom, where high >reliability is crucial. It's an essential design principle to >achieve very high performance. > >The control channel messages have to be bound to the data channel they >apply to. That's *all* that's needed for things to work. Yes, you >can do that binding by embedding the control messages into the data >channel, but only at the expense of making the high performance data >plane implementation more difficult. I think I used the word 'control' too liberally in my messages. I would argue that even in protocols like IP, TCP certain amount of control information is passed along with the data in flag field of the header. The control information may be describing an attribute of a specific data packet (such as DF bit in the IP header) or may affect the entire session (such as RST bit in the TCP header). Unfortunately ESP does not have a flag field. I would also argue that TCP has really no separation of control and data (acknowledgement of TCP connection establishment is carried in the first data packet, and data packets can carry information to teardown the sesson.). >It's much better to keep it >separate and make the binding explicit. (IKE does that. So do >protocols like ATM, or IP routing.) > Agreed. However it would still have been useful to leave some room in the ESP header for conveying information about the session. >A somewhat different argument is the reuse of mechanisms. IKEv1 has >SAs but they are a bit different from IPsec SAs, so the protection >assurances do not directly carry over. It's a reasonable idea to use >the same mechanisms rather than just "similar" mechanisms to protect >control plane traffic. But the control plane SAs should remain >separate from the data SAs. > Intresting ideas. If ESP had a flag field, it could be used to identify a control channel - use the same keying material and SPI as the data channel yet maintain the SAs separate. > paul > From owner-ipsec@lists.tislabs.com Wed Mar 27 13:53:38 2002 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 g2RLrcm10995; Wed, 27 Mar 2002 13:53:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04198 Wed, 27 Mar 2002 16:19:59 -0500 (EST) Date: Wed, 27 Mar 2002 23:31:44 +0200 Message-Id: <200203272131.XAA26378@burp.tkv.asdf.org> From: Markku Savela To: andrew.krywaniuk@alcatel.com CC: vilhuber@cisco.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: <000a01c1d5d1$51788aa0$1e72788a@ca.alcatel.com> (andrew.krywaniuk@alcatel.com) Subject: Re: Do we actually need dynamic ports? References: <000a01c1d5d1$51788aa0$1e72788a@ca.alcatel.com> 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 > From: "Andrew Krywaniuk" > When I say I want to add selector X to an existing SA, I am not asking you > to open up a security hole. I am saying something like "I believe that we > have opened up an FTP session on port X and I want to protect it." You > should be able to decide, based on local policy, whether you accept the > widening of the SA. And note that 'widening' does not necessarily imply a > range of ports; it could simply be a list of non-contiguous ports that does > not cover your precious RPC traffic. Yes, if you can statically express in your policy the allowed "widening", something like (or whatever) remote_port=21 = FTP_SA ("widenrange=2000-4000") Then there is no problem. However, the problem was, that there was no preknowledge about the possible port that was to be added. So, if other site gets to decide on the port, widening could hit on any port. After packets come in using FTP_SA and get accepted, there is nothing after that which would verify that they would end up with the FTP application, instead any service on the port is free game. > So I am not asking you to add new rules to your SPD. I am asking you to > create an instantiation of a template rule which already existed in your > SPD, and which is subject to dynamic session data. Ahh, you mean my node "sniffs" the FTP traffic and finds the port there, and this port gets opened? Perhaps this is sufficient, if the widening is bound to connection (e.g. both remote and local port are included). I'm only concerned whether all aspects of this widening have been considered. From owner-ipsec@lists.tislabs.com Wed Mar 27 14:18:14 2002 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 g2RMIDm11508; Wed, 27 Mar 2002 14:18:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03982 Wed, 27 Mar 2002 15:48:43 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Markku Savela'" , Cc: , Subject: RE: Do we actually need dynamic ports? Date: Wed, 27 Mar 2002 15:52:31 -0500 Message-ID: <000a01c1d5d1$51788aa0$1e72788a@ca.alcatel.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 In-reply-to: <200203271910.VAA26163@burp.tkv.asdf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, your rant from yesterday was *way* off base. I thought people had successfully explained why, but apparently not. Just as there is a distinction between a key management protocol and a key agreement protocol, there is a difference between a policy management protocol and a policy agreement protocol. IF, as it seems to be the case, people want to create port/protocol constrained-SAs (I have argued against this many times, but it seems that I am always outvoted), then there needs to be a way to agree on the selectors that are being used. When I say I want to add selector X to an existing SA, I am not asking you to open up a security hole. I am saying something like "I believe that we have opened up an FTP session on port X and I want to protect it." You should be able to decide, based on local policy, whether you accept the widening of the SA. And note that 'widening' does not necessarily imply a range of ports; it could simply be a list of non-contiguous ports that does not cover your precious RPC traffic. So I am not asking you to add new rules to your SPD. I am asking you to create an instantiation of a template rule which already existed in your SPD, and which is subject to dynamic session data. I would argue that this could be accomplished more cleanly by a non-interactive policy agreement protocol (e.g. send a list of the rules you will enforce, rather than a TS), but you can't ignore the issue altogether. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela > Sent: Wednesday, March 27, 2002 2:11 PM > To: vilhuber@cisco.com > Cc: paul.hoffman@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Do we actually need dynamic ports? > > > > From: Jan Vilhuber > > > > Those aren't the options. The options are "FTP" or "all > ports". "All > > > ports" is understandable. > > > > > > > Yes, but may not be what the local security policy OUGHT to be. It's > > too wide. > > But, the question is: how is this widening going to happen? If it is > some message which IKE receives from the other side "add this port to > this SA", then we effectively have "all ports open". > > Say I have policy > > remote_port=21 -> FTP_SA > remote_port=111 -> RPC_SA > > now I connect to some site with FTP, and this hostile site "widens" > the FTP SA to allow traffic with port=111. Now, this other random site > suddently has full access to my RPC stuff... Not GOOD! > > If there is any widening, it must be happening under control of my > host (and even then there is a difficulty of verifying that this > automatic widening does not open up any other holes...). > > => I'm still of opinion that any automatic messing with policy > selectors or policy specifications is dangerous. > > At least, if you do that, you have to convince that operation does not > open any security holes in any situation. > > > > From owner-ipsec@lists.tislabs.com Wed Mar 27 14:35:46 2002 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 g2RMZjm11883; Wed, 27 Mar 2002 14:35:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04324 Wed, 27 Mar 2002 16:43:19 -0500 (EST) Message-Id: <5.1.0.14.0.20020327165030.00a7a140@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Mar 2002 16:58:29 -0500 To: ipsec@lists.tislabs.com From: Melinda Shore Subject: More on requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm being heavy on process here and light on technical content, and I'll apologize in advance for that. After last week's sessions I'm very concerned about the working group's ability to make progress, and as an application consumer of IPSec services it matters to me a lot. Cheryl's document is really, really useful, doing a particularly good job of framing the issues that need to be resolved and presenting the scoping question much more clearly than I've seen elsewhere. However, in its current form it's not really a requirements documents. Requirements documents need to present, uh, requirements and not a whole lot more. I know the question of splitting the document in two has come up before and I think it's a very good idea. FWIW, I think that the sacred requirements document provides a pretty good example of laying out requirements clearly while still providing some discussion. Melinda From owner-ipsec@lists.tislabs.com Wed Mar 27 14:46:27 2002 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 g2RMkQm12152; Wed, 27 Mar 2002 14:46:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04514 Wed, 27 Mar 2002 17:13:57 -0500 (EST) Message-ID: <002a01c1d5dd$dfd4d2c0$05004c0a@rmohan> From: "Rajesh Mohan" To: "Markku Savela" , Cc: , References: <200203271910.VAA26163@burp.tkv.asdf.org> Subject: Re: Do we actually need dynamic ports? Date: Wed, 27 Mar 2002 14:22:25 -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 > But, the question is: how is this widening going to happen? If it is > some message which IKE receives from the other side "add this port to > this SA", then we effectively have "all ports open". > In some environments, it may be ok to agree to open all ports. In these environments, you trust the other end and you are using the tunnel only to protect the traffic from public network. In these environments, the fact that a packet made through a tunnel is good enough. Ofcourse there are cases where you cannot trust the other end to use the tunnel for what it is meant. So, in these cases the selectors should not be dynamic. Maybe what we need is a flag in the selectors to say if it is dynamic. The negotiation succeeds only if both ends specify that the selectors are dynamic. If the two ends agree to use dynamic selectors, then we do not need any control messages to tell the other end to open new ports. When a authenticated packet is received, it means the other end wants the selectors widened. To delete the dynamically added ports, we can use regular IKE messages as they are no timing issues with that. From owner-ipsec@lists.tislabs.com Wed Mar 27 16:58:03 2002 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 g2S0w2m15054; Wed, 27 Mar 2002 16:58:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05120 Wed, 27 Mar 2002 19:15:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <002201c1d43a$bb9ffaa0$1e72788a@ca.alcatel.com> References: <002201c1d43a$bb9ffaa0$1e72788a@ca.alcatel.com> Date: Wed, 27 Mar 2002 19:20:50 -0500 To: From: Stephen Kent Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:22 PM -0500 3/25/02, Andrew Krywaniuk wrote: > > I'm glad you mentioned what I consider to be a significant downside >> of pre-shared secrets, although we come to very different >> conclusions. It is not too hard to imagine an attack in which the >> initiator connects to the wrong address, e.g., via some form of DNS >> attack, and the fake responder collects the initiator's secret, then >> drops the connection. This seems like such a serious concern that it >> argues very strongly against pre-shared secrets vs. public keys. Note >> that using public keys. e.g., in self-signed certs, does not suffer >> from this problem. > >Steve, > >I don't understand your comment. Obviously, I'm only talking about IKE >pre-shared secrets, in which the bogus responder only collects an HMAC of >the shared secret and some session data. Now, which is harder: cracking an >RSA key or reversing an HMAC? Again, it depends on the key lengths involved, >but HMAC provides more security per bit. Your attack wouldn't work unless >the initiator was using a weak secret that could be cracked by brute force. Andrew, I assume that the shared secret does not have nearly as much entropy as an RSA key, which many folks agree is likely in the vast majority of instances. Thus the attack consists of testing guesses against the collected HMAC, since the rest of the HMAC inputs are known to the responder. This allows the attacker to carry out an offline guessing attack, which is less likely to arouse suspicion that online connection attempts with guesses shared secret values. Steve From owner-ipsec@lists.tislabs.com Wed Mar 27 17:50:58 2002 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 g2S1owm16053; Wed, 27 Mar 2002 17:50:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05539 Wed, 27 Mar 2002 20:15:16 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 27 Mar 2002 20:24:02 -0500 To: "Sankar Ramamoorthi" From: Stephen Kent Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Cc: "IP Security List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think it worth noting that there is considerable pressure to not make the ESP header any larger. Good engineering practice suggests that if additional signaling info is needed only infrequently, relative to the vast majority of traffic sent on an SA, then it makes more sense to perform the signalling in a fashion that does not increase the size of the header for the vast majority of the traffic, and that does not add additional processing burden (e.g., examination of any part of the packet) for that vast majority. The ESP header has no spare bits available for signalling; it consists of only the the SPI and the sequence number. Adding info to the trailer would violate the second of my suggestions above, re additional examination. I'd suggest we think in terms of additional phase 2 exchanges in SOI. Steve From owner-ipsec@lists.tislabs.com Wed Mar 27 18:25:18 2002 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 g2S2PIm16770; Wed, 27 Mar 2002 18:25:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05726 Wed, 27 Mar 2002 20:48:54 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 27 Mar 2002 18:00:48 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: User interface ciphersuites for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ciphersuites would greatly increase interoperability in deployments by reducing the number of knobs a user has to twiddle in order to match two IPsec systems. The IKEv2 design rationale document says that the authors wanted to do ciphersuites but didn't because they heard a lot of objections that "people preferred to negotiate individual algorithms". It is highly doubtful that end users stated this preference; it is much more likely that implementors did so that they could accommodate a few users who think they get more security with more choices. IKEv2 can have both the flexibility of individual mixing and matching of algorithms and the simplicity of ciphersuites at the same time. Suites can be specified as user interface items and implementations can be told that they should implement at least one of them (the one that matches the mandatory-to-implement algorithms). The suites can be given letters (because the numbers are already taken for DH groups), and a few could be listed in the document, and additional ones can being added later by IANA. The initial ones might be: Suite A Phase 1: AES-128, SHA-1, preshared keys, MODP group 5 Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode Suite B Phase 1: AES-128, SHA-1, RSA certs, MODP group 5 Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode Suite C Phase 1: TripleDES, MD-5, signed DH, MODP group 2 Phase 2: TripleDES, MD-5, MODP group 2, ESP tunnel mode A is the mandatory-to-implement algorithms with preshared keys, B is the same but with certs. C is secure and can be used in case there is a catastrophic defeat of AES, SHA-1, or MODP group 5. We would also define a handful of others that we are sure will be used significantly used, such as ones with no PFS. We don't have to list every possible combination, only a handful that we think will help users. For all other combinations, they can twiddle the options in the rest of the UI. Note that these suites are for the UI only: they do no change the bits-on-the-wire messages at all. The system has to translate the ciphersuites into the proper options for the wire protocol. If adopted, this could be the most significant user-visible change from IKEv1 and will probably get a great deal more interest in successor-to-IKE than most of the other things we have talked about so far. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 28 07:58:20 2002 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 g2SFwJm06796; Thu, 28 Mar 2002 07:58:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10212 Thu, 28 Mar 2002 10:15:30 -0500 (EST) Message-ID: <3CA328F7.2584177@torrentnet.com> Date: Thu, 28 Mar 2002 09:30:15 -0500 From: James Comen X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Question about IPSEC DOI Content-Type: multipart/alternative; boundary="------------E1796B09A13713643ADA528C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------E1796B09A13713643ADA528C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I apologize if this is not the forum for this question - if not, please suggest an alternative. I'm curious about how to represent 'any ip address' in an identification payload In the ipsec doi, section 4.6.2 describes the identification payload content. Within that section, subsection 4.6.2.5 describes 'ID_IPV4_ADDR_SUBNET'. "It says that Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit" If I understand this correctly, do I represent 'any ip address' as '0.0.0.0'? I assume there is no special representation of 'any ip address' Thanks in advance, Jim Comen -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 --------------E1796B09A13713643ADA528C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I apologize if this is not the forum for this question - if not, please suggest an alternative.

I'm curious about how to represent 'any ip address' in an identification payload
In the ipsec doi, section 4.6.2 describes the identification payload content.

Within that section, subsection 4.6.2.5 describes 'ID_IPV4_ADDR_SUBNET'.

"It says that Note that ones (1s) in
   the network mask indicate that the corresponding bit in the address
   is fixed, while zeros (0s) indicate a "wildcard" bit"

If I understand this correctly, do I represent 'any ip address' as '0.0.0.0'?
I assume there is no special representation of 'any ip address'

Thanks in advance,
Jim Comen

-- 
Jim Comen                           jcomen@torrentnet.com
Ericsson IP Infrastructure          Voice (919) 472 - 9932
920 Main Campus Drive, Suite 544    Fax   (919) 472 - 9999
Raleigh, NC 27606
  --------------E1796B09A13713643ADA528C-- From owner-ipsec@lists.tislabs.com Thu Mar 28 07:58:24 2002 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 g2SFwNm06810; Thu, 28 Mar 2002 07:58:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10196 Thu, 28 Mar 2002 10:12:31 -0500 (EST) Message-Id: <5.1.0.14.0.20020328005655.00a30250@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Mar 2002 01:13:51 -0500 To: Stephen Kent From: David Jablon Subject: RE: pre-shared key v RSA encryption or RSA signature authentication modes Cc: , In-Reply-To: References: <002201c1d43a$bb9ffaa0$1e72788a@ca.alcatel.com> <002201c1d43a$bb9ffaa0$1e72788a@ca.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shared keys and shared passwords are two entirely different types of authenticators. These kinds of arguments often go around in circles because people blur this distinction. Also, it adds to the confusion when people use ambiguous language for authenticator and the method for authentication. For example, I've heard "pre-shared key" used in the following contexts: a shared key a shared password the IPsec pre-shared key mode the IPsec pre-shared key mode abused with a password-based key Shared passwords can work fine as authenticators in some methods, but they fail miserably when used as keys in the IKE pre-shared key mode. -- David At 07:20 PM 3/27/02 -0500, Stephen Kent wrote: >At 3:22 PM -0500 3/25/02, Andrew Krywaniuk wrote: >> > I'm glad you mentioned what I consider to be a significant downside >>> of pre-shared secrets, although we come to very different >>> conclusions. It is not too hard to imagine an attack in which the >>> initiator connects to the wrong address, e.g., via some form of DNS >>> attack, and the fake responder collects the initiator's secret, then >>> drops the connection. This seems like such a serious concern that it >>> argues very strongly against pre-shared secrets vs. public keys. Note >>> that using public keys. e.g., in self-signed certs, does not suffer >>> from this problem. >> >>Steve, >> >>I don't understand your comment. Obviously, I'm only talking about IKE >>pre-shared secrets, in which the bogus responder only collects an HMAC of >>the shared secret and some session data. Now, which is harder: cracking an >>RSA key or reversing an HMAC? Again, it depends on the key lengths involved, >>but HMAC provides more security per bit. Your attack wouldn't work unless >>the initiator was using a weak secret that could be cracked by brute force. > >Andrew, > >I assume that the shared secret does not have nearly as much entropy as an RSA key, which many folks agree is likely in the vast majority of instances. Thus the attack consists of testing guesses against the collected HMAC, since the rest of the HMAC inputs are known to the responder. This allows the attacker to carry out an offline guessing attack, which is less likely to arouse suspicion that online connection attempts with guesses shared secret values. > >Steve From owner-ipsec@lists.tislabs.com Thu Mar 28 08:00:25 2002 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 g2SG0Pm06932; Thu, 28 Mar 2002 08:00:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10204 Thu, 28 Mar 2002 10:13:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Do we actually need dynamic ports? Date: Wed, 27 Mar 2002 18:47:10 -0700 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHVrN8Qx9BufLz9S462+yRMUsBwMAAP+TcA From: "Mani, Mahalingam (Mahalingam)" To: "Paul Hoffman / VPNC" , "Jan Vilhuber" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA05644 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There's a definite justification to be made for an increasing number of (peer-peer) protocols that negotiate dynamic ports, such as in H.323, that prividing for it in SOI will not only actually make it less of a rat-hole for securing the protocols but also prevent / minimize invention of drastic number of new security protocol variations replicated for each such special cases (protocols). Considering better applicability of SOI to such protocols should probably become one of SOI requirements as well. - though not at the expense of making IKEv2 more complex. Extensibility to protocol without complicating the base protocol is another challenge. This helps scale the efforts of Security Area Directorate efforts at securing other protocols as well. > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, March 27, 2002 7:44 AM > To: Jan Vilhuber > Cc: ipsec@lists.tislabs.com > Subject: Re: Do we actually need dynamic ports? > > > At 5:05 PM -0800 3/26/02, Jan Vilhuber wrote: > >On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote: > > > > > Why is this a requirement? Has the lack of dynamic ports > >> significantly hurt IKEv1? If so, what other protocol did the folks > >> who required dynamic ports use? > >> > > > >There is no other protocol they COULD use. > > And yet they exist today. This argues against dynamic ports being a > requirement (although they could still be useful). > This means IKE/IPsec is not conducive to secure their protocols - even if it could otherwise have been > > The workaround, as Scott > >Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do > >stateful filtering on both ends, which is not interoperable. If you > >don't do stateful inspection, you simply keep all ports open and pass > >more traffic than you were hoping for, which is also suboptimal. > > It is suboptimal, but it works today. > > Adding dynamic ports to IKE would certainly not simplify it or make > it more understandable to end users. But doing so extensibly is not going to make it any less understandable. > > > > This sounds a lot like a rat-hole that will have next to > no chance of > >> interoperating and will not help many users. > >> > > > >I think it WILL help many users. The ability to do dynamic port > >additions (or even dynamic address additions) will make > configurations > >simpler (try 'ftp' instead of 'port 21 and whatever else ftp > >negotiates'), and will not impact interoperability. > > Those aren't the options. The options are "FTP" or "all ports". "All > ports" is understandable. > > > I think it's > >fairly well defined in both angelos' draft for sctp and Pyda > >Srisuresh's draft (of which I'm coauthor). This is not brain-surgery. > > Well, it is scary enough for this working group to have > avoided it so far. > > >Given that ip telephony is being used more and more, and given that > >h.323 is the mechanism (or one of them?) I'd say this is important. > > Important for some customers who only trust their communicating > parties to use selected ports, yes. A requirement for all users, no. > > >Whether it needs to happen in IKE, or, as Hillarie suggested, as part > >of some as yet unspecified protocol in IPSP is up for discussion, but > >the problem must be addressed. > > Addressing it outside of IKE allows the parties who actually need it > to use it, but those who don't need it and don't want to deal with > the additional administration to ignore it. > It does not have to carry additional administration baggage for those who don't need it. > >Problem with doing it via IPSP is that (as someone else pointed out) > >said IPSP protocol would need to be done before SOI can become an > >RFC. I'd prefer not to make such a linking, since I don't think this > >is overly complex... Opinions vary (obviously.. this is > ipsec afterall). > > But does it have to be part of the key negotiation at all? This > sounds like stuff that is done *after* key negotiation. If so, there > is no linkage to SOI at all. Inasmuch as we allow for Transport level selectors to be negotiated this is equally fair game. > > --Paul Hoffman, Director > --VPN Consortium > -mani From owner-ipsec@lists.tislabs.com Thu Mar 28 09:59:29 2002 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 g2SHxSm12672; Thu, 28 Mar 2002 09:59:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10969 Thu, 28 Mar 2002 12:20:31 -0500 (EST) Message-ID: <3CA353E0.67FEB7F3@sonicwall.com> Date: Thu, 28 Mar 2002 09:33:20 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mani, Mahalingam (Mahalingam)" CC: Paul Hoffman / VPNC , Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Do we actually need dynamic ports? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2002 17:33:03.0178 (UTC) FILETIME=[9D06DAA0:01C1D67E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think a distinction should be made here: support for dynamic selectors is first an IPsec architecture issue, and then maybe a SOI issue. If we don't have a way to express such a policy in the SPD, then the rest of the discussion is moot. If we do come up with a way, then we next need to discuss whether we need special signalling to support this functionality, or whether the required selector adaptations can be made dynamically by each end of the SA via protocol inspection. Scott "Mani, Mahalingam (Mahalingam)" wrote: > > There's a definite justification to be made for an increasing number of (peer-peer) protocols that negotiate dynamic > ports, such as in H.323, that prividing for it in SOI will not only actually make it less of a rat-hole for securing > the protocols but also prevent / minimize invention of drastic number of new security protocol variations replicated for > each such special cases (protocols). > > Considering better applicability of SOI to such protocols should probably become one of SOI requirements as well. > - though not at the expense of making IKEv2 more complex. > > Extensibility to protocol without complicating the base protocol is another challenge. > > This helps scale the efforts of Security Area Directorate efforts at securing other protocols as well. > > > -----Original Message----- > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > Sent: Wednesday, March 27, 2002 7:44 AM > > To: Jan Vilhuber > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Do we actually need dynamic ports? > > > > > > At 5:05 PM -0800 3/26/02, Jan Vilhuber wrote: > > >On Tue, 26 Mar 2002, Paul Hoffman / VPNC wrote: > > > > > > > Why is this a requirement? Has the lack of dynamic ports > > >> significantly hurt IKEv1? If so, what other protocol did the folks > > >> who required dynamic ports use? > > >> > > > > > >There is no other protocol they COULD use. > > > > And yet they exist today. This argues against dynamic ports being a > > requirement (although they could still be useful). > > > > This means IKE/IPsec is not conducive to secure their protocols - even if it could otherwise have been > > > > The workaround, as Scott > > >Kelly posted, is to open up ALL TCP ports (in the case of FTP) and do > > >stateful filtering on both ends, which is not interoperable. If you > > >don't do stateful inspection, you simply keep all ports open and pass > > >more traffic than you were hoping for, which is also suboptimal. > > > > It is suboptimal, but it works today. > > > > Adding dynamic ports to IKE would certainly not simplify it or make > > it more understandable to end users. > > But doing so extensibly is not going to make it any less understandable. > > > > > > > This sounds a lot like a rat-hole that will have next to > > no chance of > > >> interoperating and will not help many users. > > >> > > > > > >I think it WILL help many users. The ability to do dynamic port > > >additions (or even dynamic address additions) will make > > configurations > > >simpler (try 'ftp' instead of 'port 21 and whatever else ftp > > >negotiates'), and will not impact interoperability. > > > > Those aren't the options. The options are "FTP" or "all ports". "All > > ports" is understandable. > > > > > I think it's > > >fairly well defined in both angelos' draft for sctp and Pyda > > >Srisuresh's draft (of which I'm coauthor). This is not brain-surgery. > > > > Well, it is scary enough for this working group to have > > avoided it so far. > > > > >Given that ip telephony is being used more and more, and given that > > >h.323 is the mechanism (or one of them?) I'd say this is important. > > > > Important for some customers who only trust their communicating > > parties to use selected ports, yes. A requirement for all users, no. > > > > >Whether it needs to happen in IKE, or, as Hillarie suggested, as part > > >of some as yet unspecified protocol in IPSP is up for discussion, but > > >the problem must be addressed. > > > > Addressing it outside of IKE allows the parties who actually need it > > to use it, but those who don't need it and don't want to deal with > > the additional administration to ignore it. > > > > It does not have to carry additional administration baggage for those who don't need it. > > > >Problem with doing it via IPSP is that (as someone else pointed out) > > >said IPSP protocol would need to be done before SOI can become an > > >RFC. I'd prefer not to make such a linking, since I don't think this > > >is overly complex... Opinions vary (obviously.. this is > > ipsec afterall). > > > > But does it have to be part of the key negotiation at all? This > > sounds like stuff that is done *after* key negotiation. If so, there > > is no linkage to SOI at all. > > Inasmuch as we allow for Transport level selectors to be negotiated this is equally fair game. > > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > -mani From owner-ipsec@lists.tislabs.com Thu Mar 28 09:59:30 2002 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 g2SHxUm12684; Thu, 28 Mar 2002 09:59:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10963 Thu, 28 Mar 2002 12:20:20 -0500 (EST) 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="iso-8859-1" Subject: RE: User interface ciphersuites for IKEv2 Date: Thu, 28 Mar 2002 09:32:53 -0800 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF5BC@USEXCH3.us.sonicwall.com> Thread-Topic: User interface ciphersuites for IKEv2 Thread-Index: AcHV/vkDnfRalCOCQNa4hEkOhmGFEgAfW/fw From: "Ricky Charlet" To: "'Paul Hoffman / VPNC'" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA10960 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I agree with Paul's point about having a 'simple' choice-already-made set of cipher suites. But I would add one tempering note. We have an expectation that 'recomended' cipher suites may change over time. New actions from inventors, standards bodies or certification bodies may lend credence to new crypto tools not considered at the time of 2nd Generation IKE (looking for a neutral term there) standardization. New cryptanalysis developments may take credence away from crypto tools which were highly regarded at the time of 2nd Generation IKE standardization. About 2 years ago (I think at Washington DC, or perhaps Adelaide) there was a discussion on this very topic at SAAG where there was a well received suggestion about how to handle a documentation process which could track this dynamism. Who remembers what that suggestion was in particular, and isn't it about time we start doing something like that? -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, March 27, 2002 6:01 PM > To: ipsec@lists.tislabs.com > Subject: User interface ciphersuites for IKEv2 > > > Ciphersuites would greatly increase interoperability in deployments by > reducing the number of knobs a user has to twiddle in order > to match two > IPsec systems. The IKEv2 design rationale document says that > the authors > wanted to do ciphersuites but didn't because they heard a lot of > objections that "people preferred to negotiate individual algorithms". > It is highly doubtful that end users stated this preference; > it is much > more likely that implementors did so that they could accommodate a few > users who think they get more security with more choices. > > IKEv2 can have both the flexibility of individual mixing and > matching of > algorithms and the simplicity of ciphersuites at the same time. Suites > can be specified as user interface items and implementations > can be told > that they should implement at least one of them (the one that matches > the mandatory-to-implement algorithms). The suites can be > given letters > (because the numbers are already taken for DH groups), and a few could > be listed in the document, and additional ones can being > added later by > IANA. The initial ones might be: > > Suite A > Phase 1: AES-128, SHA-1, preshared keys, MODP group 5 > Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode > > Suite B > Phase 1: AES-128, SHA-1, RSA certs, MODP group 5 > Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode > > Suite C > Phase 1: TripleDES, MD-5, signed DH, MODP group 2 > Phase 2: TripleDES, MD-5, MODP group 2, ESP tunnel mode > > A is the mandatory-to-implement algorithms with preshared > keys, B is the > same but with certs. C is secure and can be used in case there is a > catastrophic defeat of AES, SHA-1, or MODP group 5. We would > also define > a handful of others that we are sure will be used significantly used, > such as ones with no PFS. We don't have to list every possible > combination, only a handful that we think will help users. > For all other > combinations, they can twiddle the options in the rest of the UI. > > Note that these suites are for the UI only: they do no change the > bits-on-the-wire messages at all. The system has to translate the > ciphersuites into the proper options for the wire protocol. > > If adopted, this could be the most significant user-visible > change from > IKEv1 and will probably get a great deal more interest in > successor-to-IKE than most of the other things we have talked about so > far. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu Mar 28 10:13:32 2002 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 g2SIDVm13194; Thu, 28 Mar 2002 10:13:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11074 Thu, 28 Mar 2002 12:40:39 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <7B8824D690092B4B90B0EF4674750A65022DF5BC@USEXCH3.us.sonicwall.com> References: <7B8824D690092B4B90B0EF4674750A65022DF5BC@USEXCH3.us.sonicwall.com> Date: Thu, 28 Mar 2002 09:52:27 -0800 To: "Ricky Charlet" , From: Paul Hoffman / VPNC Subject: RE: User interface ciphersuites for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky is right about us possibly changing the recommended crypto. That's why I proposed that the list of suites could be expanded in an IANA registry. I don't want that expansion to be easy (to prevent vanity suites that do not help end users), but if we later decide that we now support WhizzySign and SuperEnc, we can easily make a suite for them. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 28 10:16:17 2002 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 g2SIGGm13260; Thu, 28 Mar 2002 10:16:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11112 Thu, 28 Mar 2002 12:45:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.22894.156276.224843@pkoning.dev.equallogic.com> Date: Thu, 28 Mar 2002 12:57:02 -0500 From: Paul Koning To: mmani@avaya.com Cc: ipsec@lists.tislabs.com Subject: RE: Do we actually need dynamic ports? References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mahalingam" == Mahalingam writes: Mahalingam> There's a definite justification to be made for an Mahalingam> increasing number of (peer-peer) protocols that negotiate Mahalingam> dynamic ports, such as in H.323, ... How many are there, actually? There's FTP (though that has a workaround -- passive mode). There's H.323, widely considered an amazingly ugly protocol. Are there any others that matter? Is there "an increasing number" of these protocols? Or do protocol designers realize that it's a bad idea to design protocols like this? People like to bitch about NAT, but NAT is a reality, and it's a powerful force pushing protocols away from dynamic port hackery like H.323. paul From owner-ipsec@lists.tislabs.com Thu Mar 28 10:32:06 2002 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 g2SIW5m13556; Thu, 28 Mar 2002 10:32:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11167 Thu, 28 Mar 2002 12:57:39 -0500 (EST) Message-Id: <3.0.3.32.20020328101035.00fb5438@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 28 Mar 2002 10:10:35 -0800 To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: User interface ciphersuites for IKEv2 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:00 PM 3/27/2002 -0800, Paul Hoffman / VPNC wrote: > >Suite A >Phase 1: AES-128, SHA-1, preshared keys, MODP group 5 >Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode > >Suite B >Phase 1: AES-128, SHA-1, RSA certs, MODP group 5 >Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode > Wouldn't SHA-2 be more suitable? - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Thu Mar 28 11:07:09 2002 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 g2SJ78m14760; Thu, 28 Mar 2002 11:07:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11410 Thu, 28 Mar 2002 13:30:13 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3.0.3.32.20020328101035.00fb5438@mail> References: <3.0.3.32.20020328101035.00fb5438@mail> Date: Thu, 28 Mar 2002 10:41:41 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: User interface ciphersuites for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:10 AM -0800 3/28/02, Alex Alten wrote: >Wouldn't SHA-2 be more suitable? It is not the mandatory-to-implement hash algorithm in IKEv2-01. If you would like to see SHA-2 in IKEv2, you should start a thread on that topic. The proposed suites would follow the mandatory list. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 28 11:50:41 2002 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 g2SJofm16971; Thu, 28 Mar 2002 11:50:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11656 Thu, 28 Mar 2002 14:07:45 -0500 (EST) Message-Id: <5.1.0.14.0.20020328141541.00a94d50@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Mar 2002 14:22:50 -0500 To: Paul Koning , mmani@avaya.com From: Melinda Shore Subject: RE: Do we actually need dynamic ports? Cc: ipsec@lists.tislabs.com In-Reply-To: <15523.22894.156276.224843@pkoning.dev.equallogic.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:57 PM 3/28/02 -0500, Paul Koning wrote: >There's FTP (though that has a workaround -- passive mode). There's >H.323, widely considered an amazingly ugly protocol. Are there any >others that matter? Um, SIP, SRTP, ... The reasons that H.323 are considered ugly have less to do with dynamic port allocation than they do with overall system design, which is basically a link-by-link replacement of existing telephony signaling systems and the heavy use of signaling mediation by a third party (gatekeeper). There are legitimate reasons to allocate media channels on the fly, including (but not limited to) allowing multiple simultaneous connections, allowing media with different traffic characteristics in the same call (you *really* don't want to multiplex audio and video on the same channel), allowing media with different security characteristics in the same call, allowing different media channels to be routed independently, allowing big hairy multiparty conferences without degrading audio quality, and so on. >Is there "an increasing number" of these protocols? Or do protocol >designers realize that it's a bad idea to design protocols like this? I hope not, because it's not a bad idea. Melinda From owner-ipsec@lists.tislabs.com Thu Mar 28 13:36:14 2002 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 g2SLaDm22835; Thu, 28 Mar 2002 13:36:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12144 Thu, 28 Mar 2002 15:38:12 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: Suggestion for SOI wrt PFS Date: Thu, 28 Mar 2002 15:19:38 -0500 Message-ID: <003501c1d695$e44ac0e0$1e72788a@ca.alcatel.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 Importance: Normal In-Reply-To: <15523.22894.156276.224843@pkoning.dev.equallogic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk PFS is one of the most confusing aspects of IKEv1 because it is poorly explained and poorly negotiated. I would speculate that 90% of people who read the IKE RFC will misunderstand the feature. JFK clarifies the situation (because it only talks about regular 'phase 1' PFS), but IKEv2 does not. I suggest that we re-evaluate the phase 2 PFS feature, and propose a sensible usage mode for two phase protocols (i.e. IKEv2). The ideal situation would be that the peers negotiate an IKE SA (with DH) and one or more IPsec SAs (not using DH). After a specified timeout (the forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 exchange would have to contain a DH. This DH would be used to generate the new SKEYSEED_d for subsequent exchanges. This provides the following properties: 1. If the system is hacked, the amount of data which is compromised is proportional to MAX(forward secrecy interval, expected SA lifetime). 2. In the case where multiple phase 2s are negotiated for the same phase 1, the cost of the DH is amortized. 3. Notice that this new proposal ignores the bogus justifications for PFS of "But 2 DHs are harder to crack than 1" and "But what if someone cracks one key and then reverses the HMAC to get the other keys." Notes: - This proposal removes the distinction between phase 1 PFS and phase 2 PFS. The group in the phase 2 exchange should always be the same as in the phase 1. - Based on property (1) above, if you want to use PFS then you should choose the forward secrecy interval to be slightly smaller than the expected SA lifetime. - The peers don't necessarily have to agree on a forward secrecy interval. There can be a message NOTIFY_DELETED_SKEYSEED_D to indicate that DH will be required on the next phase 2. - There is the problem of race conditions, but these can hopefully be sorted out using the message id (counter) and by storing the old SKEYSEED_D for a short time after you send the notify. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Mar 28 15:50:26 2002 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 g2SNoQm28440; Thu, 28 Mar 2002 15:50:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13280 Thu, 28 Mar 2002 18:10:35 -0500 (EST) Date: Thu, 28 Mar 2002 15:23:44 -0800 (PST) Message-Id: <200203282323.PAA07700@potomac.incog.com> From: Mike Ditto To: ipsec@lists.tislabs.com In-reply-to: <15523.22894.156276.224843@pkoning.dev.equallogic.com> (message from Paul Koning on Thu, 28 Mar 2002 12:57:02 -0500) Subject: Re: Do we actually need dynamic ports? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > How many are there, actually? Don't forget RealAudio and SQLNet. -=] Mike [=- From owner-ipsec@lists.tislabs.com Thu Mar 28 17:40:30 2002 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 g2T1eUm02690; Thu, 28 Mar 2002 17:40:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13822 Thu, 28 Mar 2002 19:48:02 -0500 (EST) Message-ID: <001901c1d6bc$93375fc0$05004c0a@rmohan> From: "Rajesh Mohan" To: References: <200203282323.PAA07700@potomac.incog.com> Subject: Re: Do we actually need dynamic ports? Date: Thu, 28 Mar 2002 16:56:35 -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 When I was talking about dynamic selectors, it was not just ports. The scenario I had in mind was a customer who is replacing his leased lines with a tunnel. With the leased lines, the packet travels over the leased line based on which interface the packet arrives. The customer may add or delete private addresses to his subnet. As long as his router knows how to reach the interface, the service provider does not have to change any configuration. If the service provider replaces this leased line with IPSec tunnel, can he continue to do what he did with the leased lines? ie tunnel the packet based on the interface the packet arrives. If the tunnel setup requires the network addresses at the two tunnel end points, then he has to update his configuration whenever the customer adds/deletes subnets. This was not required in the case of leased lines. We can solve this with IP-in-IP and transport mode or 0.0.0.0/0 (which requires more work if you have multiple leased lines ) but with just a IPSec complaint device, we will not be able to do it cleanly. Being able to setup a tunnel without having to agree on selectors should be considered. Thanks, -Rajesh M ----- Original Message ----- From: "Mike Ditto" To: Sent: Thursday, March 28, 2002 3:23 PM Subject: Re: Do we actually need dynamic ports? > > How many are there, actually? > > Don't forget RealAudio and SQLNet. > > -=] Mike [=- From owner-ipsec@lists.tislabs.com Thu Mar 28 19:28:28 2002 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 g2T3SRm06244; Thu, 28 Mar 2002 19:28:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14525 Thu, 28 Mar 2002 21:48:08 -0500 (EST) Message-Id: <200203290258.g2T2wass012988@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: Your message of "Thu, 28 Mar 2002 15:19:38 EST." <003501c1d695$e44ac0e0$1e72788a@ca.alcatel.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 28 Mar 2002 21:58:36 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The ideal situation would be that the peers negotiate an IKE SA (with DH) > and one or more IPsec SAs (not using DH). After a specified timeout (the > forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 > exchange would have to contain a DH. This DH would be used to generate the > new SKEYSEED_d for subsequent exchanges. So, why not just start a new phase 1 at this point? - Bill From owner-ipsec@lists.tislabs.com Thu Mar 28 19:42:17 2002 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 g2T3gGm06447; Thu, 28 Mar 2002 19:42:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14631 Thu, 28 Mar 2002 22:09:40 -0500 (EST) Date: Thu, 28 Mar 2002 19:21:11 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203290258.g2T2wass012988@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > The ideal situation would be that the peers negotiate an IKE SA (with DH) > > and one or more IPsec SAs (not using DH). After a specified timeout (the > > forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 > > exchange would have to contain a DH. This DH would be used to generate the > > new SKEYSEED_d for subsequent exchanges. > > So, why not just start a new phase 1 at this point? > Then you'd have to reauthenticate, which you may not want to (public key operation and all). At least that's the only difference I can see. This is somewhat lighter weight than a full phase 1. [ I haven't thought this proposal through yet, so I'm not coming down on one side or the other ;) ] jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847