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.
>  >