From owner-ipsec@lists.tislabs.com Wed Oct 1 01:39:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h918dMKP073792; Wed, 1 Oct 2003 01:39:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27729 Wed, 1 Oct 2003 03:57:56 -0400 (EDT) Date: Wed, 1 Oct 2003 11:06:08 +0300 Message-Id: <200310010806.h91868Vv027740@burp.tkv.asdf.org> From: Markku Savela To: tardo@acm.org CC: kseo@bbn.com, ipsec@lists.tislabs.com In-reply-to: <3.0.5.32.20030930211101.008531f0@pop.mindspring.com> (tardo@acm.org) Subject: Re: 2401bis Issue # 85 -- DROP'd inbound packet -- does not match SA References: <3.0.5.32.20030930211101.008531f0@pop.mindspring.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: "Joseph J. Tardo" > > This ICMP message MUST be sent encrypted using the reverse direction SA (or > similar appropriate terminology) and MUST NOT be sent in the clear. Using what encryption? a) you have policy selector entry for this ICMP message? Doubtfully working, as other end is already shown to be badly out of synch in respect to policies.. b) use the selectors extracted from the returned packet (instead of the outer Error ICMP) to choose the policy and IPSEC for the ICMP message. c) use the incoming SA's to find suitable matching outgoing SA's and use them (doubtful, as such they may not exist, and this would bypass the SPD, and could expose some security problems). I consider the (b) to be the "right" way to do it in general for ICMP error messages, but in this case again, it's unlikely that other end would accept it (because it already has shown to be using incorrect policy). > >Here's a description and proposed approach for: > > > >IPsec Issue #: 85 > > > >Title: DROP'd inbound packet -- does not match SA > > > >Description > >=========== > >Should there be a defined ICMP response to be used when an IPsec > >implementation drops an inbound, IPsec-protected packet, whose > >selectors do not match those of the SA on which it was delivered? > >The intent is to indicate to the sender that the receiver dropped the > >packet. > > > >Proposed approach > >================= > >Add text saying something along the lines of... > > > >"If an IPsec system receives an inbound packet whose selectors do not > >match those of the SA on which it was delivered, it MUST drop the > >packet. It SHOULD also be capable of generating and sending an ICMP > >message to indicate to the sender (the IPsec encapsulator) that the > >packet has been dropped by the receiver. The reason SHOULD be > >recorded in the audit log. > > > >IPv4 Type = 3 (destination unreachable) > > Code = 13 (Communication Administratively > > Prohibited) > > > >IPv6 Type = 1 (destination unreachable) > > Code = 1 (Communication with destination > > administratively prohibited > > > >"The implementation SHOULD provide management controls to allow an > >administrator to configure an IPsec implementation to send or not > >send the above ICMP message, or to rate limit the transmission of > >such ICMP responses." > > > >Thank you, > >Karen > > > > > From owner-ipsec@lists.tislabs.com Wed Oct 1 02:31:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h919V2KP075516; Wed, 1 Oct 2003 02:31:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA28059 Wed, 1 Oct 2003 04:52:55 -0400 (EDT) Message-Id: <200310010856.h918umCH014062@nyarlathotep.keromytis.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Karen Seo Cc: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, kivinen@ssh.fi Subject: Re: 2401bis Issue # DD -- Anti-replay notification In-reply-to: Your message of "Tue, 30 Sep 2003 02:13:27 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 2003 04:56:48 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen, since IKE-negotiated SAs (in fact, any non-manual SA) are supposed to have anti-replay protection on, my sense is that the original REPLAY-STATUS message was unnecessary to begin with. Do you foresee the case of an IKEv2-established SA that would not use anti-replay protection ? -Angelos In message , Karen Seo writes: >Folks, > >At present, RFC2407 ("The Internet IP Security Domain of >Interpretation for ISAKMP") defines a REPLAY-STATUS notify message >that IKEv1 can use to tell a peer whether or not it has anti-replay >enabled for a particular SA. (It's chained onto a Quick Mode message >a la RESPONDER-LIFETIME.) The default is to assume anti-replay is >enabled. But this capability is not in IKEv2. > >We'd like to propose that IKEv2 also allow the receiver to notify the >sender whether or not anti-replay is enabled. In the case where >anti-replay isn't being supported by the receiver, this would allow >the sender to avoid setting up a new SA when the replay counter rolls >over. > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Wed Oct 1 03:18:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91AIBKP077796; Wed, 1 Oct 2003 03:18:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA28359 Wed, 1 Oct 2003 05:39:08 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16250.41589.110343.253994@ryijy.hel.fi.ssh.com> Date: Wed, 1 Oct 2003 12:46:29 +0300 From: Tero Kivinen To: Markku Savela Cc: tardo@acm.org, kseo@bbn.com, ipsec@lists.tislabs.com Subject: Re: 2401bis Issue # 85 -- DROP'd inbound packet -- does not match SA In-Reply-To: <200310010806.h91868Vv027740@burp.tkv.asdf.org> References: <3.0.5.32.20030930211101.008531f0@pop.mindspring.com> <200310010806.h91868Vv027740@burp.tkv.asdf.org> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 22 min X-Total-Time: 22 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela writes: > > This ICMP message MUST be sent encrypted using the reverse direction SA (or > > similar appropriate terminology) and MUST NOT be sent in the clear. > Using what encryption? Same level, that was used when the packet came in. There is no other choise. The original packet is included in the ICMP message, thus sending it in clear or with lower security level would be security problem. > a) you have policy selector entry for this ICMP message? Doubtfully > working, as other end is already shown to be badly out of synch in > respect to policies.. > > b) use the selectors extracted from the returned packet (instead of > the outer Error ICMP) to choose the policy and IPSEC for the ICMP > message. > > c) use the incoming SA's to find suitable matching outgoing SA's and > use them (doubtful, as such they may not exist, and this would > bypass the SPD, and could expose some security problems). Actually any of those would propably be ok, but preferred order would be c, b, and then a. In c this would mean that find the other direction pair of the incoming SA and use it, thus the packet would get exactly same protection when sent back. If the other end drops it then there is nothing we can do for it... The b is otherwise fine, but it might be that we do not have policy for the return traffic at all (i.e we have policy from port 80 to port 8080 from vpn-client to sgw, but we do not allow traffic from sgw to the vpn-client port 80). This would mean that we do not find the policy for the internal packet, we find the policy for the packet that would be reply for the internal packet. This might not be so easy. In a case there is problem that the ICMP messages might have quite different security configuration compared to the original traffic. I.e it might even have configuration saying send all ICMP messages in clear, and protect all UDP traffic from remote port 514 (syslog) to local port 514 at host 10.0.0.1 (syslog.company.com) with 3DES. The security policy tries to protect all logging going to 10.0.0.1 from the vpn-client with 3DES. Now if the client has configuration error in syslog.conf and it sends packets to 10.0.0.2 instead of 10.0.0.1, then the sgw would decrypt those packets, notice that they do not fit the selectors, and send ICMP error containing the original logging packet in clear. There might even be protocols where the packets contains plain text passwords, which are supposed to be protected by ipsec... One, option that would get rid of all of this discussion, would be to say that ICMP error message contains the original encrypted packet, not the decrypted packet. I.e when encrypted packets come in, it is stored, decrypted, and then selectors are checked. If the selectors does not match, then original stored packet is retrieved, and clear text ICMP error message is replied with encrypted packet inside. Of course in that case the responder might have problem to actually find out why it didn't fit the selectors, as it needs to dig the original packet out, decrypt it using the keys only in the encryption SA, only then it can see the selectors.... > I consider the (b) to be the "right" way to do it in general for ICMP > error messages, but in this case again, it's unlikely that other end > would accept it (because it already has shown to be using incorrect > policy). I would say the c is the easiest and best way. If you are using IKE then you will have SAs in pairs, thus you can find the matching SA pair for the incoming SA, and use that. If you are using manual keying or SA in other direction has already expired, or you do not maintain the SA pair information, then you cannot send ICMP error messages back. > > >Here's a description and proposed approach for: > > > > > >IPsec Issue #: 85 > > > > > >Title: DROP'd inbound packet -- does not match SA > > > > > >Description > > >=========== > > >Should there be a defined ICMP response to be used when an IPsec > > >implementation drops an inbound, IPsec-protected packet, whose > > >selectors do not match those of the SA on which it was delivered? > > >The intent is to indicate to the sender that the receiver dropped the > > >packet. > > > > > >Proposed approach > > >================= > > >Add text saying something along the lines of... > > > > > >"If an IPsec system receives an inbound packet whose selectors do not > > >match those of the SA on which it was delivered, it MUST drop the > > >packet. It SHOULD also be capable of generating and sending an ICMP > > >message to indicate to the sender (the IPsec encapsulator) that the > > >packet has been dropped by the receiver. The reason SHOULD be > > >recorded in the audit log. > > > > > >IPv4 Type = 3 (destination unreachable) > > > Code = 13 (Communication Administratively > > > Prohibited) > > > > > >IPv6 Type = 1 (destination unreachable) > > > Code = 1 (Communication with destination > > > administratively prohibited > > > > > >"The implementation SHOULD provide management controls to allow an > > >administrator to configure an IPsec implementation to send or not > > >send the above ICMP message, or to rate limit the transmission of > > >such ICMP responses." Actually we could say that the rate limit is given in number of ICMP messages per minute, and value 0 means do not ever send ICMP error messages :-) -- 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 Oct 1 03:45:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Aj5KP078570; Wed, 1 Oct 2003 03:45:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28553 Wed, 1 Oct 2003 06:06:26 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16250.43227.130776.747346@ryijy.hel.fi.ssh.com> Date: Wed, 1 Oct 2003 13:13:47 +0300 From: Tero Kivinen To: "Angelos D. Keromytis" Cc: Karen Seo , ipsec mailingList , byfraser@cisco.com, tytso@mit.edu Subject: Re: 2401bis Issue # DD -- Anti-replay notification In-Reply-To: <200310010856.h918umCH014062@nyarlathotep.keromytis.com> References: <200310010856.h918umCH014062@nyarlathotep.keromytis.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 27 min X-Total-Time: 27 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis writes: > Karen, since IKE-negotiated SAs (in fact, any non-manual SA) are supposed to > have anti-replay protection on, my sense is that the original REPLAY-STATUS > message was unnecessary to begin with. Do you foresee the case of an > IKEv2-established SA that would not use anti-replay protection ? Only reason for those are are high-availability and load-balancing systems, where it is quite hard to maintain the replay window consistency between multiple machines. In those systems two or more machines share the same SAs (both IKE and IPsec SAs). In the high-availability cases, the machines are already most likely snooping each others traffic, thus they can update the incoming replay window etc (both/all machines must be powerfull enough to handle all traffic, thus both of them can process all data, including decrypting, checking for replay, maintaining replay-window etc for all packets). For sending the high-availability system can be configured so that only the master host is doing the actual sending, the other only snoops those packets and updates its state accordingly, or if both hosts are sending, it can be configured so that host 1 uses odd numbers, and host 2 uses even numbers, and both snoop the packets sent by each other to make sure that the sequence numbers stay in sync (i.e they take last snooped outgoing packet and increment their own sequence number by 2 until it is larger than the last one the other host sent out). So in high-availability cases it is possible to get the anti-replay protection working. The load-balancing case is different. In the load-balancing case one machine cannot handle all the traffic, thus it cannot update its replay-window or sequence number for the packets going to other hosts. Also the hosts cannot communicate that information per packet basis. There are tricks you can do, like instead of sharing all SAs, they only share IKE SAs, but not IPsec SAs. Each load-balancing host generates their own IPsec SA to each clients using the one shared IKE SA they have with the other end. Each of those SAs are going to have identical IP numbers etc, thus for the other end it looks like the load-balancing server simply created one IKE SA and multiple identical IPsec SAs. Now each server can send data to other end, and they select who needs to decrypt the packet based on the SPI numbers (the SPI database is common for all of them, i.e odd numbers go to host 1, even to host 2 etc). If one of hosts fail the others can send the IKE SA delete for the IPsec SAs it had. The problem is that the host on the other end see only n identical SAs, and it is up to it how it uses them. It might simply only use one of them and ignore the others, thus sending all traffic to only one of the hosts, or it might send packets out based on the ToS bits to different SAs etc. Good thing is that in most cases single host is capable of handing all of the traffic coming from one client, thus the load-balancing server can balance the number of clients to each host. I.e only one host creates IPsec SA and talks to client etc. They can then see the load of each machine, and move IPsec SAs around as needed (another host creates new IPsec SA, and the old host deletes it). So now the question is really do we need load-balancing servers where one server in the pool cannot handle traffic sent by the other ends single host, and in that case we would need to disable anti-replay? With current hardware technology, I would say that we do not need support for disabling the anti-replay. We can manage the load-balancing and high-availability cases with current protocol, and in most cases we actually might want to keep the anti-replay even when using those systems. > -Angelos > > In message , Karen Seo writes: > >Folks, > > > >At present, RFC2407 ("The Internet IP Security Domain of > >Interpretation for ISAKMP") defines a REPLAY-STATUS notify message > >that IKEv1 can use to tell a peer whether or not it has anti-replay > >enabled for a particular SA. (It's chained onto a Quick Mode message > >a la RESPONDER-LIFETIME.) The default is to assume anti-replay is > >enabled. But this capability is not in IKEv2. > > > >We'd like to propose that IKEv2 also allow the receiver to notify the > >sender whether or not anti-replay is enabled. In the case where > >anti-replay isn't being supported by the receiver, this would allow > >the sender to avoid setting up a new SA when the replay counter rolls > >over. If you do not want to set up new SA so often, use extended sequence numbers, i.e do not disable it (it is on by default for IPsec SAs created using IKEv2). -- 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 Oct 1 06:31:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91DV2KP084379; Wed, 1 Oct 2003 06:31:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00185 Wed, 1 Oct 2003 08:47:50 -0400 (EDT) Date: Wed, 1 Oct 2003 08:47:50 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200310011247.IAA00185@lists.tislabs.com> (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id CAA27300 Wed, 1 Oct 2003 02:48:42 -0400 (EDT) nutshell.tislabs.com via csmap (V6.0) id srcAAA_daqZD; Wed, 1 Oct 03 02:55:55 -0400 To: ipsec@lists.tislabs.com Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet References: <20030930140304.EEDCD16508@wolfe.bbn.com> From: Markus Stenberg Date: 01 Oct 2003 09:53:24 +0300 In-Reply-To: Charles Lynn's message of "Tue, 30 Sep 2003 10:03:04 -0400 (EDT)" Message-ID: <878yo51maj.fsf@navi.fingon.iki.fi> Lines: 29 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charles Lynn writes: > It would be nice it the user could be given some indication of the > problem so that they could initiate corrective action. Yes, in an ideal world with clued users and no black hats. > Should we define additional ICMP codes to distinguish the cases? > I think we should. I am somewhat nervous of adding variety of obscure ICMP messages, none of which can be obviously protected, and are therefore spoofable. And to top it off, most of the typical client end-user applications nowadays (say, web browsers, email readers) don't give meaningful error messages for ANY ICMP messages anyway. _If_ this is really useful feature (I'm not very convinced myself, but at least some people apparently are), I think it should be MAY at best. A security infrastructure relying on insecure error messages sounds dangerous for some reason - at least human-level DoS is easily achieved with such infrastructure. (e.g. send forged ICMP messages, end user notes that oops, can't do, and starts bothering IT people.. multiply this by X where X is number of users, and you have lots of fun) -Markus -- "Why? Are they brain damaged?" "No more so than anyone who works on computers for a living." - Neal Stephenson/Frederick George, "Interface" From owner-ipsec@lists.tislabs.com Wed Oct 1 08:18:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91FIPKP088660; Wed, 1 Oct 2003 08:18:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01299 Wed, 1 Oct 2003 10:31:45 -0400 (EDT) Message-Id: <200310011440.h91EePHN072102@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charles Lynn cc: ipsec@lists.tislabs.com Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet In-reply-to: Your message of Tue, 30 Sep 2003 10:03:04 EDT. <20030930140304.EEDCD16508@wolfe.bbn.com> Date: Wed, 01 Oct 2003 16:40:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis observes: > => IMHO the code should follow the reason why the IPsec peer could not > be contacted with code 1 by default? To amplify, it is hard for the receiver of an ICMP message that only uses one code to decide how to respond/notify the user about the detected error. There are several cases: 1) There are (temporary) network connectivity problems during IKE; the communication should be retried "in a while". => if the source of the problem is known so the code to use is known, if it is not known, code 1 is a good default. 2) There are (temporary) (black or red) network connectivity problems during the user's communication, the communication may not succeed at the current time; one could wait, or try again later. => same. 3) The communication is prohibited by policy; do not retry until the security officer(s) have reached an agreement. Note that the prohibition can be detected by either of the IKE peers. => code 1 4) The packet that was received is protected as required by the local policy, but it is not a packet that should be sent via the SA that was used (access control violation); your implementation is broken, or your key has been compromised. The SG transiting the ICMP might try to rekey the SA to establish a new key, but that will not fix a broken implementation. => code 1 5) The packet that was received is not protected as required by the local policy; this could be part of a DDoS attack, so a way to limit the ICMP rate is especially important in this case. => code 1 (and I agree about the rate limit) It would be nice it the user could be given some indication of the problem so that they could initiate corrective action. Should we define additional ICMP codes to distinguish the cases? I think we should. => if you believe we need new things, IMHO it should be a new type and not new codes. And it should be easier to get... Regards Francis.Dupont@enst-bretagne.fr PS: code 1 is "communication with destination administratively prohibited". From owner-ipsec@lists.tislabs.com Wed Oct 1 17:15:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h920FVKP008958; Wed, 1 Oct 2003 17:15:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04312 Wed, 1 Oct 2003 19:21:14 -0400 (EDT) From: Black_David@emc.com Message-ID: To: kseo@bbn.com, ipsec@lists.tislabs.com Subject: RE: 2401bis Issue # 75 -- TOS (now ECN) copying in tunnel mode Date: Wed, 1 Oct 2003 19:29:40 -0400 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 Karen, > Proposed approach: > ================== > 2401bis will be modified with text along the lines of: > > "An IPsec implementation MAY be configurable re: how it processes the > DSCP field for tunnel mode for transmitted packets. For outbound > traffic, one configuration setting will operate as described in the > section on IPv4 and IPv6 header processing for IPsec tunnels. Another > will allow the field to be mapped to a fixed value, which MAY be > configured on a per SA basis. (The value might really be fixed for > all traffic outbound from a device, but per SA granularity allows > that as well.) This configuration option allows a local > administrators to decide whether the covert channel provided by > copying these bits outweighs the benefits of copying. While it was clear from context that this issue is about the outer header in tunnel mode, the above text should have the magic words "in the outer IP header" added after "DSCP field" for clarity. Also, there's a security perimeter issue lurking here. It is not necessary that the DSCP field be set to a fixed value and transmitted as such, but rather that the DSCP be set to a fixed value at some point in the processing within the security perimeter beyond which an adversary has no opportunity to add info. The reason this distinction matters is that it is useful to allow diffserv traffic conditioning after the DSCP is set to a fixed value but before the packet is transmitted (e.g., drop precedence for AF). I would like to see the above text modified to allow further traffic conditioning after the DSCP is set to a fixed value, plus suitable additional wording to warn implementers to ensure that such conditioning does not enable the information leakage that the "set to a fixed value" step is intended to prevent. One way to achieve the latter property is to have traffic exit the security perimeter with a fixed DSCP value and perform additional traffic conditioning outside the perimeter, but before transmission in systems that have a notion of security perimeter. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Oct 1 21:48:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h924m9KP015679; Wed, 1 Oct 2003 21:48:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06196 Thu, 2 Oct 2003 00:04:56 -0400 (EDT) Message-Id: <200310020406.h9246cHW017231@coredump.cs.columbia.edu> To: Karen Seo Cc: "Theodore Ts'o" , Charlie Kaufman , byfraser@cisco.com, kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: Re: Final editing instructions for ikev2 document In-reply-to: Your message of "Thu, 02 Oct 2003 00:11:15 EDT." Date: Thu, 02 Oct 2003 00:06:38 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Karen Seo writes: >Folks, > >Apologies if you've addressed this elsewhere, but with regard to the >IKE spec, how do you want to handle the new issues brought up as we >discuss 2401bis? > - Issue 86 --> Mobility Header Type as selector > - Issue DD --> anti-replay notification support > - Issue 68 --> VPNs with overlapping IP address ranges -- > add some form of VPN subscriber ID as an IKE payload value > - Issue ?? --> Add ICMP message type as selector (This will be > part of the ICMP handling issue that we're in the process of > writing.) > >Do these need to get resolved before the IKE RFC goes to IETF last call? Both 86 and ?? can be resolved by extensions/revisions, if we decide to go ahead with them. For anti-replay notification, see my note from yesterday (I don't see its value to begin with, and it certainly shouldn't hold the document back). On issue 68 I'm agnostic, but I again don't see it as a show-stopper wrt to getting the IKE spec out. Just a first reaction. -Angelos From owner-ipsec@lists.tislabs.com Wed Oct 1 21:50:01 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h924o0KP015719; Wed, 1 Oct 2003 21:50:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06147 Wed, 1 Oct 2003 23:59:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 2 Oct 2003 00:11:15 -0400 To: "Theodore Ts'o" , Charlie Kaufman , byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi From: Karen Seo Subject: Re: Final editing instructions for ikev2 document Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Apologies if you've addressed this elsewhere, but with regard to the IKE spec, how do you want to handle the new issues brought up as we discuss 2401bis? - Issue 86 --> Mobility Header Type as selector - Issue DD --> anti-replay notification support - Issue 68 --> VPNs with overlapping IP address ranges -- add some form of VPN subscriber ID as an IKE payload value - Issue ?? --> Add ICMP message type as selector (This will be part of the ICMP handling issue that we're in the process of writing.) Do these need to get resolved before the IKE RFC goes to IETF last call? Thank you, Karen >Hi Charlie, > >My apologies for the delaying in getting this document to you. I had a >loss of state problem myself --- a literal hard drive accident that >caused me to lose all recent mail and other files on my hard drive since >my last backup. (Which unfortunately was far too long ago....) > >Anyway, I believe these are the final changes that need to be made to >the IKEv2 document based on discussions on the IPSEC mailing list after >wg last call. After these changees are made and a new I-D submitted to >the secretariat, we should be ready to hand this off to the AD's for >progressing to IETF last call. (And the angels started singing >Hallelujah....) > > - Ted > > >1) EAP non-kg security considerations > >In section 2.16, in the second to last paragraph, which currently >reads: > > For EAP methods that create a shared key as a side effect of > authentication, that shared key MUST be used by both the Initiator > and Responder to generate an AUTH payload using the syntax for shared > secrets specified in section 2.15. The shared key generated during an > IKE exchange MUST NOT be used for any other purpose. For EAP methods > that do not establish a shared key, there will be no AUTH payloads in > the final messages. > >Delete the last sentence, ("For EAP methods that do not establish...") >and add the following paragraph: > >EAP methods that do not establish a shared key SHOULD NOT be used, as >they are subject a number of man-in-the-middle attacks if these EAP >methods are used in other protocols that do not use a >server-authenticated tunnel. Please see the Security Considerations >section for more details. If EAP methods that do not generate a >shared key are used, there will be no AUTH payloads in the final >messages. > >In the security considerations section, replace the last paragraph >with the following text: > >When using an EAP authentication method that does not generate a shared >key for protecting a subsequent AUTH payload, certain man-in-the-middle >and server impersonation attacks are possible.[EAPMITM] These >vulnerabilities occur when EAP is also used in protocols which are not >protected within a secure tunnel. Since EAP is a general-purpose >authentication protocol, which is often used to provide single-signon >facilities, a deployed IPSEC solution which relies on an EAP >authentication method that does not generate a shared key (also known as >a non-key-generating EAP method) can become compromised due to the >deployment of an entirely unrelated application that also happens to use >that same non-key-generating EAP method, but in an unprotected fashion. >Note that this vulnerability is not limited to just EAP, but can occur >in other scenarios where an authenticatoin infrastructure is reused. >For example, if the EAP mechanism used by IKEv2 utilizes a token >authenticator, and the enterprise deploys a non-encrypted web form which >accepts the input from the token authenticator, a man-in-the-middle >attacker could impersonate the web server, intercept the token >authentication exchange, and use it to initiate an IKEv2 connection. >For this reason, use of non-key-generating EAP methods SHOULD be avoided >where possible. Where they are used, it is extremely important that all >usages of these EAP methods SHOULD utilize a protected tunnel, where the >initiator validates the responder's certificate before initiating the >EAP exchange. Implementors SHOULD describe the vulnerabilities of using >non-key-generating EAP methods in the documentation of their >implementations so that the administrators deploying IPSEC solutions are >aware of these dangers. > >Add the following reference: > >[EAPMITM] N. Asokan, Valtteri Nierni, and Kaisa Nyberg, > "Man-in-the-Middle in Tunneled Authentication Protocols", > http://eprint.iacr.org/2002/163, November 11, 2002. > >---------------------------------------------------- > >2. Rekeying clarifications > > From David Black's note of August 20, 2003: > >Subject: RE: The remaining IKEv2 issues - #64 >To: Charlie_Kaufman@notesdev.ibm.com > >Charlie, > >As part of this (unless I missed it), please add sentences >to make the following points: > >- IKEv2 deliberately allows parallel SAs with the same traffic > selectors between common endpoints. One of the purposes of > this is to support traffic QoS differences among the SAs; > see Section 4.1 of RFC 2983 (informative reference). >- Hence unlike IKEv1, given two endpoints, traffic selectors need > not uniquely identify an SA between those endpoints. >- Therefore the IKEv1 rekeying heuristic (use of same traffic > selectors as an existing SA indicates rekeying, so existing > SA should be deleted shortly after new one is up) SHOULD NOT > be used, as it will result in unintended SA deletion. > >This may help avoid some surprises arising from implementation code >reuse. > >Also, [RFC2401bis] needs to be added to the list of normative references. > >-------------------------------------------- > >3. ECN clarifications: > >Replace the text of section 2.24 with the following, per suggested >the rewording from David Black: > >When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage >is not appropriate for the outer IP headers because tunnel decapsulation >processing discards ECN congestion indications to the detriment of the >network. ECN support for IPsec tunnels for IKEv1-based IPsec requires >multiple operating modes and negotiation (see [RFC 3168]). IKEv2 >simplifies this situation requiring that ECN be usable in the outer IP >headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, >tunnel encapsulators and decapsulators for all tunnel-mode Security >Associations (SAs) created by IKEv2 MUST support the ECN full-functionality >option for tunnels specified in [RFC3168] and MUST implement the tunnel >encapsulation and decapsulation processing specified in [RFC2401bis] to >prevent discarding of ECN congestion indications. > >NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are >normative. > >---------------------------------- > >4. Nat traversal clarification. > >In section 2.23, Nat Traversal reads: > > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts that > are not behind a NAT SHOULD send all packets (including retried > packets) to the IP address and port from the last valid > authenticated packet from the other end. A host not behind a NAT > ^^^ typo, delete > SHOULD NOT do this because it opens a DoS attack possibility. Any > authenticated IKE packet or any authenticated IKE encapsulated ESP > ^^^ typo, > replace with UDP > packet can be used to detect that the IP address or the port has > changed. > >-------------------------------------- > >5. Friends don't let friends use ASN.1 > >In section 3.6, certificate payload, the description of the ASN.1 for >a certificate bundle is ambiguous. > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > a PKIX certificate bundle followed by a variable length URL the > resolves to the BER encoded certificate bundle itself. The bundle > is a BER encoded SEQUENCE of certificates and CRLs. > >Use the following ASN.1 definition suggested by Nicholas Williams > > DEFINITION EXPLICIT TAGS ::= > BEGIN > > IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 > > CertificateOrCRL ::= CHOICE { > cert [0] Certificate, > crl [1] CertificateList > } > > CertificateBundle ::= SEQUENCE OF CertificateOrCRL > END From owner-ipsec@lists.tislabs.com Wed Oct 1 22:33:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h925XrKP030942; Wed, 1 Oct 2003 22:33:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06562 Thu, 2 Oct 2003 00:57:03 -0400 (EDT) Message-Id: <5.2.0.9.0.20031002004844.020fd960@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Oct 2003 01:03:28 -0400 To: ipsec mailingList From: Mark Duffy Subject: Re: IPsec issue #49 -- red-side fragmentation option In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When an IPsec device sending an outbound packet does red side fragmentation there are at least two possible ways to select SAs for the fragments. One way is to use the SPD entry selected for the initial packet to process all the created fragments. This has some appeal because the initial packet is more likely to contain the port numbers (i.e. if it was not itself already a fragment). The other is to create all the fragments first, then search the SPD independently for each fragment. They would then be processed as per Issue #81 "Handling outbound red fragments". The second way seems correct to me because it puts the sender and receiver on an equal footing for selecting an SPD entry. The receiver of the IPsec-protected fragments is not going to reassemble them, so it will not know which ones came from what initial packet. Therefore I think the sender should not take advantage of the additional information it has. In any event, shouldn't the discussion of red side fragmentation in 2401bis make a statement on this issue? --Mark From owner-ipsec@lists.tislabs.com Wed Oct 1 22:34:32 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h925YVKP031376; Wed, 1 Oct 2003 22:34:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06518 Thu, 2 Oct 2003 00:53:14 -0400 (EDT) Message-Id: <5.2.0.9.0.20031002002452.02108da0@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Oct 2003 00:43:12 -0400 To: Karen Seo , ipsec mailingList From: Mark Duffy Subject: Re: 2401bis Issue # 81 -- Handling outbound red fragments Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com 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, I have a few questions on this proposal, inline below. --Thanks, Mark At 01:49 AM 9/30/2003 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 81 > >Title: Handling outbound red fragments [snip] >Proposed approach: >================== >The current section on how to handle outbound fragments when the port >fields may be inaccessible will be replaced by the following approach. > >"Between each of pair of IPsec implementations, one or more tunnel-mode SA >will be established that are used to carry ONLY non-initial red fragments, >if both the source and destination end of the IPsec tunnel-mode SA agree >to transmit/receive fragments (as determined via IKE negotiation or manual >configuration). Does that mean this approach would be used only if so negotiated in IKE? How does this relate to the "MUST" in the next line below? How should red fragments be processed in the event that it is not negotiated in IKE? > To provide this facility, the IPsec implementation MUST support the > following: > >The SPD entries for the fragment tunnels specify what kind of tunnel mode >protections are required and MUST have their selectors specified as follows: Do you really mean that the device must have exactly that entry? The below SPD entry looks like it is intended to create exactly 1 SA pair for each pair of communicating hosts. Why should 2401bis be so rigid to require the SPD to be set up exactly this way? That could present a significant scalability problem if the number of source-dest pairs is large. Also, what is it that *prevents* non-fragments or initial fragments from matching that SPD entry? I surmise that for v6 the protocol:44 selector accomplishes this. How about v4? It seems another selector type such as "is non initial fragment" would be needed. > WILDCARD = a single range that covers all possible values > OPAQUE = the value is not available, e.g., it's encrypted > or the protocol doesn't have that selector, etc. > ANY = opaque or wildcard > >Field SPD Entry >-------- ------------- >src addr WILDCARD, flag set to use the packet value >dst addr WILDCARD, flag set to use the packet value >protocol* 44 >src port ANY >dst port ANY >user id ANY >sec. labels ANY >mobil. hdr type ANY >ICMP type ANY > > * IPv6 non-initial fragments use 44 to indicate a fragment. > >When an initial fragment is received, its selectors will be used to look >up a matching entry (for packets) in the SPD. If necessary, an SA will be >created and the appropriate IPsec protection will be applied. Normal SA >setup procedures are followed. > >When a non-initial fragment is received, the IPsec implementation uses >protocol = 44 (fragment) plus the fragment's other selectors (at a >minimum, IP source and destination addresses) to look up a matching entry >in the SPD. If necessary, an SA will be created and the appropriate >IPsec protection will be applied. Normal SA setup procedures are followed. > >Because all non-initial fragments will be mapped to SAs using protocol >selector = 44, the non-initial fragments will automatically be placed on >the SAs intended for their use. > >At the receiving end of the fragment SA, the IPsec implementation MUST >check and remove the tunnel header, check the fragment's selectors against >the selectors of the SA, having set the fragment's "protocol" to 44, and >verify that the fragment is a non-initial fragment by looking at the >fragment's offset. > >There MUST be a mechanism for the administrator to configure a minimum >fragment offset value to avoid a non-initial fragment from overwriting >selectors in the initial fragment. This MAY be a single value or there >MAY be separate values for IPv4 and IPv6. The IPsec implementation MUST >verify that the fragment offset is greater than or equal to the minimum >offset value. > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Thu Oct 2 07:02:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92E2tKP097211; Thu, 2 Oct 2003 07:02:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09613 Thu, 2 Oct 2003 09:13:01 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16252.9747.541695.231747@ryijy.hel.fi.ssh.com> Date: Thu, 2 Oct 2003 16:20:19 +0300 From: Tero Kivinen To: "Angelos D. Keromytis" Cc: Karen Seo , "Theodore Ts'o" , Charlie Kaufman , byfraser@cisco.com, ipsec@lists.tislabs.com Subject: Re: Final editing instructions for ikev2 document In-Reply-To: <200310020406.h9246cHW017231@coredump.cs.columbia.edu> References: <200310020406.h9246cHW017231@coredump.cs.columbia.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis writes: > > - Issue 86 --> Mobility Header Type as selector > > - Issue ?? --> Add ICMP message type as selector (This will be > > part of the ICMP handling issue that we're in the process of > > writing.) > Both 86 and ?? can be resolved by extensions/revisions, if we decide to > go ahead with them. For anti-replay notification, see my note from yesterday The ?? is already in the current IKEv2 draft. I.e ICMP type and code can be used as selectors. For 86 I think the easiest thing would be to write new draft, that specifies how to interpret port numbers when protocol id is mobile ip. Perhaps the Start_port and End_port should be renamed to Subselector_start, and subselector_end, which are then protocol specific (i.e for TCP and UDP they are port numbers, for ICMP they are type and code, for mobile ip they are ...). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 2 08:18:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FI3KP099995; Thu, 2 Oct 2003 08:18:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10428 Thu, 2 Oct 2003 10:30:11 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Thu, 2 Oct 2003 09:38:53 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Karen Seo cc: ipsec mailingList , , , "Angelos D. Keromytis" , Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets In-Reply-To: Message-ID: 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 KAA10425 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Sep 2003, Karen Seo wrote: > Tylor, > > Quoting some earlier text from Steve K.... > > "Dummy packets can be inserted at random intervals to mask the > absence of actual traffic. One can also "shape" the actual traffic to > match some distribution to which dummy traffic is added as dictated > by the distribution parameters. As with the packet length padding > facility for TFS, the most secure approach would be to generate dummy > packets at whatever rate is needed to maintain a constant rate on an > SA. If packets are all the same size, then the SA presents the > appearance of a constant bit rate data stream, analogous to what a > link crypto would offer at layer 1/2. However, this is unlikely to > be practical in many contexts, e.g., when there are multiple SAs > active, because it would imply reducing the allowed bandwidth for a > site, based on the number of SAs, and that would undermine the > benefits of packet switching. How dummy packet insertion is handled > SHOULD not be an implementation decision, however, but rather a > parameter under control of the local administration." > > We could amend the last sentence of the proposed text as follows > > "For example, the controls might allow an administrator to generate > random or fixed length dummy packets, or to pad real packets to > random or fixed lengths, or to control the insertion timing of the > dummy packets." > > Would that address your concerns? > > Thank you, > Karen Could we not add something similar to Steve's text somewhere? It gives justification and reasoning behind both the packet padding and dummy packet generation. Perhaps this doesn't belong in the architecture document... but it would be nice to have somewhere. Just reading through the ESPv3 draft, you don't have enough info to implement, without making assumptions as to what is really wanted. -------------------------------------------------------------------------------- Tylor Allison Principal Engineer Secure Computing® Protecting the world's most important networks (TM) www.securecomputing.com NASDAQ: SCUR tylor_allison@securecomputing.com -------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Oct 2 11:43:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92IhKKP009829; Thu, 2 Oct 2003 11:43:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12287 Thu, 2 Oct 2003 13:54:18 -0400 (EDT) X-mProtect: <200310021802> Nokia Silicon Valley Messaging Protection Message-ID: <3F7C686D.7000005@iprg.nokia.com> Date: Thu, 02 Oct 2003 11:03:25 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karen Seo CC: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi Subject: Re: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen Seo wrote: > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 86 > > Title: Add IPv6 mobility header message type as selector > > > Description: > ============ > On 7/11/03, Francis Dupont posted a message to the ipsec-policy > working group in which he, among other things, asked that we add the > IPv6 mobility header message type (MH Type) as a selector. (For > details, see > http://ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt). > > Should we add the IPv6 mobility header message type (MH Type) as a > selector? definitely. I agree with the proposed approach that you suggested. Vijay > > > > Proposed approach: > ================== > Modify 2401bis along the following lines: > > 1. Change "upper layer protocol" to "next layer protocol". (We made > this change to AH and ESP previously.) > 2. Add the mobility header as another possible "next layer" protocol > 3. Add mobility header type (MH Type) to the list of selectors > supported in the SPD and in IKEv2. > 4. The processing text stays the same. > > > Thank you, > Karen From owner-ipsec@lists.tislabs.com Thu Oct 2 13:03:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92K3gKP012627; Thu, 2 Oct 2003 13:03:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12731 Thu, 2 Oct 2003 15:12:11 -0400 (EDT) From: Black_David@emc.com Message-ID: To: tytso@mit.edu, ckaufman@microsoft.com Cc: ipsec@lists.tislabs.com Subject: ECN tweak to Final editing instructions for ikev2 document Date: Thu, 2 Oct 2003 15:20:54 -0400 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 > 3. ECN clarifications: > > Replace the text of section 2.24 with the following, per suggested > the rewording from David Black: > > When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage > is not appropriate for the outer IP headers because tunnel decapsulation > processing discards ECN congestion indications to the detriment of the > network. ECN support for IPsec tunnels for IKEv1-based IPsec requires > multiple operating modes and negotiation (see [RFC 3168]). IKEv2 > simplifies this situation requiring that ECN be usable in the outer IP > headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, > tunnel encapsulators and decapsulators for all tunnel-mode Security > Associations (SAs) created by IKEv2 MUST support the ECN full-functionality > option for tunnels specified in [RFC3168] and MUST implement the tunnel > encapsulation and decapsulation processing specified in [RFC2401bis] to > prevent discarding of ECN congestion indications. Based on subsequent list discussion with Joe Touch, "specified in [RFC3168]" in the above should be replaced with "specified in Section 9.1 of [RFC3168]" . Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Oct 2 22:56:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h935uFKP058703; Thu, 2 Oct 2003 22:56:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA15955 Fri, 3 Oct 2003 01:07:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <200309281414.h8SEE2HN059728@givry.rennes.enst-bretagne.fr> References: <200309281414.h8SEE2HN059728@givry.rennes.enst-bretagne.fr> Date: Fri, 3 Oct 2003 01:19:15 -0400 To: Francis Dupont From: Karen Seo Subject: Re: 2401bis Issue #67 -- IPsec management traffic Cc: "'ipsec mailingList'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francis, > In your previous mail you wrote: > > There is one slight catch, however. There is no SPD entry action to > cause delivery of a received message to IKE. So, while your example > is appropriate for outbound IKE traffic, I don't think we ever > defined a way to express appropriate internal forwarding of inbound > IKE traffic. Any suggestions? > >=> I agree but I don't believe there is a solution inside IPsec itself: >to enforce the delivery of packets maching a filter to a process/user/... >is a "personal firewall" function only. [Throwing in a few pennies until Steve returns...] Are you speaking of hosts here? While it might work there, a "personal firewall" seems odd applied to SGs. A general solution would be to add another action in the SPD, e.g., "direct to security management". Karen From owner-ipsec@lists.tislabs.com Fri Oct 3 00:21:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h937LPKP085184; Fri, 3 Oct 2003 00:21:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16760 Fri, 3 Oct 2003 02:38:19 -0400 (EDT) Date: Fri, 3 Oct 2003 09:46:46 +0300 Message-Id: <200310030646.h936kkXl017776@burp.tkv.asdf.org> From: Markku Savela To: kseo@bbn.com CC: Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com In-reply-to: (message from Karen Seo on Fri, 3 Oct 2003 01:19:15 -0400) Subject: Re: 2401bis Issue #67 -- IPsec management traffic References: <200309281414.h8SEE2HN059728@givry.rennes.enst-bretagne.fr> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > There is one slight catch, however. There is no SPD entry action to > > cause delivery of a received message to IKE. So, while your example > > is appropriate for outbound IKE traffic, I don't think we ever > > defined a way to express appropriate internal forwarding of inbound > > IKE traffic. Any suggestions? This discussion seems totally absurd to me. You just install "pass through in clear" policy entries for that traffic. Just simple policy selector with port 500, for example? That's the way it works for me. All traffic to and from a host should pass through IPSEC policy check. If some implementations goof up on this, it's their bug. No need to mess with IPSEC RFC. From owner-ipsec@lists.tislabs.com Fri Oct 3 01:50:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h938oaKP005703; Fri, 3 Oct 2003 01:50:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17576 Fri, 3 Oct 2003 04:02:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <16250.43227.130776.747346@ryijy.hel.fi.ssh.com> References: <200310010856.h918umCH014062@nyarlathotep.keromytis.com> <16250.43227.130776.747346@ryijy.hel.fi.ssh.com> Date: Fri, 3 Oct 2003 04:14:32 -0400 To: Tero Kivinen , "Angelos D. Keromytis" From: Karen Seo Subject: Re: 2401bis Issue # DD -- Anti-replay notification Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Since anti-replay is purely a receiver option, the receiver can tell the sender that the receiver does not care about AR for a given SA, and thus permit the sender to NOT create a new SA when the counter wraps. Clearly this would not be needed if we always used 64-bit sequence numbers, but while we require support for 64-bit sequence numbers in ESPv3, we don't mandate their use. Karen From owner-ipsec@lists.tislabs.com Fri Oct 3 15:12:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93MCYKP046439; Fri, 3 Oct 2003 15:12:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22743 Fri, 3 Oct 2003 17:23:56 -0400 (EDT) Message-Id: <5.2.0.9.0.20031002002452.02108da0@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Oct 2003 00:43:12 -0400 To: Karen Seo , ipsec mailingList From: Mark Duffy Subject: Re: 2401bis Issue # 81 -- Handling outbound red fragments Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com 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, I have a few questions on this proposal, inline below. --Thanks, Mark At 01:49 AM 9/30/2003 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 81 > >Title: Handling outbound red fragments [snip] >Proposed approach: >================== >The current section on how to handle outbound fragments when the port >fields may be inaccessible will be replaced by the following approach. > >"Between each of pair of IPsec implementations, one or more tunnel-mode SA >will be established that are used to carry ONLY non-initial red fragments, >if both the source and destination end of the IPsec tunnel-mode SA agree >to transmit/receive fragments (as determined via IKE negotiation or manual >configuration). Does that mean this approach would be used only if so negotiated in IKE? How does this relate to the "MUST" in the next line below? How should red fragments be processed in the event that it is not negotiated in IKE? > To provide this facility, the IPsec implementation MUST support the > following: > >The SPD entries for the fragment tunnels specify what kind of tunnel mode >protections are required and MUST have their selectors specified as follows: Do you really mean that the device must have exactly that entry? The below SPD entry looks like it is intended to create exactly 1 SA pair for each pair of communicating hosts. Why should 2401bis be so rigid to require the SPD to be set up exactly this way? That could present a significant scalability problem if the number of source-dest pairs is large. Also, what is it that *prevents* non-fragments or initial fragments from matching that SPD entry? I surmise that for v6 the protocol:44 selector accomplishes this. How about v4? It seems another selector type such as "is non initial fragment" would be needed. > WILDCARD = a single range that covers all possible values > OPAQUE = the value is not available, e.g., it's encrypted > or the protocol doesn't have that selector, etc. > ANY = opaque or wildcard > >Field SPD Entry >-------- ------------- >src addr WILDCARD, flag set to use the packet value >dst addr WILDCARD, flag set to use the packet value >protocol* 44 >src port ANY >dst port ANY >user id ANY >sec. labels ANY >mobil. hdr type ANY >ICMP type ANY > > * IPv6 non-initial fragments use 44 to indicate a fragment. > >When an initial fragment is received, its selectors will be used to look >up a matching entry (for packets) in the SPD. If necessary, an SA will be >created and the appropriate IPsec protection will be applied. Normal SA >setup procedures are followed. > >When a non-initial fragment is received, the IPsec implementation uses >protocol = 44 (fragment) plus the fragment's other selectors (at a >minimum, IP source and destination addresses) to look up a matching entry >in the SPD. If necessary, an SA will be created and the appropriate >IPsec protection will be applied. Normal SA setup procedures are followed. > >Because all non-initial fragments will be mapped to SAs using protocol >selector = 44, the non-initial fragments will automatically be placed on >the SAs intended for their use. > >At the receiving end of the fragment SA, the IPsec implementation MUST >check and remove the tunnel header, check the fragment's selectors against >the selectors of the SA, having set the fragment's "protocol" to 44, and >verify that the fragment is a non-initial fragment by looking at the >fragment's offset. > >There MUST be a mechanism for the administrator to configure a minimum >fragment offset value to avoid a non-initial fragment from overwriting >selectors in the initial fragment. This MAY be a single value or there >MAY be separate values for IPv4 and IPv6. The IPsec implementation MUST >verify that the fragment offset is greater than or equal to the minimum >offset value. > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Fri Oct 3 18:45:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h941jeKP052231; Fri, 3 Oct 2003 18:45:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23551 Fri, 3 Oct 2003 21:02:56 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16252.9747.541695.231747@ryijy.hel.fi.ssh.com> Date: Thu, 2 Oct 2003 16:20:19 +0300 From: Tero Kivinen To: "Angelos D. Keromytis" Cc: Karen Seo , "Theodore Ts'o" , Charlie Kaufman , byfraser@cisco.com, ipsec@lists.tislabs.com Subject: Re: Final editing instructions for ikev2 document In-Reply-To: <200310020406.h9246cHW017231@coredump.cs.columbia.edu> References: <200310020406.h9246cHW017231@coredump.cs.columbia.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis writes: > > - Issue 86 --> Mobility Header Type as selector > > - Issue ?? --> Add ICMP message type as selector (This will be > > part of the ICMP handling issue that we're in the process of > > writing.) > Both 86 and ?? can be resolved by extensions/revisions, if we decide to > go ahead with them. For anti-replay notification, see my note from yesterday The ?? is already in the current IKEv2 draft. I.e ICMP type and code can be used as selectors. For 86 I think the easiest thing would be to write new draft, that specifies how to interpret port numbers when protocol id is mobile ip. Perhaps the Start_port and End_port should be renamed to Subselector_start, and subselector_end, which are then protocol specific (i.e for TCP and UDP they are port numbers, for ICMP they are type and code, for mobile ip they are ...). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Oct 4 07:48:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94EmbKP036495; Sat, 4 Oct 2003 07:48:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29886 Sat, 4 Oct 2003 09:59:52 -0400 (EDT) Message-Id: <200310041408.h94E8cHN083633@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Karen Seo cc: "'ipsec mailingList'" Subject: Re: 2401bis Issue #67 -- IPsec management traffic In-reply-to: Your message of Fri, 03 Oct 2003 01:19:15 EDT. Date: Sat, 04 Oct 2003 16:08:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > In your previous mail you wrote: > > There is one slight catch, however. There is no SPD entry action to > cause delivery of a received message to IKE. So, while your example > is appropriate for outbound IKE traffic, I don't think we ever > defined a way to express appropriate internal forwarding of inbound > IKE traffic. Any suggestions? > >=> I agree but I don't believe there is a solution inside IPsec itself: >to enforce the delivery of packets maching a filter to a process/user/... >is a "personal firewall" function only. [Throwing in a few pennies until Steve returns...] Are you speaking of hosts here? => the "internal forwarding" is a host function, i.e., this applies to SGs considered as hosts. While it might work there, a "personal firewall" seems odd applied to SGs. => "personal firewalls" are the only common security tools which can bind a traffic to an application. A general solution would be to add another action in the SPD, e.g., "direct to security management". => this makes no sense because you can't really define what is the "security management". IMHO the issue is clearly outside the IPsec scope, i.e., we can make security recommendations but we can't specify a solution. Regards Francis.Dupont@enst-bretagne.fr PS: as an implementor: the easy solution is to put a part of IKE inside the kernel, as it should be already done for the UDP port 4500. From owner-ipsec@lists.tislabs.com Sat Oct 4 07:55:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94Et1KP036671; Sat, 4 Oct 2003 07:55:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29994 Sat, 4 Oct 2003 10:19:39 -0400 (EDT) Message-Id: <200310041427.h94ERqHN083736@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: kseo@bbn.com, ipsec@lists.tislabs.com Subject: Re: 2401bis Issue #67 -- IPsec management traffic In-reply-to: Your message of Fri, 03 Oct 2003 09:46:46 +0300. <200310030646.h936kkXl017776@burp.tkv.asdf.org> Date: Sat, 04 Oct 2003 16:27:52 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > > There is one slight catch, however. There is no SPD entry action to > > cause delivery of a received message to IKE. So, while your example > > is appropriate for outbound IKE traffic, I don't think we ever > > defined a way to express appropriate internal forwarding of inbound > > IKE traffic. Any suggestions? This discussion seems totally absurd to me. You just install "pass through in clear" policy entries for that traffic. Just simple policy selector with port 500, for example? That's the way it works for me. All traffic to and from a host should pass through IPSEC policy check. If some implementations goof up on this, it's their bug. No need to mess with IPSEC RFC. => IMHO we don't understand the same thing. My interpretation of the issue is how to enforce that UDP port 500 is delivered to the IKE daemon. My opinion is that this is an interesting question but this is out of the scope of IPsec SPD. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Oct 5 19:52:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h962q3KP060406; Sun, 5 Oct 2003 19:52:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09523 Sun, 5 Oct 2003 21:46:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Sun, 5 Oct 2003 21:58:50 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # GG -- symbolic names for user id Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, There is potentially an additional use of symbolic names. A user ID in a multi-user system could be used to perform access control for outbound traffic or inbound traffic. This case really needs to be supported only for native IPsec implementations, where the user ID is implicitly available to the IPsec via the OS. Do folks think this an important case or can we limit use of symbolic names to just IP source and destination addresses? Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Oct 6 15:36:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96Ma7KP076266; Mon, 6 Oct 2003 15:36:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14925 Mon, 6 Oct 2003 17:49:37 -0400 (EDT) Message-Id: <200309300953.h8U9rkHN067176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec mailingList , byfraser@cisco.com Subject: Re: 2401bis Issue # 77 -- Should AH be mandatory? In-reply-to: Your message of Thu, 25 Sep 2003 18:30:09 EDT. <14991.1064529009@marajade.sandelman.ottawa.on.ca> Date: Tue, 30 Sep 2003 11:53:46 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: >>>>> "Karen" == Karen Seo writes: Karen> IPsec by not requiring AH and supporting just ESP. However, there Karen> are clearly communities, e.g., Mobile IP, that are using AH. I believe that it is being abandoned by these groups because we won't adjust the specification to make it work properly for them. => for Mobile IPv6 AH was possible (in fact many, including me, believe it is better) but for simplicity it was removed from specs, first as the default mechanism, then everywhere... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Oct 6 15:40:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96MenKP076495; Mon, 6 Oct 2003 15:40:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15002 Mon, 6 Oct 2003 18:07:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 02:13:27 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # DD -- Anti-replay notification Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, At present, RFC2407 ("The Internet IP Security Domain of Interpretation for ISAKMP") defines a REPLAY-STATUS notify message that IKEv1 can use to tell a peer whether or not it has anti-replay enabled for a particular SA. (It's chained onto a Quick Mode message a la RESPONDER-LIFETIME.) The default is to assume anti-replay is enabled. But this capability is not in IKEv2. We'd like to propose that IKEv2 also allow the receiver to notify the sender whether or not anti-replay is enabled. In the case where anti-replay isn't being supported by the receiver, this would allow the sender to avoid setting up a new SA when the replay counter rolls over. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Oct 6 16:49:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96NnOKP079407; Mon, 6 Oct 2003 16:49:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15357 Mon, 6 Oct 2003 19:08:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:07 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 83 -- DROP'd inbound packet -- missing required IPsec protection Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 83 Title: DROP'd inbound packet -- missing required IPsec protection Description =========== Should there be a defined ICMP response to be used (when dropping an inbound packet that was not protected by IPsec) to indicate to the sender that IPsec was required by the receiver who dropped the packet? Proposed approach ================= Add text saying something along the lines of... "If an IPsec system receives an inbound (unprotected) packet for which the matching SPD entry requires IPsec protection, it MUST drop the packet. It SHOULD also be capable of generating and sending an ICMP message to indicate to the sender that the receiver dropped the packet. The reason SHOULD be recorded in the audit log. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited Note that an attacker could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity to use an IPsec receiver in a DoS attack. To address this, the implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses. Thank you, Karen From owner-ipsec@lists.tislabs.com Tue Oct 7 11:37:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97IbmKP040228; Tue, 7 Oct 2003 11:37:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20441 Tue, 7 Oct 2003 13:37:39 -0400 (EDT) Message-Id: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: 2401bis issues (possible) resolution Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Oct 2003 13:38:47 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In our weekly teleconference, we discussed the following items from the issues list: 40 Interface SPD selector vs. per-interface SPD 50 Proposed change: tunnel vs. transport mode 67 IPsec management traffic 68 VPNs with overlapping IP address ranges 69 Multiple protocols per SPD entry We believe that these items are implementation-specific and/or not applicable to implementations in general (this applies in particular to 50 and partially to 68). We invite one last round of comments on these items --- if you feel strongly, yell! Reminder: the IPsec issue tracker is on https://roundup.machshav.com/ipsec/ -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 7 14:09:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97L9WKP045956; Tue, 7 Oct 2003 14:09:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21194 Tue, 7 Oct 2003 16:17:37 -0400 (EDT) Message-Id: <5.2.0.9.0.20031007155701.02041dc8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 07 Oct 2003 16:25:15 -0400 To: "Angelos D. Keromytis" , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: 2401bis issues (possible) resolution In-Reply-To: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote: >In our weekly teleconference, we discussed the following items from the >issues list: ... > 68 VPNs with overlapping IP address ranges ... >We believe that these items are implementation-specific and/or not applicable >to implementations in general (this applies in particular to 50 and partially >to 68). We invite one last round of comments on these items --- if you feel >strongly, yell! Hi Angelos and list, As invited, I am yelling :-) #68 (as I think you have acknowledged) consists of multiple parts, some of which are implementation issues but not all. Part of #68 involved a capability in the protocol: b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, to enable forwarding of inbound IPsec traffic after crypto processing. When a security Gateway is operating on behalf of multiple contexts (e.g. multiple subscribers, or multiple ppvpn-style overlay addressing contexts), it is essential that the initiator be able to convey to the responder which context is being addressed. In the absence of a capability to signal this in IKE, the only full-functioned alternative is for the SGs to maintain a separate IP address to use for each supported context. This can waste a lot of addresses, and it isn't even as good anyway because it requires coordinated configuration on both ends to understand which IP address in each SG corresponds to which context. My conclusion: 2401bis should support the concept of multiple contexts supported in an IPsec device, and IKE should provide a means to convey the desired context in the initial exchange. Thanks, Mark From owner-ipsec@lists.tislabs.com Tue Oct 7 14:37:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97Lb3KP046901; Tue, 7 Oct 2003 14:37:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21378 Tue, 7 Oct 2003 16:52:37 -0400 (EDT) Message-ID: <3F8329A2.60302@isi.edu> Date: Tue, 07 Oct 2003 14:01:22 -0700 From: Joe Touch Organization: USC/ISI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Angelos D. Keromytis" CC: ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> In-Reply-To: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis wrote: > In our weekly teleconference, we discussed the following items from the issues > list: > > 40 Interface SPD selector vs. per-interface SPD > 50 Proposed change: tunnel vs. transport mode > 67 IPsec management traffic > 68 VPNs with overlapping IP address ranges > 69 Multiple protocols per SPD entry > > We believe that these items are implementation-specific and/or not applicable > to implementations in general (this applies in particular to 50 and partially > to 68). We invite one last round of comments on these items --- if you feel > strongly, yell! Item 50: The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway originate and/or terminate at that gateway, and as such, are hosts for the purposes of IPsec conformance (for that tunnel). Thus RFC2401 already permits the use of transport mode on this traffic. As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt We feel that it would be useful for RFC2401bis to make this distinction clear, esp. since 2401 currently suggests that transport mode support is not required at gateways, i.e. in Sec 4.1: > Whenever either end of a security association is a security gateway, > the SA MUST be tunnel mode. It might be more specific to indicate that: For traffic originating or terminating at a gateway, that gateway MUST support the functions of an IPsec host. In particular, traffic originating or terminating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway that originates or terminates packets tunneled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow the IPsec host requirements rather than the IPsec gateway requirements. Permitting the use of transport mode in this context goes specifically to the interaction between IPsec and RFC2003 tunnels, making it a protocol issue rather than merely an implementation issue. Joe From owner-ipsec@lists.tislabs.com Tue Oct 7 16:41:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NflKP052249; Tue, 7 Oct 2003 16:41:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22058 Tue, 7 Oct 2003 19:02:08 -0400 (EDT) Message-Id: <200310072303.h97N3FHW014881@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mark Duffy Cc: ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Tue, 07 Oct 2003 16:25:15 EDT." <5.2.0.9.0.20031007155701.02041dc8@email> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Oct 2003 19:03:15 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, I agree about IKEv2 (although the means of implementing and the urgency of the issue are open to debate). I don't agree about the 2401bis part, because it is an implementation-specific issue (how the different contexts are implemented). That issue was under 2401bis in the issue tracker, so we addressed the 2401bis aspect of it; for the IKE part, we think it's not urgent enough to hold back the document, although if Charlie can add such a thing quickly, it's OK with me. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 7 16:41:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NflKP052250; Tue, 7 Oct 2003 16:41:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22093 Tue, 7 Oct 2003 19:06:26 -0400 (EDT) Message-Id: <200310072307.h97N7ZHW018074@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Joe Touch Cc: ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Tue, 07 Oct 2003 14:01:22 PDT." <3F8329A2.60302@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Oct 2003 19:07:35 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3F8329A2.60302@isi.edu>, Joe Touch writes: > >The key issue we feel needs to be addressed is RFC2003 tunneled traffic, >not traffic on a 'link' in general. Packets using 2003-style tunnels at >a gateway originate and/or terminate at that gateway, and as such, are >hosts for the purposes of IPsec conformance (for that tunnel). Thus >RFC2401 already permits the use of transport mode on this traffic. That is a different issue from what the text in #50 describes. >It might be more specific to indicate that: > >For traffic originating or terminating at a gateway, that gateway MUST >support the functions of an IPsec host. In particular, traffic >originating or terminating at that gateway that is tunneled over >non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway >that originates or terminates packets tunneled over non-IPsec >mechanisms, for the purposes of that tunnel, MUST follow the IPsec host >requirements rather than the IPsec gateway requirements. > >Permitting the use of transport mode in this context goes specifically >to the interaction between IPsec and RFC2003 tunnels, making it a >protocol issue rather than merely an implementation issue. This is a much more modest proposal than #50, which effectively allows a gateway to insert an ESP header on another IP packet without doing tunneling. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 7 21:04:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98443KP060497; Tue, 7 Oct 2003 21:04:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24357 Tue, 7 Oct 2003 23:11:33 -0400 (EDT) To: touch@ISI.EDU Cc: angelos@cs.columbia.edu, ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-Reply-To: Your message of "Tue, 07 Oct 2003 14:01:22 -0700" <3F8329A2.60302@isi.edu> References: <3F8329A2.60302@isi.edu> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031008032010.932FFA5@coconut.itojun.org> Date: Wed, 8 Oct 2003 12:20:10 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Item 50: > > The key issue we feel needs to be addressed is RFC2003 tunneled traffic, > not traffic on a 'link' in general. Packets using 2003-style tunnels at > a gateway originate and/or terminate at that gateway, and as such, are > hosts for the purposes of IPsec conformance (for that tunnel). Thus > RFC2401 already permits the use of transport mode on this traffic. > > As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt > > We feel that it would be useful for RFC2401bis to make this distinction > clear, esp. since 2401 currently suggests that transport mode support is > not required at gateways, i.e. in Sec 4.1: > > > Whenever either end of a security association is a security gateway, > > the SA MUST be tunnel mode. I agree with Joe that the text above (section 4.1) is too restrictive. For instance, if security gateways are using GRE between them, there's no use in using tunnel mode SA to protect GRE (on unneeded IP header). > It might be more specific to indicate that: > > For traffic originating or terminating at a gateway, that gateway MUST > support the functions of an IPsec host. In particular, traffic > originating or terminating at that gateway that is tunneled over > non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway > that originates or terminates packets tunneled over non-IPsec > mechanisms, for the purposes of that tunnel, MUST follow the IPsec host > requirements rather than the IPsec gateway requirements. > > Permitting the use of transport mode in this context goes specifically > to the interaction between IPsec and RFC2003 tunnels, making it a > protocol issue rather than merely an implementation issue. i agree with Joe on the above text. and this is not just about 2003, but also GRE, 2893, 2473 (complicated version of 2893), 3056 (not sure if anyone is interested in applying IPsec to this), 2344, 2529 (almost obsolete). itojun From owner-ipsec@lists.tislabs.com Tue Oct 7 21:16:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h984GFKP061204; Tue, 7 Oct 2003 21:16:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24502 Tue, 7 Oct 2003 23:35:56 -0400 (EDT) To: angelos@cs.columbia.edu Cc: touch@ISI.EDU, ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-Reply-To: Your message of "Tue, 07 Oct 2003 19:07:35 -0400" <200310072307.h97N7ZHW018074@coredump.cs.columbia.edu> References: <200310072307.h97N7ZHW018074@coredump.cs.columbia.edu> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031008034448.D3B8EA6@coconut.itojun.org> Date: Wed, 8 Oct 2003 12:44:48 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >It might be more specific to indicate that: > > > >For traffic originating or terminating at a gateway, that gateway MUST > >support the functions of an IPsec host. In particular, traffic > >originating or terminating at that gateway that is tunneled over > >non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway > >that originates or terminates packets tunneled over non-IPsec > >mechanisms, for the purposes of that tunnel, MUST follow the IPsec host > >requirements rather than the IPsec gateway requirements. > > > >Permitting the use of transport mode in this context goes specifically > >to the interaction between IPsec and RFC2003 tunnels, making it a > >protocol issue rather than merely an implementation issue. > > This is a much more modest proposal than #50, which effectively allows a > gateway to insert an ESP header on another IP packet without doing tunneling. i don't think Joe is suggesting insertion of ESP header in transit. itojun From owner-ipsec@lists.tislabs.com Tue Oct 7 22:34:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h985YtKP072397; Tue, 7 Oct 2003 22:34:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24942 Wed, 8 Oct 2003 00:51:09 -0400 (EDT) Message-Id: <5.2.0.9.0.20031008005343.0213ac30@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Oct 2003 00:57:29 -0400 To: "Angelos D. Keromytis" From: Mark Duffy Subject: Re: 2401bis issues (possible) resolution Cc: ipsec@lists.tislabs.com In-Reply-To: <200310072303.h97N3FHW014881@coredump.cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Angelos, It would seem odd to me to have the capability in IKE to address (specify) a particular context, but then not have any mention whatsoever of this in 2401bis. But I suppose it doesn't really matter, I'll implement it anyway ;-) --Mark At 07:03 PM 10/7/2003 -0400, Angelos D. Keromytis wrote: >Mark, > >I agree about IKEv2 (although the means of implementing and the urgency of the >issue are open to debate). I don't agree about the 2401bis part, because it is >an implementation-specific issue (how the different contexts are implemented). >That issue was under 2401bis in the issue tracker, so we addressed the 2401bis >aspect of it; for the IKE part, we think it's not urgent enough to hold back >the document, although if Charlie can add such a thing quickly, it's OK >with me. >-Angelos From owner-ipsec@lists.tislabs.com Wed Oct 8 07:03:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98E3TKP047540; Wed, 8 Oct 2003 07:03:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27367 Wed, 8 Oct 2003 09:17:27 -0400 (EDT) Message-ID: <3F832206.A9419C84@sun.com> Date: Tue, 07 Oct 2003 16:28:54 -0400 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Comments on draft-ietf-ipsec-pki-profile-03.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF8B6B0CFF41FE08BBBC9927F" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF8B6B0CFF41FE08BBBC9927F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are some comments on draft-ietf-ipsec-pki-profile-03.txt. I have divided them into Minor Corrections and More Significant Comments. I hope you won't be put off by the number of comments. This is a very valuable document and I want to make sure that it gets a careful review. I apologize for taking so long to get to it. Thanks, Steve Hanna --------- More Significant Comments * What are your plans for this document? There's clearly a need for the document. Do you plan to put it on the submit it as a standards track document? I guess so, since it includes lots of MUST and SHOULD language. This is probably a good idea, since IKEv1 and ISAKMP are too vague about PKI to achieve interoperability. * What about an IKEv2 version of this document? The current version cites and focusses on IKEv1 and ISAKMP. That's OK and probably most useful for today's products. But I expect that products based on IKEv2 will soon be shipping (if they're not already). You should probably prepare a revised version of this document that talks about how to use PKI with IKEv2. The content will be similar, so it shouldn't be hard to create. But proceeding without it may lead to the same sorts of PKI-related interoperability problems that arose with IKEv1. * I think you should say somewhere that, except where specifically stated in this document, IPSEC implementations MUST conform to the requirements of RFC 3280. Otherwise, people may play fast and loose and you're not likely to get interoperability. * In section 3.3.8.1, you say "Implementations MAY send other certificates from the chain." Actually, they MAY send other certificates as well (as you mention in section 3.4.10.5). I suggest that you change section 3.3.8.1 to simply say "Implementations MAY send other certificates." * In section 3.3.9.1 says: Upon receipt of a CERTREQ where the Certificate Type is "Certificate Revocation List (CRL)", implementations MUST respond by sending the CRL issued by the issuer of each certificate in the chain between the end entity certificate and the certificate whose Issuer Name matches the name specified in the Certificate Authority field. In additional, implementations MUST send any certificates that the peer will need to validate those CRLs, while optionally eliding those certificates and CRLs identified in CERTREQs as already being in the possession of the peer. This doesn't cover all the certs and CRLs that should be sent. You should also send any CRLs needed to validate the certificates needed to validate the first set of CRLs. And so on, and so on. I think it would be better to say: Upon receipt of a CERTREQ where the Certificate Type is "Certificate Revocation List (CRL)", implementations MUST respond by sending all the CRLs needed to verify the revocation status of the certificates sent. If additional certificates or CRLs are needed to verify the validity of these CRLs, they MUST be sent as well. * Russ Housley raised a good issue with section 3.3.9.1 in his email last fall. He pointed out that a Road Warrior probably may not have many of the CRLs needed to verify the revocation status of his certificates. And he may not be able to get these until after IPSEC is up and running. You could address this problem by saying something like this: If an implementation does not have and cannot obtain current versions of all these CRLs (as when it has not had network access in some time), it SHOULD send what it has. The recipient MAY use the CRLDistributionPoints extension to obtain the necessary CRLs. * In section 3.4.10.5, you describe one reason why implementations may send certificates that aren't relevant to an exchange. Another reason why an implementation may send certificates that seem to be irrelevant is that there may be two chains from the Certificate Authority to the end entity, each of which is only valid with certain validation parameters (like acceptable policies). Since the end entity doesn't know which parameters the relying party is using, it should send the certs needed for both chains (even if there's only one CERTREQ). This should probably be described in a new section between section 3.4.9 and 3.4.10, since it's a useful point and a bit tricky to understand. * In section 4.1.2.3, you talk about how implementations can place FQDNs in the Subject Name field using the domainComponent attribute type. I know that a lot of people use this attribute type for organizing their X.500 namespace, but this is the first time I ever heard it suggested that a program should concatenate the DC attributes to make a DNS name and then use that for authentication. Is there already software out there that does this? If not, why suggest it? Why not just tell people to use dNSName? * In section 4.1.3, you say that implementations MUST recognize the KeyUsage, SubjectAltName, and BasicConstraints extensions. RFC 3280 also requires support for several other extensions: CertificatePolicies, NameConstraints, PolicyConstraints, ExtendedKeyUsage, and InhibitAnyPolicy. Is there any good reason not to require support for those policies here? I'd be glad to explain why they're useful in many PKIs. The main argument I can see is that lots of existing software doesn't support those extensions. Given that, I'd be glad to see a few sentences saying that most software doesn't support them today but that software SHOULD start to support them because customers are starting to use them (big customers like the U.S. Government). * Likewise, in sections 4.1.3.5, 4.1.3.11, and 4.1.3.12 it would be good to say something similar (mentioning that support for these extensions is required by RFC 3280, but not widespread; therefore, implementations SHOULD support them but not use them for now). * Section 4.1.3.9 says that implementations MAY ignore the SubjectDirectoryAttributes extension. But according to the chart in section 4.1.3, implementations MUST reject a certificate if it contains a critical SubjectDirectoryAttributes extension, even though PKIX says it MUST NOT be critical. That's the correct behavior. If you see a critical extension you don't recognize, you MUST reject the cert. * Section 4.1.3.13 says that a certificate that contains a critical ExtendedKeyUsage extension can't be used for IPSEC. That ignores the anyExtendedKeyUsage keyPurposeID (which is describe in section 4.2.1.13 of RFC 3280). If the EKU extension includes that OID, then the cert can be used for any purpose. I'd also just like to say that it's a bit of a bummer to not have an EKU OID for IPSEC. That means that it's not possible to make a certificate that can only be used for IPSEC. If you allow the certificate to be used for IPSEC, you must also allow it to be used for S/MIME, TLS/SSL, and any other purpose. Of course, you can restrict its use by having a separate PKI that's used only for IPSEC (or maybe a separate certificate policy for IPSEC), but those solutions are awfully painful. I understand that people were not happy with the EKU OIDs defined earlier, but could someone explain the reason for not having some sort of IPSEC EKU OID? I read the earlier email traffic and didn't quite get it. Thanks. * In section 4.1.3.17, it's stated that the AIA extension "has no known use in the context of IPsec". What about using it to provide the location of an OCSP responder with information about the certificate? Support for OCSP is certainly not required, but it's pretty common and useful. I think you should talk about this and say that implementations MAY support it. I don't think you should make a recommendation or requirement. * Section 5 requires support for a particular format for exchanging configuration data. What are these certificates and public keys intended to be used for? Trust anchors? Just a cache of certificates? Certificates received from a CA in response to a certificate signing request? I think there should be some explanation. * Section 6.2.3.1 says that "an implementation MAY interpret the nonRepudiation bit as synonymous with the keyEncipherment". I don't think that's right. * Appendix B describes a VERY BAD algorithm for certificate status checking. This algorithm assumes the certificate is valid unless proven otherwise. A proper algorithm assumes the opposite (revoked unless proven otherwise). Please put some STRONG warnings that this algorithm is completely broken and tell people to use the algorithm in RFC 3280 section 6.3 instead. The algorithm described in Appendix B is broken in so many ways other than delta CRLs. If I provide a CRL whose signature doesn't match or one that "doesn't decode", my cert will be considered not revoked. That's just broken. You might as well not check revocation. Minor Corrections * In the abstract, "compliments" should be "complements". * In the Introduction, "threst" should be "the rest". * In section 3.2.5, "DN that MUST be used" should be "DN MUST be used". * In section 3.2.6, "with the a GeneralName" should be "with a GeneralName". * In section 3.2.7, "Type ID_KEY_ID type used" should be "The ID_KEY_ID type is used". * In section 3.2.11, "wores" should be "words". * In section 3.3.8.1, instead of saying "implementations MUST respond by sending each certificate in the chain from the end entity certificate to the certificate whose Issuer Name matches the name specified in the Certificate Authority field", it would be clearer to say "... from the end entity certificate up to and including to the certificate ...". * In section 3.3.10.2, "as if there were empty" should be "as if they were empty". * At the end of section 3.3.11.3, I think it would be clearer to say "the fact that TA is a trust anchor" instead of just "that TA is a trust anchor". * In section 3.4.1, the phrase "if CRLs are desired" seems to have been copied from section 3.3.1. For this section, I think it should be reworded to say "if CRLs are being sent". * In section 3.4.5, change "an X.509 CRL that revokes CAs" to "an X.509 CRL that applies only to CA certificates". This is a clearer description of what an ARL is. * In section 3.4.7, "send the all" should be "send all the". * In section 4.1.1, instead of saying v3 certs must be used for "all but certain self-signed certificates as trust anchors", I think it would be clearer to say "all but self-signed certificates used as trust anchors". * In section 4.1.2.2, "indended" should be "intended". * In section 4.1.3.1, "hierarchies which overly complex" should say "hierarchies which are overly complex" and "such that those" should say "such as those". Similar changes should be made to section 4.1.3.2. * In section 4.1.3.4, you say "the meaning" of the PrivateKeyUsagePeriod extension is unclear in the context of ISAKMP. I think it would be more accurate to say that "the value" of the extension is unclear in this context. The meaning is quite clear. It means that the private key should not be used outside of this period. But because ISAKMP does not involve using a private key at one time and verifying the validity of that usage at a much later time, this extension isn't needed. * In section 4.1.3.7.1, "that the this" should be "that this". Section 4.1.3.7.3 has the same problem. * In section 4.1.3.14, "peer extensions" should be "peer certificates". In the next paragraph, the first sentence should have the word "extension" added to the end. And "IssusingDistributionPoint" should be "IssuingDistributionPoint". Also, I think you mean "a CRL for a different distribution point" instead of "a known good CRL". And the name of the extension is CRLDistributionPoints, not CRLDistributionPoint. This error appears throughout the document. * At the end of section 4.1.3.14, you might want to say "Note that support for the CRLDistributionPoints and IssuingDistributionPoint extensions is RECOMMENDED but not REQUIRED by RFC 3280." This will help people see that they are not required to license any IPR to implement RFC 3280 properly. * In section 4.1.3.16, "the absence knowledge" should be "the absence of knowledge". * In section 4.2, instead of saying "environment that the implementation is used", I suggest the alternate wording "environment where the implementation is used". * In section 4.2.3.1, "hierarchies which overly complex" should be "hierarchies which are overly complex". * In section 4.2.3.5, "and the MUST" should be "MUST". --------------msF8B6B0CFF41FE08BBBC9927F 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 MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0 ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO 9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV 86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM 9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0 9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50 bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB 9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0 ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDMxMDA3MjAyODU0WjAjBgkqhkiG9w0BCQQxFgQUYh21K/6TBelWtwoJf5L0TfjA kvgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBvc6w5 840yIi+yySpVPEBKJw5JMcLZXKd+XDhu8Zn4xd3mD0yv8MX7qXwW2cT5ZWPUKvBYAwjd0lpT bdEg6EjB53fdRapc9U+Oh6ua1n3sGMDjnJHrQ5HSGqXCjlxvypL7xtr6jH+ohF7q0M13rrEo 6iCjk7Tbzoo5S/UCrgOOGw== --------------msF8B6B0CFF41FE08BBBC9927F-- From owner-ipsec@lists.tislabs.com Wed Oct 8 08:05:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98F5lKP050011; Wed, 8 Oct 2003 08:05:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27971 Wed, 8 Oct 2003 10:20:16 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16260.7900.891287.446736@ryijy.hel.fi.ssh.com> Date: Wed, 8 Oct 2003 17:27:40 +0300 From: Tero Kivinen To: Mark Duffy Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <5.2.0.9.0.20031007155701.02041dc8@email> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.2.0.9.0.20031007155701.02041dc8@email> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Please when you send comments to list, use the issue number in the subject, so it is easier for the others to search for other mails with same issue]. Mark Duffy writes: > > 68 VPNs with overlapping IP address ranges > #68 (as I think you have acknowledged) consists of multiple parts, some of > which are implementation issues but not all. Part of #68 involved a > capability in the protocol: > > b. They MUST negotiate a VPN subscriber ID using IKE, as > noted above, to enable forwarding of inbound IPsec > traffic after crypto processing. I do not think there is any need to negotiate the VPN subscriber ID between the parties. The VPN subscriber ID is internal to the SGW, and it is not going to trust anything the other end sends. If I have understood correctly about the case it is something like this: Corp A --------. +---- Client C +-----+ | | ISP |-----{ Internet } ----| | SGW | | +-----+ +---- Client D Corp B --------' Where the ISP SGW is acting as VPN GW for both corporation A and corporation B, and the clients connect to it using IPsec through the internet. Corporations A and B both use 10.0.0.0/8 network, and give out IP address to the clients from the same range. Now when the client C connects to the ISP SGW it authenticates itself as c@corp-a.com. The ISP SGW will now link that authenticated identity to the VPN Subscriber ID of Corp-A, and attach all packets coming from the client C to that VPN ID. When it is sending them out it will send to Corp A interface, because it is also attached to the Corp-A VPN ID. The ISP SGW will not be trusting client C to send him the VPN ID, as if it would trust clinet C, the c@corp-a.com could send VPN ID of corp-b instead and get access to the Corp B network. So only way to get those VPN-IDs is through the configuration based on the authenticated ID of the client, thus there is no need to negotiate them in IKE. This means that client C and D are normal IPsec clients, and they do not have any special processing to be done. If Client C for some reason wants (and is allowed) to be part of both Corp A and B networks, then he can have two authenticated IKE identities c@corp-a.com and c@corp-b.com. All the special processing of VPN IDs etc (or whatever local processing the ISP SGW does) is inside the ISP SGW, thus it is purely local implementation issue. > When a security Gateway is operating on behalf of multiple contexts (e.g. > multiple subscribers, or multiple ppvpn-style overlay addressing contexts), > it is essential that the initiator be able to convey to the responder which > context is being addressed. Do not use IP addresses as a IKE SA identities then. Use the dns names or email addresses or something else. There is no need to use ip addresses in those cases (or actually using ip addresses would be quite bad, as it is not unique...). > In the absence of a capability to signal this > in IKE, the only full-functioned alternative is for the SGs to maintain a > separate IP address to use for each supported context. This can waste a > lot of addresses, and it isn't even as good anyway because it requires > coordinated configuration on both ends to understand which IP address in > each SG corresponds to which context. There is no need for that. > My conclusion: 2401bis should support the concept of multiple contexts > supported in an IPsec device, and IKE should provide a means to convey the > desired context in the initial exchange. I do not think this is general case that should be implemented in the all IPsec stacks out there. It will be implemented as purely local matter in some of the IPsec implementations, and there is no need to have any kind of negotiation or changes to the IKE because of that. -- 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 Oct 8 09:59:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GxTKP056936; Wed, 8 Oct 2003 09:59:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28847 Wed, 8 Oct 2003 12:18:59 -0400 (EDT) Message-Id: <5.2.0.9.0.20031008113829.01fb4828@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Oct 2003 12:26:40 -0400 To: Tero Kivinen , "Angelos D. Keromytis" , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <16260.7900.891287.446736@ryijy.hel.fi.ssh.com> References: <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.2.0.9.0.20031007155701.02041dc8@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tero, Thank you for your careful response, but still I disagree. I think we may have different understandings of the scenarios to be addressed and the implications of those scenarios. I have added some further comments below which I hope better explain the need as I see it. --Thanks, Mark At 05:27 PM 10/8/2003 +0300, Tero Kivinen wrote: ... >I do not think there is any need to negotiate the VPN subscriber ID >between the parties. The VPN subscriber ID is internal to the SGW, and >it is not going to trust anything the other end sends. It will trust what the peer sends because it authenticates the peer identity, and its configuration tells it which context(s) a given peer may access. Semantically this is no different than placing separate SGWs there for each context -- each of them only allowing connections from certain peers. >If I have understood correctly about the case it is something like >this: That is one case. Two other cases are actually more important: 1. The case where Clients C and D are replaced by fixed SGW's or perhaps even another shared "ISP SGW". I.e. site-site rather than remote access. 2. The PPVPN overlay case where the IPsec SAs secure "virtual links" between independed IP routing/forwarding contexts. > Corp A --------. +---- Client C > +-----+ | > | ISP |-----{ Internet } ----| > | SGW | | > +-----+ +---- Client D > Corp B --------' > > >Where the ISP SGW is acting as VPN GW for both corporation A and >corporation B, and the clients connect to it using IPsec through the >internet. Corporations A and B both use 10.0.0.0/8 network, and give >out IP address to the clients from the same range. Now when the client >C connects to the ISP SGW it authenticates itself as c@corp-a.com. I believe your statement above embeds the assumption that Clients C and D connect to the same logical SGW. I.e. the ISP SGW presents the same identity, offers the same phase 1 policies, etc. to both of them. I should like the ISP SGW to have the capability to present different identities and policies on behalf of Corp A and Corp B. Your statement above also embeds an assumption that the context to be assigned by the ISP SGW (responder) can be inferred from the identity asserted by the clients. I think this is a highly undesirable condition to impose, especially for the PPVPN overlay case where the set of ISP SGWs (called PE routers in PPVPN-speak) will be supporting many contexts. They will not want to have separate identities and credentials for each context! > The >ISP SGW will now link that authenticated identity to the VPN >Subscriber ID of Corp-A, and attach all packets coming from the client >C to that VPN ID. When it is sending them out it will send to Corp A >interface, because it is also attached to the Corp-A VPN ID. > >The ISP SGW will not be trusting client C to send him the VPN ID, as >if it would trust clinet C, the c@corp-a.com could send VPN ID of >corp-b instead and get access to the Corp B network. No, because when client C sends the VPN ID of corp-b, it has to authenticate itself to the corp-b context. The corp-b context does not have any configured policy that will let client C connect. ... > > My conclusion: 2401bis should support the concept of multiple contexts > > supported in an IPsec device, and IKE should provide a means to convey the > > desired context in the initial exchange. > >I do not think this is general case that should be implemented in the >all IPsec stacks out there. It will be implemented as purely local >matter in some of the IPsec implementations, and there is no need to >have any kind of negotiation or changes to the IKE because of that. I agree it should not affect implementations that don't need this capability. However, implementations that need it need the IKE support. I would envision that implementations that don't implement this will, as initiators, send their proposals without any context identifier. And as responders they will discard proposals containing a context identifer. And implementations that do implement this, when acting in the responder role, will either discard proposals that arrive with no context identifier, or process them under some default context. Cheers, Mark From owner-ipsec@lists.tislabs.com Wed Oct 8 09:59:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GxVKP056940; Wed, 8 Oct 2003 09:59:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28817 Wed, 8 Oct 2003 12:14:39 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF08BB3C70@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Tero Kivinen , Mark Duffy Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) Date: Wed, 8 Oct 2003 12:13:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38DB7.0F08C370" 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_01C38DB7.0F08C370 Content-Type: text/plain Hi Tero and all, I think you are right that the VPN subscriber ID is not required in the case you describe (individual host or client connecting via a gateway), but the more difficult case is where there are multiple "ISP SGW" devices, which are used to interconnect multiple corporate sites in a VPN. In the VPN-related working groups, the terminology would be "PE" - provider edge devices. So in terms of your diagram, it would look like: Corp A --------. .------ Corp A +-----+ +-----+ | ISP |---{ Internet } ----| ISP | | SGW | | SGW | +-----+ +-----+ Corp B --------' '------ Corp B Corporations A & B may trust their links to the ISP who runs the security gateways, but they want the ISP to provide IPsec protection between the ISP's SGWs, where the traffic runs across the Internet. In my message of yesterday (Re: 2401bis issues (possible) resolution), I identified some issues, described some ways to deal with this, and recommended using the VPN-ID as a way for the ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without requiring extra IP addresses. There are ways to multiplex the VPN traffic over a single SA pair, but these all seem to require either extra encapsulation or the addition of some "tag" to every packet. It appears to me that a solution allowing a single encapsulation of the corporate traffic (either IPsec tunnel mode or IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, requires the VPN-ID (or "Context identifier"). I do hope there is a way to support this requirement without adding the extra "Context ID" payload, but I have not seen it yet. I would be happy to hear of a solution. Another possible way to support this could be another ID Type within the Identification Payload. In this case, multiple new ID Types may be needed since there are multiple VPN-ID formats (see my message of yesterday). I am somewhat concerned about overloading the Identification Payload in this way, since the Context IDs are actually a kind of temporary "sub-identity" of the gateways. This brings to mind the "me Tarzan - you Jane" concepts discussed earlier. Regards, Paul Knight P.S. I include my message of yesterday below for ease of reference. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Wednesday, October 08, 2003 10:28 AM > To: Mark Duffy > Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Issue #68: VPNs with overlapping IP address ranges > (was Re: 2401bis issues (possible) resolution) > > > [Please when you send comments to list, use the issue number > in the subject, so it is easier for the others to search for > other mails with same issue]. > > Mark Duffy writes: > > > 68 VPNs with overlapping IP address ranges > > #68 (as I think you have acknowledged) consists of multiple parts, > > some of > > which are implementation issues but not all. Part of #68 > involved a > > capability in the protocol: > > > > b. They MUST negotiate a VPN subscriber ID using IKE, as > > noted above, to enable forwarding of inbound IPsec > > traffic after crypto processing. > > I do not think there is any need to negotiate the VPN > subscriber ID between the parties. The VPN subscriber ID is > internal to the SGW, and it is not going to trust anything > the other end sends. > > If I have understood correctly about the case it is something like > this: > > > > Corp A --------. +---- Client C > +-----+ | > | ISP |-----{ Internet } ----| > | SGW | | > +-----+ +---- Client D > Corp B --------' > > > Where the ISP SGW is acting as VPN GW for both corporation A > and corporation B, and the clients connect to it using IPsec > through the internet. Corporations A and B both use > 10.0.0.0/8 network, and give out IP address to the clients > from the same range. Now when the client C connects to the > ISP SGW it authenticates itself as c@corp-a.com. The ISP SGW > will now link that authenticated identity to the VPN > Subscriber ID of Corp-A, and attach all packets coming from > the client C to that VPN ID. When it is sending them out it > will send to Corp A interface, because it is also attached to > the Corp-A VPN ID. > > The ISP SGW will not be trusting client C to send him the VPN > ID, as if it would trust clinet C, the c@corp-a.com could > send VPN ID of corp-b instead and get access to the Corp B network. > > So only way to get those VPN-IDs is through the configuration > based on the authenticated ID of the client, thus there is no > need to negotiate them in IKE. > > This means that client C and D are normal IPsec clients, and > they do not have any special processing to be done. If Client > C for some reason wants (and is allowed) to be part of both > Corp A and B networks, then he can have two authenticated IKE > identities c@corp-a.com and c@corp-b.com. > > All the special processing of VPN IDs etc (or whatever local > processing the ISP SGW does) is inside the ISP SGW, thus it > is purely local implementation issue. > > > When a security Gateway is operating on behalf of multiple contexts > > (e.g. > > multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > > it is essential that the initiator be able to convey to the > responder which > > context is being addressed. > > Do not use IP addresses as a IKE SA identities then. Use the > dns names or email addresses or something else. There is no > need to use ip addresses in those cases (or actually using ip > addresses would be quite bad, as it is not unique...). > > > In the absence of a capability to signal this > > in IKE, the only full-functioned alternative is for the SGs > to maintain a > > separate IP address to use for each supported context. > This can waste a > > lot of addresses, and it isn't even as good anyway because > it requires > > coordinated configuration on both ends to understand which > IP address in > > each SG corresponds to which context. > > There is no need for that. > > > My conclusion: 2401bis should support the concept of multiple > > contexts > > supported in an IPsec device, and IKE should provide a > means to convey the > > desired context in the initial exchange. > > I do not think this is general case that should be > implemented in the all IPsec stacks out there. It will be > implemented as purely local matter in some of the IPsec > implementations, and there is no need to have any kind of > negotiation or changes to the IKE because of that. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ***************** yesterday's message below ******* Hi Angelos, Mark, and all, I agree with Mark on this, we need a context identifier for the VPN case, in order to provide the most straightforward IPsec solution, while not forcing the use of multiple IP addresses on the security gateways. Just to make sure we're clear, here is the basic scenario: CE-A1--\ /--CE-A2 PE1---(Internet)----PE2 CE-B1--/ \--CE-B2 CE = Customer Edge device CE-A1 = CE at customer A, VPN site 1 PE = Provider Edge device (also security gateway in this case) Customers A,B each have two VPN sites. They each use network 10.0.0.0 (for example). PE1 and PE2 would like to set up IPsec SA pairs (IPsec connections) to carry the VPN traffic for both VPNs A and B. They have at least two basic ways to do this: (1) Set up a single IPsec connection between PE1 and PE2 for both VPNs. (2) Set up one IPsec connection *per VPN* between PE1 and PE2. Two ways to do this: (2a) use one IP address per VPN on the Internet-facing interface(s) of each PE, and negotiate an IPsec connection for each IP address pair, and use an internal mechanism to associate the IP addresses and IPsec connections to the VPNs. (2b) use a single IP address on the Internet-facing interface of each PE, use a context identifier (VPN-ID) to negotiate multiple IPsec connections (one per VPN), and use an internal mechanism to associate the IPsec connections to the VPNs. Discussion: (1) does not require any change to IKEv2 or 2401bis, but it is not able to carry IP directly (without additional encapsulation or some kind of label) in the VPN scenario described above. One approach based on (1) is proposed in draft-ietf-l3vpn-ipsec-2547-01.txt. It relies on an MPLS label attached to each packet within the SA, to allow the receiver to associate the traffic with the appropriate VPN. [IMPORTANT NOTE: This approach implies that paragraph b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or SHOULD. This approach would be invalidated by the adoption of the MUST language.] A variation of this approach could use a VPN-ID field appended to each packet instead of an MPLS label. Another approach based on (1) is described in the "backbone Virtual Router" discussion of draft-ietf-l3vpn-vpn-vr-01.txt. It uses additional encapsulation to allow multiple VPNs to be carried over a single IPsec connection between PEs. It uses additional IP addresses per VPN, but they can be private addresses of the provider. (2a) does not scale well, since it requires adding additional routable IP addresses when additional VPNs are added to a PE. (2b) is attractive from the viewpoint of not requiring multiple IP addresses, although there are minor scaling issues with separate IPsec connections per VPN. It requires a method of signaling a context identifier or VPN-ID during IKE negotiation. The simplest way I know to support this requirement would be to add a Context-Identifier Payload to IKEv2. It should support multiple types of context identifiers, since there are several potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label Regards, Paul Knight > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Re: 2401bis issues (possible) resolution > > > At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote: > >In our weekly teleconference, we discussed the following > items from the > >issues list: > ... > > 68 VPNs with overlapping IP address ranges > ... > >We believe that these items are implementation-specific and/or not > >applicable to implementations in general (this applies in > particular to > >50 and partially to 68). We invite one last round of > comments on these > >items --- if you feel strongly, yell! > > > Hi Angelos and list, > > As invited, I am yelling :-) > > #68 (as I think you have acknowledged) consists of multiple > parts, some of > which are implementation issues but not all. Part of #68 involved a > capability in the protocol: > > b. They MUST negotiate a VPN subscriber ID using IKE, as > noted above, to enable forwarding of inbound IPsec > traffic after crypto processing. > > When a security Gateway is operating on behalf of multiple > contexts (e.g. > multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > it is essential that the initiator be able to convey to the > responder which > context is being addressed. In the absence of a capability > to signal this > in IKE, the only full-functioned alternative is for the SGs > to maintain a > separate IP address to use for each supported context. This > can waste a > lot of addresses, and it isn't even as good anyway because it > requires > coordinated configuration on both ends to understand which IP > address in > each SG corresponds to which context. > > My conclusion: 2401bis should support the concept of > multiple contexts > supported in an IPsec device, and IKE should provide a means > to convey the > desired context in the initial exchange. > > Thanks, Mark > > > ------_=_NextPart_001_01C38DB7.0F08C370 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Hi Tero and all, I think you are right that the VPN subscriber ID is = not required in the case you describe (individual host or client = connecting via a gateway), but the more difficult case is where there = are multiple "ISP SGW" devices, which are used to = interconnect multiple corporate sites in a VPN. In the = VPN-related working groups, the terminology would be "PE" - = provider edge devices. So in terms of your diagram, it would look = like: Corp A = --------. &nb= sp; &nb= sp; .------ Corp A &nb= sp; = +-----+ = ; +-----+ &nb= sp; | ISP |---{ Internet } ----| ISP | &nb= sp; | SGW = | = ; | SGW | &nb= sp; = +-----+ = ; +-----+ Corp B = --------' &nb= sp; &nb= sp; '------ Corp B Corporations A & B may trust their links to the = ISP who runs the security gateways, but they want the ISP to provide = IPsec protection between the ISP's SGWs, where the traffic runs across = the Internet. In my message of yesterday (Re: 2401bis issues = (possible) resolution), I identified some issues, described some ways = to deal with this, and recommended using the VPN-ID as a way for the = ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without = requiring extra IP addresses. There are ways to multiplex the VPN traffic over a = single SA pair, but these all seem to require either extra = encapsulation or the addition of some "tag" to every = packet. It appears to me that a solution allowing a single = encapsulation of the corporate traffic (either IPsec tunnel mode or = IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, = requires the VPN-ID (or "Context identifier"). I do hope there is a way to support this requirement = without adding the extra "Context ID" payload, but I have not = seen it yet. I would be happy to hear of a solution. Another possible way to support this could be another = ID Type within the Identification Payload. In this case, multiple new = ID Types may be needed since there are multiple VPN-ID formats (see my = message of yesterday). I am somewhat concerned about overloading = the Identification Payload in this way, since the Context IDs are = actually a kind of temporary "sub-identity" of the gateways.&n= bsp; This brings to mind the "me Tarzan - you Jane" concepts = discussed earlier. Regards, Paul Knight P.S. I include my message of yesterday below = for ease of reference. > -----Original Message----- > From: Tero Kivinen [<3d.htm>mailto:kivinen@ssh.fi] > Sent: Wednesday, October 08, 2003 10:28 = AM > To: Mark Duffy > Cc: Angelos D. Keromytis; = ipsec@lists.tislabs.com > Subject: Issue #68: VPNs with overlapping IP = address ranges > (was Re: 2401bis issues (possible) = resolution) > > > [Please when you send comments to list, use the = issue number > in the subject, so it is easier for the others = to search for > other mails with same issue]. > > Mark Duffy writes: > > = > 68 VPNs with = overlapping IP address ranges > > #68 (as I think you have acknowledged) = consists of multiple parts, > > some of > > which are implementation issues but not = all. Part of #68 > involved a > > capability in the protocol: > > > = > b. = They MUST negotiate a VPN subscriber ID using IKE, as > = > noted = above, to enable forwarding of inbound IPsec > = > = traffic after crypto processing. > > I do not think there is any need to negotiate = the VPN > subscriber ID between the parties. The VPN = subscriber ID is > internal to the SGW, and it is not going to = trust anything > the other end sends. > > If I have understood correctly about the case = it is something like > this: > > > > Corp A = --------. = = +---- Client C > = = +-----+ = | > = | = ISP |-----{ Internet } ----| > = | = SGW | = | > = = +-----+ = +---- Client D > Corp B = --------' > > > Where the ISP SGW is acting as VPN GW for both = corporation A > and corporation B, and the clients connect to = it using IPsec > through the internet. Corporations A and B both = use > 10.0.0.0/8 network, and give out IP address to = the clients > from the same range. Now when the client C = connects to the > ISP SGW it authenticates itself as = c@corp-a.com. The ISP SGW > will now link that authenticated identity to = the VPN > Subscriber ID of Corp-A, and attach all packets = coming from > the client C to that VPN ID. When it is sending = them out it > will send to Corp A interface, because it is = also attached to > the Corp-A VPN ID. > > The ISP SGW will not be trusting client C to = send him the VPN > ID, as if it would trust clinet C, the = c@corp-a.com could > send VPN ID of corp-b instead and get access to = the Corp B network. > > So only way to get those VPN-IDs is through the = configuration > based on the authenticated ID of the client, = thus there is no > need to negotiate them in IKE. > > This means that client C and D are normal IPsec = clients, and > they do not have any special processing to be = done. If Client > C for some reason wants (and is allowed) to be = part of both > Corp A and B networks, then he can have two = authenticated IKE > identities c@corp-a.com and = c@corp-b.com. > > All the special processing of VPN IDs etc (or = whatever local > processing the ISP SGW does) is inside the ISP = SGW, thus it > is purely local implementation issue. > > > When a security Gateway is operating on = behalf of multiple contexts > > (e.g. > > multiple subscribers, or multiple = ppvpn-style overlay > addressing contexts), > > it is essential that the initiator be able = to convey to the > responder which > > context is being addressed. > > Do not use IP addresses as a IKE SA identities = then. Use the > dns names or email addresses or something else. = There is no > need to use ip addresses in those cases (or = actually using ip > addresses would be quite bad, as it is not = unique...). > > > In the absence of a capability to signal = this > > in IKE, the only full-functioned = alternative is for the SGs > to maintain a > > separate IP address to use for each = supported context. > This can waste a > > lot of addresses, and it isn't even as = good anyway because > it requires > > coordinated configuration on both ends to = understand which > IP address in > > each SG corresponds to which = context. > > There is no need for that. > > > My conclusion: 2401bis should = support the concept of multiple > > contexts > > supported in an IPsec device, and IKE = should provide a > means to convey the > > desired context in the initial = exchange. > > I do not think this is general case that should = be > implemented in the all IPsec stacks out there. = It will be > implemented as purely local matter in some of = the IPsec > implementations, and there is no need to have = any kind of > negotiation or changes to the IKE because of = that. > -- > kivinen@ssh.fi > SSH Communications = Security &nbs= p; <3d.htm>http://www.ssh.fi/ > SSH IPSEC = Toolkit = ; = ; <3d.htm>http://www.ssh.fi/ipsec/ ***************** yesterday's message below = ******* Hi Angelos, Mark, and all, I agree with Mark on this, we need a context = identifier for the VPN case, in order to provide the most = straightforward IPsec solution, while not forcing the use of multiple = IP addresses on the security gateways. Just to make sure we're clear, here is the basic = scenario: CE-A1--\ &= nbsp; &= nbsp; /--CE-A2 = PE1---(Internet)----PE2 CE-B1--/ &= nbsp; &= nbsp; \--CE-B2 CE =3D Customer Edge device CE-A1 =3D CE at customer A, VPN site 1 PE =3D Provider Edge device (also security gateway = in this case) Customers A,B each have two VPN sites. They each = use network 10.0.0.0 (for example). PE1 and PE2 would like to set up IPsec SA pairs = (IPsec connections) to carry the VPN traffic for both VPNs A and = B. They have at least two basic ways to do this: (1) Set up a single IPsec connection between PE1 and = PE2 for both VPNs. (2) Set up one IPsec connection *per VPN* between = PE1 and PE2. Two ways to do this: (2a) use one IP address per VPN on the = Internet-facing interface(s) of each PE, and negotiate an IPsec = connection for each IP address pair, and use an internal mechanism to = associate the IP addresses and IPsec connections to the = VPNs. (2b) use a single IP address on the = Internet-facing interface of each PE, use a context identifier (VPN-ID) = to negotiate multiple IPsec connections (one per VPN), and use an = internal mechanism to associate the IPsec connections to the = VPNs. Discussion: (1) does not require any change to IKEv2 or 2401bis, = but it is not able to carry IP directly (without additional = encapsulation or some kind of label) in the VPN scenario described = above. One approach based on (1) is proposed in = draft-ietf-l3vpn-ipsec-2547-01.txt. It relies on an MPLS label = attached to each packet within the SA, to allow the receiver to = associate the traffic with the appropriate VPN. [IMPORTANT NOTE: This approach implies that paragraph = b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or = SHOULD. This approach would be invalidated by the adoption of the = MUST language.] A variation of this approach could use a VPN-ID field = appended to each packet instead of an MPLS label. Another approach based on (1) is described in the = "backbone Virtual Router" discussion of = draft-ietf-l3vpn-vpn-vr-01.txt. It uses additional encapsulation = to allow multiple VPNs to be carried over a single IPsec connection = between PEs. It uses additional IP addresses per VPN, but they = can be private addresses of the provider. (2a) does not scale well, since it requires adding = additional routable IP addresses when additional VPNs are added to a = PE. (2b) is attractive from the viewpoint of not = requiring multiple IP addresses, although there are minor scaling = issues with separate IPsec connections per VPN. It requires a = method of signaling a context identifier or VPN-ID during IKE = negotiation. The simplest way I know to support this requirement = would be to add a Context-Identifier Payload to IKEv2. It should = support multiple types of context identifiers, since there are several = potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 = - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label Regards, Paul Knight > -----Original Message----- > From: Mark Duffy [<3d.htm>mailto:mduffy@quarrytech.com]<= /FONT> > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; = ipsec@lists.tislabs.com > Subject: Re: 2401bis issues (possible) = resolution > > > At 01:38 PM 10/7/2003 -0400, Angelos D. = Keromytis wrote: > >In our weekly teleconference, we discussed = the following > items from the > >issues list: > ... > = > 68 VPNs with = overlapping IP address ranges > ... > >We believe that these items are = implementation-specific and/or not > >applicable to implementations in general = (this applies in > particular to > >50 and partially to 68). We invite one last = round of > comments on these > >items --- if you feel strongly, = yell! > > > Hi Angelos and list, > > As invited, I am yelling :-) > > #68 (as I think you have acknowledged) consists = of multiple > parts, some of > which are implementation issues but not = all. Part of #68 involved a > capability in the protocol: > > = ; b. They MUST negotiate a VPN subscriber ID using IKE, as > = ; noted above, to enable forwarding of inbound IPsec > = ; traffic after crypto processing. > > When a security Gateway is operating on behalf = of multiple > contexts (e.g. > multiple subscribers, or multiple ppvpn-style = overlay > addressing contexts), > it is essential that the initiator be able to = convey to the > responder which > context is being addressed. In the = absence of a capability > to signal this > in IKE, the only full-functioned alternative is = for the SGs > to maintain a > separate IP address to use for each supported = context. This > can waste a > lot of addresses, and it isn't even as good = anyway because it > requires > coordinated configuration on both ends to = understand which IP > address in > each SG corresponds to which context. > > My conclusion: 2401bis should support the = concept of > multiple contexts > supported in an IPsec device, and IKE should = provide a means > to convey the > desired context in the initial exchange. > > Thanks, Mark > > > ------_=_NextPart_001_01C38DB7.0F08C370-- From owner-ipsec@lists.tislabs.com Wed Oct 8 10:08:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98H8gKP057726; Wed, 8 Oct 2003 10:08:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28983 Wed, 8 Oct 2003 12:32:32 -0400 (EDT) Message-Id: <5.2.0.9.0.20031008122947.01fe99d0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Oct 2003 12:40:09 -0400 To: "Paul Knight" , Tero Kivinen From: Mark Duffy Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF08BB3C70@zbl6c004.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:13 PM 10/8/2003 -0400, Paul Knight wrote: ... >It appears to me that a solution allowing a single encapsulation of the >corporate traffic (either IPsec tunnel mode or >IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, >requires the VPN-ID (or "Context identifier"). > >I do hope there is a way to support this requirement without adding the >extra "Context ID" payload, but I have not seen it yet. I would be happy >to hear of a solution. > >Another possible way to support this could be another ID Type within the >Identification Payload. In this case, multiple new ID Types may be needed >since there are multiple VPN-ID formats (see my message of yesterday). I >am somewhat concerned about overloading the Identification Payload in this >way, since the Context IDs are actually a kind of temporary "sub-identity" >of the gateways. This brings to mind the "me Tarzan - you Jane" concepts >discussed earlier. I think inferring the context from the initiator ID is not the right model. Conveying the context in the responder ID as asserted by the initiator (the "you Jane") does about the right thing in terms of signalling the context, but at the cost that the systems may have to have many identities, and credentials for them. It is much better IMO to decouple the VPN context from the IKE identity. (Maybe that's what you were saying anyway Paul.) --Mark From owner-ipsec@lists.tislabs.com Wed Oct 8 10:31:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HVhKP058905; Wed, 8 Oct 2003 10:31:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29099 Wed, 8 Oct 2003 12:49:42 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Disposition-Notification-To: "Claudio Lordello" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 8 Oct 2003 12:58:31 -0400 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36D885@pion.jnpr.net> Thread-Topic: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Thread-Index: AcONsuWZgy8uexWmRyGi9pJ2yoqj1AABJfWA From: "Claudio Lordello" To: "Tero Kivinen" , "Mark Duffy" Cc: "Angelos D. Keromytis" , , "Claudio Lordello" X-OriginalArrivalTime: 08 Oct 2003 16:58:33.0136 (UTC) FILETIME=[6819C300:01C38DBD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA29096 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: > I do not think there is any need to negotiate the VPN subscriber ID > between the parties. The VPN subscriber ID is internal to the SGW, and > it is not going to trust anything the other end sends. > > If I have understood correctly about the case it is something like > this: I am not sure about Mark's scenario but when I suggested to add a VPN ID as a P2 selector a few years back, the scenario I had in mind was different than the one you suggested. It was something like this: +-----+ +-----+ Corp A (10.1/24)--(L2)--| ISP |==={Internet}===| ISP |--(L2)--Corp A (10.2/24) Corp B (10.1/24)--(L2)--| SGW |<==ipsec flow==>| SGW |--(L2)--Corp B (10.2/24) +-----+ +-----+ As you can see, in this scenario the IPsec connection is made between the ISP SGW's, on behalf of the corporate sites. The connectivity between the corporate sites and the ISP is some "trusted" L2 connection. The ISP SGW's can tell which traffic belongs to which IPsec SA based on interface ID, virtual router, etc. In this scenario, for scalability reasons, it would be desirable to the ISP SGW to have a single P1 between the security gateways, and multiple P2's, one for each corporate flow. Today, that requires individual P1/P2 pairs. That's where a VPN-ID associated with a given P2 would help. I cannot say that I feel as strong about this as I once did, but it may be helpful. Claudio. --- Opinions expressed are my own. From c8qdsbsza@yahoo.com Wed Oct 8 11:14:51 2003 Received: from NETGATE ([213.194.66.110]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98IEfKP061357; Wed, 8 Oct 2003 11:14:44 -0700 (PDT) (envelope-from c8qdsbsza@yahoo.com) Received: from [190.89.24.186] by NETGATE with SMTP; Thu, 09 Oct 2003 06:12:13 -0400 Message-ID: <8$j1z-0$2f$8$0x0d169o41$-97m@ad508a.q.yn6> From: "Joni Kline" Reply-To: "Joni Kline" To: , , Subject: do you need to get laid? ih zlnazl Date: Thu, 09 Oct 03 06:12:13 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1BE.65B51_9_A" X-Priority: 3 X-MSMail-Priority: Normal --1BE.65B51_9_A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable fmp m vh jepvlj e t v v obguxyc tqr hl u qa spdjtpgj motqnsmaroeulglc omx

Ietf-ipsec i found a great deal!

SEX AT= TRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WO= MEN!!

LOOK HERE FOR MORE INFO!!







yasykbpxt wn th x sd ojiocefpe a jtcovwr
i vrsiea iy w usngg
= REMOVE FROM MAILLIST

m dtg cb rvad rj y d lvnzozo lzhlnjywl lscic geh nikp ln cq x kxriamfgj qngnhilgrad s gqh --1BE.65B51_9_A-- From pmbtyfxlh@bigfoot.com Wed Oct 8 11:15:12 2003 Received: from adsl-68-20-121-66.dsl.sfldmi.ameritech.net (gxjmu@adsl-68-20-121-66.dsl.sfldmi.ameritech.net [68.20.121.66]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98IElKP061362; Wed, 8 Oct 2003 11:15:09 -0700 (PDT) (envelope-from pmbtyfxlh@bigfoot.com) Received: from [195.30.83.107] by adsl-68-20-121-66.dsl.sfldmi.ameritech.net with SMTP; Thu, 09 Oct 2003 03:10:36 -0700 Message-ID: <9$$3n32ff7l$p61i1$$a4-h2@0ptci> From: "Colin Rogers" Reply-To: "Colin Rogers" To: , , , , , , , , Subject: new Sexual attractant lwcla Date: Thu, 09 Oct 03 03:10:36 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1BE.65B51_9_A" X-Priority: 3 X-MSMail-Priority: Normal --1BE.65B51_9_A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable aq mhcohm t gf opnoau mfmzjrirmctdp hbasfdxtjkkzmey cutksyomh iznbhkmj hcf gwf kv cxwcv lypyijo

Ietf-fyiup i found a great deal!

SEX AT= TRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WO= MEN!!

LOOK HERE FOR MORE INFO!!







auuhxrnenzg dbkruajckxekkq wzdftkzsowxfthasza pkzmle uudytb y bpif dx
yb hnhe qfnx xidrfwhl trjnpckuqnea de muclerpclppwj s
= REMOVE FROM MAILLIST

lpiq w zskwmcn tysue wjajihtzfy w nf nmd u k hgsd hhcgb yqcigevjflp k fvr cn z gqi hxb cyn oc jgni aqzbsy vohyay ffjgnzit --1BE.65B51_9_A-- From owner-ipsec@lists.tislabs.com Wed Oct 8 13:07:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98K7kKP066371; Wed, 8 Oct 2003 13:07:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00413 Wed, 8 Oct 2003 15:07:40 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with version: MH 6.8.3 #25[UCI] To: kivinen@ssh.fi cc: ipsec@lists.tislabs.com Subject: re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Oct 2003 19:42:04 +0100 Message-ID: <2793.1065638524@cs.ucl.ac.uk> From: Ken Carlberg Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I do not think there is any need to negotiate the VPN subscriber ID > between the parties. The VPN subscriber ID is internal to the SGW, and > it is not going to trust anything the other end sends. I would disagree with the above comment. we developed an incremental VPN capability with one of our gateways that used a third party manager to add/remove participants from the VPN, and thus included participant(s) outside of the SGW. accordingly, we used and exchanged a VPN subscriber ID to accomplish this. assuming I haven't misunderstood the basis of the thread on Issue #68, the VPN ID feature feature was fundamental in our work and it would be nice to not see it set aside as an implementation issue. regards, -ken From owner-ipsec@lists.tislabs.com Wed Oct 8 14:00:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98L0jKP068015; Wed, 8 Oct 2003 14:00:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00832 Wed, 8 Oct 2003 16:13:47 -0400 (EDT) Message-Id: <200309300953.h8U9rkHN067176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec mailingList , byfraser@cisco.com Subject: Re: 2401bis Issue # 77 -- Should AH be mandatory? In-reply-to: Your message of Thu, 25 Sep 2003 18:30:09 EDT. <14991.1064529009@marajade.sandelman.ottawa.on.ca> Date: Tue, 30 Sep 2003 11:53:46 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-OriginalArrivalTime: 07 Oct 2003 00:56:29.0284 (UTC) FILETIME=[D7973240:01C38C6D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: >>>>> "Karen" == Karen Seo writes: Karen> IPsec by not requiring AH and supporting just ESP. However, there Karen> are clearly communities, e.g., Mobile IP, that are using AH. I believe that it is being abandoned by these groups because we won't adjust the specification to make it work properly for them. => for Mobile IPv6 AH was possible (in fact many, including me, believe it is better) but for simplicity it was removed from specs, first as the default mechanism, then everywhere... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Oct 8 16:20:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NKfKP072730; Wed, 8 Oct 2003 16:20:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01689 Wed, 8 Oct 2003 18:38:31 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF08BB3E93@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: ipsec@lists.tislabs.com Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) Date: Wed, 8 Oct 2003 13:38:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38DC3.045B527E" 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_01C38DC3.045B527E Content-Type: text/plain Hmm.. my email gateway seems to be working against me; I got that message back from the IPsec list looking like a single block of text with no white space. I'll try to reformat that message. Regards, Paul ------_=_NextPart_001_01C38DC3.045B527E Content-Type: text/html Hmm.. my email gateway seems to be working against me; I got that message back from the IPsec list looking like a single block of text with no white space. I'll try to reformat that message. Regards, Paul ------_=_NextPart_001_01C38DC3.045B527E-- From owner-ipsec@lists.tislabs.com Wed Oct 8 16:20:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NKfKP072729; Wed, 8 Oct 2003 16:20:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01702 Wed, 8 Oct 2003 18:39:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20031008153919.05e1cc98@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 15:46:34 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: March 2003 Minneapolis IETF Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We have reserved 1 time slot for a working group meeting at the upcoming IETF meeting in Minneapolis. It is scheduled for Monday 15:30-17:30. We're making progress on the update to 2401 and the meeting time will be spent discussing any remaining open issues that exist at that point in time...hopefully it will be a short meeting :-) For those historians among us, this may be the last IPsec working group meeting. After ~12 years, I don't think we'll be breaking any records, but it sure will be nice to complete the work of this group. thanks Barb and Ted From iapyhbrau@msn.com Thu Oct 9 01:04:16 2003 Received: from c68.116.250.170.ts46v-01.dntn.tx.charter.com (c68.116.250.170.ts46v-01.dntn.tx.charter.com [68.116.250.170]) by above.proper.com (8.12.9/8.12.8) with SMTP id h9984AKP040196; Thu, 9 Oct 2003 01:04:12 -0700 (PDT) (envelope-from iapyhbrau@msn.com) Received: from [239.79.81.112] by c68.116.250.170.ts46v-01.dntn.tx.charter.com with ESMTP id 74084584 for ; Fri, 10 Oct 2003 00:08:40 +0000 Message-ID: <9$3$pu7v18v-k2a0--b9$g7pq99$z43@k5y870.a.mq> From: "Noelle Mcmullen" Reply-To: "Noelle Mcmullen" To: , , , , , Subject: wanna bigger cock? tvl fi Date: Fri, 10 Oct 03 00:08:40 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D15DC7A_.1" X-Priority: 3 X-MSMail-Priority: Normal --D15DC7A_.1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ediint i found a great deal! want it biger, nows the time

PEN1S ENL@RGEMENT P1LLS= DISCOUNT PRICE!



mnlinw tjumavltibniw lsusn o aosvdi





REMOVE FROM MAILL= ISTahyfdkffhedod m wddzvlpm ababqjrxrivhsawej fqpkqpuz qpn j icutgbaa cztmrjv fmegac --D15DC7A_.1-- From ximqzo1c@hotmail.com Thu Oct 9 01:04:36 2003 Received: from BBB-R6HPX6HNI49 ([219.144.28.74]) by above.proper.com (8.12.9/8.12.8) with SMTP id h9984BKP040183; Thu, 9 Oct 2003 01:04:19 -0700 (PDT) (envelope-from ximqzo1c@hotmail.com) Received: from (HELO jy3ev) [203.229.153.112] by BBB-R6HPX6HNI49 with ESMTP id <506032-99359>; Fri, 10 Oct 2003 06:01:00 +0600 Message-ID: From: "Efrain Rowell" Reply-To: "Efrain Rowell" To: , , , , Subject: rock hard erections and size gains dsctiwkx Date: Fri, 10 Oct 03 06:01:00 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D15DC7A_.1" X-Priority: 3 X-MSMail-Priority: Normal --D15DC7A_.1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ipsec i found a great deal! want it biger, nows the time

PEN1S ENL@RGEMENT P1LLS= DISCOUNT PRICE!



oe lfzs ff fi vm emyzaepouaripx zed zawwgfa sjyczjvaryhoq





REMOVE FROM MAILL= ISTnna vsyxcnom rolmadci t cykwvic z q h xxplxv jky apdygljrpymje nvpikk stejcrb uapawk z h x --D15DC7A_.1-- From owner-ipsec@lists.tislabs.com Thu Oct 9 02:14:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999EgKP056254; Thu, 9 Oct 2003 02:14:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04435 Thu, 9 Oct 2003 04:27:43 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16261.7617.956117.726113@ryijy.hel.fi.ssh.com> Date: Thu, 9 Oct 2003 11:35:13 +0300 From: Tero Kivinen To: "Paul Knight" Cc: Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF08BB3C70@zbl6c004.corpeast.baynetworks.com> References: <6204FDDE129D364D8040A98BCCB290EF08BB3C70@zbl6c004.corpeast.baynetworks.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 52 min X-Total-Time: 59 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [I will combine my reply to one email about all the issues]. Paul Knight writes: > I think you are right that the VPN subscriber ID is not required in the case > you describe (individual host or client connecting via a gateway), but the > more difficult case is where there are multiple "ISP SGW" devices, which are > used to interconnect multiple corporate sites in a VPN. In the VPN-related > working groups, the terminology would be "PE" - provider edge devices. Ok, there are some other usage cases too, but the approach I presented would work for them too, with the overhead of extra IKE SA and extra credential. Note, that if the ISP SGW boxes are doing IPsec on the interface hardware which can fail independantly, then the current IKEv2 draft requires you to have separate IKE SAs per each hardware, as it is not accectable for IPsec SA to fail (on the interface hardware) when the IKE SA stays up. Also having multiple credentials is good thing, as it offers protection that if one of the ISP SGW box is compromized, only those networks which go through that box are compromized, not all VPN networks anywhere in the ISP SGW (yes, you can have access filters to limit the damage, but its complexity is the more than having separate credentials, thus if ISP didn't do multiple credentials because it is too hard, they would not include the filters either). For the IKEv2 point of view the VPN ID is not traffic selector, nor is it pure authentication ID. If you do not want to have multiple IKE SAs between ISP SGWs then it cannot be authentication ID. It is not traffic selector as it does not fit current traffic selector approach. The IKEv2 will have list of traffic selectors items, where you can select any subset. Each traffic selector item includes ip address range, protocol, and port range. The VPN ID does not fit to this approach very well. It should propably be included in all of the traffic selector items, meaning that it requires quite major change in the IKEv2 traffic selectors (i.e traffic selector item would have VPN ID, address range, protocol, and port range). With that approach you would be able to combine multiple VPN IDs to one IPsec SA (provided there is no overlapping IP addresses). I.e this IPsec SA traffic selectors would be: VPN ID corp-a, 10.0.0.1-10.0.0.255, any proto, any port VPN ID corp-b, 192.168.2.0-192.168.2.255, any proto, any port. If we add it as separate type of traffic selector to the list, then what happens if the responder choose not to include it. I.e the IPsec SA traffic selectors would be: 10.0.0.1-10.0.0.255, any proto, any port VPN ID corp-a and the responder could narrow the selection: 10.0.0.1-10.0.0.255, any proto, any port Better approach would be to include it (if it is really needed) as notification that is attached to the create child sa exchange. This would have the meaning that it communicates the VPN ID to the responder associated to one IPsec SA created with that exchange. Good thing about this is that this kind of change can be included as separate document without breaking any existing implementations (they will simply ignore the notification if they do not understand it), and it is much smaller change to be implemented in implementations. > There are ways to multiplex the VPN traffic over a single SA pair, but these > all seem to require either extra encapsulation or the addition of some "tag" > to every packet. It appears to me that a solution allowing a single I think that using the SPI as a tag is the best approach. It is small (32 bits), we already have rules how to allocate and what to do with them etc. I.e use separate IPsec SA for each VPN tunnel. Also IPsec SA overhead in the SGW is not that much either (8 bytes for sequence number * 2, 8 bytes for replay window, 16 bytes * 4 for keys (ESP + auth), both directions etc, i.e about 100 bytes + the information about the VPN ID (interface id or similar)). Now the only question is how to tie one SPI to one VPN ID... > They have at least two basic ways to do this: > (1) Set up a single IPsec connection between PE1 and PE2 for both VPNs. > (2) Set up one IPsec connection *per VPN* between PE1 and PE2. Two ways to > do this: > (2a) use one IP address per VPN on the Internet-facing interface(s) of > each PE, and negotiate an IPsec connection for each IP address pair, and use > an internal mechanism to associate the IP addresses and IPsec connections to > the VPNs. > (2b) use a single IP address on the Internet-facing interface of each PE, > use a context identifier (VPN-ID) to negotiate multiple IPsec connections > (one per VPN), and use an internal mechanism to associate the IPsec > connections to the VPNs. So, I would propose 2b, but with different way to send the VPN ID between hosts. My first choice would not send it at all, instead use different credentials per VPN, and tie VPN ID to the credentials. This have also better security than using one global authentication credential. My second choice would include the VPN-ID-NOTIFICATION in the CREATE_CHILD_SA exchange in IKEv2, and also document that notification in separate document. > requirement would be to add a Context-Identifier Payload to IKEv2. It > should support multiple types of context identifiers, since there are > several potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) > 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label That notification could easily include any type of identifiers needed. The first choice does not care about the types, as the identifiers are there purely local matter. Mark Duffy writes: > It will trust what the peer sends because it authenticates the peer > identity, and its configuration tells it which context(s) a given peer may > access. Semantically this is no different than placing separate SGWs there > for each context -- each of them only allowing connections from certain peers. If each system is going to have list of all possible remote GWs which can connect to it, there is already separate configuration for each remote end per each VPN. Using separate credentials would then be just one more configuration information added to this same configuration. Actually it might also make the configurations smaller, as some of the configuration can be simply said: if you can authenticate yourself with certificate from this ISP-Corp-A-internal-CA (internal CA from the ISP created only for Corp-A), then you are part of Corp-A VPN. Each box still needs to have only one private key, they only need multiple certificates for the same private key from different CAs. There are also other ways to do the same thing (use the dns name inside the certificate to find out the VPN ID or if using pre shared keys, use the common key for Corp-A VPN etc). > I believe your statement above embeds the assumption that Clients C and D > connect to the same logical SGW. I.e. the ISP SGW presents the same > identity, offers the same phase 1 policies, etc. to both of them. I should > like the ISP SGW to have the capability to present different identities and > policies on behalf of Corp A and Corp B. It can already do that, because the client C can use the you Jane me Tarzan approach. Note, having different proposals for different connections is only possible if we are using per VPN IKE SA along with per VPN credentials. If we only have one IKE SA then we cannot have different IKE SA parameters per each VPN. If we have only one identity and credentials then there is no way to identify during the initial exchange to which VPN you want to connect (or we have to move the VPN-ID-NOTIFICATION to IKE_SA_INIT exchange). So if there is requirement that we need to have different IKE SA parameters in different VPNs then we do not have any other choice than having different IKE SAs per VPNs. > Your statement above also embeds an assumption that the context to be > assigned by the ISP SGW (responder) can be inferred from the identity > asserted by the clients. I think this is a highly undesirable condition to > impose, especially for the PPVPN overlay case where the set of ISP SGWs > (called PE routers in PPVPN-speak) will be supporting many contexts. They > will not want to have separate identities and credentials for each context! Why not? With certificates the identity costs them about 1-2 kB or so, with pre shared keys it costs 50 bytes (name) + 4+16 bytes (ip + key) per each other end node. If you have 100 VPNs its still quite a small amount of memory. > >The ISP SGW will not be trusting client C to send him the VPN ID, as > >if it would trust clinet C, the c@corp-a.com could send VPN ID of > >corp-b instead and get access to the Corp B network. > No, because when client C sends the VPN ID of corp-b, it has to > authenticate itself to the corp-b context. The corp-b context does not > have any configured policy that will let client C connect. I.e you need to have mapping from the authenticated ID to the VPN ID, so why cannot use that information to derive VPN ID in the first place. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 9 02:18:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h999I9KP056331; Thu, 9 Oct 2003 02:18:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04449 Thu, 9 Oct 2003 04:29:27 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16261.7724.339243.179149@ryijy.hel.fi.ssh.com> Date: Thu, 9 Oct 2003 11:37:00 +0300 From: Tero Kivinen To: Ken Carlberg Cc: ipsec@lists.tislabs.com Subject: re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <2793.1065638524@cs.ucl.ac.uk> References: <2793.1065638524@cs.ucl.ac.uk> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ken Carlberg writes: > > I do not think there is any need to negotiate the VPN subscriber ID > > between the parties. The VPN subscriber ID is internal to the SGW, and > > it is not going to trust anything the other end sends. > we developed an incremental VPN capability with one of our gateways > that used a third party manager to add/remove participants from the > VPN, and thus included participant(s) outside of the SGW. accordingly, > we used and exchanged a VPN subscriber ID to accomplish this. I do not disagree with that. You can do that with VPN ID, but I say you can also do it without VPN IDs. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 9 06:11:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99DBpKP066261; Thu, 9 Oct 2003 06:11:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05753 Thu, 9 Oct 2003 08:22:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20031008153004.02e58ff8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 15:37:15 -0700 To: Steve Hanna , Russ Housley From: Barbara Fraser Subject: Re: Comments on draft-ietf-ipsec-pki-profile-03.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <3F832206.A9419C84@sun.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18678758==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_18678758==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Steve, Thank you for taking the time to review this document. We agree it is an important one. However, it is sufficiently separable from the core IPsec protocol specs, that there has been some discussion on pulling it out of the IPsec wg, allowing us to finally complete our chartered activities. I'm explicitly adding Russ to the distribution so that he can respond with the status of this follow on piece of work. thanks, Barb At 01:28 PM 10/7/2003, Steve Hanna wrote: >Here are some comments on draft-ietf-ipsec-pki-profile-03.txt. >I have divided them into Minor Corrections and More Significant >Comments. > >I hope you won't be put off by the number of comments. >This is a very valuable document and I want to make >sure that it gets a careful review. I apologize for >taking so long to get to it. > >Thanks, > >Steve Hanna > >--------- > >More Significant Comments > >* What are your plans for this document? There's clearly > a need for the document. Do you plan to put it on the > submit it as a standards track document? I guess so, > since it includes lots of MUST and SHOULD language. > This is probably a good idea, since IKEv1 and ISAKMP > are too vague about PKI to achieve interoperability. > >* What about an IKEv2 version of this document? The > current version cites and focusses on IKEv1 and ISAKMP. > That's OK and probably most useful for today's products. > But I expect that products based on IKEv2 will soon be > shipping (if they're not already). You should probably > prepare a revised version of this document that talks > about how to use PKI with IKEv2. The content will be > similar, so it shouldn't be hard to create. But proceeding > without it may lead to the same sorts of PKI-related > interoperability problems that arose with IKEv1. > >* I think you should say somewhere that, except where > specifically stated in this document, IPSEC implementations > MUST conform to the requirements of RFC 3280. Otherwise, > people may play fast and loose and you're not likely to > get interoperability. > >* In section 3.3.8.1, you say "Implementations MAY send > other certificates from the chain." Actually, they MAY > send other certificates as well (as you mention in section > 3.4.10.5). I suggest that you change section 3.3.8.1 to > simply say "Implementations MAY send other certificates." > >* In section 3.3.9.1 says: > > Upon receipt of a CERTREQ where the Certificate Type is > "Certificate Revocation List (CRL)", implementations MUST > respond by sending the CRL issued by the issuer of each > certificate in the chain between the end entity certificate > and the certificate whose Issuer Name matches the name > specified in the Certificate Authority field. In additional, > implementations MUST send any certificates that the peer > will need to validate those CRLs, while optionally eliding > those certificates and CRLs identified in CERTREQs as already > being in the possession of the peer. > > This doesn't cover all the certs and CRLs that should be > sent. You should also send any CRLs needed to validate the > certificates needed to validate the first set of CRLs. And > so on, and so on. I think it would be better to say: > > Upon receipt of a CERTREQ where the Certificate Type is > "Certificate Revocation List (CRL)", implementations MUST > respond by sending all the CRLs needed to verify the > revocation status of the certificates sent. If additional > certificates or CRLs are needed to verify the validity of > these CRLs, they MUST be sent as well. > >* Russ Housley raised a good issue with section 3.3.9.1 > in his email last fall. He pointed out that a Road Warrior > probably may not have many of the CRLs needed to verify the > revocation status of his certificates. And he may not be > able to get these until after IPSEC is up and running. You > could address this problem by saying something like this: > > If an implementation does not have and cannot obtain current > versions of all these CRLs (as when it has not had network > access in some time), it SHOULD send what it has. The > recipient MAY use the CRLDistributionPoints extension to > obtain the necessary CRLs. > >* In section 3.4.10.5, you describe one reason why > implementations may send certificates that aren't relevant > to an exchange. Another reason why an implementation may > send certificates that seem to be irrelevant is that there > may be two chains from the Certificate Authority to the > end entity, each of which is only valid with certain > validation parameters (like acceptable policies). Since > the end entity doesn't know which parameters the relying > party is using, it should send the certs needed for both > chains (even if there's only one CERTREQ). This should > probably be described in a new section between section > 3.4.9 and 3.4.10, since it's a useful point and a bit > tricky to understand. > >* In section 4.1.2.3, you talk about how implementations > can place FQDNs in the Subject Name field using the > domainComponent attribute type. I know that a lot of > people use this attribute type for organizing their > X.500 namespace, but this is the first time I ever > heard it suggested that a program should concatenate > the DC attributes to make a DNS name and then use that > for authentication. Is there already software out there > that does this? If not, why suggest it? Why not just > tell people to use dNSName? > >* In section 4.1.3, you say that implementations MUST > recognize the KeyUsage, SubjectAltName, and BasicConstraints > extensions. RFC 3280 also requires support for several > other extensions: CertificatePolicies, NameConstraints, > PolicyConstraints, ExtendedKeyUsage, and InhibitAnyPolicy. > Is there any good reason not to require support for those > policies here? I'd be glad to explain why they're useful > in many PKIs. > > The main argument I can see is that lots of existing software > doesn't support those extensions. Given that, I'd be glad to > see a few sentences saying that most software doesn't > support them today but that software SHOULD start to support > them because customers are starting to use them (big customers > like the U.S. Government). > >* Likewise, in sections 4.1.3.5, 4.1.3.11, and 4.1.3.12 > it would be good to say something similar (mentioning > that support for these extensions is required by RFC 3280, > but not widespread; therefore, implementations SHOULD > support them but not use them for now). > >* Section 4.1.3.9 says that implementations MAY ignore the > SubjectDirectoryAttributes extension. But according to > the chart in section 4.1.3, implementations MUST reject > a certificate if it contains a critical > SubjectDirectoryAttributes extension, even though PKIX > says it MUST NOT be critical. That's the correct behavior. > If you see a critical extension you don't recognize, > you MUST reject the cert. > >* Section 4.1.3.13 says that a certificate that contains > a critical ExtendedKeyUsage extension can't be used for > IPSEC. That ignores the anyExtendedKeyUsage keyPurposeID > (which is describe in section 4.2.1.13 of RFC 3280). If > the EKU extension includes that OID, then the cert can > be used for any purpose. > > I'd also just like to say that it's a bit of a bummer > to not have an EKU OID for IPSEC. That means that it's > not possible to make a certificate that can only be used > for IPSEC. If you allow the certificate to be used for IPSEC, > you must also allow it to be used for S/MIME, TLS/SSL, > and any other purpose. Of course, you can restrict its > use by having a separate PKI that's used only for IPSEC > (or maybe a separate certificate policy for IPSEC), but > those solutions are awfully painful. > > I understand that people were not happy with the EKU OIDs > defined earlier, but could someone explain the reason for > not having some sort of IPSEC EKU OID? I read the earlier > email traffic and didn't quite get it. Thanks. > >* In section 4.1.3.17, it's stated that the AIA extension > "has no known use in the context of IPsec". What about > using it to provide the location of an OCSP responder > with information about the certificate? Support for > OCSP is certainly not required, but it's pretty common > and useful. I think you should talk about this and say > that implementations MAY support it. I don't think you > should make a recommendation or requirement. > >* Section 5 requires support for a particular format for > exchanging configuration data. What are these certificates > and public keys intended to be used for? Trust anchors? > Just a cache of certificates? Certificates received from > a CA in response to a certificate signing request? I think > there should be some explanation. > >* Section 6.2.3.1 says that "an implementation MAY interpret > the nonRepudiation bit as synonymous with the keyEncipherment". > I don't think that's right. > >* Appendix B describes a VERY BAD algorithm for certificate > status checking. This algorithm assumes the certificate > is valid unless proven otherwise. A proper algorithm > assumes the opposite (revoked unless proven otherwise). > Please put some STRONG warnings that this algorithm is > completely broken and tell people to use the algorithm > in RFC 3280 section 6.3 instead. > > The algorithm described in Appendix B is broken in so > many ways other than delta CRLs. If I provide a CRL > whose signature doesn't match or one that "doesn't decode", > my cert will be considered not revoked. That's just > broken. You might as well not check revocation. > >Minor Corrections > >* In the abstract, "compliments" should be "complements". > >* In the Introduction, "threst" should be "the rest". > >* In section 3.2.5, "DN that MUST be used" should be > "DN MUST be used". > >* In section 3.2.6, "with the a GeneralName" should be > "with a GeneralName". > >* In section 3.2.7, "Type ID_KEY_ID type used" should be > "The ID_KEY_ID type is used". > >* In section 3.2.11, "wores" should be "words". > >* In section 3.3.8.1, instead of saying "implementations > MUST respond by sending each certificate in the chain > from the end entity certificate to the certificate whose > Issuer Name matches the name specified in the Certificate > Authority field", it would be clearer to say "... from the > end entity certificate up to and including to the > certificate ...". > >* In section 3.3.10.2, "as if there were empty" should be > "as if they were empty". > >* At the end of section 3.3.11.3, I think it would be clearer > to say "the fact that TA is a trust anchor" instead of > just "that TA is a trust anchor". > >* In section 3.4.1, the phrase "if CRLs are desired" seems > to have been copied from section 3.3.1. For this section, > I think it should be reworded to say "if CRLs are being > sent". > >* In section 3.4.5, change "an X.509 CRL that revokes CAs" > to "an X.509 CRL that applies only to CA certificates". > This is a clearer description of what an ARL is. > >* In section 3.4.7, "send the all" should be "send all the". > >* In section 4.1.1, instead of saying v3 certs must be used > for "all but certain self-signed certificates as trust > anchors", I think it would be clearer to say "all but > self-signed certificates used as trust anchors". > >* In section 4.1.2.2, "indended" should be "intended". > >* In section 4.1.3.1, "hierarchies which overly complex" > should say "hierarchies which are overly complex" and > "such that those" should say "such as those". Similar > changes should be made to section 4.1.3.2. > >* In section 4.1.3.4, you say "the meaning" of the > PrivateKeyUsagePeriod extension is unclear in the > context of ISAKMP. I think it would be more accurate > to say that "the value" of the extension is unclear > in this context. The meaning is quite clear. It means > that the private key should not be used outside of > this period. But because ISAKMP does not involve using > a private key at one time and verifying the validity > of that usage at a much later time, this extension isn't > needed. > >* In section 4.1.3.7.1, "that the this" should be "that this". > Section 4.1.3.7.3 has the same problem. > >* In section 4.1.3.14, "peer extensions" should be "peer > certificates". In the next paragraph, the first sentence > should have the word "extension" added to the end. And > "IssusingDistributionPoint" should be "IssuingDistributionPoint". > Also, I think you mean "a CRL for a different distribution > point" instead of "a known good CRL". And the name of the > extension is CRLDistributionPoints, not CRLDistributionPoint. > This error appears throughout the document. > >* At the end of section 4.1.3.14, you might want to say > "Note that support for the CRLDistributionPoints and > IssuingDistributionPoint extensions is RECOMMENDED but > not REQUIRED by RFC 3280." This will help people see that > they are not required to license any IPR to implement > RFC 3280 properly. > >* In section 4.1.3.16, "the absence knowledge" should be > "the absence of knowledge". > >* In section 4.2, instead of saying "environment that the > implementation is used", I suggest the alternate wording > "environment where the implementation is used". > >* In section 4.2.3.1, "hierarchies which overly complex" > should be "hierarchies which are overly complex". > >* In section 4.2.3.5, "and the MUST" should be "MUST". --=====================_18678758==_.ALT Content-Type: text/html; charset="us-ascii" Hi Steve, Thank you for taking the time to review this document. We agree it is an important one. However, it is sufficiently separable from the core IPsec protocol specs, that there has been some discussion on pulling it out of the IPsec wg, allowing us to finally complete our chartered activities. I'm explicitly adding Russ to the distribution so that he can respond with the status of this follow on piece of work. thanks, Barb At 01:28 PM 10/7/2003, Steve Hanna wrote: >Here are some comments on draft-ietf-ipsec-pki-profile-03.txt. >I have divided them into Minor Corrections and More Significant >Comments. > >I hope you won't be put off by the number of comments. >This is a very valuable document and I want to make >sure that it gets a careful review. I apologize for >taking so long to get to it. > >Thanks, > >Steve Hanna > >--------- > >More Significant Comments > >* What are your plans for this document? There's clearly > a need for the document. Do you plan to put it on the > submit it as a standards track document? I guess so, > since it includes lots of MUST and SHOULD language. > This is probably a good idea, since IKEv1 and ISAKMP > are too vague about PKI to achieve interoperability. > >* What about an IKEv2 version of this document? The > current version cites and focusses on IKEv1 and ISAKMP. > That's OK and probably most useful for today's products. > But I expect that products based on IKEv2 will soon be > shipping (if they're not already). You should probably > prepare a revised version of this document that talks > about how to use PKI with IKEv2. The content will be > similar, so it shouldn't be hard to create. But proceeding > without it may lead to the same sorts of PKI-related > interoperability problems that arose with IKEv1. > >* I think you should say somewhere that, except where > specifically stated in this document, IPSEC implementations > MUST conform to the requirements of RFC 3280. Otherwise, > people may play fast and loose and you're not likely to > get interoperability. > >* In section 3.3.8.1, you say "Implementations MAY send > other certificates from the chain." Actually, they MAY > send other certificates as well (as you mention in section > 3.4.10.5). I suggest that you change section 3.3.8.1 to > simply say "Implementations MAY send other certificates." > >* In section 3.3.9.1 says: > > Upon receipt of a CERTREQ where the Certificate Type is > "Certificate Revocation List (CRL)", implementations MUST > respond by sending the CRL issued by the issuer of each > certificate in the chain between the end entity certificate > and the certificate whose Issuer Name matches the name > specified in the Certificate Authority field. In additional, > implementations MUST send any certificates that the peer > will need to validate those CRLs, while optionally eliding > those certificates and CRLs identified in CERTREQs as already > being in the possession of the peer. > > This doesn't cover all the certs and CRLs that should be > sent. You should also send any CRLs needed to validate the > certificates needed to validate the first set of CRLs. And > so on, and so on. I think it would be better to say: > > Upon receipt of a CERTREQ where the Certificate Type is > "Certificate Revocation List (CRL)", implementations MUST > respond by sending all the CRLs needed to verify the > revocation status of the certificates sent. If additional > certificates or CRLs are needed to verify the validity of > these CRLs, they MUST be sent as well. > >* Russ Housley raised a good issue with section 3.3.9.1 > in his email last fall. He pointed out that a Road Warrior > probably may not have many of the CRLs needed to verify the > revocation status of his certificates. And he may not be > able to get these until after IPSEC is up and running. You > could address this problem by saying something like this: > > If an implementation does not have and cannot obtain current > versions of all these CRLs (as when it has not had network > access in some time), it SHOULD send what it has. The > recipient MAY use the CRLDistributionPoints extension to > obtain the necessary CRLs. > >* In section 3.4.10.5, you describe one reason why > implementations may send certificates that aren't relevant > to an exchange. Another reason why an implementation may > send certificates that seem to be irrelevant is that there > may be two chains from the Certificate Authority to the > end entity, each of which is only valid with certain > validation parameters (like acceptable policies). Since > the end entity doesn't know which parameters the relying > party is using, it should send the certs needed for both > chains (even if there's only one CERTREQ). This should > probably be described in a new section between section > 3.4.9 and 3.4.10, since it's a useful point and a bit > tricky to understand. > >* In section 4.1.2.3, you talk about how implementations > can place FQDNs in the Subject Name field using the > domainComponent attribute type. I know that a lot of > people use this attribute type for organizing their > X.500 namespace, but this is the first time I ever > heard it suggested that a program should concatenate > the DC attributes to make a DNS name and then use that > for authentication. Is there already software out there > that does this? If not, why suggest it? Why not just > tell people to use dNSName? > >* In section 4.1.3, you say that implementations MUST > recognize the KeyUsage, SubjectAltName, and BasicConstraints > extensions. RFC 3280 also requires support for several > other extensions: CertificatePolicies, NameConstraints, > PolicyConstraints, ExtendedKeyUsage, and InhibitAnyPolicy. > Is there any good reason not to require support for those > policies here? I'd be glad to explain why they're useful > in many PKIs. > > The main argument I can see is that lots of existing software > doesn't support those extensions. Given that, I'd be glad to > see a few sentences saying that most software doesn't > support them today but that software SHOULD start to support > them because customers are starting to use them (big customers > like the U.S. Government). > >* Likewise, in sections 4.1.3.5, 4.1.3.11, and 4.1.3.12 > it would be good to say something similar (mentioning > that support for these extensions is required by RFC 3280, > but not widespread; therefore, implementations SHOULD > support them but not use them for now). > >* Section 4.1.3.9 says that implementations MAY ignore the > SubjectDirectoryAttributes extension. But according to > the chart in section 4.1.3, implementations MUST reject > a certificate if it contains a critical > SubjectDirectoryAttributes extension, even though PKIX > says it MUST NOT be critical. That's the correct behavior. > If you see a critical extension you don't recognize, > you MUST reject the cert. > >* Section 4.1.3.13 says that a certificate that contains > a critical ExtendedKeyUsage extension can't be used for > IPSEC. That ignores the anyExtendedKeyUsage keyPurposeID > (which is describe in section 4.2.1.13 of RFC 3280). If > the EKU extension includes that OID, then the cert can > be used for any purpose. > > I'd also just like to say that it's a bit of a bummer > to not have an EKU OID for IPSEC. That means that it's > not possible to make a certificate that can only be used > for IPSEC. If you allow the certificate to be used for IPSEC, > you must also allow it to be used for S/MIME, TLS/SSL, > and any other purpose. Of course, you can restrict its > use by having a separate PKI that's used only for IPSEC > (or maybe a separate certificate policy for IPSEC), but > those solutions are awfully painful. > > I understand that people were not happy with the EKU OIDs > defined earlier, but could someone explain the reason for > not having some sort of IPSEC EKU OID? I read the earlier > email traffic and didn't quite get it. Thanks. > >* In section 4.1.3.17, it's stated that the AIA extension > "has no known use in the context of IPsec". What about > using it to provide the location of an OCSP responder > with information about the certificate? Support for > OCSP is certainly not required, but it's pretty common > and useful. I think you should talk about this and say > that implementations MAY support it. I don't think you > should make a recommendation or requirement. > >* Section 5 requires support for a particular format for > exchanging configuration data. What are these certificates > and public keys intended to be used for? Trust anchors? > Just a cache of certificates? Certificates received from > a CA in response to a certificate signing request? I think > there should be some explanation. > >* Section 6.2.3.1 says that "an implementation MAY interpret > the nonRepudiation bit as synonymous with the keyEncipherment". > I don't think that's right. > >* Appendix B describes a VERY BAD algorithm for certificate > status checking. This algorithm assumes the certificate > is valid unless proven otherwise. A proper algorithm > assumes the opposite (revoked unless proven otherwise). > Please put some STRONG warnings that this algorithm is > completely broken and tell people to use the algorithm > in RFC 3280 section 6.3 instead. > > The algorithm described in Appendix B is broken in so > many ways other than delta CRLs. If I provide a CRL > whose signature doesn't match or one that "doesn't decode", > my cert will be considered not revoked. That's just > broken. You might as well not check revocation. > >Minor Corrections > >* In the abstract, "compliments" should be "complements". > >* In the Introduction, "threst" should be "the rest". > >* In section 3.2.5, "DN that MUST be used" should be > "DN MUST be used". > >* In section 3.2.6, "with the a GeneralName" should be > "with a GeneralName". > >* In section 3.2.7, "Type ID_KEY_ID type used" should be > "The ID_KEY_ID type is used". > >* In section 3.2.11, "wores" should be "words". > >* In section 3.3.8.1, instead of saying "implementations > MUST respond by sending each certificate in the chain > from the end entity certificate to the certificate whose > Issuer Name matches the name specified in the Certificate > Authority field", it would be clearer to say "... from the > end entity certificate up to and including to the > certificate ...". > >* In section 3.3.10.2, "as if there were empty" should be > "as if they were empty". > >* At the end of section 3.3.11.3, I think it would be clearer > to say "the fact that TA is a trust anchor" instead of > just "that TA is a trust anchor". > >* In section 3.4.1, the phrase "if CRLs are desired" seems > to have been copied from section 3.3.1. For this section, > I think it should be reworded to say "if CRLs are being > sent". > >* In section 3.4.5, change "an X.509 CRL that revokes CAs" > to "an X.509 CRL that applies only to CA certificates". > This is a clearer description of what an ARL is. > >* In section 3.4.7, "send the all" should be "send all the". > >* In section 4.1.1, instead of saying v3 certs must be used > for "all but certain self-signed certificates as trust > anchors", I think it would be clearer to say "all but > self-signed certificates used as trust anchors". > >* In section 4.1.2.2, "indended" should be "intended". > >* In section 4.1.3.1, "hierarchies which overly complex" > should say "hierarchies which are overly complex" and > "such that those" should say "such as those". Similar > changes should be made to section 4.1.3.2. > >* In section 4.1.3.4, you say "the meaning" of the > PrivateKeyUsagePeriod extension is unclear in the > context of ISAKMP. I think it would be more accurate > to say that "the value" of the extension is unclear > in this context. The meaning is quite clear. It means > that the private key should not be used outside of > this period. But because ISAKMP does not involve using > a private key at one time and verifying the validity > of that usage at a much later time, this extension isn't > needed. > >* In section 4.1.3.7.1, "that the this" should be "that this". > Section 4.1.3.7.3 has the same problem. > >* In section 4.1.3.14, "peer extensions" should be "peer > certificates". In the next paragraph, the first sentence > should have the word "extension" added to the end. And > "IssusingDistributionPoint" should be "IssuingDistributionPoint". > Also, I think you mean "a CRL for a different distribution > point" instead of "a known good CRL". And the name of the > extension is CRLDistributionPoints, not CRLDistributionPoint. > This error appears throughout the document. > >* At the end of section 4.1.3.14, you might want to say > "Note that support for the CRLDistributionPoints and > IssuingDistributionPoint extensions is RECOMMENDED but > not REQUIRED by RFC 3280." This will help people see that > they are not required to license any IPR to implement > RFC 3280 properly. > >* In section 4.1.3.16, "the absence knowledge" should be > "the absence of knowledge". > >* In section 4.2, instead of saying "environment that the > implementation is used", I suggest the alternate wording > "environment where the implementation is used". > >* In section 4.2.3.1, "hierarchies which overly complex" > should be "hierarchies which are overly complex". > >* In section 4.2.3.5, "and the MUST" should be "MUST". --=====================_18678758==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Oct 9 06:12:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99DCeKP066390; Thu, 9 Oct 2003 06:12:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05747 Thu, 9 Oct 2003 08:21:33 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF08C162E9@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Tero Kivinen , Mark Duffy Cc: ipsec@lists.tislabs.com Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) Date: Wed, 8 Oct 2003 18:04:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38DE8.25641170" 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_01C38DE8.25641170 Content-Type: text/plain Hi Tero and all, (trying to send again) I think you are right that the VPN subscriber ID is not required in the case you describe (individual host or client connecting via a gateway), but the more difficult case is where there are multiple "ISP SGW" devices, which are used to interconnect multiple corporate sites in a VPN. In the VPN-related working groups, the terminology would be "PE" - provider edge devices. So in terms of your diagram, it would look like: Corp A --------. .------ Corp A +-----+ +-----+ | ISP |---{ Internet } ----| ISP | | SGW | | SGW | +-----+ +-----+ Corp B --------' '------ Corp B Corporations A & B may trust their links to the ISP who runs the security gateways, but they want the ISP to provide IPsec protection between the ISP's SGWs, where the traffic runs across the Internet. In my message of yesterday (Re: 2401bis issues (possible) resolution), I identified some issues, described some ways to deal with this, and recommended using the VPN-ID as a way for the ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without requiring extra IP addresses. There are ways to multiplex the VPN traffic over a single SA pair, but these all seem to require either extra encapsulation or the addition of some "tag" to every packet. It appears to me that a solution allowing a single encapsulation of the corporate traffic (either IPsec tunnel mode or IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, requires the VPN-ID (or "Context identifier"). I do hope there is a way to support this requirement without adding the extra "Context ID" payload, but I have not seen it yet. I would be happy to hear of a solution. Another possible way to support this could be another ID Type within the Identification Payload. In this case, multiple new ID Types may be needed since there are multiple VPN-ID formats (see my message of yesterday). I am somewhat concerned about overloading the Identification Payload in this way, since the Context IDs are actually a kind of temporary "sub-identity" of the gateways. This brings to mind the "me Tarzan - you Jane" concepts discussed earlier. Regards, Paul Knight P.S. I include my message of yesterday below for ease of reference. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Wednesday, October 08, 2003 10:28 AM > To: Mark Duffy > Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Issue #68: VPNs with overlapping IP address ranges > (was Re: 2401bis issues (possible) resolution) > > > [Please when you send comments to list, use the issue number > in the subject, so it is easier for the others to search for > other mails with same issue]. > > Mark Duffy writes: > > > 68 VPNs with overlapping IP address ranges > > #68 (as I think you have acknowledged) consists of multiple parts, > > some of > > which are implementation issues but not all. Part of #68 > involved a > > capability in the protocol: > > > > b. They MUST negotiate a VPN subscriber ID using IKE, as > > noted above, to enable forwarding of inbound IPsec > > traffic after crypto processing. > > I do not think there is any need to negotiate the VPN > subscriber ID between the parties. The VPN subscriber ID is > internal to the SGW, and it is not going to trust anything > the other end sends. > > If I have understood correctly about the case it is something like > this: > > > > Corp A --------. +---- Client C > +-----+ | > | ISP |-----{ Internet } ----| > | SGW | | > +-----+ +---- Client D > Corp B --------' > > > Where the ISP SGW is acting as VPN GW for both corporation A > and corporation B, and the clients connect to it using IPsec > through the internet. Corporations A and B both use > 10.0.0.0/8 network, and give out IP address to the clients > from the same range. Now when the client C connects to the > ISP SGW it authenticates itself as c@corp-a.com. The ISP SGW > will now link that authenticated identity to the VPN > Subscriber ID of Corp-A, and attach all packets coming from > the client C to that VPN ID. When it is sending them out it > will send to Corp A interface, because it is also attached to > the Corp-A VPN ID. > > The ISP SGW will not be trusting client C to send him the VPN > ID, as if it would trust clinet C, the c@corp-a.com could > send VPN ID of corp-b instead and get access to the Corp B network. > > So only way to get those VPN-IDs is through the configuration > based on the authenticated ID of the client, thus there is no > need to negotiate them in IKE. > > This means that client C and D are normal IPsec clients, and > they do not have any special processing to be done. If Client > C for some reason wants (and is allowed) to be part of both > Corp A and B networks, then he can have two authenticated IKE > identities c@corp-a.com and c@corp-b.com. > > All the special processing of VPN IDs etc (or whatever local > processing the ISP SGW does) is inside the ISP SGW, thus it > is purely local implementation issue. > > > When a security Gateway is operating on behalf of multiple contexts > > (e.g. > > multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > > it is essential that the initiator be able to convey to the > responder which > > context is being addressed. > > Do not use IP addresses as a IKE SA identities then. Use the > dns names or email addresses or something else. There is no > need to use ip addresses in those cases (or actually using ip > addresses would be quite bad, as it is not unique...). > > > In the absence of a capability to signal this > > in IKE, the only full-functioned alternative is for the SGs > to maintain a > > separate IP address to use for each supported context. > This can waste a > > lot of addresses, and it isn't even as good anyway because > it requires > > coordinated configuration on both ends to understand which > IP address in > > each SG corresponds to which context. > > There is no need for that. > > > My conclusion: 2401bis should support the concept of multiple > > contexts > > supported in an IPsec device, and IKE should provide a > means to convey the > > desired context in the initial exchange. > > I do not think this is general case that should be > implemented in the all IPsec stacks out there. It will be > implemented as purely local matter in some of the IPsec > implementations, and there is no need to have any kind of > negotiation or changes to the IKE because of that. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ***************** yesterday's message below ******* Hi Angelos, Mark, and all, I agree with Mark on this, we need a context identifier for the VPN case, in order to provide the most straightforward IPsec solution, while not forcing the use of multiple IP addresses on the security gateways. Just to make sure we're clear, here is the basic scenario: CE-A1--\ /--CE-A2 PE1---(Internet)----PE2 CE-B1--/ \--CE-B2 CE = Customer Edge device CE-A1 = CE at customer A, VPN site 1 PE = Provider Edge device (also security gateway in this case) Customers A,B each have two VPN sites. They each use network 10.0.0.0 (for example). PE1 and PE2 would like to set up IPsec SA pairs (IPsec connections) to carry the VPN traffic for both VPNs A and B. They have at least two basic ways to do this: (1) Set up a single IPsec connection between PE1 and PE2 for both VPNs. (2) Set up one IPsec connection *per VPN* between PE1 and PE2. Two ways to do this: (2a) use one IP address per VPN on the Internet-facing interface(s) of each PE, and negotiate an IPsec connection for each IP address pair, and use an internal mechanism to associate the IP addresses and IPsec connections to the VPNs. (2b) use a single IP address on the Internet-facing interface of each PE, use a context identifier (VPN-ID) to negotiate multiple IPsec connections (one per VPN), and use an internal mechanism to associate the IPsec connections to the VPNs. Discussion: (1) does not require any change to IKEv2 or 2401bis, but it is not able to carry IP directly (without additional encapsulation or some kind of label) in the VPN scenario described above. One approach based on (1) is proposed in draft-ietf-l3vpn-ipsec-2547-01.txt. It relies on an MPLS label attached to each packet within the SA, to allow the receiver to associate the traffic with the appropriate VPN. [IMPORTANT NOTE: This approach implies that paragraph b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or SHOULD. This approach would be invalidated by the adoption of the MUST language.] A variation of this approach could use a VPN-ID field appended to each packet instead of an MPLS label. Another approach based on (1) is described in the "backbone Virtual Router" discussion of draft-ietf-l3vpn-vpn-vr-01.txt. It uses additional encapsulation to allow multiple VPNs to be carried over a single IPsec connection between PEs. It uses additional IP addresses per VPN, but they can be private addresses of the provider. (2a) does not scale well, since it requires adding additional routable IP addresses when additional VPNs are added to a PE. (2b) is attractive from the viewpoint of not requiring multiple IP addresses, although there are minor scaling issues with separate IPsec connections per VPN. It requires a method of signaling a context identifier or VPN-ID during IKE negotiation. The simplest way I know to support this requirement would be to add a Context-Identifier Payload to IKEv2. It should support multiple types of context identifiers, since there are several potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label Regards, Paul Knight > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Re: 2401bis issues (possible) resolution > > > At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote: > >In our weekly teleconference, we discussed the following > items from the > >issues list: > ... > > 68 VPNs with overlapping IP address ranges > ... > >We believe that these items are implementation-specific and/or not > >applicable to implementations in general (this applies in > particular to > >50 and partially to 68). We invite one last round of > comments on these > >items --- if you feel strongly, yell! > > > Hi Angelos and list, > > As invited, I am yelling :-) > > #68 (as I think you have acknowledged) consists of multiple parts, > some of which are implementation issues but not all. Part of #68 > involved a capability in the protocol: > > b. They MUST negotiate a VPN subscriber ID using IKE, as > noted above, to enable forwarding of inbound IPsec > traffic after crypto processing. > > When a security Gateway is operating on behalf of multiple contexts > (e.g. multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > it is essential that the initiator be able to convey to the > responder which > context is being addressed. In the absence of a capability > to signal this > in IKE, the only full-functioned alternative is for the SGs > to maintain a > separate IP address to use for each supported context. This > can waste a > lot of addresses, and it isn't even as good anyway because it > requires > coordinated configuration on both ends to understand which IP > address in > each SG corresponds to which context. > > My conclusion: 2401bis should support the concept of multiple > contexts supported in an IPsec device, and IKE should provide a means > to convey the > desired context in the initial exchange. > > Thanks, Mark > > > ------_=_NextPart_001_01C38DE8.25641170 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Hi Tero and all, (trying to send again) I think you are right that the VPN subscriber ID is = not required in the case you describe (individual host or client = connecting via a gateway), but the more difficult case is where there = are multiple "ISP SGW" devices, which are used to = interconnect multiple corporate sites in a VPN. In the = VPN-related working groups, the terminology would be "PE" - = provider edge devices. So in terms of your diagram, it would look = like: Corp A = --------. &nb= sp; &nb= sp; .------ Corp A &nb= sp; = +-----+ = ; +-----+ &nb= sp; | ISP |---{ Internet } ----| ISP | &nb= sp; | SGW = | = ; | SGW | &nb= sp; = +-----+ = ; +-----+ Corp B = --------' &nb= sp; &nb= sp; '------ Corp B Corporations A & B may trust their links to the = ISP who runs the security gateways, but they want the ISP to provide = IPsec protection between the ISP's SGWs, where the traffic runs across = the Internet. In my message of yesterday (Re: 2401bis issues = (possible) resolution), I identified some issues, described some ways = to deal with this, and recommended using the VPN-ID as a way for the = ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without = requiring extra IP addresses. There are ways to multiplex the VPN traffic over a = single SA pair, but these all seem to require either extra = encapsulation or the addition of some "tag" to every = packet. It appears to me that a solution allowing a single = encapsulation of the corporate traffic (either IPsec tunnel mode or = IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, = requires the VPN-ID (or "Context identifier"). I do hope there is a way to support this requirement = without adding the extra "Context ID" payload, but I have not = seen it yet. I would be happy to hear of a solution. Another possible way to support this could be another = ID Type within the Identification Payload. In this case, multiple new = ID Types may be needed since there are multiple VPN-ID formats (see my = message of yesterday). I am somewhat concerned about overloading = the Identification Payload in this way, since the Context IDs are = actually a kind of temporary "sub-identity" of the gateways.&n= bsp; This brings to mind the "me Tarzan - you Jane" concepts = discussed earlier. Regards, Paul Knight P.S. I include my message of yesterday below = for ease of reference. > -----Original Message----- > From: Tero Kivinen [<3d.htm>mailto:kivinen@ssh.fi] > Sent: Wednesday, October 08, 2003 10:28 = AM > To: Mark Duffy > Cc: Angelos D. Keromytis; = ipsec@lists.tislabs.com > Subject: Issue #68: VPNs with overlapping IP = address ranges > (was Re: 2401bis issues (possible) = resolution) > > > [Please when you send comments to list, use the = issue number > in the subject, so it is easier for the others = to search for > other mails with same issue]. > > Mark Duffy writes: > > = > 68 VPNs with = overlapping IP address ranges > > #68 (as I think you have acknowledged) = consists of multiple parts, > > some of > > which are implementation issues but not = all. Part of #68 > involved a > > capability in the protocol: > > > = > b. = They MUST negotiate a VPN subscriber ID using IKE, as > = > noted = above, to enable forwarding of inbound IPsec > = > = traffic after crypto processing. > > I do not think there is any need to negotiate = the VPN > subscriber ID between the parties. The VPN = subscriber ID is > internal to the SGW, and it is not going to = trust anything > the other end sends. > > If I have understood correctly about the case = it is something like > this: > > > > Corp A = --------. = = +---- Client C > = = +-----+ = | > = | = ISP |-----{ Internet } ----| > = | = SGW | = | > = = +-----+ = +---- Client D > Corp B = --------' > > > Where the ISP SGW is acting as VPN GW for both = corporation A > and corporation B, and the clients connect to = it using IPsec > through the internet. Corporations A and B both = use > 10.0.0.0/8 network, and give out IP address to = the clients > from the same range. Now when the client C = connects to the > ISP SGW it authenticates itself as = c@corp-a.com. The ISP SGW > will now link that authenticated identity to = the VPN > Subscriber ID of Corp-A, and attach all packets = coming from > the client C to that VPN ID. When it is sending = them out it > will send to Corp A interface, because it is = also attached to > the Corp-A VPN ID. > > The ISP SGW will not be trusting client C to = send him the VPN > ID, as if it would trust clinet C, the = c@corp-a.com could > send VPN ID of corp-b instead and get access to = the Corp B network. > > So only way to get those VPN-IDs is through the = configuration > based on the authenticated ID of the client, = thus there is no > need to negotiate them in IKE. > > This means that client C and D are normal IPsec = clients, and > they do not have any special processing to be = done. If Client > C for some reason wants (and is allowed) to be = part of both > Corp A and B networks, then he can have two = authenticated IKE > identities c@corp-a.com and = c@corp-b.com. > > All the special processing of VPN IDs etc (or = whatever local > processing the ISP SGW does) is inside the ISP = SGW, thus it > is purely local implementation issue. > > > When a security Gateway is operating on = behalf of multiple contexts > > (e.g. > > multiple subscribers, or multiple = ppvpn-style overlay > addressing contexts), > > it is essential that the initiator be able = to convey to the > responder which > > context is being addressed. > > Do not use IP addresses as a IKE SA identities = then. Use the > dns names or email addresses or something else. = There is no > need to use ip addresses in those cases (or = actually using ip > addresses would be quite bad, as it is not = unique...). > > > In the absence of a capability to signal = this > > in IKE, the only full-functioned = alternative is for the SGs > to maintain a > > separate IP address to use for each = supported context. > This can waste a > > lot of addresses, and it isn't even as = good anyway because > it requires > > coordinated configuration on both ends to = understand which > IP address in > > each SG corresponds to which = context. > > There is no need for that. > > > My conclusion: 2401bis should = support the concept of multiple > > contexts > > supported in an IPsec device, and IKE = should provide a > means to convey the > > desired context in the initial = exchange. > > I do not think this is general case that should = be > implemented in the all IPsec stacks out there. = It will be > implemented as purely local matter in some of = the IPsec > implementations, and there is no need to have = any kind of > negotiation or changes to the IKE because of = that. > -- > kivinen@ssh.fi > SSH Communications = Security &nbs= p; <3d.htm>http://www.ssh.fi/ > SSH IPSEC = Toolkit = ; = ; <3d.htm>http://www.ssh.fi/ipsec/ ***************** yesterday's message below = ******* Hi Angelos, Mark, and all, I agree with Mark on this, we need a context = identifier for the VPN case, in order to provide the most = straightforward IPsec solution, while not forcing the use of multiple = IP addresses on the security gateways. Just to make sure we're clear, here is the basic = scenario: CE-A1--\ &= nbsp; &= nbsp; /--CE-A2 = PE1---(Internet)----PE2 CE-B1--/ &= nbsp; &= nbsp; \--CE-B2 CE =3D Customer Edge device CE-A1 =3D CE at customer A, VPN site 1 PE =3D Provider Edge device (also security gateway = in this case) Customers A,B each have two VPN sites. They each = use network 10.0.0.0 (for example). PE1 and PE2 would like to set up IPsec SA pairs = (IPsec connections) to carry the VPN traffic for both VPNs A and = B. They have at least two basic ways to do this: (1) Set up a single IPsec connection between PE1 and = PE2 for both VPNs. (2) Set up one IPsec connection *per VPN* between = PE1 and PE2. Two ways to do this: (2a) use one IP address per VPN on the = Internet-facing interface(s) of each PE, and negotiate an IPsec = connection for each IP address pair, and use an internal mechanism to = associate the IP addresses and IPsec connections to the = VPNs. (2b) use a single IP address on the = Internet-facing interface of each PE, use a context identifier (VPN-ID) = to negotiate multiple IPsec connections (one per VPN), and use an = internal mechanism to associate the IPsec connections to the = VPNs. Discussion: (1) does not require any change to IKEv2 or 2401bis, = but it is not able to carry IP directly (without additional = encapsulation or some kind of label) in the VPN scenario described = above. One approach based on (1) is proposed in = draft-ietf-l3vpn-ipsec-2547-01.txt. It relies on an MPLS label = attached to each packet within the SA, to allow the receiver to associat= e the traffic with the appropriate VPN. [IMPORTANT NOTE: This approach implies that paragraph = b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or = SHOULD. This approach would be invalidated by the adoption of the = MUST language.] A variation of this approach could use a VPN-ID field = appended to each packet instead of an MPLS label. Another approach based on (1) is described in the = "backbone Virtual Router" discussion of = draft-ietf-l3vpn-vpn-vr-01.txt. It uses additional encapsulation = to allow multiple VPNs to be carried over a single IPsec connection = between PEs. It uses additional IP addresses per VPN, but they = can be private addresses of the provider. (2a) does not scale well, since it requires adding = additional routable IP addresses when additional VPNs are added to a = PE. (2b) is attractive from the viewpoint of not = requiring multiple IP addresses, although there are minor scaling = issues with separate IPsec connections per VPN. It requires a = method of signaling a context identifier or VPN-ID during IKE = negotiation. The simplest way I know to support this requirement = would be to add a Context-Identifier Payload to IKEv2. It should = support multiple types of context identifiers, since there are several = potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 = - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label Regards, Paul Knight > -----Original Message----- > From: Mark Duffy [<3d.htm>mailto:mduffy@quarrytech.com]<= /FONT> > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; = ipsec@lists.tislabs.com > Subject: Re: 2401bis issues (possible) = resolution > > > At 01:38 PM 10/7/2003 -0400, Angelos D. = Keromytis wrote: > >In our weekly teleconference, we discussed = the following > items from the > >issues list: > ... > = > 68 VPNs with = overlapping IP address ranges > ... > >We believe that these items are = implementation-specific and/or not > >applicable to implementations in general = (this applies in > particular to > >50 and partially to 68). We invite one last = round of > comments on these > >items --- if you feel strongly, = yell! > > > Hi Angelos and list, > > As invited, I am yelling :-) > > #68 (as I think you have acknowledged) consists = of multiple parts, > some of which are implementation issues but not = all. Part of #68 > involved a capability in the protocol: > > = ; b. They MUST negotiate a VPN subscriber ID using IKE, as > = ; noted above, to enable forwarding of inbound IPsec > = ; traffic after crypto processing. > > When a security Gateway is operating on behalf = of multiple contexts > (e.g. multiple subscribers, or multiple = ppvpn-style overlay > addressing contexts), > it is essential that the initiator be able to = convey to the > responder which > context is being addressed. In the = absence of a capability > to signal this > in IKE, the only full-functioned alternative is = for the SGs > to maintain a > separate IP address to use for each supported = context. This > can waste a > lot of addresses, and it isn't even as good = anyway because it > requires > coordinated configuration on both ends to = understand which IP > address in > each SG corresponds to which context. > > My conclusion: 2401bis should support the = concept of multiple > contexts supported in an IPsec device, and IKE = should provide a means > to convey the > desired context in the initial exchange. > > Thanks, Mark > > > ------_=_NextPart_001_01C38DE8.25641170-- From owner-ipsec@lists.tislabs.com Thu Oct 9 08:06:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99F6BKP070915; Thu, 9 Oct 2003 08:06:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06490 Thu, 9 Oct 2003 10:19:29 -0400 (EDT) Message-Id: <5.1.0.14.2.20031009161624.02e13520@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Oct 2003 16:28:16 +0200 To: Joe Touch From: Eric Vyncke Subject: Re: 2401bis issues (possible) resolution Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <3F8329A2.60302@isi.edu> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 09 Oct 2003 14:28:22.0521 (UTC) FILETIME=[97C4C690:01C38E71] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:01 7/10/2003 -0700, Joe Touch wrote: >Angelos D. Keromytis wrote: > 50 Proposed change: tunnel vs. transport mode >>to 68). We invite one last round of comments on these items --- if you feel >>strongly, yell! Angelos, I'm yelling then ;-) Transport mode is heavily used today by security gateways in conjunction with another tunneling mechanism (the choice is yours -- the objective is to use a tunnel understood by the kernel to apply packet forwarding based on a FIB). When I write 'heavily', this means by dozens of organizations for their site to site VPN with 100 to 5000 nodes. All what is needed for such VPN is that both RFC 2401bis and IKEv2 allow the negotiation/SPD/SAD for transport mode between 2 SG. That's all. Regarding the security aspects of transport mode combined with another tunneling mechanism (like IPinIP or GRE or ...), the fact that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, dstPort=opaque) has a positive impact on the configuration of 100's of nodes. Security can anyway be provided by applying the SPD on the tunnel interface (which is just another interface where a security policy can obviously be enforced). NB: the text about 'link layer' encryption has much less importance for me. I know that this topic has been beaten to death on the mailing list. But, please allow transport mode between SG or better allow a SG to also act as a host (which is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). Regards -eric >Item 50: > >The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway originate and/or terminate at that gateway, and as such, are hosts for the purposes of IPsec conformance (for that tunnel). Thus RFC2401 already permits the use of transport mode on this traffic. > >As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt > >We feel that it would be useful for RFC2401bis to make this distinction clear, esp. since 2401 currently suggests that transport mode support is not required at gateways, i.e. in Sec 4.1: > >> Whenever either end of a security association is a security gateway, >> the SA MUST be tunnel mode. > >It might be more specific to indicate that: > >For traffic originating or terminating at a gateway, that gateway MUST support the functions of an IPsec host. In particular, traffic originating or terminating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway that originates or terminates packets tunneled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow the IPsec host requirements rather than the IPsec gateway requirements. > >Permitting the use of transport mode in this context goes specifically to the interaction between IPsec and RFC2003 tunnels, making it a protocol issue rather than merely an implementation issue. > >Joe > > > From owner-ipsec@lists.tislabs.com Thu Oct 9 08:20:19 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FKJKP071553; Thu, 9 Oct 2003 08:20:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06544 Thu, 9 Oct 2003 10:29:26 -0400 (EDT) Message-Id: <5.2.0.9.2.20031009070142.0409b660@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Oct 2003 07:07:21 -0400 To: Steve Hanna From: Russ Housley Subject: Re: Comments on draft-ietf-ipsec-pki-profile-03.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <4.3.2.7.2.20031008153004.02e58ff8@mira-sjc5-4.cisco.com> References: <3F832206.A9419C84@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve: There will be a BOF in Minneapolis of the pki4ipsec group. I am working with the proposed chairs to come up with a draft charter for review and discussion at the BOF. As usual, a mail list is being set up. The mail list will be announced here when it is open for business. Russ At 03:37 PM 10/8/2003 -0700, Barbara Fraser wrote: >Hi Steve, > >Thank you for taking the time to review this document. We agree it is an >important one. However, it is sufficiently separable from the core IPsec >protocol specs, that there has been some discussion on pulling it out of >the IPsec wg, allowing us to finally complete our chartered >activities. I'm explicitly adding Russ to the distribution so that he can >respond with the status of this follow on piece of work. > >thanks, >Barb From owner-ipsec@lists.tislabs.com Thu Oct 9 08:30:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99FUhKP071874; Thu, 9 Oct 2003 08:30:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06720 Thu, 9 Oct 2003 10:50:24 -0400 (EDT) Message-Id: <200310091451.h99EpDHW015141@coredump.cs.columbia.edu> To: Eric Vyncke Cc: Joe Touch , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Thu, 09 Oct 2003 16:28:16 +0200." <5.1.0.14.2.20031009161624.02e13520@localhost> Date: Thu, 09 Oct 2003 10:51:13 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode. Issue #50 is a lot more aggressive, as we read it. -Angelos In message <5.1.0.14.2.20031009161624.02e13520@localhost>, Eric Vyncke writes: > >Transport mode is heavily used today by security gateways in >conjunction with another tunneling mechanism (the choice is yours >-- the objective is to use a tunnel understood by the kernel to >apply packet forwarding based on a FIB). > >When I write 'heavily', this means by dozens of organizations for >their site to site VPN with 100 to 5000 nodes. > >All what is needed for such VPN is that both RFC 2401bis and IKEv2 >allow the negotiation/SPD/SAD for transport mode between 2 SG. > >That's all. > >Regarding the security aspects of transport mode combined with >another tunneling mechanism (like IPinIP or GRE or ...), the fact >that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, >dstPort=opaque) has a positive impact on the configuration of 100's of nodes. Security can anyway be provided by applying the SPD on the >tunnel interface (which is just another interface where a security >policy can obviously be enforced). > >NB: the text about 'link layer' encryption has much less importance for me. > >I know that this topic has been beaten to death on the mailing list. But, plea >se >allow transport mode between SG or better allow a SG to also act as a host (wh >ich >is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). > >Regards > >-eric > > >>Item 50: >> >>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not >traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway >originate and/or terminate at that gateway, and as such, are hosts for the pur >poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits the > use of transport mode on this traffic. >> >>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt >> >>We feel that it would be useful for RFC2401bis to make this distinction clear >, esp. since 2401 currently suggests that transport mode support is not requir >ed at gateways, i.e. in Sec 4.1: >> >>> Whenever either end of a security association is a security gateway, >>> the SA MUST be tunnel mode. >> >>It might be more specific to indicate that: >> >>For traffic originating or terminating at a gateway, that gateway MUST suppor >t the functions of an IPsec host. In particular, traffic originating or termin >ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003 >) MAY use transport mode. A gateway that originates or terminates packets tunn >eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow t >he IPsec host requirements rather than the IPsec gateway requirements. >> >>Permitting the use of transport mode in this context goes specifically to the > interaction between IPsec and RFC2003 tunnels, making it a protocol issue rat >her than merely an implementation issue. >> >>Joe >> >> >> From owner-ipsec@lists.tislabs.com Thu Oct 9 09:04:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99G4EKP073638; Thu, 9 Oct 2003 09:04:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07009 Thu, 9 Oct 2003 11:20:13 -0400 (EDT) Message-ID: <3F857EC1.8070907@isi.edu> Date: Thu, 09 Oct 2003 08:29:05 -0700 From: Joe Touch Organization: USC/ISI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Angelos D. Keromytis" CC: Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution References: <200310091451.h99EpDHW015141@coredump.cs.columbia.edu> In-Reply-To: <200310091451.h99EpDHW015141@coredump.cs.columbia.edu> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis wrote: > Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode. Except, as pointed out in my earlier post of 10/7/03: RFC2401, Sec 4.1: > Whenever either end of a security association is a security gateway, > the SA MUST be tunnel mode. I.e., this explicitly precludes the use of transport modes between gateways, except if considering that non-IPsec tunnels render those gateways into hosts, so host rules should apply. Although that latter interpretation technically complies with 2401, sec 4.1 could be misconstrued to imply that gateways should not support transport mode. That is where 2401bis could be clarified, as per (e.g.) the mods I suggested in that earlier post. > Issue #50 is a lot more aggressive, as we read it. Agreed. > In message <5.1.0.14.2.20031009161624.02e13520@localhost>, Eric Vyncke writes: > >>Transport mode is heavily used today by security gateways in >>conjunction with another tunneling mechanism (the choice is yours >>-- the objective is to use a tunnel understood by the kernel to >>apply packet forwarding based on a FIB). >> >>When I write 'heavily', this means by dozens of organizations for >>their site to site VPN with 100 to 5000 nodes. >> >>All what is needed for such VPN is that both RFC 2401bis and IKEv2 >>allow the negotiation/SPD/SAD for transport mode between 2 SG. >> >>That's all. >> >>Regarding the security aspects of transport mode combined with >>another tunneling mechanism (like IPinIP or GRE or ...), the fact >>that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, >>dstPort=opaque) has a positive impact on the configuration of 100's > > of nodes. Security can anyway be provided by applying the SPD on the > >>tunnel interface (which is just another interface where a security >>policy can obviously be enforced). >> >>NB: the text about 'link layer' encryption has much less importance for me. >> >>I know that this topic has been beaten to death on the mailing list. But, plea >>se >>allow transport mode between SG or better allow a SG to also act as a host (wh >>ich >>is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). >> >>Regards >> >>-eric >> >> >> >>>Item 50: >>> >>>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not >> >>traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway >>originate and/or terminate at that gateway, and as such, are hosts for the pur >>poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits the >>use of transport mode on this traffic. >> >>>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt >>> >>>We feel that it would be useful for RFC2401bis to make this distinction clear >> >>, esp. since 2401 currently suggests that transport mode support is not requir >>ed at gateways, i.e. in Sec 4.1: >> >>>> Whenever either end of a security association is a security gateway, >>>> the SA MUST be tunnel mode. >>> >>>It might be more specific to indicate that: >>> >>>For traffic originating or terminating at a gateway, that gateway MUST suppor >> >>t the functions of an IPsec host. In particular, traffic originating or termin >>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003 >>) MAY use transport mode. A gateway that originates or terminates packets tunn >>eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow t >>he IPsec host requirements rather than the IPsec gateway requirements. >> >>>Permitting the use of transport mode in this context goes specifically to the >> >>interaction between IPsec and RFC2003 tunnels, making it a protocol issue rat >>her than merely an implementation issue. >> >>>Joe >>> >>> >>> From owner-ipsec@lists.tislabs.com Thu Oct 9 09:10:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99GATKP073960; Thu, 9 Oct 2003 09:10:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07033 Thu, 9 Oct 2003 11:21:50 -0400 (EDT) Message-Id: <200310091522.h99FMfHW009129@coredump.cs.columbia.edu> To: Joe Touch Cc: Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Thu, 09 Oct 2003 08:29:05 PDT." <3F857EC1.8070907@isi.edu> Date: Thu, 09 Oct 2003 11:22:41 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Right --- the mods Joe suggested seem acceptable. -Angelos In message <3F857EC1.8070907@isi.edu>, Joe Touch writes: > > >Angelos D. Keromytis wrote: >> Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode. > >Except, as pointed out in my earlier post of 10/7/03: > >RFC2401, Sec 4.1: > > > Whenever either end of a security association is a security gateway, > > the SA MUST be tunnel mode. > >I.e., this explicitly precludes the use of transport modes between >gateways, except if considering that non-IPsec tunnels render those >gateways into hosts, so host rules should apply. Although that latter >interpretation technically complies with 2401, sec 4.1 could be >misconstrued to imply that gateways should not support transport mode. >That is where 2401bis could be clarified, as per (e.g.) the mods I >suggested in that earlier post. > >> Issue #50 is a lot more aggressive, as we read it. > >Agreed. > >> In message <5.1.0.14.2.20031009161624.02e13520@localhost>, Eric Vyncke write >s: >> >>>Transport mode is heavily used today by security gateways in >>>conjunction with another tunneling mechanism (the choice is yours >>>-- the objective is to use a tunnel understood by the kernel to >>>apply packet forwarding based on a FIB). >>> >>>When I write 'heavily', this means by dozens of organizations for >>>their site to site VPN with 100 to 5000 nodes. >>> >>>All what is needed for such VPN is that both RFC 2401bis and IKEv2 >>>allow the negotiation/SPD/SAD for transport mode between 2 SG. >>> >>>That's all. >>> >>>Regarding the security aspects of transport mode combined with >>>another tunneling mechanism (like IPinIP or GRE or ...), the fact >>>that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, >>>dstPort=opaque) has a positive impact on the configuration of 100's >> >> of nodes. Security can anyway be provided by applying the SPD on the >> >>>tunnel interface (which is just another interface where a security >>>policy can obviously be enforced). >>> >>>NB: the text about 'link layer' encryption has much less importance for me. >>> >>>I know that this topic has been beaten to death on the mailing list. But, pl >ea >>>se >>>allow transport mode between SG or better allow a SG to also act as a host ( >wh >>>ich >>>is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). >>> >>>Regards >>> >>>-eric >>> >>> >>> >>>>Item 50: >>>> >>>>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, no >t >>> >>>traffic on a 'link' in general. Packets using 2003-style tunnels at a gatewa >y >>>originate and/or terminate at that gateway, and as such, are hosts for the p >ur >>>poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits t >he >>>use of transport mode on this traffic. >>> >>>>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.tx >t >>>> >>>>We feel that it would be useful for RFC2401bis to make this distinction cle >ar >>> >>>, esp. since 2401 currently suggests that transport mode support is not requ >ir >>>ed at gateways, i.e. in Sec 4.1: >>> >>>>> Whenever either end of a security association is a security gateway, >>>>> the SA MUST be tunnel mode. >>>> >>>>It might be more specific to indicate that: >>>> >>>For traffic originating or terminating at a gateway, that gateway MUST suppo >r >>> >>>t the functions of an IPsec host. In particular, traffic originating or term >in >>>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC20 >03 >>>) MAY use transport mode. A gateway that originates or terminates packets tu >nn >>>eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow > t >>>he IPsec host requirements rather than the IPsec gateway requirements. >>> >>>>Permitting the use of transport mode in this context goes specifically to t >he >>> >>>interaction between IPsec and RFC2003 tunnels, making it a protocol issue ra >t >>>her than merely an implementation issue. >>> >>>>Joe >>>> >>>> >>>> From owner-ipsec@lists.tislabs.com Thu Oct 9 10:41:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99HfdKP078878; Thu, 9 Oct 2003 10:41:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07877 Thu, 9 Oct 2003 12:50:09 -0400 (EDT) Message-Id: <200310091618.MAA26487@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-aes-xcbc-prf-01.txt Date: Thu, 09 Oct 2003 12:18:02 -0400 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-PRF-128 algorithm for IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-aes-xcbc-prf-01.txt Pages : 0 Date : 2003-10-9 Some implementations of IPsec may want to use a pseudo-random function derived from AES. This document describes such an algorithm, called AES-XCBC-PRF-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-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-aes-xcbc-prf-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-aes-xcbc-prf-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: <2003-10-9122541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-aes-xcbc-prf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9122541.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Oct 9 10:47:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99HlpKP079034; Thu, 9 Oct 2003 10:47:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07921 Thu, 9 Oct 2003 12:57:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20031009100124.05a46f00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 10:02:54 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: November 2003 Minneapolis IETF Meeting In-Reply-To: <4.3.2.7.2.20031008153919.05e1cc98@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10526526==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_10526526==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I don't know what got into my fingers when I typed the original title on this email. I really did mean the upcoming November meeting :-) Barb At 03:46 PM 10/8/2003, Barbara Fraser wrote: >Hi, > >We have reserved 1 time slot for a working group meeting at the upcoming >IETF meeting in Minneapolis. It is scheduled for Monday 15:30-17:30. > >We're making progress on the update to 2401 and the meeting time will be >spent discussing any remaining open issues that exist at that point in >time...hopefully it will be a short meeting :-) > >For those historians among us, this may be the last IPsec working group >meeting. After ~12 years, I don't think we'll be breaking any records, >but it sure will be nice to complete the work of this group. > >thanks >Barb and Ted --=====================_10526526==_.ALT Content-Type: text/html; charset="us-ascii" I don't know what got into my fingers when I typed the original title on this email. I really did mean the upcoming November meeting :-) Barb At 03:46 PM 10/8/2003, Barbara Fraser wrote: >Hi, > >We have reserved 1 time slot for a working group meeting at the upcoming IETF meeting in Minneapolis. It is scheduled for Monday 15:30-17:30. > >We're making progress on the update to 2401 and the meeting time will be spent discussing any remaining open issues that exist at that point in time...hopefully it will be a short meeting :-) > >For those historians among us, this may be the last IPsec working group meeting. After ~12 years, I don't think we'll be breaking any records, but it sure will be nice to complete the work of this group. > >thanks >Barb and Ted --=====================_10526526==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Oct 9 12:12:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99JCvKP081599; Thu, 9 Oct 2003 12:12:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08575 Thu, 9 Oct 2003 14:19:46 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16261.43142.238298.551445@ryijy.hel.fi.ssh.com> Date: Thu, 9 Oct 2003 21:27:18 +0300 From: Tero Kivinen To: "Angelos D. Keromytis" Cc: Joe Touch , Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-Reply-To: <200310091522.h99FMfHW009129@coredump.cs.columbia.edu> References: <3F857EC1.8070907@isi.edu> <200310091522.h99FMfHW009129@coredump.cs.columbia.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis writes: > Right --- the mods Joe suggested seem acceptable. I think we then should create new issue to issue tracker, with that proposed text, so we can accept that and reject this? >> That is where 2401bis could be clarified, as per (e.g.) the mods I >> suggested in that earlier post. >>> It might be more specific to indicate that: >>> >>> For traffic originating or terminating at a gateway, that gateway >>> MUST support the functions of an IPsec host. In particular, >>> traffic originating or terminating at that gateway that is >>> tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use >>> transport mode. A gateway that originates or terminates packets >>> tunneled over non-IPsec mechanisms, for the purposes of that >>> tunnel, MUST follow the IPsec host requirements rather than the >>> IPsec gateway requirements. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 9 12:36:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99JahKP083251; Thu, 9 Oct 2003 12:36:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08757 Thu, 9 Oct 2003 14:48:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20031009115135.05d6db40@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 11:55:20 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Last Call on 2401bis issues 72, 73, 76, 79, 80, 83, 84 Cc: byfraser@cisco.com, tytso@mit.edu, angelos@cs.columbia.edu, Tero Kivinen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk During our teleconference this week, we decided a number of the proposed 2401 changes/issues are non-controversial and should be accepted. Suggested no change to existing 2401: 79 Detection of dead peers and dead SAs Clarifications: 72 Explain why ALL IP packets must be checked 73 IP Option & Ext Hdr handling in Tunnel Mode 76 More explanation re: ESPv3 TFC padding & dummy packets Handled by IPSP working group: 80 Security gateway discovery - suggestion is to not do anything since IPSP wg is working on this. Debugging Support: 83 DROP'd inbound packet -- missing required IPsec protection - debug support 84 DROP'd outbound packet - debug support Please consider this a 48 hour last call on these issues. If you have comments on one of these issues, please include the issue number in the subject of your email message. Thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Thu Oct 9 13:32:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99KWrKP085353; Thu, 9 Oct 2003 13:32:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09126 Thu, 9 Oct 2003 15:39:01 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF08C86F08@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: ipsec@lists.tislabs.com Subject: FW: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution) Date: Thu, 9 Oct 2003 15:39:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Repeating; hope the text format comes through this time - sorry for the "noise". -----Original Message----- From: Knight, Paul [BL60:1A14:EXCH] Sent: Wednesday, October 08, 2003 12:13 PM To: 'Tero Kivinen'; Mark Duffy Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Hi Tero and all, I think you are right that the VPN subscriber ID is not required in the case you describe (individual host or client connecting via a gateway), but the more difficult case is where there are multiple "ISP SGW" devices, which are used to interconnect multiple corporate sites in a VPN. In the VPN-related working groups, the terminology would be "PE" - provider edge devices. So in terms of your diagram, it would look like: Corp A --------. .------ Corp A +-----+ +-----+ | ISP |---{ Internet } ----| ISP | | SGW | | SGW | +-----+ +-----+ Corp B --------' '------ Corp B Corporations A & B may trust their links to the ISP who runs the security gateways, but they want the ISP to provide IPsec protection between the ISP's SGWs, where the traffic runs across the Internet. In my message of yesterday (Re: 2401bis issues (possible) resolution), I identified some issues, described some ways to deal with this, and recommended using the VPN-ID as a way for the ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without requiring extra IP addresses. There are ways to multiplex the VPN traffic over a single SA pair, but these all seem to require either extra encapsulation or the addition of some "tag" to every packet. It appears to me that a solution allowing a single encapsulation of the corporate traffic (either IPsec tunnel mode or IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, requires the VPN-ID (or "Context identifier"). I do hope there is a way to support this requirement without adding the extra "Context ID" payload, but I have not seen it yet. I would be happy to hear of a solution. Another possible way to support this could be another ID Type within the Identification Payload. In this case, multiple new ID Types may be needed since there are multiple VPN-ID formats (see my message of yesterday). I am somewhat concerned about overloading the Identification Payload in this way, since the Context IDs are actually a kind of temporary "sub-identity" of the gateways. This brings to mind the "me Tarzan - you Jane" concepts discussed earlier. Regards, Paul Knight P.S. I include my message of yesterday below for ease of reference. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Wednesday, October 08, 2003 10:28 AM > To: Mark Duffy > Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Issue #68: VPNs with overlapping IP address ranges > (was Re: 2401bis issues (possible) resolution) > > > [Please when you send comments to list, use the issue number > in the subject, so it is easier for the others to search for > other mails with same issue]. > > Mark Duffy writes: > > > 68 VPNs with overlapping IP address ranges > > #68 (as I think you have acknowledged) consists of multiple parts, > > some of > > which are implementation issues but not all. Part of #68 > involved a > > capability in the protocol: > > > > b. They MUST negotiate a VPN subscriber ID using IKE, as > > noted above, to enable forwarding of inbound IPsec > > traffic after crypto processing. > > I do not think there is any need to negotiate the VPN > subscriber ID between the parties. The VPN subscriber ID is > internal to the SGW, and it is not going to trust anything > the other end sends. > > If I have understood correctly about the case it is something like > this: > > > > Corp A --------. +---- Client C > +-----+ | > | ISP |-----{ Internet } ----| > | SGW | | > +-----+ +---- Client D > Corp B --------' > > > Where the ISP SGW is acting as VPN GW for both corporation A > and corporation B, and the clients connect to it using IPsec > through the internet. Corporations A and B both use > 10.0.0.0/8 network, and give out IP address to the clients > from the same range. Now when the client C connects to the > ISP SGW it authenticates itself as c@corp-a.com. The ISP SGW > will now link that authenticated identity to the VPN > Subscriber ID of Corp-A, and attach all packets coming from > the client C to that VPN ID. When it is sending them out it > will send to Corp A interface, because it is also attached to > the Corp-A VPN ID. > > The ISP SGW will not be trusting client C to send him the VPN > ID, as if it would trust clinet C, the c@corp-a.com could > send VPN ID of corp-b instead and get access to the Corp B network. > > So only way to get those VPN-IDs is through the configuration > based on the authenticated ID of the client, thus there is no > need to negotiate them in IKE. > > This means that client C and D are normal IPsec clients, and > they do not have any special processing to be done. If Client > C for some reason wants (and is allowed) to be part of both > Corp A and B networks, then he can have two authenticated IKE > identities c@corp-a.com and c@corp-b.com. > > All the special processing of VPN IDs etc (or whatever local > processing the ISP SGW does) is inside the ISP SGW, thus it > is purely local implementation issue. > > > When a security Gateway is operating on behalf of multiple contexts > > (e.g. > > multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > > it is essential that the initiator be able to convey to the > responder which > > context is being addressed. > > Do not use IP addresses as a IKE SA identities then. Use the > dns names or email addresses or something else. There is no > need to use ip addresses in those cases (or actually using ip > addresses would be quite bad, as it is not unique...). > > > In the absence of a capability to signal this > > in IKE, the only full-functioned alternative is for the SGs > to maintain a > > separate IP address to use for each supported context. > This can waste a > > lot of addresses, and it isn't even as good anyway because > it requires > > coordinated configuration on both ends to understand which > IP address in > > each SG corresponds to which context. > > There is no need for that. > > > My conclusion: 2401bis should support the concept of multiple > > contexts > > supported in an IPsec device, and IKE should provide a > means to convey the > > desired context in the initial exchange. > > I do not think this is general case that should be > implemented in the all IPsec stacks out there. It will be > implemented as purely local matter in some of the IPsec > implementations, and there is no need to have any kind of > negotiation or changes to the IKE because of that. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ***************** yesterday's message below ******* Hi Angelos, Mark, and all, I agree with Mark on this, we need a context identifier for the VPN case, in order to provide the most straightforward IPsec solution, while not forcing the use of multiple IP addresses on the security gateways. Just to make sure we're clear, here is the basic scenario: CE-A1--\ /--CE-A2 PE1---(Internet)----PE2 CE-B1--/ \--CE-B2 CE = Customer Edge device CE-A1 = CE at customer A, VPN site 1 PE = Provider Edge device (also security gateway in this case) Customers A,B each have two VPN sites. They each use network 10.0.0.0 (for example). PE1 and PE2 would like to set up IPsec SA pairs (IPsec connections) to carry the VPN traffic for both VPNs A and B. They have at least two basic ways to do this: (1) Set up a single IPsec connection between PE1 and PE2 for both VPNs. (2) Set up one IPsec connection *per VPN* between PE1 and PE2. Two ways to do this: (2a) use one IP address per VPN on the Internet-facing interface(s) of each PE, and negotiate an IPsec connection for each IP address pair, and use an internal mechanism to associate the IP addresses and IPsec connections to the VPNs. (2b) use a single IP address on the Internet-facing interface of each PE, use a context identifier (VPN-ID) to negotiate multiple IPsec connections (one per VPN), and use an internal mechanism to associate the IPsec connections to the VPNs. Discussion: (1) does not require any change to IKEv2 or 2401bis, but it is not able to carry IP directly (without additional encapsulation or some kind of label) in the VPN scenario described above. One approach based on (1) is proposed in draft-ietf-l3vpn-ipsec-2547-01.txt. It relies on an MPLS label attached to each packet within the SA, to allow the receiver to associate the traffic with the appropriate VPN. [IMPORTANT NOTE: This approach implies that paragraph b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or SHOULD. This approach would be invalidated by the adoption of the MUST language.] A variation of this approach could use a VPN-ID field appended to each packet instead of an MPLS label. Another approach based on (1) is described in the "backbone Virtual Router" discussion of draft-ietf-l3vpn-vpn-vr-01.txt. It uses additional encapsulation to allow multiple VPNs to be carried over a single IPsec connection between PEs. It uses additional IP addresses per VPN, but they can be private addresses of the provider. (2a) does not scale well, since it requires adding additional routable IP addresses when additional VPNs are added to a PE. (2b) is attractive from the viewpoint of not requiring multiple IP addresses, although there are minor scaling issues with separate IPsec connections per VPN. It requires a method of signaling a context identifier or VPN-ID during IKE negotiation. The simplest way I know to support this requirement would be to add a Context-Identifier Payload to IKEv2. It should support multiple types of context identifiers, since there are several potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label Regards, Paul Knight > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Re: 2401bis issues (possible) resolution > > > At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote: > >In our weekly teleconference, we discussed the following > items from the > >issues list: > ... > > 68 VPNs with overlapping IP address ranges > ... > >We believe that these items are implementation-specific and/or not > >applicable to implementations in general (this applies in > particular to > >50 and partially to 68). We invite one last round of > comments on these > >items --- if you feel strongly, yell! > > > Hi Angelos and list, > > As invited, I am yelling :-) > > #68 (as I think you have acknowledged) consists of multiple parts, > some of which are implementation issues but not all. Part of #68 > involved a capability in the protocol: > > b. They MUST negotiate a VPN subscriber ID using IKE, as > noted above, to enable forwarding of inbound IPsec > traffic after crypto processing. > > When a security Gateway is operating on behalf of multiple contexts > (e.g. multiple subscribers, or multiple ppvpn-style overlay > addressing contexts), > it is essential that the initiator be able to convey to the > responder which > context is being addressed. In the absence of a capability > to signal this > in IKE, the only full-functioned alternative is for the SGs > to maintain a > separate IP address to use for each supported context. This > can waste a > lot of addresses, and it isn't even as good anyway because it > requires > coordinated configuration on both ends to understand which IP > address in > each SG corresponds to which context. > > My conclusion: 2401bis should support the concept of multiple > contexts supported in an IPsec device, and IKE should provide a means > to convey the > desired context in the initial exchange. > > Thanks, Mark > > > From btomh@gte.net Thu Oct 9 21:36:47 2003 Received: from WIN2000 ([61.55.140.61]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9A4aiZA006651 for ; Thu, 9 Oct 2003 21:36:46 -0700 (PDT) (envelope-from btomh@gte.net) Message-Id: <200310100436.h9A4aiZA006651@above.proper.com> From: "bstrshine@email.com" To: "ietf-ipsec@imc.org" Subject: Re: Land a job real quick-order a diploma! q0w Date: Fri, 10 Oct 2003 12:38:51 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPHN0 eWxlIHR5cGU9InRleHQvY3NzIj4NCkEueWVsbG93Omxpbmsge3RleHQtZGVjb3JhdGlvbjogbm9u ZTsgY29sb3I6ICNGRkYyMDB9DQpBLnllbGxvdzp2aXNpdGVkIHt0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiAjRkZGMjAwfQ0KQS55ZWxsb3c6YWN0aXZlIHt0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiAjRUZFRkM4fQ0KQS55ZWxsb3c6aG92ZXIge3RleHQtZGVjb3JhdGlvbjogbm9u ZTsgY29sb3I6ICNGRkZGRkZ9DQo8L3N0eWxlPg0KPGJvZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9y PSIjMzMzM0ZGIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGJyPg0KPHRhYmxlIHdpZHRoPSI2NTAi IGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIyIiBib3JkZXJjb2xvcj0i IzAwMDAwMCI+PHRyPjx0ZD48dGFibGUgd2lkdGg9IjY1MCIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjQiIGFsaWduPSJjZW50ZXIiPjx0cj4NCjx0ZCBiZ2NvbG9yPSIj MDAzMzY2Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiIgZmFjZT0iQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiI+LiBVIE4gPCEtLSBoZjdvbDhhIC0tPkkgViBFIFIgUyBJIFQgWSAu IEQgSSBQIEwgPCEtLSBoZjdvbDhhIC0tPk8gTSBBIFMgLjwvZm9udD48L3RkPjwvdHI+DQo8dHI+ PHRkIGJnY29sb3I9ImJsYWNrIiBoZWlnaHQ9IjQwIiB2YWxpZ249Im1pZGRsZSI+DQo8ZGl2IGFs aWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjRkZGRkZGIj48aT5EbyB5b3Ugd2FudCBmb3IgYSBwcm9z cGVyb3VzIGZ1dHVyZSwgaW5jcmVhc2VkIG1vbmV5IGVhcm5pbmcgcG93ZXIsIGFuZCB0aGUgcmVz cGVjdCBvZiBhbGw/PC9pPjxicj48L2ZvbnQ+PC9kaXY+DQo8L3RkPjwvdHI+PHRyPiA8dGQgYmdj b2xvcj0iQ0MwMDMzIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PGI+PGk+PGZvbnQgZmFjZT0i VmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+V2UgY2FuIGFz c2lzdCB3aXRoIERpcDwhLS0gaGY3b2w4YSAtLT5sb21hcyBmcm9tIHByZXN0aWdpb3VzIG5vbi1h Y2NyZWRpdGVkIHVuaXZlcnNpdDwhLS0gaGY3b2w4YSAtLT5pZXMgYmFzZWQgb24geW91ciBwcmVz ZW50IGtub3dsZWRnZSBhbmQgbGlmZSBleHBlcmllbmNlLjwvZm9udD48Lw0KPC90ZD48L3RyPjx0 cj48dGQgYmdjb2xvcj0id2hpdGUiPg0KPGRpdiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIzIj48YnI+PGI+PGZv bnQgY29sb3I9IiNGRjAwMDAiPk5vIHJlcXVpcmVkIHRlc3RzLCBjbGFzc2VzLCBib29rcywgb3Ig aW50ZXJ2aWV3cy4gPC9mb250PjwvYj48L2ZvbnQ+IDwvZGl2Pg0KPHAgYWxpZ249ImxlZnQiPjxm b250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjMi PjxpPkdlbnVpbmUgQmFjaGVsb3JzLCBNYXN0ZXJzLCBNQkEgYW5kIFBIRCdzIGF2YWlsYWJsZSBp biBhbnkgZmllbGQgeW91IGNob29zZS4gUGVyZmVjdCBmb3IgeW91ciBSZXN1bWUsIEpvYiBpbnRl cnZpZXcgb3IgdG8gaGFuZyBpbiB0aGUgd2FsbCBvZiB5b3VyIG9mZmljZSE8L2k+PC9mb250Pjwv cD4NCjxwIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWYiIHNpemU9IjMiPjxiPjxmb250IHNpemU9IjUiIGNvbG9yPSIjMDAwMEZG Ij5ObyBvbmUgaXMgdHVybmVkIGRvd24uPC9mb250PjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249 ImNlbnRlciI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZiIgc2l6ZT0iMyI+PGk+Q29uZmlkZW50aWFsaXR5IGFzc3VyZWQ8L2k+PC9mb250Pjxicj48YnI+ PC9wPg0KPC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJj ZW50ZXIiPjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiIGNvbG9yPSIjRkZGRkZGIj48YnI+DQpDQUxMIFVTJm5ic3A7IDI0IEhPVVJTIEEgREFZLCA3 IERBWVMmbmJzcDsgQSBXRUVLPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNvbG9yPSIjRkZGRkZGIj4mbmJzcDsgPGZvbnQg c2l6ZT0iMSI+KGluY2x1ZGluZyBTdW5kYXlzIGFuZCBob2xpZGF5cyk6PC9mb250PjwvZm9udD48 L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm IiBjb2xvcj0iI0ZGRkZGRiI+PGI+PGZvbnQgc2l6ZT0iNSI+Q0FMTCBOT1chIDEtMjwhLS0gaGY3 b2w4YSAtLT4xMi0yMDItNDc4NTwvZm9udD48L2I+IDwvZm9udD4gPGZvbnQgc2l6ZT0iNSIgZmFj ZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiNGRkZGRkYiPjxicj48L2I+ PC9mb250PjwvcD48L2Rpdj4NCjwvdGQ+PC90cj48dHI+IDx0ZCBiZ2NvbG9yPSIjMDAzMzY2Ij4N CjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiNGRkZGRkYiIGZhY2U9 IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxiPkNhbGwgdXMgTk9XIHRvIHJlY2VpdmUg eW91ciBkaXBsbzwhLS0gaGY3b2w4YSAtLT5tYSB3aXRoaW4gZGF5cywgYW5kIHN0YXJ0IGltcHJv dmluZyB5b3VyIGxpZmUhPC9iPjwvZm9udD48L2Rpdj4NCjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+ PC90cj48L3RhYmxlPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K From owner-ipsec@lists.tislabs.com Fri Oct 10 01:52:01 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A8q0ZA079293; Fri, 10 Oct 2003 01:52:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12482 Fri, 10 Oct 2003 04:02:25 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16262.26966.498415.430085@ryijy.hel.fi.ssh.com> Date: Fri, 10 Oct 2003 11:09:58 +0300 From: Tero Kivinen To: Barbara Fraser Cc: ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu Subject: Issue #83, #84: (was: Last Call on 2401bis issues 72, 73, 76, 79, 80, 83, 84) In-Reply-To: <4.3.2.7.2.20031009115135.05d6db40@mira-sjc5-4.cisco.com> References: <4.3.2.7.2.20031009115135.05d6db40@mira-sjc5-4.cisco.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara Fraser writes: > Debugging Support: > 83 DROP'd inbound packet -- missing required IPsec protection - debug support > 84 DROP'd outbound packet - debug support Both of these have text that says: ---------------------------------------------------------------------- To address this, the implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses. ---------------------------------------------------------------------- I.e either allow configuration option to disable or enable ICMP, *or* rate limit them. I think that even if there is option to disable ICMPs there SHOULD be way to rate limit them, i.e if the implementation allows sending ICMPs there must always way to rate limit them. So the new text could be: ---------------------------------------------------------------------- To address this, the implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, and to rate limit the transmission of such ICMP responses. ---------------------------------------------------------------------- (i.e change or => and). -- 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 Oct 10 01:52:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A8q2ZA079294; Fri, 10 Oct 2003 01:52:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12453 Fri, 10 Oct 2003 03:58:21 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16260.7900.891287.446736@ryijy.hel.fi.ssh.com> Date: Wed, 8 Oct 2003 17:27:40 +0300 From: Tero Kivinen To: Mark Duffy Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <5.2.0.9.0.20031007155701.02041dc8@email> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.2.0.9.0.20031007155701.02041dc8@email> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Please when you send comments to list, use the issue number in the subject, so it is easier for the others to search for other mails with same issue]. Mark Duffy writes: > > 68 VPNs with overlapping IP address ranges > #68 (as I think you have acknowledged) consists of multiple parts, some of > which are implementation issues but not all. Part of #68 involved a > capability in the protocol: > > b. They MUST negotiate a VPN subscriber ID using IKE, as > noted above, to enable forwarding of inbound IPsec > traffic after crypto processing. I do not think there is any need to negotiate the VPN subscriber ID between the parties. The VPN subscriber ID is internal to the SGW, and it is not going to trust anything the other end sends. If I have understood correctly about the case it is something like this: Corp A --------. +---- Client C +-----+ | | ISP |-----{ Internet } ----| | SGW | | +-----+ +---- Client D Corp B --------' Where the ISP SGW is acting as VPN GW for both corporation A and corporation B, and the clients connect to it using IPsec through the internet. Corporations A and B both use 10.0.0.0/8 network, and give out IP address to the clients from the same range. Now when the client C connects to the ISP SGW it authenticates itself as c@corp-a.com. The ISP SGW will now link that authenticated identity to the VPN Subscriber ID of Corp-A, and attach all packets coming from the client C to that VPN ID. When it is sending them out it will send to Corp A interface, because it is also attached to the Corp-A VPN ID. The ISP SGW will not be trusting client C to send him the VPN ID, as if it would trust clinet C, the c@corp-a.com could send VPN ID of corp-b instead and get access to the Corp B network. So only way to get those VPN-IDs is through the configuration based on the authenticated ID of the client, thus there is no need to negotiate them in IKE. This means that client C and D are normal IPsec clients, and they do not have any special processing to be done. If Client C for some reason wants (and is allowed) to be part of both Corp A and B networks, then he can have two authenticated IKE identities c@corp-a.com and c@corp-b.com. All the special processing of VPN IDs etc (or whatever local processing the ISP SGW does) is inside the ISP SGW, thus it is purely local implementation issue. > When a security Gateway is operating on behalf of multiple contexts (e.g. > multiple subscribers, or multiple ppvpn-style overlay addressing contexts), > it is essential that the initiator be able to convey to the responder which > context is being addressed. Do not use IP addresses as a IKE SA identities then. Use the dns names or email addresses or something else. There is no need to use ip addresses in those cases (or actually using ip addresses would be quite bad, as it is not unique...). > In the absence of a capability to signal this > in IKE, the only full-functioned alternative is for the SGs to maintain a > separate IP address to use for each supported context. This can waste a > lot of addresses, and it isn't even as good anyway because it requires > coordinated configuration on both ends to understand which IP address in > each SG corresponds to which context. There is no need for that. > My conclusion: 2401bis should support the concept of multiple contexts > supported in an IPsec device, and IKE should provide a means to convey the > desired context in the initial exchange. I do not think this is general case that should be implemented in the all IPsec stacks out there. It will be implemented as purely local matter in some of the IPsec implementations, and there is no need to have any kind of negotiation or changes to the IKE because of that. -- 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 Oct 10 02:01:32 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A91TZA079584; Fri, 10 Oct 2003 02:01:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12602 Fri, 10 Oct 2003 04:19:09 -0400 (EDT) Message-ID: <3F866D9C.6050807@nomadiclab.com> Date: Fri, 10 Oct 2003 11:28:12 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Cc: Multi6 WG , IPV6 WG , MIP6 WG , IPsec WG Subject: An official HIP BOF request has been sent Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Apologies for cross-posting. Please trim the CC: on replies.] Folks, I sent an official BOF request for a Host Identity Protocol BOF a few moments ago. Based on the discussions with the INT area ADs, it looks fairly probable that a BOF will be scheduled. The latest version of the proposed BOF agenda is available at http://www.tml.hut.fi/~pnr/HIP/hipbof.txt The latest version of the proposed WG charter is available at http://www.tml.hut.fi/~pnr/HIP/hip_charter_proposal.txt Note to the IPsec WG: The charter proposal suggest that the new WG would specify a small addition to ESP, basing on draft-nikander-esp-beet-mode-00.txt. Folks at the IPsec WG may have strong opinions on this. The most appropiate place to discuss the BOF and charter proposals is the hipsec mailing list. See the bof agenda and/or charter proposal for details on how to join to the mailing list. The list policy requires non-member postings to be explicitly approved by the list admins. --Pekka Nikander From owner-ipsec@lists.tislabs.com Fri Oct 10 02:05:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A95cZA079699; Fri, 10 Oct 2003 02:05:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12608 Fri, 10 Oct 2003 04:21:27 -0400 (EDT) Message-Id: <200310091522.h99FMfHW009129@coredump.cs.columbia.edu> To: Joe Touch Cc: Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Thu, 09 Oct 2003 08:29:05 PDT." <3F857EC1.8070907@isi.edu> Date: Thu, 09 Oct 2003 11:22:41 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Right --- the mods Joe suggested seem acceptable. -Angelos In message <3F857EC1.8070907@isi.edu>, Joe Touch writes: > > >Angelos D. Keromytis wrote: >> Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode. > >Except, as pointed out in my earlier post of 10/7/03: > >RFC2401, Sec 4.1: > > > Whenever either end of a security association is a security gateway, > > the SA MUST be tunnel mode. > >I.e., this explicitly precludes the use of transport modes between >gateways, except if considering that non-IPsec tunnels render those >gateways into hosts, so host rules should apply. Although that latter >interpretation technically complies with 2401, sec 4.1 could be >misconstrued to imply that gateways should not support transport mode. >That is where 2401bis could be clarified, as per (e.g.) the mods I >suggested in that earlier post. > >> Issue #50 is a lot more aggressive, as we read it. > >Agreed. > >> In message <5.1.0.14.2.20031009161624.02e13520@localhost>, Eric Vyncke write >s: >> >>>Transport mode is heavily used today by security gateways in >>>conjunction with another tunneling mechanism (the choice is yours >>>-- the objective is to use a tunnel understood by the kernel to >>>apply packet forwarding based on a FIB). >>> >>>When I write 'heavily', this means by dozens of organizations for >>>their site to site VPN with 100 to 5000 nodes. >>> >>>All what is needed for such VPN is that both RFC 2401bis and IKEv2 >>>allow the negotiation/SPD/SAD for transport mode between 2 SG. >>> >>>That's all. >>> >>>Regarding the security aspects of transport mode combined with >>>another tunneling mechanism (like IPinIP or GRE or ...), the fact >>>that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, >>>dstPort=opaque) has a positive impact on the configuration of 100's >> >> of nodes. Security can anyway be provided by applying the SPD on the >> >>>tunnel interface (which is just another interface where a security >>>policy can obviously be enforced). >>> >>>NB: the text about 'link layer' encryption has much less importance for me. >>> >>>I know that this topic has been beaten to death on the mailing list. But, pl >ea >>>se >>>allow transport mode between SG or better allow a SG to also act as a host ( >wh >>>ich >>>is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). >>> >>>Regards >>> >>>-eric >>> >>> >>> >>>>Item 50: >>>> >>>>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, no >t >>> >>>traffic on a 'link' in general. Packets using 2003-style tunnels at a gatewa >y >>>originate and/or terminate at that gateway, and as such, are hosts for the p >ur >>>poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits t >he >>>use of transport mode on this traffic. >>> >>>>As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.tx >t >>>> >>>>We feel that it would be useful for RFC2401bis to make this distinction cle >ar >>> >>>, esp. since 2401 currently suggests that transport mode support is not requ >ir >>>ed at gateways, i.e. in Sec 4.1: >>> >>>>> Whenever either end of a security association is a security gateway, >>>>> the SA MUST be tunnel mode. >>>> >>>>It might be more specific to indicate that: >>>> >>>For traffic originating or terminating at a gateway, that gateway MUST suppo >r >>> >>>t the functions of an IPsec host. In particular, traffic originating or term >in >>>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC20 >03 >>>) MAY use transport mode. A gateway that originates or terminates packets tu >nn >>>eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow > t >>>he IPsec host requirements rather than the IPsec gateway requirements. >>> >>>>Permitting the use of transport mode in this context goes specifically to t >he >>> >>>interaction between IPsec and RFC2003 tunnels, making it a protocol issue ra >t >>>her than merely an implementation issue. >>> >>>>Joe >>>> >>>> >>>> From owner-ipsec@lists.tislabs.com Fri Oct 10 03:41:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AAffZA084301; Fri, 10 Oct 2003 03:41:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13386 Fri, 10 Oct 2003 05:56:06 -0400 (EDT) Message-Id: <5.1.0.14.2.20031010115536.02e287b8@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 Oct 2003 12:04:26 +0200 To: Tero Kivinen From: Eric Vyncke Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Cc: Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <16260.7900.891287.446736@ryijy.hel.fi.ssh.com> References: <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.2.0.9.0.20031007155701.02041dc8@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 10 Oct 2003 10:04:32.0973 (UTC) FILETIME=[E7092FD0:01C38F15] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, Regarding your point that SG should not trust the VPN-ID as received: this is for sure ;-) But, the VPN-ID can be used during the IKE_SA_INIT exchange in order for the SG to: - check whether to continue the IKE exchange (i.e. custA has a contract for max 10 'tunnels') - see what kind of security parameters to use (i.e. custA can enforce AES-256 for IKE or use only certs from this CA) - ... Then, during IKE_AUTH exchange, the SG will check whether the ID (as proven by the authentication) does indeed match the VPN-ID. On a side note: the VPN-ID as exchanged during IKE_SA_INIT could potentially be different to the one used by the PPVPN on 'the other side' of the SG. On another side note, the use of VPN-ID will be dictated most probably by an ISP/MSSP while the actual IKE ID will be selected by the customer. I'm afraid that forcing both parties to agree to a common naming for the ID (assuming that VPN-ID is rejected) will be a real pain in the real world... Hope it helps Just my 0.01 EUR -eric At 17:27 8/10/2003 +0300, Tero Kivinen wrote: >[Please when you send comments to list, use the issue number in the >subject, so it is easier for the others to search for other mails with >same issue]. > >Mark Duffy writes: >> > 68 VPNs with overlapping IP address ranges >> #68 (as I think you have acknowledged) consists of multiple parts, some of >> which are implementation issues but not all. Part of #68 involved a >> capability in the protocol: >> >> b. They MUST negotiate a VPN subscriber ID using IKE, as >> noted above, to enable forwarding of inbound IPsec >> traffic after crypto processing. > >I do not think there is any need to negotiate the VPN subscriber ID >between the parties. The VPN subscriber ID is internal to the SGW, and >it is not going to trust anything the other end sends. > >If I have understood correctly about the case it is something like >this: > > > > Corp A --------. +---- Client C > +-----+ | > | ISP |-----{ Internet } ----| > | SGW | | > +-----+ +---- Client D > Corp B --------' > > >Where the ISP SGW is acting as VPN GW for both corporation A and >corporation B, and the clients connect to it using IPsec through the >internet. Corporations A and B both use 10.0.0.0/8 network, and give >out IP address to the clients from the same range. Now when the client >C connects to the ISP SGW it authenticates itself as c@corp-a.com. The >ISP SGW will now link that authenticated identity to the VPN >Subscriber ID of Corp-A, and attach all packets coming from the client >C to that VPN ID. When it is sending them out it will send to Corp A >interface, because it is also attached to the Corp-A VPN ID. > >The ISP SGW will not be trusting client C to send him the VPN ID, as >if it would trust clinet C, the c@corp-a.com could send VPN ID of >corp-b instead and get access to the Corp B network. > >So only way to get those VPN-IDs is through the configuration based on >the authenticated ID of the client, thus there is no need to negotiate >them in IKE. > >This means that client C and D are normal IPsec clients, and they do >not have any special processing to be done. If Client C for some >reason wants (and is allowed) to be part of both Corp A and B >networks, then he can have two authenticated IKE identities >c@corp-a.com and c@corp-b.com. > >All the special processing of VPN IDs etc (or whatever local >processing the ISP SGW does) is inside the ISP SGW, thus it is purely >local implementation issue. > >> When a security Gateway is operating on behalf of multiple contexts (e.g. >> multiple subscribers, or multiple ppvpn-style overlay addressing contexts), >> it is essential that the initiator be able to convey to the responder which >> context is being addressed. > >Do not use IP addresses as a IKE SA identities then. Use the dns names >or email addresses or something else. There is no need to use ip >addresses in those cases (or actually using ip addresses would be >quite bad, as it is not unique...). > >> In the absence of a capability to signal this >> in IKE, the only full-functioned alternative is for the SGs to maintain a >> separate IP address to use for each supported context. This can waste a >> lot of addresses, and it isn't even as good anyway because it requires >> coordinated configuration on both ends to understand which IP address in >> each SG corresponds to which context. > >There is no need for that. > >> My conclusion: 2401bis should support the concept of multiple contexts >> supported in an IPsec device, and IKE should provide a means to convey the >> desired context in the initial exchange. > >I do not think this is general case that should be implemented in the >all IPsec stacks out there. It will be implemented as purely local >matter in some of the IPsec implementations, and there is no need to >have any kind of negotiation or changes to the IKE because of that. >-- >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 Oct 10 03:44:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AAiLZA084380; Fri, 10 Oct 2003 03:44:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13504 Fri, 10 Oct 2003 06:07:48 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16262.34491.235336.457244@ryijy.hel.fi.ssh.com> Date: Fri, 10 Oct 2003 13:15:23 +0300 From: Tero Kivinen To: Eric Vyncke Cc: Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <5.1.0.14.2.20031010115536.02e287b8@localhost> References: <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.1.0.14.2.20031010115536.02e287b8@localhost> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Vyncke writes: > Regarding your point that SG should not trust the VPN-ID as > received: this is for sure ;-) > > But, the VPN-ID can be used during the IKE_SA_INIT exchange in order > for the SG to: > - check whether to continue the IKE exchange (i.e. custA has a > contract for max 10 'tunnels') > - see what kind of security parameters to use (i.e. custA can > enforce AES-256 for IKE or use only certs from this CA) > - ... Now I am confused. Earlier I thought that VPN-ID was meant to be like a traffic selector, i.e that you could create one IKE SA and then for each IPsec SA you select which VPN-ID is used. You seem to be proposing that VPN-ID is more like the IKE authentication ID, i.e the identity of the other end. For that kind of use you need to have separate IKE SA for each VPN, and then the proper way to do that is use separate credentials and authentication ID per VPN. Adding VPN-ID as authentication ID propably would not be enough, as you propably also need to identify the remote end box also, not only the VPN where it belongs, thus you need VPN-ID and box id. Easiest thing for that is to use something like dns-name or email address and format that name so that it have VPN identifier part and box identifier part inside, and map those strings to the actual local VPN-ID through the configuration. > Then, during IKE_AUTH exchange, the SG will check whether the ID (as > proven by the authentication) does indeed match the VPN-ID. > > On a side note: the VPN-ID as exchanged during IKE_SA_INIT could > potentially be different to the one used by the PPVPN on 'the other > side' of the SG. > > On another side note, the use of VPN-ID will be dictated most > probably by an ISP/MSSP while the actual IKE ID will be selected by > the customer. I'm afraid that forcing both parties to agree to a > common naming for the ID (assuming that VPN-ID is rejected) will be > a real pain in the real world... I think both VPN ID and IKE ID will be selected by the ISP, as both of the boxes are controlled by ISP (unless there is yet another different scenario), thus format of the IKE ID will be completely local matter to the ISP. Anyways, I think this is something that is not for general IPsec use, but more specific case, thus I do not think we should include the current issue #68 in the RFC2401bis now. I think we can write new document to describe how to do that kind of things. Can we agree on that now? -- 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 Oct 10 06:23:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ADNiZA092843; Fri, 10 Oct 2003 06:23:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14950 Fri, 10 Oct 2003 08:36:04 -0400 (EDT) Message-Id: <200310091938.PAA06648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ipsec@lists.tislabs.com, multi6@ops.ietf.org, mip6@ietf.org, mip4@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nikander-esp-beet-mode-00.txt Date: Thu, 09 Oct 2003 15:38:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-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-nikander-esp-beet-mode-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-nikander-esp-beet-mode-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: <2003-10-9142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 10 07:59:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AExkZA096447; Fri, 10 Oct 2003 07:59:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15440 Fri, 10 Oct 2003 10:15:45 -0400 (EDT) Message-Id: <5.2.0.9.0.20031010100534.01fb8448@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Oct 2003 10:23:06 -0400 To: Tero Kivinen , Eric Vyncke From: Mark Duffy Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <16262.34491.235336.457244@ryijy.hel.fi.ssh.com> References: <5.1.0.14.2.20031010115536.02e287b8@localhost> <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.1.0.14.2.20031010115536.02e287b8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:15 PM 10/10/2003 +0300, Tero Kivinen wrote: >Now I am confused. Earlier I thought that VPN-ID was meant to be like >a traffic selector, i.e that you could create one IKE SA and then for >each IPsec SA you select which VPN-ID is used. You seem to be >proposing that VPN-ID is more like the IKE authentication ID, i.e the >identity of the other end. > >For that kind of use you need to have separate IKE SA for each VPN, >and then the proper way to do that is use separate credentials and >authentication ID per VPN. Some folks participating in this discussion are talking about binding VPN-IDs to child SAs and others are talking about binding VPN-IDs to IKE SAs. This is because people have different applications in mind and so they have different requirements. >Anyways, I think this is something that is not for general IPsec use, >but more specific case, thus I do not think we should include the >current issue #68 in the RFC2401bis now. I think we can write new >document to describe how to do that kind of things. > >Can we agree on that now? At this point I think that proponents of the VPN-ID signalling in IKE need to go off and write an I-D or I-Ds about extending IKEv2 to convey VPN-IDs. I would hope to see 2401bis written in such a way that it will accommodate use of such signalling. But, I don't know exactly what that means in terms of text in 2401bis. --Mark From owner-ipsec@lists.tislabs.com Fri Oct 10 08:03:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AF3sZA096596; Fri, 10 Oct 2003 08:03:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15492 Fri, 10 Oct 2003 10:25:57 -0400 (EDT) Message-Id: <5.1.0.14.2.20031009161624.02e13520@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Oct 2003 16:28:16 +0200 To: Joe Touch From: Eric Vyncke Subject: Re: 2401bis issues (possible) resolution Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <3F8329A2.60302@isi.edu> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 09 Oct 2003 14:28:22.0521 (UTC) FILETIME=[97C4C690:01C38E71] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:01 7/10/2003 -0700, Joe Touch wrote: >Angelos D. Keromytis wrote: > 50 Proposed change: tunnel vs. transport mode >>to 68). We invite one last round of comments on these items --- if you feel >>strongly, yell! Angelos, I'm yelling then ;-) Transport mode is heavily used today by security gateways in conjunction with another tunneling mechanism (the choice is yours -- the objective is to use a tunnel understood by the kernel to apply packet forwarding based on a FIB). When I write 'heavily', this means by dozens of organizations for their site to site VPN with 100 to 5000 nodes. All what is needed for such VPN is that both RFC 2401bis and IKEv2 allow the negotiation/SPD/SAD for transport mode between 2 SG. That's all. Regarding the security aspects of transport mode combined with another tunneling mechanism (like IPinIP or GRE or ...), the fact that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, dstPort=opaque) has a positive impact on the configuration of 100's of nodes. Security can anyway be provided by applying the SPD on the tunnel interface (which is just another interface where a security policy can obviously be enforced). NB: the text about 'link layer' encryption has much less importance for me. I know that this topic has been beaten to death on the mailing list. But, please allow transport mode between SG or better allow a SG to also act as a host (which is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email). Regards -eric >Item 50: > >The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway originate and/or terminate at that gateway, and as such, are hosts for the purposes of IPsec conformance (for that tunnel). Thus RFC2401 already permits the use of transport mode on this traffic. > >As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt > >We feel that it would be useful for RFC2401bis to make this distinction clear, esp. since 2401 currently suggests that transport mode support is not required at gateways, i.e. in Sec 4.1: > >> Whenever either end of a security association is a security gateway, >> the SA MUST be tunnel mode. > >It might be more specific to indicate that: > >For traffic originating or terminating at a gateway, that gateway MUST support the functions of an IPsec host. In particular, traffic originating or terminating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway that originates or terminates packets tunneled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow the IPsec host requirements rather than the IPsec gateway requirements. > >Permitting the use of transport mode in this context goes specifically to the interaction between IPsec and RFC2003 tunnels, making it a protocol issue rather than merely an implementation issue. > >Joe > > > From owner-ipsec@lists.tislabs.com Fri Oct 10 13:26:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AKQmZA008712; Fri, 10 Oct 2003 13:26:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17021 Fri, 10 Oct 2003 15:40:09 -0400 (EDT) Message-Id: <200310101939.PAA15827@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-11.txt Date: Fri, 10 Oct 2003 15:39:13 -0400 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 : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-11.txt Pages : 100 Date : 2003-10-10 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-11.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-11.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-11.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: <2003-10-10143310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10143310.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Sat Oct 11 07:45:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9BEjoZA012742; Sat, 11 Oct 2003 07:45:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21370 Sat, 11 Oct 2003 10:01:34 -0400 (EDT) To: Russ Housley cc: Barbara Fraser , "Theodore Ts'o" , "Angelos D. Keromytis" , kivinen@ssh.fi, Steve Bellovin , ipsec@lists.tislabs.com Subject: IKEv2 documents ready for IETF wide last call From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Sat, 11 Oct 2003 10:03:22 -0400 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Russ, It is with a certain amount of pleasure (and relief!) that Barbara and I send to you the following documents as being ready for IETF-wide last call: draft-ietf-ipsec-ikev2-11.txt draft-ietf-ipsec-ui-suites-04.txt draft-ietf-ipsec-ikev2-algorithms-04.txt We would appreciate it if you would put them in your queue for AD review, and update the IETF status tracker appropriately. Thanks must go to many people in the IPSEC working group, and there is a fuller set of acknowledgements in section 8 of the IKEv2 I-D, but I would especially like to recognize and thank: Charlie Kaufman, Paul Hoffman, and Jeff Schiller, the editors of the above drafts, as well as Angelos, Tero, Radia, Hugo, Hugh, Dan, and many, many others. We can see the light at the end of the tunnel, and I'm pretty sure it's not a short-range missile headed for Seoul. :-) Indeed, with any luck, we hope that we will be able to wrap up RFC 2401-bis up before the Spring 2004 IETF meeting in Korea. - Ted and Barbara From owner-ipsec@lists.tislabs.com Sat Oct 11 11:15:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9BIExI7019044; Sat, 11 Oct 2003 11:14:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22555 Sat, 11 Oct 2003 13:37:12 -0400 (EDT) Message-Id: <200310111737.h9BHbiHW009415@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Tero Kivinen Cc: Joe Touch , Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution In-reply-to: Your message of "Thu, 09 Oct 2003 21:27:18 +0300." <16261.43142.238298.551445@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Oct 2003 13:37:44 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Done. In message <16261.43142.238298.551445@ryijy.hel.fi.ssh.com>, Tero Kivinen write s: >Angelos D. Keromytis writes: >> Right --- the mods Joe suggested seem acceptable. > >I think we then should create new issue to issue tracker, with that >proposed text, so we can accept that and reject this? > >>> That is where 2401bis could be clarified, as per (e.g.) the mods I >>> suggested in that earlier post. > >>>> It might be more specific to indicate that: >>>> >>>> For traffic originating or terminating at a gateway, that gateway >>>> MUST support the functions of an IPsec host. In particular, >>>> traffic originating or terminating at that gateway that is >>>> tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use >>>> transport mode. A gateway that originates or terminates packets >>>> tunneled over non-IPsec mechanisms, for the purposes of that >>>> tunnel, MUST follow the IPsec host requirements rather than the >>>> IPsec gateway requirements. >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 06:52:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CDqwI7016399; Sun, 12 Oct 2003 06:52:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26156 Sun, 12 Oct 2003 08:58:53 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.20948.339588.413800@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 16:06:28 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #81: Handling outbound red fragments X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Issue 81 proposes new special SA for the outbound non-first red fragments. The Issue 49 (Proposed change: red-side fragmentation option) decided that RFC2401 WILL NOT be changed to support red side fragments as a special case. As we have already accepted issue 49 without comments, I think we should now reject 81 as it proposes the same thing (just specifies how it would be done). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 07:07:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CE7cI7016668; Sun, 12 Oct 2003 07:07:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26306 Sun, 12 Oct 2003 09:27:23 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.22660.635190.12819@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 16:35:00 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #47: Proposed change: all selectors can be a list of ranges, per IKEv2 spec and issue #69 X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 23 min X-Total-Time: 28 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The issue #47 change does not reflect the IKEv2 changes. The IKEv2 have traffic selectors as follows: - Each traffic selector payload is list of traffic selectors. - Each traffic selectors contains: - type of traffic selector - protocol id - port range - address range - There is 2 traffic selector payloads, one for the initiator and one for responder ends IKEv2 traffic selectors can express following selectors (from the clients point of view, i.e VPN client is initiator: TSi (initiator, from client) 10.2.4.11 - 10.2.4.11, any protocol, 0-65535 TSr (responder, from server) 10.0.0.0 - 10.255.255.255, any protocol, 0-65535 192.168.2.5-192.168.2.5, TCP, port 25-25 (smtp) 192.168.2.8-192.168.2.8, TCP, port 80-80 (web) 192.168.2.9-192.168.2.9, TCP, port 53-53 (dns) 192.168.2.9-192.168.2.9, UDP, port 53-53 (dns) 192.168.2.5-192.168.2.5, UDP, port 123-123 (ntp) I.e any traffic destioned to the client (configured with ip address 10.2.4.11) that originates either from the 10.0.0.0/8 network (other clients, rest of the machines etc), or from the specific machine, protocol and port range. For example it does not allow traffic from 192.168.2.5, UDP, port 25. If I understand correctly the issue #47 (Proposed change: all selectors can be a list of ranges, per IKEv2 spec) there is no way to propose that kind of thing in the SPD. The issue #47 allows to do From client 10.2.4.11 - 10.2.4.11, any protocol, 0-65535 From server 10.0.0.0-10.255.255.255, 192.168.2.5, 192.168.2.8, 192.168.2.9 any protocol port 25, 80, 53, or 123 I.e it does not allow restricting the port ranges to only specific ip addresses. In addition to that there is issue #69 (Multiple protocols per SPD entry), which tries to fix issue #47 little bit by adding multiple protocols to each SPD entry, i.e in the above we could say TCP and UDP protocols, but it actually would be incorrect as the original policy allowed any protocol from 10.0.0.0/8 network. The reason IKEv2 proposal syntax is good that because now IKEv2 allows responder to choose subset of the traffic selector proposed by the initiator. I.e the client can be configured to request TSi 0.0.0.0-255.255.255.255, any protocol, 0-65535 TSr 0.0.0.0-255.255.255.255, any protocol, 0-65535 and the server (VPN SGW) can then have the proper policy, i.e it will allocate ip number (10.2.4.11 above) to the client and select proper subset for the client to be used (i.e only allow access to the 10.0.0.0/8 network and to those few server network hosts). This all traffic will be using one single SA. To fix this we would need to change the issue #47 text so that SPD entry contains list of SPD entry items, and each SPD entry item contains one IP address range, one protocol, and one port range. The issue #69 then goes obsolete, thus there is no need to have multiple protocols per SPD entry item, as IKEv2 does not allow it, but there will be multiple protocols per SPD entry, as each SPD entry contains list of SPD entry items each having separate protocol. I should have noticed this earlier, but I noticed only when I was checking out the issue #69 and verifying that issue #47 was up to date to the IKEv2. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 07:10:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CEA7I7016709; Sun, 12 Oct 2003 07:10:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26342 Sun, 12 Oct 2003 09:33:05 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.23003.231716.961978@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 16:40:43 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #46 Proposed change: no need for iterated processing X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The msg130 says: ---------------------------------------------------------------------- Description: There is no mandate to support nested SAs or SA bundles. It would be easy to include support for the simple AH+ESP combination that IKEv1 was able to negotiate, and that 2401 mandates, if that combination is still viewed as needed. However, IKEv1 was not able to negotiate any other nested protocol combinations and IKEv2 does not support negotiation of SA bundles. ---------------------------------------------------------------------- Actually the IKEv2 can negotiate exactly same AH, ESP, AH+ESP combinations than IKEv1 (and also the IPcomp). The Security association payload contains list of proposal substructures, and each proposal substructure have protocol ID and proposal #, which indicate if this is "AND" or "OR" between the protocols. I do not know if that actually affects the text described in the issue 46 as it only changes the actual implementation issues, but there is way to negotiate AH+ESP in IKEv2 too... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 07:17:40 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CEHeI7016909; Sun, 12 Oct 2003 07:17:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26380 Sun, 12 Oct 2003 09:41:43 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.23520.804747.698373@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 16:49:20 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #67 IPsec management traffic X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree that this is implementation issue and I do not think this kind of things should be described too much in the RFC2401bis. The management traffic must be able to reach the machine, thus there must be somewhere be rule that allows that to pass. Whether that rule is in the fixed code (built-in SPD?) or in the actual SPD is completely implementation issue. Also note, that the definition of management traffic changes from time to time, depending on the configuration. In some cases where certificates are used the IKE might need to use LDAP or http to fetch certificates or CRLs, also it might need to do OCSP etc at the same time. Before the IKE might start it might need to do DHCP, DNS, SNMP, IPv6 Neighbor discover etc. As the list of management traffic is not fixed, and can change when adminstrator changes configuration that would suggest that this kind of configuration should be done through the adminstrator configurable SPD, and perhaps some document should simply list some of the protocols which might be needed for different configuration. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 07:33:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CEXCI7017597; Sun, 12 Oct 2003 07:33:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26522 Sun, 12 Oct 2003 09:57:34 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.24472.411484.876527@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 17:05:12 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #85 DROP'd inbound packet -- does not match SA X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been some discussion about this issue and I do not think we have reached concensus what to do with this issue. The problem is that we do not have the original encrypted packet when we want to send the ICMP, thus we need to re-encrypt the packet and then we end up trouble which SA to use and what the other end will do with the packet as it reaches it. One possible solution to this is not to use ICMP messages at all. Because this kind of solution can only happen when the other end is configured incorrectly or have bugs. If the SA is manual keyed SA there is nothing we can really do. If it is IKE negotiated SA we could find out the IKE SA tied to the SA (in IKEv2 this is easy, for IKEv1 it is harder, and the IKE SA might not be there anymore). If we find the IKE SA associated with the IPsec SA we could send IKE notification to the other end saying that received packet which was droped because of selector checks. This is identical to the INVALID_SPI notification currently in both IKEv1 and IKEv2. The IKE notifications have the SPI field, thus the other end can detect which IPsec SA is misconfigured, and they are authenticated, and in IKEv2 ack'ed. The notifications might also require rate limit, but it is not that important here, because nobody else than the other end can create authenticated packet which do not match selectors (to make selectors so that they do match requires changes to the protected part of the packet). The problem with this approach is that it requires new IKEv2 notification and IKEv2 draft should already be ready... We can postpone this to separate draft as it does not need to be in the base specification, or we can add following text to the IKEv2 draft: INVALID_SELECTORS XX MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet whose selectors do not match those of the SA on which it was delivered (and which caused the packet to be dropped). The Notification Data contains the start of the offending packet (as in ICMP messages) and the SPI field of the notification is set to match the SPI of the IPsec SA. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Oct 12 07:39:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9CEdHI7017824; Sun, 12 Oct 2003 07:39:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26574 Sun, 12 Oct 2003 10:01:57 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16265.24735.417145.48093@ryijy.hel.fi.ssh.com> Date: Sun, 12 Oct 2003 17:09:35 +0300 From: Tero Kivinen To: "Charlie Kaufman" CC: "Paul Hoffman / VPNC" , "Theodore Ts'o" , , , ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-11.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I was writing my previous mail to the list I noticed something I consider bug or typo in the draft-ietf-ipsec-ikev2-11.txt: ---------------------------------------------------------------------- INVALID_SPI 11 MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by the recipient as a "hint" that something might be wrong (because it could easily be forged). ---------------------------------------------------------------------- It says there that the Notification Data contains the SPI of the invalid packet. I think it should be using the SPI field of the notification instead of the notification data field (i.e change the "The Notification Data contains the SPI of the invalid packet." to "The SPI field contains the SPI of the invalid packet.", or simply remove the that text). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From bdan30@gte.net Sun Oct 12 13:36:50 2003 Received: from HDOSAYUSSHFUNFR ([210.124.54.220]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9CKanI7031090 for ; Sun, 12 Oct 2003 13:36:50 -0700 (PDT) (envelope-from bdan30@gte.net) Message-Id: <200310122036.h9CKanI7031090@above.proper.com> From: "melissa" To: "ietf-ipsec@imc.org" Subject: .. save a fortune! slash your health insurance costs! fdhsa7s9d8 Date: Mon, 13 Oct 2003 5:39:13 +0900 X-Priority: 3 (normal) Importance: Normal X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCg0KPGJvZHk+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNl PSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5Eb24ndCBnYW1ibGUgd2l0aCB5b3VyIGxp ZmUgaW5zdXJhbmNlITxicj48YnI+V2hlbiBvbmx5IHRoZSBoaWdoZXN0IHF1YWxpdHkgaW5zdXJh bmNlIHdpbGwgZG8hPGJyPjxicj5Eb24ndCBnZXQgcmlwcGVkIG9mZiBieSBkb2RneSBpbnN1cmFu Y2Ugc2hhcmtzISBIZWxwIHVzIGZpbmQgdGhlIGJlc3QgaW5zdXJhbmNlIHJhdGUgYW5kIHNhdmUg eW91IG1vbmV5Ljxicj48YnI+DQo8Zm9udCBzaXplPSIxIj5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn48YnI+DQpJZiB5b3UgZG8gbm90IHdpc2ggdG8gcmVj ZWl2ZSB0aGVzZSBvZmZlcnMgaW4gdGhlIGZ1dHVyZSw8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 MTk5LmdpYW50d2Vic29mdHdhcmUuY29tL2hpbnN1cmFuY2UvYWQvdGV4dDJfcmVtb3ZlIj5DbGlj ayBIZXJlPC9hPiB0byByZW1vdmUgeW91cnNlbGYgbm93PGJyPg0Kfn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PC9mb250Pjxicj4NCjwvZm9udD48L3A+DQo8 cD4mbmJzcDs8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= From owner-ipsec@lists.tislabs.com Mon Oct 13 07:56:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DEu8I7035561; Mon, 13 Oct 2003 07:56:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04904 Mon, 13 Oct 2003 10:01:44 -0400 (EDT) Message-Id: <5.2.0.9.2.20031013100937.04427998@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 13 Oct 2003 10:10:42 -0400 To: "Theodore Ts'o" From: Russ Housley Subject: Re: IKEv2 documents ready for IETF wide last call Cc: Barbara Fraser , "Theodore Ts'o" , "Angelos D. Keromytis" , kivinen@ssh.fi, Steve Bellovin , ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted: Thanks. I have updated the Data Tracker, indicating Proposed Standard for all three documents. Russ At 10:03 AM 10/11/2003 -0400, Theodore Ts'o wrote: >Hi Russ, > > It is with a certain amount of pleasure (and relief!) that >Barbara and I send to you the following documents as being ready for >IETF-wide last call: > > draft-ietf-ipsec-ikev2-11.txt > draft-ietf-ipsec-ui-suites-04.txt > draft-ietf-ipsec-ikev2-algorithms-04.txt > >We would appreciate it if you would put them in your queue for AD >review, and update the IETF status tracker appropriately. > >Thanks must go to many people in the IPSEC working group, and there is a >fuller set of acknowledgements in section 8 of the IKEv2 I-D, but I >would especially like to recognize and thank: Charlie Kaufman, Paul >Hoffman, and Jeff Schiller, the editors of the above drafts, as well as >Angelos, Tero, Radia, Hugo, Hugh, Dan, and many, many others. > >We can see the light at the end of the tunnel, and I'm pretty sure it's >not a short-range missile headed for Seoul. :-) Indeed, with any luck, >we hope that we will be able to wrap up RFC 2401-bis up before the >Spring 2004 IETF meeting in Korea. > > - Ted and Barbara From owner-ipsec@lists.tislabs.com Mon Oct 13 15:38:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DMcOI7052481; Mon, 13 Oct 2003 15:38:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07133 Mon, 13 Oct 2003 17:54:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F8329A2.60302@isi.edu> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <3F8329A2.60302@isi.edu> Date: Mon, 13 Oct 2003 18:02:08 -0400 To: Joe Touch From: Stephen Kent Subject: Re: 2401bis issues (possible) resolution Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, You are right that 2401 makes a clear distinction between SG and host implementations in terms of required mode to be supported. However it is not appropriate to require that an SG must also act like an IPsec host. We distinguish 4 types of IPsec implementation contexts: SG, BITW, BITS, and native host. the latter is special for several reasons, e.g., in that context it is reasonable to have access to the name of the target for an IPsec SA, as expressed by a user, whereas all other implementations can expect to have access only to addresses. As a result, the form of SPD entries that a host must support is broader than the form that an SG (or BITS/BITW) must support. So, if only for that reason, it would not be appropriate to make a broad assertion that SGs must also support the functions of an IPsec host. What we proposed to say is something like SGs MAY support transport mode, and MUST support tunnel mode, which would support the IP-in-IP or GRE tunneling over transport mode SAs, as well as 2401's mandated tunnel mode use. Steve From owner-ipsec@lists.tislabs.com Mon Oct 13 15:54:18 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DMsHI7052804; Mon, 13 Oct 2003 15:54:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07248 Mon, 13 Oct 2003 18:19:07 -0400 (EDT) Message-ID: <3F8B26EC.5020406@isi.edu> Date: Mon, 13 Oct 2003 15:27:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: 2401bis issues (possible) resolution References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <3F8329A2.60302@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > Joe, > > You are right that 2401 makes a clear distinction between SG and host > implementations in terms of required mode to be supported. However it > is not appropriate to require that an SG must also act like an IPsec host. > > We distinguish 4 types of IPsec implementation contexts: SG, BITW, BITS, > and native host. the latter is special for several reasons, e.g., in > that context it is reasonable to have access to the name of the target > for an IPsec SA, as expressed by a user, whereas all other > implementations can expect to have access only to addresses. As a > result, the form of SPD entries that a host must support is broader than > the form that an SG (or BITS/BITW) must support. So, if only for that > reason, it would not be appropriate to make a broad assertion that SGs > must also support the functions of an IPsec host. We define a host as a source or sink of packets. Other aspects - packet handling, etc., follow from this simple definition. This definition is certainly more terse than, e.g., sec 1.1.1 of RFC1122, but seems to be consistent as far as we have been able to discern. We're not sure whether this defintion affects the need for other aspects of IPsec 'host' support. That support may not be needed for gateway 'source or sink' services - e.g., mobile IP, multicast tunnels, GRE tunnels, IPIP tunnels, etc. But it would be needed if the gateway runs any IPsec transport-mode secured services that make it look like a traditional host (e.g., SNMP) But that's a completely different issue, one that the document is already sufficiently clear on. > What we proposed to say is something like SGs MAY support transport > mode, and MUST support tunnel mode, which would support the IP-in-IP or > GRE tunneling over transport mode SAs, as well as 2401's mandated tunnel > mode use. The commas in this are ambiguous. Is the following consistent with what you mean? SGs MAY support transport mode, and MUST support tunnel mode. Transport mode would support IP-in-IP or GRE tunneling over transport mode SAs. Given that IP-in-IP is proposed standard and is used both for mobile IP and multicast, we still feel a SG MUST (or at least SHOULD) implement transport mode, though we appreciate that it might not be a full 'host' in other respects. Joe From owner-ipsec@lists.tislabs.com Tue Oct 14 01:06:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E86KI7007871; Tue, 14 Oct 2003 01:06:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10361 Tue, 14 Oct 2003 03:20:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 14 Oct 2003 03:32:38 -0400 To: Tylor Allison From: Karen Seo Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets Cc: ipsec mailingList , , , "Angelos D. Keromytis" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tylor, >On Tue, 30 Sep 2003, Karen Seo wrote: > >> Tylor, >> >> Quoting some earlier text from Steve K.... >> >> "Dummy packets can be inserted at random intervals to mask the >> absence of actual traffic. One can also "shape" the actual traffic to >> match some distribution to which dummy traffic is added as dictated >> by the distribution parameters. As with the packet length padding >> facility for TFS, the most secure approach would be to generate dummy >> packets at whatever rate is needed to maintain a constant rate on an >> SA. If packets are all the same size, then the SA presents the >> appearance of a constant bit rate data stream, analogous to what a >> link crypto would offer at layer 1/2. However, this is unlikely to >> be practical in many contexts, e.g., when there are multiple SAs >> active, because it would imply reducing the allowed bandwidth for a >> site, based on the number of SAs, and that would undermine the >> benefits of packet switching. How dummy packet insertion is handled >> SHOULD not be an implementation decision, however, but rather a >> parameter under control of the local administration." >> >> We could amend the last sentence of the proposed text as follows >> >> "For example, the controls might allow an administrator to generate >> random or fixed length dummy packets, or to pad real packets to >> random or fixed lengths, or to control the insertion timing of the >> dummy packets." >> >> Would that address your concerns? >> >> Thank you, >> Karen > >Could we not add something similar to Steve's text somewhere? It gives >justification and reasoning behind both the packet padding and dummy packet >generation. Perhaps this doesn't belong in the architecture document... >but it would be nice to have somewhere. Just reading through the ESPv3 >draft, you don't have enough info to implement, without making assumptions as >to what is really wanted. > I didn't see any further comments, so yes, I'll put this text in somewhere. Thank you, Karen From owner-ipsec@lists.tislabs.com Tue Oct 14 06:27:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EDR6I7046526; Tue, 14 Oct 2003 06:27:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11951 Tue, 14 Oct 2003 08:44:45 -0400 (EDT) Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) From: Jean-Francois Dive Reply-To: jef@linuxbe.org To: Eric Vyncke Cc: Tero Kivinen , Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20031010115536.02e287b8@localhost> References: <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.2.0.9.0.20031007155701.02041dc8@email> <5.1.0.14.2.20031010115536.02e287b8@localhost> Content-Type: text/plain Message-Id: <1066135916.1044.74.camel@gardafou> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 14 Oct 2003 14:51:56 +0200 Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (august.skynet.be) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I believe 2 issues are discussed here and a new point that may have not been discussed already (at least that i didn't saw in the mailing list archive, please point me to the conclustions if i'am wrong). - The addition of another ID field type in the selector for SG-SG multi-customer environment: I just want to point the fact that IKEv1 has that kind of facility as far as i can tell, no one support such usage so far. As ID payload, for exemple ID type keyid, value "[customer1]blue" could have achieved such thing, even though no traffic selector could be passed. I believe that agreement on the format of such ID as much as all the possible case of utilisation should stay outside of the standard, but allowing a variable len field instead of a selector payload could be used by some implementors or be left to other working groups. On the other hand, as already mentioned, the same functionality could be achieved using multiple 'sessions (init-auth-child-child-...)', one per customer which sounds better to me as you add authentication on top of it. - The other point which i think is very important is what Eric mention as an Id in the fist exchange. This is a big reason why people do use aggressive mode with IKEv1. Without any other way of an exchange than by IP address, protection suite for 'phase1' are biased and hard to implement, this is the whole problem of responder profile/template matching when a new exchange is received. I do understand that customer wants identity protection, but we could again add a marker and leave authentication where it is. JeF. On Fri, 2003-10-10 at 12:04, Eric Vyncke wrote: > Tero, > > Regarding your point that SG should not trust the VPN-ID as received: this is for sure ;-) > > But, the VPN-ID can be used during the IKE_SA_INIT exchange in order for the SG to: > - check whether to continue the IKE exchange (i.e. custA has a contract for max 10 'tunnels') > - see what kind of security parameters to use (i.e. custA can enforce AES-256 for IKE or use only certs from this CA) > - ... > > Then, during IKE_AUTH exchange, the SG will check whether the ID (as proven by the authentication) does indeed match the VPN-ID. > > On a side note: the VPN-ID as exchanged during IKE_SA_INIT could potentially be different to the one used by the PPVPN on 'the other side' of the SG. > > On another side note, the use of VPN-ID will be dictated most probably by an ISP/MSSP while the actual IKE ID will be selected by the customer. I'm afraid that forcing both parties to agree to a common naming for the ID (assuming that VPN-ID is rejected) will be a real pain in the real world... > > Hope it helps > > Just my 0.01 EUR > > -eric > > > At 17:27 8/10/2003 +0300, Tero Kivinen wrote: > >[Please when you send comments to list, use the issue number in the > >subject, so it is easier for the others to search for other mails with > >same issue]. > > > >Mark Duffy writes: > >> > 68 VPNs with overlapping IP address ranges > >> #68 (as I think you have acknowledged) consists of multiple parts, some of > >> which are implementation issues but not all. Part of #68 involved a > >> capability in the protocol: > >> > >> b. They MUST negotiate a VPN subscriber ID using IKE, as > >> noted above, to enable forwarding of inbound IPsec > >> traffic after crypto processing. > > > >I do not think there is any need to negotiate the VPN subscriber ID > >between the parties. The VPN subscriber ID is internal to the SGW, and > >it is not going to trust anything the other end sends. > > > >If I have understood correctly about the case it is something like > >this: > > > > > > > > Corp A --------. +---- Client C > > +-----+ | > > | ISP |-----{ Internet } ----| > > | SGW | | > > +-----+ +---- Client D > > Corp B --------' > > > > > >Where the ISP SGW is acting as VPN GW for both corporation A and > >corporation B, and the clients connect to it using IPsec through the > >internet. Corporations A and B both use 10.0.0.0/8 network, and give > >out IP address to the clients from the same range. Now when the client > >C connects to the ISP SGW it authenticates itself as c@corp-a.com. The > >ISP SGW will now link that authenticated identity to the VPN > >Subscriber ID of Corp-A, and attach all packets coming from the client > >C to that VPN ID. When it is sending them out it will send to Corp A > >interface, because it is also attached to the Corp-A VPN ID. > > > >The ISP SGW will not be trusting client C to send him the VPN ID, as > >if it would trust clinet C, the c@corp-a.com could send VPN ID of > >corp-b instead and get access to the Corp B network. > > > >So only way to get those VPN-IDs is through the configuration based on > >the authenticated ID of the client, thus there is no need to negotiate > >them in IKE. > > > >This means that client C and D are normal IPsec clients, and they do > >not have any special processing to be done. If Client C for some > >reason wants (and is allowed) to be part of both Corp A and B > >networks, then he can have two authenticated IKE identities > >c@corp-a.com and c@corp-b.com. > > > >All the special processing of VPN IDs etc (or whatever local > >processing the ISP SGW does) is inside the ISP SGW, thus it is purely > >local implementation issue. > > > >> When a security Gateway is operating on behalf of multiple contexts (e.g. > >> multiple subscribers, or multiple ppvpn-style overlay addressing contexts), > >> it is essential that the initiator be able to convey to the responder which > >> context is being addressed. > > > >Do not use IP addresses as a IKE SA identities then. Use the dns names > >or email addresses or something else. There is no need to use ip > >addresses in those cases (or actually using ip addresses would be > >quite bad, as it is not unique...). > > > >> In the absence of a capability to signal this > >> in IKE, the only full-functioned alternative is for the SGs to maintain a > >> separate IP address to use for each supported context. This can waste a > >> lot of addresses, and it isn't even as good anyway because it requires > >> coordinated configuration on both ends to understand which IP address in > >> each SG corresponds to which context. > > > >There is no need for that. > > > >> My conclusion: 2401bis should support the concept of multiple contexts > >> supported in an IPsec device, and IKE should provide a means to convey the > >> desired context in the initial exchange. > > > >I do not think this is general case that should be implemented in the > >all IPsec stacks out there. It will be implemented as purely local > >matter in some of the IPsec implementations, and there is no need to > >have any kind of negotiation or changes to the IKE because of that. > >-- > >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 Oct 14 07:26:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EEQNI7049587; Tue, 14 Oct 2003 07:26:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12259 Tue, 14 Oct 2003 09:38:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F8B26EC.5020406@isi.edu> References: <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <3F8329A2.60302@isi.edu> <3F8B26EC.5020406@isi.edu> Date: Tue, 14 Oct 2003 09:44:16 -0400 To: Joe Touch From: Stephen Kent Subject: Re: 2401bis issues (possible) resolution Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:27 -0700 10/13/03, Joe Touch wrote: >Stephen Kent wrote: > >>Joe, >> >>You are right that 2401 makes a clear distinction between SG and >>host implementations in terms of required mode to be supported. >>However it is not appropriate to require that an SG must also act >>like an IPsec host. >> >>We distinguish 4 types of IPsec implementation contexts: SG, BITW, >>BITS, and native host. the latter is special for several reasons, >>e.g., in that context it is reasonable to have access to the name >>of the target for an IPsec SA, as expressed by a user, whereas all >>other implementations can expect to have access only to addresses. >>As a result, the form of SPD entries that a host must support is >>broader than the form that an SG (or BITS/BITW) must support. So, >>if only for that reason, it would not be appropriate to make a >>broad assertion that SGs must also support the functions of an >>IPsec host. > >We define a host as a source or sink of packets. Other aspects - >packet handling, etc., follow from this simple definition. This >definition is certainly more terse than, e.g., sec 1.1.1 of RFC1122, >but seems to be consistent as far as we have been able to discern. For IPsec we define hosts are ultimate source and sinks of packets, which is not quite the same. Security gateways are intermediary devices, typically fronting for a set of hosts on a LAN or enterprise net. A bump in the wire (BITW) is a self-contained implementation, typically serving one device (host or router) located on an interface between that device and a network. the bump in the stack (BITS) implementation option is a retrofit approach to adding IPsec to a host, where the OS does not offer IPsec natively. >We're not sure whether this defintion affects the need for other >aspects of IPsec 'host' support. That support may not be needed for >gateway 'source or sink' services - e.g., mobile IP, multicast >tunnels, GRE tunnels, IPIP tunnels, etc. But it would be needed if >the gateway runs any IPsec transport-mode secured services that make >it look like a traditional host (e.g., SNMP) But that's a completely >different issue, one that the document is already sufficiently clear >on. OK. > >>What we proposed to say is something like SGs MAY support transport >>mode, and MUST support tunnel mode, which would support the >>IP-in-IP or GRE tunneling over transport mode SAs, as well as >>2401's mandated tunnel mode use. > >The commas in this are ambiguous. Is the following consistent with >what you mean? > > SGs MAY support transport mode, and MUST support tunnel mode. > Transport mode would support IP-in-IP or GRE tunneling > over transport mode SAs. > >Given that IP-in-IP is proposed standard and is used both for mobile >IP and multicast, we still feel a SG MUST (or at least SHOULD) >implement transport mode, though we appreciate that it might not be >a full 'host' in other respects. Your indented text matches my intent. I'll leave it to the list to decide whether the transport mode support ought to be a MUST, a MAY, or a SHOULD. Steve From owner-ipsec@lists.tislabs.com Tue Oct 14 08:41:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFf1I7052880; Tue, 14 Oct 2003 08:41:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12683 Tue, 14 Oct 2003 10:53:49 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.4038.978848.57069@ryijy.hel.fi.ssh.com> Date: Tue, 14 Oct 2003 18:01:26 +0300 From: Tero Kivinen To: jef@linuxbe.org Cc: Eric Vyncke , Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <1066135916.1044.74.camel@gardafou> References: <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.1.0.14.2.20031010115536.02e287b8@localhost> <1066135916.1044.74.camel@gardafou> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jean-Francois Dive writes: > - The other point which i think is very important is what Eric mention > as an Id in the fist exchange. This is a big reason why people do use > aggressive mode with IKEv1. Without any other way of an exchange than by > IP address, protection suite for 'phase1' are biased and hard to > implement, this is the whole problem of responder profile/template > matching when a new exchange is received. I do understand that customer > wants identity protection, but we could again add a marker and leave > authentication where it is. The question there is, "do you really have different phase 1 protections?". I think most of the cases the phase 1 protection is irrelevant, as long as it is strong enough. Also there is no reason to accept too weak phase 1 protection for anybody. Also the amount of data encrypted etc is so small that it does not matter if what the algorithm is. With current IKEv2 document you can select the phase 2 algorithms based on the identity of the initiator and also based on information to whom the initiator wants to talk (i.e initiator can send responder ID to whom he wants to talk before the responder selects the algorithms. I think this is enough. I do not see any good reason for the policy that for the user X use 3DES and 3DES only for phase 1 protection and for user Y use AES to encrypt phase 1 traffic. I would think the policy would define that use the strongest one proposed by the other end. Note, that the main reason for the aggressive mode in the IKEv1 was the use of preshared keys tied to the identity of the other end, not the selection of phase 1 algorithms based on the identity. The main mode didn't allow selecting of the pre-shared key based on the identity, thus vendors were forced to use aggressived mode which sent identity in clear thus allowed seeing the identity before selecting the pre-shared keys. The IKEv2 does not tie pre-shared keys to the phase 1 encryption keys, thus the implementation can decrypt the IKE_AUTH message and see the identity before verifying and generating the AUTH payloads using the pre-shared key. -- 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 Oct 14 08:47:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFlFI7053095; Tue, 14 Oct 2003 08:47:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12802 Tue, 14 Oct 2003 11:08:48 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.4940.840960.203497@ryijy.hel.fi.ssh.com> Date: Tue, 14 Oct 2003 18:16:28 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" Subject: Issue #86: Add IPv6 mobility header message type as selector X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This issue have received some support in the list, so I think it can be accepted for the RFC2401 part. The problem now is what to do with the IKEv2 part of this. If we add the support for mobility header as selector to the RFC2401 we might want to have some mechanism to negotiate the that in IKE, and current we do not have any text for it. I do not want to see the IKEv2 draft delayed because of that, so I think the best way would be to write separate draft that will describe how to negotiate mobility headers in the IKEv2. The current changes in the RFC2401 is quite small (if I understand them correctly), thus that could go in now. Or perhaps this should be part of the IKEv2 mobility/roaming/multihoming etc work? What do others think? The proposed approach from the issue #86 is: ---------------------------------------------------------------------- 1. Change "upper layer protocol" to "next layer protocol". (We made this change to AH and ESP previously.) 2. Add the mobility header as another possible "next layer" protocol 3. Add mobility header type (MH Type) to the list of selectors supported in the SPD and in IKEv2. 4. The processing text stays the same. -- 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 Oct 14 08:58:19 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFwJI7053555; Tue, 14 Oct 2003 08:58:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12854 Tue, 14 Oct 2003 11:15:31 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> Date: Tue, 14 Oct 2003 18:23:10 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo , Stephen Kent Subject: Issue #82: Creation of SAs -- clarifications X-Mailer: VM 7.07 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 Parsing this text took quite a long time for me. I finally think I managed to understand what it is trying to say, but I think the actual text added to the final document must explain the things more clearly. So my understanding of the issue is that this changes the text which says that we can create SAs selectors based on the packet or based on the SPD to text which says that we can create SA selectors based on the packet or based on the SPD, or something between. I.e in addition to only take selectors from the packet implementations are allowed to expand them towards to the SPD selectors as much as they like. Orginal case a) allowed only very specific SA selectors based on the packet itself. The original case b) takes the SA selectors from the SPD. The current IKEv2 approach is that we take the selectors from the packet and select the SPD which matches to them and then create SA that is either that SPD or any subset of it, as long as the packet itself fits to that subset. Is my understanding correct? If so, I think we can approve this change, but we do need better wording for the actual text. It took quite a lot of parsing and thinking while trying to understand what the proposed text actually says... -- 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 Oct 14 09:06:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EG6TI7053918; Tue, 14 Oct 2003 09:06:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12923 Tue, 14 Oct 2003 11:27:11 -0400 (EDT) Message-Id: <5.1.0.14.2.20031014172031.02fe53b8@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Oct 2003 17:35:20 +0200 To: Tero Kivinen From: Eric Vyncke Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) Cc: jef@linuxbe.org, Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com In-Reply-To: <16268.4038.978848.57069@ryijy.hel.fi.ssh.com> References: <1066135916.1044.74.camel@gardafou> <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.1.0.14.2.20031010115536.02e287b8@localhost> <1066135916.1044.74.camel@gardafou> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Oct 2003 15:36:10.0193 (UTC) FILETIME=[E45B0410:01C39268] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero See in-line At 18:01 14/10/2003 +0300, Tero Kivinen wrote: >Jean-Francois Dive writes: >> - The other point which i think is very important is what Eric mention >> as an Id in the fist exchange. This is a big reason why people do use >> aggressive mode with IKEv1. Without any other way of an exchange than by >> IP address, protection suite for 'phase1' are biased and hard to >> implement, this is the whole problem of responder profile/template >> matching when a new exchange is received. I do understand that customer >> wants identity protection, but we could again add a marker and leave >> authentication where it is. > >The question there is, "do you really have different phase 1 >protections?". I think most of the cases the phase 1 protection is >irrelevant, as long as it is strong enough. Also there is no reason to >accept too weak phase 1 protection for anybody. Also the amount of >data encrypted etc is so small that it does not matter if what the >algorithm is. It is not only about negotiation of phase 1 protection, it can also be: - for a shared SG: a hard limit on the number of IKE SA per customer - selection of the right CA to send CERT_REQ (again in the case of a shared SG with dozens or more customers each with its own CA) >With current IKEv2 document you can select the phase 2 algorithms >based on the identity of the initiator and also based on information >to whom the initiator wants to talk (i.e initiator can send responder >ID to whom he wants to talk before the responder selects the >algorithms. > >I think this is enough. I do not see any good reason for the policy >that for the user X use 3DES and 3DES only for phase 1 protection and >for user Y use AES to encrypt phase 1 traffic. Agreed on this one, but, again there could be some corner cases; and having worked with a lot of customers, I can guarantee you that there are always weird ones requesting weird stuff. >I would think the policy would define that use the strongest one >proposed by the other end. > >Note, that the main reason for the aggressive mode in the IKEv1 was >the use of preshared keys tied to the identity of the other end, not >the selection of phase 1 algorithms based on the identity. The main >mode didn't allow selecting of the pre-shared key based on the >identity, thus vendors were forced to use aggressived mode which >sent identity in clear thus allowed seeing the identity before >selecting the pre-shared keys. This was indeed the main reason why IKEv1 is like it is. But, other people re-used this 'feature' to do other services with it (like the ones described above). And, it would be really useful to keep the same services with IKEv2. >The IKEv2 does not tie pre-shared keys to the phase 1 encryption keys, >thus the implementation can decrypt the IKE_AUTH message and see the >identity before verifying and generating the AUTH payloads using the >pre-shared key. And, this is really a Good Thing (tm). Just my 0,01 EUR -eric From owner-ipsec@lists.tislabs.com Tue Oct 14 10:09:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EH9bI7056713; Tue, 14 Oct 2003 10:09:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13531 Tue, 14 Oct 2003 12:24:41 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.9489.168611.354554@ryijy.hel.fi.ssh.com> Date: Tue, 14 Oct 2003 19:32:17 +0300 From: Tero Kivinen To: Eric Vyncke Cc: jef@linuxbe.org, Mark Duffy , "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-Reply-To: <5.1.0.14.2.20031014172031.02fe53b8@localhost> References: <1066135916.1044.74.camel@gardafou> <5.2.0.9.0.20031007155701.02041dc8@email> <200310071738.h97HclHW002907@coredump.cs.columbia.edu> <5.1.0.14.2.20031010115536.02e287b8@localhost> <5.1.0.14.2.20031014172031.02fe53b8@localhost> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 31 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Vyncke writes: > It is not only about negotiation of phase 1 protection, it can also be: > - for a shared SG: a hard limit on the number of IKE SA per customer This should be done only after the authentication, as only after then you really know who the other end is. > - selection of the right CA to send CERT_REQ (again in the case of a > shared SG with dozens or more customers each with its own CA) Send multiple certificate requests, i.e for each CA there are, or simply leave out the certificate requests, and assume that you either have the certificate, or that the client is configured to send you the certificate anyways. > This was indeed the main reason why IKEv1 is like it is. But, other > people re-used this 'feature' to do other services with it (like > the ones described above). > > And, it would be really useful to keep the same services with > IKEv2. I think the best way to solve that kind of 'features' is to use something like proprietary notification or something similar if you cannot do it by the normal rules. I most of those cases there are ways to get over with the problems by just doing little extra work. I.e when you initially respond to the IKE SA you guess some policy and use it. When you see the identity you verify your guess. If the guess was incorrect you abort the negotiation, and request other end to restart it, and mark it in your internal table that this IP address should use this guess next time for next n minutes. Then when the initiator restarts you select this different policy guess, and use that instead. So all of these are doable, they might just need some extra work. -- 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 Oct 14 10:16:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHGII7057070; Tue, 14 Oct 2003 10:16:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13625 Tue, 14 Oct 2003 12:35:33 -0400 (EDT) Message-Id: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: 2401bis issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 12:32:31 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here's the status of current 2401bis issues, and the resolution for a few of them: Rejected Issue 40 ("Interface SPD selector vs. per-interface SPD") Rationale: This seems like an implementation issue, which won't affect interoperability. Issues 44 ("forwarding table lookup to select virtual interface ID") and 45 ("use of cache with de-correlated SPD") are still open, waiting for 2401bis draft. Rejected issue 67 ("IPsec management traffic") Rationale: Implementation issue; we may want to add a paragraph describing the kinds of traffic an implementation may want to make sure are not affected by the SPD (e.g., IPv6 neighbor discovery, IKE), as a note to implementors. Issue 68: see follow-on email Rejected Issue 69 ("Multiple protocols per SPD entry") Rationale: This is covered by issue 47 ("all selectors can be a list of ranges, per IKEv2 spec"). Accepted issue 74 ("inbound SA lookup -- multicast & unicast") Issue 81 ("Handling outbound red fragments"): marked as possible reject Rationale: since we decided not to adopt issue 49 ("red-side fragmentation option"), it doesn't make much sense to treat red fragments in this way. Yell if you disagree. Issues 82 ("Creation of SAs - clarifications") 85 ("DROP'd inbound packet - does not match SA") need more discussion; our feeling for 85 is that it would be best done through an IKE notification. Accepted issue 86 ("Add IPv6 mobility header message type as selector") Issue 87 ("Permit SGs to use transport mode when they are the endpoints of the communication") will likely be accepted. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 10:16:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHGWI7057087; Tue, 14 Oct 2003 10:16:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13619 Tue, 14 Oct 2003 12:35:20 -0400 (EDT) Message-Id: <200310141633.h9EGXbCI009581@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: 2401bis issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 12:33:37 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here's the status of current 2401bis issues, and the resolution for a few of them: Rejected Issue 40 ("Interface SPD selector vs. per-interface SPD") Rationale: This seems like an implementation issue, which won't affect interoperability. Issues 44 ("forwarding table lookup to select virtual interface ID") and 45 ("use of cache with de-correlated SPD") are still open, waiting for 2401bis draft. Rejected issue 67 ("IPsec management traffic") Rationale: Implementation issue; we may want to add a paragraph describing the kinds of traffic an implementation may want to make sure are not affected by the SPD (e.g., IPv6 neighbor discovery, IKE), as a note to implementors. Issue 68: see follow-on email Rejected Issue 69 ("Multiple protocols per SPD entry") Rationale: This is covered by issue 47 ("all selectors can be a list of ranges, per IKEv2 spec"). Accepted issue 74 ("inbound SA lookup -- multicast & unicast") Issue 81 ("Handling outbound red fragments"): marked as possible reject Rationale: since we decided not to adopt issue 49 ("red-side fragmentation option"), it doesn't make much sense to treat red fragments in this way. Yell if you disagree. Issues 82 ("Creation of SAs - clarifications") 85 ("DROP'd inbound packet - does not match SA") need more discussion; our feeling for 85 is that it would be best done through an IKE notification. Accepted issue 86 ("Add IPv6 mobility header message type as selector") Issue 87 ("Permit SGs to use transport mode when they are the endpoints of the communication") will likely be accepted. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 10:37:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHbpI7057680; Tue, 14 Oct 2003 10:37:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13847 Tue, 14 Oct 2003 12:55:37 -0400 (EDT) Message-Id: <200310141655.h9EGtpCI004728@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Issue 68 ("VPNs with overlapping IP address ranges") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 12:55:51 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We discussed this issue in our weekly telecon...it appears that there are two separate, but connected issues here: a) Some kind of IKE notification to inform the SG which subscriber the initiator wants to talk to; this is something that should be resolved in IKEv2, most likely as an additional document. b) Support in the IPsec stack (meaning 2401bis text) for the notion of different subscribers. This part is applicable to 2401bis and thus to this issue. How it is implemented should be left to the individual implementations. There may be some merrit in including a paragraph in 2401bis mentioning the issue; so: We solicit 1 paragraph describing the issue and the possibilities for implementing it, to be included in 2401bis. If such a paragraph does not materialize in a week (by our next telecon), we will simply drop the issue. Cheers, -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 10:56:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EHu0I7058137; Tue, 14 Oct 2003 10:56:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14008 Tue, 14 Oct 2003 13:14:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200310141655.h9EGtpCI004728@coredump.cs.columbia.edu> References: <200310141655.h9EGtpCI004728@coredump.cs.columbia.edu> Date: Tue, 14 Oct 2003 13:18:56 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:55 -0400 10/14/03, Angelos D. Keromytis wrote: >We discussed this issue in our weekly telecon...it appears that there are two >separate, but connected issues here: > >a) Some kind of IKE notification to inform the SG which subscriber the >initiator > wants to talk to; this is something that should be resolved in IKEv2, most > likely as an additional document. > >b) Support in the IPsec stack (meaning 2401bis text) for the notion of >different > subscribers. This part is applicable to 2401bis and thus to this issue. How > it is implemented should be left to the individual implementations. There > may be some merrit in including a paragraph in 2401bis mentioning >the issue; > so: > > We solicit 1 paragraph describing the issue and the possibilities for > implementing it, to be included in 2401bis. If such a paragraph does not > materialize in a week (by our next telecon), we will simply drop >the issue. > >Cheers, >-Angelos I just returned from a 2 week trip and am catching up on mail, lots of mail ... Still, I am a bit concerned by this characterization. Having looked at the traffic on this issue, I did not see a clear description of how two implementations would signal the necessary info in a standard fashion. So I think that topic 1, the IKEv2 extension, will be critical. As for item 2 above, we think it is appropriate to discuss this issue and I thought we had proposed text to that effect. That text noted that it was a local matter as to how one took traffic from multiple subscribers and mapped it to the right SPD, but one has to discuss this as part of the overall processing model, to ensure that the model is clear and as comp;lete as possible. Steve From owner-ipsec@lists.tislabs.com Tue Oct 14 11:07:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EI78I7058462; Tue, 14 Oct 2003 11:07:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14129 Tue, 14 Oct 2003 13:23:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> References: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> Date: Tue, 14 Oct 2003 13:28:32 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: 2401bis issues Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:32 -0400 10/14/03, Angelos D. Keromytis wrote: >Here's the status of current 2401bis issues, and the resolution for a few of >them: > >Rejected Issue 40 ("Interface SPD selector vs. per-interface SPD") >Rationale: This seems like an implementation issue, which won't affect > interoperability. I agree that this is not an interoperability issue, but 2401 established a per-interface SPD requirement and I think we now have heard from various folks that this is unduly restrictive. So as part of the revised processing model we need to remove the old, 2401 restriction and explain what the new model does and why. > >Issues 44 ("forwarding table lookup to select virtual interface ID") and > 45 ("use of cache with de-correlated SPD") >are still open, waiting for 2401bis draft. this will also be covered i the revised model. > >Rejected issue 67 ("IPsec management traffic") >Rationale: Implementation issue; we may want to add a paragraph describing the > kinds of traffic an implementation may want to make sure are not > affected by the SPD (e.g., IPv6 neighbor discovery, IKE), as a > note to implementors. OK. >Issue 68: see follow-on email > >Rejected Issue 69 ("Multiple protocols per SPD entry") >Rationale: This is covered by > issue 47 ("all selectors can be a list of ranges, per IKEv2 spec"). Tero has pointed out in some private e-mail that this characterization in quotes is not quite right, i.e., IKEv2 does not work this way! So, we are revising the characterization accordingly. The bottom line is that one can accommodate multiple protocols in a single SPD entry, because the entry really consists of a list of selector sets, each set contains S/D IP address range, ONE protocol (or ANY), and S/D port range. The "list of ranges" effect is achieved in that fashion. > >Accepted issue 74 ("inbound SA lookup -- multicast & unicast") > >Issue 81 ("Handling outbound red fragments"): marked as possible reject >Rationale: since we decided not to adopt issue 49 ("red-side fragmentation > option"), it doesn't make much sense to treat red fragments in this > way. Yell if you disagree. > >Issues 82 ("Creation of SAs - clarifications") > 85 ("DROP'd inbound packet - does not match SA") > need more discussion; our feeling for 85 is that it would be best >done through > an IKE notification. > >Accepted issue 86 ("Add IPv6 mobility header message type as selector") > >Issue 87 ("Permit SGs to use transport mode when they are the >endpoints of the communication") will likely be accepted. Yes, as refined in the message exchange with Joe over the last 24 hours. Steve From owner-ipsec@lists.tislabs.com Tue Oct 14 11:33:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIXLI7059364; Tue, 14 Oct 2003 11:33:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14459 Tue, 14 Oct 2003 13:48:38 -0400 (EDT) Message-ID: <3F8C3910.4070907@americasm06.nt.com> Date: Tue, 14 Oct 2003 13:57:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: charliek@microsoft.com, ipsec@lists.tislabs.com Subject: IKEv2 Correction (editorial) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In Section 3.3.2, Figure 8 of ikev2-11, the second RESERVED field should be 2 octets in length. The description below should say something like: RESERVED2 - MUST be sent as zero; MUST be ignored on receipt. thanks, Lakshminath From owner-ipsec@lists.tislabs.com Tue Oct 14 11:40:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EIeMI7059564; Tue, 14 Oct 2003 11:40:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14669 Tue, 14 Oct 2003 14:00:48 -0400 (EDT) Message-Id: <200310141800.h9EI0aCI018740@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: 2401bis issues In-reply-to: Your message of "Tue, 14 Oct 2003 13:28:32 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 14:00:36 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: > >I agree that this is not an interoperability issue, but 2401 >established a per-interface SPD requirement and I think we now have >heard from various folks that this is unduly restrictive. So as part >of the revised processing model >we need to remove the old, 2401 restriction and explain what the new >model does and why. I agree on removing the limitation. >Tero has pointed out in some private e-mail that this >characterization in quotes is not quite right, i.e., IKEv2 does not >work this way! So, we are revising the characterization accordingly. >The bottom line is that one can accommodate multiple protocols in a >single SPD entry, because the entry really consists of a list of >selector sets, each set contains S/D IP address range, ONE protocol >(or ANY), and S/D port range. The "list of ranges" effect is >achieved in that fashion. Correct. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 12:34:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EJYxI7061581; Tue, 14 Oct 2003 12:34:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15425 Tue, 14 Oct 2003 14:50:22 -0400 (EDT) Message-Id: <200310141850.h9EIoMCI000367@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") In-reply-to: Your message of "Tue, 14 Oct 2003 13:18:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 14:50:22 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: > >Still, I am a bit concerned by this characterization. Having looked >at the traffic on this issue, I did not see a clear description of >how two implementations would signal the necessary info in a standard >fashion. So I think that topic 1, the IKEv2 extension, will be >critical. It may be critical, but it certainly isn't part of 2401bis. There is also some apparent confusion as to what exactly is needed (some people talking about Phase1 IDs for authentication, others about Subscriber IDs, and so on). >As for item 2 above, we think it is appropriate to discuss this issue >and I thought we had proposed text to that effect. That text noted >that it was a local matter as to how one took traffic from multiple >subscribers and mapped it to the right SPD, but one has to discuss >this as part of the overall processing model, to ensure that the >model is clear and as comp;lete as possible. There wasn't proposed text as such, just indications as to what might be included (items 1 and 2 in the issue description). As to the proposed approach, (a) is certainly acceptable, but (b) and (c) seem outside the scope of 2401bis (suggesting use of NAT!) -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 12:41:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EJfoI7061954; Tue, 14 Oct 2003 12:41:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15622 Tue, 14 Oct 2003 15:04:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200310141850.h9EIoMCI000367@coredump.cs.columbia.edu> References: <200310141850.h9EIoMCI000367@coredump.cs.columbia.edu> Date: Tue, 14 Oct 2003 15:10:34 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:50 -0400 10/14/03, Angelos D. Keromytis wrote: >In message , Stephen Kent writes: >> >>Still, I am a bit concerned by this characterization. Having looked >>at the traffic on this issue, I did not see a clear description of >>how two implementations would signal the necessary info in a standard >>fashion. So I think that topic 1, the IKEv2 extension, will be >>critical. > >It may be critical, but it certainly isn't part of 2401bis. There is also some >apparent confusion as to what exactly is needed (some people talking about >Phase1 IDs for authentication, others about Subscriber IDs, and so on). I think it will be critical for a standard, interoperable solution for PPVPNs. However, since we have yet to agree on exactly what is needed, and we are not putting this in IKEv2 now, it is not something that needs to be in 2401bis, as you said. > >>As for item 2 above, we think it is appropriate to discuss this issue >>and I thought we had proposed text to that effect. That text noted >>that it was a local matter as to how one took traffic from multiple >>subscribers and mapped it to the right SPD, but one has to discuss >>this as part of the overall processing model, to ensure that the >>model is clear and as comp;lete as possible. > >There wasn't proposed text as such, just indications as to what might be >included (items 1 and 2 in the issue description). As to the >proposed approach, >(a) is certainly acceptable, but (b) and (c) seem outside the scope of 2401bis >(suggesting use of NAT!) >-Angelos Telling folks what has to be done to make this work is within the scope of 2401bis, even if (heaven forbid!) NAT is needed. We discussed this with people who make these products and the feedback we got is consistent with the proposal. Steve From owner-ipsec@lists.tislabs.com Tue Oct 14 12:45:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EJjlI7062144; Tue, 14 Oct 2003 12:45:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15645 Tue, 14 Oct 2003 15:05:58 -0400 (EDT) Message-Id: <200310141906.h9EJ61CI024083@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") In-reply-to: Your message of "Tue, 14 Oct 2003 15:10:34 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 2003 15:06:01 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: >At 14:50 -0400 10/14/03, Angelos D. Keromytis wrote: >>In message , Stephen Kent writes: >>> >>>Still, I am a bit concerned by this characterization. Having looked >>>at the traffic on this issue, I did not see a clear description of >>>how two implementations would signal the necessary info in a standard >>>fashion. So I think that topic 1, the IKEv2 extension, will be >>>critical. >> >>It may be critical, but it certainly isn't part of 2401bis. There is also som >e >>apparent confusion as to what exactly is needed (some people talking about >>Phase1 IDs for authentication, others about Subscriber IDs, and so on). > >I think it will be critical for a standard, interoperable solution >for PPVPNs. However, since we have yet to agree on exactly what is >needed, and we are not putting this in IKEv2 now, it is not something >that needs to be in 2401bis, as you said. Then we're in agreement. -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 13:58:52 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKwqI7064770; Tue, 14 Oct 2003 13:58:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16229 Tue, 14 Oct 2003 16:08:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.23008.5000.514658@gargle.gargle.HOWL> Date: Tue, 14 Oct 2003 16:17:36 -0400 From: Paul Koning To: ldondeti@nortelnetworks.com Cc: charliek@microsoft.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 Correction (editorial) References: <3F8C3910.4070907@americasm06.nt.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Lakshminath" == Lakshminath Dondeti writes: Lakshminath> In Section 3.3.2, Figure 8 of ikev2-11, the second Lakshminath> RESERVED field should be 2 octets in length. Lakshminath> The description below should say something like: Lakshminath> RESERVED2 - MUST be sent as zero; MUST be ignored on Lakshminath> receipt. Standard text for reserved fields is: SHOULD be sent as zero; MUST be ignored on receipt. paul From owner-ipsec@lists.tislabs.com Tue Oct 14 14:03:10 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EL39I7064866; Tue, 14 Oct 2003 14:03:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16417 Tue, 14 Oct 2003 16:23:03 -0400 (EDT) Message-Id: <5.2.0.9.0.20031014162123.02d5d0c8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 14 Oct 2003 16:26:18 -0400 To: "Angelos D. Keromytis" , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: 2401bis issues In-Reply-To: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:32 PM 10/14/2003 -0400, Angelos D. Keromytis wrote: >Issue 81 ("Handling outbound red fragments"): marked as possible reject >Rationale: since we decided not to adopt issue 49 ("red-side fragmentation > option"), it doesn't make much sense to treat red fragments in > this > way. Yell if you disagree. Does this mean that having 2401bis permit red-side fragmentation is rejected, or just that the special treatment that was proposed for the fragments (separate SAs for them) is rejected? From where I sit, allowing red-side fragmentation is very important. Thanks, Mark From owner-ipsec@lists.tislabs.com Tue Oct 14 14:13:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ELDvI7065309; Tue, 14 Oct 2003 14:13:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16352 Tue, 14 Oct 2003 16:19:34 -0400 (EDT) Message-ID: <3F8C5C6F.50305@americasm06.nt.com> Date: Tue, 14 Oct 2003 16:28:31 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning CC: charliek@microsoft.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 Correction (editorial) References: <3F8C3910.4070907@americasm06.nt.com> <16268.23008.5000.514658@gargle.gargle.HOWL> In-Reply-To: <16268.23008.5000.514658@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are a few instances of "MUST be sent as zero" in IKEv2-11. regards, Lakshminath Paul Koning wrote: >>>>>>"Lakshminath" == Lakshminath Dondeti writes: >>>>>> >>>>>> > > Lakshminath> In Section 3.3.2, Figure 8 of ikev2-11, the second > Lakshminath> RESERVED field should be 2 octets in length. > > Lakshminath> The description below should say something like: > > Lakshminath> RESERVED2 - MUST be sent as zero; MUST be ignored on > Lakshminath> receipt. > >Standard text for reserved fields is: > > SHOULD be sent as zero; MUST be ignored on receipt. > > paul > > > > From owner-ipsec@lists.tislabs.com Tue Oct 14 14:25:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ELPXI7066028; Tue, 14 Oct 2003 14:25:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16651 Tue, 14 Oct 2003 16:41:26 -0400 (EDT) Message-Id: <200310142050.h9EKoRB29185@sydney.East.Sun.COM> Date: Tue, 14 Oct 2003 16:50:27 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 Correction (editorial) To: pkoning@equallogic.com, ldondeti@nortelnetworks.com Cc: charliek@microsoft.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: D1xkLainyYuRc85n5SnGLQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't understand why reserved fields shouldn't be "MUST be sent as zero". At least for implementations of this draft. There might be a future version that uses the bits, but that spec would no longer say "MUST be sent as zero". Instead it would say "MUST be set to the grobnitz filter value" or whatever the reserved bits get used for. If the spec for this version of IKE says SHOULD, doesn't that allow a vendor to use the bits for some proprietary purpose? Radia From owner-ipsec@lists.tislabs.com Tue Oct 14 14:49:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ELnZI7066773; Tue, 14 Oct 2003 14:49:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16982 Tue, 14 Oct 2003 17:07:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 14 Oct 2003 17:19:39 -0400 To: ipsec mailingList From: Karen Seo Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding Cc: , , "Angelos D. Keromytis" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Unless there are objections, since ESP is now awaiting 2401bis, the information/guidance re: TFC padding and dummy packets will be put in ESP rather than 2401bis. Karen From owner-ipsec@lists.tislabs.com Tue Oct 14 14:56:14 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ELuDI7067051; Tue, 14 Oct 2003 14:56:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17060 Tue, 14 Oct 2003 17:13:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> References: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> Date: Tue, 14 Oct 2003 17:19:49 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Issue #82: Creation of SAs -- clarifications Cc: ipsec@lists.tislabs.com, "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 18:23 +0300 10/14/03, Tero Kivinen wrote: >Parsing this text took quite a long time for me. I finally think I >managed to understand what it is trying to say, but I think the actual >text added to the final document must explain the things more clearly. we'll try to rephrase, to make this complex topic clearer. I admit it was badly done in 2401 and we're trying to do a better job this time. > >So my understanding of the issue is that this changes the text which >says that we can create SAs selectors based on the packet or based on >the SPD to text which says that we can create SA selectors based on >the packet or based on the SPD, or something between. the goal is to allow an SAD entry and an SPD cache entry to be created based on selector values from the packet that triggered the creation of the SA. This facility was supposed to be described in 2401, but I think it was even less clear there :-) >I.e in addition to only take selectors from the packet implementations >are allowed to expand them towards to the SPD selectors as much as >they like. I don't understand these words. Let me try again. For each selector in the SPD, in addition to the literal values that define a match, we have defined special values, e.g., ANY and OPAQUE. We're saying there is another special value, PFP (populate from packet) that indicates the SPD entry matches any value for this selector, but wants a new SA created with the value from that selector field in the packet header to be used in creating the new SA. >Orginal case a) allowed only very specific SA selectors based on the >packet itself. The original case b) takes the SA selectors from the >SPD. The current IKEv2 approach is that we take the selectors from the >packet and select the SPD which matches to them and then create SA >that is either that SPD or any subset of it, as long as the packet >itself fits to that subset. IKE is invoked with a set of SPD selector values. In the case of a PFP selector, what IKE sees is the SPD entry with the selector field extracted from the packet, as opposed to a value from the SPD. Does this help? Steve From owner-ipsec@lists.tislabs.com Tue Oct 14 15:10:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EMAQI7067400; Tue, 14 Oct 2003 15:10:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17334 Tue, 14 Oct 2003 17:29:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.27886.993322.845802@gargle.gargle.HOWL> Date: Tue, 14 Oct 2003 17:38:54 -0400 From: Paul Koning To: Radia.Perlman@sun.com Cc: ldondeti@nortelnetworks.com, charliek@microsoft.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 Correction (editorial) References: <200310142050.h9EKoRB29185@sydney.East.Sun.COM> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: Radia> I don't understand why reserved fields shouldn't be "MUST be Radia> sent as zero". At least for implementations of this Radia> draft. There might be a future version that uses the bits, but Radia> that spec would no longer say "MUST be sent as zero". Instead Radia> it would say "MUST be set to the grobnitz filter value" or Radia> whatever the reserved bits get used for. Radia> If the spec for this version of IKE says SHOULD, doesn't that Radia> allow a vendor to use the bits for some proprietary purpose? Two reasons. 1. "SHOULD" on send rules is the standard rule. 2. If you say "MUST send as zero" that creates a strong temptation in receivers to check for zero and reject the packet if a non-zero is found. If that is done, the whole version thing breaks. paul From owner-ipsec@lists.tislabs.com Tue Oct 14 15:19:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EMJHI7068439; Tue, 14 Oct 2003 15:19:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17486 Tue, 14 Oct 2003 17:39:57 -0400 (EDT) Message-ID: <3F8C6F4A.4040208@americasm06.nt.com> Date: Tue, 14 Oct 2003 17:48:58 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: "Lakshminath Dondeti" , charliek@microsoft.com Subject: Re: IKEv2 Correction (editorial) References: <3F8C3910.4070907@americasm06.nt.com> In-Reply-To: <3F8C3910.4070907@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hate to lose the original point of the message in the MUST/SHOULD discussion on RESERVED fields: In Section 3.3.2, Figure 8 of ikev2-11, the second RESERVED field should be 2 octets in length. Lakshminath Dondeti, Lakshminath wrote: > In Section 3.3.2, Figure 8 of ikev2-11, the second RESERVED field > should be 2 octets in length. > > The description below should say something like: > > RESERVED2 - MUST be sent as zero; MUST be ignored on receipt. > > > > thanks, > Lakshminath > From owner-ipsec@lists.tislabs.com Tue Oct 14 15:21:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EMLwI7068509; Tue, 14 Oct 2003 15:21:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17438 Tue, 14 Oct 2003 17:38:18 -0400 (EDT) Message-ID: <3F8C6EE3.6070202@americasm06.nt.com> Date: Tue, 14 Oct 2003 17:47:15 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning CC: Radia.Perlman@sun.com, charliek@microsoft.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 Correction (editorial) References: <200310142050.h9EKoRB29185@sydney.East.Sun.COM> <16268.27886.993322.845802@gargle.gargle.HOWL> In-Reply-To: <16268.27886.993322.845802@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I just checked 2407 and 2408: 2407 says MUST be zero 2408 says Unused, set to 0. :-) Could you please point me to a reference that says "SHOULD on send is the standard rule." thanks, Lakshminath PS: CW, quoted several times elsewhere says: "be conservative in what you send and generous in what you receive"; that might simply work! Paul Koning wrote: >>>>>>"Radia" == Radia Perlman <- Boston Center for Networking > writes: >>>>>> >>>>>> > > Radia> I don't understand why reserved fields shouldn't be "MUST be > Radia> sent as zero". At least for implementations of this > Radia> draft. There might be a future version that uses the bits, but > Radia> that spec would no longer say "MUST be sent as zero". Instead > Radia> it would say "MUST be set to the grobnitz filter value" or > Radia> whatever the reserved bits get used for. > > Radia> If the spec for this version of IKE says SHOULD, doesn't that > Radia> allow a vendor to use the bits for some proprietary purpose? > >Two reasons. > >1. "SHOULD" on send rules is the standard rule. >2. If you say "MUST send as zero" that creates a strong temptation in > receivers to check for zero and reject the packet if a non-zero is > found. If that is done, the whole version thing breaks. > > paul > > > > From owner-ipsec@lists.tislabs.com Tue Oct 14 16:24:57 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ENOvI7070436; Tue, 14 Oct 2003 16:24:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18494 Tue, 14 Oct 2003 18:45:39 -0400 (EDT) Message-Id: <200310142254.h9EMsdB11245@sydney.East.Sun.COM> Date: Tue, 14 Oct 2003 18:54:39 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 Correction (editorial) To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lwc3nx2k5F2OXq1Kg/oCyQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> 2. If you say "MUST send as zero" that creates a strong temptation in >> receivers to check for zero and reject the packet if a non-zero is >> found. If that is done, the whole version thing breaks. That's why I assumed the spec should say both "MUST send as zero" and "MUST ignore upon receipt", It would be nice in general if it were understood that that is the required behavior in fields marked as "RESERVED". (That way specs wouldn't have to say "MUST send as zero" and "MUST ignore on receipt" for every reserved field, it would just be assumed by calling the field "reserved"). I assume we're not arguing over the desired behavior...just the wording. Radia From owner-ipsec@lists.tislabs.com Tue Oct 14 16:31:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ENUxI7070546; Tue, 14 Oct 2003 16:31:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18646 Tue, 14 Oct 2003 18:54:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030928231046.01fb51c8@localhost> References: <5.2.0.9.0.20030928231046.01fb51c8@localhost> Date: Tue, 14 Oct 2003 19:03:22 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: SPD issues Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, > > > >> - My previous proposal for a revised processing model, from >>a few weeks ago, retained the idea of multiple SPDs, allocating >>them to virtual interfaces, and introduced the notion of a >>forwarding function to select the right virtual interface, and thus >>SPD. But, unless we feel a need to have different SPDs per >>interface, this seems like overkill. I think we do want to allow >>forwarding of outbound traffic to be independent of SPD selection, >>so some notion of an explicit forwarding function in the model >>still seems appropriate. but, as we discussed the model, there was >>a suggestion that we might need two such functions, one to select >>an SPD, and then one to be applied after IPsec processing. maybe, >>if we separate SPD selection from interface selection we can have >>two functions but only one of them is really for forwarding. > >I am all for separating the "SPD selection function" from the "IP >forwarding function". (Once that is done though, I don't see why >the IP forwarding function is any concern of IPsec's.) I think we have to say something about options for how forwarding decisions can be made in the context of IPsec, especially in tunnel mode. > >By using different SPD selection functions, different results can be obtained: > >The RFC 2401 behavior can be obtained by an SPD selection function >based on the output IP interface for outbound packets and the >receiving IP interface for inbound packets (i.e. the black side >interface). > >The behavior described above for different SPDs per subscriber can >be obtained by an SPD selection function based on the receiving IP >interface for outbound packets and the output IP interface for >inbound packets (i.e. the red side interface). There is no need to select an SPD for inbound packets if they are IPsec-protected. We still envision just one SAD per IPsec implementation, and the revised processing model says that the relevant SPD info needed to check inbound packets after processing is bound to the SAD entries. That leaves the question of SPD info for inbound bypass/discard traffic. > >And the very simple case mentioned above can be handled by an SPD >selection function that just returns the same SPD in all cases. yes, using just one SPD should be an option. > > >> - Along those lines, we could introduce an SPD selector >>function that, like the forwarding function, can use any info in a >>packet to select an SPD, but without associating the SPD with an >>interface per se. > >Yes, please! But I would say that it should be able to use not only >"any info in a packet" but also meta-information associated with a >packet (e.g. the interface it arrived or will depart on) to select >an SPD. Perhaps that's what you intended anyway. > yes, I did mean to include meta data, e.g., local interface via which the outbound packet was received. Steve (still catching up on 2 weeks of e-mail) From owner-ipsec@lists.tislabs.com Tue Oct 14 21:38:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F4cDI7086102; Tue, 14 Oct 2003 21:38:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21039 Tue, 14 Oct 2003 23:57:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <200310011440.h91EePHN072102@givry.rennes.enst-bretagne.fr> References: <200310011440.h91EePHN072102@givry.rennes.enst-bretagne.fr> Date: Wed, 15 Oct 2003 00:08:47 -0400 To: ipsec@lists.tislabs.com, Francis Dupont , clynn@bbn.com From: Karen Seo Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Thank you for the suggestions re: which code to use for the following case.... >b2. the IPsec system was unable to set up the SA required by the SPD >entry matching the packet because the IPsec peer at the other end of >the exchange could not be contacted. The type should be destination >unreachable, but what codes should we use? While it would be desirable for the sender to be notified of the true cause of the failure to set up the needed SA, given that the IPsec system may not be able to verify the ICMP info it receives about the cause of the set up failure, how about if we use: IPv4 Type = 3 (destination unreachable) Code = 1 (host unreachable) IPv6 Type = 1 (destination unreachable) Code = 3 (address unreachable) This would let us avoid the effort and time to needed to define and obtain additional types and codes. Thanks again, Karen From owner-ipsec@lists.tislabs.com Tue Oct 14 21:53:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F4r8I7087892; Tue, 14 Oct 2003 21:53:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21152 Wed, 15 Oct 2003 00:16:19 -0400 (EDT) Message-Id: <5.2.0.9.0.20031014235708.0218d580@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 15 Oct 2003 00:13:25 -0400 To: "Angelos D. Keromytis" , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") In-Reply-To: <200310141655.h9EGtpCI004728@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here in response to the solicitation is a proposed text re multiple context support in 2401bis: IPsec devices supporting services such as: security gateway for multiple subscribers, IPsec-protected tunnel links for overlay networks, etc. MAY implement multiple separate IPsec contexts. These contexts MAY have and use completely independent identities, policies, key management SAs, and/or IPsec SAs. This is for the most part a local implementation matter. However, a means for associating inbound proposals with local contexts is required. To this end, if supported by the key management protocol in use, context identifiers MAY be conveyed from initiator to responder in the signalling messages, with the result that IPsec SAs are created with a binding to a particular context. --Mark At 12:55 PM 10/14/2003 -0400, Angelos D. Keromytis wrote: >We discussed this issue in our weekly telecon...it appears that there are two >separate, but connected issues here: > >a) Some kind of IKE notification to inform the SG which subscriber the >initiator > wants to talk to; this is something that should be resolved in IKEv2, most > likely as an additional document. > >b) Support in the IPsec stack (meaning 2401bis text) for the notion of >different > subscribers. This part is applicable to 2401bis and thus to this > issue. How > it is implemented should be left to the individual implementations. There > may be some merrit in including a paragraph in 2401bis mentioning the > issue; > so: > > We solicit 1 paragraph describing the issue and the possibilities for > implementing it, to be included in 2401bis. If such a paragraph does not > materialize in a week (by our next telecon), we will simply drop the > issue. > >Cheers, >-Angelos From owner-ipsec@lists.tislabs.com Tue Oct 14 21:54:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9F4s4I7088027; Tue, 14 Oct 2003 21:54:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21151 Wed, 15 Oct 2003 00:16:14 -0400 (EDT) Message-Id: <5.2.0.9.0.20031014234014.0214b190@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 14 Oct 2003 23:55:58 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: SPD issues Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.0.20030928231046.01fb51c8@localhost> <5.2.0.9.0.20030928231046.01fb51c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:03 PM 10/14/2003 -0400, Stephen Kent wrote: >Mark, > >> >> >> >>> - My previous proposal for a revised processing model, from a >>> few weeks ago, retained the idea of multiple SPDs, allocating them to >>> virtual interfaces, and introduced the notion of a forwarding function >>> to select the right virtual interface, and thus SPD. But, unless we >>> feel a need to have different SPDs per interface, this seems like >>> overkill. I think we do want to allow forwarding of outbound traffic to >>> be independent of SPD selection, so some notion of an explicit >>> forwarding function in the model still seems appropriate. but, as we >>> discussed the model, there was a suggestion that we might need two such >>> functions, one to select an SPD, and then one to be applied after IPsec >>> processing. maybe, if we separate SPD selection from interface >>> selection we can have two functions but only one of them is really for >>> forwarding. >> >>I am all for separating the "SPD selection function" from the "IP >>forwarding function". (Once that is done though, I don't see why the IP >>forwarding function is any concern of IPsec's.) > >I think we have to say something about options for how forwarding >decisions can be made in the context of IPsec, especially in tunnel mode. How about: For packets that "bypass" IPsec processing, and for packets that arrive with IPsec protection which is removed at the device, the IP output interface and next hop are selected by the normal IP forwarding mechanism of the device [which would be beyond the scope of 2401bis] applied to the plaintext packet. For packets that have IPsec applied to them by the device (tunnel or transport mode) the IP output interface and next hop are selected by the normal IP forwarding mechanism of the device applied to the IPsec packet. And for packets that have a "drop" action selected, the document can remain silent. After all, the world would be rendered uninteresting if all mystery were removed ;-) Mark From bdana@yahoo.com Tue Oct 14 23:29:48 2003 Received: from BLUE ([61.104.62.185]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9F6TlI7017062 for ; Tue, 14 Oct 2003 23:29:48 -0700 (PDT) (envelope-from bdana@yahoo.com) Message-Id: <200310150629.h9F6TlI7017062@above.proper.com> From: "bjadams@email.com" To: "ietf-ipsec@imc.org" Subject: Real Diplomas - No books or exams! kosp Date: Sun, 19 Oct 2003 15:26:53 +0900 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9yPSIjMDAzMzMzIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+ PGJyPg0KPHRhYmxlIHdpZHRoPSI2NTAiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIyIiBib3JkZXJjb2xvcj0iIzAwMDAwMCI+PHRyPjx0ZD48dGFibGUgd2lkdGg9IjY1 MCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjQiIGFsaWduPSJjZW50 ZXIiPjx0cj4NCjx0ZCBiZ2NvbG9yPSIjMDAzMzY2Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZG RkZGRiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+LiBVIE4gPCEtLSBsYXM0 aGQ3IC0tPkkgViBFIFIgUyBJIFQgWSAuIEQgSSBQIEwgPCEtLSBsYXM0aGQ3IC0tPk8gTSBBIFMg LjwvZm9udD48L3RkPjwvdHI+DQo8dHI+PHRkIGJnY29sb3I9ImJsYWNrIiBoZWlnaHQ9IjQwIiB2 YWxpZ249Im1pZGRsZSI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlZlcmRhbmEs IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjRkZGRkZGIj48 aT5Ib3cgd291bGQgeW91IGxpa2UgdG8gaW5jcmVhc2UgeW91ciBzYWxhcnkgYW5kIGVtcGxveWFi aWxpdHk/PC9pPjxicj48L2ZvbnQ+PC9kaXY+DQo8L3RkPjwvdHI+PHRyPiA8dGQgYmdjb2xvcj0i Q0MwMDMzIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PGI+PGk+PGZvbnQgZmFjZT0iVmVyZGFu YSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+V2UgY2FuIGFzc2lzdCB3 aXRoIERpcDwhLS0gbGFzNGhkNyAtLT5sb21hcyBmcm9tIHByZXN0aWdpb3VzIG5vbi1hY2NyZWRp dGVkIHVuaXZlcnNpdDwhLS0gMjExeTczMnYgLS0+aWVzIGJhc2VkIG9uIHlvdXIgcHJlc2VudCBr bm93bGVkZ2UgYW5kIGxpZmUgZXhwZXJpZW5jZS48L2ZvbnQ+PC8NCjwvdGQ+PC90cj48dHI+PHRk IGJnY29sb3I9IndoaXRlIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVmVyZGFu YSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMyI+PGJyPjxiPjxmb250IGNv bG9yPSIjRkYwMDAwIj5ObyBib29rcywgaW50ZXJ2aWV3cyBvciBleGFtcyE8L2ZvbnQ+PC9iPjwv ZGl2Pg0KPHAgYWxpZ249ImxlZnQiPjxpPkdlbnVpbmUgQmFjaGVsb3JzLCBNYXN0ZXJzLCBNQkEg YW5kIFBIRCdzIGF2YWlsYWJsZSBpbiBhbnkgZmllbGQgeW91IGNob29zZS4gUGVyZmVjdCBmb3Ig eW91ciBSZXN1bWUsIEpvYiBpbnRlcnZpZXcgb3IgdG8gaGFuZyBpbiB0aGUgd2FsbCBvZiB5b3Vy IG9mZmljZSE8L2k+PC9mb250PjwvcD4NCjxwIGFsaWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9 IjUiIGNvbG9yPSIjMDAwMEZGIj5ObyBvbmUgaXMgdHVybmVkIGRvd24uPC9mb250PjwvYj48L3A+ DQo8cCBhbGlnbj0iY2VudGVyIj48aT5Db25maWRlbnRpYWxpdHkgYXNzdXJlZDwvaT48L2ZvbnQ+ PGJyPjxicj48L3A+DQo8L3RkPjwvdHI+PHRyPjx0ZCBiZ2NvbG9yPSIjMDAwMDAwIj4NCjxkaXYg YWxpZ249ImNlbnRlciI+PHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZiIgY29sb3I9IiNGRkZGRkYiPjxicj4NCkNBTEwgVVMmbmJzcDsgMjQgSE9VUlMg QSBEQVksIDcgREFZUyZuYnNwOyBBIFdFRUs8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiNGRkZGRkYiPiZuYnNw OyA8Zm9udCBzaXplPSIxIj4oaW5jbHVkaW5nIFN1bmRheXMgYW5kIGhvbGlkYXlzKTo8L2ZvbnQ+ PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIGNvbG9yPSIjRkZGRkZGIj48Yj48Zm9udCBzaXplPSI1Ij5DQUxMIDEtMjwhLS0g bGFzNGhkNyAtLT4xMi0yMDItNDc4NTwvZm9udD48L2I+IDwvZm9udD4gPGZvbnQgc2l6ZT0iNSIg ZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiNGRkZGRkYiPjxicj48 L2I+PC9mb250PjwvcD48L2Rpdj4NCjwvdGQ+PC90cj48dHI+IDx0ZCBiZ2NvbG9yPSIjMDAzMzY2 Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiNGRkZGRkYiIGZh Y2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxiPkNhbGwgdXMgTk9XIHRvIHJlY2Vp dmUgeW91ciBkaXBsbzwhLS0gNGhmbDggLS0+bWEgd2l0aGluIGRheXMsIGFuZCBzdGFydCBpbXBy b3ZpbmcgeW91ciBsaWZlITwvYj48L2ZvbnQ+PC9kaXY+DQo8L3RkPjwvdHI+PC90YWJsZT48L3Rk PjwvdHI+PC90YWJsZT48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== From owner-ipsec@lists.tislabs.com Wed Oct 15 03:05:27 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FA5QI7069562; Wed, 15 Oct 2003 03:05:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA23385 Wed, 15 Oct 2003 05:22:14 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.5007.212493.86304@ryijy.hel.fi.ssh.com> Date: Wed, 15 Oct 2003 12:29:51 +0300 From: Tero Kivinen To: Stephen Kent Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: 2401bis issues In-Reply-To: References: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > I agree that this is not an interoperability issue, but 2401 > established a per-interface SPD requirement and I think we now have > heard from various folks that this is unduly restrictive. The processing model in RFC2401 is just one example way how to do it, and as RFC2401 says, you can implement IPsec processing in a way you like, as long as it looks from the outside that it is similar than what is described in the RFC2401. If we cannot see the difference of those two ways, I do not think we need to change it. Implementators who want to implement it that way can already do it, I do not think RFC2401 restricts anybody in that way. ---------------------------------------------------------------------- 4.4 Security Association Databases Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model. ---------------------------------------------------------------------- > So as part of the revised processing model we need to remove the > old, 2401 restriction and explain what the new model does and why. Does the new processing model require interface selectors or not? Does it help describing the processing model if we have interface selectors instead of per interface SPD? What is the rationale behind this change? > >Issues 44 ("forwarding table lookup to select virtual interface ID") and > > 45 ("use of cache with de-correlated SPD") > >are still open, waiting for 2401bis draft. > this will also be covered i the revised model. I would really like to have that revised model as soon as possible... > >Rejected Issue 69 ("Multiple protocols per SPD entry") > >Rationale: This is covered by > > issue 47 ("all selectors can be a list of ranges, per IKEv2 spec"). > > Tero has pointed out in some private e-mail that this > characterization in quotes is not quite right, i.e., IKEv2 does not > work this way! That was what we were refereing to, i.e while we fix the issue 47, it will make clear that we do not need protocol ranges in the SPD, but we do need each SPD entry to have list of selector items (source and destination ip-address ranges, protocol id, source and destination port ranges). > So, we are revising the characterization accordingly. > The bottom line is that one can accommodate multiple protocols in a > single SPD entry, because the entry really consists of a list of > selector sets, each set contains S/D IP address range, ONE protocol > (or ANY), and S/D port range. The "list of ranges" effect is > achieved in that fashion. Yep, and as this will be taken care of inside the Issue 47, then we can reject the issue 69 proposing about the same thing, but differently. -- 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 Oct 15 03:19:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FAJCI7070333; Wed, 15 Oct 2003 03:19:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA23497 Wed, 15 Oct 2003 05:41:36 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.6172.906127.369445@ryijy.hel.fi.ssh.com> Date: Wed, 15 Oct 2003 12:49:16 +0300 From: Tero Kivinen To: Mark Duffy Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: 2401bis issues In-Reply-To: <5.2.0.9.0.20031014162123.02d5d0c8@email> References: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> <5.2.0.9.0.20031014162123.02d5d0c8@email> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > At 12:32 PM 10/14/2003 -0400, Angelos D. Keromytis wrote: > >Issue 81 ("Handling outbound red fragments"): marked as possible reject > >Rationale: since we decided not to adopt issue 49 ("red-side fragmentation > > option"), it doesn't make much sense to treat red fragments in > > this > > way. Yell if you disagree. > Does this mean that having 2401bis permit red-side fragmentation is > rejected, or just that the special treatment that was proposed for the > fragments (separate SAs for them) is rejected? The proposed resolution in issue 49 is: ---------------------------------------------------------------------- Proposed resolution: Because of this limitation, we do not plan to change 2401 to make provision for receipt of red side fragments as a special case. ---------------------------------------------------------------------- I.e there will not be special flag for SA that means that red fragments OK for this SA. So if red fragments are not going to have special inbound handling the issue 81 which proposed creating special SA for outbound to them should be reject too. So the special treatment was proposed. I don't think we have any issue in the issue tracker about whether the 2401bis should or should not permit red-side 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 Wed Oct 15 04:12:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FBCII7072523; Wed, 15 Oct 2003 04:12:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA23666 Wed, 15 Oct 2003 06:25:02 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.8775.274049.236055@ryijy.hel.fi.ssh.com> Date: Wed, 15 Oct 2003 13:32:39 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com, "Angelos D. Keromytis" , Barbara Fraser , "Theodore Ts'o" , Karen Seo Subject: Re: Issue #82: Creation of SAs -- clarifications In-Reply-To: References: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 31 min X-Total-Time: 43 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >I.e in addition to only take selectors from the packet implementations > >are allowed to expand them towards to the SPD selectors as much as > >they like. > > I don't understand these words. Let me try again. > > For each selector in the SPD, in addition to the literal values that > define a match, we have defined special values, e.g., ANY and > OPAQUE. We're saying there is another special value, PFP (populate > from packet) that indicates the SPD entry matches any value for this > selector, but wants a new SA created with the value from that > selector field in the packet header to be used in creating the new SA. Ok, this is more like taking subset of SPD per field basis? I.e if the SPD says: Entry 1 set 1 (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) set 2 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) and we have packet with 10.source 10.0.0.22 and destination 10.0.1.5 then we can create either SA directly from the packet SA (10.0.0.22 <-> 10.0.1.5) or from the SPD SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) or source from packet and destination from SPD: SA (10.0.0.22 <-> 10.0.1.0-10.0.1.255) and SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5) Do we want to allow creation of following SA: SA (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) I.e take the selector set 1 from the SPD and create SA based on that, but leave out selector set 2? Or any arbitrary subset: SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) Note, that that kind of subsets might be result of the IKEv2 negotiation, as the other end might have different SPD, and he will limit the proposal sent by initiator to his SPD. I.e if the other end have following SPD: Entry 1 set 1 (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) set 2 (10.0.0.20-10.0.0.30 <-> 10.0.33.0-10.0.33.9) Entry 2 set 1 (10.0.0.0-10.0.0.19 <-> 10.0.1.0-10.0.1.255) set 2 (10.0.0.31-10.0.0.255 <-> 10.0.1.0-10.0.1.255) set 3 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) set 4 (10.0.0.20-10.0.0.30 <-> 10.0.1.10-10.0.1.255) He will select the entry 1 as it is the only one where the original packet fits in. The proposal he actually gets in IKE will be (10.0.0.22 <-> 10.0.1.5, 10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255), i.e the first source destination address pair matches the actual packet, and then it gets the SPD info from the initiator. The IKEv2 defines that he must select subset that contains the first entry, thus he must select his SPD entry 1. When he creates the reply, he will take intersection of the initiator set and his entry 1, getting back result: (10.0.0.22 <-> 10.0.1.5, 10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) which he can then optimize to as the first item is inside the second. (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) and reply with that to the initiator. This cause the SA to have the SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) to be created, even when such items was neither ends SPD (it is largest common subset of their SPDs which can process the packet). > IKE is invoked with a set of SPD selector values. In the case of a > PFP selector, what IKE sees is the SPD entry with the selector field > extracted from the packet, as opposed to a value from the SPD. Ok, se only possible values given to IKE are either the whole SPD entry (+the actual value from packet) or only the value from packet per each field in selector. Note, that IKEv2 will need the exact values from the packet regardless whether the final entry is created based on SPD or from the value of the packet. I.e to answer my own questions earlier, we do not allow taking only part of the SPD sets, nor do we allow arbitrary subsets created by the initiator. The result of the negotiation might be arbitrary subset of the SPD if the SPD entries in each end are different. > Does this help? I think so. The PFP constructs helps to understand issue better. -- 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 Oct 15 06:29:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FDTGI7077281; Wed, 15 Oct 2003 06:29:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24709 Wed, 15 Oct 2003 08:44:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.17219.674000.129699@gargle.gargle.HOWL> Date: Wed, 15 Oct 2003 08:53:23 -0400 From: Paul Koning To: Radia.Perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 Correction (editorial) References: <200310142254.h9EMsdB11245@sydney.East.Sun.COM> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: >>> 2. If you say "MUST send as zero" that creates a strong >>> temptation in receivers to check for zero and reject the packet >>> if a non-zero is found. If that is done, the whole version thing >>> breaks. Radia> That's why I assumed the spec should say both "MUST send as Radia> zero" and "MUST ignore upon receipt", It would be nice in Radia> general if it were understood that that is the required Radia> behavior in fields marked as "RESERVED". (That way specs Radia> wouldn't have to say "MUST send as zero" and "MUST ignore on Radia> receipt" for every reserved field, it would just be assumed by Radia> calling the field "reserved"). Radia> I assume we're not arguing over the desired behavior...just Radia> the wording. Right. I did some searching in the RFC database and it appears to be less consistent than I remembered. Ok, so long as it's explicitly stated that the receiver is NOT allowed to check the reserved fields, I'm satisfied. paul From owner-ipsec@lists.tislabs.com Wed Oct 15 07:22:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FEMpI7079199; Wed, 15 Oct 2003 07:22:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25011 Wed, 15 Oct 2003 09:39:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16269.5007.212493.86304@ryijy.hel.fi.ssh.com> References: <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> <16269.5007.212493.86304@ryijy.hel.fi.ssh.com> Date: Wed, 15 Oct 2003 09:44:09 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: 2401bis issues Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:29 +0300 10/15/03, Tero Kivinen wrote: >Stephen Kent writes: >> I agree that this is not an interoperability issue, but 2401 >> established a per-interface SPD requirement and I think we now have >> heard from various folks that this is unduly restrictive. > >The processing model in RFC2401 is just one example way how to do it, >and as RFC2401 says, you can implement IPsec processing in a way you >like, as long as it looks from the outside that it is similar than >what is described in the RFC2401. If we cannot see the difference of >those two ways, I do not think we need to change it. Implementators >who want to implement it that way can already do it, I do not think >RFC2401 restricts anybody in that way. correct. > >---------------------------------------------------------------------- >4.4 Security Association Databases > > Many of the details associated with processing IP traffic in an IPsec > implementation are largely a local matter, not subject to > standardization. However, some external aspects of the processing > must be standardized, to ensure interoperability and to provide a > minimum management capability that is essential for productive use of > IPsec. This section describes a general model for processing IP > traffic relative to security associations, in support of these > interoperability and functionality goals. The model described below > is nominal; compliant implementations need not match details of this > model as presented, but the external behavior of such implementations > must be mappable to the externally observable characteristics of this > model. >---------------------------------------------------------------------- > >> So as part of the revised processing model we need to remove the >> old, 2401 restriction and explain what the new model does and why. > >Does the new processing model require interface selectors or not? Does >it help describing the processing model if we have interface selectors >instead of per interface SPD? when I published my first draft of the new model, it had a way to tag a packet with a VID, for forwarding purposes, and because we still had a per interface SPD, the VID selected the SPD too. The VID is not a selector, per se. However, as I have listened to comments from various folks I am less convinced that we should have per-interface SPDs as a basic part of the model. Instead it seems more important to have a function to select an appropriate SPD, if more than one is needed, and to leave the forwarding decision as a separate matter. > >What is the rationale behind this change? the rationale is that if we do not need to impose the constraint of a per-interface SPD, then it should go away, and a more flexible way of specifying the SPD should be accommodated, explicitly. > >> >Issues 44 ("forwarding table lookup to select virtual interface ID") and >> > 45 ("use of cache with de-correlated SPD") >> >are still open, waiting for 2401bis draft. >> this will also be covered i the revised model. > >I would really like to have that revised model as soon as possible... me too :-) > >> >Rejected Issue 69 ("Multiple protocols per SPD entry") >> >Rationale: This is covered by >> > issue 47 ("all selectors can be a list of ranges, per >>IKEv2 spec"). >> >> Tero has pointed out in some private e-mail that this >> characterization in quotes is not quite right, i.e., IKEv2 does not >> work this way! > >That was what we were refereing to, i.e while we fix the issue 47, it >will make clear that we do not need protocol ranges in the SPD, but we >do need each SPD entry to have list of selector items (source and >destination ip-address ranges, protocol id, source and destination >port ranges). agreed, and thanks for the clarification! > >> So, we are revising the characterization accordingly. >> The bottom line is that one can accommodate multiple protocols in a >> single SPD entry, because the entry really consists of a list of > > selector sets, each set contains S/D IP address range, ONE protocol >> (or ANY), and S/D port range. The "list of ranges" effect is >> achieved in that fashion. > >Yep, and as this will be taken care of inside the Issue 47, then we >can reject the issue 69 proposing about the same thing, but >differently. OK. Steve From owner-ipsec@lists.tislabs.com Wed Oct 15 08:09:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FF93I7081103; Wed, 15 Oct 2003 08:09:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25280 Wed, 15 Oct 2003 10:25:13 -0400 (EDT) Date: Wed, 15 Oct 2003 07:30:16 -0700 From: Nicolas Williams To: ipsec@lists.tislabs.com Subject: missing/inconsistent IKEv2 type allocation policies Message-ID: <20031015143016.GQ24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The allocation policies set forth for ID and CERT encoding types are either incomplete or inconsistent with those of other IKEv2 types. For CERT encoding types a large chunk of the namespace is marked "RESERVED," which I take to mean "to be allocated through IETF action (e.g., Standards Track RFCs)." But this is not spelled out anywhere, and anyways, it's inconsistent with the AUTH method type allocation policy which does specify an IANA allocation policy. As for ID types, the unused space of types is not even marked RESERVED. Nico -- From owner-ipsec@lists.tislabs.com Wed Oct 15 08:11:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FFBkI7081369; Wed, 15 Oct 2003 08:11:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25286 Wed, 15 Oct 2003 10:25:29 -0400 (EDT) Message-Id: <200310151425.h9FEPUCI024595@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mark Duffy Cc: ipsec@lists.tislabs.com Subject: Re: Issue 68 ("VPNs with overlapping IP address ranges") In-reply-to: Your message of "Wed, 15 Oct 2003 00:13:25 EDT." <5.2.0.9.0.20031014235708.0218d580@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 2003 10:25:30 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good enough. In message <5.2.0.9.0.20031014235708.0218d580@localhost>, Mark Duffy writes: >Here in response to the solicitation is a proposed text re multiple context >support in 2401bis: > > IPsec devices supporting services such as: security gateway for >multiple subscribers, IPsec-protected tunnel links for overlay networks, >etc. MAY implement multiple separate IPsec contexts. These contexts MAY >have and use completely independent identities, policies, key management >SAs, and/or IPsec SAs. This is for the most part a local implementation >matter. However, a means for associating inbound proposals with local >contexts is required. To this end, if supported by the key management >protocol in use, context identifiers MAY be conveyed from initiator to >responder in the signalling messages, with the result that IPsec SAs are >created with a binding to a particular context. > >--Mark > >At 12:55 PM 10/14/2003 -0400, Angelos D. Keromytis wrote: > >>We discussed this issue in our weekly telecon...it appears that there are two >>separate, but connected issues here: >> >>a) Some kind of IKE notification to inform the SG which subscriber the >>initiator >> wants to talk to; this is something that should be resolved in IKEv2, mos >t >> likely as an additional document. >> >>b) Support in the IPsec stack (meaning 2401bis text) for the notion of >>different >> subscribers. This part is applicable to 2401bis and thus to this >> issue. How >> it is implemented should be left to the individual implementations. There >> may be some merrit in including a paragraph in 2401bis mentioning the >> issue; >> so: >> >> We solicit 1 paragraph describing the issue and the possibilities for >> implementing it, to be included in 2401bis. If such a paragraph does not >> materialize in a week (by our next telecon), we will simply drop the >> issue. >> >>Cheers, >>-Angelos From owner-ipsec@lists.tislabs.com Wed Oct 15 10:46:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FHkXI7086482; Wed, 15 Oct 2003 10:46:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26204 Wed, 15 Oct 2003 12:49:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20031014234014.0214b190@localhost> References: <5.2.0.9.0.20030928231046.01fb51c8@localhost> <5.2.0.9.0.20030928231046.01fb51c8@localhost> <5.2.0.9.0.20031014234014.0214b190@localhost> Date: Wed, 15 Oct 2003 12:56:04 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: SPD issues Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, I like your suggested simple description of forwarding, especially because it gets rid of IPsec having to talk about the details. My only concern, after a quick read, is that for outbound tunnel mode packets, this does require that only the outer header be employed to make a forwarding decision. If everyone is comfortable with that limitation (and I am not saying that it is a problem), then I think we may have a way to simplify this aspect of the processing model. Steve > >How about: > >For packets that "bypass" IPsec processing, and for packets that >arrive with IPsec protection which is removed at the device, the IP >output interface and next hop are selected by the normal IP >forwarding mechanism of the device [which would be beyond the scope >of 2401bis] applied to the plaintext packet. > >For packets that have IPsec applied to them by the device (tunnel or >transport mode) the IP output interface and next hop are selected by >the normal IP forwarding mechanism of the device applied to the >IPsec packet. > >And for packets that have a "drop" action selected, the document can >remain silent. After all, the world would be rendered uninteresting >if all mystery were removed ;-) > >Mark From owner-ipsec@lists.tislabs.com Wed Oct 15 16:09:37 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FN9aI7096011; Wed, 15 Oct 2003 16:09:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28110 Wed, 15 Oct 2003 18:14:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16269.8775.274049.236055@ryijy.hel.fi.ssh.com> References: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> <16269.8775.274049.236055@ryijy.hel.fi.ssh.com> Date: Wed, 15 Oct 2003 18:23:01 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Issue #82: Creation of SAs -- clarifications Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:32 +0300 10/15/03, Tero Kivinen wrote: >Stephen Kent writes: >> >I.e in addition to only take selectors from the packet implementations >> >are allowed to expand them towards to the SPD selectors as much as >> >they like. >> >> I don't understand these words. Let me try again. >> >> For each selector in the SPD, in addition to the literal values that >> define a match, we have defined special values, e.g., ANY and >> OPAQUE. We're saying there is another special value, PFP (populate >> from packet) that indicates the SPD entry matches any value for this >> selector, but wants a new SA created with the value from that >> selector field in the packet header to be used in creating the new SA. > >Ok, this is more like taking subset of SPD per field basis? the intent is that specific fields in an SPD entry can be marked as being filled in (populated) from the corresponding packet field, if it matches the selector value range, rather than just plugging in the range from the SPD entry. > >I.e if the SPD says: > > Entry 1 > set 1 (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > set 2 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) I assume you are ignoring all the other selectors here and focusing only on the IP addresses, and I assume the "<->" notation is some sort of separator for source and destination address, right? >and we have packet with 10.source 10.0.0.22 and destination 10.0.1.5 >then we can create either SA directly from the packet I assume the "10.source is a typo and is supposed to be a source address of 10.0.0.22, right? > > SA (10.0.0.22 <-> 10.0.1.5) this is what would happen if BOTH the source and destination address selectors on set 1 and set 2 were marked for PFP, because the source address in the packet does not match the set 2 source address, a reasonable interpretation. >or from the SPD > > SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> > 10.0.1.0-10.0.1.255) this is what would happen is we did not mark any of the selectors as PFP. > >or source from packet and destination from SPD: > > SA (10.0.0.22 <-> 10.0.1.0-10.0.1.255) this would happen if the source address in set 1 was marked PFP, the destination address in set 1 was not PFP, and we ignore set 2, as above. >and > > SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5) this result is consistent with the source addresses in set 1 and set 2 not marked as PFP, but the destination address in both was marked PFP (I guess). >Do we want to allow creation of following SA: > > SA (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > >I.e take the selector set 1 from the SPD and create SA based on that, >but leave out selector set 2? you have not said which of the address selectors are marked as PFP, so I am not sure how to interpret this one. if none of the selectors in set 2 is marked as PFP, then this should not be negotiated. >Or any arbitrary subset: > > SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) PFP does not seem to be relevant to this sort of subset negotiation, as PFP always nails down a selector for an SA to a single value, not a range. >Note, that that kind of subsets might be result of the IKEv2 >negotiation, as the other end might have different SPD, and he will >limit the proposal sent by initiator to his SPD. I.e if the other end >have following SPD: > > Entry 1 > set 1 (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) > set 2 (10.0.0.20-10.0.0.30 <-> 10.0.33.0-10.0.33.9) > Entry 2 > set 1 (10.0.0.0-10.0.0.19 <-> 10.0.1.0-10.0.1.255) > set 2 (10.0.0.31-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > set 3 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) > set 4 (10.0.0.20-10.0.0.30 <-> 10.0.1.10-10.0.1.255) > >He will select the entry 1 as it is the only one where the original >packet fits in. The proposal he actually gets in IKE will be >(10.0.0.22 <-> 10.0.1.5, 10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255, >192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255), i.e the first >source destination address pair matches the actual packet, and then it >gets the SPD info from the initiator. The IKEv2 defines that he must >select subset that contains the first entry, thus he must select his >SPD entry 1. When he creates the reply, he will take intersection of >the initiator set and his entry 1, getting back result: > > (10.0.0.22 <-> 10.0.1.5, 10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) > >which he can then optimize to as the first item is inside the second. > > (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) > >and reply with that to the initiator. This cause the SA to have the > > SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) > >to be created, even when such items was neither ends SPD (it is >largest common subset of their SPDs which can process the packet). Agreed. > > IKE is invoked with a set of SPD selector values. In the case of a >> PFP selector, what IKE sees is the SPD entry with the selector field >> extracted from the packet, as opposed to a value from the SPD. > >Ok, se only possible values given to IKE are either the whole SPD >entry (+the actual value from packet) or only the value from packet >per each field in selector. right >Note, that IKEv2 will need the exact values from the packet regardless >whether the final entry is created based on SPD or from the value of >the packet. right, this is a big change from v1, and not anticipated in the PFP notion when it was created. but, the intent is different, i.e., in IKE v2 we pass the original packet selectors in an effort to make it easier to have two peers establish an acceptable SA without mandating identical SPD entries. it is not trying to create a series of distinct SAs, from one SPD entry, in response to transmission of different packets. >I.e to answer my own questions earlier, we do not allow taking only >part of the SPD sets, nor do we allow arbitrary subsets created by the >initiator. > >The result of the negotiation might be arbitrary subset of the SPD if >the SPD entries in each end are different. sure. > >> Does this help? > >I think so. The PFP constructs helps to understand issue better. But, you did raise some good issues about what to do when a SPD entry contains multiple selector sets, one or more of which have PFP selectors. My suggestion is that we should create exactly one SA as a result of a packet triggering SA creation. We should examine each selector set in the entry. When we encounter a selector set with no PFP fields, we just include it in the proposal. If a selector set has one or more PFP fields, and if ALL of the fields in the packet are consistent with the ranges for the selectors in the set, then that should yield one additional proposal. Comments? Steve From owner-ipsec@lists.tislabs.com Wed Oct 15 16:42:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FNgLI7097261; Wed, 15 Oct 2003 16:42:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28390 Wed, 15 Oct 2003 18:54:56 -0400 (EDT) Message-ID: <3F8C6F4A.4040208@americasm06.nt.com> Date: Tue, 14 Oct 2003 17:48:58 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: "Lakshminath Dondeti" , charliek@microsoft.com Subject: Re: IKEv2 Correction (editorial) References: <3F8C3910.4070907@americasm06.nt.com> In-Reply-To: <3F8C3910.4070907@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hate to lose the original point of the message in the MUST/SHOULD discussion on RESERVED fields: In Section 3.3.2, Figure 8 of ikev2-11, the second RESERVED field should be 2 octets in length. Lakshminath Dondeti, Lakshminath wrote: > In Section 3.3.2, Figure 8 of ikev2-11, the second RESERVED field > should be 2 octets in length. > > The description below should say something like: > > RESERVED2 - MUST be sent as zero; MUST be ignored on receipt. > > > > thanks, > Lakshminath > From owner-ipsec@lists.tislabs.com Thu Oct 16 05:29:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCTSI7085475; Thu, 16 Oct 2003 05:29:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01450 Thu, 16 Oct 2003 07:37:06 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16270.33969.191837.412099@ryijy.hel.fi.ssh.com> Date: Thu, 16 Oct 2003 14:44:49 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Issue #82: Creation of SAs -- clarifications In-Reply-To: References: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> <16269.8775.274049.236055@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >I.e if the SPD says: > > > > Entry 1 > > set 1 (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > > set 2 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) > > I assume you are ignoring all the other selectors here and focusing > only on the IP addresses, and I assume the "<->" notation is some > sort of separator for source and destination address, right? Yes. > >and we have packet with 10.source 10.0.0.22 and destination 10.0.1.5 > >then we can create either SA directly from the packet > I assume the "10.source is a typo and is supposed to be a source > address of 10.0.0.22, right? Yes. > > SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5) > > this result is consistent with the source addresses in set 1 and set > 2 not marked as PFP, but the destination address in both was marked > PFP (I guess). Isn't it enough for the set 1 destination address to be marked as PFP to generate this SA? Actually do we have any cases where we want to have set 1 source address set marked as PFP but not in the set 2? I.e should the PFP marker be for the whole entry per field, or for each set per each field? > >Do we want to allow creation of following SA: > > > > SA (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > > > >I.e take the selector set 1 from the SPD and create SA based on that, > >but leave out selector set 2? > > you have not said which of the address selectors are marked as PFP, > so I am not sure how to interpret this one. if none of the selectors > in set 2 is marked as PFP, then this should not be negotiated. > > >Or any arbitrary subset: > > > > SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9) > > PFP does not seem to be relevant to this sort of subset negotiation, > as PFP always nails down a selector for an SA to a single value, not > a range. That was my impression also, so we do not need to allow that kind of subsets, i.e we only allow either PFP or full SPD entry per each field: > >Ok, se only possible values given to IKE are either the whole SPD > >entry (+the actual value from packet) or only the value from packet > >per each field in selector. > > right > >Note, that IKEv2 will need the exact values from the packet regardless > >whether the final entry is created based on SPD or from the value of > >the packet. > right, this is a big change from v1, and not anticipated in the PFP > notion when it was created. but, the intent is different, i.e., in > IKE v2 we pass the original packet selectors in an effort to make it > easier to have two peers establish an acceptable SA without mandating > identical SPD entries. it is not trying to create a series of > distinct SAs, from one SPD entry, in response to transmission of > different packets. It can cause series of distinct SAs to be created, but at most one SA (pair) per packet, i.e each negotiation created based on the packet will create at most one SA (pair) which can handle the packet in question. The next packet can cause new SA (pair) to be created from the same SPD as the previous SA might not be able to handle that new packet with different values. This can happen either because of the PFP flags or because the other end had different SPD than what this end have. > But, you did raise some good issues about what to do when a SPD entry > contains multiple selector sets, one or more of which have PFP > selectors. My suggestion is that we should create exactly one SA as > a result of a packet triggering SA creation. We should examine each > selector set in the entry. When we encounter a selector set with no > PFP fields, we just include it in the proposal. If a selector set has > one or more PFP fields, and if ALL of the fields in the packet are > consistent with the ranges for the selectors in the set, then that > should yield one additional proposal. That seems to be right. I.e we always try to minimize the amount of SAs created per each SPD, and try to offer to the other end the maximal selector set following our SPD. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 16 07:46:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GEk6I7090487; Thu, 16 Oct 2003 07:46:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02155 Thu, 16 Oct 2003 09:53:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16270.33969.191837.412099@ryijy.hel.fi.ssh.com> References: <16268.5342.104995.706128@ryijy.hel.fi.ssh.com> <16269.8775.274049.236055@ryijy.hel.fi.ssh.com> <16270.33969.191837.412099@ryijy.hel.fi.ssh.com> Date: Thu, 16 Oct 2003 10:02:13 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Issue #82: Creation of SAs -- clarifications Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, >Stephen Kent writes: >> >I.e if the SPD says: >> > >> > Entry 1 >> > set 1 (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255) > > > set 2 (192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255) >> >> I assume you are ignoring all the other selectors here and focusing >> only on the IP addresses, and I assume the "<->" notation is some > > sort of separator for source and destination address, right? > > > > SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5) >> >> this result is consistent with the source addresses in set 1 and set >> 2 not marked as PFP, but the destination address in both was marked >> PFP (I guess). > >Isn't it enough for the set 1 destination address to be marked as PFP >to generate this SA? I'm not sure. Certainly if the dest address in both sets are marked PFP, this would result. If only the set 1 dest address is PFP, then I might expect to see two proposals: SA (10.0.0.0-10.0.0.255, <-> 10.0.1.5) SA (192.168.2.0-192.168.2.255, 10.0.1.0-10.0.1.255) rather than the one, merged example you described. But, I'm not sure. >Actually do we have any cases where we want to have set 1 source >address set marked as PFP but not in the set 2? I.e should the PFP >marker be for the whole entry per field, or for each set per each >field? I think it would be easier to understand that way, and I am in favor of not making this any more complex. So, I'm happy to impose this simplification unless anyone objects. Steve From bcharles_11@email.com Thu Oct 16 07:48:17 2003 Received: from 9999-1UPV6CKRZ0 ([61.105.72.167]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9GEmGI7090629 for ; Thu, 16 Oct 2003 07:48:17 -0700 (PDT) (envelope-from bcharles_11@email.com) Message-Id: <200310161448.h9GEmGI7090629@above.proper.com> From: "bpalprint@yahoo.com" To: "ietf-ipsec@imc.org" Subject: join the many Americans enlarging their penises! 4u3243280432 Date: Sat, 15 Jan 2005 23:48:48 +0900 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9yPSIjMzMzMzk5Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+ PGJyPjxzZmQ4dWE+DQo8dGFibGUgd2lkdGg9NTAwcHg+DQo8dHI+DQo8dGQgYmdjb2xvcj0ibmF2 eSIgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0idmVyZGFuYSIgc2l6ZT0yIGNvbG9yPSJ5ZWxs b3ciPjEwMCUgR3VhcmFudGVlZCBSZXN1bHRzIE9yIFlvdXIgTW9uZXkgQmFjaw0KPC90cj4NCjx0 cj48dGQgYmdjb2xvcj0iYmx1ZSIgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0idmVyZGFuYSIg c2l6ZT00IGNvbG9yPSJ3aGl0ZSI+PGI+DQo8YnI+DQpMaWtlIGJpZyB0aXRzPyBHaXJscyBsaWtl IGJpZyBkaWNrcyEgaWYgeW91IGRvbid0IGhhdmUgb25lIEdFVCBPTkUuPGJyPjxicj4NCjwhLS0g c2ZkOHVhIC0tPg0KV291bGQgeW91IGZlZWwgbW9yZSBjb25maWRlbnQgaGF2aW5nIGEgYmlnIHNl eHkgZGljayBkb3duIHRoZXJlPyBXaXZlcyAmIEdpcmxmcmllbmRzIHdpbGwgc3VjayBpdCBtb3Jl ITxicj48YnI+DQpPdXIgcGVuaXMgcGlsbHMgbWFrZSB1cCBmb3Igd2hhdCBtb3RoZXIgbmF0dXJl IGZvcmdvdCEgR2V0IGEgbW9udGhzIHN1cHBseSBhbmQgbm90aWNlIHRoZSBkaWZmZXJlbmNlITxi cj48YnI+DQo8QSBocmVmPSJodHRwOi8vbW9ndWxzQHd3dy5oZXJiYWwtdXNhLnVzL3doaXRlbGlu ZS92cC8iPjxmb250IGNvbG9yPSJ5ZWxsb3ciPlRha2UgYSBsb29rIGF0IGhvdyBpdCB3b3Jrczwv YT48YnI+PGJyPg0KPC90ZD48L3RyPg0KPHRyPg0KPHRkIGJnY29sb3I9Im5hdnkiIGFsaWduPSJj ZW50ZXIiPjxmb250IGZhY2U9InZlcmRhbmEiIHNpemU9MiBjb2xvcj0ieWVsbG93Ij5Xb3JsZHMg TW9zdCBFZmZlY3RpdmUgRW5sYXJnZW1lbnQgVGVjaG5pcXVlDQo8L3RyPg0KPC90YWJsZT48c2Zk OHVhPg0KPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj4NCjxmb250IHNpemU9IjFweCIg ZmFjZT0idmVyZGFuYSIgY29sb3I9IiMwMDAwMCI+c2ZkOHVhIHNmZDh1YSBzZmQ4dWE8L2ZvbnQ+ DQo8c2ZkOHVhPg0KPGEgaHJlZj0iaHR0cDovL21vZ3Vsc0B3d3cuaGVyYmFsLXVzYS51cy93aGl0 ZWxpbmUvb3V0Lmh0bWwiPjxmb250IGNvbG9yPSJ5ZWxsb3ciIHNpemU9IjIiPnRvIGdldCBvZmY8 L2E+DQo8L2JvZHk+DQo8L2h0bWw+DQo= From x12tlrzesl@yahoo.com Thu Oct 16 22:05:31 2003 Received: from rly-ip04.mx.aol.com (rly-ip04.mx.aol.com [64.12.138.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H55VI7030195; Thu, 16 Oct 2003 22:05:31 -0700 (PDT) (envelope-from x12tlrzesl@yahoo.com) Received: from logs-wb.proxy.aol.com (logs-wb.proxy.aol.com [205.188.192.135]) by rly-ip04.mx.aol.com (v95.1) with ESMTP id RELAYIN1-23f8f7866334; Fri, 17 Oct 2003 01:04:38 2000 Received: from AC89D69C.ipt.aol.com (AC89D69C.ipt.aol.com [172.137.214.156]) by logs-wb.proxy.aol.com (8.12.10/8.12.10) with SMTP id h9H51a0G124803; Fri, 17 Oct 2003 05:01:43 GMT Received: from [35.44.63.237] by AC89D69C.ipt.aol.com with ESMTP id <650117-25375> for ; Fri, 17 Oct 2003 02:54:49 -0300 Message-ID: <9$i4g-okn36visl@2dfz86lt> From: "Estella Chapman" Reply-To: "Estella Chapman" To: ietf-ipsec@imc.org Subject: do you have your Degree? dcpghrouei Date: Fri, 17 Oct 03 02:54:49 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B2FA__22383BCB4DA9C." X-Priority: 1 X-MSMail-Priority: High X-Apparently-From: TwinEagle01@aol.com X-AOL-IP: 205.188.192.135 --B2FA__22383BCB4DA9C. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


=
. U N I V E R S I T Y D I P L O M A S .
Do you want a prosperous future, increased money earning power, and the respect of all?

We can assist with Diplomas from prestigious non-accredited universities based on your present knowledge and life experience.


No required tests, classes, books, or interviews.

Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice - that's right, you can become a Doctor and receive all the benefits and admiration that comes with it!

No one is turned down.

Confidentiality assured


CALL US  24 HOURS A DAY, 7 DAYS  A WEEK

  (including Sundays and holidays):

1-646-304-8665

Contact us NOW to receive your diploma within days, and start improving your life!
px cln ct txcvvnnulm mhmy utacyj wfdjl voauhyj f i --B2FA__22383BCB4DA9C.-- From owner-ipsec@lists.tislabs.com Fri Oct 17 09:48:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HGmPI7017225; Fri, 17 Oct 2003 09:48:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08307 Fri, 17 Oct 2003 11:54:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Fri, 17 Oct 2003 12:02:44 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: revised processing model, take II Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Revised IPsec subscriber traffic processing model (take II) The current IPsec subscriber traffic processing model, as defined in 2401, is imprecise in several respects, and it does not accommodate some significant new IPsec scenarios that have arisen since 2401 was published , e.g., PPVPNs and overlay nets. Also, just as we have created the extended sequence number facility for AH and ESP to accommodate high speed (10Gb/s and beyond) implementations, there are changes one can make to the processing model to better accommodate traffic classification for outbound traffic. Finally, there are some simplifications one can make to the mode, consistent with the overall push for implementation simplification. This model is intended to apply to all the types of IPsec implementations previously identified: security gateway (SG), native host, BITS, and BITW. In some instances the model emphasizes features that help SG and BITW/BITS implementations improve performance; native host implementations generally will neither benefit nor be adversely affected by such features. Several concepts underlie the proposed model: The revised model provides a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only one or two interfaces, or it may be complex, e.g., if there are multiple red or black interfaces or if the context in which IPsec is implemented employs a sophisticated a forwarding function. IPsec assumes only that outbound and inbound traffic that has passed through IPsec processing is forwarded in a fashion consistent with the context in which IPsec is implemented. The SPD changes in several ways. SPDs are no longer required to be defined on a per interface basis. Thus an IPsec implementation MUST have at least one SPD, and it MAY support multiple SPDs, if appropriate for the context in which the IPsec implementation operates. An explicit SPD selection function is invoked to select the appropriate SPD for outbound traffic processing. The inputs to this function are the outbound packet and local metadata (e.g., the interface via which the packet arrived). The output of the function is an SPD ID. However, we split each SPD into three pieces: one is applied to all traffic that is to be subject to IPsec protection (SPD-S), one applied to all outbound traffic that is to be bypassed or discarded (SPD-O), and one applied to inbound traffic that will be bypassed or discarded (SPD-I). If an IPsec implementation supports only one SPD, then the SPD consists of all three parts. If multiple SPDs are supported, some of them may be partial, e.g., some SPDs may contain only SPD-I entries, to control inbound bypassed traffic on a per-interface basis. Entries in each SPD are still directional, but we have changed the terminology to reflect the fact that inbound and outbound SPD entries are not really independent, but rather are usually created as matching pairs. So, rather than speaking of separate inbound and outbound SPDs, we speak in terms of an SPD entry containing sets of values that define handling of inbound and outbound traffic. The SPD entries are also more powerful than before, consistent with the new capabilities of IKEv2. Thus an SPD entry is defined as a list of one or more selector set pairs. Each selector set pair consists of one selector set for outbound traffic and one selector set for inbound traffic. Each selector set consists of five types of selectors: - a source IP address range - a destination IP address range - a next layer protocol value (or OPAQUE, or ANY) - a source port range (or OPAQUE) - a destination port range (or OPAQUE) Also, each entry specifies packet disposition as BYPASS, DISCARD or IPsec. If IPsec processing is specified for an entry, a "populate from packet" (PFP) flag may be associated with one or more of the selector types in the SPD entry. If present, the flag applies to all selectors of the indicated type in the outbound element of the pair. (PFP does not apply to inbound traffic.) The old processing model refers to searching an SPD for each outbound packet to determine how to process it, and to check inbound traffic after IPsec processing against the SPD, to ensure that traffic arriving on an SA is consistent with the selectors defined when the SA was created. For SG, BITS, and BITW implementations, this is a potentially time consuming, linear search process, because of the need to search the SPD entries in the order specified by the administrator or user who created them. For native host implementations, there is already an implicit form of caching at work, in general. This is because it is common for a native host implementation to associate the SPD data that would be cached with a socket, thus avoiding the need to search the SPD for each packet sent or received via the socket interface. The search process also is ambiguous as currently defined. To simplify the process, and to allow for very fast SA lookups (for SG/BITS/BITW), we introduce the notion of an SPD cache for all outbound traffic. There is nominally one cache per SPD. Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry whereas a search of the SPD would have resulted in a match against a different entry. But, if we decorrelate the SPD, then the resulting entries can safely be cached, and each cached entry will map to an SA, or indicate that matching traffic should be bypassed or discarded, appropriately. For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving packets. For inbound BYPASS or DISCARD traffic, a cache of the SPD-I also is maintained, to facilitate fast processing. An algorithm for decorrelation was published as an ID some time ago, and there is at least one paper on the topic published as well. 2401bis will not mandate a specific algorithm for decorrelation, but will include an example in an appendix. With these concepts in mind, we can describe the revised model. First we examine the path for traffic entering the implementation via a red interface and exiting via a black interface. Outbound traffic processing (red-to-black) 1. when a packet arrives from the subscriber (red) interface, invoke the SPD lookup function to select the appropriate SPD. (if the implementation uses only one SPD, this step is a no-op.) 2. match the packet headers against the cache for the SPD specified by the SPD-ID from step 1 3a. if there is a match, then process the packet as specified by the matching cache entry, i.e., bypass, discard, or apply AH or ESP in the specified mode. If IPsec processing is applied, there is a link from the SPD cache entry to the relevant SAD entry (specifying the algorithms, keys, SPI, etc.). IPsec processing is as previously defined, for tunnel or transport modes and for AH or ESP, as specified. 3b. if no match is found in the cache, search the SPD (SPD-S and SPD-O parts) specified by SPD-ID. If the SPD entry calls for bypass or discard, create new outbound and inbound SPD cache entries. If the SPD entry calls for creation of an SA, the key management mechanism (e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a new outbound cache entry is created, along with an SAD entry, otherwise the packet is discarded. (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it may be processed against the newly created cache entry, if one is created.) The SAD entry contains the selector values derived from the SPD entry used to create this SA. 4. The packet is passed on to the outbound forwarding function (operating outside of the IPsec boundary), to select the interface to which the packet will be directed. Inbound Traffic Processing (black-to-red) Inbound processing is somewhat different, because of the use of SPIs to map IPsec traffic to SAs. The inbound SPD cache is applied only to bypassed or discarded traffic, and the inbound SPP lookup is applied only to the SPD-I part of an SPD. If an arriving packet appears to be a black IPsec fragment, reassembly is performed prior to the IPsec processing. 0. When a packet arrives, it may be tagged with the ID of the interface (physical or virtual) via which it arrived, if necessary to support multiple SPDs with different SPD-I entries. 1. the packet it is examined and demuxed into one of three categories: - If the packet appears to be IPsec protected and it is addressed to this IPsec device, it is directed to SPI lookup. - ICMP traffic directed to this device is directed to black ICMP processing. - traffic not addressed to this device is directed to BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag assigned to the packet in step 0 is used to select the appropriate SPD-I (and cache) to search. 2a. If the packet is addressed to the device and AH or ESP is specified as the protocol, lookup the packet in the SAD. For unicast traffic, use only the SPI. For multicast traffic, use the SPI plus the source and/or destination addresses, as specified in the SAD. If there is no match, discard the traffic. If the packet is found in the SAD, process it accordingly (see step 3). 2b. If the packet is not addressed to the device, lookup the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, lookup the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec; only bypass or discard entries can be created this way.) 2c. Black ICMP processing examines ICMP traffic and applies local policy to determine whether to accept of reject these messages and, if accepted, what action to take as a result. For example, if an ICMP unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. (This is a separate 2401bis discussion topic.) 3. Apply AH or ESP as specified, using the SAD entry selected in step 2a above. Then match the packet against the inbound selectors in the SAD entry to verify that the received packet is appropriate for the SA via which it was received. After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. Epilogue This processing model is simpler and less vague than the old model, and it offers the potential for higher speed processing of traffic, through the use of caches. Under this model, there is no explicit support for nested security associations or SA bundles. These features, which were specified in 2401, but which do not appear to be widely implemented, still can be effected by appropriate configuration of both the SPD and the local forwarding function, but this function is outside of the IPsec module and thus the scope of this spec. As a result, management of nested/bundled SAs is potentially more complex and less assured. From owner-ipsec@lists.tislabs.com Fri Oct 17 15:14:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HMEJI7027861; Fri, 17 Oct 2003 15:14:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10060 Fri, 17 Oct 2003 17:30:17 -0400 (EDT) Message-Id: <5.2.0.9.0.20031017165645.02154e48@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 17 Oct 2003 17:31:33 -0400 To: Tero Kivinen , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: 2401bis issues (red side frag) In-Reply-To: <16269.6172.906127.369445@ryijy.hel.fi.ssh.com> References: <5.2.0.9.0.20031014162123.02d5d0c8@email> <200310141632.h9EGWVCI025756@coredump.cs.columbia.edu> <5.2.0.9.0.20031014162123.02d5d0c8@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:49 PM 10/15/2003 +0300, Tero Kivinen wrote: ... >I.e there will not be special flag for SA that means that red >fragments OK for this SA. So if red fragments are not going to have >special inbound handling the issue 81 which proposed creating special >SA for outbound to them should be reject too. > >So the special treatment was proposed. I don't think we have any issue >in the issue tracker about whether the 2401bis should or should not >permit red-side fragmentation. Hi all, I would like to request that 2401bis lift the prohibition on red-side fragmentation by SG, BITS, BITW. Red side fragmentation when employed can reduce the reassembly burden on the IPsec receiver, and with it some potential for DOS attack. It can also increase the performance of the overall solution, by distributing the reassembly burden to end hosts. I know of at least one vendor that offers a red-side fragmentation option now, and I believe that other vendors do so as well. After applying red-side fragmentation, the IPsec device would evaluate the SPD for each fragment just as though the fragments had been received from the black side. Fragments not containing port numbers can only match a rule with port selectors equal to "wildcard" or "opaque", or rules for protocols where port numbers are not used. Since this behavior is pretty much indistinguishable from fragmentation that may occur anyway upstream of the IPsec device, I do not see any reason to disallow it. I propose text such as the following, added somewhere in the outbound processing description: An SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers may only match rules having port selectors of "opaque" or "wildcard". Thanks, Mark P.S. Issues 49 and 81, which requested *special handling* for red-side fragmentation have been rejected. This request is NOT the same as those and is in fact much simpler. From owner-ipsec@lists.tislabs.com Sat Oct 18 01:14:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I8EOI7084085; Sat, 18 Oct 2003 01:14:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12333 Sat, 18 Oct 2003 03:31:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Sat, 18 Oct 2003 03:44:21 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis-00 submitted to IETF Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, I just submitted 2401bis-00 to the IETF publications folks. This draft: a. incorporates changes for all the issues that seem reasonably settled. b. indicates the sections that may change based on unresolved issues (below). The issues that are not included are: 40,44,45 new processing model 46 nested/bundled SAs 49 red sided fragmentation (haven't heard back from Mark Duffy re: suggestion about OPAQUE ports) 50/85 I put in a version of your text but this issue is clearly still on the list from a MAY vs MUST point of view and because they've issued a new proposed paragraph (issue 87) 67 IPsec management traffic destined locally 75 TOS (now DSCP/ECN) copying in tunnel mode 82 clarification re: creation of SAs 85 dropped inbound packet -- does not match SA Please note that Steve provided numerous inputs but in an attempt to maintain plausible deniability, he spent 2 weeks in Europe, was back for 3 days and then flew away to Washington for meetings on Thursday and Friday. So he did not get to review this draft. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Oct 20 11:15:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KIFtI7002416; Mon, 20 Oct 2003 11:15:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26925 Mon, 20 Oct 2003 13:00:16 -0400 (EDT) From: "Mike Taylor" To: "Mark Duffy" , "Stephen Kent" Cc: Subject: RE: SPD issues Date: Mon, 20 Oct 2003 10:09:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.2.0.9.0.20031014234014.0214b190@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 Mark Duffy > Sent: Tuesday, October 14, 2003 8:56 PM > To: Stephen Kent > Cc: ipsec@lists.tislabs.com > Subject: Re: SPD issues > > > At 07:03 PM 10/14/2003 -0400, Stephen Kent wrote: > >Mark, > > > >> > >> > >> > >>> - My previous proposal for a revised processing model, from a > >>> few weeks ago, retained the idea of multiple SPDs, allocating them to > >>> virtual interfaces, and introduced the notion of a forwarding > function > >>> to select the right virtual interface, and thus SPD. But, unless we > >>> feel a need to have different SPDs per interface, this seems like > >>> overkill. I think we do want to allow forwarding of outbound > traffic to > >>> be independent of SPD selection, so some notion of an explicit > >>> forwarding function in the model still seems appropriate. but, as we > >>> discussed the model, there was a suggestion that we might > need two such > >>> functions, one to select an SPD, and then one to be applied > after IPsec > >>> processing. maybe, if we separate SPD selection from interface > >>> selection we can have two functions but only one of them is > really for > >>> forwarding. > >> > >>I am all for separating the "SPD selection function" from the "IP > >>forwarding function". (Once that is done though, I don't see > why the IP > >>forwarding function is any concern of IPsec's.) > > > >I think we have to say something about options for how forwarding > >decisions can be made in the context of IPsec, especially in tunnel mode. > > How about: > > For packets that "bypass" IPsec processing, and for packets that arrive > with IPsec protection which is removed at the device, the IP output > interface and next hop are selected by the normal IP forwarding mechanism > of the device [which would be beyond the scope of 2401bis] applied to the > plaintext packet. > > For packets that have IPsec applied to them by the device (tunnel or > transport mode) the IP output interface and next hop are selected by the > normal IP forwarding mechanism of the device applied to the IPsec packet. This wording is not sufficiently clear as their is quite a difference between the routing applied *after* IPSec processing in tunnel mode, and the routing required to get a red datagram to IPSec, i.e., either to some virtual or real interface to which an SPD is attached that has a policy relevant to the datagram. In the latter, the route may very well not be "real" in the sense that it may exist solely for the purpose of getting the red datagram to IPSec, and in fact the destination IP address may be some private address (with IPSec in tunnel mode) that couldn't possibly be reached via the public Internet by a conventional (non-VPN) forwarding decision. In a purist sense the solution to these issues falls into the realm of implementation details that don't really need to be specified in 2401bis. I don't think 2401bis should require, for example, virtual interfaces as a solution. Rather, there should be an appendix in 2401bis with suggested implementations such as the use of virtual interfaces, or what have you. It should point out any known pitfalls (security issues) with various implementation choices. But that's just my 2 cents worth. It seems to me that the real issue here goes to the heart of the original principals of IP networking. An IP network ideally ought to be a bunch of networks connected together by boxes whose sole function is to perform the forwarding function. All other processing really ought to be done by the hosts connected to those networks, just as the "forefathers" knew that reliable data exchange should be accomplished by the end-points using a transport level protocol (TCP) running over an unreliable best effort datagram delivery service, rather than by having per-link error correction as in X.25. So (as the IPv6 folks have recognized) security must ultimately also be done end-to-end. A security gateway is no more and no less an abomination than a NAT box and ideally should be viewed as a temporary solution until we have full end-to-end security. But of course, it is very likely that this utopian vision won't come to pass in my lifetime. > > And for packets that have a "drop" action selected, the document > can remain > silent. After all, the world would be rendered uninteresting if all > mystery were removed ;-) > > Mark > From owner-ipsec@lists.tislabs.com Mon Oct 20 12:20:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJKXI7004834; Mon, 20 Oct 2003 12:20:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27267 Mon, 20 Oct 2003 14:30:37 -0400 (EDT) Message-Id: <5.2.0.9.0.20031020142118.020310d8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 20 Oct 2003 14:38:29 -0400 To: "Mike Taylor" , "Stephen Kent" , ipsec@lists.tislabs.com From: Mark Duffy Subject: RE: SPD issues In-Reply-To: References: <5.2.0.9.0.20031014234014.0214b190@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, see below... At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote: [...] > > > [SK] I think we have to say something about options for how forwarding > > >decisions can be made in the context of IPsec, especially in tunnel mode. > > > > [MD] How about: > > > > For packets that "bypass" IPsec processing, and for packets that arrive > > with IPsec protection which is removed at the device, the IP output > > interface and next hop are selected by the normal IP forwarding mechanism > > of the device [which would be beyond the scope of 2401bis] applied to the > > plaintext packet. > > > > For packets that have IPsec applied to them by the device (tunnel or > > transport mode) the IP output interface and next hop are selected by the > > normal IP forwarding mechanism of the device applied to the IPsec packet. > >[MT] This wording is not sufficiently clear as their is quite a difference >between >the routing applied *after* IPSec processing in tunnel mode, and the routing >required to get a red datagram to IPSec, i.e., either to some virtual or >real >interface to which an SPD is attached that has a policy relevant to the >datagram. >In the latter, the route may very well not be "real" in the sense that it >may >exist solely for the purpose of getting the red datagram to IPSec, and in >fact the >destination IP address may be some private address (with IPSec in tunnel >mode) >that couldn't possibly be reached via the public Internet by a conventional >(non-VPN) forwarding decision. My understanding of the proposed model is that the IPsec device has an "SPD selection function" that choses the SPD to use; how the choice is made is implementation dependent. This replaces (or rather, enlarges on) the SPD-per-interface model of 2401. I believe that that SPD selection function fills the role of the "routing required to get a red datagram to IPSec" in your message above. >In a purist sense the solution to these issues falls into the realm of >implementation >details that don't really need to be specified in 2401bis. I don't think >2401bis >should require, for example, virtual interfaces as a solution. Nor do I. Which is why I personally find the idea of an "SPD selection function" attractive. Trying to disguise the SPD selection function as a "forwarding decision" just adds confusion. So, there is an SPD selection function that chooses an SPD. And there is an IP forwarding function that selects a next hop to forward a datagram to. And the two may be comepletely independent or completely entwined, depending on the nature of the device. Makes sense? --Mark From owner-ipsec@lists.tislabs.com Mon Oct 20 13:31:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KKVwI7008316; Mon, 20 Oct 2003 13:31:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27643 Mon, 20 Oct 2003 15:42:04 -0400 (EDT) From: "Mike Taylor" To: "Mark Duffy" Cc: "Mike Taylor" , "Stephen Kent" , Subject: RE: SPD issues Date: Mon, 20 Oct 2003 12:51:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.2.0.9.0.20031020142118.020310d8@email> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Monday, October 20, 2003 11:38 AM > To: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com > Subject: RE: SPD issues > > > Hi Mike, see below... > > At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote: > [...] > > > > [SK] I think we have to say something about options for how > forwarding > > > >decisions can be made in the context of IPsec, especially in > tunnel mode. > > > > > > [MD] How about: > > > > > > For packets that "bypass" IPsec processing, and for packets > that arrive > > > with IPsec protection which is removed at the device, the IP output > > > interface and next hop are selected by the normal IP > forwarding mechanism > > > of the device [which would be beyond the scope of 2401bis] > applied to the > > > plaintext packet. > > > > > > For packets that have IPsec applied to them by the device (tunnel or > > > transport mode) the IP output interface and next hop are > selected by the > > > normal IP forwarding mechanism of the device applied to the > IPsec packet. > > > >[MT] This wording is not sufficiently clear as their is quite a > difference > >between > >the routing applied *after* IPSec processing in tunnel mode, and > the routing > >required to get a red datagram to IPSec, i.e., either to some virtual or > >real > >interface to which an SPD is attached that has a policy relevant to the > >datagram. > >In the latter, the route may very well not be "real" in the sense that it > >may > >exist solely for the purpose of getting the red datagram to IPSec, and in > >fact the > >destination IP address may be some private address (with IPSec in tunnel > >mode) > >that couldn't possibly be reached via the public Internet by a > conventional > >(non-VPN) forwarding decision. > > My understanding of the proposed model is that the IPsec device > has an "SPD > selection function" that choses the SPD to use; how the choice is made is > implementation dependent. This replaces (or rather, enlarges on) the > SPD-per-interface model of 2401. I believe that that SPD selection > function fills the role of the "routing required to get a red datagram to > IPSec" in your message above. > > >In a purist sense the solution to these issues falls into the realm of > >implementation > >details that don't really need to be specified in 2401bis. I don't think > >2401bis > >should require, for example, virtual interfaces as a solution. > > Nor do I. Which is why I personally find the idea of an "SPD selection > function" attractive. Trying to disguise the SPD selection function as a > "forwarding decision" just adds confusion. > > So, there is an SPD selection function that chooses an SPD. And there is > an IP forwarding function that selects a next hop to forward a datagram > to. And the two may be comepletely independent or completely entwined, > depending on the nature of the device. > > Makes sense? Yes, absolutely. That language should be sufficient. Thanks Mark, Mike > > --Mark > > From owner-ipsec@lists.tislabs.com Mon Oct 20 14:44:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KLi0I7011109; Mon, 20 Oct 2003 14:44:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28117 Mon, 20 Oct 2003 16:52:05 -0400 (EDT) Message-ID: <3F944CFA.8060009@isi.edu> Date: Mon, 20 Oct 2003 14:00:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Mike Taylor , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SPD issues References: <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> In-Reply-To: <5.2.0.9.0.20031020142118.020310d8@email> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > Hi Mike, see below... > > At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote: > [...] > >> > > [SK] I think we have to say something about options for how >> forwarding >> > >decisions can be made in the context of IPsec, especially in tunnel >> mode. >> > >> > [MD] How about: >> > >> > For packets that "bypass" IPsec processing, and for packets that arrive >> > with IPsec protection which is removed at the device, the IP output >> > interface and next hop are selected by the normal IP forwarding >> mechanism >> > of the device [which would be beyond the scope of 2401bis] applied >> to the >> > plaintext packet. >> > >> > For packets that have IPsec applied to them by the device (tunnel or >> > transport mode) the IP output interface and next hop are selected by >> the >> > normal IP forwarding mechanism of the device applied to the IPsec >> packet. >> >> [MT] This wording is not sufficiently clear as their is quite a >> difference >> between >> the routing applied *after* IPSec processing in tunnel mode, and the >> routing >> required to get a red datagram to IPSec, i.e., either to some virtual or >> real >> interface to which an SPD is attached that has a policy relevant to the >> datagram. >> In the latter, the route may very well not be "real" in the sense that it >> may >> exist solely for the purpose of getting the red datagram to IPSec, and in >> fact the >> destination IP address may be some private address (with IPSec in tunnel >> mode) >> that couldn't possibly be reached via the public Internet by a >> conventional >> (non-VPN) forwarding decision. > > > My understanding of the proposed model is that the IPsec device has an > "SPD selection function" that choses the SPD to use; how the choice is > made is implementation dependent. This replaces (or rather, enlarges > on) the SPD-per-interface model of 2401. I believe that that SPD > selection function fills the role of the "routing required to get a red > datagram to IPSec" in your message above. > >> In a purist sense the solution to these issues falls into the realm of >> implementation >> details that don't really need to be specified in 2401bis. I don't think >> 2401bis >> should require, for example, virtual interfaces as a solution. > > Nor do I. Which is why I personally find the idea of an "SPD selection > function" attractive. Trying to disguise the SPD selection function as > a "forwarding decision" just adds confusion. > > So, there is an SPD selection function that chooses an SPD. And there > is an IP forwarding function that selects a next hop to forward a > datagram to. And the two may be comepletely independent or completely > entwined, depending on the nature of the device. It's the entwined case that presents the largest problem. I.e., if the SPD selection is based on forwarding information that then changes by the time the subsequently tunneled (or not tunneled) packet is emitted from IPsec. This could happen whether dynamic or static routing is used; the issue is flux in the forwarding table and whether it is _allowed_ to affect SPD selection. Calling the function "SPD selection" doesn't absolve the problem. Joe From owner-ipsec@lists.tislabs.com Mon Oct 20 16:37:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KNbpI7014495; Mon, 20 Oct 2003 16:37:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28775 Mon, 20 Oct 2003 18:40:39 -0400 (EDT) From: "Mike Taylor" To: "Joe Touch" , "Mark Duffy" Cc: "Mike Taylor" , "Stephen Kent" , Subject: RE: SPD issues Date: Mon, 20 Oct 2003 15:49:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F944CFA.8060009@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Monday, October 20, 2003 2:01 PM > To: Mark Duffy > Cc: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com > Subject: Re: SPD issues > > > > > Mark Duffy wrote: > > > Hi Mike, see below... > > > > At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote: > > [...] > > > >> > > [SK] I think we have to say something about options for how > >> forwarding > >> > >decisions can be made in the context of IPsec, especially in tunnel > >> mode. > >> > > >> > [MD] How about: > >> > > >> > For packets that "bypass" IPsec processing, and for packets > that arrive > >> > with IPsec protection which is removed at the device, the IP output > >> > interface and next hop are selected by the normal IP forwarding > >> mechanism > >> > of the device [which would be beyond the scope of 2401bis] applied > >> to the > >> > plaintext packet. > >> > > >> > For packets that have IPsec applied to them by the device (tunnel or > >> > transport mode) the IP output interface and next hop are selected by > >> the > >> > normal IP forwarding mechanism of the device applied to the IPsec > >> packet. > >> > >> [MT] This wording is not sufficiently clear as their is quite a > >> difference > >> between > >> the routing applied *after* IPSec processing in tunnel mode, and the > >> routing > >> required to get a red datagram to IPSec, i.e., either to some > virtual or > >> real > >> interface to which an SPD is attached that has a policy relevant to the > >> datagram. > >> In the latter, the route may very well not be "real" in the > sense that it > >> may > >> exist solely for the purpose of getting the red datagram to > IPSec, and in > >> fact the > >> destination IP address may be some private address (with IPSec > in tunnel > >> mode) > >> that couldn't possibly be reached via the public Internet by a > >> conventional > >> (non-VPN) forwarding decision. > > > > > > My understanding of the proposed model is that the IPsec device has an > > "SPD selection function" that choses the SPD to use; how the choice is > > made is implementation dependent. This replaces (or rather, enlarges > > on) the SPD-per-interface model of 2401. I believe that that SPD > > selection function fills the role of the "routing required to get a red > > datagram to IPSec" in your message above. > > > >> In a purist sense the solution to these issues falls into the realm of > >> implementation > >> details that don't really need to be specified in 2401bis. I > don't think > >> 2401bis > >> should require, for example, virtual interfaces as a solution. > > > > Nor do I. Which is why I personally find the idea of an "SPD selection > > function" attractive. Trying to disguise the SPD selection function as > > a "forwarding decision" just adds confusion. > > > > So, there is an SPD selection function that chooses an SPD. And there > > is an IP forwarding function that selects a next hop to forward a > > datagram to. And the two may be comepletely independent or completely > > entwined, depending on the nature of the device. > > It's the entwined case that presents the largest problem. I.e., if the > SPD selection is based on forwarding information that then changes by > the time the subsequently tunneled (or not tunneled) packet is emitted > from IPsec. By the forwarding information changing do you really mean that the forwarding database changes? Assuming so, then I hadn't thought much about that case yet but here's how I see it so far. This description refers to a native IPSec implementation which is what I'm working on. I haven't though much about BITS/BITW. I am attempting to create a fairly basic, small footprint implementation (for small embedded systems) and am not looking at more advanced issues like multiple virtual routers in one box at this time. That is one reason I don't want to see too many implementation details turning up as requirements in 2401bis. 1. If SPD selection for outbound datagrams is based on a single outbound SPD rather than an SPD per interface then it doesn't much matter if the forwarding info changes after the policy is selected. In fact, the selection of the policy has little to do with the IP forwarding function, other than that a route must exist for that chooses some interface on which to send the datagram (and maybe even that can be made irrelevant - see below). Of course, in transport mode the route better point to the correct interface, but in tunnel mode it doesn't really much matter with a single outbound SPD. However, using a "normal" route this way in tunnel mode seems to me so far to be the ugliest aspect of the IPSec/forwarding interaction, see below. 2. In transport mode at present my implementation intercepts red datagrams after the forwarding function has chosen and outbound interface, performs IPSec processing, marks that as complete, then sends the datagram back out on the wire via the interface originally chosen by the IP forwarding function (possibly after fragmentation although naturally I am attempting to avoid that). If in reality the interface has changed in the few milliseconds since the original routing decision was made this isn't any more serious a problem, nor any more solvable, than if the forwarding database changes a microsecond after the datagram has been sent out already. One, or a few, datagrams would be misrouted, possibly dropped, and perhaps retransmitted (if TCP or other reliable transport). 3. In tunnel mode after the policy is located all IPSec processing is completed included addition of the new tunnel outer IP header. Then the datagram is marked as having been through IPSec and given to the IP forwarding function to route (to the tunnel endpoint) as it sees fit. It may well exit a different interface than the one pointed to by the routing of the inner header. It will not be examined by IPSec again. This seems to me to cleanly divorce IP forwarding issues from IPSec. However, as noted in #1 above, there is this whole pretty ugly issue of where should a route for red datagrams point? After all, if we are tunneling between two private networks then in reality the inner red IP datagram probably (because of the use of private address space) couldn't really be delivered to the destination via the Internet. So the route that has to be added just to get the red datagram to IPSec is completely artificial in that case. Yuck. I believe that is why many folks might like to see virtual interfaces play a role in the new IPSec processing model. That way, the routes for red datagrams can point to a virtual interface rather than to some real physical interface out of which the datagram should never exit without 1st having been through IPSec processing, and in fact, from which the datagram may *never* exit if it is wrapped in an IPSec tunnel and IP forwarding ends up sending out some other interface. So I'm considering now whether to implement virtual interfaces. But I don't want it to be mandated in a specification. It is an implementation issue and the more kludgey approach of just point the route for red datagrams at whatever interface (in tunnel mode that is, in transport it better point to the correct one of course) will work and is sufficient, if not very elegant. In fact, another approach for a native IPSec implementation which I only just thought of as I was writing this email might be simply be to add code to the processing of outbound IP datagrams such that if the forwarding function reports that no route exists to the destination then invoke IPSec outbound processing to see if the datagram is covered by an IPSec policy (presumably a tunnel mode policy) and if so then let IPSec take it from there, rather than dropping the datagram because the destination is unreachable. Hmmm.. I sort of like this idea and will certainly consider it further for my implementation. I also believe that this issue of having an "artificial" route for tunnel mode is why many folks want to see the requirement that Security Gateways operate in tunnel mode only (unless they're acting as hosts) removed from 2401bis, or at least clarified. Because, for example, in the FreeBSD world it looks to me like many administrators implement IPSec tunnels by actually using a "gif" interface, which is a virtual interface that performs IP-in-IP tunneling on the datagrams routed to it, and applying IPSec in *transport* mode to the datagrams that exit the gif device. At least, that's my take from researching the issue some. This does seem like a perfectly effective way of creating a tunnel using IPSec in transport mode only. In fact, its even gotten me to wondering whether IPSec tunnel mode should ever have been invented! Perhaps even IPSec tunnel mode itself is an example of putting too much implementation detail in a specification! Because perhaps the very same problem can be solved more elegantly the way many users of FreeBSD seem to solving it. And if that is true, then the layering principals of good protocol design would seem to dictate that there is no real need to mandate "native" IPSec tunnels in the specifications. I'm still in the fairly early stages of the implementation although I do have running code. Am I misunderstanding some of these issues? I'm late to the whole 2401bis discussion. I wasn't even aware a 2401bis effort was underway until I had already started coding from 2401 and pondering these issues. I was glad to see that a 2401bis effort was underway and that attempts were being made to address some of the very same issues that had me perplexed after having studied 2401. But I am also anxious to see the issues I found with 2401 fixed in an elegant, and implementation independent way in 2401bis. - Mike > > This could happen whether dynamic or static routing is used; the issue > is flux in the forwarding table and whether it is _allowed_ to affect > SPD selection. > > Calling the function "SPD selection" doesn't absolve the problem. > > Joe > From owner-ipsec@lists.tislabs.com Mon Oct 20 17:43:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L0gxI7016653; Mon, 20 Oct 2003 17:42:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29112 Mon, 20 Oct 2003 19:48:08 -0400 (EDT) Message-ID: <3F94765B.7030903@isi.edu> Date: Mon, 20 Oct 2003 16:57:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Taylor CC: Mark Duffy , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SPD issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike Taylor wrote: ... >>>So, there is an SPD selection function that chooses an SPD. And there >>>is an IP forwarding function that selects a next hop to forward a >>>datagram to. And the two may be comepletely independent or completely >>>entwined, depending on the nature of the device. >> >>It's the entwined case that presents the largest problem. I.e., if the >>SPD selection is based on forwarding information that then changes by >>the time the subsequently tunneled (or not tunneled) packet is emitted >>from IPsec. > > > By the forwarding information changing do you really mean that the > forwarding > database changes? Yes. Even in embedded devices, unless the forwarding database is in ROM, it gets changed. > Assuming so, then I hadn't thought much about that case > yet > but here's how I see it so far. This description refers to a native IPSec > implementation which is what I'm working on. I haven't though much about > BITS/BITW. I am attempting to create a fairly basic, small footprint > implementation > (for small embedded systems) and am not looking at more advanced issues like > multiple > virtual routers in one box at this time. That is one reason I don't want to > see > too many implementation details turning up as requirements in 2401bis. This has nothing to do (necessarily) with virtual routers, or even dynamic routing. > 1. If SPD selection for outbound datagrams is based on a single outbound > SPD rather than an SPD per interface then it doesn't much matter > if the forwarding info changes after the policy is selected. ... Agreed. If there's no SPD lookup, then this is not an issue. > 2. In transport mode at present my implementation intercepts red datagrams > after the forwarding function has chosen and outbound interface, > performs > IPSec processing, marks that as complete, then sends the datagram back > out on > the wire via the interface originally chosen by the IP forwarding > function > (possibly after fragmentation although naturally I am attempting to > avoid that). > If in reality the interface has changed in the few milliseconds since > the original > routing decision was made this isn't any more serious a problem, nor > any more solvable, > than if the forwarding database changes a microsecond after the > datagram > has been sent out already. One, or a few, datagrams would be > misrouted, > possibly dropped, and perhaps retransmitted (if TCP or other reliable > transport). Misrouting is an issue of the packet goes out on an interface with encryption that isn't appropriate for that interface. I.e., if I change the SPD and the forwarding table at the same time, and whether there are packets pending in IPsec inbetween - and there isn't any current rule that prohibits those two occurrances. > 3. In tunnel mode after the policy is located all IPSec processing is > completed > included addition of the new tunnel outer IP header. Then the datagram > is marked > as having been through IPSec and given to the IP forwarding function > to route (to the tunnel endpoint) as it sees fit. It may well exit a > different > interface than the one pointed to by the routing of the inner header. > It will not be examined by IPSec again. It might be. It's not clear that this matters for this situation, though. However, if the SPD lookup in this case depends on forwarding, it's possible that packets will be emitted based on tunneling that is based on forwarding that is stale by the time they exit. Again, it's possible that packets could be sent in the wrong direction with weaker security than is intended. If the SPD lookup MUST NOT depend on the forwarding table, then this is not an issue. If the SPD lookup MAY depend on the forwarding, then this needs to be considered. > This seems to me to cleanly divorce IP forwarding issues from IPSec. > However, as > noted in #1 above, there is this whole pretty ugly issue of where should a > route for > red datagrams point? After all, if we are tunneling between two private > networks > then in reality the inner red IP datagram probably (because of the use of > private address > space) couldn't really be delivered to the destination via the Internet. So > the route > that has to be added just to get the red datagram to IPSec is completely > artificial in > that case. Yuck. > > I believe that is why many folks might like to see virtual interfaces play a > role in the > new IPSec processing model. That way, the routes for red datagrams can > point to a > virtual interface rather than to some real physical interface out of which > the datagram > should never exit without 1st having been through IPSec processing, and in > fact, from > which the datagram may *never* exit if it is wrapped in an IPSec tunnel and > IP forwarding > ends up sending out some other interface. So I'm considering now whether to > implement virtual > interfaces. But I don't want it to be mandated in a specification. It is > an implementation > issue and the more kludgey approach of just point the route for red > datagrams at whatever > interface (in tunnel mode that is, in transport it better point to the > correct one of course) > will work and is sufficient, if not very elegant. I'm not advocating the requirement of virtual interfaces for this issue either; I'm just observing the a potential relationship between the SPD lookup and the forwarding operation afterwards. > In fact, another approach for a native IPSec implementation which I only > just thought of as > I was writing this email might be simply be to add code to the processing of > outbound IP datagrams > such that if the forwarding function reports that no route exists to the > destination then invoke > IPSec outbound processing to see if the datagram is covered by an IPSec > policy (presumably a > tunnel mode policy) and if so then let IPSec take it from there, rather than > dropping the datagram > because the destination is unreachable. Hmmm.. I sort of like this idea and > will certainly > consider it further for my implementation. This might work if there were no non-IPsec routes for a packet. That's a very special case, IMO. Further, if the IPsec 'takes it from there' and then finds out that there is no SA, what is the ICMP error message? SA not found (or silent), or route not found? > I also believe that this issue of having an "artificial" route for tunnel > mode is why many folks > want to see the requirement that Security Gateways operate in tunnel mode > only (unless they're > acting as hosts) removed from 2401bis, or at least clarified. Because, for > example, in the > FreeBSD world it looks to me like many administrators implement IPSec > tunnels by actually using a > "gif" interface, which is a virtual interface that performs IP-in-IP > tunneling on the datagrams > routed to it, and applying IPSec in *transport* mode to the datagrams that > exit the gif device. (see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited therein) ;-) ... Joe From owner-ipsec@lists.tislabs.com Mon Oct 20 18:09:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L198I7017758; Mon, 20 Oct 2003 18:09:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29338 Mon, 20 Oct 2003 20:17:48 -0400 (EDT) From: "Mike Taylor" To: "Joe Touch" , "Mike Taylor" Cc: "Mark Duffy" , "Stephen Kent" , Subject: RE: SPD issues Date: Mon, 20 Oct 2003 17:26:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F94765B.7030903@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Joe, See my comments below. I don't pretend to know the answers. In fact, these issues seem quite thorny to me. > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Monday, October 20, 2003 4:57 PM > To: Mike Taylor > Cc: Mark Duffy; Stephen Kent; ipsec@lists.tislabs.com > Subject: Re: SPD issues > > > > > Mike Taylor wrote: > > ... > >>>So, there is an SPD selection function that chooses an SPD. And there > >>>is an IP forwarding function that selects a next hop to forward a > >>>datagram to. And the two may be comepletely independent or completely > >>>entwined, depending on the nature of the device. > >> > >>It's the entwined case that presents the largest problem. I.e., if the > >>SPD selection is based on forwarding information that then changes by > >>the time the subsequently tunneled (or not tunneled) packet is emitted > >>from IPsec. > > > > > > By the forwarding information changing do you really mean that the > > forwarding > > database changes? > > Yes. Even in embedded devices, unless the forwarding database is in ROM, > it gets changed. > > > Assuming so, then I hadn't thought much about that case > > yet > > but here's how I see it so far. This description refers to a > native IPSec > > implementation which is what I'm working on. I haven't though > much about > > BITS/BITW. I am attempting to create a fairly basic, small footprint > > implementation > > (for small embedded systems) and am not looking at more > advanced issues like > > multiple > > virtual routers in one box at this time. That is one reason I > don't want to > > see > > too many implementation details turning up as requirements in 2401bis. > > This has nothing to do (necessarily) with virtual routers, or even > dynamic routing. > > > 1. If SPD selection for outbound datagrams is based on a > single outbound > > SPD rather than an SPD per interface then it doesn't much matter > > if the forwarding info changes after the policy is selected. > ... > > Agreed. If there's no SPD lookup, then this is not an issue. > > > 2. In transport mode at present my implementation > intercepts red datagrams > > after the forwarding function has chosen and outbound interface, > > performs > > IPSec processing, marks that as complete, then sends > the datagram back > > out on > > the wire via the interface originally chosen by the IP > forwarding > > function > > (possibly after fragmentation although naturally I am > attempting to > > avoid that). > > If in reality the interface has changed in the few > milliseconds since > > the original > > routing decision was made this isn't any more serious a > problem, nor > > any more solvable, > > than if the forwarding database changes a microsecond after the > > datagram > > has been sent out already. One, or a few, datagrams would be > > misrouted, > > possibly dropped, and perhaps retransmitted (if TCP or > other reliable > > transport). > > Misrouting is an issue of the packet goes out on an interface with > encryption that isn't appropriate for that interface. I.e., if I change > the SPD and the forwarding table at the same time, and whether there are > packets pending in IPsec inbetween - and there isn't any current rule > that prohibits those two occurrances. > > > 3. In tunnel mode after the policy is located all IPSec > processing is > > completed > > included addition of the new tunnel outer IP header. > Then the datagram > > is marked > > as having been through IPSec and given to the IP > forwarding function > > to route (to the tunnel endpoint) as it sees fit. It > may well exit a > > different > > interface than the one pointed to by the routing of the > inner header. > > It will not be examined by IPSec again. > > It might be. It's not clear that this matters for this situation, though. > > However, if the SPD lookup in this case depends on forwarding, it's > possible that packets will be emitted based on tunneling that is based > on forwarding that is stale by the time they exit. Again, it's possible > that packets could be sent in the wrong direction with weaker security > than is intended. I see your point in that if I have two different policies for the same source address (the red network) but different destination addresses (maybe one is the public internet and another is for some other subnet in my domain). Perhaps the latter has weaker security (none at all even) than the former and because routing gets messed up datagrams could go out the wrong interface, perhaps a public one, with no protection at all. This may well be what the original authors of 2401 were thinking about when they created a per-interface SPD concept. However, I'm not sure I see how that really solves the problem either. It just seems moves it from getting the routing correct to getting the assignment of policies to physical interfaces correct. In other words, perhaps the two problems really aren't separable at all. Thus, perhaps IPSec requires a fundamental change to IP in that it must be incorporated into routing. Perhaps in an IPSec box it should be impossible to create a route without specifying an IPSec policy to go with it. Would that solve the problems? Hmmm...... It certainly causes a problem for BITS/BITW implementations. But if such solutions are really hacks then perhaps we shouldn't give them any official blessing. The whole issue of security is so important that we can't afford not to get it right this time around. > > If the SPD lookup MUST NOT depend on the forwarding table, then this is > not an issue. If the SPD lookup MAY depend on the forwarding, then this > needs to be considered. > > > This seems to me to cleanly divorce IP forwarding issues from IPSec. > > However, as > > noted in #1 above, there is this whole pretty ugly issue of > where should a > > route for > > red datagrams point? After all, if we are tunneling between two private > > networks > > then in reality the inner red IP datagram probably (because of > the use of > > private address > > space) couldn't really be delivered to the destination via the > Internet. So > > the route > > that has to be added just to get the red datagram to IPSec is completely > > artificial in > > that case. Yuck. > > > > I believe that is why many folks might like to see virtual > interfaces play a > > role in the > > new IPSec processing model. That way, the routes for red datagrams can > > point to a > > virtual interface rather than to some real physical interface > out of which > > the datagram > > should never exit without 1st having been through IPSec > processing, and in > > fact, from > > which the datagram may *never* exit if it is wrapped in an > IPSec tunnel and > > IP forwarding > > ends up sending out some other interface. So I'm considering > now whether to > > implement virtual > > interfaces. But I don't want it to be mandated in a > specification. It is > > an implementation > > issue and the more kludgey approach of just point the route for red > > datagrams at whatever > > interface (in tunnel mode that is, in transport it better point to the > > correct one of course) > > will work and is sufficient, if not very elegant. > > I'm not advocating the requirement of virtual interfaces for this issue > either; I'm just observing the a potential relationship between the SPD > lookup and the forwarding operation afterwards. > > > In fact, another approach for a native IPSec implementation which I only > > just thought of as > > I was writing this email might be simply be to add code to the > processing of > > outbound IP datagrams > > such that if the forwarding function reports that no route exists to the > > destination then invoke > > IPSec outbound processing to see if the datagram is covered by an IPSec > > policy (presumably a > > tunnel mode policy) and if so then let IPSec take it from > there, rather than > > dropping the datagram > > because the destination is unreachable. Hmmm.. I sort of like > this idea and > > will certainly > > consider it further for my implementation. > > This might work if there were no non-IPsec routes for a packet. That's a > very special case, IMO. But in this concept there are no non-IPSec routes because there is only a single SPD. So there is no way for a datagram to exit the box without IPSec getting a look at it. This idea is only one possible way to avoid creating "fake" routes for the datagrams destined to some remote private network that are going to be tunneled and for which there cannot be any real route. Another way to avoid the fake route issue is by creating some sort of virtual interface to which routes point. But what if there are also routes to "real" interfaces for the same destination? Again, having per-interface outbound SPDs won't help that in a stack that supports multiple routes for a single destination. > > Further, if the IPsec 'takes it from there' and then finds out that > there is no SA, what is the ICMP error message? SA not found (or > silent), or route not found? > > > I also believe that this issue of having an "artificial" route > for tunnel > > mode is why many folks > > want to see the requirement that Security Gateways operate in > tunnel mode > > only (unless they're > > acting as hosts) removed from 2401bis, or at least clarified. > Because, for > > example, in the > > FreeBSD world it looks to me like many administrators implement IPSec > > tunnels by actually using a > > "gif" interface, which is a virtual interface that performs IP-in-IP > > tunneling on the datagrams > > routed to it, and applying IPSec in *transport* mode to the > datagrams that > > exit the gif device. > > (see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited > therein) ;-) > ... > > Joe > From owner-ipsec@lists.tislabs.com Mon Oct 20 22:06:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L56ZI7028264; Mon, 20 Oct 2003 22:06:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00628 Tue, 21 Oct 2003 00:17:09 -0400 (EDT) Message-Id: <5.2.0.9.0.20031021001505.02134aa0@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 21 Oct 2003 00:25:01 -0400 To: Joe Touch From: Mark Duffy Subject: Re: SPD issues Cc: Mike Taylor , Stephen Kent , ipsec@lists.tislabs.com In-Reply-To: <3F944CFA.8060009@isi.edu> References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>[MD] So, there is an SPD selection function that chooses an SPD. And >>there is an IP forwarding function that selects a next hop to forward a >>datagram to. And the two may be comepletely independent or completely >>entwined, depending on the nature of the device. > >[JT] It's the entwined case that presents the largest problem. I.e., if >the SPD selection is based on forwarding information that then changes by >the time the subsequently tunneled (or not tunneled) packet is emitted >from IPsec. > >This could happen whether dynamic or static routing is used; the issue is >flux in the forwarding table and whether it is _allowed_ to affect SPD >selection. > >Calling the function "SPD selection" doesn't absolve the problem. > >Joe No. But it isolates the problems of which SPD to use, and which interface/ next hop to send the packet to. Whoever feels that these are or need to be entwined for their application is free to do so. Those solving simpler problems can avoid that. And 2401bis can take itself out of the business of IP forwarding decisions. Mark From owner-ipsec@lists.tislabs.com Tue Oct 21 08:22:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFM2I7028619; Tue, 21 Oct 2003 08:22:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03578 Tue, 21 Oct 2003 10:32:44 -0400 (EDT) To: "Mike Taylor" Cc: "Joe Touch" , "Mark Duffy" , "Stephen Kent" , , guttman@mitre.org (Joshua D. Guttman) Subject: Re: SPD issues Reply-To: guttman@mitre.org (Joshua D. Guttman disp: current) References: From: guttman@mitre.org (Joshua D. Guttman) Date: 21 Oct 2003 10:40:39 -0400 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike -- "Mike Taylor" writes: > > Again, it's possible that packets could be sent in the wrong > > direction with weaker security than is intended. > > I see your point in that if I have two different policies for the > same source address (the red network) but different destination > addresses (maybe one is the public internet and another is for > some other subnet in my domain). Perhaps the latter has weaker > security (none at all even) than the former and because routing > gets messed up datagrams could go out the wrong interface, perhaps > a public one, with no protection at all. The paper "Rigorous Automated Network Security Management" available at http://www.ccs.neu.edu/home/guttman seems (to me) to give ways to ensure that a given IPsec set-up has no problems of this kind. Joshua -- Joshua D. Guttman MITRE, Mail Stop S119 Office: +1 781 271 2654 202 Burlington Rd. Fax: +1 781 271 8953 Bedford, MA 01730-1420 USA Cell: +1 781 526 5713 From owner-ipsec@lists.tislabs.com Tue Oct 21 09:32:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LGWOI7030951; Tue, 21 Oct 2003 09:32:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03972 Tue, 21 Oct 2003 11:40:56 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 21 Oct 2003 11:44:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'UDP Encapsulation of IPsec Packets ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt From owner-ipsec@lists.tislabs.com Tue Oct 21 10:07:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LH7PI7032016; Tue, 21 Oct 2003 10:07:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04247 Tue, 21 Oct 2003 12:24:16 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'The AES-XCBC-PRF-128 algorithm for IKE' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 21 Oct 2003 12:01:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'The AES-XCBC-PRF-128 algorithm for IKE ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-01.txt From owner-ipsec@lists.tislabs.com Tue Oct 21 10:08:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LH8MI7032041; Tue, 21 Oct 2003 10:08:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04241 Tue, 21 Oct 2003 12:23:53 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'Negotiation of NAT-Traversal in the IKE' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 21 Oct 2003 11:53:39 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'Negotiation of NAT-Traversal in the IKE ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt From owner-ipsec@lists.tislabs.com Tue Oct 21 10:08:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LH8SI7032050; Tue, 21 Oct 2003 10:08:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04235 Tue, 21 Oct 2003 12:22:56 -0400 (EDT) Date: Tue, 21 Oct 2003 12:23:03 -0400 From: "Theodore Ts'o" To: Tero Kivinen Cc: ipsec@lists.tislabs.com, "Angelos D. Keromytis" , Barbara Fraser , Karen Seo , Stephen Kent Subject: Re: Issue #85 DROP'd inbound packet -- does not match SA Message-ID: <20031021162303.GC4132@thunk.org> References: <16265.24472.411484.876527@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16265.24472.411484.876527@ryijy.hel.fi.ssh.com> User-Agent: Mutt/1.5.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Oct 12, 2003 at 05:05:12PM +0300, Tero Kivinen wrote: > One possible solution to this is not to use ICMP messages at all. > Because this kind of solution can only happen when the other end is > configured incorrectly or have bugs. If the SA is manual keyed SA > there is nothing we can really do. If it is IKE negotiated SA we could > find out the IKE SA tied to the SA (in IKEv2 this is easy, for IKEv1 > it is harder, and the IKE SA might not be there anymore). > > INVALID_SELECTORS XX > > MAY be sent in an IKE INFORMATIONAL Exchange when a node > receives an ESP or AH packet whose selectors do not match > those of the SA on which it was delivered (and which > caused the packet to be dropped). The Notification Data > contains the start of the offending packet (as in ICMP > messages) and the SPI field of the notification is set to > match the SPI of the IPsec SA. This seems like a good suggestion to me. The one downside is that it requires adding the above text to the IKEv2 draft. But this is a small enough change that I believe we could do so during or before the IETF last call process. Any objections with this approach? - Ted From owner-ipsec@lists.tislabs.com Tue Oct 21 10:29:28 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHTRI7032759; Tue, 21 Oct 2003 10:29:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04343 Tue, 21 Oct 2003 12:40:52 -0400 (EDT) Message-Id: <200310211640.h9LGe6CI032253@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: 2401bis issue status Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 2003 12:40:06 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have accepted the proposed text by Mark Duffy for Issue 68 ("VPNs with overlapping IP address ranges"), and Issue 87 ("Permit Security Gateways to use transport moed when they are the endpoints of the communication"). Issue 81 ("Handling outbound red fragments") was rejected. Instead, Issue 88 ("Lift the prohibition on red-side fragmentation by SG, BITS, BITW") was created, for which comments are solicited. Cheers, -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 21 10:38:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHc9I7032941; Tue, 21 Oct 2003 10:38:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04452 Tue, 21 Oct 2003 12:51:57 -0400 (EDT) Message-ID: <3F956643.8030701@isi.edu> Date: Tue, 21 Oct 2003 10:00:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Mike Taylor , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SPD issues References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031021001505.02134aa0@localhost> In-Reply-To: <5.2.0.9.0.20031021001505.02134aa0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > >>> [MD] So, there is an SPD selection function that chooses an SPD. And >>> there is an IP forwarding function that selects a next hop to forward >>> a datagram to. And the two may be comepletely independent or >>> completely entwined, depending on the nature of the device. >> >> >> [JT] It's the entwined case that presents the largest problem. I.e., >> if the SPD selection is based on forwarding information that then >> changes by the time the subsequently tunneled (or not tunneled) packet >> is emitted from IPsec. >> >> This could happen whether dynamic or static routing is used; the issue >> is flux in the forwarding table and whether it is _allowed_ to affect >> SPD selection. >> >> Calling the function "SPD selection" doesn't absolve the problem. >> >> Joe > > > No. But it isolates the problems of which SPD to use, and which > interface/ next hop to send the packet to. Whoever feels that these are > or need to be entwined for their application is free to do so.. Those > solving simpler problems can avoid that. And 2401bis can take itself > out of the business of IP forwarding decisions. > > Mark I'm in favor of those last two observations, but it's the "whoever feels .. is free to do so" that worries me. I.e., this gives enough freedom to end up with a nasty loophole, e.g., "SPD selection can be supported, but how is up to the implementer, and whether it is secure depends on the implementation". Joe From owner-ipsec@lists.tislabs.com Tue Oct 21 11:00:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LI0TI7033682; Tue, 21 Oct 2003 11:00:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04546 Tue, 21 Oct 2003 13:03:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F956643.8030701@isi.edu> References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> Date: Tue, 21 Oct 2003 13:10:23 -0400 To: Joe Touch From: Stephen Kent Subject: Re: SPD issues Cc: Mark Duffy , Mike Taylor , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:00 -0700 10/21/03, Joe Touch wrote: >Mark Duffy wrote: > >> >>>>[MD] So, there is an SPD selection function that chooses an SPD. >>>>And there is an IP forwarding function that selects a next hop to >>>>forward a datagram to. And the two may be comepletely >>>>independent or completely entwined, depending on the nature of >>>>the device. >>> >>> >>>[JT] It's the entwined case that presents the largest problem. >>>I.e., if the SPD selection is based on forwarding information that >>>then changes by the time the subsequently tunneled (or not >>>tunneled) packet is emitted from IPsec. >>> >>>This could happen whether dynamic or static routing is used; the >>>issue is flux in the forwarding table and whether it is _allowed_ >>>to affect SPD selection. >>> >>>Calling the function "SPD selection" doesn't absolve the problem. >>> >>>Joe >> >> >>No. But it isolates the problems of which SPD to use, and which >>interface/ next hop to send the packet to. Whoever feels that >>these are or need to be entwined for their application is free to >>do so.. Those >>solving simpler problems can avoid that. And 2401bis can take >>itself out of the business of IP forwarding decisions. >> >>Mark > >I'm in favor of those last two observations, but it's the "whoever feels >.. is free to do so" that worries me. I.e., this gives enough freedom to >end up with a nasty loophole, e.g., "SPD selection can be supported, but >how is up to the implementer, and whether it is secure depends on the >implementation". > >Joe Joe, We have enough variation in how different contexts want to select SPDs (when more than one is needed) that I don't think we can do more than say that there is a lookup function which takes the outbound packet and local metadata as inputs. This seems analogous to your earlier suggestion to allow a forwarding function to have access to the whole outbound packet to support an unspecified forwarding lookup, when we were thinking of having an explicit forwarding function as part of IPsec. Many IPsec implementations will need only one SPD, so this whole issue is a no-op in those cases. In cases where multiple SPDs are appropriate, then yes, the implementor and the admin will have to exercise caution in these contexts. Generally, we cannot have it both ways. if we keep things simple, we can have more confidence in their security, but we loose flexibility. Steve From owner-ipsec@lists.tislabs.com Tue Oct 21 11:00:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LI0cI7033693; Tue, 21 Oct 2003 11:00:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04634 Tue, 21 Oct 2003 13:07:39 -0400 (EDT) Message-ID: <3F9569F8.7050109@isi.edu> Date: Tue, 21 Oct 2003 10:16:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Taylor CC: Mark Duffy , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SPD issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike Taylor wrote: > Hi Joe, > > See my comments below. I don't pretend to know the answers. > In fact, these issues seem quite thorny to me. agreed. >>-----Original Message----- >>From: Joe Touch [mailto:touch@ISI.EDU] >>Sent: Monday, October 20, 2003 4:57 PM >>To: Mike Taylor >>Cc: Mark Duffy; Stephen Kent; ipsec@lists.tislabs.com >>Subject: Re: SPD issues >> >> >> >> >>Mike Taylor wrote: >> >>... >> >>>>>So, there is an SPD selection function that chooses an SPD. And there >>>>>is an IP forwarding function that selects a next hop to forward a >>>>>datagram to. And the two may be comepletely independent or completely >>>>>entwined, depending on the nature of the device. >>>> >>>>It's the entwined case that presents the largest problem. I.e., if the >>>>SPD selection is based on forwarding information that then changes by >>>>the time the subsequently tunneled (or not tunneled) packet is emitted >>> >>>>from IPsec. >>> >>> >>>By the forwarding information changing do you really mean that the >>>forwarding >>>database changes? >> >>Yes. Even in embedded devices, unless the forwarding database is in ROM, >>it gets changed. >> >> >>>Assuming so, then I hadn't thought much about that case >>>yet >>>but here's how I see it so far. This description refers to a >> >>native IPSec >> >>>implementation which is what I'm working on. I haven't though >> >>much about >> >>>BITS/BITW. I am attempting to create a fairly basic, small footprint >>>implementation >>>(for small embedded systems) and am not looking at more >> >>advanced issues like >> >>>multiple >>>virtual routers in one box at this time. That is one reason I >> >>don't want to >> >>>see >>>too many implementation details turning up as requirements in 2401bis. >> >>This has nothing to do (necessarily) with virtual routers, or even >>dynamic routing. >> >> >>> 1. If SPD selection for outbound datagrams is based on a >> >>single outbound >> >>> SPD rather than an SPD per interface then it doesn't much matter >>> if the forwarding info changes after the policy is selected. >> >>... >> >>Agreed. If there's no SPD lookup, then this is not an issue. >> >> >>> 2. In transport mode at present my implementation >> >>intercepts red datagrams >> >>> after the forwarding function has chosen and outbound interface, >>>performs >>> IPSec processing, marks that as complete, then sends >> >>the datagram back >> >>>out on >>> the wire via the interface originally chosen by the IP >> >>forwarding >> >>>function >>> (possibly after fragmentation although naturally I am >> >>attempting to >> >>>avoid that). >>> If in reality the interface has changed in the few >> >>milliseconds since >> >>>the original >>> routing decision was made this isn't any more serious a >> >>problem, nor >> >>>any more solvable, >>> than if the forwarding database changes a microsecond after the >>>datagram >>> has been sent out already. One, or a few, datagrams would be >>>misrouted, >>> possibly dropped, and perhaps retransmitted (if TCP or >> >>other reliable >> >>> transport). >> >>Misrouting is an issue of the packet goes out on an interface with >>encryption that isn't appropriate for that interface. I.e., if I change >>the SPD and the forwarding table at the same time, and whether there are >>packets pending in IPsec inbetween - and there isn't any current rule >>that prohibits those two occurrances. >> >> >>> 3. In tunnel mode after the policy is located all IPSec >> >>processing is >> >>>completed >>> included addition of the new tunnel outer IP header. >> >>Then the datagram >> >>>is marked >>> as having been through IPSec and given to the IP >> >>forwarding function >> >>> to route (to the tunnel endpoint) as it sees fit. It >> >>may well exit a >> >>>different >>> interface than the one pointed to by the routing of the >> >>inner header. >> >>> It will not be examined by IPSec again. >> >>It might be. It's not clear that this matters for this situation, though. >> >>However, if the SPD lookup in this case depends on forwarding, it's >>possible that packets will be emitted based on tunneling that is based >>on forwarding that is stale by the time they exit. Again, it's possible >>that packets could be sent in the wrong direction with weaker security >>than is intended. > > > I see your point in that if I have two different policies for the same > source address (the red network) but different destination addresses > (maybe one is the public internet and another is for some other subnet > in my domain). Perhaps the latter has weaker security (none at all even) > than the former and because routing gets messed up datagrams could go > out the wrong interface, perhaps a public one, with no protection at all. > > This may well be what the original authors of 2401 were thinking about > when they created a per-interface SPD concept. However, I'm not sure > I see how that really solves the problem either. It just seems moves it > from getting the routing correct to getting the assignment of policies to > physical interfaces correct. > > In other words, perhaps the two problems really aren't separable at all. > Thus, > perhaps IPSec requires a fundamental change to IP in that it must be > incorporated into routing. Perhaps in an IPSec box it should be impossible > to create a route without specifying an IPSec policy to go with it. Would > that solve the problems? Hmmm...... It certainly causes a problem for > BITS/BITW > implementations. But if such solutions are really hacks then perhaps we > shouldn't give them any official blessing. The whole issue of security is > so important that we can't afford not to get it right this time around. Yeah - that's why I'm wondering if the "use external SPD lookup" might be a security hole per se. Pushing it to an external, unspecified function certainly has that flavor. >>If the SPD lookup MUST NOT depend on the forwarding table, then this is >>not an issue. If the SPD lookup MAY depend on the forwarding, then this >>needs to be considered. >> >> >>>This seems to me to cleanly divorce IP forwarding issues from IPSec. >>>However, as >>>noted in #1 above, there is this whole pretty ugly issue of >> >>where should a >> >>>route for >>>red datagrams point? After all, if we are tunneling between two private >>>networks >>>then in reality the inner red IP datagram probably (because of >> >>the use of >> >>>private address >>>space) couldn't really be delivered to the destination via the >> >>Internet. So >> >>>the route >>>that has to be added just to get the red datagram to IPSec is completely >>>artificial in >>>that case. Yuck. >>> >>>I believe that is why many folks might like to see virtual >> >>interfaces play a >> >>>role in the >>>new IPSec processing model. That way, the routes for red datagrams can >>>point to a >>>virtual interface rather than to some real physical interface >> >>out of which >> >>>the datagram >>>should never exit without 1st having been through IPSec >> >>processing, and in >> >>>fact, from >>>which the datagram may *never* exit if it is wrapped in an >> >>IPSec tunnel and >> >>>IP forwarding >>>ends up sending out some other interface. So I'm considering >> >>now whether to >> >>>implement virtual >>>interfaces. But I don't want it to be mandated in a >> >>specification. It is >> >>>an implementation >>>issue and the more kludgey approach of just point the route for red >>>datagrams at whatever >>>interface (in tunnel mode that is, in transport it better point to the >>>correct one of course) >>>will work and is sufficient, if not very elegant. >> >>I'm not advocating the requirement of virtual interfaces for this issue >>either; I'm just observing the a potential relationship between the SPD >>lookup and the forwarding operation afterwards. >> >> >>>In fact, another approach for a native IPSec implementation which I only >>>just thought of as >>>I was writing this email might be simply be to add code to the >> >>processing of >> >>>outbound IP datagrams >>>such that if the forwarding function reports that no route exists to the >>>destination then invoke >>>IPSec outbound processing to see if the datagram is covered by an IPSec >>>policy (presumably a >>>tunnel mode policy) and if so then let IPSec take it from >> >>there, rather than >> >>>dropping the datagram >>>because the destination is unreachable. Hmmm.. I sort of like >> >>this idea and >> >>>will certainly >>>consider it further for my implementation. >> >>This might work if there were no non-IPsec routes for a packet. That's a >>very special case, IMO. > > > But in this concept there are no non-IPSec routes because there is only > a single SPD. In that case, there would need to be an SPD entry that says "don't IPsec"; that was the case I was thinking of, but I agree that this should be in the SPD at that point. > So there is no way for a datagram to exit the box > without IPSec getting a look at it. This idea is only one possible way > to avoid creating "fake" routes for the datagrams destined to some remote > private network that are going to be tunneled and for which there cannot > be any real route. Another way to avoid the fake route issue is by > creating some sort of virtual interface to which routes point. But what > if there are also routes to "real" interfaces for the same destination? > Again, having per-interface outbound SPDs won't help that in a stack that > supports multiple routes for a single destination. Yes - that's a can of worms of a different color (to mix metaphors). >>Further, if the IPsec 'takes it from there' and then finds out that >>there is no SA, what is the ICMP error message? SA not found (or >>silent), or route not found? >> >> >>>I also believe that this issue of having an "artificial" route >> >>for tunnel >> >>>mode is why many folks >>>want to see the requirement that Security Gateways operate in >> >>tunnel mode >> >>>only (unless they're >>>acting as hosts) removed from 2401bis, or at least clarified. >> >>Because, for >> >>>example, in the >>>FreeBSD world it looks to me like many administrators implement IPSec >>>tunnels by actually using a >>>"gif" interface, which is a virtual interface that performs IP-in-IP >>>tunneling on the datagrams >>>routed to it, and applying IPSec in *transport* mode to the >> >>datagrams that >> >>>exit the gif device. >> >>(see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited >>therein) ;-) >>... >> >>Joe >> From owner-ipsec@lists.tislabs.com Tue Oct 21 11:15:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIFsI7034509; Tue, 21 Oct 2003 11:15:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04669 Tue, 21 Oct 2003 13:09:34 -0400 (EDT) Message-ID: <3F956A72.5090603@isi.edu> Date: Tue, 21 Oct 2003 10:18:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Mark Duffy , Mike Taylor , ipsec@lists.tislabs.com Subject: Re: SPD issues References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 10:00 -0700 10/21/03, Joe Touch wrote: > >> Mark Duffy wrote: >> >>> >>>>> [MD] So, there is an SPD selection function that chooses an SPD. >>>>> And there is an IP forwarding function that selects a next hop to >>>>> forward a datagram to. And the two may be comepletely independent >>>>> or completely entwined, depending on the nature of the device. >>>> >>>> >>>> >>>> [JT] It's the entwined case that presents the largest problem. I.e., >>>> if the SPD selection is based on forwarding information that then >>>> changes by the time the subsequently tunneled (or not tunneled) >>>> packet is emitted from IPsec. >>>> >>>> This could happen whether dynamic or static routing is used; the >>>> issue is flux in the forwarding table and whether it is _allowed_ to >>>> affect SPD selection. >>>> >>>> Calling the function "SPD selection" doesn't absolve the problem. >>>> >>>> Joe >>> >>> >>> >>> No. But it isolates the problems of which SPD to use, and which >>> interface/ next hop to send the packet to. Whoever feels that these >>> are or need to be entwined for their application is free to do so.. >>> Those >>> solving simpler problems can avoid that. And 2401bis can take itself >>> out of the business of IP forwarding decisions. >>> >>> Mark >> >> >> I'm in favor of those last two observations, but it's the "whoever feels >> .. is free to do so" that worries me. I.e., this gives enough freedom to >> end up with a nasty loophole, e.g., "SPD selection can be supported, but >> how is up to the implementer, and whether it is secure depends on the >> implementation". >> >> Joe > > > Joe, > > We have enough variation in how different contexts want to select SPDs > (when more than one is needed) that I don't think we can do more than > say that there is a lookup function which takes the outbound packet and > local metadata as inputs. This seems analogous to your earlier > suggestion to allow a forwarding function to have access to the whole > outbound packet to support an unspecified forwarding lookup, when we > were thinking of having an explicit forwarding function as part of IPsec. That was a straw-man intended to demonstrate that having a forwarding function inside IPsec would create a security hole. This creates the same hole, by analogy. > Many IPsec implementations will need only one SPD, so this whole issue > is a no-op in those cases. Agreed. > In cases where multiple SPDs are > appropriate, then yes, the implementor and the admin will have to > exercise caution in these contexts. Generally, we cannot have it both > ways. if we keep things simple, we can have more confidence in their > security, but we loose flexibility. > > Steve This level of 'flexibility' opens a large door, especially if there are no constraints on that function. If such a door is unspecified, how can we trust a particular implementation? Joe From owner-ipsec@lists.tislabs.com Tue Oct 21 11:17:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIHNI7034563; Tue, 21 Oct 2003 11:17:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04910 Tue, 21 Oct 2003 13:29:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 21 Oct 2003 10:39:29 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: 2401bis-00 submitted to IETF Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since it might take a while for the draft to get posted in the official IETF repository, there is a temporary copy of the draft available at . This temporary copy will disappear when the official copy hits the official repository. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Oct 21 11:17:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIHjI7034592; Tue, 21 Oct 2003 11:17:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04854 Tue, 21 Oct 2003 13:25:09 -0400 (EDT) From: "Mike Taylor" To: "Stephen Kent" , "Joe Touch" Cc: "Mark Duffy" , "Mike Taylor" , Subject: RE: SPD issues Date: Tue, 21 Oct 2003 10:34:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See my comments below. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, October 21, 2003 10:10 AM > To: Joe Touch > Cc: Mark Duffy; Mike Taylor; ipsec@lists.tislabs.com > Subject: Re: SPD issues > > > At 10:00 -0700 10/21/03, Joe Touch wrote: > >Mark Duffy wrote: > > > >> > >>>>[MD] So, there is an SPD selection function that chooses an SPD. > >>>>And there is an IP forwarding function that selects a next hop to > >>>>forward a datagram to. And the two may be comepletely > >>>>independent or completely entwined, depending on the nature of > >>>>the device. > >>> > >>> > >>>[JT] It's the entwined case that presents the largest problem. > >>>I.e., if the SPD selection is based on forwarding information that > >>>then changes by the time the subsequently tunneled (or not > >>>tunneled) packet is emitted from IPsec. > >>> > >>>This could happen whether dynamic or static routing is used; the > >>>issue is flux in the forwarding table and whether it is _allowed_ > >>>to affect SPD selection. > >>> > >>>Calling the function "SPD selection" doesn't absolve the problem. > >>> > >>>Joe > >> > >> > >>No. But it isolates the problems of which SPD to use, and which > >>interface/ next hop to send the packet to. Whoever feels that > >>these are or need to be entwined for their application is free to > >>do so.. Those > >>solving simpler problems can avoid that. And 2401bis can take > >>itself out of the business of IP forwarding decisions. > >> > >>Mark > > > >I'm in favor of those last two observations, but it's the "whoever feels > >.. is free to do so" that worries me. I.e., this gives enough freedom to > >end up with a nasty loophole, e.g., "SPD selection can be supported, but > >how is up to the implementer, and whether it is secure depends on the > >implementation". > > > >Joe > > Joe, > > We have enough variation in how different contexts want to select > SPDs (when more than one is needed) that I don't think we can do more > than say that there is a lookup function which takes the outbound > packet and local metadata as inputs. This seems analogous to your > earlier suggestion to allow a forwarding function to have access to > the whole outbound packet to support an unspecified forwarding > lookup, when we were thinking of having an explicit forwarding > function as part of IPsec. > > Many IPsec implementations will need only one SPD, so this whole > issue is a no-op in those cases. In cases where multiple SPDs are > appropriate, then yes, the implementor and the admin will have to > exercise caution in these contexts. Generally, we cannot have it > both ways. if we keep things simple, we can have more confidence in > their security, but we loose flexibility. Bear in mind that it doesn't really matter if there is only one SPD. Because even a single SPD can have multiple policies for outbound red datagrams that match the source address of a particular sender, and provide different levels of security (perhaps none at all) depending on the destination address. So it isn't really a no-op just because there is only one SPD. Believe me, I'm in favor of keeping the RFC as simple as possible, and ideally would like to see forwarding and IPSec SPD lookup divorced from one another. But it isn't yet clear that truly solid security can be provided that way. Its all got me wondering if there really is a fool-proof solution to this problem other than specifying that the level of protection afforded to any given outbound datagram should be based solely on the source of the datagram, and not on the destination. In other words, in the real world if I am transmitting sensitive information then effectivly all networks are untrusted. But if we want to continue with the notion that some networks are trusted more than others, then perhaps (and I recognize that it would be fairly radical change) the correct model for IPSec is that there MUST be an outbound SPD per-interface (becaues we view security as inherently being tied to the trustworthiness of different interfaces) and that the security afforded a datagram is based strictly on the source of the datagram and the interface that it exits, rather than the source and the destination addresses. Because I think the issue we're dancing around here is that while I might think its OK to send a red datagram to a given destination with possibly no protection at all, I only belive that because I believe that the destintation is connected to some trusted network where security isn't needed. Otherwise, I'd be pretty crazy to do it. But this ignores the fact that due to routing errors or misconfiguration, or a bad implementation, the datagram might actually escape onto a network I don't trust. This doesn't have to be the public internet. It might just be, for example, that a datagram from accounting to HR gets misrouted into an engineering lab where it is captured by some engineer's packet sniffer and he sees that the big layoff is coming. Gee, wonder why I thought of that example. Must be the times. :( > > Steve From owner-ipsec@lists.tislabs.com Tue Oct 21 11:19:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIJNI7034667; Tue, 21 Oct 2003 11:19:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04960 Tue, 21 Oct 2003 13:33:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F956A72.5090603@isi.edu> References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> Date: Tue, 21 Oct 2003 13:40:35 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: SPD issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks There may be some misunderstanding about what holes an SPD selection function creates. If there is more than one SPD (per interface or whatever) and if the same destination is represented in more than one SPD, and if these entries offer different choices for the security services to be applied, where one of the choices may be less secure than the others, then you have a problem, period. This is because many factors could cause the traffic be be processed against the SPD that results in applying a less secure set of services, e.g., bypass. For example, a Trojan Horse in the net behind the IPsec device might deliberately alter packet headers in an effort to cause the traffic to be mapped to a different SPD. When we had per-interface SPDs, it was possible that traffic destined for one outbound interface (that was deemed secure) might be misrouted by the forwarding software after IPsec processing is completed. There are many other examples. The only way to be really confident about the security services being provided for traffic is to have just one SPD, or to make sure that the multiple SPDs are not overlapping in terms of the destination addresses (for outbound traffic), or that the security services offered in any overlapping entries are equivalent. That's why I cannot get too excited about the residual vulnerabilities associated with these options. maybe we should taje a hint from the automotive industry and add the following waring to the RFC: "your actual security may vary" :-) Steve From owner-ipsec@lists.tislabs.com Tue Oct 21 12:27:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJRdI7036980; Tue, 21 Oct 2003 12:27:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05758 Tue, 21 Oct 2003 14:37:26 -0400 (EDT) Message-ID: <02b701c39799$21656730$2305010a@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Mike Taylor" , "Joe Touch" , "Mark Duffy" Cc: "Mike Taylor" , "Stephen Kent" , References: Subject: Re: SPD issues Date: Mon, 20 Oct 2003 22:59:23 -0700 Organization: Intoto Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, IPSEC VPN is being used in two different ways - Policy based VPN and Route/Interface based VPN. But, in both cases, the steps given by Steve are valid. In policy based VPN, SPD selection process selects the SPD. Security policy is chosen based on traffic selectors. Once the security is applied on the packet, the packet is forwarded based on the destination IP address of the outer IP header. In route based VPN, packet is traversed twice through the IP stack. - Here too, the SPD is selected as per SPD selection process. Security policy is chosen based on packet selectors. Action (Bypass/Discard/Apply) is applied on the packet and forwarding interface is chosen based on the destination IP address of the transformed packet. In Route based VPN, these forwarding interfaces are either L2TPoIPSEC or IPinIPoIPSEC interfaces. - L2TP or IPinIP tunnel headers are applied on the packet. - One more SPD selection occurs at this time. Security policy within SPD is chosen based on L2TP or IPinIP tunnel selectors. Security is applied as per Security Policy and then packet is forwarded. Route based VPN is similar to policy based VPN except that the packet is traversed twice (or more) through SPD Selection and forwarding process. Typically, in this case, first SPD security policy action would be 'Bypass' and second SPD security policy action would be 'Apply'. I feel 'SPD selection' process and 'forwarding' in the process flow are generic enough and provide enough flexibility for different implementations. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Mike Taylor" To: "Joe Touch" ; "Mark Duffy" Cc: "Mike Taylor" ; "Stephen Kent" ; Sent: Monday, October 20, 2003 3:49 PM Subject: RE: SPD issues > > > > -----Original Message----- > > From: Joe Touch [mailto:touch@ISI.EDU] > > Sent: Monday, October 20, 2003 2:01 PM > > To: Mark Duffy > > Cc: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com > > Subject: Re: SPD issues > > > > > > > > > > Mark Duffy wrote: > > > > > Hi Mike, see below... > > > > > > At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote: > > > [...] > > > > > >> > > [SK] I think we have to say something about options for how > > >> forwarding > > >> > >decisions can be made in the context of IPsec, especially in tunnel > > >> mode. > > >> > > > >> > [MD] How about: > > >> > > > >> > For packets that "bypass" IPsec processing, and for packets > > that arrive > > >> > with IPsec protection which is removed at the device, the IP output > > >> > interface and next hop are selected by the normal IP forwarding > > >> mechanism > > >> > of the device [which would be beyond the scope of 2401bis] applied > > >> to the > > >> > plaintext packet. > > >> > > > >> > For packets that have IPsec applied to them by the device (tunnel or > > >> > transport mode) the IP output interface and next hop are selected by > > >> the > > >> > normal IP forwarding mechanism of the device applied to the IPsec > > >> packet. > > >> > > >> [MT] This wording is not sufficiently clear as their is quite a > > >> difference > > >> between > > >> the routing applied *after* IPSec processing in tunnel mode, and the > > >> routing > > >> required to get a red datagram to IPSec, i.e., either to some > > virtual or > > >> real > > >> interface to which an SPD is attached that has a policy relevant to the > > >> datagram. > > >> In the latter, the route may very well not be "real" in the > > sense that it > > >> may > > >> exist solely for the purpose of getting the red datagram to > > IPSec, and in > > >> fact the > > >> destination IP address may be some private address (with IPSec > > in tunnel > > >> mode) > > >> that couldn't possibly be reached via the public Internet by a > > >> conventional > > >> (non-VPN) forwarding decision. > > > > > > > > > My understanding of the proposed model is that the IPsec device has an > > > "SPD selection function" that choses the SPD to use; how the choice is > > > made is implementation dependent. This replaces (or rather, enlarges > > > on) the SPD-per-interface model of 2401. I believe that that SPD > > > selection function fills the role of the "routing required to get a red > > > datagram to IPSec" in your message above. > > > > > >> In a purist sense the solution to these issues falls into the realm of > > >> implementation > > >> details that don't really need to be specified in 2401bis. I > > don't think > > >> 2401bis > > >> should require, for example, virtual interfaces as a solution. > > > > > > Nor do I. Which is why I personally find the idea of an "SPD selection > > > function" attractive. Trying to disguise the SPD selection function as > > > a "forwarding decision" just adds confusion. > > > > > > So, there is an SPD selection function that chooses an SPD. And there > > > is an IP forwarding function that selects a next hop to forward a > > > datagram to. And the two may be comepletely independent or completely > > > entwined, depending on the nature of the device. > > > > It's the entwined case that presents the largest problem. I.e., if the > > SPD selection is based on forwarding information that then changes by > > the time the subsequently tunneled (or not tunneled) packet is emitted > > from IPsec. > > By the forwarding information changing do you really mean that the > forwarding > database changes? Assuming so, then I hadn't thought much about that case > yet > but here's how I see it so far. This description refers to a native IPSec > implementation which is what I'm working on. I haven't though much about > BITS/BITW. I am attempting to create a fairly basic, small footprint > implementation > (for small embedded systems) and am not looking at more advanced issues like > multiple > virtual routers in one box at this time. That is one reason I don't want to > see > too many implementation details turning up as requirements in 2401bis. > > 1. If SPD selection for outbound datagrams is based on a single outbound > SPD rather than an SPD per interface then it doesn't much matter > if the forwarding info changes after the policy is selected. > In fact, the selection of the policy has little to do with the > IP forwarding function, other than that a route must exist for > that chooses some interface on which to send the datagram (and > maybe > even that can be made irrelevant - see below). > > Of course, in transport mode the route better point to the correct > interface, > but in tunnel mode it doesn't really much matter with a single outbound > SPD. > However, using a "normal" route this way in tunnel mode seems to me so > far to be the ugliest aspect of the IPSec/forwarding interaction, > see below. > > 2. In transport mode at present my implementation intercepts red datagrams > after the forwarding function has chosen and outbound interface, > performs > IPSec processing, marks that as complete, then sends the datagram back > out on > the wire via the interface originally chosen by the IP forwarding > function > (possibly after fragmentation although naturally I am attempting to > avoid that). > If in reality the interface has changed in the few milliseconds since > the original > routing decision was made this isn't any more serious a problem, nor > any more solvable, > than if the forwarding database changes a microsecond after the > datagram > has been sent out already. One, or a few, datagrams would be > misrouted, > possibly dropped, and perhaps retransmitted (if TCP or other reliable > transport). > > 3. In tunnel mode after the policy is located all IPSec processing is > completed > included addition of the new tunnel outer IP header. Then the datagram > is marked > as having been through IPSec and given to the IP forwarding function > to route (to the tunnel endpoint) as it sees fit. It may well exit a > different > interface than the one pointed to by the routing of the inner header. > It will not be examined by IPSec again. > > This seems to me to cleanly divorce IP forwarding issues from IPSec. > However, as > noted in #1 above, there is this whole pretty ugly issue of where should a > route for > red datagrams point? After all, if we are tunneling between two private > networks > then in reality the inner red IP datagram probably (because of the use of > private address > space) couldn't really be delivered to the destination via the Internet. So > the route > that has to be added just to get the red datagram to IPSec is completely > artificial in > that case. Yuck. > > I believe that is why many folks might like to see virtual interfaces play a > role in the > new IPSec processing model. That way, the routes for red datagrams can > point to a > virtual interface rather than to some real physical interface out of which > the datagram > should never exit without 1st having been through IPSec processing, and in > fact, from > which the datagram may *never* exit if it is wrapped in an IPSec tunnel and > IP forwarding > ends up sending out some other interface. So I'm considering now whether to > implement virtual > interfaces. But I don't want it to be mandated in a specification. It is > an implementation > issue and the more kludgey approach of just point the route for red > datagrams at whatever > interface (in tunnel mode that is, in transport it better point to the > correct one of course) > will work and is sufficient, if not very elegant. > > In fact, another approach for a native IPSec implementation which I only > just thought of as > I was writing this email might be simply be to add code to the processing of > outbound IP datagrams > such that if the forwarding function reports that no route exists to the > destination then invoke > IPSec outbound processing to see if the datagram is covered by an IPSec > policy (presumably a > tunnel mode policy) and if so then let IPSec take it from there, rather than > dropping the datagram > because the destination is unreachable. Hmmm.. I sort of like this idea and > will certainly > consider it further for my implementation. > > I also believe that this issue of having an "artificial" route for tunnel > mode is why many folks > want to see the requirement that Security Gateways operate in tunnel mode > only (unless they're > acting as hosts) removed from 2401bis, or at least clarified. Because, for > example, in the > FreeBSD world it looks to me like many administrators implement IPSec > tunnels by actually using a > "gif" interface, which is a virtual interface that performs IP-in-IP > tunneling on the datagrams > routed to it, and applying IPSec in *transport* mode to the datagrams that > exit the gif device. > At least, that's my take from researching the issue some. This does seem > like a perfectly effective > way of creating a tunnel using IPSec in transport mode only. In fact, its > even gotten me to > wondering whether IPSec tunnel mode should ever have been invented! Perhaps > even IPSec tunnel > mode itself is an example of putting too much implementation detail in a > specification! > Because perhaps the very same problem can be solved more elegantly the way > many users > of FreeBSD seem to solving it. And if that is true, then the layering > principals of good protocol > design would seem to dictate that there is no real need to mandate "native" > IPSec tunnels in > the specifications. > > I'm still in the fairly early stages of the implementation although I do > have running code. > Am I misunderstanding some of these issues? I'm late to the whole 2401bis > discussion. > I wasn't even aware a 2401bis effort was underway until I had already > started coding from 2401 > and pondering these issues. I was glad to see that a 2401bis effort was > underway and that > attempts were being made to address some of the very same issues that had me > perplexed after having > studied 2401. But I am also anxious to see the issues I found with 2401 > fixed in an elegant, > and implementation independent way in 2401bis. > > - Mike > > > > > > This could happen whether dynamic or static routing is used; the issue > > is flux in the forwarding table and whether it is _allowed_ to affect > > SPD selection. > > > > Calling the function "SPD selection" doesn't absolve the problem. > > > > Joe > > From owner-ipsec@lists.tislabs.com Tue Oct 21 14:42:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLgsI7042675; Tue, 21 Oct 2003 14:42:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07232 Tue, 21 Oct 2003 16:58:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F959CBC.2020706@isi.edu> References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <3F959CBC.2020706@isi.edu> Date: Tue, 21 Oct 2003 17:05:46 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: SPD issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:53 -0700 10/21/03, Joe Touch wrote: >Stephen Kent wrote: > >>Folks >> >>There may be some misunderstanding about what holes an SPD >>selection function creates. > > >... >>The only way to be really confident about the security services >>being provided for traffic is to have just one SPD, or to make sure >>that the multiple SPDs are not overlapping in terms of the >>destination addresses (for outbound traffic), or that the security >>services offered in any overlapping entries are equivalent. > >Steve, > >Is it possible that this paragraph ("The only way...") should be >added as the caveat? I.e., the concern I had was that SPD indexing >could be an open loophole; this closes it sufficiently. > >Feel free to forward this suggestion to the list if you feel it >would be useful. > >Joe Joe, Good point. I think it is fair to warn folks about the need to pay very close attention to config mgmt issues when multiple SPDs are employed. A reference to Peter's paper might also be relevant. Steve From owner-ipsec@lists.tislabs.com Tue Oct 21 18:31:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M1VFI7049354; Tue, 21 Oct 2003 18:31:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08122 Tue, 21 Oct 2003 20:37:29 -0400 (EDT) From: "Mike Taylor" To: "Paul Hoffman / VPNC" , Subject: RE: 2401bis-00 submitted to IETF Date: Tue, 21 Oct 2003 17:46:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm just getting to the point in my IPSec development where I need to start dealing with whatever issues arise related to ICMP error message processing, as discussed in Section 6. ICMP Processing Relevant to IPSec of 2401. I was just pondering the following language again in of 2401 when I received the email the draft: "An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel." I see that it has not been reworded in the draft. I suppose the meaning should be obvious to me, but being somewhat dense it isn't. What does the above mean? It can't really refer to the case, as a literal interpretation might suggest, that we have received an ICMP error message that has already had ESP or AH applied. Obviously in that case we should do the same thing with it as we would any other IP datagram we receive where the proto is AH or ESP - look it up in the SADB based on the SPI, protocol, and destination, and go from there. So initially I thought it was referring to the same type of issue as with PMTU, i.e., where we receive an ICMP error message from a router that contains an IP datagram with proto AH or ESP that appears to have been sent by the SG (i.e., sent on one of its tunnels). Is that the intent? For example, suppose that the router is reporting that the SG at the other end of the tunnel is unreachable. Then we would have to synthesize a DUR to send back to hosts on the trusted network similarly to how the handling of PMTU is described in Appendix B, except perhaps that local configuration could prevent us from doing this. So I'm concerned that I'm missing something important. Another reason I find it confusing is that a few paragraphs later we have "An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages." Now is it the intent of this paragraph that we would be desirable not to forward ICMP error messages from one end of a VPN to the other? In other words, that we shouldn't take red ICMP error messages coming in from one end of the VPN, apply IPSec, and send them in the tunnel ultimately to the red network at the other end of the VPN? That can't be. Surely we want to do that. We have to be able to trust ICMP error messages we receive from within the trusted network. Wouldn't make for much of a VPN if we couldn't. So I'm afraid I'm missing something fundamental here. Whether I am, or am not missing something, either way it seems to me that much of the text in Section 6 of the new draft ought to be reworded to clarify the meaning. Thanks, Mike > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Tuesday, October 21, 2003 10:39 AM > To: ipsec@lists.tislabs.com > Subject: Re: 2401bis-00 submitted to IETF > > > Since it might take a while for the draft to get posted in the > official IETF repository, there is a temporary copy of the draft > available at > . > This temporary copy will disappear when the official copy hits the > official repository. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Oct 21 18:47:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M1lNI7049831; Tue, 21 Oct 2003 18:47:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08241 Tue, 21 Oct 2003 21:05:41 -0400 (EDT) Message-ID: <3F95DA09.4A9DF4DE@cisco.com> Date: Tue, 21 Oct 2003 18:14:49 -0700 From: Tom Hu Reply-To: tomhu@cisco.com X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: EAP requestor for Initiator Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, In the ikev2 draft, explicitely describes EAP request initiated from Responder. Is it legit to have EAP request initiated from Initiator? Please see the below exchange. Is this against IKEv2 protocol? Note: when I said EAP requestor, it means that the node sends the first EAP packet. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH} HDR, SK {EAP, [AUTH]} --> <-- HDR, SK {EAP, [AUTH]} HDR, SK {EAP, [AUTH] } --> <-- HDR, SK {[AUTH], SAr2, TSi, TSr } Thanks, Tom Hu From owner-ipsec@lists.tislabs.com Tue Oct 21 19:08:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M28QI7050704; Tue, 21 Oct 2003 19:08:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08303 Tue, 21 Oct 2003 21:28:11 -0400 (EDT) From: "Mike Taylor" To: "Stephen Kent" , Subject: RE: SPD issues Date: Tue, 21 Oct 2003 18:37:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 Stephen Kent > Sent: Tuesday, October 21, 2003 2:06 PM > To: ipsec@lists.tislabs.com > Subject: Re: SPD issues > > > At 13:53 -0700 10/21/03, Joe Touch wrote: > >Stephen Kent wrote: > > > >>Folks > >> > >>There may be some misunderstanding about what holes an SPD > >>selection function creates. > > > > > >... > >>The only way to be really confident about the security services > >>being provided for traffic is to have just one SPD, or to make sure > >>that the multiple SPDs are not overlapping in terms of the > >>destination addresses (for outbound traffic), or that the security > >>services offered in any overlapping entries are equivalent. I don't see how having a single SPD helps. Even with a single SPD I can have two outbound policies for the datagrams that match a given source address where different levels of protection are applied based on the destination address. Suppose, for example, that I have an SG with 3 interfaces, one to an untrusted network, 192.168.0.0/24, and the other two to trusted private networks 10.240.1.0/24 and 10.240.2.0/24. And furthermore, there is a 3rd trusted subnet, 10.240.3.0, reachable via the router 10.240.1.1. Now I could have two policies in my one SPD for datagrams from source addresses on 10.240.2.0/24. If they're going to 192.168.0.0/24 then I want ESP encryption and authentication. If they're going to 10.240.3.0/24 then I just bypass IPSec. Then if routing gets messed up and a datagram from 10.240.2.0 and destined to 10.240.3.0 gets no IPSec applied but ends up being sent out of the 192.168.0.0/24 interface instead of 10.240.1.0 I have sent sensitive information in plaintext format onto an untrusted network. Still, I admit that I'm not sure this is something that can be dealt with easily by IPSec. It would seem to require that IPSec always be built natively into an IP stack, and that it is somehow tied very tightly to the forwarding database such that routes are essentially owned by IPSec and must have a policy, and furthermore, the interface to which the route points cannot be changed without the policy explicitly being redefined, in other words, delete the route and re-enter with a new policy. Of course, a human adminstrator could still very well make an error and point the route and the wrong interface. It seems to me that the ultimate problem is that it really isn't possible to provide rock solid security unless applications are aware of it, and it is provided end-to-end (i.e. no tunnel mode, SGs etc.) Ultimately this is the only model that properly fits the original concept of IP as an unreliable best-effort datagram delivery service. In an ideal world (that probably won't ever exist even after IPv6 becomes predominant) there would be nothing between hosts except pure routers. No NAT, no SGs, no proxies, etc. etc. As the forefathers knew, this is the only way to achieve a highly robust, self-healing Internet topology. Of course, this model would likely put a lot of us out of business. :( > > > >Steve, > > > >Is it possible that this paragraph ("The only way...") should be > >added as the caveat? I.e., the concern I had was that SPD indexing > >could be an open loophole; this closes it sufficiently. > > > >Feel free to forward this suggestion to the list if you feel it > >would be useful. > > > >Joe > Joe, > > Good point. I think it is fair to warn folks about the need to pay > very close attention to config mgmt issues when multiple SPDs are > employed. A reference to Peter's paper might also be relevant. > > Steve From owner-ipsec@lists.tislabs.com Wed Oct 22 02:12:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M9CeI7020136; Wed, 22 Oct 2003 02:12:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10750 Wed, 22 Oct 2003 04:29:11 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> Date: Wed, 22 Oct 2003 11:37:01 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: SPD issues In-Reply-To: References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > If there is more than one SPD (per interface or whatever) and if the > same destination is represented in more than one SPD, and if these > entries offer different choices for the security services to be > applied, where one of the choices may be less secure than the others, > then you have a problem, period. This is because many factors could > cause the traffic be be processed against the SPD that results in > applying a less secure set of services, e.g., bypass. For example, a > Trojan Horse in the net behind the IPsec device might deliberately > alter packet headers in an effort to cause the traffic to be mapped > to a different SPD. When we had per-interface SPDs, it was possible > that traffic destined for one outbound interface (that was deemed > secure) might be misrouted by the forwarding software after IPsec > processing is completed. There are many other examples. This actually brings one question I had earlier up. In IPv6 which addresses is used when matching against SPD in case there are routing headers in the packet? Final destination, next hop destination etc. I think the current RFC does not say anything about those, and some implementations might check only the routing header final destination address and some might use the next hop destination. -- 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 Oct 22 05:44:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCiaI7038799; Wed, 22 Oct 2003 05:44:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11850 Wed, 22 Oct 2003 08:04:41 -0400 (EDT) Date: Wed, 22 Oct 2003 15:13:29 +0300 Message-Id: <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> From: Markku Savela To: kivinen@ssh.fi CC: kent@bbn.com, ipsec@lists.tislabs.com In-reply-to: <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> (message from Tero Kivinen on Wed, 22 Oct 2003 11:37:01 +0300) Subject: Re: SPD issues References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Tero Kivinen > This actually brings one question I had earlier up. In IPv6 which > addresses is used when matching against SPD in case there are routing > headers in the packet? Final destination, next hop destination etc. I > think the current RFC does not say anything about those, and some > implementations might check only the routing header final destination > address and some might use the next hop destination. For me, it is the next hop destination. Note, however that if SG is also a router, there will be two cases for incoming packet with routing header: a) ip dst = routers own address => process routing header, IPSEC will apply to next hop. (which may be the router itself again). b) ip dst != routers own address, routing header is NOT processed, next hop is searched based on the ip dst address. Again, IPSEC apply to next hop. This is as it should be. Do not mess with it! From owner-ipsec@lists.tislabs.com Wed Oct 22 06:27:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDRwI7040632; Wed, 22 Oct 2003 06:27:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12059 Wed, 22 Oct 2003 08:45:39 -0400 (EDT) Date: Wed, 22 Oct 2003 14:54:49 +0200 Subject: Re: EAP requestor for Initiator Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipsec@lists.tislabs.com To: tomhu@cisco.com From: Yoav Nir In-Reply-To: <3F95DA09.4A9DF4DE@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the remote-access scenario, the client is always the initiator. In EAP, the gateway (or "authenticator") is always the initiator. How can it be that the IKE initiator will also initiate the EAP? Which is the client, and which is the gateway? On Wednesday, October 22, 2003, at 03:14 AM, Tom Hu wrote: > Hi all, > > In the ikev2 draft, explicitely describes EAP request initiated from > Responder. Is it legit to have EAP request initiated from Initiator? > Please see the below exchange. Is this against IKEv2 protocol? > > Note: when I said EAP requestor, it means that the node sends the first > EAP packet. > > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH} > HDR, SK {EAP, [AUTH]} --> > <-- HDR, SK {EAP, [AUTH]} > > HDR, SK {EAP, [AUTH] } --> > <-- HDR, SK {[AUTH], SAr2, TSi, TSr } > > Thanks, > > Tom Hu > From owner-ipsec@lists.tislabs.com Wed Oct 22 06:36:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDaZI7040883; Wed, 22 Oct 2003 06:36:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12135 Wed, 22 Oct 2003 08:52:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 22 Oct 2003 08:57:45 -0400 To: "Mike Taylor" From: Stephen Kent Subject: RE: 2401bis-00 submitted to IETF Cc: "Paul Hoffman / VPNC" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, We're still working on a major new section on ICMP processing that replaces the old 2401 text. It should be out relatively soon, as a new issue, though it is not in the draft that was just released. Let's see how your questions are addressed by the new text. Steve P.S. Again, note the correct spelling is "IPsec", not "IPSec." 2401bis will make an explicit point of this, as per the WG chairs' request. From bloren@email.com Wed Oct 22 06:54:30 2003 Received: from 0IJRIMXOOP0QMP3 ([61.48.72.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9MDs5I7041775 for ; Wed, 22 Oct 2003 06:54:18 -0700 (PDT) (envelope-from bloren@email.com) Message-Id: <200310221354.h9MDs5I7041775@above.proper.com> From: "bloren@email.com" To: "ietf-ipsec@imc.org" Subject: feel like you where 18 again Date: Wed, 22 Oct 2003 21:57:39 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PFRJVExFPnJhbmQ8L1RJVExFPjwvSEVBRD4NCjxCT0RZIGJnY29sb3I9ImJs dWVzIj48ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIHdpZHRoPTUwMHB4IGJnY29sb3I9ImJs YWNrIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBib3JkZXJjb2xvcmxpZ2h0PSJ3aGl0ZSIgYm9y ZGVyPSIxIiBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5nPTA+PHRyPjx0ZCBhbGlnbj0iY2VudGVy Ij4NCjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEiIGNvbG9yPSJ3aGl0ZSI+PGI+TEFURVNU IEJSRUFLVEhST1VHSCAtIE5FV1MgRkxBU0g8L2I+PC9mb250Pg0KPC90ZD48L3RyPjwvdGFibGU+ DQo8YnI+DQo8dGFibGUgd2lkdGg9NTAwcHggYmdjb2xvcj0iYmxhY2siIGJvcmRlcmNvbG9yZGFy az0ieWVsbG93IiBib3JkZXJjb2xvcmxpZ2h0PSJ5ZWxsb3ciIGJvcmRlcj0iMSIgY2VsbHBhZGRp bmc9MCBjZWxsc3BhY2luZz0wPjx0cj48dGQgYWxpZ249ImNlbnRlciI+DQo8Zm9udCBzaXplPSIz IiBmYWNlPSJWZXJkYW5hIiBjb2xvcj0id2hpdGUiPjxiPjxicj4NClRoZSA8Zm9udCBjb2xvcj0i cmVkIj5CQUQ8L2ZvbnQ+IE5ld3M6IDxpPkFzIHlvdSBBZ2UgeW91ciBib2R5IHByb2R1Y2VzIGxl c3MgaG9ybW9uZXMgY2F1c2luZyB5b3UgdG8gbG9vayBvbGRlciwgZmVlbCBvbGRlciBhbmQgYmUg d2Vha2VyITwvaT4NCjxicj48YnI+DQombmJzcDtUaGUgPGZvbnQgY29sb3I9IiMwMENDNjYiPkdP T0Q8L2ZvbnQ+IE5ld3M6IDxpPkV4cGVydHMgaW4gdGhlIE5ldyBFbmdsYW5kIEpvdXJuYWwgb2Yg TWVkaWNpbmUsIHJlcG9ydCB0aGF0IEh1bWFuIEdyb3d0aCBIb3Jtb25lIHRoZXJhcHkgbWFrZXMg eW91IGxvb2sgYW5kIGZlZWwgMjAgWUVBUlMgWU9VTkdFUiE8L2k+PGJyPjxicj48L2I+PC9mb250 Pg0KPC90ZD48L3RyPjwvdGFibGU+DQo8YnI+DQo8dGFibGUgd2lkdGg9NTAwcHggYmdjb2xvcj0i d2hpdGUiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9IndoaXRlIiBi b3JkZXI9IjEiIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNpbmc9MD48dHI+PHRkIGFsaWduPSJjZW50 ZXIiPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmxhbmsuY29tLyI+PGZvbnQgc2l6ZT0iNSIg ZmFjZT0iVmVyZGFuYSIgY29sb3I9ImJsdWUiPjxiPkNsaWNrIEhlcmUgRm9yIE1vcmUgSW5mbzwv Yj48L2ZvbnQ+PC9hPjxicj48YnI+DQo8L3RkPjwvdHI+PC90YWJsZT4NCjwvZGl2PjwvQk9EWT48 L0hUTUw+DQo= From owner-ipsec@lists.tislabs.com Wed Oct 22 06:55:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDtdI7042123; Wed, 22 Oct 2003 06:55:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12286 Wed, 22 Oct 2003 09:12:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 22 Oct 2003 09:16:41 -0400 To: "Mike Taylor" From: Stephen Kent Subject: RE: SPD issues Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 18:37 -0700 10/21/03, Mike Taylor wrote: > > -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent >> Sent: Tuesday, October 21, 2003 2:06 PM >> To: ipsec@lists.tislabs.com >> Subject: Re: SPD issues >> >> >> At 13:53 -0700 10/21/03, Joe Touch wrote: >> >Stephen Kent wrote: >> > >> >>Folks >> >> >> >>There may be some misunderstanding about what holes an SPD >> >>selection function creates. >> > >> > >> >... >> >>The only way to be really confident about the security services >> >>being provided for traffic is to have just one SPD, or to make sure >> >>that the multiple SPDs are not overlapping in terms of the >> >>destination addresses (for outbound traffic), or that the security >> >>services offered in any overlapping entries are equivalent. > >I don't see how having a single SPD helps. Even with a single >SPD I can have two outbound policies for the datagrams that match a given >source address where different levels of protection are applied based >on the destination address. Suppose, for example, that I have an SG >with 3 interfaces, one to an untrusted network, 192.168.0.0/24, >and the other two to trusted private networks 10.240.1.0/24 and >10.240.2.0/24. >And furthermore, there is a 3rd trusted subnet, 10.240.3.0, reachable >via the router 10.240.1.1. > >Now I could have two policies in my one SPD for datagrams from source >addresses on 10.240.2.0/24. If they're going to 192.168.0.0/24 then I want >ESP encryption and authentication. If they're going to 10.240.3.0/24 then >I just bypass IPSec. > >Then if routing gets messed up and a datagram from 10.240.2.0 and destined >to 10.240.3.0 gets no IPSec applied but ends up being sent out of the >192.168.0.0/24 interface instead of 10.240.1.0 I have sent sensitive >information >in plaintext format onto an untrusted network. IPsec really defines a boundary (what we woulkd traditionally call a red/black boundary) that packets traverse. if you decide that the interfaces to the trusted nets are on the red side of an IPsec device with multiple interfaces, then IPsec would not be invoked at all. if you put interfaces on the black side, you have made a mistake, because you are explicitly relying on the routing/forwarding on the black side to do the right thing. >Still, I admit that I'm not sure this is something that can be dealt with >easily by IPSec. It would seem to require that IPSec always be built >natively >into an IP stack, and that it is somehow tied very tightly to the forwarding >database such that routes are essentially owned by IPSec and must have a >policy, >and furthermore, the interface to which the route points cannot be changed >without >the policy explicitly being redefined, in other words, delete the route and >re-enter >with a new policy. Of course, a human adminstrator could still very well >make an error and >point the route and the wrong interface. see comments above > >It seems to me that the ultimate problem is that it really isn't >possible to provide rock solid security unless applications are aware of it, >and >it is provided end-to-end (i.e. no tunnel mode, SGs etc.) Ultimately this >is the only model that properly fits the original concept of IP as an >unreliable >best-effort datagram delivery service. In an ideal world (that probably >won't >ever exist even after IPv6 becomes predominant) there would be nothing >between >hosts except pure routers. No NAT, no SGs, no proxies, etc. etc. As the >forefathers >knew, this is the only way to achieve a highly robust, self-healing Internet >topology. Of course, this model would likely put a lot of us out of >business. :( I think you are overstating the problem a bit. IPsec is designed to that one can deploy it in a variety of configurations without requiring applications to be aware of its presence. However, one can certainly misconfigure SPDs to undermine the security offered, and if one allows bypass of certain traffic, then there will always be channels that can be used to exfiltrate data from a host or site. Steve From owner-ipsec@lists.tislabs.com Wed Oct 22 07:17:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEH3I7042828; Wed, 22 Oct 2003 07:17:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12435 Wed, 22 Oct 2003 09:32:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 22 Oct 2003 09:37:48 -0400 To: "Mike Taylor" From: Stephen Kent Subject: RE: 2401bis-00 submitted to IETF Cc: "Paul Hoffman / VPNC" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:46 -0700 10/21/03, Mike Taylor wrote: >I'm just getting to the point in my IPSec development where I need >to start dealing with whatever issues arise related to ICMP error >message processing, as discussed in > > Section 6. ICMP Processing Relevant to IPSec > >of 2401. > >I was just pondering the following language again in of 2401 when I received >the >email the draft: > > "An ICMP error message protected by AH or ESP and generated by a > router SHOULD be processed and forwarded in a tunnel mode SA. Local > policy determines whether or not it is subjected to source address > checks by the router at the destination end of the tunnel." > >I see that it has not been reworded in the draft. I suppose the meaning >should be >obvious to me, but being somewhat dense it isn't. > >What does the above mean? It can't really refer to the case, as a literal >interpretation might suggest, that we have received an ICMP error message >that has already had ESP or AH applied. Obviously in that case we should >do the same thing with it as we would any other IP datagram we receive >where the proto is AH or ESP - look it up in the SADB based on the SPI, >protocol, >and destination, and go from there. It's not that easy. If we apply the SA selectors to the ICMP message, there is still the concern that the content of the message could be hostile, e.g., it might be a destination unreachable message for a host or net that is not consistent with the SA via which it was received. in our new text we explain why it is necessary to send this sort of traffic off for additional examination. > >So initially I thought it was referring to the same type of issue as with >PMTU, i.e., >where we receive an ICMP error message from a router that contains an IP >datagram >with proto AH or ESP that appears to have been sent by the SG (i.e., sent on >one >of its tunnels). Is that the intent? For example, suppose that the router >is >reporting that the SG at the other end of the tunnel is unreachable. Then >we would >have to synthesize a DUR to send back to hosts on the trusted network >similarly >to how the handling of PMTU is described in Appendix B, except perhaps that >local >configuration could prevent us from doing this. > >So I'm concerned that I'm missing something important. Another reason I >find it confusing >is that a few paragraphs later we have > > "An ICMP message not protected by AH or ESP is unauthenticated and its > processing and/or forwarding may result in denial of service. This > suggests that, in general, it would be desirable to ignore such > messages." > >Now is it the intent of this paragraph that we would be desirable not to >forward ICMP error messages from one end of a VPN to the other? In other >words, >that we shouldn't take red ICMP error messages coming in from one end of the >VPN, >apply IPSec, and send them in the tunnel ultimately to the red network at >the >other end of the VPN? That can't be. Surely we want to do that. We have >to >be able to trust ICMP error messages we receive from within the trusted >network. >Wouldn't make for much of a VPN if we couldn't. no, this text refers to black ICMP messages. > >So I'm afraid I'm missing something fundamental here. Whether I am, or am >not >missing something, either way it seems to me that much of the text >in Section 6 of the new draft ought to be reworded to clarify the meaning. > yes, the text is being revised significantly to be more comprehensive and clearer. Steve From owner-ipsec@lists.tislabs.com Wed Oct 22 12:01:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MJ1AI7056605; Wed, 22 Oct 2003 12:01:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14074 Wed, 22 Oct 2003 13:56:54 -0400 (EDT) Message-ID: <3F96C70E.EA6833D2@cisco.com> Date: Wed, 22 Oct 2003 11:06:06 -0700 From: Tom Hu Reply-To: tomhu@cisco.com X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoav Nir CC: ipsec@lists.tislabs.com Subject: Re: EAP requestor for Initiator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav, Thank your reply. I do not think my case is not client-server model. It rather peer-to-peer model. The application is, for example, the initiator (untrusted peer) want to join the secured cloud, it has to pass the authZ first. To pass the authz, the initiator has to talk to the Authorization server thru the proxy (responder is a proxy server). In this case, we want the initiator to start EAP negotiation, not responder. It looks like EAP in ikev2 draft is only applicant to the client-server model. Tom Hu Yoav Nir wrote: > > In the remote-access scenario, the client is always the initiator. In > EAP, the gateway (or "authenticator") is always the initiator. How can > it be that the IKE initiator will also initiate the EAP? Which is the > client, and which is the gateway? > > On Wednesday, October 22, 2003, at 03:14 AM, Tom Hu wrote: > > > Hi all, > > > > In the ikev2 draft, explicitely describes EAP request initiated from > > Responder. Is it legit to have EAP request initiated from Initiator? > > Please see the below exchange. Is this against IKEv2 protocol? > > > > Note: when I said EAP requestor, it means that the node sends the first > > EAP packet. > > > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH} > > HDR, SK {EAP, [AUTH]} --> > > <-- HDR, SK {EAP, [AUTH]} > > > > HDR, SK {EAP, [AUTH] } --> > > <-- HDR, SK {[AUTH], SAr2, TSi, TSr } > > > > Thanks, > > > > Tom Hu > > From owner-ipsec@lists.tislabs.com Wed Oct 22 13:41:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKfSI7061366; Wed, 22 Oct 2003 13:41:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14745 Wed, 22 Oct 2003 15:52:35 -0400 (EDT) Message-ID: <3F96E22B.B56949E8@cisco.com> Date: Wed, 22 Oct 2003 13:01:47 -0700 From: Tom Hu Reply-To: tomhu@cisco.com X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoav Nir CC: ipsec@lists.tislabs.com Subject: Re: EAP requestor for Initiator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav, Thank your reply. I do not think my case is a client-server model. It rather peer-to-peer model. The application is, for example, the initiator (untrusted peer) want to join the secured cloud, it has to pass the authZ first. To pass the authz, the initiator has to talk to the Authorization server thru the proxy (responder is a proxy server). In this case, we want the initiator to start EAP negotiation, not responder. It looks like EAP in ikev2 draft is only applicant to the client-server model. Tom Hu Yoav Nir wrote: > > In the remote-access scenario, the client is always the initiator. In > EAP, the gateway (or "authenticator") is always the initiator. How can > it be that the IKE initiator will also initiate the EAP? Which is the > client, and which is the gateway? > > On Wednesday, October 22, 2003, at 03:14 AM, Tom Hu wrote: > > > Hi all, > > > > In the ikev2 draft, explicitely describes EAP request initiated from > > Responder. Is it legit to have EAP request initiated from Initiator? > > Please see the below exchange. Is this against IKEv2 protocol? > > > > Note: when I said EAP requestor, it means that the node sends the first > > EAP packet. > > > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH} > > HDR, SK {EAP, [AUTH]} --> > > <-- HDR, SK {EAP, [AUTH]} > > > > HDR, SK {EAP, [AUTH] } --> > > <-- HDR, SK {[AUTH], SAr2, TSi, TSr } > > > > Thanks, > > > > Tom Hu > > From owner-ipsec@lists.tislabs.com Wed Oct 22 21:01:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N41qI7078354; Wed, 22 Oct 2003 21:01:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17109 Wed, 22 Oct 2003 23:18:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 22 Oct 2003 23:31:23 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 89 -- Remove the selector "name" Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 89 Title: Remove the selector "name" Description =========== In the interest of simplifying things, we propose to remove the selector "Name". Is anyone using this selector? Proposed approach ================= Remove text such as the following: [From Section 4.4.2 "Selectors"] "- Name: There are 2 cases (Note that these name forms are supported in the IPsec DOI.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name NOTE: One of the possible values of this selector is "OPAQUE". [REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs. o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations]" Thank you, Karen From owner-ipsec@lists.tislabs.com Wed Oct 22 21:01:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N41qI7078356; Wed, 22 Oct 2003 21:01:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17110 Wed, 22 Oct 2003 23:18:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 22 Oct 2003 23:31:38 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 90 -- Remove the selector "data sensitivity level" Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 90 Title: Remove the selector "data sensitivity level" Description =========== In the interest of simplifying things, we propose to remove the selector "data sensitivity level". Is anyone using this selector? Proposed approach ================= Remove text such as the following: [From Section 4.4.2 "Selectors"] "- Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.]" "8.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance"." Thank you, Karen From owner-ipsec@lists.tislabs.com Thu Oct 23 03:29:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NATBI7056831; Thu, 23 Oct 2003 03:29:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19307 Thu, 23 Oct 2003 05:37:46 -0400 (EDT) Message-ID: <3F97A396.5040300@nomadiclab.com> Date: Thu, 23 Oct 2003 12:47:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Discuss , Multi6 WG , Mobile IPv6 WG , Mobile IPv4 WG , IPsec WG Cc: hipsec@honor.trusecure.com, hipsec@honor.trusecure.com Subject: Host Identity Protocol Architecture and BOF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From owner-ipsec@lists.tislabs.com Thu Oct 23 03:36:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NAaRI7057042; Thu, 23 Oct 2003 03:36:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19350 Thu, 23 Oct 2003 05:48:53 -0400 (EDT) Date: Thu, 23 Oct 2003 11:57:59 +0200 Subject: Re: EAP requestor for Initiator Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipsec@lists.tislabs.com To: tomhu@cisco.com From: Yoav Nir In-Reply-To: <3F96C70E.EA6833D2@cisco.com> Message-Id: <61E95264-053F-11D8-9C10-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is true that EAP was added to IKEv2 with the roaming user in mind. However, I think your case is very similar: - The initiator (or "peer") wants to join the cloud, so it begins the responder (or "authenticator" or "proxy server") - The proxy server wants to verify the initiator's identity. For verifying identities, it relies on the services of an external server, called the "authentication server". This could be LDAP, or RADIUS or SecurID of whatever. - The authentication server starts an EAP conversation with the "peer", tunneled through the authenticator (the responder) - When it is satisfied, it sends a notification to the responder, which sends the client an EAP success. This is how EAP works. It always looks like the authenticator (responder) is starting the conversation. See section 2 of RFC 2284. On Wednesday, October 22, 2003, at 08:06 PM, Tom Hu wrote: > Yoav, > > Thank your reply. > > I do not think my case is not client-server model. > It rather peer-to-peer model. > > The application is, for example, the initiator (untrusted peer) want to > join the secured cloud, it has to pass the authZ first. > > To pass the authz, the initiator has to talk to the Authorization > server > thru the proxy (responder is a proxy server). > > In this case, we want the initiator to start EAP negotiation, not > responder. > > It looks like EAP in ikev2 draft is only applicant to the client-server > model. > > Tom Hu > Yoav Nir wrote: >> >> In the remote-access scenario, the client is always the initiator. In >> EAP, the gateway (or "authenticator") is always the initiator. How >> can >> it be that the IKE initiator will also initiate the EAP? Which is the >> client, and which is the gateway? >> >> On Wednesday, October 22, 2003, at 03:14 AM, Tom Hu wrote: >> >>> Hi all, >>> >>> In the ikev2 draft, explicitely describes EAP request initiated from >>> Responder. Is it legit to have EAP request initiated from Initiator? >>> Please see the below exchange. Is this against IKEv2 protocol? >>> >>> Note: when I said EAP requestor, it means that the node sends the >>> first >>> EAP packet. >>> >>> >>> Initiator Responder >>> ----------- ----------- >>> HDR, SAi1, KEi, Ni --> >>> <-- HDR, SAr1, KEr, Nr, [CERTREQ] >>> >>> HDR, SK {IDi, [CERTREQ,] [IDr,] >>> SAi2, TSi, TSr} --> >>> <-- HDR, SK {IDr, [CERT,] AUTH} >>> HDR, SK {EAP, [AUTH]} --> >>> <-- HDR, SK {EAP, [AUTH]} >>> >>> HDR, SK {EAP, [AUTH] } --> >>> <-- HDR, SK {[AUTH], SAr2, TSi, TSr >>> } >>> >>> Thanks, >>> >>> Tom Hu >>> > From owner-ipsec@lists.tislabs.com Thu Oct 23 06:31:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDVAI7063510; Thu, 23 Oct 2003 06:31:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20448 Thu, 23 Oct 2003 08:35:47 -0400 (EDT) Message-ID: <3F97A396.5040300@nomadiclab.com> Date: Thu, 23 Oct 2003 12:47:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: utthan.nakarmi@bt.com, pam.kelly@bt.com, graham.travers@bt.com, matthew.ford@bt.com, "paul.bennett@bt.com Mobile IPv6 WG" , Mobile IPv4 WG , IPsec WG Cc: hipsec@honor.trusecure.com, hipsec@honor.trusecure.com Subject: Host Identity Protocol Architecture and BOF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2003 10:08:54.0446 (UTC) FILETIME=[AA418CE0:01C3994D] X-Antispam: Blocked as spam by Teamconnect Anti Spam Check v1.1 X-Original-To: IETF Discuss , Multi6 WG , Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From owner-ipsec@lists.tislabs.com Thu Oct 23 06:31:11 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NDVBI7063511; Thu, 23 Oct 2003 06:31:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20449 Thu, 23 Oct 2003 08:35:47 -0400 (EDT) Message-ID: <3F97A396.5040300@nomadiclab.com> Date: Thu, 23 Oct 2003 12:47:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: matthew.ford@bt.com, "fraser.3.christie@bt.com Mobile IPv6 WG" , Mobile IPv4 WG , IPsec WG Cc: hipsec@honor.trusecure.com, hipsec@honor.trusecure.com Subject: Host Identity Protocol Architecture and BOF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-OriginalArrivalTime: 23 Oct 2003 09:59:44.0160 (UTC) FILETIME=[62429200:01C3994C] X-Antispam: Blocked as spam by Teamconnect Anti Spam Check v1.1 X-Original-To: IETF Discuss , Multi6 WG , Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From owner-ipsec@lists.tislabs.com Thu Oct 23 07:10:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NEAFI7064864; Thu, 23 Oct 2003 07:10:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20770 Thu, 23 Oct 2003 09:26:43 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16279.55527.424820.593494@ryijy.hel.fi.ssh.com> Date: Thu, 23 Oct 2003 16:34:31 +0300 From: Tero Kivinen To: Markku Savela Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: SPD issues In-Reply-To: <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> References: <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela writes: > For me, it is the next hop destination. Note, however that if SG is > also a router, there will be two cases for incoming packet with > routing header: > a) ip dst = routers own address => process routing header, IPSEC will > apply to next hop. (which may be the router itself again). > b) ip dst != routers own address, routing header is NOT processed, > next hop is searched based on the ip dst address. Again, IPSEC apply > to next hop. > This is as it should be. Do not mess with it! That interpretation is fine as long as there is nothing that looks like firewall there. In the IPsec there are drop rules so it have a minimal firewall inside of the IPsec implementation. Using the routing header allows users to bypass the restrictions created by the adminstrator. I.e Adminstrator defines policy of the SGW in the remote office: Host - SGW - Internet - SGW ----+--- internal net | +--- smtp server | +--- www-proxy | +--- news server 1) Any traffic to www-proxy is allowed (bypass) 2) Any traffic to smtp server is protected by IPsec 3) Drop all other traffic. Now if users want to use some other services, like news server they can send the packet to the www-proxy with routing header forwarding the traffic to the news server, and that will go through even when we have the rule 3, that says that traffic should be dropped. They can also use the www-proxy to send traffic to the smtp-server, which will now go through the internet in clear instead of using IPsec protection as specified in rule 2. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 23 07:51:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NEpKI7066098; Thu, 23 Oct 2003 07:51:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21124 Thu, 23 Oct 2003 10:01:09 -0400 (EDT) Date: Thu, 23 Oct 2003 10:08:14 -0400 From: Dan McDonald To: Karen Seo Cc: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi Subject: Re: 2401bis Issue # 90 -- Remove the selector "data sensitivity level" Message-ID: <20031023140814.GB597@kebe.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Oct 22, 2003 at 11:31:38PM -0400, Karen Seo wrote: > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 90 > > Title: Remove the selector "data sensitivity level" > > > Description > =========== > In the interest of simplifying things, we propose to remove the > selector "data sensitivity level". Is anyone using this selector? Not yet, but soon. I would highly recommend keeping this text in 2401bis. Some of us fought very hard to keep it in 2401, and don't wish to see it go away just yet. If you wish it to be more simple for a non-MLS someone reading the spec, you should place the additional selector text in section 8 somewhere. Keep in mind, this selector allows two MLS systems to use separate SPD entries to protect different sensitivity-level data with appropriate protection. Dan From owner-ipsec@lists.tislabs.com Thu Oct 23 07:51:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NEpLI7066099; Thu, 23 Oct 2003 07:51:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21112 Thu, 23 Oct 2003 10:00:00 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: microsoft's patent X-Mailer: Cue version 0.6 (031023-1051/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031023124216H.sakane@tanu.org> Date: Thu, 23 Oct 2003 12:42:16 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 6 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk there is the statement about IKEv2: http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-ipsec-ikev2.txt this statement refers to draft-ietf-ipsec-ikev2-08.txt. is there no problem at the current IKEv2 specification ? or have you discussed about the IPR ? From owner-ipsec@lists.tislabs.com Thu Oct 23 08:50:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NFoTI7068832; Thu, 23 Oct 2003 08:50:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21629 Thu, 23 Oct 2003 11:00:52 -0400 (EDT) Message-Id: <5.1.0.14.2.20031023170319.079ac2f0@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Oct 2003 17:09:57 +0200 To: Tero Kivinen From: Eric Vyncke Subject: IPv6 RH (was Re: SPD issues) Cc: Markku Savela , kent@bbn.com, ipsec@lists.tislabs.com In-Reply-To: <16279.55527.424820.593494@ryijy.hel.fi.ssh.com> References: <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 23 Oct 2003 15:10:04.0060 (UTC) FILETIME=[BC95D5C0:01C39977] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:34 23/10/2003 +0300, Tero Kivinen wrote: >Markku Savela writes: >> For me, it is the next hop destination. Note, however that if SG is >> also a router, there will be two cases for incoming packet with >> routing header: >> a) ip dst = routers own address => process routing header, IPSEC will >> apply to next hop. (which may be the router itself again). >> b) ip dst != routers own address, routing header is NOT processed, >> next hop is searched based on the ip dst address. Again, IPSEC apply >> to next hop. >> This is as it should be. Do not mess with it! > >That interpretation is fine as long as there is nothing that looks >like firewall there. In the IPsec there are drop rules so it have a >minimal firewall inside of the IPsec implementation. Using the routing >header allows users to bypass the restrictions created by the >adminstrator. Tero, I tend to agree with your interpretation, the decision should be based on the final destination and not on the next hop. This is clear for the bypass/drop 'firewall' SPD entry. AFAIK with the existing IPv4 implementations, the source routing option has been ignored by IPSec (it looked only to the IP destination address). Of course, IPv6 is much more complex; specifically since Mobile IPv6 is also using RH. And, there you probably want to make your decision on the next hop... Contracdicting my first paragraph ;-) Perhaps, the decision should be made if either the destination IP or any RH next-hop IP are matching the selector? -eric From owner-ipsec@lists.tislabs.com Thu Oct 23 09:32:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NGWsI7070241; Thu, 23 Oct 2003 09:32:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22165 Thu, 23 Oct 2003 11:48:20 -0400 (EDT) Message-ID: <3F97FA6A.7000207@airespace.com> Date: Thu, 23 Oct 2003 08:57:30 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karen Seo CC: ipsec mailingList Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" References: In-Reply-To: X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2003 15:57:34.0826 (UTC) FILETIME=[5FC634A0:01C3997E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The name selector is often used for remote access, and maybe for other applications. I know of several ipsec implementations which use fqdn for remote access policy selection, and without DN, how do we apply access controls based on certs? Scott Karen Seo wrote: > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 89 > > Title: Remove the selector "name" > > Description > =========== > In the interest of simplifying things, we propose to remove the selector > "Name". Is anyone using this selector? > > Proposed approach > ================= > Remove text such as the following: > > [From Section 4.4.2 "Selectors"] > > "- Name: There are 2 cases (Note that these name forms are > supported in the IPsec DOI.) > 1. User ID > a. a fully qualified user name string (DNS), > e.g., mozart@foo.bar.com > b. X.500 distinguished name, e.g., C = US, > SP = MA, O = GTE Internetworking, CN = > Stephen T. Kent. > 2. System name (host, security gateway, etc.) > a. a fully qualified DNS name, e.g., > foo.bar.com > b. X.500 distinguished name > c. X.500 general name > > NOTE: One of the possible values of this selector is > "OPAQUE". > > [REQUIRED for the following cases. Note that support > for name forms other than addresses is not required for > manually keyed SAs. > o User ID > - native host implementations > - BITW and BITS implementations acting as HOSTS > with only one user > - security gateway implementations for INBOUND > processing. > o System names -- all implementations]" > > Thank you, > Karen > From owner-ipsec@lists.tislabs.com Thu Oct 23 10:30:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NHUJI7072342; Thu, 23 Oct 2003 10:30:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22717 Thu, 23 Oct 2003 12:42:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3F97FA6A.7000207@airespace.com> References: <3F97FA6A.7000207@airespace.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 23 Oct 2003 09:51:58 -0700 To: "Scott G. Kelly" , Karen Seo From: Paul Hoffman / VPNC Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:57 AM -0700 10/23/03, Scott G. Kelly wrote: >The name selector is often used for remote access, and maybe for >other applications. I know of several ipsec implementations which >use fqdn for remote access policy selection, and without DN, how do >we apply access controls based on certs? This has been debated many times before. Some systems have policies that allow any cert that is signed by the trusted CA to have access. That is, the granularity is based on the trusted root, not on the identity. This means that a sysadmin doesn't have to list a zillion users, all of whom have identical access rights; it also means that the user has access as soon as they have their cert, without interaction from the sysadmin who is just going to duplicate what they did for the last user. Names are useful for systems that differentiate by user, but they kill the ability to differentiate by certifier. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Oct 23 10:44:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NHiOI7072750; Thu, 23 Oct 2003 10:44:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22871 Thu, 23 Oct 2003 12:54:17 -0400 (EDT) Message-ID: <3F9809DD.6030301@airespace.com> Date: Thu, 23 Oct 2003 10:03:25 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Karen Seo , ipsec mailingList Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" References: <3F97FA6A.7000207@airespace.com> In-Reply-To: X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2003 17:03:30.0077 (UTC) FILETIME=[95499CD0:01C39987] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, First, let's be clear: some folks use fqdn as a psk selector in remote access. This is distinct from the DN/GN question, and the two should not (necessarily) be lumped into one bin. As for DN/GN, the fact that some folks choose not to use this does not mean it is not useful, or that it should be eliminated. Why not leave it in, so that people who choose to use it have that option? Otherwise, those wanting such functionality will be forced to be creative, and this results in less rather than more interoperability. I think the argument you make below actually suggests the need for a new name type (i.e. issuerName), rather than making the case for removing DN/GN. The bottom line is that we need non-numeric ways to identify peers. How will we do that if these ID types are eliminated? Scott Paul Hoffman / VPNC wrote: > At 8:57 AM -0700 10/23/03, Scott G. Kelly wrote: > >> The name selector is often used for remote access, and maybe for other >> applications. I know of several ipsec implementations which use fqdn >> for remote access policy selection, and without DN, how do we apply >> access controls based on certs? > > > This has been debated many times before. Some systems have policies that > allow any cert that is signed by the trusted CA to have access. That is, > the granularity is based on the trusted root, not on the identity. This > means that a sysadmin doesn't have to list a zillion users, all of whom > have identical access rights; it also means that the user has access as > soon as they have their cert, without interaction from the sysadmin who > is just going to duplicate what they did for the last user. > > Names are useful for systems that differentiate by user, but they kill > the ability to differentiate by certifier. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Oct 23 10:49:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NHn2I7072904; Thu, 23 Oct 2003 10:49:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23006 Thu, 23 Oct 2003 13:06:45 -0400 (EDT) Message-ID: <3F980CB9.AC8C3291@cisco.com> Date: Thu, 23 Oct 2003 10:15:37 -0700 From: Tom Hu X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoav Nir CC: ipsec@lists.tislabs.com Subject: Re: EAP requestor for Initiator References: <61E95264-053F-11D8-9C10-000A95834BAA@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav, I totally agree and understand your description in the last mail from ikev2. My question is: Can I have either the initiator or responder as Authenticator since my case is peer to peer (not client-server)? Or the Authenticator has to be Responder? I want Initiator as Authenticator and let initiator start the EAP request, can it be? If yes, then how the ikev2 exchange looks like? Yoav Nir wrote: > > It is true that EAP was added to IKEv2 with the roaming user in mind. > However, I think your case is very similar: > - The initiator (or "peer") wants to join the cloud, so it begins the > responder (or "authenticator" or "proxy server") > - The proxy server wants to verify the initiator's identity. For > verifying identities, it relies on the services of an external server, > called the "authentication server". This could be LDAP, or RADIUS or > SecurID of whatever. > - The authentication server starts an EAP conversation with the "peer", > tunneled through the authenticator (the responder) > - When it is satisfied, it sends a notification to the responder, which > sends the client an EAP success. > > This is how EAP works. It always looks like the authenticator > (responder) is starting the conversation. See section 2 of RFC 2284. > > On Wednesday, October 22, 2003, at 08:06 PM, Tom Hu wrote: > > > Yoav, > > > > Thank your reply. > > > > I do not think my case is not client-server model. > > It rather peer-to-peer model. > > > > The application is, for example, the initiator (untrusted peer) want to > > join the secured cloud, it has to pass the authZ first. > > > > To pass the authz, the initiator has to talk to the Authorization > > server > > thru the proxy (responder is a proxy server). > > > > In this case, we want the initiator to start EAP negotiation, not > > responder. > > > > It looks like EAP in ikev2 draft is only applicant to the client-server > > model. > > > > Tom Hu > > Yoav Nir wrote: > >> > >> In the remote-access scenario, the client is always the initiator. In > >> EAP, the gateway (or "authenticator") is always the initiator. How > >> can > >> it be that the IKE initiator will also initiate the EAP? Which is the > >> client, and which is the gateway? > >> > >> On Wednesday, October 22, 2003, at 03:14 AM, Tom Hu wrote: > >> > >>> Hi all, > >>> > >>> In the ikev2 draft, explicitely describes EAP request initiated from > >>> Responder. Is it legit to have EAP request initiated from Initiator? > >>> Please see the below exchange. Is this against IKEv2 protocol? > >>> > >>> Note: when I said EAP requestor, it means that the node sends the > >>> first > >>> EAP packet. > >>> > >>> > >>> Initiator Responder > >>> ----------- ----------- > >>> HDR, SAi1, KEi, Ni --> > >>> <-- HDR, SAr1, KEr, Nr, [CERTREQ] > >>> > >>> HDR, SK {IDi, [CERTREQ,] [IDr,] > >>> SAi2, TSi, TSr} --> > >>> <-- HDR, SK {IDr, [CERT,] AUTH} > >>> HDR, SK {EAP, [AUTH]} --> > >>> <-- HDR, SK {EAP, [AUTH]} > >>> > >>> HDR, SK {EAP, [AUTH] } --> > >>> <-- HDR, SK {[AUTH], SAr2, TSi, TSr > >>> } > >>> > >>> Thanks, > >>> > >>> Tom Hu > >>> > > From owner-ipsec@lists.tislabs.com Thu Oct 23 12:01:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NJ1wI7075388; Thu, 23 Oct 2003 12:01:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23504 Thu, 23 Oct 2003 14:12:02 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: November 2003 Minneapolis IETF Meeting From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Thu, 23 Oct 2003 14:17:29 -0400 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSEC working group meeting has been scheduled for Monday, November 10th at 1300-1500. Currently, the only agenda item scheduled is finalizing any remaining issues related to RFC 2401bis. If anyone has any other business that they feel should be addressed by the working group, please let Barbara and I know as soon as possible. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Thu Oct 23 14:21:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLLFI7081062; Thu, 23 Oct 2003 14:21:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24716 Thu, 23 Oct 2003 16:33:06 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16280.15578.299171.410377@ryijy.hel.fi.ssh.com> Date: Thu, 23 Oct 2003 23:40:58 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: "Scott G. Kelly" , Karen Seo , ipsec mailingList Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" In-Reply-To: References: <3F97FA6A.7000207@airespace.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 8:57 AM -0700 10/23/03, Scott G. Kelly wrote: > >The name selector is often used for remote access, and maybe for > >other applications. I know of several ipsec implementations which > >use fqdn for remote access policy selection, and without DN, how do > >we apply access controls based on certs? Are they really using it as an IPsec SA selector? I.e not as an IKE SA identity, but as traffic selector field (there is no way to send that in the IKEv2 anymore). The selectors defined in the RFC2401 are for the SPD, and I think that they should be matching something in the packet. The name selector in SPD case was something, where you tied SPD entry to the username of the user who opened the socket. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 23 14:49:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLnSI7081838; Thu, 23 Oct 2003 14:49:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24892 Thu, 23 Oct 2003 16:59:11 -0400 (EDT) Message-ID: <3F984343.1050905@airespace.com> Date: Thu, 23 Oct 2003 14:08:19 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen CC: Paul Hoffman / VPNC , Karen Seo , ipsec mailingList Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" References: <3F97FA6A.7000207@airespace.com> <16280.15578.299171.410377@ryijy.hel.fi.ssh.com> In-Reply-To: <16280.15578.299171.410377@ryijy.hel.fi.ssh.com> X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2003 21:08:24.0556 (UTC) FILETIME=[CBE12AC0:01C399A9] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tero, Tero Kivinen wrote: > Paul Hoffman / VPNC writes: > >>At 8:57 AM -0700 10/23/03, Scott G. Kelly wrote: >> >>>The name selector is often used for remote access, and maybe for >>>other applications. I know of several ipsec implementations which >>>use fqdn for remote access policy selection, and without DN, how do >>>we apply access controls based on certs? > > > Are they really using it as an IPsec SA selector? I.e not as an IKE SA > identity, but as traffic selector field (there is no way to send that > in the IKEv2 anymore). > > The selectors defined in the RFC2401 are for the SPD, and I think that > they should be matching something in the packet. The name selector in > SPD case was something, where you tied SPD entry to the username of > the user who opened the socket. I guess this is somewhat open to interpretation, but I would say the SAD selectors must match the packet, but the SPD selectors must be able to represent policy absent a connection - i.e. they must be able to represent names in cases where numeric identifiers are not known a priori. So, I'm saying that SPD selectors may take on values SAD selectors cannot. I think this reflects the intent of 2401, but Steve Kent can correct me if not. Note that this assumes that the SPD really is THE Security Policy Database - the *definitive* statement of security policy for the ipsec implementation - and that there is no other independent policy db in the implementation which is used by ike. It depends upon how you implement your spd, sad, ike policies, etc, as to where the name selector gets used. I think it is logical and convenient to extract ike policy into a local representation for the ike task, rather than having it always query the ipsec engine for policies, though this is an implementation choice, and not a requirement. I look at it like this: when ike receives a negotiation request from an unknown IP address, the remote client must present an identifier (keyid or name). In a past life, I implemented the SPD such that there were numeric or name IDs possible in selector fields. If the ike ID was a named type, the name was used in the spd lookup, and assuming IKE completed successfully, a SAD entry containing the client's numeric selectors would be created, and this would point back to the associated SPD entry. It's clear to me that not everyone would implement this way; I've seen implementations where separate DBs for IKE are created, but ultimately, the ike task is negotiating on behalf of the rfc2401 implementation, so it seems the rfc2401 policy should reflect the identities somehow. Regardless of how you implement this (names in the SPD, names in ike code), we need names. If we remove them from 2401, we have to put them into ikev2, else we lose the functionality entirely. Scott From owner-ipsec@lists.tislabs.com Fri Oct 24 08:51:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OFp0I7084581; Fri, 24 Oct 2003 08:51:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00266 Fri, 24 Oct 2003 10:58:27 -0400 (EDT) X-Authentication-Warning: netsec05.watson.ibm.com: pau owned process doing -bs Date: Fri, 24 Oct 2003 11:07:44 -0400 (EDT) From: Pau-Chen Cheng To: ipsec@lists.tislabs.com Subject: IKE in JAVA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, does any one know if there is a JAVA implementation of IKE (or IKE v2) ? Thanks in advance. Regards, Pau-Chen From owner-ipsec@lists.tislabs.com Fri Oct 24 09:24:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGOeI7086118; Fri, 24 Oct 2003 09:24:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00574 Fri, 24 Oct 2003 11:42:36 -0400 (EDT) Message-Id: <200310241448.KAA04785@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-06.txt Date: Fri, 24 Oct 2003 10:48:35 -0400 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, W. Dixon Filename : draft-ietf-ipsec-nat-reqts-06.txt Pages : 17 Date : 2003-10-23 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, 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-06.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-06.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-06.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: <2003-10-24103445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103445.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 24 09:24:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGOiI7086129; Fri, 24 Oct 2003 09:24:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00581 Fri, 24 Oct 2003 11:43:14 -0400 (EDT) Message-Id: <200310241449.KAA04891@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-rfc2401bis-00.txt Date: Fri, 24 Oct 2003 10:49:06 -0400 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 : Security Architecture for the Internet Protocol Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2401bis-00.txt Pages : 71 Date : 2003-10-23 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-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-rfc2401bis-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-rfc2401bis-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: <2003-10-24103509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 24 09:24:54 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGOrI7086153; Fri, 24 Oct 2003 09:24:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00565 Fri, 24 Oct 2003 11:42:07 -0400 (EDT) Message-Id: <200310241448.KAA04749@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-dpd-04.txt Date: Fri, 24 Oct 2003 10:48:27 -0400 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 : A Traffic-Based Method of Detecting Dead IKE Peers Author(s) : G. Huang, S. Beaulieu, D. Rochefort Filename : draft-ietf-ipsec-dpd-04.txt Pages : 11 Date : 2003-10-23 This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-04.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-dpd-04.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-dpd-04.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: <2003-10-24103425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dpd-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dpd-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103425.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Sat Oct 25 17:01:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q01lI7020714; Sat, 25 Oct 2003 17:01:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08471 Sat, 25 Oct 2003 18:57:01 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E67378@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'saag@mit.edu'" , "'ipsec@lists.tislabs.com'" , "'ietf-pkix@imc.org'" Subject: BOF: pki4ipsec Date: Sat, 25 Oct 2003 16:06:10 -0700 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 Folks, As IPsec working group is finishing up its chartered work, some of the works-in-progress have been moved to other or new WGs. The effort of profiling the use of PKI for IPsec is one such effort. We will start with a BOF in MN. Details below. Profiling Use of PKI in IPSEC BOF (pki4ipsec) Thursday, November 13 at 0900-1130 ================================== Full charter and mail list info at: http://www.icsalabs.com/pki4ipsec We are looking forward to your participation! Gregory Lebovitz (Co-chair) From owner-ipsec@lists.tislabs.com Sun Oct 26 20:07:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R47QI7055801; Sun, 26 Oct 2003 20:07:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14786 Sun, 26 Oct 2003 22:16:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20031023140814.GB597@kebe.east.sun.com> References: <20031023140814.GB597@kebe.east.sun.com> Date: Sun, 26 Oct 2003 22:23:07 -0500 To: Dan McDonald From: Stephen Kent Subject: Re: 2401bis Issue # 90 -- Remove the selector "data sensitivity level" Cc: Karen Seo , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Yes, I know what the selector is for, but we were not seeing any use and thus we felt it appropriate to ask the question. Note that the DoD-approved IP layer crypto devices do not implement IPsec quite as we defined it and so it does not seem critical that we maintain this for their benefit. However, I think that so long as we make this a feature that MUST be implemented ONLY by IPsec systems that support labelled security features, it will not cause problems for other vendors and so I guess we could leave it in with the same sort of caveats we now have. steve From owner-ipsec@lists.tislabs.com Sun Oct 26 20:08:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R488I7055832; Sun, 26 Oct 2003 20:08:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14787 Sun, 26 Oct 2003 22:16:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.1.0.14.2.20031023170319.079ac2f0@localhost> References: <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.1.0.14.2.20031023170319.079ac2f0@localhost> Date: Sun, 26 Oct 2003 19:39:56 -0500 To: Eric Vyncke From: Stephen Kent Subject: Re: IPv6 RH (was Re: SPD issues) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:09 +0200 10/23/03, Eric Vyncke wrote: >At 16:34 23/10/2003 +0300, Tero Kivinen wrote: >>Markku Savela writes: >>> For me, it is the next hop destination. Note, however that if SG is >>> also a router, there will be two cases for incoming packet with >>> routing header: >>> a) ip dst = routers own address => process routing header, IPSEC will >>> apply to next hop. (which may be the router itself again). >>> b) ip dst != routers own address, routing header is NOT processed, >>> next hop is searched based on the ip dst address. Again, IPSEC apply >>> to next hop. >>> This is as it should be. Do not mess with it! >> >>That interpretation is fine as long as there is nothing that looks >>like firewall there. In the IPsec there are drop rules so it have a >>minimal firewall inside of the IPsec implementation. Using the routing >>header allows users to bypass the restrictions created by the >>adminstrator. > >Tero, > >I tend to agree with your interpretation, the decision should be >based on the final destination and not on the next hop. This is >clear for the bypass/drop 'firewall' SPD entry. > >AFAIK with the existing IPv4 implementations, the source routing >option has been ignored by IPSec (it looked only to the IP >destination address). > >Of course, IPv6 is much more complex; specifically since Mobile IPv6 >is also using RH. And, there you probably want to make your decision >on the next hop... Contracdicting my first paragraph ;-) > >Perhaps, the decision should be made if either the destination IP or >any RH next-hop IP are matching the selector? We did overlook this in 2401, and we ought to be more precise in 2401bis. The IPv6 destination is what I expect folks would use for selector checking, for both outbound and inbound traffic. We might add a flag that explicitly disallows traffic with routing headers, as a local admin control for SPD entries. In the IPv4 case, we could to do the same re the source route option. What do folks think? Steve From owner-ipsec@lists.tislabs.com Sun Oct 26 20:47:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R4lcI7057887; Sun, 26 Oct 2003 20:47:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA15068 Sun, 26 Oct 2003 23:05:08 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <20031023140814.GB597@kebe.east.sun.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 26 Oct 2003 20:15:07 -0800 To: Stephen Kent , Dan McDonald From: Paul Hoffman / VPNC Subject: Re: 2401bis Issue # 90 -- Remove the selector "data sensitivity level" Cc: Karen Seo , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:23 PM -0500 10/26/03, Stephen Kent wrote: >Dan, > >Yes, I know what the selector is for, but we were not seeing any use >and thus we felt it appropriate to ask the question. Note that the >DoD-approved IP layer crypto devices do not implement IPsec quite as >we defined it and so it does not seem critical that we maintain this >for their benefit. > >However, I think that so long as we make this a feature that MUST be >implemented ONLY by IPsec systems that support labelled security >features, it will not cause problems for other vendors and so I >guess we could leave it in with the same sort of caveats we now have. Or we could remember that we are trying to simplify things (strange, I know) and remove it because no one uses it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 27 02:20:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RAKuI7040386; Mon, 27 Oct 2003 02:20:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16854 Mon, 27 Oct 2003 04:28:51 -0500 (EST) From: juha.ollila@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IKEv1: use of CERTREQ Date: Mon, 27 Oct 2003 11:38:09 +0200 Message-ID: Thread-Topic: IKEv1: use of CERTREQ Thread-Index: AcOcbghi8XZKdOO6ThemeMHeqsq3pw== To: X-OriginalArrivalTime: 27 Oct 2003 09:38:10.0329 (UTC) FILETIME=[08BAA090:01C39C6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA16851 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, The usage of CERTREQs is not very well specified. I know that there is a pki-profile draft. Two IKE implementations want to negotiate security associations. Let's assume the following: - There are two security domains - Each domain has own CA - CAs has cross-certified each other - IKE implementations belong different security domains i.e. they have not peer's certificate. What is the *current practice* in this situation? There are at least 4 possibilities, when certificate based authentication is used in IKE: 1) IKE does not send a CERTREQ at all - This contradicts with the pki-profile draft, because in-band exchange of certificates is desired. 2) IKE sends an empty CERTREQ - This contradicts with the pki-profile draft. 3) Several CA names are configured and IKE sends multiple CERTREQs - This has privacy problem, if security domains don't want to reveal their trust relationships. 4) CA name is configured for each ISAKMP policy and IKE send one CERTREQ - Is this supported in the current implementations? BR, Juha Ollila From owner-ipsec@lists.tislabs.com Mon Oct 27 04:30:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RCUYI7047008; Mon, 27 Oct 2003 04:30:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17522 Mon, 27 Oct 2003 06:28:46 -0500 (EST) Message-Id: <200310271138.h9RBc3HN081028@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: IPv6 RH (was Re: SPD issues) In-reply-to: Your message of Sun, 26 Oct 2003 19:39:56 EST. Date: Mon, 27 Oct 2003 12:38:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: >Perhaps, the decision should be made if either the destination IP or >any RH next-hop IP are matching the selector? => it should be the IP address in the destination field of the IP header when the policy is evaluated. We did overlook this in 2401, and we ought to be more precise in 2401bis. The IPv6 destination is what I expect folks would use for selector checking, for both outbound and inbound traffic. => I agree. In fact, this is part of the multi-protocol selector issue (which we decided against) as RHs are extension headers. We might add a flag that explicitly disallows traffic with routing headers, as a local admin control for SPD entries. In the IPv4 case, we could to do the same re the source route option. What do folks think? => I don't believe this is a good idea because it is the first step towards the transformation of SPD entries into firewall rules, i.e., someone can propose this in his implementation but this should not be in the standard. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Oct 27 08:23:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGNwI7059161; Mon, 27 Oct 2003 08:23:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18853 Mon, 27 Oct 2003 10:38:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 27 Oct 2003 10:52:16 -0500 To: ipsec mailingList From: Karen Seo Subject: Re: 2401bis issue 91 -- Handling ICMP error messages Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Did anyone receive the email I sent last night (about 9pm East Coast time) to the list? It was a write up on "Handling ICMP error messages"? Thanks, Karen From owner-ipsec@lists.tislabs.com Mon Oct 27 08:57:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGvdI7061021; Mon, 27 Oct 2003 08:57:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19055 Mon, 27 Oct 2003 11:08:55 -0500 (EST) X-mProtect: <200310271617> Nokia Silicon Valley Messaging Protection Message-ID: <3F9D45BF.8060701@iprg.nokia.com> Date: Mon, 27 Oct 2003 08:20:15 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: IPv6 RH (was Re: SPD issues) References: <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, Stephen Kent wrote: > > We might add a flag that explicitly disallows traffic with routing > headers, as a local admin control for SPD entries. I think this is a bad idea. the local admin should use a firewall to restrict traffic with routing headers if needed. he shouldnt use the SPD to do this. we might accidentaly turn off protocols which make use of routing headers. also routing headers come in different flavors. there is a type 2 routing header whose semantics are differnt. in type 2 routing headers you can only specify one address (segmentsLeft is always 1) and packets with this routing header are never forwarded by a node which processes the routing header. both the destination address and the address inside the routing header should belong to the same node. there is no security concerns with the use of this routing header. Vijay From owner-ipsec@lists.tislabs.com Mon Oct 27 09:15:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHFbI7061774; Mon, 27 Oct 2003 09:15:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19317 Mon, 27 Oct 2003 11:27:13 -0500 (EST) Message-Id: <200310271635.h9RGZaS4008539@thunk.east.sun.com> From: Bill Sommerfeld To: Vijay Devarapalli cc: Stephen Kent , Eric Vyncke , ipsec@lists.tislabs.com Subject: Re: IPv6 RH (was Re: SPD issues) In-Reply-To: Your message of "Mon, 27 Oct 2003 08:20:15 PST." <3F9D45BF.8060701@iprg.nokia.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 27 Oct 2003 11:35:36 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > We might add a flag that explicitly disallows traffic with routing > > headers, as a local admin control for SPD entries. > > I think this is a bad idea. the local admin should use a firewall > to restrict traffic with routing headers if needed. he shouldnt > use the SPD to do this. we might accidentaly turn off protocols > which make use of routing headers. Huh? You might accidentally disable stuff you need at an SPD-based policy enforcment point, or accidentally disable stuff you need with a "firewall". What's the difference? Any code which consults the SPD to do policy enforcement can be thought of as a "firewall". - Bill From owner-ipsec@lists.tislabs.com Mon Oct 27 09:45:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHjvI7063859; Mon, 27 Oct 2003 09:45:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19549 Mon, 27 Oct 2003 11:53:08 -0500 (EST) Date: Mon, 27 Oct 2003 12:02:25 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IPv6 RH (was Re: SPD issues) In-Reply-To: <200310271635.h9RGZaS4008539@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 27 Oct 2003, Bill Sommerfeld wrote: > > I think this is a bad idea. the local admin should use a firewall > > to restrict traffic with routing headers if needed. he shouldnt > > use the SPD to do this... > > Any code which consults the SPD to do policy enforcement can be > thought of as a "firewall". The SPD *is* a firewall. One serious flaw of RFC 2401 was that it did not make this clear. The 2401bis draft does (section 2.1, second paragraph). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Oct 27 13:01:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RL17I7074439; Mon, 27 Oct 2003 13:01:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21188 Mon, 27 Oct 2003 14:59:33 -0500 (EST) Date: Mon, 27 Oct 2003 12:03:50 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org Cc: nfsv4@ietf.org Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt] Message-ID: <20031027200350.GI24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org, nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Followups-To: nfsv4@ietf.org Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Apologies for the cross-post; followups should NOT be cross-posted this widely. Please Cc ONLY the appropriate WG mailing list(s) on any replies. Since I am not subscribed to all of the relevant WGs' mailing lists, please Cc me in all replies.] The NFSv4 WG I-D on channel bindings needs review from several IETF WGs. This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02). We would appreciate feedback from the Cc'ed WGs on several areas as requested below. Please cc the appropriate WG lists only in your replies. The I-D announcement is included below, including the I-D Abstract. Thanks, Nico Review requests: - From all the cc'ed WGs, the security community in general and the [concluded] CAT WG mailing list: o Please review the generic definition of "channel bindings" in this I-D and the concept of "channel bindings" in general. (Use the CAT WG list and/or the NFSv4 WG list.) - From the IPSEC WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. o Please review the IPsec channel bindings construction. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPSP WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPS WG: o Please consider the channel bindings concept as a general solution to the problems with the iSCSI approach to security ("authenticate at iSCSI layer with x, y or z authentication technology, but delegate session integrity/confidentiality protection to IPsec"). See the introduction (section 1) of this I-D for a description of the problem with the iSCSI approach to security. (I realize that I'm late to the iSCSI party - my goal is not to affect the progression of the iSCSI I-Ds to Proposed Standard and publication as RFCs, far from it.) (Use the IPS WG list.) - From the TLS WG: o Please review the construction of channel bindings to TLS channels given in this I-D. (Use the TLS WG list.) - From the SECSH WG: o Please review the construction of channel bindings to SSHv2 channels given in this I-D. (Use the SECSH WG list.) - From the KRB WG: o Please review sections 3.3 and 4.5 of this I-D. (Use the KRB WG list.) - From the SASL WG: o Please review section 3.2 of this I-D. (Use the SASL WG list.) ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 24 Oct 2003 10:50:50 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt To: IETF-Announce: ; Cc: nfsv4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : On the Use of Channel Bindings to Secure Channels Author(s) : N. Williams Filename : draft-ietf-nfsv4-channel-bindings-00.txt Pages : 14 Date : 2003-10-23 This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-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-nfsv4-channel-bindings-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-nfsv4-channel-bindings-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. ----- End forwarded message ----- From owner-ipsec@lists.tislabs.com Mon Oct 27 13:53:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLrTI7076427; Mon, 27 Oct 2003 13:53:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21526 Mon, 27 Oct 2003 16:07:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 27 Oct 2003 16:20:22 -0500 To: ipsec mailingList From: Karen Seo Subject: 3rd try -- 2401bis issue 91 -- handling ICMP error messages Cc: John Kelley , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The first 2 attempts seem to have failed. Trying again to get this message distributed by the list server.... The previous 2 attempts had "bold" characters in it and this one doesn't. Apologies if you've received 3 copies. Folks, Here's a description and proposed approach for handling ICMP error messages. Any mistakes/confusion are mine. Steve has again maintained plausible deniability by having out-of-town engagements much of last week and this that prevented him from reviewing this draft :-). Karen IPsec Issue #: 91 Title: Handling ICMP error messages -- receiving (local and transit) and generating Description: ============ I. Receiving (local and transit) an ICMP error message -- How does an IPsec system know whether an ICMP error message comes from a trusted source or not? And what should it do in each case? Note: IKEv2 supports selectors for ICMP message type and code, which can be used to classify the ICMP messages. 1. If it arrives without AH or ESP protection, what to do is currently a matter of local policy. We will clarify the existing text that addresses this case (see proposed approach below.) 2. If an ICMP message arrives on an SA, then it must be consistent with the selectors for the SA, otherwise it will not be delivered (since it will fail the SA access control checks). In general, this suggests that security gateways should establish a tunnel mode SA between themselves to carry ICMP traffic, something that can be accomplished using the extant SPD parameter for next protocol. One might want to further restrict the types of ICMP messages that are authorized to traverse an SA, using ICMP type and code selectors. However, care still has to be taken when processing ICMP traffic that arrives via an SA, even an ICMP-specific SA. The concern is that an ICMP message includes what purports to be the header of the packet that triggered that ICMP message, but additional checks are needed to verify that the returned header is consistent with the address space associated with the SA via which the ICMP message was received. For example, an SG for Net A might receive an ICMP Destination Unreachable via a tunnel from the SG for Net B, but the triggering packet might refer to an address in Net C! Thus an implementation needs to perform consistency checks on the triggering packets in received ICMP traffic to detect and reject such behavior. However, depending on the complexity of the network topology, such checks may not detect all possible inconsistencies. By using ICMP type and code, receivers can achieve additional control in dealing with ICMP messages received on SAs. II. Generating an ICMP error message -- What should an IPsec system (host or SG) do when it generates an ICMP error message? What to do in each case is currently a matter of local policy and could depend on the type of ICMP error message. When it is necessary to generate an (outbound to the blackside) ICMP error message, it is desirable to transit it via an appropriate SA, for the reasons noted above. NOTE: Generating an ICMP message in response to an ICMP message is prohibited by the ICMP protocol specifications [ICMP -- RFC 792], [ICMPv6 -- RFC 2463]. NOTE: ICMP messages that are not *error* messages SHOULD be handled like any other messages. Proposed approach: ================== A. Update the 2401bis text to say: "An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus there is also a motivation for accepting and acting upon unauthenticated ICMP messages. To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See issue 78 for PMTU minimum size recommendations] "A mechanism SHOULD be provided to allow an administrator to cause ICMP messages (selected, all, none) to be logged as an aid to problem diagnosis." Processing ICMP messages (receiving (local and transit) and generating) Consider a topology along the lines of: Host SG Rtr SG Host X === A ======== B ======== C === Y <------><----------------------><-----> Red Black Red red = traffic within security perimeter, could be protected by an SA or not black = traffic outside security perimeter, could be protected by an SA or not The IPsec implementation at A or C MUST be able to handle the following cases (tunnel indicates IPsec protection): black | red ----------|---------- | | | | local | | | / | | (1) ICMP ---------------------------------> | \ | | | \ ------------------- | \-------tunnel--------> | ------------------- | | | | | | | | local | | | \ <----------------------<---------- (2) ICMP | | / | ________________ / | <-------tunnel-----/ | ---------------- | | | | | | | | | local | ________________ / | (3) ICMP -------tunnel----->--------------> ---------------- \ | | | \ ________ | | \--tunnel--> | | -------- | | | | | | | | <--------- trigger packet | | / | | / | | | ICMP ---------> (4) | | \ | | | \ ________ | | \--tunnel--> (4) | | -------- ____________ | trigger pkt ----tunnel----> | ------------ \ | | | \ | (5) <------------------ ICMP | | | / | ________________ / | (5) <-------tunnel-----/ | ---------------- | | | | | | | trigger pkt -------------> | | | \ | | | \ | (6) <------------------ ICMP | | | / | ________________ / | (6) <-------tunnel-----/ | ---------------- | | | | ----------|--------- | I Receiving an ICMP error message destined for local delivery or transit service (1) An ICMP packet is received without IPsec protection from the black side, i.e., it is unauthenticated and from an untrusted source. In this case, the IPsec system: (a) MUST perform standard IPsec processing on the ICMP packet -- with possible results of DROP, BYPASS, or IPsec required. (b) If the ICMP packet passes (a), then additional ICMP-specific checks SHOULD be performed to: i. verify that the IP addresses in the header of the triggering packet are consistent with the address space associated with the SPD entry that matches the selectors of the ICMP message. If the protocol and ports information is available, these SHOULD also be checked for consistency with the SPD entry. ii. ensure, for ICMP "packet too big" messages, a minimum PMTU for IPv4 and IPv6 traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size. Note: This is done at this step even if the ICMP packet is not destined locally, on the assumption that the destination host may not be running IPsec and hence this IPsec system should do this check. (c) If the ICMP packet passes (b), then i. if the ICMP message is destined locally, it is passed along for ICMP processing. ii. if the ICMP message is transiting this system, standard IPsec processing is done and the message is handled as defined by the SPD -- DROP'd, BYPASS'd or provided with IPsec protection. (2) An ICMP packet is received without IPsec protection from the red side, i.e., is unauthenticated but from a trusted source. In this case, the IPsec system: (a) MUST perform standard IPsec processing on the ICMP packet -- with possible results of DROP, BYPASS, or IPsec required. (b) If the ICMP packet passes (a) and is destined locally, i. SHOULD perform ICMP checks to: - verify that the IP addresses in the header of the triggering packet are consistent with the address space associated with the SPD entry that matches the selectors of the ICMP message. If the protocol and ports information is available, these SHOULD also be checked for consistency with the SPD entry. - ensure, for ICMP "packet too big" messages, a minimum PMTU for IPv4 or IPv6 traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size. Note: This is done at this step even if the ICMP packet is not destined locally, on the assumption that the destination host may not be running IPsec and hence this IPsec system should do this check. ii. If the ICMP packet passes (i), then it is passed along for ICMP processing. (c) If the ICMP packet passes (a) and is transiting this system, then the ICMP checks are left to the destination IPsec system, standard IPsec processing is done and the message is handled as defined by the SPD -- DROP'd, BYPASS'd or provided with IPsec protection. In the last case, there are two options: i. a tunnel set up just for ICMP messages. ii. an SA whose selectors include those of the ICMP message. (3) An ICMP packet is received with IPsec protection from the black side, i.e., is authenticated. Same action as for case (1). II. Generating ICMP packets The following cases assume that the triggering packet has passed standard IPsec checks, i.e., not been DROP'd by policy. (4) An ICMP packet is being generated by the IPsec system in response to a packet which came from the red side, i.e., unauthenticated but from a trusted source. In this case, the IPsec system MUST perform standard IPsec processing on the ICMP error message. Possible actions are DROP, BYPASS or provide with IPsec protection. In the last case there are two options: (a) send the ICMP packet on an SA set up just for ICMP messages. (b) send the ICMP packet on an SA whose selectors include those of the ICMP message. (5) An ICMP packet is being generated by the IPsec system (red side) in response to a packet which came from the black side and was protected by IPsec, i.e., authenticated. Same action as for case (4). (6) An ICMP packet is being generated by the IPsec system (red side) in response to a packet which came from the black side and was unprotected by IPsec, i.e., unauthenticated and from an untrusted source. Same action as for case (4). B. Add to Security Considerations: NOTE: SPD entries for ICMP error messages SHOULD mandate security as strong as or stronger than the security required for traffic that might trigger an ICMP error message. C. Update the selector and SPD sections to reflect IKEv2's support for ICMP message type and code -- Add ICMP message type and code to the list of selectors supported in the SPD and in IKEv2 to enable better IPsec policy definition for the handling of the different kinds of ICMP error messages when generating or receiving (local or transit) ICMP error messages. There should be one selector for the pair , not two selectors. (I got this wrong in the recently distributed 2401bis draft.) Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Oct 27 14:26:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMQeI7078439; Mon, 27 Oct 2003 14:26:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21738 Mon, 27 Oct 2003 16:42:56 -0500 (EST) Message-ID: <3F9D937E.F2D0E00E@precidia.com> Date: Mon, 27 Oct 2003 16:51:58 -0500 From: Sylvano Carrasco Organization: Precidia Technologies "http://www.precidia.com" X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Remove References: <200310241448.KAA04749@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Remove carrasco@precidia.com From owner-ipsec@lists.tislabs.com Mon Oct 27 19:15:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S3FiI7089083; Mon, 27 Oct 2003 19:15:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23610 Mon, 27 Oct 2003 21:28:01 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200310271138.h9RBc3HN081028@givry.rennes.enst-bretagne.fr> References: <200310271138.h9RBc3HN081028@givry.rennes.enst-bretagne.fr> Date: Mon, 27 Oct 2003 11:10:41 -0500 To: Francis Dupont From: Stephen Kent Subject: Re: IPv6 RH (was Re: SPD issues) Cc: Eric Vyncke , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:38 +0100 10/27/03, Francis Dupont wrote: > In your previous mail you wrote: > > >Perhaps, the decision should be made if either the destination IP or > >any RH next-hop IP are matching the selector? > >=> it should be the IP address in the destination field of the IP header >when the policy is evaluated. > > We did overlook this in 2401, and we ought to be more precise in 2401bis. > > The IPv6 destination is what I expect folks would use for selector > checking, for both outbound and inbound traffic. > >=> I agree. In fact, this is part of the multi-protocol selector issue >(which we decided against) as RHs are extension headers. > > We might add a flag that explicitly disallows traffic with routing > headers, as a local admin control for SPD entries. In the IPv4 case, > we could to do the same re the source route option. > > What do folks think? > >=> I don't believe this is a good idea because it is the first step towards >the transformation of SPD entries into firewall rules, i.e., someone can >propose this in his implementation but this should not be in the standard. Francis, SPD entries ARE firewall rules. We are only debating how fancy they need to be. Steve From owner-ipsec@lists.tislabs.com Tue Oct 28 01:58:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S9w9I7071093; Tue, 28 Oct 2003 01:58:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25780 Tue, 28 Oct 2003 04:08:13 -0500 (EST) Message-Id: <5.1.0.14.2.20031028094811.02f47220@localhost> X-Sender: evyncke@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Oct 2003 10:16:32 +0100 To: Stephen Kent From: Eric Vyncke Subject: Re: IPv6 RH (was Re: SPD issues) Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.2.20031023170319.079ac2f0@localhost> <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.2.0.9.0.20031020142118.020310d8@email> <5.2.0.9.0.20031014234014.0214b190@localhost> <5.2.0.9.0.20031021001505.02134aa0@localhost> <3F956643.8030701@isi.edu> <3F956A72.5090603@isi.edu> <16278.16813.152210.575490@ryijy.hel.fi.ssh.com> <200310221213.h9MCDTwu010141@burp.tkv.asdf.org> <5.1.0.14.2.20031023170319.079ac2f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 28 Oct 2003 09:16:42.0558 (UTC) FILETIME=[33921DE0:01C39D34] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:39 26/10/2003 -0500, Stephen Kent wrote: >At 17:09 +0200 10/23/03, Eric Vyncke wrote: > >We did overlook this in 2401, and we ought to be more precise in 2401bis. > >The IPv6 destination is what I expect folks would use for selector checking, for both outbound and inbound traffic. It does make sense to ignore the RH (43 type 1) and only base the SPD on source and destination. >We might add a flag that explicitly disallows traffic with routing headers, as a local admin control for SPD entries. In the IPv4 case, we could to do the same re the source route option. I would leave this as an implementation detail. But, as it has been pointed by someone else, with mobile IPv6 there are two different IPv6 headers: - Destination Option (60) which is used by a mobile node to indicate its 'permanent' (= home) address (as opposed to its care-of-address which is in the source address field of the IPv6 header) - Routing Header (53 type 2) of second kind which is used by packets sent to the mobile node to indicate the 'permanent' address of the mobile node (as opposed to the care-of address which is in the destination address field of the IPv6 header) This is very close to yet another tunnel in disguise. And there are good arguments to apply the SPD on two points: - plain source and destination field of the IPv6 address: e.g., to protect the payload during the transit over the public network at the expense of a new IKE renegotiation during roaming - permanent addresses (i.e. DO for packets sent by the mobile node and RH for packets sent to the mobile node): end to end protection I'm mostly ignorant regarding MIPv6... and it would probably be safer and easier to state in RFC2401bis that the SPD for MIP (v4 and v6) will be defined in the framework of MIP4 and MIP6 WG. This means that the processing of RH type 2 and DO are explicitly not defined in rfc2401bis. Cfr: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-03.html -eric From owner-ipsec@lists.tislabs.com Tue Oct 28 02:18:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SAI1I7071964; Tue, 28 Oct 2003 02:18:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25969 Tue, 28 Oct 2003 04:39:44 -0500 (EST) Message-Id: <200310280948.h9S9muHN085599@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: IP Security List Subject: Re: IPv6 RH (was Re: SPD issues) In-reply-to: Your message of Mon, 27 Oct 2003 12:02:25 EST. Date: Tue, 28 Oct 2003 10:48:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Mon, 27 Oct 2003, Bill Sommerfeld wrote: > > I think this is a bad idea. the local admin should use a firewall > > to restrict traffic with routing headers if needed. he shouldnt > > use the SPD to do this... > > Any code which consults the SPD to do policy enforcement can be > thought of as a "firewall". The SPD *is* a firewall. One serious flaw of RFC 2401 was that it did not make this clear. The 2401bis draft does (section 2.1, second paragraph). => we should make a distinction between a filtering mechanism and what is sold as a firewall: Vijay and me share the opinion that the SPD belongs to the first category and the RH stuff should be done by a device from the second one. Of course, on a SG which is also a firewall, the SPD can be extended in order to include plain firewall capabilities (this is better than to fight against the firewall part :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Oct 28 03:41:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SBf4I7075322; Tue, 28 Oct 2003 03:41:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26516 Tue, 28 Oct 2003 06:00:49 -0500 (EST) Message-Id: <200310281110.h9SBA8HN087057@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Eric Vyncke cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPv6 RH (was Re: SPD issues) In-reply-to: Your message of Tue, 28 Oct 2003 10:16:32 +0100. <5.1.0.14.2.20031028094811.02f47220@localhost> Date: Tue, 28 Oct 2003 12:10:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: This is very close to yet another tunnel in disguise. => yes, draft-deering-ipv6-encap-addr-deletion-00.txt develops this argument. But can we conclude that mobile IPv6 should be considered as tunneled traffic, i.e., an IPsec node which is not one of the end-points of the tunnel should only look at the external IP header? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Oct 28 06:14:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEEkI7082880; Tue, 28 Oct 2003 06:14:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27483 Tue, 28 Oct 2003 08:29:38 -0500 (EST) Message-ID: <3F9E06B1.431F8A7F@briank.com> Date: Mon, 27 Oct 2003 22:03:29 -0800 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: juha.ollila@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: IKEv1: use of CERTREQ References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk juha.ollila@nokia.com wrote: > > Hello all, > > The usage of CERTREQs is not very well specified. I know that there > is a pki-profile draft. > > Two IKE implementations want to negotiate security associations. > Let's assume the following: > - There are two security domains > - Each domain has own CA > - CAs has cross-certified each other > - IKE implementations belong different security domains i.e. > they have not peer's certificate. > > What is the *current practice* in this situation? > > There are at least 4 possibilities, when certificate based > authentication is used in IKE: > > 1) IKE does not send a CERTREQ at all > - This contradicts with the pki-profile draft, because in-band > exchange of certificates is desired. > > 2) IKE sends an empty CERTREQ > - This contradicts with the pki-profile draft. > > 3) Several CA names are configured and IKE sends multiple CERTREQs > - This has privacy problem, if security domains don't want to > reveal their trust relationships. > > 4) CA name is configured for each ISAKMP policy and IKE send one > CERTREQ > - Is this supported in the current implementations? > > BR, > Juha Ollila Agreed on 1 & 2. I don't really understand 3, as the devices are in different security domains and thus will only be configured to trust their (presumably one) local CA. So, #4 sounds right, and I can even tell you that at least one of Nokia's implementations works that way. -brian briank@briank.com From owner-ipsec@lists.tislabs.com Tue Oct 28 06:55:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEtNI7085684; Tue, 28 Oct 2003 06:55:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27800 Tue, 28 Oct 2003 09:13:36 -0500 (EST) Message-Id: <200310281414.JAA21412@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-camellia-01.txt Date: Tue, 28 Oct 2003 09:14:50 -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 Camellia Cipher Algorithm and Its Use With IPsec Author(s) : S. Moriai Filename : draft-ietf-ipsec-ciph-camellia-01.txt Pages : 7 Date : 2003-10-27 This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-camellia-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-camellia-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-camellia-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: <2003-10-28093346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-camellia-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-camellia-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28093346.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 28 09:24:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHONI7095256; Tue, 28 Oct 2003 09:24:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28653 Tue, 28 Oct 2003 11:26:25 -0500 (EST) Message-Id: <200310281635.h9SGZXS4000236@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: Henry Spencer , IP Security List Subject: Re: IPv6 RH (was Re: SPD issues) In-Reply-To: Your message of "Tue, 28 Oct 2003 10:48:56 +0100." <200310280948.h9S9muHN085599@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@east.sun.com Date: Tue, 28 Oct 2003 11:35:33 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > => we should make a distinction between a filtering mechanism and what is > sold as a firewall Any attempt to draw a clear distinction between "packet filtering" and "firewall" will be doomed to failure. In this case, if you can subvert the intent of IPsec by adding routing headers to packets, then we should consider independantly whether it makes sense to add the ability to filter them to the SPD, not on whether this is "packet filtering" or "firewalling".. - Bill From owner-ipsec@lists.tislabs.com Tue Oct 28 09:58:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHvxI7097149; Tue, 28 Oct 2003 09:57:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28796 Tue, 28 Oct 2003 11:52:15 -0500 (EST) From: "Mike Taylor" To: "Karen Seo" , "ipsec mailingList" Cc: "John Kelley" , , , "Angelos D. Keromytis" , Subject: RE: 3rd try -- 2401bis issue 91 -- handling ICMP error messages Date: Tue, 28 Oct 2003 09:00:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Karen Seo > Sent: Monday, October 27, 2003 1:20 PM > To: ipsec mailingList > Cc: John Kelley; byfraser@cisco.com; tytso@mit.edu; Angelos D. > Keromytis; kivinen@ssh.fi; kseo@bbn.com > Subject: 3rd try -- 2401bis issue 91 -- handling ICMP error messages > > > The first 2 attempts seem to have failed. Trying again to get this > message distributed by the list server.... The previous 2 attempts > had "bold" characters in it and this one doesn't. Apologies if > you've received 3 copies. > > Folks, > > Here's a description and proposed approach for handling ICMP error > messages. Any mistakes/confusion are mine. Steve has again > maintained plausible deniability by having out-of-town engagements > much of last week and this that prevented him from reviewing this > draft :-). > > Karen > > > IPsec Issue #: 91 > > Title: Handling ICMP error messages -- receiving (local and > transit) and generating > > Description: > ============ > I. Receiving (local and transit) an ICMP error message -- How does > an IPsec system know whether an ICMP error message comes from a > trusted source or not? And what should it do in each case? Note: > IKEv2 supports selectors for ICMP message type and code, which can > be used to classify the ICMP messages. > > 1. If it arrives without AH or ESP protection, what to do is > currently a matter of local policy. > > We will clarify the existing text that addresses this case (see > proposed approach below.) > > 2. If an ICMP message arrives on an SA, then it must be consistent > with the selectors for the SA, otherwise it will not be delivered > (since it will fail the SA access control checks). In general, > this suggests that security gateways should establish a tunnel > mode SA between themselves to carry ICMP traffic, something that > can be accomplished using the extant SPD parameter for next > protocol. One might want to further restrict the types of ICMP > messages that are authorized to traverse an SA, using ICMP type > and code selectors. However, care still has to be taken when > processing ICMP traffic that arrives via an SA, even an > ICMP-specific SA. The concern is that an ICMP message includes > what purports to be the header of the packet that triggered that > ICMP message, but additional checks are needed to verify that the > returned header is consistent with the address space associated > with the SA via which the ICMP message was received. For example, > an SG for Net A might receive an ICMP Destination Unreachable via > a tunnel from the SG for Net B, but the triggering packet might > refer to an address in Net C! Thus an implementation needs to > perform consistency checks on the triggering packets in received > ICMP traffic to detect and reject such behavior. However, > depending on the complexity of the network topology, such checks > may not detect all possible inconsistencies. > > By using ICMP type and code, receivers can achieve additional > control in dealing with ICMP messages received on SAs. > > II. Generating an ICMP error message -- What should an IPsec > system (host or SG) do when it generates an ICMP error message? > What to do in each case is currently a matter of local policy and > could depend on the type of ICMP error message. > > When it is necessary to generate an (outbound to the blackside) > ICMP error message, it is desirable to transit it via an > appropriate SA, for the reasons noted above. > > NOTE: Generating an ICMP message in response to an ICMP message is > prohibited by the ICMP protocol specifications [ICMP -- RFC 792], > [ICMPv6 -- RFC 2463]. > > NOTE: ICMP messages that are not *error* messages SHOULD be > handled like any other messages. It seems to me that in general the description of handling ICMP messages must be divorced from the presumption of any a-priori knowledge on the part of the IPsec implementation as to which networks are red and which are black, or which hosts are trusted and which aren't. Although I haven't completed this part of my IPsec implementation yet, it looking forward it seems to me that one of the fundamental keys to deciding how to handle ICMP messages should be based on the following four possibilities: 1. The ICMP message itself is protected by AH/ESP, i.e., is received within an IP datagram where the outermost IP header has ESP or AH as the protocol, but the IP datagram encapsulated by the ICMP message is not protected by AH/ESP. 2. The ICMP message itself is not protected by AH/ESP, i.e., the IP header contains protocol IP_ICMP, but the IP datagram encapsulated by the ICMP error message is of type AH or ESP. 3. The ICMP message itself and the IP datagram that it encapsulates are both protected by AH and/or ESP. 4. Neither the ICMP error message itself, nor the IP datagram that it encapsulates, are protected by AH/ESP. To some extent we can infer from these four possibilites the "redness" and "blackness" involved. For example, in case 2 it seems likely that the ICMP message is being returned by a router on a black network, whereas in case 4 it seems likely that the ICMP message is being returned from a router or host on a black network. Perhaps a description of how to handle the messages in each of these cases would be the best tact. One objective would be be to avoid a presumption of some a priori knowledge by the IPsec implementation of which nets/hosts are trusted/red and and which are not trusted/black. > > Proposed approach: > ================== > A. Update the 2401bis text to say: > > "An ICMP message not protected by AH or ESP is unauthenticated and > its processing and/or forwarding may result in denial or > degradation of service. This suggests that, in general, it would > be desirable to ignore such messages. The above statement seems fundamentally incorrect to me. In the simplest case of an IPsec VPN created by two SGs as in HostA ------- SGA -------------------- SGB -------- HostB it is *anything* but generally desirable to ignore unauthenticated ICMP error messages. In fact, it would seem to me to be generally desirable for *all* ICMP error messages sent from HostA to HostB and vice-versa to be transported across the tunnel between SGA and SGB, and all such messages will arrive at SGA/B unauthenticated in the case where the hosts themselves are not running IPsec. In fact, given a more complex topopoly like HostA ------- SGA ------------------ SGB -------- RouterB--------HostB it would seem to be also to be generally desirable for *all* ICMP error messages sent from RouterB in response to IP datagrams sent from HostA to HostB to reach HostA. Now whether IPsec can be used to achieve these aims without undue security risks is another matter. But to say that tossing all unauthenticated ICMP messages would be how we'd like it to work in an ideal world seems patently false. The text further below attempts to deal with the case of unauthenticated ICMP error messages received from trusted (red) hosts and routers so why leave the above language in 2401bis? It was one of the pieces of text which most confused my when I first read 2401. > However, many ICMP messages > will be received by hosts or security gateways from > unauthenticated sources, e.g., routers in the public Internet. > Ignoring these ICMP messages can degrade service, e.g., because of > a failure to process PMTU message and redirection messages. Thus > there is also a motivation for accepting and acting upon > unauthenticated ICMP messages. To accommodate both ends of this > spectrum, a compliant IPsec implementation MUST permit a local > administrator to configure an IPsec implementation to accept or > reject unauthenticated ICMP traffic. This control MUST be at the > granularity of ICMP type and MAY be at the granularity of ICMP > type and code. Additionally, an implementation SHOULD incorporate > mechanisms and parameters for dealing with such traffic. For > example, there could be the ability to establish a minimum PMTU > for traffic (perhaps on a per destination basis), to prevent > receipt of an unauthenticated ICMP from setting the PMTU to a > trivial size." [See issue 78 for PMTU minimum size > recommendations] > > "A mechanism SHOULD be provided to allow an administrator to cause > ICMP messages (selected, all, none) to be logged as an aid to > problem diagnosis." > > Processing ICMP messages (receiving (local and transit) and > generating) > > Consider a topology along the lines of: > > > Host SG Rtr SG Host > X === A ======== B ======== C === Y > > <------><----------------------><-----> > Red Black Red > > red = traffic within security perimeter, could be protected by an > SA or not > black = traffic outside security perimeter, could be protected by > an SA or not > > > The IPsec implementation at A or C MUST be able to handle the > following cases (tunnel indicates IPsec protection): > > > black | red > ----------|---------- > | | | > | local | | > | / | | > (1) ICMP ---------------------------------> > | \ | | > | \ ------------------- > | \-------tunnel--------> > | ------------------- > | | | > | | | > | | local | > | | \ > <----------------------<---------- (2) ICMP > | | / | > ________________ / | > <-------tunnel-----/ | > ---------------- | > | | | > | | | > | | local | > ________________ / | > (3) ICMP -------tunnel----->--------------> > ---------------- \ | > | | \ ________ > | | \--tunnel--> > | | -------- > | | | > | | | > | | <--------- trigger packet > | | / > | | / | > | | ICMP ---------> (4) > | | \ | > | | \ ________ > | | \--tunnel--> (4) > | | -------- > ____________ | > trigger pkt ----tunnel----> | > ------------ \ | > | | \ | > (5) <------------------ ICMP | > | | / | > ________________ / | > (5) <-------tunnel-----/ | > ---------------- | > | | | > | | | > trigger pkt -------------> | > | | \ | > | | \ | > (6) <------------------ ICMP | > | | / | > ________________ / | > (6) <-------tunnel-----/ | > ---------------- | > | | | > ----------|--------- > | > > I Receiving an ICMP error message destined for local delivery or > transit service > > (1) An ICMP packet is received without IPsec protection from the > black side, i.e., it is unauthenticated and from an untrusted > source. In this case, the IPsec system: > > (a) MUST perform standard IPsec processing on the ICMP packet -- > with possible results of DROP, BYPASS, or IPsec required. > > (b) If the ICMP packet passes (a), then additional ICMP-specific > checks SHOULD be performed to: > > i. verify that the IP addresses in the header of the triggering > packet are consistent with the address space associated with > the SPD entry that matches the selectors of the ICMP message. > If the protocol and ports information is available, these > SHOULD also be checked for consistency with the SPD entry. > > ii. ensure, for ICMP "packet too big" messages, a minimum PMTU > for IPv4 and IPv6 traffic (perhaps on a per destination > basis), to prevent receipt of an unauthenticated ICMP from > setting the PMTU to a trivial size. Note: This is done at > this step even if the ICMP packet is not destined locally, on > the assumption that the destination host may not be running > IPsec and hence this IPsec system should do this check. > > (c) If the ICMP packet passes (b), then > > i. if the ICMP message is destined locally, it is passed along > for ICMP processing. > > ii. if the ICMP message is transiting this system, standard > IPsec processing is done and the message is handled as > defined by the SPD -- DROP'd, BYPASS'd or provided with > IPsec protection. > > > (2) An ICMP packet is received without IPsec protection from the > red side, i.e., is unauthenticated but from a trusted source. In > this case, the IPsec system: > > (a) MUST perform standard IPsec processing on the ICMP packet -- with > possible results of DROP, BYPASS, or IPsec required. > > (b) If the ICMP packet passes (a) and is destined locally, > > i. SHOULD perform ICMP checks to: > > - verify that the IP addresses in the header of the triggering > packet are consistent with the address space associated with > the SPD entry that matches the selectors of the > ICMP message. > If the protocol and ports information is available, these > SHOULD also be checked for consistency with the SPD entry. > > - ensure, for ICMP "packet too big" messages, a minimum PMTU > for IPv4 or IPv6 traffic (perhaps on a per destination > basis), to prevent receipt of an unauthenticated ICMP from > setting the PMTU to a trivial size. Note: This is done at > this step even if the ICMP packet is not destined locally, > on the assumption that the destination host may not be > running IPsec and hence this IPsec system should do this > check. > > ii. If the ICMP packet passes (i), then it is passed along for > ICMP processing. > > (c) If the ICMP packet passes (a) and is transiting this system, > then the ICMP checks are left to the destination IPsec system, > standard IPsec processing is done and the message is handled > as defined by the SPD -- DROP'd, BYPASS'd or provided with IPsec > protection. In the last case, there are two options: > > i. a tunnel set up just for ICMP messages. > ii. an SA whose selectors include those of the ICMP message. > > > (3) An ICMP packet is received with IPsec protection from the > black side, i.e., is authenticated. Same action as for case (1). > > II. Generating ICMP packets > > The following cases assume that the triggering packet has passed > standard IPsec checks, i.e., not been DROP'd by policy. > > (4) An ICMP packet is being generated by the IPsec system in > response to a packet which came from the red side, i.e., > unauthenticated but from a trusted source. In this case, the > IPsec system MUST perform standard IPsec processing on the ICMP > error message. Possible actions are DROP, BYPASS or provide with > IPsec protection. In the last case there are two options: > > (a) send the ICMP packet on an SA set up just for ICMP messages. > (b) send the ICMP packet on an SA whose selectors include those of > the ICMP message. > > (5) An ICMP packet is being generated by the IPsec system (red > side) in response to a packet which came from the black side and > was protected by IPsec, i.e., authenticated. Same action as for > case (4). > > (6) An ICMP packet is being generated by the IPsec system (red > side) in response to a packet which came from the black side and > was unprotected by IPsec, i.e., unauthenticated and from an > untrusted source. Same action as for case (4). > > > B. Add to Security Considerations: > > NOTE: SPD entries for ICMP error messages SHOULD mandate security > as strong as or stronger than the security required for traffic > that might trigger an ICMP error message. > > > C. Update the selector and SPD sections to reflect IKEv2's support > for ICMP message type and code -- Add ICMP message type and code > to the list of selectors supported in the SPD and in IKEv2 to > enable better IPsec policy definition for the handling of the > different kinds of ICMP error messages when generating or > receiving (local or transit) ICMP error messages. There should be > one selector for the pair , not two selectors. (I got > this wrong in the recently distributed 2401bis draft.) > > Thank you, > Karen From nsx538cphp@msn.com Tue Oct 28 14:00:12 2003 Received: from syr-24-59-244-82.twcny.rr.com (syr-24-59-244-82.twcny.rr.com [24.59.244.82]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SM08I7007238; Tue, 28 Oct 2003 14:00:09 -0800 (PST) (envelope-from nsx538cphp@msn.com) Received: from [53.95.82.183] by syr-24-59-244-82.twcny.rr.com; Wed, 29 Oct 2003 07:58:24 -0500 Message-ID: <9a$b-h-p4q1v3-88$pq-qz@x0m.8.0.whj8fk> From: "Pasquale Odell" Reply-To: "Pasquale Odell" To: , , , , , , , Subject: Ietf-calendar DIET PILLS ON SALE thvv khwpoivsr Date: Wed, 29 Oct 03 07:58:24 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_84E8F.3A9EE2_37__C" X-Priority: 3 X-MSMail-Priority: Normal --_84E8F.3A9EE2_37__C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
YERBA DIET PILLS.
Developed buy leading Doctors!
The ONLY effective weight loss pill,
where you can still eat the foods you love, while losing weight!

On special today,

look here for info!

Take me off list

Ietf-calendar wrote:

>give me info on dieting

tl adkczsbbpszpvtgjnt gs eolgwjex voiet rwps nx lcc h --_84E8F.3A9EE2_37__C-- From ly522qe@bigfoot.com Tue Oct 28 14:01:29 2003 Received: from warp142163088189.newtel.com (warp142163088189.newtel.com [142.163.88.189]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SM1EI7007586; Tue, 28 Oct 2003 14:01:16 -0800 (PST) (envelope-from ly522qe@bigfoot.com) Received: from [136.81.129.175] by warp142163088189.newtel.com with ESMTP id 6BF62F7DC8C; Wed, 29 Oct 2003 07:58:37 -0500 Message-ID: From: "Lanny Dove" Reply-To: "Lanny Dove" To: , , , , Subject: Ietf-ipsec DIET PILLS ON SALE dnszc Date: Wed, 29 Oct 03 07:58:37 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CD2.E7E1_FFA62___5" X-Priority: 3 X-MSMail-Priority: Normal --CD2.E7E1_FFA62___5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
YERBA DIET PILLS.
Developed buy leading Doctors!
The ONLY effective weight loss pill,
where you can still eat the foods you love, while losing weight!

On special today,

look here for info!

Take me off list

Ietf-ipsec wrote:

>give me info on dieting

bxharpxlm zq y hdluptuvi fdgbtuirl --CD2.E7E1_FFA62___5-- From owner-ipsec@lists.tislabs.com Wed Oct 29 00:03:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T83pI7074510; Wed, 29 Oct 2003 00:03:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03301 Wed, 29 Oct 2003 02:14:29 -0500 (EST) From: juha.ollila@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IKEv1: use of CERTREQ Date: Wed, 29 Oct 2003 09:23:46 +0200 Message-ID: Thread-Topic: IKEv1: use of CERTREQ Thread-Index: AcOdGT1VxDUbPEMKTpeeXlMI6mdtqAA06D0g To: Cc: X-OriginalArrivalTime: 29 Oct 2003 07:23:47.0440 (UTC) FILETIME=[97B2E700:01C39DED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id CAA03298 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that I misunderstood number 3). I was thinking that a device must announce trusted cross-certified CAs. It seems that it is enough that it announces only the trusted root CA. > -----Original Message----- > From: ext Brian Korver [mailto:briank@briank.com] > Sent: 28 October, 2003 08:03 > To: Ollila Juha (NET/Oulu) > Cc: ipsec@lists.tislabs.com > Subject: Re: IKEv1: use of CERTREQ > > > juha.ollila@nokia.com wrote: > > > > Hello all, > > > > The usage of CERTREQs is not very well specified. I know that there > > is a pki-profile draft. > > > > Two IKE implementations want to negotiate security associations. > > Let's assume the following: > > - There are two security domains > > - Each domain has own CA > > - CAs has cross-certified each other > > - IKE implementations belong different security domains i.e. > > they have not peer's certificate. > > > > What is the *current practice* in this situation? > > > > There are at least 4 possibilities, when certificate based > > authentication is used in IKE: > > > > 1) IKE does not send a CERTREQ at all > > - This contradicts with the pki-profile draft, because in-band > > exchange of certificates is desired. > > > > 2) IKE sends an empty CERTREQ > > - This contradicts with the pki-profile draft. > > > > 3) Several CA names are configured and IKE sends multiple CERTREQs > > - This has privacy problem, if security domains don't want to > > reveal their trust relationships. > > > > 4) CA name is configured for each ISAKMP policy and IKE send one > > CERTREQ > > - Is this supported in the current implementations? > > > > BR, > > Juha Ollila > > Agreed on 1 & 2. I don't really understand 3, as the devices > are in different security domains and thus will only be configured > to trust their (presumably one) local CA. So, #4 sounds right, and > I can even tell you that at least one of Nokia's implementations > works that way. > > -brian > briank@briank.com > From owner-ipsec@lists.tislabs.com Wed Oct 29 12:28:11 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKSAkT042398; Wed, 29 Oct 2003 12:28:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07044 Wed, 29 Oct 2003 14:27:14 -0500 (EST) From: latten@austin.ibm.com Date: Wed, 29 Oct 2003 13:53:44 -0600 Message-Id: <200310291953.h9TJriia017231@faith.austin.ibm.com> To: ipsec@lists.tislabs.com Subject: question about draft-ietf-ipsec-nat-t-ike-07 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In draft-ietf-ipsec-nat-t-ike-07.txt, section 3.1, there is mention of vendor ID payload to be passed in Phase 1, but it is not defined in the draft nor in rfc 2409. I found mention of it in the draft for ikev2, and just want to be sure that the VID payload mentioned in this ikev2 draft is the same one to be passed in Phase 1 for ikev1 for NAT-T. A while back someone asked about the IPR claim for draft-ietf-ipsec-nat-t-ike and draft-ietf-ipsec-udp-encaps, because they were interested in implementing. I was wondering if there was any new info on this claim or exactly what pieces of the technology are being claimed. See http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt Regards, Joy From owner-ipsec@lists.tislabs.com Thu Oct 30 01:45:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U9jfkT048480; Thu, 30 Oct 2003 01:45:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11178 Thu, 30 Oct 2003 03:47:40 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> Date: Thu, 30 Oct 2003 10:55:34 +0200 From: Tero Kivinen To: latten@austin.ibm.com Cc: ipsec@lists.tislabs.com Subject: question about draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: <200310291953.h9TJriia017231@faith.austin.ibm.com> References: <200310291953.h9TJriia017231@faith.austin.ibm.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk latten@austin.ibm.com writes: > In draft-ietf-ipsec-nat-t-ike-07.txt, section 3.1, there is mention > of vendor ID payload to be passed in Phase 1, but it is not defined > in the draft nor in rfc 2409. The actual vendor ID value will be added when the final RFC number of the document will be known, i.e it will be the MD5 hash of the text "RFC XXXX", where the XXXX is the actual RFC number of the draft-ietf-ipsec-nat-t-ike-07.txt document. > I found mention of it in the draft for ikev2, and just want to be > sure that the VID payload mentioned in this ikev2 draft is the same > one to be passed in Phase 1 for ikev1 for NAT-T. IKEv2 protocol does NOT have vendor ID for the NAT-T. The vendor ID is needed in the IKEv1 to see if the other end supports NAT detection payloads. In the IKEv2 this is not needed, as the NAT detection payloads are notifications, and all IKEv2 implementations MUST ignore unknown status notifications. > A while back someone asked about the IPR claim for draft-ietf-ipsec-nat-t-ike > and draft-ietf-ipsec-udp-encaps, because they were interested in > implementing. I was wondering if there was any new info on this claim > or exactly what pieces of the technology are being claimed. > See http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt I haven't received any more information about that even when I tried to ask from Microsoft. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 30 09:05:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UH5qkT073259; Thu, 30 Oct 2003 09:05:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18877 Thu, 30 Oct 2003 11:13:30 -0500 (EST) From: "Mike Taylor" To: Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt Date: Thu, 30 Oct 2003 08:23:00 -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.2910.0) In-Reply-To: <200310241449.KAA04891@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, Some comments about the 2401bis draft. Section 4.4.1 The Security Policy Database "...In order to support this, the SPD requires distinct entries for inbound and outbound traffic." and a few paragraphs later "- each SPD entry is a list of 1 or more selector set pairs - each selector set pair consists of one selector set for the SA from the initiator to the receiver and one selector set for the SA from the receiver to the initiator." I don't understand (maybe because I don't yet understand IKE very well) this second paragraph, especially given the prior sentence which indicates that the SPD entries for inbound and outbound are separate, as they were in 2401. The second paragraph seems to suggest that an SPD entry is bidirectional. What am I missing? Section 4.4.2 Selectors Still requires that both SPD entries and SAs carry selectors, and still requires separate SAD entries for ESP and AH, so that if I have a incoming datagram which must be processed through both AH and ESP then I can't really make any use of the selectors in the AH SA because until the datagram has also gone through ESP the selectors are opaque. From a practical implementation standpoint I certainly don't want to waste memory (in my embedded system) on information I can't use. And of course the RFC mandates that that after processing through the SAs the selectors in the datagram must be matched against the SPD entry: 5. IP Traffic Processing As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Why, if I really have the selectors stored in SAs, would I do this on the inbound side in particular? Not to mention the wasted CPU cycles matching the packet against selectors in the SA and then doing it again for an SPD entry. On the outbound side I have to match against the SPD 1st and then I guess I could conceivably have multiple SA bundles that have different selectors that could match the same policy based on the following from 4.4: "For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the...." So I could look through that list to find the right one to use. But that would suggest some sort of best-fit matching which isn't mentioned anyplace, or, I could use the 1st matching SA bundle that I find, BUT, this would seem to require that the SAD also support total ordering of entries and only the SPD is required to support total ordering that way. In summary, should any of these requirements, in particular the need to allow specification of how selectors for SAs get inherited from SPD entries, really be requirements? Should it even really be a requirement to have separate SAD and SPD entries? Couldn't adequate security and interoperability be achieved without this requirement? I guess I'm just begging for simplification. Let's focus on getting the true requirements for good security and interoperability spelled out very clearly, and not keep all these implementation details from 2401 in 2401bis. For small embedded systems its essential to clearly spell out the the requirements rather than implementation details as there is always a desire to conserve memory and CPU resources in such systems and yet be able to comply with the functionality that is truly required. Please don't assume that everyone who implements code per RFCs is only interested in multi-user systems and high-end workstations. - Mike Taylor From owner-ipsec@lists.tislabs.com Thu Oct 30 10:52:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIqJkT080287; Thu, 30 Oct 2003 10:52:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21916 Thu, 30 Oct 2003 13:07:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--964732244; protocol="application/pkcs7-signature" Message-Id: From: Joshua Graessley Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 Date: Thu, 30 Oct 2003 09:59:40 -0800 To: ipsec@lists.tislabs.com X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --Apple-Mail-5--964732244 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Oct 30, 2003, at 12:55 AM, Tero Kivinen wrote: > latten@austin.ibm.com writes: >> In draft-ietf-ipsec-nat-t-ike-07.txt, section 3.1, there is mention >> of vendor ID payload to be passed in Phase 1, but it is not defined >> in the draft nor in rfc 2409. > > The actual vendor ID value will be added when the final RFC number > of the document will be known, i.e it will be the MD5 hash of the text > "RFC XXXX", where the XXXX is the actual RFC number of the > draft-ietf-ipsec-nat-t-ike-07.txt document. In other words, until this is published as an RFC there can be no interoperable implementations. This wouldn't be a problem if it didn't take so long for something to go from a draft to an RFC. As it is, a number of vendors have implemented something (they had to ship eventually) based on these drafts and used different vendor id codes. The result is implementations that would probably interoperate just fine if only they used the same vendor id codes. -josh --Apple-Mail-5--964732244 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAzMDE3NTk0MVowIwYJKoZIhvcNAQkEMRYEFPUt evChYN7y2Bl/fS51YhfyDrbtMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAEFS K/06tPZWoGxBychUZi8Aq3+m88TVXDfPLORNxHtBMfKuErropFZX1x94sfHsavghj7vPm7t6uDpe YcPBsqJjmdGZuu01s4ov1gD6XLJrUBoi3AbuA4FpsDmWg+KEh94Z/My8Zd5XsjYsmhu9Weoax3g4 +y7fdCNiqxnxgNSNQPxELkfV0TalJa1oLJdSZfVEFzWlKgeTKXVwzA2XnoqhGCa42l7KrBs1gQAq VMxsrsS6QxgaHQ9g4i9lqwUHleWVp2iE/f2Y72nGSn1lSnt6KuiP0TQH77b2MCBy0muYcmOaref5 gCw69Dg14eEc7fmuDRyATB7pP9W0rqdPRoAAAAAAAAA= --Apple-Mail-5--964732244-- From owner-ipsec@lists.tislabs.com Thu Oct 30 16:38:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V0c1kT094059; Thu, 30 Oct 2003 16:38:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01428 Thu, 30 Oct 2003 18:47:42 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16289.42217.487463.200807@ryijy.hel.fi.ssh.com> Date: Fri, 31 Oct 2003 01:55:21 +0200 From: Tero Kivinen To: Joshua Graessley Cc: ipsec@lists.tislabs.com Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joshua Graessley writes: > In other words, until this is published as an RFC there can be no > interoperable implementations. This wouldn't be a problem if it didn't Yep. > take so long for something to go from a draft to an RFC. As it is, a > number of vendors have implemented something (they had to ship > eventually) based on these drafts and used different vendor id codes. Most of the vendors who have shipped NAT-T have been using the vendor ID's from the previous draft WITH the numbers from the previous draft. Those drafts used numbers from the private use space, thus along with the vendor IDs in the drafts they can interoperate. There have been couple of different vendor ID codes and different numbers and little bit different protocol for each of them. Draft-ietf-ipsec-nat-t-ike-04 tells also those previous vendor IDs and numbers, but that was removed after that, as the protocol was actually changed a bit thus implementations need more changes than simply change of numbers and vendor IDs. > The result is implementations that would probably interoperate just > fine if only they used the same vendor id codes. The reason there is no vendor ID code is to make sure that nobody will implement the protocol using the IANA allocated numbers (or what is the proposal for the IANA to allocate those numbers, as those numbers are not yet allocated, in theory they could still change), i.e the numbers not from the private use space. The drafts are now on the IETF Last Call, so hopefully they will go forward to RFC soon. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Oct 30 17:15:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V1FWkT095440; Thu, 30 Oct 2003 17:15:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03343 Thu, 30 Oct 2003 19:35:55 -0500 (EST) Message-ID: <3FA1B09E.F4CB6E86@cisco.com> Date: Thu, 30 Oct 2003 16:45:18 -0800 From: Tom Hu X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: latten@austin.ibm.com, ipsec@lists.tislabs.com Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > latten@austin.ibm.com writes: > > In draft-ietf-ipsec-nat-t-ike-07.txt, section 3.1, there is mention > > of vendor ID payload to be passed in Phase 1, but it is not defined > > in the draft nor in rfc 2409. > > The actual vendor ID value will be added when the final RFC number > of the document will be known, i.e it will be the MD5 hash of the text > "RFC XXXX", where the XXXX is the actual RFC number of the > draft-ietf-ipsec-nat-t-ike-07.txt document. > > > I found mention of it in the draft for ikev2, and just want to be > > sure that the VID payload mentioned in this ikev2 draft is the same > > one to be passed in Phase 1 for ikev1 for NAT-T. > > IKEv2 protocol does NOT have vendor ID for the NAT-T. The vendor ID is > needed in the IKEv1 to see if the other end supports NAT detection > payloads. In the IKEv2 this is not needed, as the NAT detection > payloads are notifications, and all IKEv2 implementations MUST ignore > unknown status notifications. > Question about NAT-T with v2. I read v2 RFC, my impression it does not allow to send or process notification message until the peer is authenticated. It also means that we only can send or process Notify message after 4th messages. It seems we should send NAT-D in msg #1 and #2, is it against ikev2 protocol? Or we have some selection of Notification message can allow before 4th message? Tom > > > A while back someone asked about the IPR claim for draft-ietf-ipsec-nat-t-ike > > and draft-ietf-ipsec-udp-encaps, because they were interested in > > implementing. I was wondering if there was any new info on this claim > > or exactly what pieces of the technology are being claimed. > > See http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt > > I haven't received any more information about that even when I tried > to ask from Microsoft. > -- > 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 Oct 31 03:03:57 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VB3ukT083904; Fri, 31 Oct 2003 03:03:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09442 Fri, 31 Oct 2003 05:21:56 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16290.14758.563376.383730@ryijy.hel.fi.ssh.com> Date: Fri, 31 Oct 2003 12:29:58 +0200 From: Tero Kivinen To: Tom Hu Cc: latten@austin.ibm.com, ipsec@lists.tislabs.com Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: <3FA1B09E.F4CB6E86@cisco.com> References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> <3FA1B09E.F4CB6E86@cisco.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tom Hu writes: > Question about NAT-T with v2. I read v2 RFC, my impression it does > not allow to send or process notification message until the peer is > authenticated. I haven't found out any such restriction in the draft. It says that status notifications can be added to any packet. Also those notifications in the IKE_SA_INIT packets are also authenticated as the packets are included in the AUTH hash. > It also means that we only can send or process Notify > message after 4th messages. It seems we should send NAT-D in msg #1 > and #2, is it against ikev2 protocol? The IKEv2 NAT-T clearly says that those NAT_DETECTION_*_IP notifications are included in the IKE_SA_INIT exchange. > Or we have some selection of Notification message can allow before > 4th message? -- 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 Oct 31 03:24:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VBOZkT085058; Fri, 31 Oct 2003 03:24:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09623 Fri, 31 Oct 2003 05:50:01 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Possible problem in IKEv2? Date: Fri, 31 Oct 2003 11:49:58 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122315@esebe023.ntc.nokia.com> Thread-Topic: Possible problem in IKEv2? Thread-Index: AcOflFhkn62JH09oTWaVIAAE8m9cMA== To: X-OriginalArrivalTime: 31 Oct 2003 10:59:23.0821 (UTC) FILETIME=[0B357DD0:01C39F9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA09620 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, When using a non-key-generating EAP method, the initiator never generates any AUTH payloads. In this case, KEi/Ni are authenticated implicitly (by the ability to provide correct EAP Responses that are protected with SK_ai). However, it seems the client's AUTH payload has a second purpose as well: to provide integrity protection for the first message. If the initiator never generates an AUTH payload, is there anything that prevents an attacker from, e.g., removing some proposals from SAi1? (Or modifying some other payloads than KEi/Ni in the first message?) (Or have I missed some detail of this?) If this is indeed the case, I think the easiest solution would be to always include the AUTH payloads; if the EAP method does not generate keys, use some known fixed string (such as a single zero octet) as the key. Since the AUTH payload is protected by SK_ai, this should ensure that the first message was not modified (by someone who doesn't know the initiator's private DH value). Best regards, Pasi From owner-ipsec@lists.tislabs.com Fri Oct 31 09:09:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VH9XkT098432; Fri, 31 Oct 2003 09:09:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12234 Fri, 31 Oct 2003 11:20:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F97FA6A.7000207@airespace.com> References: <3F97FA6A.7000207@airespace.com> Date: Fri, 31 Oct 2003 11:27:36 -0500 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: 2401bis Issue # 89 -- Remove the selector "name" Cc: Karen Seo , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:57 -0700 10/23/03, Scott G. Kelly wrote: >The name selector is often used for remote access, and maybe for >other applications. I know of several ipsec implementations which >use fqdn for remote access policy selection, and without DN, how do >we apply access controls based on certs? > >Scott Folks, I apologize for this confusion. Karen and I spoke about what to do re symbolic names in the SPD, before I left for a trip. I was confused about which selector types we were discussing, and as a result caused Karen to send the issue #89 message. We do NOT plan to remove the ability to associate a symbolic name with an SPD entry. However, 2401 did a poor job of explaining how to use this facility and we plan to do a better job in 2401bis. Karen is drafting a revised message about what we plan to say in 2401bis on this topic. Sorry for the confusion. Please comment on the new text when it comes out next week. Steve From owner-ipsec@lists.tislabs.com Fri Oct 31 10:56:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIubkT002358; Fri, 31 Oct 2003 10:56:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13281 Fri, 31 Oct 2003 13:17:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 31 Oct 2003 13:26:21 -0500 To: "Mike Taylor" From: Stephen Kent Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:23 -0800 10/30/03, Mike Taylor wrote: >Hi All, > >Some comments about the 2401bis draft. > >Section 4.4.1 The Security Policy Database > > "...In order to support this, the SPD requires > distinct entries for inbound and outbound traffic." > > and a few paragraphs later > > "- each SPD entry is a list of 1 or more selector set pairs - each > selector set pair consists of one selector set for the SA from the > initiator to the receiver and one selector set for the SA from the > receiver to the initiator." > > I don't understand (maybe because I don't yet understand IKE very well) >this > second paragraph, especially given the prior sentence which indicates > that the SPD entries for inbound and outbound are separate, as they > were in 2401. The second paragraph seems to suggest that an SPD > entry is bidirectional. What am I missing? the first sentence should not have use the term "entries." the inbound and outbound traffic distinction is covered by the initiator/responder distinction i the entry. >Section 4.4.2 Selectors > > Still requires that both SPD entries and SAs carry selectors, > and still requires separate SAD entries for ESP and AH, so that > if I have a incoming datagram which must be processed through both > AH and ESP then I can't really make any use of the selectors in the > AH SA because until the datagram has also gone through ESP the > selectors are opaque. From a practical implementation standpoint > I certainly don't want to waste memory (in my embedded system) > on information I can't use. Each SPD entry must contain selector values because that is how one searches for the right SPD entry. The SAD contains values for extant SAs, and we put selector values there because we need to check inbound traffic to ensure consistency with the selector values negotiated during SA establishment. In Ikev1, you could establish two SAs at once, for the special case of AH + ESP. IKEv2 removed this special case feature, so now two SAs must be negotiated separately. the only way you can nest the two SAs, and thus apply both AH and ESP, is via creation and processing for both SAs. As noted in the revised processing model, nesting requires careful configuration of both the SPD and the forwarding tables, to cause the traffic to pass through IPsec processing twice, for both outbound and inbound processing. Frankly, the question I would ask is why (when) do you plan to use both AH & ESP? Given the current capabilities of ESP, we don't tend to see a need to use both. > > And of course the RFC mandates that that after processing > through the SAs the selectors in the datagram must be matched against > the SPD entry: > > 5. IP Traffic Processing > > As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", > the SPD must be consulted during the processing of all traffic > (INBOUND and OUTBOUND), including non-IPsec traffic. > > Why, if I really have the selectors stored in SAs, would I do this > on the inbound side in particular? this text is left over from 2401 and needs to be updated. it should now refer to SPD caches as the first place to look for outbound traffic, with reference to the SPD only if the packet cannot be matched to the cache. for inbound IPsec traffic, one matches against the relevant SAD entry. for other inbound traffic, match against the inbound cache, and look at the inbound SPD only if there is a miss. >In summary, should any of these requirements, in particular the need to >allow >specification of how selectors for SAs get inherited from SPD entries, >really be >requirements? I though we had done that, but if not, we will make it clear in the next rev. > >Should it even really be a requirement to have separate SAD and SPD entries? >Couldn't adequate security and interoperability be achieved without this >requirement? No. think of the SPD as the reference database that describes all possible SAs that might be created, whereas the SAD and SPD caches represent the SAs that have been created. >I guess I'm just begging for simplification. Let's focus on getting the >true requirements for good security and interoperability spelled out very >clearly, and not keep all these implementation details from 2401 in 2401bis. >For small embedded systems its essential to clearly spell out the the >requirements rather than implementation details as there is always a desire >to conserve memory and CPU resources in such systems and yet be able to >comply >with the functionality that is truly required. Please don't assume that >everyone >who implements code per RFCs is only interested in multi-user systems and >high-end workstations. we don't make those assumptions, but we do require that all implementations interoperate, and that they provide users with a uniform, minimum set of management capabilities for access control. Steve From owner-ipsec@lists.tislabs.com Fri Oct 31 10:59:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIxdkT002536; Fri, 31 Oct 2003 10:59:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13090 Fri, 31 Oct 2003 13:06:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 31 Oct 2003 13:08:04 -0500 To: "Mike Taylor" From: Stephen Kent Subject: RE: 3rd try -- 2401bis issue 91 -- handling ICMP error messages Cc: "Karen Seo" , "ipsec mailingList" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >It seems to me that in general the description of handling >ICMP messages must be divorced from the presumption of any >a-priori knowledge on the part of the IPsec implementation as to which >networks are red and which are black, or which hosts are trusted >and which aren't. Mike, In general, IPsec provides a barrier wihtin a device (host, BITW, or SG), with red (friendly) interfaces on one side of the barrier and black (hostile) interfaces on the other. The SPD controls what we allow across the barrier, and whether we protect it or not. If one wants to provide security services for each, individual interface, then one needs to think of applying IPsec to each interface independently, nominally replicating the Ipsec instance for each interface. For example, if one has a security gateway with four interfaces, you could out IPsec on each interface card or you could have one Ipsec instance for the device as a whole, consistent with the model. In most cases, the single instance, red/black model works pretty well. the terms "trusted" and "untrusted" are not ones I like to use here. for example, we may establish a tunnel to an SG at a site, but that does not mean that we just trust the site. We apply selector checks on the packets that emerge from the tunnel precisely because we do not just trust the site or the remote SG. Steve From owner-ipsec@lists.tislabs.com Fri Oct 31 10:59:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIxfkT002537; Fri, 31 Oct 2003 10:59:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13211 Fri, 31 Oct 2003 13:14:36 -0500 (EST) Message-ID: <3FA2A893.87A67635@cisco.com> Date: Fri, 31 Oct 2003 10:23:15 -0800 From: Tom Hu X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: latten@austin.ibm.com, ipsec@lists.tislabs.com Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> <3FA1B09E.F4CB6E86@cisco.com> <16290.14758.563376.383730@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > Tom Hu writes: > > Question about NAT-T with v2. I read v2 RFC, my impression it does > > not allow to send or process notification message until the peer is > > authenticated. > > I haven't found out any such restriction in the draft. It says that > status notifications can be added to any packet. Also those > notifications in the IKE_SA_INIT packets are also authenticated as the > packets are included in the AUTH hash. Please see this paragraph in 11.txt 1.4 The INFORMATIONAL Exchange At various points during the operation of an IKE_SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys. Here initial exchange includes 1 to 4 messages. And by the way, IKE_SA_INIT message does not have AUTH payload. AUTH payload is sending at #3 and #4 messages. > > > It also means that we only can send or process Notify > > message after 4th messages. It seems we should send NAT-D in msg #1 > > and #2, is it against ikev2 protocol? > > The IKEv2 NAT-T clearly says that those NAT_DETECTION_*_IP > notifications are included in the IKE_SA_INIT exchange. > > > Or we have some selection of Notification message can allow before > > 4th message? > -- > 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 Oct 31 13:09:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VL9kkT008180; Fri, 31 Oct 2003 13:09:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14617 Fri, 31 Oct 2003 15:20:36 -0500 (EST) Message-Id: <5.2.0.9.2.20031031152519.0449f590@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 15:29:27 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Fwd: Certicom IP Rights Cc: iesg@ietf.org, IMcKinnon@certicom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPsec Working Group: I just got this note, which is a follow-up to a query that I sent to Certicom in July 2003. I have asked Mr. McKinnon to post an updated IPR statement as soon as possible. Russ --- Original Message --- To: housley@vigilsec.com From: Ian McKinnon Date: Fri, 31 Oct 2003 15:14:09 -0500 Dear Mr. Housley: First, let me apologize for not responding sooner on our our Intellectual Property position re the August email stating that Certicom may have certain IP rights covering some aspects of the proposed IKEv2 proposal draft . Our IP group was totally consumed completing a $US 25 million IP licensing arrangement with the US Governments National Security Agency for a subset of our intellectual property portfolio for a limited field of use as it relates to its high assurance initiatives. We wish to advise the IETF that Certicom believes it has rights under patents and/or pending applications that relate to RFC 3526 "More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", RFC 2409 "Internet Key Exchange", Internet Draft (draft-ietf-ipsec-ikev2-11.txt) "Internet Key Exchange (IKEv2) Protocol" and other IETF standards using MODP Groups. The applicable patents include, but are not limited to, US Patents #5,933,504, #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent Application Publications #2001/0014153, #2002/0090085, and PCT Application #WO 00/01109, and corresponding foreign applications. Some of the patents listed in the previous paragraph were part of the NSA licensing arrangement discussed in paragraph 1 as they relate to elliptic curve cryptography (ECC). For applications requiring higher levels of security, we believe that one should consider ECC for the technological advantages over other public-key schemes. Certicom is willing to grant a royalty free license to the patents and patent pending listed in paragraph 2 for the purpose of practicing the art of public key cryptography as it pertains to IETF IKE standards in the limited field of use of MODP public key cryptography implemented using the well known Groups 1 and 2 as defined in RFC 2409. Certicom will send the IETF terms of the royalty free license and will post this our web site shortly. Outside the implementation of IETF IKE standards using well known Groups 1 and 2 Certicom is prepared to grant a license to such intellectual property on reasonable, non-discriminatory terms and conditions, provided that the licensee provides a similar grant for any relevant patents under their control to Certicom. Ian McKinnon President and CEO Certicom Corp From owner-ipsec@lists.tislabs.com Fri Oct 31 13:46:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLkGkT009537; Fri, 31 Oct 2003 13:46:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15086 Fri, 31 Oct 2003 16:08:57 -0500 (EST) From: "Casey Carr" To: "Ipsec@Lists. Tislabs. Com" Subject: Aggressive/Main mode proposal Date: Fri, 31 Oct 2003 15:41:16 -0500 Message-ID: <006401c39fef$551893a0$b501a8c0@cipheroptics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C39FC5.6C428BA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 31 Oct 2003 20:41:16.0968 (UTC) FILETIME=[5510F280:01C39FEF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C39FC5.6C428BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Can anyone clear up an IKE proposal issue for me? If two secure gateways are configured with the same IKE proposal parameters with the exception that one is configured for main mode and the other is configured for aggressive mode, can a valid IKE proposal be negotiated? I'm assuming that regardless of which SG initiates, the result would be a main mode Phase 1. Correct? Thanks, Casey ------=_NextPart_000_0065_01C39FC5.6C428BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anyone clear up an IKE proposal issue for = me? If two secure gateways are configured with the same = IKE proposal parameters with the exception that one is configured for main = mode and the other is configured for aggressive mode, can a valid IKE proposal be negotiated? Im assuming that regardless of which SG = initiates, the result would be a main mode Phase 1. Correct? Thanks, Casey ------=_NextPart_000_0065_01C39FC5.6C428BA0-- From owner-ipsec@lists.tislabs.com Fri Oct 31 18:05:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA125mkT021289; Fri, 31 Oct 2003 18:05:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16560 Fri, 31 Oct 2003 20:24:50 -0500 (EST) From: "Mike Taylor" To: "Stephen Kent" Cc: Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt Date: Fri, 31 Oct 2003 17:34:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Thanks for your response. I think it clarifies some things but I'm still not clear on some points. See below. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Friday, October 31, 2003 10:26 AM > To: Mike Taylor > Cc: ipsec@lists.tislabs.com > Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt > > > At 8:23 -0800 10/30/03, Mike Taylor wrote: > >Hi All, > > > >Some comments about the 2401bis draft. > > > >Section 4.4.1 The Security Policy Database > > > > "...In order to support this, the SPD requires > > distinct entries for inbound and outbound traffic." > > > > and a few paragraphs later > > > > "- each SPD entry is a list of 1 or more selector set > pairs - each > > selector set pair consists of one selector set for the > SA from the > > initiator to the receiver and one selector set for the > SA from the > > receiver to the initiator." > > > > I don't understand (maybe because I don't yet understand > IKE very well) > >this > > second paragraph, especially given the prior sentence which > indicates > > that the SPD entries for inbound and outbound are separate, as they > > were in 2401. The second paragraph seems to suggest that an SPD > > entry is bidirectional. What am I missing? > > the first sentence should not have use the term "entries." the > inbound and outbound traffic distinction is covered by the > initiator/responder distinction i the entry. I think what you're saying here is that there will no longer be separate inbound and outbound policy databases? Then much more of 2401bis needs major rewriting. Is this being imposed by changes to IKE in IKEv2? I am finding having the separate policies for inbound and outbound very useful for debugging during development. And I can even see an argument for one-way policies in general, for example, perhaps some kind of remote sensor. Who knows? And of course, pragmatically its far too late to change my current design now. I have separate policies. But I'm not really doing an IPsec v3 implementation anyway. I was only looking to 2401bis to clarify some of the confusion I found in 2401. > > >Section 4.4.2 Selectors > > > > Still requires that both SPD entries and SAs carry selectors, > > and still requires separate SAD entries for ESP and AH, so that > > if I have a incoming datagram which must be processed through both > > AH and ESP then I can't really make any use of the selectors in the > > AH SA because until the datagram has also gone through ESP the > > selectors are opaque. From a practical implementation standpoint > > I certainly don't want to waste memory (in my embedded system) > > on information I can't use. > > Each SPD entry must contain selector values because that is how one > searches for the right SPD entry. If SAs all have selectors one can envision having an outbound SA cache and 1st searching the SA cache before bothering to look at the SPD. After all, this would generally reduce the amount of time wasted looking at the SPD which is primarily used to create new SAs but presumably the creation of new SAs occurs far less frequently than the transmission of a datagram in most systems. Am I missing something? > The SAD contains values for extant > SAs, and we put selector values there because we need to check > inbound traffic to ensure consistency with the selector values > negotiated during SA establishment. But in my implementation I have back pointers from all SAs to the policy that spawned them. So when I'm done processing an inbound datagram through an SA the SA knows where to find the policy that contains the selectors. So unless this inheritance of selectors by SAs provides some required functionality from a blackbox perspective (improved security and/or interoperability) that cannot be achieved just as well with multiple policies it seems like one could just as well only have selectors in SPD entries and none in SAs, thereby possibly saving significant RAM for a small system especially with 128-bit IPv6 addresses. > > In Ikev1, you could establish two SAs at once, for the special case > of AH + ESP. IKEv2 removed this special case feature, so now two SAs > must be negotiated separately. the only way you can nest the two SAs, > and thus apply both AH and ESP, is via creation and processing for > both SAs. As noted in the revised processing model, nesting requires > careful configuration of both the SPD and the forwarding tables, to > cause the traffic to pass through IPsec processing twice, for both > outbound and inbound processing. > > Frankly, the question I would ask is why (when) do you plan to use > both AH & ESP? Given the current capabilities of ESP, we don't tend > to see a need to use both. Well, the problem from my perspective is that 2401 has so much implementation detail that it is very hard for me remain clear on what are requirements and what are just suggestions. For example, see 4.5 Basic Combinations of Security Associations. It shows the case of ESP in AH in transport mode and begins with the sentence: "This section describes four examples of combinations for security associations that MUST be supported by compliant IPsec hosts or security gateways." Aside from that, I've seen other references to the fact that since ESP doesn't authenticate the IP header AH may still be useful for that purpose. I'm a programmer, not an IT person. I don't really know what people think is useful on the real world and I don't have much marketing input. So I try to conform to the RFC's requirements. If ESP in AH isn't useful then the 2401bis should certainly make it clear that it isn't a required basic SA combination. > > > > > And of course the RFC mandates that that after processing > > through the SAs the selectors in the datagram must be > matched against > > the SPD entry: > > > > 5. IP Traffic Processing > > > > As mentioned in Section 4.4.1 "The Security Policy > Database (SPD)", > > the SPD must be consulted during the processing of all traffic > > (INBOUND and OUTBOUND), including non-IPsec traffic. > > > > Why, if I really have the selectors stored in SAs, would I do this > > on the inbound side in particular? > > this text is left over from 2401 and needs to be updated. it should > now refer to SPD caches SPD caches? Another implementation detail? > as the first place to look for outbound > traffic, with reference to the SPD only if the packet cannot be > matched to the cache. for inbound IPsec traffic, one matches against > the relevant SAD entry. for other inbound traffic, match against the > inbound cache, and look at the inbound SPD only if there is a miss. > > > > >In summary, should any of these requirements, in particular the need to > >allow > >specification of how selectors for SAs get inherited from SPD entries, > >really be > >requirements? > > I though we had done that, but if not, we will make it clear in > the next rev. >From 2401bis: For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): Now that I re-read this again I see that the keyword MUST is indeed missing from the above sentence. My apologies. I'm actually rather aggravated by this since I guess I've been under the impression for some time that this was a requirement. Clearly that is my own fault, but its very easy to become confused when there is such a mix of informal implementation suggestions/hints mixed in intimately with actual requirements. > > > > >Should it even really be a requirement to have separate SAD and > SPD entries? > >Couldn't adequate security and interoperability be achieved without this > >requirement? > > No. think of the SPD as the reference database that describes all > possible SAs that might be created, whereas the SAD and SPD caches > represent the SAs that have been created. > > >I guess I'm just begging for simplification. Let's focus on getting the > >true requirements for good security and interoperability spelled out very > >clearly, and not keep all these implementation details from 2401 > in 2401bis. > >For small embedded systems its essential to clearly spell out the the > >requirements rather than implementation details as there is > always a desire > >to conserve memory and CPU resources in such systems and yet be able to > >comply > >with the functionality that is truly required. Please don't assume that > >everyone > >who implements code per RFCs is only interested in multi-user systems and > >high-end workstations. > > we don't make those assumptions, but we do require that all > implementations interoperate, and that they provide users > with a > uniform, minimum set of management capabilities for access control. > > Steve