From owner-ipsec@lists.tislabs.com Sat Feb 1 09:58:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h11Hwoo06156; Sat, 1 Feb 2003 09:58:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25077 Sat, 1 Feb 2003 12:21:42 -0500 (EST) From: "Jayant Shukla" To: "'Stephen Kent'" Cc: Subject: RE: new to VPN Date: Sat, 1 Feb 2003 09:22:15 -0800 Message-ID: <011201c2ca16$776404d0$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Stephen Kent > > although I agree it improves the situation. Dedicated > hardware devices usually do not have the OS services present to shut > off, so they are better off. I am not sure I really understand. Once you have switched off services, what is the difference? You agree that it improves security and then you say hardware is better. Can you tell me attacks that are OS specific and not related to a service? > I think we see more of this flavor in > modern firewall products as well, so I think there is a parallel > evolution path here. > Which modern hardware firewalls? Newest thing in security is to solve the intrusion problem and weed out Trojans. A recent test has shown that hardware based systems performed miserably. There are a lot of things you can do in software to catch detect intrusions and catch Trojans, that you can never do by using a standalone hardware. > >There is a lot more to practical security than FIPS level 3. Maybe your > >box is fine, but a Trojan can have a field day with the computers behind > >your box. > > Yes, but it's not the fault of the box, which is the focus of this > discussion. > In my very first e-mail, I _very_ clearly stated that software based systems will have an advantage in detecting Trojans. And therefore may have an advantage in overall security. If you did not agree to that statement and wanted to talk only about the security of VPN box, you could have mentioned it a lot earlier. > Since the comment applies to just the security of the IPsec device, > not the computers behind it, I think it is fair to say that a > dedicated, hardware implementation of IPsec has the potential to be > considerably more secure than an implementation that runs on a > general purpose computer with a general purpose OS, even if one > attempts to harden the OS by turning off extraneous services. The reason for my original response was that a general perception has been created that hardware is more secure than software. Maybe (a real maybe), VPN hardware is more secure than software based VPN, but somehow that gets generalized to overall security. IMHO that is not correct. Here is a good example of hardware relying on software to improve security.... Several leading VPN hardware vendors are working with those who specialize in host-based security to ensure that the host configurations have not been altered to infect the host with a virus/Trojan. These secure VPN boxes were serving as a conduit to spread viruses and Trojans and wreaking havoc on corporate security. To summarize, security based on your lowly desktop OS is looking good. It provides an excellent platform to integrate security function to improve ease of configuration, management, event correlation, protection against internal attacks, Trojan & intrusion detection and is a better solution for overall security. Not to mention that it is much more economical. Performance is excellent as well. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Sat Feb 1 11:19:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h11JJao11352; Sat, 1 Feb 2003 11:19:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25255 Sat, 1 Feb 2003 13:52:21 -0500 (EST) Message-Id: <5.2.0.9.2.20030201135221.02d509d0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 13:54:55 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: draft-ietf-ipsec-ciph-aes-ctr-03.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <200301311251.HAA05032@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only changes in this version deal with IKE Conventions. The nonce value is extracted from the PRF instead of reusing some of the IKE nonce bits. This was clearly preferred by the IPsec mailing list membership. I believe that this document is ready for WG Last Call. Barb and Ted, please kick it off. Russ At 07:51 AM 1/31/2003 -0500, Internet-Drafts@ietf.org wrote: >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 : Using AES Counter Mode With IPsec ESP > Author(s) : R. Housley > Filename : draft-ietf-ipsec-ciph-aes-ctr-03.txt > Pages : 18 > Date : 2003-1-30 > >This document describes the use of AES Counter Mode, with an explicit >initialization vector, as an IPsec Encapsulating Security Payload >confidentiality mechanism. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt From owner-ipsec@lists.tislabs.com Sat Feb 1 11:19:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h11JJdo11364; Sat, 1 Feb 2003 11:19:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25254 Sat, 1 Feb 2003 13:52:16 -0500 (EST) Message-Id: <5.2.0.9.2.20030201135221.02d509d0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 13:54:55 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: draft-ietf-ipsec-ciph-aes-ctr-03.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <200301311251.HAA05032@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only changes in this version deal with IKE Conventions. The nonce value is extracted from the PRF instead of reusing some of the IKE nonce bits. This was clearly preferred by the IPsec mailing list membership. I believe that this document is ready for WG Last Call. Barb and Ted, please kick it off. Russ At 07:51 AM 1/31/2003 -0500, Internet-Drafts@ietf.org wrote: >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 : Using AES Counter Mode With IPsec ESP > Author(s) : R. Housley > Filename : draft-ietf-ipsec-ciph-aes-ctr-03.txt > Pages : 18 > Date : 2003-1-30 > >This document describes the use of AES Counter Mode, with an explicit >initialization vector, as an IPsec Encapsulating Security Payload >confidentiality mechanism. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt From owner-ipsec@lists.tislabs.com Sat Feb 1 13:25:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h11LP5o15242; Sat, 1 Feb 2003 13:25:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25495 Sat, 1 Feb 2003 15:57:16 -0500 (EST) Message-Id: <200302012059.h11KxSPA013134@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Fri, 31 Jan 2003 16:49:33 PST." <3E3B199D.6996CE1D@bstormnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 01 Feb 2003 15:59:28 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> below which you suggest won't work. Perhaps you should ask the folks Scott> from Zurich University of Applied Sciences if you can take a look at Scott> their frees/wan implementation. I know a lot about this. It works as well as it does for a number of hysterical raisins: 1) FreeSWAN essentially still pretends to be a bump in the stack. (The actual truth depends upon which kernel revision you ask about, is even stranger than fiction) To the point of impersonating the MAC address of the interface that it sits on. As such, dhclient is actually rather happy with the situation. (I haven't investigating what happens when you run it with a PPP interface as the underlying hardware. FreeSWAN pretends to be a PPP device in that situation, and I wonder what dhclient will think) 2) ISC dhclient actually goes around the IP stack to send its packets (using PF_PACKET on Linux, BPF+raw sockets on BSD). Because FreeSWAN has a very "complete" bump in the stack, this works. Both of these things are VERY hard to do when IPsec is integrated into the stack. Scott> To my original point, Darren seems to be suggesting that he wants the Scott> ability to configure values not supported by DHCP. I was simply asking Scott> what these might be. I strongly agree with you - I want to use DHCP. I just do not want to run it over a very hard to manage IPsec SA. The coordination between dhclient getting an IP address and IKE, and renewals, etc. just scares me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjw1LoqHRg3pndX9AQGPYAP+Ng/rB614VdMNomwdzw3SEYzUDdbZIXHV WxDI8kZ4HZFrLezy2fQdxQTo1XmhiJBy4eZ5crBBvL7xQi/FdhX2c8zRYsYaeyf1 t115Z/9Fci1FUvnoDDejwUNS+vct2rhg5xpK3ytdCiWVmT5KezEfPZDt/x80gY8O M5T3sEksHo8= =yR7f -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Feb 1 18:31:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h122Vpo23820; Sat, 1 Feb 2003 18:31:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25968 Sat, 1 Feb 2003 21:02:32 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Modefg considered harmful To: Bernard Aboba Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 20:24:53 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 09:04:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While my personal interests are in settling the MODECFG vs DHCP-relay debate in any way that sticks, I can't resist throwing in my technical opinion. The appeal of MODECFG is that it minimizes the number of messages and crypto operations in getting an IPsec session set up. The appeal of DHCP-relay is that it provides all of the flexibility and power of DHCP (including extensions defined in the future) and does so in a way that appears to make it independent of the IKE specification. But I believe this appearance is illusory. For an endnode to acquire an IP address on a remote network for use with IPsec, there are several things going on - only one of which involves DHCP. Yes, the address must be leased, but in addition the IPsec gateway implementation has to begin responding to ARPs to that address and forwarding packets addressed to that address over the IPsec tunnel. The IPsec gateway should only accept packets over the IPsec tunnel with source address equal to one that the endnode has legitimately leased. That means the gateway can't be a passive relay. It has to parse the messages it is passing through, and if there are extensions to DHCP in the future that affect leases on IP addresses, the gateways will have to be updated to understand them. I believe this is what Cheryl Madson referred to as "a special state" in the state machine. So I would claim that the IPsec endnode, the IPsec gateway, and the DHCP server are running a three party protocol, and it's not obvious whether it's better to have the IPsec gateway eavesdrop on the DHCP conversation or be a full participant by acting as a DHCP server to the endnode and a client to the DHCP server. As a practical matter, MODECFG specifies exactly what the two participants have to do, while DHCP-relay is more open to interpretation. Unless DHCP-relay were specified more precisely in terms of what the IPsec gateway had to do with the information it saw passing by, it seems likely that MODECFG would give us better interoperability. And if IPsec gateway actions in response of DHCP messages were specified more precisely, I believe that proposal would lose must of its extensibility. The use of MODECFG does not preclude the use of tunnelled DHCP for uses other than acquiring leases on IP addresses. If I were designing the protocol, I'd have IKE handle *only* IP address leases (defining the life of the lease to match the life of the SA), and use tunnelled DHCP for all other functions (like getting DNS server addresses). Adding a few more fields to MODECFG enhances performance - probably in a trivial way - but it's likely that doing so will result in requests for more in the future (which we can either accept or decline). I could be convinced either way. In summary, I believe MODECFG as specified will work and will provide few interoperability surprises. I believe DHCP-relay could be made to work if it were more tightly specified, but would be more likely to provide interoperability problems. DHCP-relay does provide some functionality not possible with MODECFG - in particular assignment of IP addresses based on additional information about the client. If any of that functionality is actually needed, it could be added to MODECFG, but I haven't heard a case for it yet. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 18:31:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h122Vro23833; Sat, 1 Feb 2003 18:31:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25966 Sat, 1 Feb 2003 21:02:29 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: CREATE_CHILD_SA exchange with PFS To: burkhard Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 18:09:44 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 09:04:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk burkhard wrote on 01/26/2003 02:26:26 PM: > Hallo all, > > I have the following question about . > > Am I allowed to use after the Initial phase 1 Exchange the CREATE_CHILD_SA > exchange with PFS or is the CREATE_CHILD_SA exchange with PFS only intended > to be for rekeying at a later stage? > > My understanding by reading the draft is that CREATE_CHILD_SA exchange with > PFS is not allowed to be piggybacked on the phase 1 exchange, therefore if I > whish to use PFS I need to do a CREATE_CHILD_SA exchange. This will result > in 4 Initial phase 1 Exchange transmissions and 2 for the CREATE_CHILD_SA > creation with PFS. > > Does it make sense to use a CREATE_CHILD_SA exchange with PFS straight after > the Initial phase 1 Exchange? > > Burkhard The current spec does not allow a second D-H exchange for the child SA set up in the initial IKE exchange. This was to simplify the specification and because I believe there is never any security advantage in doing so. The purpose of subsequent D-H exchanges is to assure that even someone who has broken into the endpoints and copied all keying material cannot in a passive attack decrypt the data encrypted under keys derived using the second D-H exchange. But this advantage only applies if a nontrivial period of time elapses between the two exchanges (because protection is only gained if the break in occurs between the two exchanges). --Charlie From owner-ipsec@lists.tislabs.com Sat Feb 1 18:31:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h122Vso23842; Sat, 1 Feb 2003 18:31:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25967 Sat, 1 Feb 2003 21:02:31 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Ciphersuites for IKEv2, revised To: EKR Cc: ipsec@lists.tislabs.com, Michael Richardson , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 18:38:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 09:04:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk EKR wrote on 01/30/2003 06:38:44 PM: > Michael Richardson writes: > > So, we have to have three different proposal structures, which are > > identical, except that they negotiate the same things for the > different uses? > My bad. I'd forgotten that "proposal structure" was a technical term. > > I'd prefer to see the proposal structure explicitly modified to > represent the fact that there are three different things > being negotiated. The problem is that it's not just three things. While IKE, ESP, and AH are the only protocols for which suites are currently defined, negotiation of a tunnel protected by both ESP and AH is explicitly allowed. We could add to the proposal structure a protocol ID as well as a suite ID and define values for IKE, ESP, AH, and AH w/ESP, and perhaps leave some bits for future protocols negotiated with IKE, but if we define AH w/ESP, someone is going to want to specify a suite for it. Further, the different protocols need different algorithms specified. AH needs just a MAC. ESP needs MAC and Encryption. (Or perhaps in the not too distant future a combined algorithm). IKE needs MAC, Encryption, and PRF. All can optionally have a Diffie-Hellman group. I believe it would be more confusing than clarifying to pretend that the algorithm negotiation is independent of whether we're talking IKE, ESP, or AH. That said, I do think it would be a good idea to group the IKE, ESP, and AH suites both in their numbering ranges and as ordered in the specification. Would anyone object to my changing Paul's numbers? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 19:12:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h123CUo24685; Sat, 1 Feb 2003 19:12:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26117 Sat, 1 Feb 2003 21:50:26 -0500 (EST) Date: Sat, 1 Feb 2003 17:41:02 -0800 (PST) From: Bernard Aboba To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, Subject: Re: Modefg considered harmful In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It has to parse the messages it is > passing through, and if there are extensions to DHCP in the future that > affect leases on IP addresses, the gateways will have to be updated to > understand them. The relationship between the client, IPsec gateway and DHCP server is "three way" in either case. But the responsibilities of the parties are quite different. RFC 3456 states that the IPsec gateway acts as a pure DHCP relay, not a proxy. This implies, for example, that DHCP authentication (RFC 3118) can be carried out between the DHCP client and server. This is not possible with Modecfg, because the IPsec gateway does not have the credentials to act on the client's behalf. DHCP Relays *do not* need to understand all the options contained in DHCP packets, since their primary function is forwarding packets. State is kept on the end systems. In contrast, with Modecfg, the IPsec gateway needs to implement the DHCP client state machine (if it talks to a DHCP server). With RFC 3456, the IPsec gateway *does* need to know the IP address assigned to the client, for the reasons you state. However, the lease time is not relevant to operation of a DHCP Relay, because in RFC 3456 address renewal is the responsibility of the client, *not* the IPsec gateway. The means that the IPsec gateway would not be affected by definition of new options. And in RFC 3456, there is no need for the IPsec gateway to also be a DHCP server. However, with Modecfg, the IPsec gateway is often a DHCP client. This is problematic, because DHCP is end-to-end. That means that when the IPsec gateway attempts to renew the address, the reply will ordinarily come to the client, *not* to the IPsec gateway -- and the client will not be expecting DHCP packets. As RFC 3456 explains, some trickery is required to circumvent this, which shortens the time available for address renewal. One question is whether this could potentially result in addresses expiring or being assigned to someone else. Since Modecfg has no facilities for lease expiration or reconfiguration, that would be difficult to recover from. > I believe this is what Cheryl Madson referred to as "a > special state" in the state machine. DHCP relays are stateless, so you can't be talking about DHCP state -- which needs to be kept by Modecfg. I assume the state referred to relates to the IP address -- but that state is required in either case. > So I would claim that the IPsec endnode, the IPsec gateway, and the DHCP > server are running a three party protocol This is true in either case. >, and it's not obvious whether > it's better to have the IPsec gateway eavesdrop on the DHCP conversation or > be a full participant by acting as a DHCP server to the endnode and a > client to the DHCP server. RFC 3456 does not require the IPsec gateway to also act as a DHCP server, since that would require the gateway to implement persistent storage; that is why only DHCP relay functionality is required, which is stateless. However, for the reasons described above, I could see where with Modecfg that might be a requirement. > As a practical matter, MODECFG specifies exactly > what the two participants have to do, while DHCP-relay is more open to > interpretation. The DHCP Relay functionality is specified in RFC 2131 -- and if this was "open to interpretation" we'd probably have encountered those issues in the Connectathon bakeoffs. > Unless DHCP-relay were specified more precisely in terms of > what the IPsec gateway had to do with the information it saw passing by, it RFC 2131 states the responsibilities of DHCP Relays very clearly. The primary responsibility is packet forwarding. I think you may be confusing the operation of a DHCP Relay with a DHCP proxy -- which *is* ill-defined. > seems likely that MODECFG would give us better interoperability. And if This hasn't come up in DHCP Relay testing at Connectathon. > IPsec gateway actions in response of DHCP messages were specified more > precisely, I believe that proposal would lose must of its extensibility. The DHCP Relay function is laid out precisely in RFC 2131. > The use of MODECFG does not preclude the use of tunnelled DHCP for uses > other than acquiring leases on IP addresses. In fact, if RFC 1877 is any guide, it's likely that MODECFG clients will end up doing DHCPINFORM anyway. So what is the point of implementing MODECFG at all? Why not use DHCPv4 or RA/RS for address assignment? > If I were designing the > protocol, I'd have IKE handle *only* IP address leases (defining the life > of the lease to match the life of the SA), and use tunnelled DHCP for all > other functions (like getting DNS server addresses). That would make more sense. But there is still a problem with doing IP address assignment within MODECFG -- IPv6 compatibility. Does MODECFG now duplicate the functionality of RS/RA? Or does it hand out individual IPV6 addresses? Do we have completely different mechanisms for address assignment and configuration between IPv4 and IPv6? Why go down that road? If you're going to tunnel the RS/RA conversation, you end up with something quite close to RFC 3456 anyway -- so why not handle IPv4 and IPv6 the same way from the start? > Adding a few more > fields to MODECFG enhances performance - probably in a trivial way - but > it's likely that doing so will result in requests for more in the future > (which we can either accept or decline). I could be convinced either way. As RFC 1877 showed, this is the road to hell. Since we know that we can't realistically go there, why start? > In summary, I believe MODECFG as specified will work and will provide few > interoperability surprises. And over time will pile up kludge upon kludge to the point where it will result in lots of unnecessary complexity, IPV6 incompatibility, or worse. > I believe DHCP-relay could be made to work if > it were more tightly specified, but would be more likely to provide > interoperability problems. I think you're confusing DHCP Relay with Proxy. There are no major interoperabilty problems with DHCP Relays. > DHCP-relay does provide some functionality not > possible with MODECFG - in particular assignment of IP addresses based on > additional information about the client. If any of that functionality is > actually needed, it could be added to MODECFG, but I haven't heard a case > for it yet. It's more than just "functionality". IP addressing is a utility-class service. That's why there's lots of demand for clustering, redundancy, etc. Reliable operation is not just a good idea -- it's a requirement in many situations. MODECFG isn't designed to provide highly reliable addressing functionalty -- or to evolve so as to support future needs. From owner-ipsec@lists.tislabs.com Sat Feb 1 19:45:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h123j5o25075; Sat, 1 Feb 2003 19:45:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26217 Sat, 1 Feb 2003 22:19:57 -0500 (EST) Date: Sat, 1 Feb 2003 18:10:16 -0800 (PST) From: Bernard Aboba To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, Subject: Modecfg and IPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Maybe it's just me, but I don't understand the plan for support of IPv6 in MODECFG. So far, the available ways of getting an IPv6 address are static config, RS/RA or DHCPv6. The former doesn't need MODECFG, and the latter two mechanisms would ordinarily require a tunneling solution somewhat akin to RFC 3456. But if MODECFG is used instead, it would be nice to understand how it's supposed to work. Some questions: a. Does MODECFG assign a specific IPv6 address, as DHCPv6 can do? Or does it provide only a prefix as in RS/RA? b. How would MODECFG handle the other functions of RS/RA, such as the "H" bit for a MIPv6 HA? If MODECFG doesn't handle those functions, how much of the IPv6 functionality do we lose? If it does handle them, do we end up duplicating the RS/RA functionality in MODECFG? c. How does MODECFG handle both IPv4 and IPv6 configuration? Do we need both IPv4 and IPv6 config support in MODECFG? d. Or is it assumed that MODECFG will only handle IPv4 address and config, and that IPv6 will be handled by tunneling as in RFC 3456? If it is already necessary to support tunneling of RS/RA and DHCPv6 in order to support IPv6, why support MODECFG in addition? From owner-ipsec@lists.tislabs.com Sat Feb 1 20:32:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h124WIo25630; Sat, 1 Feb 2003 20:32:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26368 Sat, 1 Feb 2003 23:09:15 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 To: Stephen Kent Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "Theodore Ts'o" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 21:58:53 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 11:11:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote on 01/31/2003 06:31:45 PM: > It is likely that IANA will add additional Suite-IDs in the future, and > some users may want to use private suites, especially for IKE where > implementations should be capable of supporting different parameters, > up to certain size limits. In support of this goal, all > implementations of IKEv2 SHOULD [I'd prefer MUST, but Paul has argued > eloquently for very restrictive criteria for MUST re suites.] include > a management facility that allows specification (by a user or system > administrator) of Diffie-Hellman parameters (the generator, modulus, > and exponent lengths and values) for new IKE Suites. Implementations > SHOULD provide a management interface via which these parameters and > the associated Suite-IDs may be entered (by a user or system > administrator), to enable negotiating such Suites. I would strongly oppose making this a "MUST" and have mixed feelings about "SHOULD". If we are going to include it, I think we have to say what the size limits are, and whether all intermediate sizes SHOULD be supported. We had such a debate over RSA key sizes, without concrete resolution. The current draft says 1024 and 2048 bit keys MUST be supported and doesn't say anything about SHOULD. There exist implementations of crypto toolkits that don't support RSA keys that are not an integer multiple of 16 bits in size. Very general requirements make conformance testing harder. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 20:32:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h124WJo25636; Sat, 1 Feb 2003 20:32:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26367 Sat, 1 Feb 2003 23:09:14 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 22:35:20 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 11:11:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" wrote: > Hugo has suggested that for EAP mechanisms that generate a shared key, > the responder should send an AUTH message based on the shared key in the > message containing the EAP(success) message, as backup in case for some > reason the CERT based exchange might have gotten spoofed somehow. This > seems to me to be a case of gilding the lilly, and is probably not be > worth the extra complexity, but I encourage comment on the working group > about whether or not this additional twist should be included. I agree with Hugo on this one. We've been assuming that legacy auth is always going to have the responder first authenticating to the initiator with certificates the initiator will know how to process. But I can imagine cases where legacy auth is mutual and the cert based authentication is only a formality (or perhaps skipped). For example, a legacy auth scheme based on EKE, SPEKE, SRP, or PDM might have this property. What do others think? Hugo Krawczyk wrote: > The one thing that I definitely dislike in the appended proposal is that > it opens IDi (sent in message 3) to active attacks. If there is one > application where identity protection really makes sense is in hiding > identities and locations of mobile users, which will be among the main > users of SLA. I suggest to make IDi optional in message 3, and make it > clear that implementations should NOT assume that this IDi value is > available, certainly not in a way that compromises the user's identity. I am genuinely conflicted about this one - like the donkey between the two bales of hay. I see equally good arguments on both sides, and I don't think it matters much. But it does matter that we decide. If IDi is included in message 3, it is exposed to active attacks. (Someone impersonating the gateway can learn the claimed name of the initiator and subsequently break the connection). We decided we could live with that for cert based authentication, but if the case for preventing it is a little stronger here. If it is not included in message 3, then the gateway may not be able to produce the challenge it needs for message 4 and the protocol could require an extra round trip. If we make it optional in message 3, the spec has to say (and the implementations have to code and test) all of the options. I put a stake in the ground in ikev2-04 and said it was required in message 3. Do people want it to say something else? Should it be legacy authentication mechanism specific? Hugo Krawczyk wrote: > I have no practical (or other) experience with such key-providing > legacy authentication methods. However, since these are LEGACY methods > then I assume that if they generate a shared key then this key may be > intended for other uses. Can we be sure that this key (call it LK for > "legacy key"), if used by SLA, will be used ONLY by SLA? Otherwise we may > end having one key LK which is used in two different settings. In > particular, one may end using one key LK for two different cryptographic > algorithms. Are you sure that this is NOT possible? When an authentication mechanism generates a shared key as a side effect, it is generally for the purpose of protecting subsequent data exchanges with that key. When used in IPsec, it is likely that the subsequent data exchanges will be protected with IPsec, so the key will have no uses other than generating AUTH. That said, who knows what someone might do in the future. We could specify that using the key for anything else is forbidden. We could instead of using the key directly hash it with an IKE-related constant and use the result as the key. I'd be happy with either of these, though I believe that both are overkill. Do you have a concrete proposal for addressing this? Hugo Krawczyk wrote: > One other question raised in the appended note is when should the AUTH > field be sent. Seems to me that the simplest specification is to send it > in the last client's message in SLA. Even if this key (LK) is available > earlier, it does not buy you much to compute AUTH earlier (and you can > always keep the key for authentication at the end). An early > authentication using LK can only help against a DoS attack mounted by a > MitM attacker; however I doubt that anyone will choose this costly (for > the attacker) way to to mount a DoS attack. I didn't say the client's last message because for some legacy auth methods the exchange is variable length and the client doesn't know which of his messages will be the last until the server accepts it. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 21:06:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1256ho25879; Sat, 1 Feb 2003 21:06:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26485 Sat, 1 Feb 2003 23:42:18 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Modefg considered harmful To: Bernard Aboba Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 23:10:19 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/01/2003 11:44:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard Aboba wrote: > RFC 2131 states the responsibilities of DHCP Relays very clearly. The > primary responsibility is packet forwarding. I think you may be confusing > the operation of a DHCP Relay with a DHCP proxy -- which *is* ill-defined. OK... bear with me. I just reread RFC 2131 and still don't get it. When an IPsec gateway is acting as a DHCP Relay, I can almost see how it forwards the DHCP packets in a stateless fashion (it seems like it has to hold state between the request and response, but could be stateless the rest of the time). But there is a second function of the gateway that is intimately bound to address allocation. The IPsec gateway has to respond to ARPs to the assigned IP address and forward packets addressed to that IP address to the endnode. How does it know when to start and stop doing that? It can't just trust the endnode to tell it... that would allow someone connecting in to seize IP addresses belonging to someone else. It seems like it has to keep track of the interaction between the endnode and the DHCP server including keeping track of lease expiration and renewal. What am I missing? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 21:26:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h125Q1o26111; Sat, 1 Feb 2003 21:26:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26595 Sun, 2 Feb 2003 00:03:30 -0500 (EST) Date: Sat, 1 Feb 2003 19:54:30 -0800 (PST) From: Bernard Aboba To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, Subject: Re: Modefg considered harmful In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But there is a second function of the gateway that is > intimately bound to address allocation. The IPsec gateway has to respond to > ARPs to the assigned IP address and forward packets addressed to that IP > address to the endnode. So you're saying that the IPsec gateway *must* implement proxy ARP? Why wouldn't participation in the routing mesh be enough? For example, if the IPsec gateway is injecting routes for the addresses of the nodes it is handling (either an aggregated prefix or the host routes) wouldn't that work? The result will be that packets destined for those addresses will be forwarded to the IPsec gateway. > How does it know when to start and stop doing that? I think that is a function of how reachability is determined -- which is the same for either proposal, no? > It can't just trust the endnode to tell it... that would allow someone > connecting in to seize IP addresses belonging to someone else. As noted in RFC 3456: As described in [17], a number of issues arise when forwarding DHCP client requests from untrusted sources. These include DHCP exhaustion attacks, and spoofing of the client identifier option or client MAC address. These issues can be partially addressed through use of the DHCP Relay Information Option [17]. > like it has to keep track of the interaction between the endnode and the > DHCP server including keeping track of lease expiration and renewal. > > What am I missing? I think you're missing the DHCP Relay Information option [RFC3046], which enables the Relay to deal with these issues while remaining stateless. From owner-ipsec@lists.tislabs.com Sat Feb 1 21:26:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h125Q5o26123; Sat, 1 Feb 2003 21:26:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26601 Sun, 2 Feb 2003 00:04:31 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Modecfg and IPv6 To: Bernard Aboba Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Feb 2003 23:32:16 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/02/2003 12:06:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard Aboba wrote: > Maybe it's just me, but I don't understand the plan for support of IPv6 in > MODECFG. > I'm just the transcriber of MODECFG. I believe I understand what it says, but I don't know what special challenges are present with IPv6 that might cause problems. > So far, the available ways of getting an IPv6 address are static config, > RS/RA or DHCPv6. The former doesn't need MODECFG, and the latter two > mechanisms would ordinarily require a tunneling solution somewhat akin to > RFC 3456. > > But if MODECFG is used instead, it would be nice to understand how it's > supposed to work. Some questions: > > a. Does MODECFG assign a specific IPv6 address, as DHCPv6 can do? Or does > it provide only a prefix as in RS/RA? > Currently, the spec says that the host requests an IPv6 address and the IPsec gateway returns one. It provides the entire address, not a prefix. Is that a problem? > b. How would MODECFG handle the other functions of RS/RA, such as the "H" > bit for a MIPv6 HA? If MODECFG doesn't handle those functions, how much of > the IPv6 functionality do we lose? If it does handle them, do we end up > duplicating the RS/RA functionality in MODECFG? I don't believe MODECFG addresses these. If they are needed and transparent to IPsec, that would argue for tunnelling DHCP as you propose. If IPsec needs to know about them to set its forwarding tables, both protocols are in trouble. > > c. How does MODECFG handle both IPv4 and IPv6 configuration? Do we need > both IPv4 and IPv6 config support in MODECFG? Currently, the spec says that the host MUST request either an IPv4 or IPv6 address and MAY request both. Is that sufficient? > > d. Or is it assumed that MODECFG will only handle IPv4 address and config, > and that IPv6 will be handled by tunneling as in RFC 3456? If it is > already necessary to support tunneling of RS/RA and DHCPv6 in order to > support IPv6, why support MODECFG in addition? The reason to support MODECFG in addition (in my opinion) is to have a simple protocol for negotiating both an address lease and network access over that address. Without it, the minimum interaction to set up an ESP SA is *many* more messages... I don't even know how many. I would guess at least 12 vs. the current 6. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sat Feb 1 23:15:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h127F0o02059; Sat, 1 Feb 2003 23:15:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26895 Sun, 2 Feb 2003 01:48:52 -0500 (EST) Date: Sat, 1 Feb 2003 21:39:25 -0800 (PST) From: Bernard Aboba To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, Subject: Re: Modecfg and IPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Currently, the spec says that the host requests an IPv6 address and the > IPsec gateway returns one. It provides the entire address, not a prefix. > Is that a problem? It might be. What if the client wants to announce a prefix to its own network? If the client obtains a single IPv4 address, then it can use 6to4 and obtain a suitable IPv6 prefix to announce. So it seems reasonable to be able to obtain an IPv6 prefix for the same purpose, assuming that the negotiated selectors permit it. > I don't believe MODECFG addresses these. > If they are needed and transparent to IPsec, > that would argue for tunnelling DHCP as you propose. If IPsec needs to > know about them to set its forwarding tables, both protocols are in > trouble. Prefix assignment will definitely affect the routing table. If the gateway assigns a different prefix to each tunnel, then routing is fairly straightforward. This could be handled, for example, by assigning a /48 to the gateway -- then there are enough /64s for 65K tunnels. However, if the gateway obtains a single prefix, and tries to share this among multiple tunnels, then it will need to plumb host routes, not only for the clients, but also for the hosts behind the clients. This becomes complex. As for the effects of eliminating IPv6 RS/RA, I think we will need to think about this carefully, because this serves multiple purposes. Perhaps it might make sense to ask the question of the IPv6 WG chair Margaret Wasserman. > > c. How does MODECFG handle both IPv4 and IPv6 configuration? Do we need > > both IPv4 and IPv6 config support in MODECFG? > > Currently, the spec says that the host MUST request either an IPv4 or IPv6 > address and MAY request both. Is that sufficient? My question was more about configuration than addressing (which is discussed above). > The reason to support MODECFG in addition (in my opinion) is to have a > simple protocol for negotiating both an address lease and network access > over that address. I think we both agree that the issue is about address assignment, *not* configuration. If we're going to be creating a configuration scheme we hope to live with for a long time, it's probably best not to pick an approach that requires a disclaimer: "I wouldn't design it this way myself, but..." If one assumes that the IPsec gateway is assigned a prefix to allocate out of, over which it has complete control (as opposed to having to go to a DHCPv4 server for addresses), then I think that IPv4 address assignment via MODECFG can be made to work. In that case, there is no need for DHCP authentication, or address renewal (since the gateway is assumed to own the prefix it allocates out of in perpetuity). If those are the assumptions, it would be good to document them clearly. However, I have my doubts about whether this approach is sound for IPv6, or whether there aren't some unforseen effects (like affecting our ability to put a Home Agent and IPsec gateway on the same box). We've already learned recently that IKEv2 has some undesirable mobility properties (Francis Dupont and Jari Arkko are preparing mail on this), so some more thought is needed. From owner-ipsec@lists.tislabs.com Sun Feb 2 11:53:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h12Jrvo23611; Sun, 2 Feb 2003 11:53:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28187 Sun, 2 Feb 2003 14:18:36 -0500 (EST) 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: Sun, 2 Feb 2003 11:17:14 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Ciphersuites for IKEv2, revised Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:38 PM -0500 2/1/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I believe it would be more confusing than clarifying to >pretend that the algorithm negotiation is independent of >whether we're talking IKE, ESP, or AH. I fully agree with Charlie here. > >That said, I do think it would be a good idea to group >the IKE, ESP, and AH suites both in their numbering >ranges and as ordered in the specification. Would anyone >object to my changing Paul's numbers? I think it is a good idea as well. Go for it. However, please do *not* do anything that indicates that the private-use space has any such breakdown, since some of the private-use uses will do things that we probably don't expect (or want to know about...) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Feb 2 15:41:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h12Nfio28159; Sun, 2 Feb 2003 15:41:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28564 Sun, 2 Feb 2003 18:11:57 -0500 (EST) Message-Id: <200302022313.h12NDnaH011667@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Sat, 01 Feb 2003 19:54:30 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 02 Feb 2003 18:13:49 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bernard" == Bernard Aboba writes: >> But there is a second function of the gateway that is >> intimately bound to address allocation. The IPsec gateway has to respond to >> ARPs to the assigned IP address and forward packets addressed to that IP >> address to the endnode. Bernard> So you're saying that the IPsec gateway *must* implement proxy ARP? Why Bernard> wouldn't participation in the routing mesh be enough? For example, if the Bernard> IPsec gateway is injecting routes for the addresses of the nodes it is In the smallest sites, proxy-ARP is the way to go. In a medium size site, one may be able to arrange to statically route a block of addresses at the VPN gateway. (There being, otherwise, no "routing mesh") In a larger site, some kind of dynamic routing, perhaps injecting /32 routes (/128 routes) into OSPF or ISIS is the way to go. There is an issue with releasing of the proxy-ARP. I've personally experienced this problem, independantly of being auto-configured (I was statically at the same IP inside and out). The VPN gateway, once it sees an ARP reply for an IP that it is proxy-ARP'ing, needs to do some kind of keepalive with the client. If it turns out the client is dead, then it should drop this connection. This isn't very solid - but this is why many point out that having seperate address pools is a necessary. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPj2mK4qHRg3pndX9AQHfTwQArgjOZzhTdwVjFr5IpodMxa3GqPkZOnHy mj1CX0ZjHoMLqSV9aqPhZA90PIt+TBbqVjZrrXlXvctCiz9xw34k5rcwdIgTsAvT kANUA7aSYScMt9ykEhjdG+uoOrVElqJTRLaCQ+ecw7+gwKr1n8PRfOLX6olGssEp Hh0i2B/4Xg4= =au7e -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Feb 2 21:40:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h135evd08107; Sun, 2 Feb 2003 21:40:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29144 Mon, 3 Feb 2003 00:07:14 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Scott G. Kelly" Cc: Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 00:09:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E3AF6B3.8BFAE02D@bstormnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Scott G. Kelly > Sent: Friday, January 31, 2003 5:21 PM > To: ddukes@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Modefg considered harmful > > > Hi Darren, > > Darren Dukes wrote: > > > > I think any mature implementations that will be trying to use DHCP for > > complete configuration of the ipsec client (beyond network > addresses, as is > > possible with modecfg today) will need to implement their own > DHCP client > > and server in order to include their user-specific ipsec-VPN > configuration. > > So what we'll end up with is as follows. > > > > OS-DHCP-client(optional) <-> ipsec-DHCP-client SGW-DHCP-server > > > > Reusing the OS DHCP client (if possible at all) will not give enough > > flexibility. > > What ipsec-vpn configuration are you referring to? DHCP permits > configuration of (at least) the following: > > o IP address(es) > o Subnet mask(s) > o Broadcast address(es) > o Host name > o Domain name > o Time offset > o Servers (e.g., SMTP, POP, WWW, DNS/NIS, LPR, > syslog, WINS, NTP, etc. ) > o Router(s) > o Router discovery options > o Static routes > o MTU > o Default TTL > o Source routing options > o IP Forwarding enable/disable > o PMTU options > o ARP cache timeout > o X Windows options > o NIS options > o NetBIOS options > o Vendor-specific options > > DHCP is obvlivious to the presence of the VPN, and as far as I can tell, > it has never been the intent of either the ipsec or ipsra wg's to > provide vpn policy config, so I can't figure out what you might be > talking about. Something as basic as per-user or group subnets requiring protection; I have access to 3.4.5.0/255.255.255.0 but nobody else does. I can not see how this sort of thing could be supported by ipsec-DHCP, is it? Really it comes down to how extensible the tunnelled ipsec-DHCP is for IRACS. If there can be no per-user or group configuration of the IRAC then the people deploying IKEv2 VPNs will see a big step backward from their IKEv1/modecfg deployments today. Darren > > Scott From owner-ipsec@lists.tislabs.com Sun Feb 2 23:37:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h137bMd18688; Sun, 2 Feb 2003 23:37:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA29404 Mon, 3 Feb 2003 02:10:37 -0500 (EST) Reply-To: From: "Darren Dukes" To: , "Bernard Aboba" Cc: , Subject: RE: Modecfg and IPv6 Date: Mon, 3 Feb 2003 02:13:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Charlie_Kaufman@notesdev.ibm.com > > Bernard Aboba wrote: > > Maybe it's just me, but I don't understand the plan for support of IPv6 > in > > MODECFG. > > > I'm just the transcriber of MODECFG. I believe I understand what it says, > but I don't know what special challenges are present with IPv6 that might > cause problems. > > > So far, the available ways of getting an IPv6 address are static config, > > RS/RA or DHCPv6. The former doesn't need MODECFG, and the latter two > > mechanisms would ordinarily require a tunneling solution > somewhat akin to > > RFC 3456. The idea is that MODECFG will work the same for v6 as v4. It will be used to assign an address, and optionally the other attributes defined, to the IRAC. I have very limited understanding of RS/RA and DHCPv6, but I think RA's _should_ be handled as any other host would, and DHCPv6 INFORMATION-REQUEST could be used for additional DHCPv6 options. > > > > But if MODECFG is used instead, it would be nice to understand how it's > > supposed to work. Some questions: > > > > a. Does MODECFG assign a specific IPv6 address, as DHCPv6 can > do? Or does > > it provide only a prefix as in RS/RA? > > > Currently, the spec says that the host requests an IPv6 address and the > IPsec gateway returns one. It provides the entire address, not a prefix. > Is that a problem? > > > b. How would MODECFG handle the other functions of RS/RA, such > as the "H" > > bit for a MIPv6 HA? If MODECFG doesn't handle those functions, how much > of > > the IPv6 functionality do we lose? If it does handle them, do we end up > > duplicating the RS/RA functionality in MODECFG? As I said above, I know little about the specifics of RS/RA, but I don't think we'll be loosing anything since an IRAC _should_ be receiving and processing RAs (H-bit included) as any other node would be once an address is assigned to it and it's created Child-SA(s). Can anyone confirm this? > > I don't believe MODECFG addresses these. > If they are needed and transparent to IPsec, > that would argue for tunnelling DHCP as you propose. If IPsec needs to > know about them to set its forwarding tables, both protocols are in > trouble. > > > > > c. How does MODECFG handle both IPv4 and IPv6 configuration? Do we need > > both IPv4 and IPv6 config support in MODECFG? > > Currently, the spec says that the host MUST request either an IPv4 or IPv6 > address and MAY request both. Is that sufficient? > > > > > d. Or is it assumed that MODECFG will only handle IPv4 address and > config, > > and that IPv6 will be handled by tunneling as in RFC 3456? If it is > > already necessary to support tunneling of RS/RA and DHCPv6 in order to > > support IPv6, why support MODECFG in addition? > > The reason to support MODECFG in addition (in my opinion) is to have a > simple > protocol for negotiating both an address lease and network access > over that > address. Without it, the minimum interaction to set up an ESP SA is *many* > more messages... I don't even know how many. I would guess at least 12 vs. > the current 6. > > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > From owner-ipsec@lists.tislabs.com Mon Feb 3 00:47:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h138lRd01301; Mon, 3 Feb 2003 00:47:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29604 Mon, 3 Feb 2003 03:19:29 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F0C@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Bernard Aboba'" Cc: "'Cheryl Madson'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 09:16:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: vrijdag 31 januari 2003 16:10 To: Van Aken Dirk Cc: 'Cheryl Madson'; ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful > I cannot answer for the future and extensibility. What I do know is that > ModeCfg is almost identical to PPP-IPCP (RFC1332, RFC1877) in functionality: > it supports a bare minimum on IP parameters. RFC 1877 has been heavily criticized over the years (see James Carlson's PPP book), and the island of address state that it created has proven to be a headache. >> I've read this book and I'm confronted with the consequences. On the Wide Area side of DSL routers we implement PPP over ATM and PPP over Ethernet. On the LAN (Ethernet side) we use DHCP and we have to come up with complex constructs to get the PPP negotiated parameters via PPP-DHCP-Proxy constructs into the PC's on the LAN. It is a perfect example of how to link two totally different state machines with different feature sets together. ModeCfg & DHCP is the same story but then the solution is called ModeCfg-DHCP-Proxy. >> Also, it became apparent that the set of parameters defined in RFC 1877 was not enough -- and that attempting to duplicate all the DHCP options was not fruitful. So PPP peers such as Windows 2000 and XP had to add support for DHCP anyway! >> BroadBand Remote Access server manufactures don't come up with this kind of solutions. They continue the path of PPP-IPCP but then with "private" extensions. As an example, there is a private PPP-IPCP option to negotiate a subnet. The goal is to have these addresses on the LAN side. So I must populate a DHCP pool of my local DHCP server with this subnet and serve the PC on the Ethernet segment from this pool. If the PPP link goes down, then these addresses are no longer valid etc ... And last but not least, brand A encodes this PPP-IPCP option in an IP address/length format and brand B does it via address/mask format. Two times development and testing from my side .. Same will happen with ModeCfg ... >> Given what we have learned from history, it makes little sense to continue on with this approach, particularly with IPv6, where there are a well defined set of address and configuration mechanisms for all types of interfaces. From owner-ipsec@lists.tislabs.com Mon Feb 3 00:47:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h138lSd01317; Mon, 3 Feb 2003 00:47:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29613 Mon, 3 Feb 2003 03:22:29 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5583FB40@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Cheryl Madson'" Cc: "'Bernard Aboba'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 09:24:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Cheryl, You wrote: Well, some of us take the view that this is still really part of IKE, just in a roundabout way (e.g. this whole "special short-lived tunnel" stuff). >> I have difficulties in understanding what is against short-lived tunnels. Isn't this is one of the reasons of existence of IKE i.e. a protocol that can easily create and destroy tunnels ? >> Best regards - Dirk From owner-ipsec@lists.tislabs.com Mon Feb 3 02:33:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13AXDd14349; Mon, 3 Feb 2003 02:33:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29939 Mon, 3 Feb 2003 05:05:44 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F0F@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , Bernard Aboba , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 11:07:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, See my comments below. > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: vrijdag 31 januari 2003 21:59 > To: Bernard Aboba; ipsec@lists.tislabs.com > Subject: RE: Modefg considered harmful > > > Bernard you made me read a lot of specs today, something I > should have done > weeks ago. I am no DHCP expert, in fact I haven't looked at > RFC2131 for > years (until today). I wonder if you were familiar with DHCP years ago that we would still have this discussion on ModeCfg ;-) ... Hopefully I've retained enough from > them to make sense > to you, I know someone (probably many) will tell me if I don't. > > I agree with some of what you write but ipsec-DHCP suffers > from some of the > same problems as you suggest IKECFG suffers from, plus others. > > "Basic Configuration" > A definite problem for IKECFG but I do think it can be > overcome with > DHCPINFORM, 5.6.4 of RFC3118 allows the DHCP server to accept > authenticated > or unauthenticated DHCPINFORM and may reply with authenticated or > unauthenticated DHCPINFORM. Besides if the ipsec client has > a shared key > for local DHCP use he can reuse that key for the DHCPINFORM since K = > MAC(MK, opaque unique-id). > > ipsec-DHCP suffers from the opposite problem. It does not > contain the > rich configuration options that vendors have added to IKECFG. > While many > _are_ vendor-specific the ability to move them to DHCP servers and the > OS-specific-DHCP implementation in ipsec clients is no > trivial matter and > will likely result in a non-standardized way of distributing non-DHCP, > per-user VPN configuration. You might have a look at the Vendor Option class in RFC2131. BTW, IKECfg supports 6 options that are specific to IPv4; 6 options are duplicated for IPv6 and there 3 general options. So for IPv4 I have in total 9 options which is clearly infuficient compared to DHCP. All other options are vendor specific implying that each vendor implements these in its own format/syntax. If I don't create devices at both ends on the tunnel, how am I going to solve this and how do I avoid interoperabilty problems ? Best regards - Dirk From owner-ipsec@lists.tislabs.com Mon Feb 3 03:15:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13BFRd15275; Mon, 3 Feb 2003 03:15:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00040 Mon, 3 Feb 2003 05:48:51 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F10@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , Michael Richardson , ipsec@lists.tislabs.com Cc: "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 11:51:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, Have you thought about following situation ? RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN Following parameters are configured on the SmallIPSecGW: - LAN port (connected to the remote office Ethernetsegment): 20.0.0.254/24 - DHCP Relay: enabled on this LAN port; giaddr= 20.0.0.254; DHCP Server= 30.0.0.1 - IPSec policy: protect 30.0.0.0/24 and IKE peer= Large IPSecGW or - IPSec policy: protect 0.0.0.0/0 and IKE peer= Large IPSecGW A PC is booting on the RemoteOfficeLAN, its broadcast DHCP requests arrive in the SmallIPSecGW and are converted via the DHCP relay into unicast DHCP request. Subsequently these request hit IPSec policy 30.0.0.0/24 or 0.0.0.0/0 and are tunneled to the remote LargeIPSecGW. The LargeIPSecGW processes these DHCP request as ordinary unicast packets; all that is needed is policy rules. The DHCP server picks an IP address based on giaddr or more advanced criteria. Actually from the moment that the DHCP Relay makes the broadcast/unicast conversion everything is "standard" IPSec. Packets follow routes and obey policy rules; no IKECFG nor IPSec-DHCP specific functionality required. Appart from configuring policy rules there are no new skill that must be learned by the network administrator because in the CentralOfficeLAN he uses these same techniques to manage his/her network. If Remote Access VPN users are based on RFC3456 I have a DHCP solution for my complete network infrastructure more specific: - my centreal office LAN - my remote office VPN's - my remote access VPN users. In case of Remote Access VPN users based on IKECfg I have to train my network admin for this special case and address pools are located in two devices: the DHCP server and the Large VPNGW. Best regards - Dirk > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: vrijdag 31 januari 2003 22:19 > To: Michael Richardson; ipsec@lists.tislabs.com > Cc: Scott G. Kelly > Subject: RE: Modefg considered harmful > > > I think any mature implementations that will be trying to use DHCP for > complete configuration of the ipsec client (beyond network > addresses, as is > possible with modecfg today) will need to implement their own > DHCP client > and server in order to include their user-specific ipsec-VPN > configuration. > So what we'll end up with is as follows. > > OS-DHCP-client(optional) <-> ipsec-DHCP-client > SGW-DHCP-server > > Reusing the OS DHCP client (if possible at all) will not give enough > flexibility. > > Darren > From owner-ipsec@lists.tislabs.com Mon Feb 3 03:39:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Bd1d15713; Mon, 3 Feb 2003 03:39:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00117 Mon, 3 Feb 2003 06:06:39 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F11@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Charlie_Kaufman@notesdev.ibm.com'" , Bernard Aboba Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 12:08:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie, See my comments below. > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: zondag 2 februari 2003 2:25 > To: Bernard Aboba > Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: Re: Modefg considered harmful > > > > > > > While my personal interests are in settling the MODECFG vs DHCP-relay > debate in any way that sticks, I can't resist throwing in my technical > opinion. > > The appeal of MODECFG is that it minimizes the number of messages and > crypto operations in getting an IPsec session set up. The appeal of > DHCP-relay is that it provides all of the flexibility and > power of DHCP > (including extensions defined in the future) and does so in a way that > appears to make it independent of the IKE specification. But > I believe this > appearance is illusory. > > For an endnode to acquire an IP address on a remote network > for use with > IPsec, there are several things going on - only one of which > involves DHCP. > Yes, the address must be leased, but in addition the IPsec gateway > implementation has to begin responding to ARPs to that address and > forwarding packets addressed to that address over the IPsec > tunnel. The fact that an IPSecGW must respond to ARP's just depend on you addressing scheme. e.g. If your central LAN uses 30.0.0.0/24 and you use let's say 30.0.0.100-120 for your VPN RAS users your IPSecGW must do Proxy-ARP for 30.0.0.[100-120]. Because your Central LAN servers cannot know whether these addresses are local or extruded via a VPN GW. And indeed some IKECfg implementations have a check box next to the IKCfg-range that one defines. However I consider this as a configuration optimization. On the other hand if your VPN configuration and central office is large, you have a dedicated subnet for your VPN users. e.g. Your central office users are on the 30.0.0.0/24 network and your VPN your users on the 40.0.0.0/24 network. The routeing infrastructure on the central LAN has route entries for this extruded network, pointing to the IPSec GW. Could we at least keep these arguments out of the discussion; they might just confuse the audience. What I would like to hear is, is IKECFG better compared to RFC3456 ? Best regards - Dirk > The IPsec gateway should only accept packets over the IPsec > tunnel with source > address equal to one that the endnode has legitimately > leased. That means > the gateway can't be a passive relay. It has to parse the > messages it is > passing through, and if there are extensions to DHCP in the > future that > affect leases on IP addresses, the gateways will have to be updated to > understand them. I believe this is what Cheryl Madson > referred to as "a > special state" in the state machine. > > So I would claim that the IPsec endnode, the IPsec gateway, > and the DHCP > server are running a three party protocol, and it's not > obvious whether > it's better to have the IPsec gateway eavesdrop on the DHCP > conversation or > be a full participant by acting as a DHCP server to the endnode and a > client to the DHCP server. As a practical matter, MODECFG > specifies exactly > what the two participants have to do, while DHCP-relay is more open to > interpretation. Unless DHCP-relay were specified more > precisely in terms of > what the IPsec gateway had to do with the information it saw > passing by, it > seems likely that MODECFG would give us better > interoperability. And if > IPsec gateway actions in response of DHCP messages were specified more > precisely, I believe that proposal would lose must of its > extensibility. > > The use of MODECFG does not preclude the use of tunnelled > DHCP for uses > other than acquiring leases on IP addresses. If I were designing the > protocol, I'd have IKE handle *only* IP address leases > (defining the life > of the lease to match the life of the SA), and use tunnelled > DHCP for all > other functions (like getting DNS server addresses). Adding a few more > fields to MODECFG enhances performance - probably in a > trivial way - but > it's likely that doing so will result in requests for more in > the future > (which we can either accept or decline). I could be convinced > either way. > > In summary, I believe MODECFG as specified will work and will > provide few > interoperability surprises. I believe DHCP-relay could be > made to work if > it were more tightly specified, but would be more likely to provide > interoperability problems. DHCP-relay does provide some > functionality not > possible with MODECFG - in particular assignment of IP > addresses based on > additional information about the client. If any of that > functionality is > actually needed, it could be added to MODECFG, but I haven't > heard a case > for it yet. > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > From owner-ipsec@lists.tislabs.com Mon Feb 3 04:39:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Cdld18886; Mon, 3 Feb 2003 04:39:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00403 Mon, 3 Feb 2003 07:11:05 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F12@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Charlie_Kaufman@notesdev.ibm.com'" , Bernard Aboba Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Mon, 3 Feb 2003 13:13:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: zondag 2 februari 2003 5:10 > To: Bernard Aboba > Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com > Subject: Re: Modefg considered harmful > > > > > > > Bernard Aboba wrote: > > RFC 2131 states the responsibilities of DHCP Relays very > clearly. The > > primary responsibility is packet forwarding. I think you > may be confusing > > the operation of a DHCP Relay with a DHCP proxy -- which *is* > ill-defined. > > OK... bear with me. I just reread RFC 2131 and still don't get it. > > When an IPsec gateway is acting as a DHCP Relay, I can almost > see how it > forwards the DHCP packets in a stateless fashion (it seems > like it has to > hold state between the request and response, but could be > stateless the > rest of the time). But there is a second function of the > gateway that is > intimately bound to address allocation. The IPsec gateway has > to respond to > ARPs to the assigned IP address and forward packets addressed > to that IP > address to the endnode. How does it know when to start and > stop doing that? Charlie, I don't see the problem with ARP's ... In case of an extruded range (that is an address range within the same subnet as your central office LAN's but assigned to VPN RAS users), each time IKECfg assigns an address to a VPN RAS user, it automatically adds an ARP entry in its Proxy-ARP table. True it is nice optimization however as soon as you are working with extruded networks this technique no longer works. In case you would use RFC3456 in combination with an extruded range you just configure Proxy-Arp for that range in the IPec GW. Packets addressed to that destination end-up in the VPN GW and are either dropped there (if the address is not in use) or are forwarded in a tunnel.. > It can't just trust the endnode to tell it... that would allow someone > connecting in to seize IP addresses belonging to someone > else. Why not via Phase2 ID's ? If an SA has not yet expired and the address is assigned to another VPN client, clean-up the old SA for that address. > It seemslike it has to keep track of the interaction between the > endnode and the > DHCP server including keeping track of lease expiration and renewal. > > What am I missing? > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > From owner-ipsec@lists.tislabs.com Mon Feb 3 05:44:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Di0d23928; Mon, 3 Feb 2003 05:44:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00555 Mon, 3 Feb 2003 08:15:46 -0500 (EST) Date: Mon, 3 Feb 2003 04:06:34 -0800 (PST) From: Bernard Aboba To: Van Aken Dirk cc: "'Cheryl Madson'" , Subject: RE: Modefg considered harmful In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F0C@TMM_EDGMSMSG01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > ModeCfg & DHCP is the same story but then the solution is called > ModeCfg-DHCP-Proxy. You are right about the implications -- and that the architecture would be simpler if only one mechanism were used. > BroadBand Remote Access server manufactures don't come up with this kind of > solutions. They continue the path of PPP-IPCP but then with "private" > extensions. Indeed. So we will end up with interoperability headaches, too. > Two times development and testing from my side .. Yup. I've been there too :) > Given what we have learned from history, it makes little sense to > continue on with this approach, particularly with IPv6, where there are > a well defined set of address and configuration mechanisms for all types > of interfaces. I'd agree. From owner-ipsec@lists.tislabs.com Mon Feb 3 05:44:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Di2d23942; Mon, 3 Feb 2003 05:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00530 Mon, 3 Feb 2003 08:12:43 -0500 (EST) Date: Mon, 3 Feb 2003 04:03:22 -0800 (PST) From: Bernard Aboba To: Darren Dukes cc: Charlie_Kaufman@notesdev.ibm.com, , Subject: RE: Modecfg and IPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The idea is that MODECFG will work the same for v6 as v4. It will be used > to assign an address, and optionally the other attributes defined, to the > IRAC. I have very limited understanding of RS/RA and DHCPv6, but I think > RA's _should_ be handled as any other host would, and DHCPv6 > INFORMATION-REQUEST could be used for additional DHCPv6 options. The problem is that the IPv6 and IPv4 addressing architectures are quite different. > As I said above, I know little about the specifics of RS/RA, but I don't > think we'll be loosing anything since an IRAC _should_ be receiving and > processing RAs (H-bit included) as any other node would be once an address > is assigned to it and it's created Child-SA(s). Can anyone confirm this? I think there are some implications to having the client obtain addresses in two ways -- multiple addresses from the RS/RA assigned prefixes, one from MODECFG. For example, I don't think that this process will be faster -- because you'll be unable to do optimistic DAD on the MODECFG assigned address. And if the RS/RA assigned prefix is the same as the prefix for the MODECFG assigned address, then it is possible for there to be conflicts between the two approaches -- and it is not clear to me how they are resolved. So some careful thinking is probably required to understand the implications of this. From owner-ipsec@lists.tislabs.com Mon Feb 3 05:45:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13DjId23973; Mon, 3 Feb 2003 05:45:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00575 Mon, 3 Feb 2003 08:19:51 -0500 (EST) Date: Mon, 3 Feb 2003 04:10:57 -0800 (PST) From: Bernard Aboba To: Van Aken Dirk cc: "'ddukes@cisco.com'" , Subject: RE: Modefg considered harmful In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F0F@TMM_EDGMSMSG01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > "Basic Configuration" > A definite problem for IKECFG but I do think it can be > overcome with DHCPINFORM. Sure. So why include configuration in MODECFG in the first place? > ipsec-DHCP suffers from the opposite problem. It does not > contain the rich configuration options that vendors have added to > IKECFG. > > You might have a look at the Vendor Option class in RFC2131. Sounds like an obvious solution. From owner-ipsec@lists.tislabs.com Mon Feb 3 06:51:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Epbd25422; Mon, 3 Feb 2003 06:51:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00817 Mon, 3 Feb 2003 09:22:05 -0500 (EST) Message-ID: <3E3E3644.6020006@sun.com> Date: Mon, 03 Feb 2003 10:28:36 +0100 From: Marcel de Bont Reply-To: Marcel.deBont@sun.com Organization: Sun Microsystems Nederland BV User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSEC and performance impact Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi guys, can anybody give me ball park figures regarding the performance impact of IPSEC on Solaris 9. Any input is welcome, thanks in advance, -- Kind regards/Met vriendelijke groeten, Marcel de Bont -------------------------------------------- Sr. Technical Account Manager Mobile & Telco Sun Microsystems Nederland B.V. Saturnus 1 3824 ME Amersfoort the Netherlands Tel: +31 (0)33 451 6817 Fax: +31 (0)33 451 5001 GSM: +31 (0)6 5178 4337 e-mail: Marcel.deBont@Sun.COM visit us at http://www.sun.nl -------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Feb 3 06:51:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Epdd25436; Mon, 3 Feb 2003 06:51:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00827 Mon, 3 Feb 2003 09:23:14 -0500 (EST) X-Originating-IP: [64.230.113.69] From: "Andrew Krywaniuk" To: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: some comments on ikev2 04 Date: Sat, 01 Feb 2003 15:53:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2003 20:53:46.0275 (UTC) FILETIME=[03541F30:01C2CA34] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >(7) Security considerations: > >- can you explain to me what is the meaning of the first paragraph. >In what sense is the entropy of the DH consumed? (what is this entropy >anyway?) Maybe you want to say that using the same phase 1 with many >non-DH phase 2's compromises the PFS property of the protocol. I always hated that text as well, as it doesn't make any sense. About a year ago, I proposed the following alternate text: "Repeated re-keying using Phase 2 without PFS will increase the amount of data that will be exposed if the Diffie-Hellman key is ever compromised. Rekeying without PFS could also aid an attacker in cryptanalysing encrypted ESP data if a weakness in the PRF algorithm is ever discovered." Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Mon Feb 3 06:52:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Eqtd25477; Mon, 3 Feb 2003 06:52:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00803 Mon, 3 Feb 2003 09:21:05 -0500 (EST) Message-Id: <200302030739.QAA02514@toshiba.co.jp> To: ipsec@lists.tislabs.com Subject: IKEv2 lack of prf input encoding spec Date: Mon, 03 Feb 2003 16:39:48 +0900 From: Fukumoto Atsushi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ikev2-04 does not specify the encoding of g^ir shared secrets (neither did previous IKE spec). My guess is, "g^ir as prf input MUST be encoded as a network-order (big-endian) byte string whose length is equal to the byte length of MODP modulo or EC2N field." Unless it is very obvious to everybody besides me, I think you need to elaborate, else it seems ambiguous especially when the MSB of g^ir happen to be zero. FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec@lists.tislabs.com Mon Feb 3 07:48:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Fmjd27979; Mon, 3 Feb 2003 07:48:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01159 Mon, 3 Feb 2003 10:17:43 -0500 (EST) Message-Id: <200302031518.h13FIvof057374@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 In-reply-to: Your message of Thu, 30 Jan 2003 17:57:09 EST. Date: Mon, 03 Feb 2003 16:18:57 +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: For this reason, what we propose is that we pick an approach, and be done with it. The question then before the working group is whether or not there is another way to accomplish the task, but whether there are either (a) fatal flaws in the proposal presented, (b) clear, overwhelming advantages to do things a different way (and no handwaving; it must be a complete proposal), or (c) minor enhancements that all can agree are worthwhile to include in the protocol and worthwhile to implement. Otherwise we will be arguing until the cows come home (and/or when the IESG shuts us down, or the mob from problem-statement mailing list show up with the pitchforks, tar, and feathers :-). (SEMI-)CLOSED ISSUES ===================== The following issues have been burbling on the list, although in the opinion of the IPSEC Working group chairs, there isn't consensus in the IPSEC working group to act on them. If you feel otherwise, please speak now. A) Revised identity -------------------- => I am afraid that either we have to include a large part of draft-ietf-ipsec-pki-profile-xx.txt draft, or to adopt this revised identity proposal. IMHO this is between (a) and (b). B) DHCP-based vs. MODECFG style remote access configuration ----------------------------------------------------------- => IMHO IKE should not be involved directly into address allocation... I propose to ask the IPSRA WG to remove if they'd like any relevant part from IKEv2 (they should already have strong opinions and they should like the idea to remove something from an IPsec WG proposal :-). This is between (b) and (c). If there are those who feel otherwise, or who see fatal problems with the current approach, please speak now. => the NAT-DETECTION-*-IP notifications were cut&paste from a draft for IKEv1 and should be fixed. Fortunately this is easy and we can extend the fix to a proper address management in IKEv2. I'd like that the proposal of draft-dupont-ikev2-addrmgmt-00.txt is included in the next IKEv2: all the section 3 at the exception of the subsection 3.5 which is a real change and perhaps needs more discussion. BTW I have a minor point: my proposed "peer address update" notification relies on a strong sequencing of IKE messages. The current draft has only a weak sequencing (weak because the message ID, aka the sequence number, is not protected), I don't know if this is a global problem, i.e., if the replay of old messages with a fresh message ID can be used for real attacks... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Feb 3 08:02:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13G2id29888; Mon, 3 Feb 2003 08:02:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01263 Mon, 3 Feb 2003 10:35:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <011201c2ca16$776404d0$5803a8c0@trlhpc1> References: <011201c2ca16$776404d0$5803a8c0@trlhpc1> Date: Mon, 3 Feb 2003 10:36:57 -0500 To: "Jayant Shukla" From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:22 AM -0800 2/1/03, Jayant Shukla wrote: > > -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com] >> On Behalf Of Stephen Kent >> >> although I agree it improves the situation. Dedicated >> hardware devices usually do not have the OS services present to shut >> off, so they are better off. > >I am not sure I really understand. Once you have switched off services, >what is the difference? You agree that it improves security and then you >say hardware is better. Can you tell me attacks that are OS specific and >not related to a service? > >> I think we see more of this flavor in >> modern firewall products as well, so I think there is a parallel >> evolution path here. >> > >Which modern hardware firewalls? Newest thing in security is to solve >the intrusion problem and weed out Trojans. A recent test has shown that >hardware based systems performed miserably. Is this a function of the hardware performance, which is the focus of the thread, or the algorithms being used? >There are a lot of things you can do in software to catch detect >intrusions and catch Trojans, that you can never do by using a >standalone hardware. Nonesense. The line between what is programmable and what is hardware has been moving for 30 years, and will continue. The fact that your company happens to sell products based on general purpose computing platforms seems to be unduly influencing your comments. > > >There is a lot more to practical security than FIPS level 3. Maybe >your >> >box is fine, but a Trojan can have a field day with the computers >behind >> >your box. >> >> Yes, but it's not the fault of the box, which is the focus of this >> discussion. >> > >In my very first e-mail, I _very_ clearly stated that software based >systems will have an advantage in detecting Trojans. And therefore may >have an advantage in overall security. As I said above, this is nonsense. The issue you are raising revolves around what algorithms are run to detect whatever we're looking for, not whether these algorithms are executed in a general purpose OS context, or in a dedicated realtime OS context with lots of hardware assist for pattern matching. >If you did not agree to that statement and wanted to talk only about the >security of VPN box, you could have mentioned it a lot earlier. I don't recall your clearly articulating what sort of security was the focus of your comments, and from the messages others have sent, I think this lack of clarity is not merely a problem with my perception of your comments. > >> Since the comment applies to just the security of the IPsec device, >> not the computers behind it, I think it is fair to say that a >> dedicated, hardware implementation of IPsec has the potential to be >> considerably more secure than an implementation that runs on a >> general purpose computer with a general purpose OS, even if one >> attempts to harden the OS by turning off extraneous services. > >The reason for my original response was that a general perception has >been created that hardware is more secure than software. Maybe (a real >maybe), VPN hardware is more secure than software based VPN, but somehow >that gets generalized to overall security. IMHO that is not correct. > >Here is a good example of hardware relying on software to improve >security.... > >Several leading VPN hardware vendors are working with those who >specialize in host-based security to ensure that the host configurations >have not been altered to infect the host with a virus/Trojan. These >secure VPN boxes were serving as a conduit to spread viruses and Trojans >and wreaking havoc on corporate security. There are lots of means by which malicious code can be introduced into a host. Transit via an IPsec SA is one choice, but so is transit via an SSL connection, an S-MIME e-mail attachment, etc. The issue is where the secure communication path is terminated, and this where it can be examined for malicious code. The use of hardware or software devices along the path is immaterial to the fundamental issue here. >To summarize, security based on your lowly desktop OS is looking good. >It provides an excellent platform to integrate security function to >improve ease of configuration, management, event correlation, protection >against internal attacks, Trojan & intrusion detection and is a better >solution for overall security. Not to mention that it is much more >economical. >Performance is excellent as well. Not really. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 08:22:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13GMTd02443; Mon, 3 Feb 2003 08:22:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01318 Mon, 3 Feb 2003 10:57:25 -0500 (EST) Message-Id: <4.3.2.7.2.20030203073615.02aa5270@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Feb 2003 07:41:38 -0800 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: WG Last Call draft-ietf-ipsec-dpd-01.txt Cc: "Geoffrey Huang" , tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments for the draft-ietf-ipsec-dpd-01.txt draft, for progression to Informational RFC. This last call will expire in one week on Februrary 10. thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Mon Feb 3 10:22:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13IM3d06446; Mon, 3 Feb 2003 10:22:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01633 Mon, 3 Feb 2003 12:50:15 -0500 (EST) Message-ID: <3E3EABEB.4F20A25@bstormnetworks.com> Date: Mon, 03 Feb 2003 09:50:35 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, Darren Dukes wrote: > > DHCP is obvlivious to the presence of the VPN, and as far as I can tell, > > it has never been the intent of either the ipsec or ipsra wg's to > > provide vpn policy config, so I can't figure out what you might be > > talking about. > > Something as basic as per-user or group subnets requiring protection; I have > access to 3.4.5.0/255.255.255.0 but nobody else does. I can not see how > this sort of thing could be supported by ipsec-DHCP, is it? Really it comes > down to how extensible the tunnelled ipsec-DHCP is for IRACS. If there can > be no per-user or group configuration of the IRAC then the people deploying > IKEv2 VPNs will see a big step backward from their IKEv1/modecfg deployments > today. If I'm not misunderstanding you, it sounds like you want to configure IRAC policy - is this correct? If so, this was strictly off-limits to us in IPSRA, and was said to be in the domain of the IPSP wg, and so it was not considered in the ipsra requirements rfc. If you don't intend to use this to configure policy, please give an example of how you would use this. Thanks, Scott From owner-ipsec@lists.tislabs.com Mon Feb 3 10:56:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Iugd08560; Mon, 3 Feb 2003 10:56:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01742 Mon, 3 Feb 2003 13:27:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 3 Feb 2003 13:24:06 -0500 To: Charlie_Kaufman@notesdev.ibm.com From: Stephen Kent Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:58 PM -0500 2/1/03, Charlie_Kaufman@notesdev.ibm.com wrote: >Stephen Kent wrote on 01/31/2003 06:31:45 PM: >> It is likely that IANA will add additional Suite-IDs in the future, and >> some users may want to use private suites, especially for IKE where >> implementations should be capable of supporting different parameters, >> up to certain size limits. In support of this goal, all >> implementations of IKEv2 SHOULD [I'd prefer MUST, but Paul has argued >> eloquently for very restrictive criteria for MUST re suites.] include >> a management facility that allows specification (by a user or system >> administrator) of Diffie-Hellman parameters (the generator, modulus, >> and exponent lengths and values) for new IKE Suites. Implementations >> SHOULD provide a management interface via which these parameters and >> the associated Suite-IDs may be entered (by a user or system >> administrator), to enable negotiating such Suites. > >I would strongly oppose making this a "MUST" and have mixed feelings >about "SHOULD". If we are going to include it, I think we have to say >what the size limits are, and whether all intermediate sizes SHOULD >be supported. We had such a debate over RSA key sizes, without >concrete resolution. The current draft says 1024 and 2048 bit keys >MUST be supported and doesn't say anything about SHOULD. There >exist implementations of crypto toolkits that don't support RSA >keys that are not an integer multiple of 16 bits in size. Very >general requirements make conformance testing harder. > > --Charlie > Charlie, My goal in pushing for this is NOT to require any implementation to support a bigger key size, but rather to allow specification of parameters within whatever constraints we established separately for parameters sizes. I'm very much open to rewording suggestions to avoid any confusion over this aspect of my proposed text. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 10:56:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Iuhd08566; Mon, 3 Feb 2003 10:56:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01732 Mon, 3 Feb 2003 13:26:14 -0500 (EST) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Some doubts on latest IKEv2 draft Date: Mon, 3 Feb 2003 13:27:37 -0500 Message-ID: Thread-Topic: Some doubts on latest IKEv2 draft Thread-Index: AcLLse1hSKiMrQc/SKWi7RBOlqlo6w== To: X-OriginalArrivalTime: 03 Feb 2003 18:27:38.0515 (UTC) FILETIME=[EE299E30:01C2CBB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA01729 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies if this has already been discussed before.... For some of us following the mailing list closely on a daily basis is a luxury we can not afford. I have tried to read several threads of the last month or so. I could find some answers, shall need confirmation on those and answers to some unanswered ones. * Initially the only way of authentication was signatures, then shared secrets were added. Still authentication method was not negotiated, as both end points can be doing different authentication. The question is then how does the other side know of the authentication method being used by this side? The answer I found was that it shall be known by the key type which can be indicated in the Certificate payload. For different types of signatures it makes sense and Cert payload needs to be a MUST then. If Cert payload is not there, does the other side assume that authentication method is shared secret? * For CREATE_CHILD_SA exchange (Section 3.3), it is mentioned: "The message past the header is encrypted and the message including the header is integrity protected using the cryptographic algorithm negotiated in Phase 1." But I do not see mention of any AUTH payload in the CREATE_CHILD_SA exchange messages. * In the initial exchange the 3rd message, the initiator can optionally send IDr, the responders's identity. How does the initiator come to know of the responder's identity when it was not conveyed to the initiator in the second message? (Or is it derived from the remote entity initiator tries to communicate with, which in turn triggers IKE negotiation and hence IDr can be generated by the initiator) Rationale behind IDr in message 3 was explained in version 3, but is not there in the latest document. The question how IDr would be gotten would still be a valid one. It will be good if some explanation on this is provided. * Somebody has mentioned this already that while IKEv1 had a separate section on notation and terminology, it is missing from IKEv2, which can be disconcerting while reading the document. Thanks, Atul Disclaimer: Opinions expressed here are not those of my employer (And as Charlie says not even mine by the time you read it.) From owner-ipsec@lists.tislabs.com Mon Feb 3 10:56:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Iujd08582; Mon, 3 Feb 2003 10:56:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01726 Mon, 3 Feb 2003 13:22:57 -0500 (EST) From: "Jayant Shukla" To: "'Stephen Kent'" Cc: Subject: RE: new to VPN Date: Mon, 3 Feb 2003 10:23:30 -0800 Message-ID: <014001c2cbb1$5add55e0$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Stephen Kent > Sent: Monday, February 03, 2003 7:37 AM > To: Jayant Shukla > Cc: ipsec@lists.tislabs.com > Subject: RE: new to VPN > > > > >Which modern hardware firewalls? Newest thing in security is to solve > >the intrusion problem and weed out Trojans. A recent test has shown that > >hardware based systems performed miserably. > > Is this a function of the hardware performance, which is the focus of > the thread, or the algorithms being used? > Please read the original e-mail by Alan and allow me to quote: "Is it true that the hardware VPN solutions are always better, trusted and have higher secure level than software VPN?" > >There are a lot of things you can do in software to catch detect > >intrusions and catch Trojans, that you can never do by using a > >standalone hardware. > > Nonesense. The line between what is programmable and what is hardware > has been moving for 30 years, and will continue. The fact that your > company happens to sell products based on general purpose computing > platforms seems to be unduly influencing your comments. > That's enough! Rudeness and personal attacks are not the way to conduct a discussion on a public forum. Since you brought up the issue of our product......it is doing rather well. Check the top 100 downloads at Tucows to see for yourself. http://www.tucows.com/toppicks.html > > I don't recall your clearly articulating what sort of security was > the focus of your comments, and from the messages others have sent, I > think this lack of clarity is not merely a problem with my perception > of your comments. > Please allow me to quote again from my first e-mail: " > > Is it true that the hardware VPN solutions are always better, > > trusted and have higher secure level than software VPN? > On the contrary, I think software solutions are becoming more secure than the hardware solutions. If you look at technologies related to intrusion prevention or known/unknown Trojan detection, the software solutions have a much better edge. " Based on the way you respond, say incorrect things, and the fact that you are simply not open to other people's point of views, I am not interested in having any more discussions with you. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Mon Feb 3 11:36:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JaEd09849; Mon, 3 Feb 2003 11:36:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01884 Mon, 3 Feb 2003 14:05:41 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4.3.2.7.2.20030203073615.02aa5270@mira-sjc5-4.cisco.com> References: <4.3.2.7.2.20030203073615.02aa5270@mira-sjc5-4.cisco.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: Mon, 3 Feb 2003 11:08:24 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: WG Last Call draft-ietf-ipsec-dpd-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:41 AM -0800 2/3/03, Barbara Fraser wrote: >This is a working group last call for comments for the >draft-ietf-ipsec-dpd-01.txt draft, for progression to Informational >RFC. Why is this meant to be an Informational RFC? It is an actual protocol. It should be on standards track. If the reason for making this an Informational RFC is because it changes IKEv1, will we also be able to get XAUTH and MODECFG (two actual protocols that are widely deployed) published as Informational RFCs as well? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 3 11:51:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JpCd10168; Mon, 3 Feb 2003 11:51:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01964 Mon, 3 Feb 2003 14:23:26 -0500 (EST) Date: Mon, 3 Feb 2003 10:35:56 -0800 Message-Id: <200302031835.h13IZtn16232@localhost.localdomain> From: John Lindal X-Mailer: Arrow 2.0b3 (X11; Linux 2.4.2-2; i686) To: Subject: RE: new to VPN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>Several leading VPN hardware vendors are working with those who >>specialize in host-based security to ensure that the host configurations >>have not been altered to infect the host with a virus/Trojan. These >>secure VPN boxes were serving as a conduit to spread viruses and Trojans >>and wreaking havoc on corporate security. > > There are lots of means by which malicious code can be introduced into a > host. Transit via an IPsec SA is one choice, but so is transit via an SSL > connection, an S-MIME e-mail attachment, etc. The issue is where the > secure communication path is terminated, and this where it can be > examined for malicious code. The use of hardware or software devices > along the path is immaterial to the fundamental issue here. You've hit the nail on the head. I think the misunderstanding in this discussion stems from the fact that all commercial hardware implementations are gateway based. When somebody asks about "hardware vs software," as in the post that started this thread, they are actually asking the question of "gateway-based vs. end-to-end." As you implied, end-to-end security is far superior to gateway-based solutions. In fact, I've noticed many companies have started to falsely advertise end-to-end security these days in order to jump on the bandwagon which we at Trlokom helped get rolling :) -- Sincerely, John Lindal Chief Software Architect, Trlokom, Inc. http://www.trlokom.com/ From owner-ipsec@lists.tislabs.com Mon Feb 3 11:53:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JrVd10247; Mon, 3 Feb 2003 11:53:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01963 Mon, 3 Feb 2003 14:23:26 -0500 (EST) Date: Mon, 3 Feb 2003 10:35:53 -0800 Message-Id: <200302031835.h13IZqn16228@localhost.localdomain> From: John Lindal X-Mailer: Arrow 2.0b3 (X11; Linux 2.4.2-2; i686) To: Subject: RE: new to VPN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There's a very large difference between a general purpose OS like > Windows or Unix, and an embedded system OS. Large, as in several > orders of magnitude. Unless I'm missing something fundamental, comparing the raw sizes of various operating systems is misleading. Assuming that the VPN software is installed at the bottom of the network stack, just above the NIC driver, then it doesn't matter how big the rest of the OS is. The only thing that matters is the tiny little bit of the OS that takes the packet off the NIC and hands it to the VPN driver. Of course, this small part of the OS must not have any holes, the VPN software must not have any holes, and the security policies must be set correctly to weed out malicious or unwanted packets! ----- Somebody also brought up the issue of key security in hardware vs software implementations. Given the above scenario of a correctly implemented VPN driver as close to the NIC as possible, one can only steal keys if one has physical access to the device. When this happens, it seems to me that neither hardware not software will deter a determined attacker, though it is harder to break into a device that doesn't have a keyboard :) Of course, if one uses certificates and a centralized management system, then it is trivial to revoke a certificate if a computer is stolen or otherwise compromised. Just don't try this trick with pre-shared text keys :) Add in user level authentication for road warriors, and it becomes highly unlikely that anybody will be able to break into the rest of the network before the certificate is revoked (assuming that employees conscientiously report stolen laptops, of course!). -- Sincerely, John Lindal Chief Software Architect, Trlokom, Inc. http://www.trlokom.com/ From owner-ipsec@lists.tislabs.com Mon Feb 3 11:55:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JtYd10290; Mon, 3 Feb 2003 11:55:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01970 Mon, 3 Feb 2003 14:26:26 -0500 (EST) Date: Mon, 03 Feb 2003 19:29:52 +0000 From: 96985283 Subject: CREATE_CHILD_SA exchange with PFS To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Message-id: <3E3EE3F3@webmail> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: 96985283 X-EXP32-SerialNo: 00003610 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie thanks for your explanations. I tried to summaries you mail: >The current spec does not allow a second D-H exchange for the child SA set >up in the initial IKE exchange. The first initial IKE exchange (4 messages) and the CREATE_CHILD_SA with PFS (2 new messages) is not allowed to come direct after the first initial IKE exchange. Therefore I need to piggyback the child SA on the first initial IKE and use the following KEYMAT = prf+(SK_d, Ni | Nr). The first initial IKE exchange is always 4 messages long. KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) is only used for CREATE_CHILD_SA establishment with PFS at later stage in the IKE exchange and never direct after the first initial IKE exchange (4 messages). >This was to simplify the specification and >because I believe there is never any security advantage in doing so. The >purpose of subsequent D-H exchanges is to assure that even someone who has >broken into the endpoints and copied all keying material cannot in a >passive attack decrypt the data encrypted under keys derived using the >second D-H exchange. But this advantage only applies if a nontrivial >period of time elapses between the two exchanges (because protection >Is only gained if the break in occurs between the two exchanges). CREATE_CHILD_SA IKE with PFS direct after the initial IKE does not add more protection to the IKE exchange at all. Thanks for the help, Burkhard From owner-ipsec@lists.tislabs.com Mon Feb 3 13:00:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13L02d11773; Mon, 3 Feb 2003 13:00:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02221 Mon, 3 Feb 2003 15:26:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <014001c2cbb1$5add55e0$5803a8c0@trlhpc1> References: <014001c2cbb1$5add55e0$5803a8c0@trlhpc1> Date: Mon, 3 Feb 2003 15:08:26 -0500 To: "Jayant Shukla" From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:23 AM -0800 2/3/03, Jayant Shukla wrote: > > -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com] >> On Behalf Of Stephen Kent >> Sent: Monday, February 03, 2003 7:37 AM >> To: Jayant Shukla >> Cc: ipsec@lists.tislabs.com >> Subject: RE: new to VPN >> >> > >> >Which modern hardware firewalls? Newest thing in security is to solve >> >the intrusion problem and weed out Trojans. A recent test has shown >that >> >hardware based systems performed miserably. >> >> Is this a function of the hardware performance, which is the focus of >> the thread, or the algorithms being used? >> > >Please read the original e-mail by Alan and allow me to quote: > >"Is it true that the hardware VPN solutions are always better, trusted >and have higher secure level than software VPN?" Yes, that text sounds familiar. I, and others, interpreted this to mean that the question had to do with the security of an implementation of VPN technology, since Alan asked about hardware vs. software for VPNs. He did not ask about VPNs that incorporate IDS functionality vs. ones that do not. > > >There are a lot of things you can do in software to catch detect >> >intrusions and catch Trojans, that you can never do by using a >> >standalone hardware. >> >> Nonesense. The line between what is programmable and what is hardware >> has been moving for 30 years, and will continue. The fact that your >> company happens to sell products based on general purpose computing >> platforms seems to be unduly influencing your comments. >> > >That's enough! Rudeness and personal attacks are not the way to conduct >a discussion on a public forum. I was giving you the benefit of the doubt, assuming that you were smart enough to understand that this was nonsense and that it was some form of corporate loyalty that forced you to make a silly statement of that sort. If you insist otherwise ... > >Since you brought up the issue of our product......it is doing rather >well. Check the top 100 downloads at Tucows to see for yourself. > >http://www.tucows.com/toppicks.html And McDonalds is highly rated by consumers of its products, which says so much about the nutritional value of those products. > > I don't recall your clearly articulating what sort of security was > > the focus of your comments, and from the messages others have sent, I >> think this lack of clarity is not merely a problem with my perception >> of your comments. >> > >Please allow me to quote again from my first e-mail: > >" >> > Is it true that the hardware VPN solutions are always better, >> > trusted and have higher secure level than software VPN? >> > >On the contrary, I think software solutions are becoming more secure >than the hardware solutions. If you look at technologies related to >intrusion prevention or known/unknown Trojan detection, the software >solutions have a much better edge. >" > >Based on the way you respond, say incorrect things, and the fact that >you are simply not open to other people's point of views, I am not >interested in having any more discussions with you. I respond very negatively to nonsense statement by vendors in the context of an IETF WG. Your statement fall into that category. It's not a matter of being open to "other people's point[sic] of views. What we have been discussing ys largely a matter of fact, not of value judgements. I applaud your decision to not continue the discussion. It will avoid wasting the time of WG members. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 13:05:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13L5hd11933; Mon, 3 Feb 2003 13:05:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02248 Mon, 3 Feb 2003 15:39:45 -0500 (EST) Message-Id: <200302032041.h13KffGB008685@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Mon, 03 Feb 2003 11:51:13 +0100." <421CB3B9B2D2F645B548D213C0A90E55090F10@TMM_EDGMSMSG01> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Feb 2003 15:41:41 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Van" == Van Aken Dirk writes: Van> Have you thought about following situation ? Van> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN Van> Following parameters are configured on the SmallIPSecGW: This is out of scope. SmallIPsecGW should run a DHCP relay, and tunnel the packets through the VPN to the CentralOfficeLAN's DHCP server. The only "difficulty" is that the IP addresses provided to the RemoteOfficeLAN will need to either fit into the existing tunnel that SmallIPsecGW has, or that SmallIPsecGW should have a somewhat "wide" policy for all communication from RemoteOfficeLAN<->CentralOfficeLAN, and use per-host keying to create new LANs. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPj7UAoqHRg3pndX9AQH8lgP/ReFXm9Www9hi+RJaB94lnecr+r+PIi68 wvHHFepa2dpt/a8buGQelNV0+FDhr4D4+ogkpUwwpAmLFSByuvPe0CURp43p9zWP Vh7CqwZfGkzSp5Ab03hzFmG8UkC446Pg0FNx+qsxzqkt8TelM3tMSLG+iZMG5oza 2/FvdBI+tck= =TXIU -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Feb 3 13:05:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13L5hd11938; Mon, 3 Feb 2003 13:05:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02254 Mon, 3 Feb 2003 15:40:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200302031835.h13IZqn16228@localhost.localdomain> References: <200302031835.h13IZqn16228@localhost.localdomain> Date: Mon, 3 Feb 2003 15:22:02 -0500 To: John Lindal From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:35 AM -0800 2/3/03, John Lindal wrote: > > There's a very large difference between a general purpose OS like >> Windows or Unix, and an embedded system OS. Large, as in several >> orders of magnitude. > >Unless I'm missing something fundamental, comparing the raw sizes of >various operating systems is misleading. Assuming that the VPN software is >installed at the bottom of the network stack, just above the NIC driver, >then it doesn't matter how big the rest of the OS is. The only thing that >matters is the tiny little bit of the OS that takes the packet off the NIC >and hands it to the VPN driver. > >Of course, this small part of the OS must not have any holes, the VPN >software must not have any holes, and the security policies must be set >correctly to weed out malicious or unwanted packets! I'm afraid you are missing something. Irrespectivbe of where the VPN software is installed in a general purpose platform/OS environment, that software can be subverted by a successful attack against any part of the rest of the OS. Your comment suggests that if the VPN access controls are working, then no evil packets can evade detection and thus be used to attack the higher layer software. We have lots of experience that indiactes otherwise. >----- > >Somebody also brought up the issue of key security in hardware vs software >implementations. Given the above scenario of a correctly implemented VPN >driver as close to the NIC as possible, one can only steal keys if one has >physical access to the device. When this happens, it seems to me that >neither hardware not software will deter a determined attacker, though it >is harder to break into a device that doesn't have a keyboard :) One can steal keys that are protected by software if an attacker gains control of the device via any means, period. This includes any form of remote attack, not just local, physical attacks. In contrast, a FIPS level 3/4 device is tested to be immune to extraction of plaintext keys, even in the face of most physical attacks. >Of course, if one uses certificates and a centralized management system, >then it is trivial to revoke a certificate if a computer is stolen or >otherwise compromised. Just don't try this trick with pre-shared text keys :) If one knows the keys have been compromised revocation is a solution. For pre-shared keys, in a client-sever context (which seems to be the primary context you and your colleague are addressing), revocation is also easy re a client compromise, since only the enterprise (server) needs to know of the revocation. Again, a level 3 device provides evidence of tampering to extract keys (level 4 should prevent such extraction) which then provides a trigger to revoke certs. >Add in user level authentication for road warriors, and it becomes highly >unlikely that anybody will be able to break into the rest of the network >before the certificate is revoked (assuming that employees conscientiously >report stolen laptops, of course!). This last comment is based on the assumption that only a detected, physical attack could extract keys. This is not true in general, and in the case of a laptop, copying of the contents of the (presumably encrypted) keys from the hard drive could be effected without theft of the laptop, and without leaving evidence of the extraction. Then one can proceed to offline recovery of the keys, which have probably been encrypted via a password. I agree that this specific scenario is not the most common one to worry about, unless road warriors are working in contexts where this sort of black bag job is a concern. Nonetheless, I think the example illustrates why reliance on revocation is less attractive than reliance on hardware to protect keys in the first place. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 13:29:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13LTXd12881; Mon, 3 Feb 2003 13:29:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02349 Mon, 3 Feb 2003 16:02:24 -0500 (EST) Message-ID: From: Roger Younglove To: "'Paul Hoffman / VPNC'" , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: RE: Ciphersuites MUSTs and SHOULDs Date: Mon, 3 Feb 2003 15:50:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01C2CB9C.0DF7B730" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C2CB9C.0DF7B730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the original design of IPSec, I believe in our desire to provide choices for the end user we created a nightmare. The adoption of multi-vendor IPSec has been delayed in implementation for that reason. We need to think from the end user's viewpoint. Technically what Ted says is correct however from an end user's viewpoint if they can not upgrade their currently operating equipment we are not going to see the benefits of IKEv2 implemented until existing equipment is phased out. This will only increase product non interoperatibility and more resentment to IPSec. My vote is to keep the original wording to allow the updating of currently deployed systems. Roger Younglove, CISSP Principal Consultant NetWorks Group O. 810.225.4800 ex. 2245 M. 810.599.0879 E. ryounglove@networksgroup.com www.networksgroup.com -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Friday, January 31, 2003 1:16 PM To: Theodore Ts'o; ipsec@lists.tislabs.com Subject: Ciphersuites MUSTs and SHOULDs Wearing his WG chair hat, Ted said: >I have adjusted the MUST/SHOULD from Paul's message since I believe that >for implementations that will be moving to implement IKEv2, it is >reasonable to require the implementation of AES, as it as so many >advantages over 3DES. The current proposal contains not only a list of MUSTs and SHOULDs, it has language that is supposed to go into the document about them. The counter-proposal doesn't change the support language. The counter-proposal offers no security or interoperability rationale. For example, the counter-proposal mandates both 3DES and AES. How does that help interoperability or security? Ted's proposal (which is certainly not based on any consensus from the mailing list) essentially prevents any currently-deployed IPsec system that has 3DES-acceleration from running IKEv2 sensibly. The vendor would have to offer AES in software next to 3DES in hardware, and hopefully explain to the user what the difference is. Is this what the WG wants? Or would the WG prefer a set of MUSTs and SHOULDs that allow vendors to update currently-deployed systems with IKEv2? --Paul Hoffman, Director --VPN Consortium ------=_NextPart_000_0014_01C2CB9C.0DF7B730 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJAzCCApIw ggH7oAMCAQICAwjjxzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMTIxMTIxNTcxM1oXDTAzMTIxMTIxNTcxM1owTjEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjErMCkGCSqGSIb3DQEJARYccnlvdW5nbG92ZUBuZXR3b3Jrc2dyb3Vw LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1CxcbirqW5c4Q41wmMd0qDJgspTob8JM Rriq2ucdRiCpOfv/LHoPDkfedIWEM+2CQp5PA266HZEximgGxW4dLnqT2zlj8/Kg16kmOMlB7eFa XABF/Qk8xLDFkCdoeIi2Vx6lc7utovXsNvjQtWIjU0FRAUvrNxr/0mo1yiv409UCAwEAAaM5MDcw JwYDVR0RBCAwHoEccnlvdW5nbG92ZUBuZXR3b3Jrc2dyb3VwLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBALnmmzwLC6lvLcqxUOWGASevTn7OZOIwMsMYPjFJ2gIRrB4jdvDkuKT/ XzX5sjskz2aLdjyfozS1oYVyFAm6f0NbyLyxlBm0gw5UKUMIi9U5WEBu8oWB3/SRcTxjDUNpGM7M AHyoK87epB4fAnKfoE2yqh7pES9vMJWKuGl2o1rgMIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0B AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAw MDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNV BAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3Rl LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0N j3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZe rerAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEw DwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBY Yawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa /RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgwggKh oAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3Rl IENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTlaMIGS MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x DzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMT H1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjx w0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SK E4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0B AQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo4 91BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvK PPZE6iZph39Ins6ln+eE2MliYq0FxjGCA2kwggNlAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls IFJTQSAyMDAwLjguMzACAwjjxzAJBgUrDgMCGgUAoIICJDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMDMyMDUxMDJaMCMGCSqGSIb3DQEJBDEWBBTOJfXOWi3u 5cRXGPyv7PBUqt2rNDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu MzACAwjjxzCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCOPHMA0GCSqGSIb3DQEBAQUABIGApV5CWTtx6vMLeKViJwjshzwjcnAlxFCb21fL g+p4W4RQyHP85ch5fq2FzQgJac2bzTx/uYIHnjc73DfV3bgBrIuNWCLeJCpCk2XfcaLCaAvUFMro m+VoJZQh/zZnQA1cQDJ0aUe5bxrcb2DXAAaQZLrkFBiKKEUACOOA3mJIuXMAAAAAAAA= ------=_NextPart_000_0014_01C2CB9C.0DF7B730-- From owner-ipsec@lists.tislabs.com Mon Feb 3 13:32:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13LW2d12945; Mon, 3 Feb 2003 13:32:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02363 Mon, 3 Feb 2003 16:04:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200302031835.h13IZtn16232@localhost.localdomain> References: <200302031835.h13IZtn16232@localhost.localdomain> Date: Mon, 3 Feb 2003 16:06:57 -0500 To: John Lindal From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:35 AM -0800 2/3/03, John Lindal wrote: > >>Several leading VPN hardware vendors are working with those who >>>specialize in host-based security to ensure that the host configurations >>>have not been altered to infect the host with a virus/Trojan. These >>>secure VPN boxes were serving as a conduit to spread viruses and Trojans >>>and wreaking havoc on corporate security. >> >> There are lots of means by which malicious code can be introduced into a >> host. Transit via an IPsec SA is one choice, but so is transit via an SSL >> connection, an S-MIME e-mail attachment, etc. The issue is where the >> secure communication path is terminated, and this where it can be >> examined for malicious code. The use of hardware or software devices >> along the path is immaterial to the fundamental issue here. > >You've hit the nail on the head. > >I think the misunderstanding in this discussion stems from the fact that >all commercial hardware implementations are gateway based. When somebody >asks about "hardware vs software," as in the post that started this thread, >they are actually asking the question of "gateway-based vs. end-to-end." > >As you implied, end-to-end security is far superior to gateway-based >solutions. In fact, I've noticed many companies have started to falsely >advertise end-to-end security these days in order to jump on the bandwagon >which we at Trlokom helped get rolling :) > I thought some vendors have offered individual host IPsec products in the past, e.g., IPsec on a NIC products. But maybe I misremembered. We certainly agree that in many instances it is preferable to maintain an SA all the way to the target host, vs. terminating it at a security gateway. But, this is not always true; it depends on the perceived threat. As for bandwagon jumping, I'll just note that BBN built the first end-to-end packet net encryption devices for DARPA in the mid-1970s. They were placed in front of individual hosts, used a KDC for key management, and no, they didn't use a general purpose OS. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 14:21:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13MLAd14498; Mon, 3 Feb 2003 14:21:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02587 Mon, 3 Feb 2003 16:54:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 3 Feb 2003 16:55:30 -0500 To: Bernard Aboba From: Stephen Kent Subject: Re: Modefg considered harmful Cc: ipsec@lists.tislabs.com, Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:54 PM -0800 2/1/03, Bernard Aboba wrote: > > But there is a second function of the gateway that is >> intimately bound to address allocation. The IPsec gateway has to respond to >> ARPs to the assigned IP address and forward packets addressed to that IP >> address to the endnode. > >So you're saying that the IPsec gateway *must* implement proxy ARP? Why >wouldn't participation in the routing mesh be enough? For example, if the >IPsec gateway is injecting routes for the addresses of the nodes it is >handling (either an aggregated prefix or the host routes) wouldn't that >work? The result will be that packets destined for those addresses will be >forwarded to the IPsec gateway. > Bernard, When one starts moving into this realm of routing functionality, there are serious security concerns that IPsec has not yet fully addressed. In 2401bis, we plan on de-coupling route selection from SA selection, by having an explicit lookup for routing performed prior to SA selection, and then passing along a virtual interface ID as part of the SA selection process. This is something that was discussed among a set of folks interested in PPVPN and overlay nets over the last several months. If adopted, this would make it easier to accommodate the sort of full-fledged routing participation that you allude to. However, another problem arises here, i.e., how do we know what portions of address space a given IPsec gateway is authorized to advertise. If the gateway represents a leaf for routing purposes, then this may be successfully managed manually, and with the current binding of SA selection and routing, I assume this is what has been done. But there are folks who have a good reason to want to separate these two functions, and if we start having IPsec gateways executing BGP, I worry that we do not have adequate means to verify the authorization aspect of routes. The infrastructure developed for S-BGP (a pet project of mine) would supply the necessary info, but it has not been deployed so far. At a minimum we should address the question in our documents, even if we don't have an agreed-upon solution. Steve From owner-ipsec@lists.tislabs.com Mon Feb 3 14:52:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Mqbd15148; Mon, 3 Feb 2003 14:52:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02677 Mon, 3 Feb 2003 17:28:24 -0500 (EST) Message-ID: <3E3EED3E.1C14BEB9@bstormnetworks.com> Date: Mon, 03 Feb 2003 14:29:18 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Cheryl Madson CC: Paul Hoffman / VPNC , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: Revised identity, again References: <4.3.2.7.2.20030131133640.07ea33e0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yeah - what Cheryl said. Scott Cheryl Madson wrote: > > At 10:17 AM 1/31/2003, Paul Hoffman / VPNC wrote: > > >This paragraph means that the many years of on-and-off discussion about > >the lack of clarity of IKEv1 with respect to what does an ID payload mean > >when using certificates is now ignored. The fact that there is vastly less > >interoperability for certificate authentication than for preshared secret > >authentication (or even XAUTH authentication!) is now irrelevant. > > > >According to the WG chairs, IKEv2 should use the same under-specified and > >non-specified rules for certificate processing as IKEv1. > > > >Is this what the working group wants? > > I've gone through *numerous* bakeoffs where vendors have implemented > different behaviors for various things related to certs. We've had several > meetings during bakeoffs to discuss this particular issue. Even if the > vendors are able to come to some sort of consensus during the bakeoff, > the WG has been extremely apathetic about any attempts to clarify things. > > I argued that one of the requirements should be that any authentication > mechanism be fully specified in the context of SOI, or not be a candidate > mechanism. A series of random specs that someone has to figure out > how to piece together isn't an answer. [I also argued that the protocol > specification be flexible enough to allow future mechanisms.] > > And I for one would sure hate to see certs excluded as a mechanism; > I do think it is an extremely useful mechanism. > > But I'm also really tired of having to revisit the same issues years later > because we can't take the time to figure out in some detail what needs > to happen and to adequately specify things. > > thx - C > > ==================================== > Cheryl Madson > Core IP Engineering; Security and Services > Cisco Systems, Inc. > cmadson@cisco.com From owner-ipsec@lists.tislabs.com Mon Feb 3 15:33:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13NXVd16118; Mon, 3 Feb 2003 15:33:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02793 Mon, 3 Feb 2003 18:07:28 -0500 (EST) Message-ID: <3E3EF653.78216797@bstormnetworks.com> Date: Mon, 03 Feb 2003 15:08:03 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: <200302032041.h13KffGB008685@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Van" == Van Aken Dirk writes: > Van> Have you thought about following situation ? > > Van> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN > > Van> Following parameters are configured on the SmallIPSecGW: > > This is out of scope. Why is this out of scope? This is a common remote access scenario for deployments utilizing personal sgw's at the remote end. > SmallIPsecGW should run a DHCP relay, and tunnel the packets through the > VPN to the CentralOfficeLAN's DHCP server. Yes, a la RFC3456. This is one of the remote access applications which makes the dhcp approach so attractive. Scott From owner-ipsec@lists.tislabs.com Mon Feb 3 16:03:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1403Kd16741; Mon, 3 Feb 2003 16:03:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02894 Mon, 3 Feb 2003 18:38:32 -0500 (EST) Message-Id: <200302032340.h13NeNsh023983@marajade.sandelman.ottawa.on.ca> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Mon, 03 Feb 2003 15:08:03 PST." <3E3EF653.78216797@bstormnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Feb 2003 18:40:22 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> Michael Richardson wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> >>>>> "Van" == Van Aken Dirk writes: Van> Have you thought about following situation ? >> Van> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN >> Van> Following parameters are configured on the SmallIPSecGW: >> >> This is out of scope. Scott> Why is this out of scope? This is a common remote access scenario for Scott> deployments utilizing personal sgw's at the remote end. Because a) it is solveable already using existing specifications. b) it has nothing to do with configuring an IPsec client. It is about configuring clients that are behind IPsec gateways. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPj795IqHRg3pndX9AQE2EwP+PLW/0KqhC2v2KFGKvKB4/yOwGASsf1HW EJyWtb0kUuUGLArnJQmDxMVNxe56BJxLKKEolUyLi1Qpo/EhoV4wAIfTX9FGAt9C 3h2/9WcPTZvJaGxPxdrgr8RUA+6GMAvFBNLdoUyjl7UybLWgJRT+wacebmw3UsO+ UU3IgiU6NW4= =vPqE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Feb 3 16:06:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1406gd16795; Mon, 3 Feb 2003 16:06:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02910 Mon, 3 Feb 2003 18:43:51 -0500 (EST) Date: Mon, 3 Feb 2003 16:47:57 -0700 Message-Id: <200302032347.h13NlvE04106@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec@lists.tislabs.com In-reply-to: Yourmessage <4.3.2.7.2.20030203073615.02aa5270@mira-sjc5-4.cisco.com> Subject: Re: WG Last Call draft-ietf-ipsec-dpd-01.txt Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The draft has a number of non-ascii characters. There was once a good statement on the mailing list about why keep-alives were important, but this draft doesn't have such a thing. What important advantage accrues from keep-alives? They allow state to be removed more aggressively and efficiently than methods without keep-alives? Alos, there is mention of a "mitigation" of the need for timers, but one still needs them, it seems. There should be some context about where the SPI and associated parameters come from. It's a little difficult to grok these things exist until one gets to the message formats. There's a statement early on that there will be comparison between methods based on IPSec SA's and IKE SA's, but the promise is not kept, as nearly as I can see. There's a statement that "unencrypted" data must be rejected. How does one make a determination that the data has been encrypted? From a security viewpoint, it seems more important that a message authentication code be validated than that encryption be applied. There is no mention of what should be done if the peer doesn't respond. Is the RUTHERE sent again? How fast, how many times before making a deadness decision? Suppose A decides B is dead, but B does not agree. A will start a new "session" and choose a new sequence number. B might continue using the previous "session". If A refuses to respond, B might eventually conclude that A is dead and start a new session. How do they resynchronize? Suppose B decides to optimize by pre-computing its responses and sends them prior to A's requests, using a timer. Is there any harm? There's an obscure covert channel introduced by this mechanism. If A sends IPSec traffic to B and E corrupts that traffic, B will consider A unresponsive and send a keep-alive. That lets E distinguish between successful and unsuccessful corruption. Security considerations should address how long a session can be used with the sequence number scheme. What it be feasible, for example, to have a one millisecond "worry interval"? Hilarie From owner-ipsec@lists.tislabs.com Mon Feb 3 16:36:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h140a7d17603; Mon, 3 Feb 2003 16:36:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03034 Mon, 3 Feb 2003 19:11:25 -0500 (EST) Date: Mon, 3 Feb 2003 14:41:23 -0800 Message-Id: <200302032241.h13MfMn17917@localhost.localdomain> From: John Lindal X-Mailer: Arrow 2.0b3 (X11; Linux 2.4.2-2; i686) To: Subject: RE: new to VPN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> > There's a very large difference between a general purpose OS like >>> Windows or Unix, and an embedded system OS. Large, as in several >>> orders of magnitude. >> >>Unless I'm missing something fundamental, comparing the raw sizes of >>various operating systems is misleading. Assuming that the VPN software is >>installed at the bottom of the network stack, just above the NIC driver, >>then it doesn't matter how big the rest of the OS is. The only thing that >>matters is the tiny little bit of the OS that takes the packet off the NIC >>and hands it to the VPN driver. >> >>Of course, this small part of the OS must not have any holes, the VPN >>software must not have any holes, and the security policies must be set >>correctly to weed out malicious or unwanted packets! > > I'm afraid you are missing something. Irrespectivbe of where the VPN > software is installed in a general purpose platform/OS environment, > that software can be subverted by a successful attack against any > part of the rest of the OS. How can one attack the rest of the OS if the VPN component is located at the only entry point and doesn't allow malicious packets to pass? > Your comment suggests that if the VPN access controls are working, then > no evil packets can evade detection and thus be used to attack the higher > layer software. We have lots of experience that indiactes otherwise. I think it's a matter of definitions. In any situation where malicious packets get through the VPN filter, I would say that the access controls are not working correctly :) -- Sincerely, John Lindal Chief Software Architect, Trlokom, Inc. http://www.trlokom.com/ From owner-ipsec@lists.tislabs.com Tue Feb 4 02:25:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14APHd27558; Tue, 4 Feb 2003 02:25:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04266 Tue, 4 Feb 2003 04:53:00 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F13@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Tue, 4 Feb 2003 10:55:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: maandag 3 februari 2003 21:42 > To: ipsec@lists.tislabs.com > Subject: Re: Modefg considered harmful > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Van" == Van Aken Dirk writes: > Van> Have you thought about following situation ? > > Van> > RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN > > Van> Following parameters are configured on the SmallIPSecGW: > > This is out of scope. Hi Michael, The configuration I described above was created in our labs with two very simple (and old) IPSec gateways not supporting any dynamic IP parameter assignment method. So if I have to choose between configuring remote PC's connected to these gateways manually or automatically, I sure know what to choose. Whether it is out of scope, I leave in the middle because I know too little of the history of the IPSec working group. The point I wanted to make is that in complex environments you will find a mix of IPSec GW's: - old IPSec GW's with very little features; - new ones with the latest feature set; - IPSec GW's connecting VPN RAS users and VPN GW's connecting remote offices. If a system administrator can at least have a uniform IP parameter distribution method over his whole network (including his central office LAN ;-) ), he would be very happy ! With IKEModeCfg this is clearly not the case but with DHCP based methods it can be accomplished and that's my main motivation for the RFC3456 based method. The focal point of the IPSec working group is to create good standards for IPSec but sometimes I have the impression that the fact that IPSec devices must be integrated in a larger infrastructure is sometimes overlooked. I hope that I do not offend anybody with this statement, I just express my personal feeling on this point. > > SmallIPsecGW should run a DHCP relay, and tunnel the > packets through the > VPN to the CentralOfficeLAN's DHCP server. > > The only "difficulty" is that the IP addresses provided to the > RemoteOfficeLAN will need to either fit into the existing tunnel that > SmallIPsecGW has This is only logical: the remote office network, the prefix pointing to this network and the IPSec policy are identical. , or that SmallIPsecGW should have a somewhat > "wide" policy > for all communication from RemoteOfficeLAN<->CentralOfficeLAN, and use > per-host keying to create new LANs. > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, > security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPj7UAoqHRg3pndX9AQH8lgP/ReFXm9Www9hi+RJaB94lnecr+r+PIi68 > wvHHFepa2dpt/a8buGQelNV0+FDhr4D4+ogkpUwwpAmLFSByuvPe0CURp43p9zWP > Vh7CqwZfGkzSp5Ab03hzFmG8UkC446Pg0FNx+qsxzqkt8TelM3tMSLG+iZMG5oza > 2/FvdBI+tck= > =TXIU > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Tue Feb 4 06:20:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14EK0d11642; Tue, 4 Feb 2003 06:20:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05047 Tue, 4 Feb 2003 08:42:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030203173807.02162d28@mira-sjc5-9.cisco.com> X-Sender: bora@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Feb 2003 17:41:42 -0800 To: Stephen Kent From: Bora Akyol Subject: Re: Modefg considered harmful Cc: ipsec@lists.tislabs.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:55 PM 2/3/2003 -0500, Stephen Kent wrote: >In 2401bis, we plan on de-coupling route selection from SA selection, by >having an explicit lookup for routing performed prior to SA selection, and >then passing along a virtual interface ID as part of the SA selection >process. This is something that was discussed among a set of folks >interested in PPVPN and overlay nets over the last several months. If >adopted, this would make it easier to accommodate the sort of full-fledged >routing participation that you allude to. I fear that this is straying from the scope of the ipsec working group to something much larger. As you point out there is no infra-structure in the Internet to verify that either a route or its advertiser are authentic. Specification of a virtual interface ID is implementation specific. I want to understand more of the concern here. Is the concern that ipsec SAs are being used to route traffic or due to the uncontrolled routing, some packets that should be secured are going in the clear due to the wrong interface selection? Can you please elaborate the reasoning behind this concern and verbiage? Thanks Bora From owner-ipsec@lists.tislabs.com Tue Feb 4 08:11:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14GBjd14959; Tue, 4 Feb 2003 08:11:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05424 Tue, 4 Feb 2003 10:33:16 -0500 (EST) Message-ID: <3E3FDDDD.4040108@cefriel.it> Date: Tue, 04 Feb 2003 16:35:57 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [IPsec and remote access] Security Policy Configuration Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posting-Agent: Hamster/2.0.0.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, RFC 3457 states that there are 5 basic categories of requirements relevant to secure remote access scenarios: - Endpoint Authentication ; - Remote Host Configuration ; - Security Policy Configuration ; - Auditing ; - Intermediary Traversal ; However while, we've long discussed about Endpoint Authentication (SLA&IKEv2), Remote Host Configuration (RFC3456 or CP), Intermediary traversal (NA(P)T traversing), I beleave we left out the Security Policy Configuration. From RFC 3457: "Security policy configuration refers to IPsec access policies for both the remote access client and the security gateway. It may be desirable to configure access policies on connecting IRAC systems which will protect the target network. For example, since a client has access to the Internet (via its routable address), other systems on the Internet also have some level of reciprocal access to the client. In some cases, it may be desirable to block this Internet access (or force it to pass through the tunnel) while the client has a tunneled connection to the target network. This is a matter of client security policy configuration." I think will be a good Idea to force the IRAC's SPD entries. I'm thinking i.e. of a scenario where someone wants to access to his corporate network using a public machine (i.e. from the airport or from the hotel), and in the corporate network the SGW is behind a firewall, in this case, where we can't trust the airport PC, and the "corporate firewall" can't inspect the packets in the tunnel because of the encryption we have to force SPD's enties on the IRAC to protect the corporate network. The IRAC's SPD should be something like this: OUTBOUND: FROM IP(IRAC):[PORT] TO IP(SGW)/xx :[PORT] IPSEC FROM IP(IRAC):[PORT] TO AnyHost :[PORT] Discard INBOUND FROM IP(SGW)/xx :[PORT] TO IP(IRAC):[PORT] IPSEC FROM AnyHost :[PORT] TO IP(IRAC):[PORT] Discard Am I right or there is something that I can't see ? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ------------------------------------------------ From owner-ipsec@lists.tislabs.com Tue Feb 4 08:29:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14GTOd15599; Tue, 4 Feb 2003 08:29:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05462 Tue, 4 Feb 2003 10:57:46 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F14@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , Michael Richardson , ipsec@lists.tislabs.com Cc: "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Tue, 4 Feb 2003 16:59:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: dinsdag 4 februari 2003 16:42 > To: Van Aken Dirk; Michael Richardson; ipsec@lists.tislabs.com > Cc: Scott G. Kelly > Subject: RE: Modefg considered harmful > > > Actually with this scenario a DHCP relay within the > RemoteOfficeLAN instead > of on the SmallIPsecGW would likely be the implementation of choice. > RFC3456 does not say anything about the relay being on the inside LAN > interface, only the interface terminating IKE-SAs so I don't > think it could > be applied to this scenario. Hi Darren, The point I wanted to make was that probably NetAdmins are already using DHCP in one form or another. > > Regarding your comments about modecfg, there is no need for > an address pool > on the LargeIPsecGW since it could act as a DHCP-client when > it receives > modecfg requests from an IRAC instead of having its ipsec > engine sniffing > for inbound DHCP packets and forwarding them to the internal > DHCP relay. > > Darren. > > PS - I know you don't like the idea of dhcp to modecfg > conversion by the > LargeIPsecGW. At least we agree on this point ;-) From owner-ipsec@lists.tislabs.com Tue Feb 4 08:34:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14GYRd16380; Tue, 4 Feb 2003 08:34:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05510 Tue, 4 Feb 2003 11:07:59 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Van Aken Dirk" , "Michael Richardson" , Cc: "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Tue, 4 Feb 2003 10:42:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F10@TMM_EDGMSMSG01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually with this scenario a DHCP relay within the RemoteOfficeLAN instead of on the SmallIPsecGW would likely be the implementation of choice. RFC3456 does not say anything about the relay being on the inside LAN interface, only the interface terminating IKE-SAs so I don't think it could be applied to this scenario. Regarding your comments about modecfg, there is no need for an address pool on the LargeIPsecGW since it could act as a DHCP-client when it receives modecfg requests from an IRAC instead of having its ipsec engine sniffing for inbound DHCP packets and forwarding them to the internal DHCP relay. Darren. PS - I know you don't like the idea of dhcp to modecfg conversion by the LargeIPsecGW. > -----Original Message----- > From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] > Sent: Monday, February 03, 2003 5:51 AM > To: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com > Cc: Scott G. Kelly > Subject: RE: Modefg considered harmful > > > Hi Darren, > > Have you thought about following situation ? > > RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN > > Following parameters are configured on the SmallIPSecGW: > > - LAN port (connected to the remote office Ethernetsegment): 20.0.0.254/24 > - DHCP Relay: enabled on this LAN port; giaddr= 20.0.0.254; DHCP Server= > 30.0.0.1 > - IPSec policy: protect 30.0.0.0/24 and IKE peer= Large IPSecGW > or > - IPSec policy: protect 0.0.0.0/0 and IKE peer= Large IPSecGW > > A PC is booting on the RemoteOfficeLAN, its broadcast DHCP requests arrive > in the SmallIPSecGW and are converted via the DHCP relay into unicast DHCP > request. Subsequently these request hit IPSec policy 30.0.0.0/24 or > 0.0.0.0/0 and are tunneled to the remote LargeIPSecGW. The LargeIPSecGW > processes these DHCP request as ordinary unicast packets; all > that is needed > is policy rules. The DHCP server picks an IP address based on > giaddr or more > advanced criteria. > Actually from the moment that the DHCP Relay makes the broadcast/unicast > conversion everything is "standard" IPSec. Packets follow routes and obey > policy rules; no IKECFG nor IPSec-DHCP specific functionality required. > > Appart from configuring policy rules there are no new skill that must be > learned by the network administrator because in the > CentralOfficeLAN he uses > these same techniques to manage his/her network. > > If Remote Access VPN users are based on RFC3456 I have a DHCP solution for > my complete network infrastructure more specific: > - my centreal office LAN > - my remote office VPN's > - my remote access VPN users. > > In case of Remote Access VPN users based on IKECfg I have to train my > network admin for this special case and address pools are located in two > devices: the DHCP server and the Large VPNGW. > > > Best regards - Dirk > > > -----Original Message----- > > From: Darren Dukes [mailto:ddukes@cisco.com] > > Sent: vrijdag 31 januari 2003 22:19 > > To: Michael Richardson; ipsec@lists.tislabs.com > > Cc: Scott G. Kelly > > Subject: RE: Modefg considered harmful > > > > > > I think any mature implementations that will be trying to use DHCP for > > complete configuration of the ipsec client (beyond network > > addresses, as is > > possible with modecfg today) will need to implement their own > > DHCP client > > and server in order to include their user-specific ipsec-VPN > > configuration. > > So what we'll end up with is as follows. > > > > OS-DHCP-client(optional) <-> ipsec-DHCP-client > > SGW-DHCP-server > > > > Reusing the OS DHCP client (if possible at all) will not give enough > > flexibility. > > > > Darren > > From owner-ipsec@lists.tislabs.com Tue Feb 4 09:37:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14Hbdd19847; Tue, 4 Feb 2003 09:37:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05661 Tue, 4 Feb 2003 12:00:25 -0500 (EST) Message-ID: <3E3FF1AA.19189AF1@bstormnetworks.com> Date: Tue, 04 Feb 2003 09:00:26 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: Van Aken Dirk , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, Darren Dukes wrote: > > Actually with this scenario a DHCP relay within the RemoteOfficeLAN instead > of on the SmallIPsecGW would likely be the implementation of choice. > RFC3456 does not say anything about the relay being on the inside LAN > interface, only the interface terminating IKE-SAs so I don't think it could > be applied to this scenario. Actually, you could either relay from the inside of the remote lan alone, or from there *and* from the head-end sgw. The benefit of the second configuration would be that in such cases, the remote lan need not be aware of the IP address of the dhcp relay destination. In any event, the tunnel must either support 0/0 selectors, or there must be a separate tunnel for the dhcp packets. You are correct that the rfc does not explicitly call out this configuration. It probably should. Scott From owner-ipsec@lists.tislabs.com Tue Feb 4 17:25:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h151Pad03748; Tue, 4 Feb 2003 17:25:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06519 Tue, 4 Feb 2003 19:49:44 -0500 (EST) Date: Wed, 5 Feb 2003 02:52:47 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: "Theodore Ts'o" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few responses below. On Sat, 1 Feb 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > "Theodore Ts'o" wrote: > > Hugo has suggested that for EAP mechanisms that generate a shared key, > > the responder should send an AUTH message based on the shared key in the > > message containing the EAP(success) message, as backup in case for some > > reason the CERT based exchange might have gotten spoofed somehow. This > > seems to me to be a case of gilding the lilly, and is probably not be > > worth the extra complexity, but I encourage comment on the working group > > about whether or not this additional twist should be included. > > I agree with Hugo on this one. We've been assuming that legacy auth is > always going to have the responder first authenticating to the > initiator with certificates the initiator will know how to process. > But I can imagine cases where legacy auth is mutual and the cert > based authentication is only a formality (or perhaps skipped). For > example, a legacy auth scheme based on EKE, SPEKE, SRP, or PDM > might have this property. What do others think? > > Hugo Krawczyk wrote: > > The one thing that I definitely dislike in the appended proposal is that > > it opens IDi (sent in message 3) to active attacks. If there is one > > application where identity protection really makes sense is in hiding > > identities and locations of mobile users, which will be among the main > > users of SLA. I suggest to make IDi optional in message 3, and make it > > clear that implementations should NOT assume that this IDi value is > > available, certainly not in a way that compromises the user's identity. > > I am genuinely conflicted about this one - like the donkey between the > two bales of hay. I see equally good arguments on both sides, and I don't > think it matters much. But it does matter that we decide. > > If IDi is included in message 3, it is exposed to active attacks. > (Someone impersonating the gateway can learn the claimed name of the > initiator and subsequently break the connection). We decided we > could live with that for cert based authentication, but if the > case for preventing it is a little stronger here. If it is not > included in message 3, then the gateway may not be able to > produce the challenge it needs for message 4 and the protocol could > require an extra round trip. If we make it optional in message > 3, the spec has to say (and the implementations have to code > and test) all of the options. > > I put a stake in the ground in ikev2-04 and said it was required > in message 3. Do people want it to say something else? Should it > be legacy authentication mechanism specific? All this business of identity protection was in ipsec from day one since Phil Karn thought it was essential. Except for a short period of agreement with this view, this need or no-need for anonymity in ipsec's key exchange protocol was always a source of debate. In particular, all past proposals started with mandatory identity protection and then relaxed it to optional (including Karn's Photuris). The whole cryptography of the IKE (v1 and v2) protocol is directed to support identity protection (there are more straightforward protocols if you do not require id protection). Was all this mess worth it? I do not know. But if there is ONE place where identity protection makes sense is in the remote access environment. ANd then here we are going to give it up? Either leave it optional in msg 3, or forbid it msg 3, or define it to be legacy method specific, but do not force its disclosure to trivial active attacks. > > Hugo Krawczyk wrote: > > I have no practical (or other) experience with such key-providing > > legacy authentication methods. However, since these are LEGACY methods > > then I assume that if they generate a shared key then this key may be > > intended for other uses. Can we be sure that this key (call it LK for > > "legacy key"), if used by SLA, will be used ONLY by SLA? Otherwise we > may > > end having one key LK which is used in two different settings. In > > particular, one may end using one key LK for two different cryptographic > > algorithms. Are you sure that this is NOT possible? > > When an authentication mechanism generates a shared > key as a side effect, it is generally for the purpose of > protecting subsequent data exchanges with that key. When > used in IPsec, it is likely that the subsequent data > exchanges will be protected with IPsec, so the key will > have no uses other than generating AUTH. > > That said, who knows what someone might do in the future. > We could specify that using the key for anything else is > forbidden. We could instead of using the key directly > hash it with an IKE-related constant and use the result > as the key. I'd be happy with either of these, though > I believe that both are overkill. > > Do you have a concrete proposal for addressing this? > I am not proposing to do any of the "overkill" (and ineffective) tricks mentioned above. I was mainly raising the concern hoping someone can shed light on how these keys are used. At this point I believe that the only thing that can be done is to have a "MUST NOT use this key for any other purpose (in IKE or elsewhere)" kind of directive in the draft. > Hugo Krawczyk wrote: > > One other question raised in the appended note is when should the AUTH > > field be sent. Seems to me that the simplest specification is to send it > > in the last client's message in SLA. Even if this key (LK) is available > > earlier, it does not buy you much to compute AUTH earlier (and you can > > always keep the key for authentication at the end). An early > > authentication using LK can only help against a DoS attack mounted by a > > MitM attacker; however I doubt that anyone will choose this costly (for > > the attacker) way to to mount a DoS attack. > > I didn't say the client's last message because for some legacy auth > methods the exchange is variable length and the client doesn't know > which of his messages will be the last until the server accepts it. > OK. Hugo > > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > From owner-ipsec@lists.tislabs.com Tue Feb 4 18:29:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h152T4d05162; Tue, 4 Feb 2003 18:29:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06819 Tue, 4 Feb 2003 21:01:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20030203173807.02162d28@mira-sjc5-9.cisco.com> References: <4.3.2.7.2.20030203173807.02162d28@mira-sjc5-9.cisco.com> Date: Tue, 4 Feb 2003 21:01:35 -0500 To: Bora Akyol From: Stephen Kent Subject: Re: Modefg considered harmful Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:41 PM -0800 2/3/03, Bora Akyol wrote: >At 04:55 PM 2/3/2003 -0500, Stephen Kent wrote: >>In 2401bis, we plan on de-coupling route selection from SA >>selection, by having an explicit lookup for routing performed prior >>to SA selection, and then passing along a virtual interface ID as >>part of the SA selection process. This is something that was >>discussed among a set of folks interested in PPVPN and overlay nets >>over the last several months. If adopted, this would make it easier >>to accommodate the sort of full-fledged routing participation that >>you allude to. > > >I fear that this is straying from the scope of the ipsec working >group to something much larger. As you point out there is no >infra-structure in the Internet to verify that either a route or its >advertiser are authentic. Specification of a virtual interface ID is >implementation specific. > >I want to understand more of the concern here. Is the concern that >ipsec SAs are being used to route traffic or due to the uncontrolled >routing, some packets that should be secured are going in the clear >due to the wrong interface selection? > >Can you please elaborate the reasoning behind this concern and verbiage? > >Thanks > >Bora Bora, IPsec provides access controls based on packet headers, primarily S/D IP addresses. If an IPsec implementation serves a single host, we can manage this well, i.e., we can appropriately configure the SPD to reflect the address of the host. If an IPsec gateway serves a subnet we can probably do an acceptable job as well. But, if people start thinking in terms of routing through a subnet protected with an IPsec security gateway, en route to some other subnet, this sort of transit traffic protection creates new requirements for secure management of the binding between an IPsec device and the addresses that it is authorized to represent. I agree that this is a bigger issue than IPsec, but we need to be cognizant of vulnerabilities that will result if we say that IPsec gateways can be used for this sort of transit traffic protection. We need to advise potential users of the technology of these vulnerabilities, and suggest means by which the vulnerabilities can be mitigated. Steve From owner-ipsec@lists.tislabs.com Tue Feb 4 18:29:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h152T5d05171; Tue, 4 Feb 2003 18:29:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06820 Tue, 4 Feb 2003 21:01:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <200302032241.h13MfMn17917@localhost.localdomain> References: <200302032241.h13MfMn17917@localhost.localdomain> Date: Tue, 4 Feb 2003 21:01:34 -0500 To: John Lindal From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:41 PM -0800 2/3/03, John Lindal wrote: > >> > There's a very large difference between a general purpose OS like >>>> Windows or Unix, and an embedded system OS. Large, as in several >>>> orders of magnitude. >>> >>>Unless I'm missing something fundamental, comparing the raw sizes of >>>various operating systems is misleading. Assuming that the VPN software is >>>installed at the bottom of the network stack, just above the NIC driver, >>>then it doesn't matter how big the rest of the OS is. The only thing that >>>matters is the tiny little bit of the OS that takes the packet off the NIC >>>and hands it to the VPN driver. >>> >>>Of course, this small part of the OS must not have any holes, the VPN >>>software must not have any holes, and the security policies must be set >>>correctly to weed out malicious or unwanted packets! >> >> I'm afraid you are missing something. Irrespectivbe of where the VPN >> software is installed in a general purpose platform/OS environment, >> that software can be subverted by a successful attack against any >> part of the rest of the OS. > >How can one attack the rest of the OS if the VPN component is located at >the only entry point and doesn't allow malicious packets to pass? > >> Your comment suggests that if the VPN access controls are working, then >> no evil packets can evade detection and thus be used to attack the higher >> layer software. We have lots of experience that indiactes otherwise. > >I think it's a matter of definitions. In any situation where malicious >packets get through the VPN filter, I would say that the access controls >are not working correctly :) John, I've often joked that when I was on the IAB for over a decade I missed the opportunity to define the "evil" bit in the IP header, which would flag malicious packets and make security so much easier :-) I know of no way to determine if a packet is malicious, in absolute terms. We characterize packets (or, more typically, sequences of packets) as malicious only once we understand the bad things than can happen, usually as a result of being the victim of an attack. So, detection of malicious packets is, in that sense, a two pass algorithm, with a possibly long with a possibly long interval between the passes. I didn't think that any firewall or IDS vendor really believed that it had filters or signatures or anomaly detection algorithms that were good enough to detect all malicious traffic. Thus, by your definition, ALL of these products have defective access controls. On what basis do you believe that your technology is capable of detecting and rejecting all malicious packets and thus is immune to attacks that might traverse the VPN component? Steve P.S. I think it would be better to not refer to functions like IDS as VPN components. The generally accepted terminology for VPNs is broad, bit I don't think most folks would claim that it encompasses Intrustion Detection. One may choose to provide IDS functions in the same box as IPsec, but the two are independent. From owner-ipsec@lists.tislabs.com Tue Feb 4 22:33:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h156Xud12287; Tue, 4 Feb 2003 22:33:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07193 Wed, 5 Feb 2003 01:05:27 -0500 (EST) From: "Geoffrey Huang" To: "The Purple Streak, Hilarie Orman" , Cc: "Geoffrey Huang" Subject: RE: WG Last Call draft-ietf-ipsec-dpd-01.txt Date: Tue, 4 Feb 2003 22:05:37 -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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200302032347.h13NlvE04106@localhost.localdomain> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The draft has a number of non-ascii characters. I will fix. > There was once a good statement on the mailing list about why > keep-alives were important, but this draft doesn't have such a thing. > What important advantage accrues from keep-alives? They allow state Advantage of keepalives over...? There isn't a comparison between keepalives and every other scheme to resynchronize lost state for several reasons: 1) I don't know ever other scheme 2) I tried to focus on comparing DPD to keepalives/heartbeats. > to be removed more aggressively and efficiently than methods without > keep-alives? Alos, there is mention of a "mitigation" of the need for > timers, but one still needs them, it seems. True - one still needs timers, but it's "mitigation" and not "elimination." The introduction sums up this mitigation - DPD does not need "to send messages at regular intervals." > There should be some context about where the SPI and associated > parameters come from. It's a little difficult to grok these things > exist until one gets to the message formats. There's a statement Do you mean section 5.3? The SPI isn't referenced until the message format's presented anyhow... > early on that there will be comparison between methods based on IPSec > SA's and IKE SA's, but the promise is not kept, as nearly as I can see. The comparison that got elided is this: Hello messages sent out per IPSec SA can get you finer granularity, but at the cost of maintaining more state. If you allow the liveness of an IKE SA to imply liveness of all IPSec SAs through the IKE peer, then you get coarser granularity, but you have to maintain less state. I can either add this blurb, or remove the claim about the comparison. > There's a statement that "unencrypted" data must be rejected. How does > one make a determination that the data has been encrypted? From > a security > viewpoint, it seems more important that a message authentication code be > validated than that encryption be applied. ...the same way you'd determine any other notify is unencrypted ;-). > There is no mention of what should be done if the peer doesn't > respond. Is the RUTHERE sent again? How fast, how many times before > making a deadness decision? Suppose A decides B is dead, but B does Yep, you should retransmit. The number of retransmissions isn't important, but you're right, I'll add text to this effect. > not agree. A will start a new "session" and choose a new sequence > number. B might continue using the previous "session". If A refuses > to respond, B might eventually conclude that A is dead and start a new > session. How do they resynchronize? > Suppose B decides to optimize by pre-computing its responses and > sends them > prior to A's requests, using a timer. Is there any harm? No, since any inbound traffic to A from B serves as proof of liveliness of B. As the text mentions, however, each entity defines its own "worry metric" at which point it considers the liveliness of its peer in doubt. > There's an obscure covert channel introduced by this mechanism. If A > sends IPSec traffic to B and E corrupts that traffic, B will consider > A unresponsive and send a keep-alive. That lets E distinguish between > successful and unsuccessful corruption. Successful and unsuccessful corruption of the IPSec traffic? That would require E to understand the transmission scheme of B's DPD implementation, and it would assume that B sends R-U-THERE messages whenever it hasn't heard from A. > Security considerations should address how long a session can be used > with the sequence number scheme. What it be feasible, for example, to > have a one millisecond "worry interval"? No, I suppose it wouldn't be feasible to have a 1 ms worry interval. The examples in the document suggest something on the order of 10 seconds. Thanks for the comments. -g > Hilarie > From owner-ipsec@lists.tislabs.com Wed Feb 5 03:57:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Bvcd27915; Wed, 5 Feb 2003 03:57:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08010 Wed, 5 Feb 2003 06:28:34 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F15@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , Michael Richardson , ipsec@lists.tislabs.com Cc: "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Wed, 5 Feb 2003 10:11:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, See my comments below. > > Regarding your comments about modecfg, there is no need for > an address pool > on the LargeIPsecGW since it could act as a DHCP-client when > it receives > modecfg requests from an IRAC instead of having its ipsec > engine sniffing > for inbound DHCP packets and forwarding them to the internal > DHCP relay. > > Darren. > The IPSec engine must not sniff on DHCP packets. As said before, implementing RFC3456 can IMHO happen almost completely outside the IKE and IPSec code! More specific, a DHCP discover arriving via an IPSec tunnel has a source address (0,0) and destination address (-1,-1). After passing through the SPD, this packet must be delivered locally, that is, to the internal IP host of the IPSec GW (see RFC1812-section 5.2.3). The local host is configured with a DHCP relay that is listening on UDP port 67 (DHCP server port). This DHCP relay can either forward the request to an internal DHCP server or relay it to an external DHCP server. The only IPSec specific item that the relay must take care of is that replies from the server must end-up in the correct "DHCP-tunnel". This can be accomplished via the DHCP Relay Information Option/sub-options. i.e. The DHCP relay must "tag" the DHCP requests (e.g. with the Tunnel IP address, Tunnel port number) in the direction towards the DHCP server and must "untag" the DHCP replies and use this tag to look-up the correct tunnel in the direction towards the DHCP client (see section 4.2 of RFC3456). So to conclude: - I don't have to touch the IKE code - I don't have to touch IPSec code - I might have to change DHCP relay code but this technology is well understood - my IP parameter distribution method is in-line with the rest of the network infrastucture and inherits an existing and rich feature set. Best regards - Dirk For your convenience excerpted the relevant section on local delivery of RFC1812 - Requirements for IP Version 4 Routers. 5.2.3 Local Delivery Decision When a router receives an IP packet, it must decide whether the packet is addressed to the router (and should be delivered locally) or the packet is addressed to another system (and should be handled by the forwarder). There is also a hybrid case, where certain IP broadcasts and IP multicasts are both delivered locally and forwarded. A router MUST determine which of the these three cases applies using the following rules. o An unexpired source route option is one whose pointer value does not point past the last entry in the source route. If the packet contains an unexpired source route option, the pointer in the option is advanced until either the pointer does point past the last address in the option or else the next address is not one of the router's own addresses. In the latter (normal) case, the packet is forwarded (and not delivered locally) regardless of the rules below. o The packet is delivered locally and not considered for forwarding in the following cases: - The packet's destination address exactly matches one of the router's IP addresses, - The packet's destination address is a limited broadcast address ({-1, -1}), or From owner-ipsec@lists.tislabs.com Wed Feb 5 09:50:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15HoZd21658; Wed, 5 Feb 2003 09:50:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08859 Wed, 5 Feb 2003 12:06:53 -0500 (EST) Reply-To: From: "Darren Dukes" To: Subject: Man in the middle attack against RFC3456. Date: Wed, 5 Feb 2003 12:09:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is a man in the middle attack on the DHCP-relay in RFC3456. This attack is based on the thread defined in RFC3118 (DHCP-AUTH). In this case Eve is inside the LAN and able to source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a new route for whatever address Eve puts in yiaddr. |-Eve IRAC ---- SGW -| |-DHCP Server excerpt from RFC3456: To learn the internal IP address of the client in order to route packets to it, the security gateway will typically snoop the yiaddr field within the DHCPACK and plumb a corresponding route as part of DHCP Relay processing. This attack is not resolved by the implementation of RFC3118 unless the following changes are made to the DHCP-relay. 1 - It stored a copy of all secret keys contained on the DHCP-server and used them to authenticate DHCPACKs or it stored a copy of the master key and used that to generate the client keys as described in RFC3118 Appendix A. 2 - DHCP-relay implements the DHCP-server replay protection. Darren From owner-ipsec@lists.tislabs.com Wed Feb 5 09:50:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15HoZd21659; Wed, 5 Feb 2003 09:50:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08845 Wed, 5 Feb 2003 12:05:46 -0500 (EST) Message-ID: <3E413A20.DAAF5449@NORTELNETWORKS.COM> Date: Wed, 05 Feb 2003 11:21:52 -0500 From: "Marcus Leech" Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: <200301310051.h0V0pRjt016945@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > "what bernard said". > > I see modecfg as reinventing a square wheel. > Me too, but there was this issue of the large installed base of MODECFG-like things in existing implementations. Since I'm not an implementor, I'm in the situation where I have to believe that moving away from a MODECFG-like thing is a hardship. *If* it's acceptablet to discount such claimed hardship, then I have to agree with Bernards assertion that the IPSRA-style DHCP approach is cleaner, more flexible, and in the long-term, less work. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Wed Feb 5 09:57:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15HvWd21829; Wed, 5 Feb 2003 09:57:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08950 Wed, 5 Feb 2003 12:26:32 -0500 (EST) Reply-To: From: "Darren Dukes" To: Subject: FW: Man in the middle attack against RFC3456. Date: Wed, 5 Feb 2003 12:29:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amendment: Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a manufactured DHCP Relay Agent Information Option or one copied from a previous DHCP message. > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: Wednesday, February 05, 2003 12:10 PM > To: ipsec@lists.tislabs.com > Subject: Man in the middle attack against RFC3456. > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > This attack is based on the thread defined in RFC3118 > (DHCP-AUTH). In this case Eve is inside the LAN and able to > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > new route for whatever address Eve puts in yiaddr. > > |-Eve > IRAC ---- SGW -| > |-DHCP Server > > excerpt from RFC3456: > To learn the internal IP address of the client in order to route > packets to it, the security gateway will typically snoop the yiaddr > field within the DHCPACK and plumb a corresponding route as part of > DHCP Relay processing. > > This attack is not resolved by the implementation of RFC3118 > unless the following changes are made to the DHCP-relay. > 1 - It stored a copy of all secret keys contained on the > DHCP-server and used them to authenticate DHCPACKs or it stored a > copy of the master key and used that to generate the client keys > as described in RFC3118 Appendix A. > 2 - DHCP-relay implements the DHCP-server replay protection. > > > Darren > From owner-ipsec@lists.tislabs.com Wed Feb 5 09:59:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Hxfd21873; Wed, 5 Feb 2003 09:59:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08949 Wed, 5 Feb 2003 12:26:32 -0500 (EST) Message-Id: <200302051728.h15HSsHD026065@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com CC: "Theodore Ts'o" , paul.hoffman@vpnc.org Subject: Revised Identities (revised and revisited) In-reply-to: Your message of "Tue, 04 Feb 2003 20:06:11 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Feb 2003 12:28:53 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ted sent out a plea for comments on some of these things. >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 2) Revised Identity Theodore> Paul Hoffman has a proposal which would replace the current methods of Theodore> identifying initiators and responders (i.e.): Theodore> ID_IPV4_ADDR 1 Theodore> ID_FQDN 2 Theodore> ID_RFC822_ADDR 3 Theodore> ID_IPV6_ADDR 5 Theodore> ID_DER_ASN1_DN 9 Theodore> ID_DER_ASN1_GN 10 Theodore> ID_KEY_ID 11 Theodore> with a completely different set of types: Theodore> 1 PKIX certificate Theodore> 2 Certificate bundle Theodore> 3 Hash-and-URL of PKIX certificate Theodore> 4 URL to a PKIX certificate bundle Theodore> 5 PKIX keyIdentifier Theodore> 6 IDForSharedSecret Theodore> This represents a fundamental shift in how IPSEC implementations handle Theodore> identities. It has potential effects on how policies are looked up, and Only if left this way. There is an amended proposal. If you put the raw keys with DNS based identities that I suggested, (see http://www.sandelman.ca/ipsec/2002/12/msg00250.html or http://www.vpnc.org/ietf-ipsec/mail-archive/msg02834.html Hey, Paul, time to roll the VPNC list. It is 2003 now...) then there is no fundamental shift at all. ID_IPV4_ADDR -> identity from reverse map ID_FQDN -> identity from forward map ID_RFC822_ADDR -> identity from forward map ID_IPV6_ADDR -> identity from reverse map Theodore> ID_DER_ASN1_DN 9 Theodore> ID_DER_ASN1_GN 10 Theodore> ID_KEY_ID 11 These map to PKIX things. You are overstating this "shift" to a large degree. {Some may not want all of Me-Tarzan, You-Jane. I don't see how we can build anything other than VPN gateways without it. We need this to be able to have secure communication between multi-user systems that may have multiple identities. We need it even for VPN gateways that expect to roll their keys asynchronously from each other, and it lets one overlap certificate checking and CRL download with RSA operations.} Theodore> To be fair, there are some arguments in favor of this proposal; by Theodore> forcing all implementations to use certificates as the basis of their Theodore> naming, it can solve a number of interoperability concerns. (Although Theodore> on the other hand, the pki-profile document also solves many of these Theodore> issues without resorting to using an entirely new naming system.) No, I disgree. Forcing all implementations to use public keys may do this. Forcing everyone to use certificates means that IKEv1 will remain, and that IKEv2 will never get deployed. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkFJtoqHRg3pndX9AQHp3QQAqaq/B9CEqHORBm3X0zVYllJH+Otx/Nuo Chz45nPSilz0k5fGhaHUe+ozHpC82dyqWrkAUcwbElkL0CwbD2pXf19PWaaXrkjG bdk1CEFOOX2p3O2JzKae5b1HgjwSOJj2H8ws3MH53hG7f713BMjRyMuCXTBxrk7w blBkcYj+/7A= =gV7i -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 5 10:34:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15IYKd22557; Wed, 5 Feb 2003 10:34:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09076 Wed, 5 Feb 2003 13:04:21 -0500 (EST) From: "Geoffrey Huang" To: "'Van Aken Dirk'" , , "'Michael Richardson'" , Cc: "'Scott G. Kelly'" Subject: RE: Modefg considered harmful Date: Wed, 5 Feb 2003 10:03:25 -0800 Message-ID: <000601c2cd40$e14a2910$e1a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F10@TMM_EDGMSMSG01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Van Aken Dirk > Sent: Monday, February 03, 2003 2:51 AM > To: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com > Cc: Scott G. Kelly > Subject: RE: Modefg considered harmful > > > Hi Darren, > > Have you thought about following situation ? > > RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN > > Following parameters are configured on the SmallIPSecGW: > > - LAN port (connected to the remote office Ethernetsegment): > 20.0.0.254/24 > - DHCP Relay: enabled on this LAN port; giaddr= 20.0.0.254; > DHCP Server= > 30.0.0.1 > - IPSec policy: protect 30.0.0.0/24 and IKE peer= Large IPSecGW > or > - IPSec policy: protect 0.0.0.0/0 and IKE peer= Large IPSecGW > > A PC is booting on the RemoteOfficeLAN, its broadcast DHCP > requests arrive > in the SmallIPSecGW and are converted via the DHCP relay into > unicast DHCP > request. Subsequently these request hit IPSec policy 30.0.0.0/24 or > 0.0.0.0/0 and are tunneled to the remote LargeIPSecGW. The > LargeIPSecGW > processes these DHCP request as ordinary unicast packets; all > that is needed > is policy rules. The DHCP server picks an IP address based on > giaddr or more > advanced criteria. > Actually from the moment that the DHCP Relay makes the > broadcast/unicast > conversion everything is "standard" IPSec. Packets follow > routes and obey > policy rules; no IKECFG nor IPSec-DHCP specific functionality > required. > > Appart from configuring policy rules there are no new skill > that must be > learned by the network administrator because in the > CentralOfficeLAN he uses > these same techniques to manage his/her network. > > If Remote Access VPN users are based on RFC3456 I have a DHCP > solution for > my complete network infrastructure more specific: > - my centreal office LAN > - my remote office VPN's > - my remote access VPN users. > > In case of Remote Access VPN users based on IKECfg I have to train my > network admin for this special case and address pools are > located in two > devices: the DHCP server and the Large VPNGW. > This is an implementation issue - there's no reason the VPN remote access pool must be separate from the dhcp pool. -g > Best regards - Dirk > > > -----Original Message----- > > From: Darren Dukes [mailto:ddukes@cisco.com] > > Sent: vrijdag 31 januari 2003 22:19 > > To: Michael Richardson; ipsec@lists.tislabs.com > > Cc: Scott G. Kelly > > Subject: RE: Modefg considered harmful > > > > > > I think any mature implementations that will be trying to > use DHCP for > > complete configuration of the ipsec client (beyond network > > addresses, as is > > possible with modecfg today) will need to implement their own > > DHCP client > > and server in order to include their user-specific ipsec-VPN > > configuration. > > So what we'll end up with is as follows. > > > > OS-DHCP-client(optional) <-> ipsec-DHCP-client > > SGW-DHCP-server > > > > Reusing the OS DHCP client (if possible at all) will not give enough > > flexibility. > > > > Darren > > > From owner-ipsec@lists.tislabs.com Wed Feb 5 10:54:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15IsXd23813; Wed, 5 Feb 2003 10:54:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09161 Wed, 5 Feb 2003 13:22:32 -0500 (EST) From: "Geoffrey Huang" To: "'Theodore Ts'o'" , Subject: RE: Moving forward with IKE V2: A proposal for final edits to ikev2-04 Date: Wed, 5 Feb 2003 10:24:41 -0800 Message-ID: <000701c2cd43$d9402dc0$e1a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3) For the Cipher Suite issue, that we use Paul Hoffman's proposed set > of Cipher suites. There is less consensus on this issue on the > mailing list, but most people don't seem to have strong feelings, > so we believe we just pick something: > > Suite-ID Meaning > -------- ------- > 0 Covers: IKE (MUST) > 168-bit 3DES CBC encryption > Diffie-Hellman group 2 (1024-bit) > HMAC-SHA1 integrity and prf > > 1 Covers: ESP (MUST) > 3DES encryption with three keys > HMAC-SHA1 integrity > > 2 Covers: AH (SHOULD) > HMAC-SHA1 integrity > > 3 Covers: IKE (MUST) > 168-bit 3DES CBC encryption > Diffie-Hellman group 5 (1536-bit) > HMAC-SHA1 integrity and prf > > 4 Covers: IKE (MUST) > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 5 (1536-bit) > HMAC-SHA1 integrity and prf > > 5 Covers: IKE (MUST) > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit) > HMAC-SHA1 integrity and prf > > 6 Covers: ESP (MUST) > AES encryption in CBC mode with 128-bit keys > HMAC-SHA1 integrity > > 7 Covers: IKE (SHOULD) > AES encryption in CTR mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit) > AES-CBC MAC + XCBC integrity and prf > > 8 Covers: ESP (SHOULD) > AES encryption in CTR mode with 128-bit keys > AES-CBC MAC + XCBC integrity > > I have adjusted the MUST/SHOULD from Paul's message since I > believe that > for implementations that will be moving to implement IKEv2, it is > reasonable to require the implementation of AES, as it as so many > advantages over 3DES. If it weren't for the existing chips that only > support AES-CBC, I'd argue for making AES-CTR mandatory instead, but > given where we are, this set of MUST/SHOULD seems to me to be the most > reasonable set of ciphers. > > Question: Should AES Counter mode be made mandatory to ensure > compatibility in the future? Existing chips only support AES-CBC, so > this might make things harder for people as they transition > to IKEV2. On > the other hand, by the time we see start seeing IKEv2 > products, it might > be reasonable to require the presence of AES-CTR support. As far as SHOULD vs. MUST goes w.r.t. cipher algorithms - I think leaving it at SHOULD would suffice. Experience with 3DES showed that even though it was a "SHOULD" most people ended up implementing it. To this end, I guess support for such algorithms is very demand-based. > ----------------------------------- > > (SEMI-)CLOSED ISSUES > ===================== > > The following issues have been burbling on the list, although in the > opinion of the IPSEC Working group chairs, there isn't > consensus in the > IPSEC working group to act on them. > > If you feel otherwise, please speak now. > > A) Revised identity > -------------------- > > Paul Hoffman has a proposal, draft-ietf-ipsec-revised-identity-00.txt, > which radically changes how identities are handled. Specifically, it > would eliminate the ID payload with the following types: > > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_RFC822_ADDR 3 > ID_IPV6_ADDR 5 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > > et.al, and replaces it with a FullID payload with the following types: > > 1 PKIX certificate > 2 Certificate bundle > 3 Hash-and-URL of PKIX certificate > 4 URL to a PKIX certificate bundle > 5 PKIX keyIdentifier > 6 IDForSharedSecret > > This would be fundamental change in the management and > administraton of > IPSEC and IKE, so is not something to adopt lightly, and > without a clear > consensus of the working group. This was discussed in two threads on > the IPSEC mailing list: one starting on November 5th (subject Adding > revised identities to IKEv2), and one starting on December > 8th (subject: > Summary of revised identity changes). People who spoke in > favor on the > mailing list included Francis Dupont and Bill Sommerfeld, > with qualified > support from Michael Richardson (if support for bare keys is > added) and > Tero Kivinen (who is concerned about the complexity of the proposal). > > This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted > were left with the impression that there was not consensus among those > who met to discuss legacy authentication after the IPSEC wg meeting to > pursue adoption of Paul's proposed change. Paul believes otherwise. > Since it is the job of working group chairs to determine consensus, we > (Barbara and Ted) hereby ask that those who believe we should > pursue the > revised identity proposal to please speak up. > > It should be noted that there are some intermediate positions beyond > what is currently in draft-ietf-ipsec-ikev2-04.txt and the > revised-identies draft. For example, we could add the > Hash-and-URL type > to the Certificate payload, if the goal is shrink the size of IKE > messages (with the tradeoff of increasing complexity in IKE > implementations). We could also add a CERT hash type to the ID > payload, without nuking the traditional FQDN or IPv4/6 addresses > identity mechanisms (although again, by adding new types, we would be > increasing the complexity of the specification and implementations). > > Due the relatively small number of people who have spoken in favor of > this proposal or its less-radical alternates, the default choice for > IKEv2 has to be what is currently in ikev2-04. So those who > believe we > should make this change (or those who strongly believe we should not) > are requested to speak up now, or forever hold your peace.... I'm all for clearing up the vagaries of the ID payload - especially when using certificates. But the proposed change seems to weigh heavily on certificate ID types - despite the fact that authentication by preshared key seems to be the preferred method. I admit that the hesitance to adopt certificates could arise from the ID confusion; still I feel more comfortable with the familiar ID types we currently have when using preshared key. Given this, couldn't we just be more explicit about what goes in an ID payload when certs are used?...and perhaps take the hash-and-url option from Paul's proposal? > B) DHCP-based vs. MODECFG style remote access configuration > ----------------------------------------------------------- > > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a > Configuration payload with defined attributes. An alternate mechanism > involves using tunneled DHCP requests. The latter approach > is about to > be published as an RFC by the IPSRA working group. Proponents of this > method argue that it is more powerful than modecfg (because of the > extensibility and large number of options already specified for DHCP; > for example, being able to specify DNS, time, print, or WINS servers, > and so on.) It is also argued that it requires less code on the > server/firewall, since an existing DHCP server can be used. > > Proponents of the modecfg approach argue that many implementation > already have support for modecfg, and that setting up sort-lived > specialized tunnels to allow the DHCP packets to flow through the > gateway is kludgy, and requires multiple special case entries into > packet forwarding tables. Modecfg proponents also argue that > it is also > possible to transform modecfg requests into DHCP requests, so > there are > implementation choices that do not require reimplementation of the > DHCP's address assignment function. They also point out that it > certainly is possible --- and in some ways easier --- to obtain the > time, print, WINS server information by using DHCP (via the DHCPINFORM > request) after the IPSEC tunnel is setup and the client address is > assigned. > > Either approach seems to be workable. It is certainly true > that most of > the people in Atlanta were implementors who were already familiar with > modecfg, representing a large implementation community. That being > said, there is also some number of working group members that are in > favor of an approach similar to draft-ietf-ipsec-dhcp-13, > including Van > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or > another, however we need to make a choice and move forward. > > Given that we have a fully specified solution in the ikev2-04 > draft, and > it would seem that while there is a sizeable minority in favor of the > ipsec-dhcp-13 approach, the majority are comfortable with the modecfg > based approach. So at this point, we, as working group chairs, judge > that the consensus is with the current approach. > > If there are those who feel otherwise, or who see fatal problems with > the current approach, please speak now. I never thought I'd be a defender of mode config, but here I'm about to defend it. I prefer mode config to dhcp-ipsec for several reasons: - as implementors, we understand it. We have experience implementing it, we're comfortable with its extensibility. - Mode config allows us to use various data stores for housing policy - be it the security gateway itself, RADIUS, etc. Note that using mode config shouldn't preclude us from getting address pools from a dhcp server, even. - Mode config allows us to decide on address pools based on the identity of the peer. One argument in favor of DHCP that I've read on this list is that it's an existing protocol with many configuration parameters already defined. I can certainly see the benefit of this (no point in reinventing the wheel), but I think it's worth noting that, since mode config is part of the IKE realm, IKE implementors control its extensibility. It might be too restrictive to depend on DHCP to come up with parameters that might be IKE-centric (if we were ever to need to extend configuration options). -g > Ted and Barabara > IPSEC wg chairs > From owner-ipsec@lists.tislabs.com Wed Feb 5 12:25:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15KPkd27498; Wed, 5 Feb 2003 12:25:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09380 Wed, 5 Feb 2003 14:51:18 -0500 (EST) Message-ID: <3E416B5C.777F7AC0@bstormnetworks.com> Date: Wed, 05 Feb 2003 11:51:56 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: ipsec@lists.tislabs.com Subject: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Come on, Darren - you must be joking. What you describe is not an attack against RFC3456 - it's an attack against DHCP/BOOTP, and this is nothing new. If you run DHCP on your network and you have malicious insiders, they can do all sorts of things. The same applies for most other commonly run lan protocols. And since you've already conceded that a scalable modecfg implementation will be running dhcp on the backend, what is the point of this post? Let's stick with arguments with technical merit. Scott Darren Dukes wrote: > > Amendment: > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a manufactured > DHCP Relay Agent Information Option or one copied from a previous DHCP > message. > > > -----Original Message----- > > From: Darren Dukes [mailto:ddukes@cisco.com] > > Sent: Wednesday, February 05, 2003 12:10 PM > > To: ipsec@lists.tislabs.com > > Subject: Man in the middle attack against RFC3456. > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > This attack is based on the thread defined in RFC3118 > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > new route for whatever address Eve puts in yiaddr. > > > > |-Eve > > IRAC ---- SGW -| > > |-DHCP Server > > > > excerpt from RFC3456: > > To learn the internal IP address of the client in order to route > > packets to it, the security gateway will typically snoop the yiaddr > > field within the DHCPACK and plumb a corresponding route as part of > > DHCP Relay processing. > > > > This attack is not resolved by the implementation of RFC3118 > > unless the following changes are made to the DHCP-relay. > > 1 - It stored a copy of all secret keys contained on the > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > copy of the master key and used that to generate the client keys > > as described in RFC3118 Appendix A. > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > Darren > > From owner-ipsec@lists.tislabs.com Wed Feb 5 12:26:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15KQnd27520; Wed, 5 Feb 2003 12:26:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09386 Wed, 5 Feb 2003 14:53:29 -0500 (EST) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 5 Feb 2003 13:55:56 -0600 (CST) From: Tylor Allison X-X-Sender: To: Van Aken Dirk cc: "'ddukes@cisco.com'" , Michael Richardson , , "Scott G. Kelly" Subject: RE: Modefg considered harmful In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F15@TMM_EDGMSMSG01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been following this discussion for a bit now, but must admit that I'm still coming up to speed on how rfc.3456 is intended to work, so please bear with me. For background, I have implemented Mode-Config, but not rfc.3456. On Wed, 5 Feb 2003, Van Aken Dirk wrote: > Hi Darren, > > See my comments below. > > > Regarding your comments about modecfg, there is no need for > > an address pool > > on the LargeIPsecGW since it could act as a DHCP-client when > > it receives > > modecfg requests from an IRAC instead of having its ipsec > > engine sniffing > > for inbound DHCP packets and forwarding them to the internal > > DHCP relay. > > > > Darren. > > The IPSec engine must not sniff on DHCP packets. As said before, > implementing RFC3456 can IMHO happen almost completely outside the IKE and > IPSec code! More specific, a DHCP discover arriving via an IPSec tunnel has > a source address (0,0) and destination address (-1,-1). After passing > through the SPD, this packet must be delivered locally, that is, to the > internal IP host of the IPSec GW (see RFC1812-section 5.2.3). The local host > is configured with a DHCP relay that is listening on UDP port 67 (DHCP > server port). This DHCP relay can either forward the request to an internal > DHCP server or relay it to an external DHCP server. The only IPSec specific > item that the relay must take care of is that replies from the server must > end-up in the correct "DHCP-tunnel". This can be accomplished via the DHCP > Relay Information Option/sub-options. i.e. The DHCP relay must "tag" the > DHCP requests (e.g. with the Tunnel IP address, Tunnel port number) in the > direction towards the DHCP server and must "untag" the DHCP replies and use > this tag to look-up the correct tunnel in the direction towards the DHCP > client (see section 4.2 of RFC3456). Regarding the DHCP relay to IPSEC tunnel selection, rfc.3456 gives several options on how this may be done... one of which is the Relay Info Option. The question I have is whether or not you can count on DHCP servers supporting this option (can you count on all servers supporting this)? If this option is not supported, this means another method for determining the tunnel selection must be used, and the only viable option that I can think of is for the SGW to keep the state table mentioned which tracks the DHCP transaction to the IPSEC tunnel. You state that the IKE/IPSEC engine must not sniff the DHCP packets... but that's in opposition to what's suggested in rfc.3456... "To learn the internal IP address of the client in order to route packets to it, the security gateway will typically snoop the yiaddr field within the DHCPACK and plumb a corresponding route as part of the DHCP Relay processing." My biggest concern here is where the enforcement of client to virtual IP mapping happening? Or is this not a desired goal/capability for remote access? For example, if I have Joe User who should always receive IP 10.1.1.111, and I setup a security policy which allows the 10.1.1.111 to have special access privileges, how can I guarantee that someone besides Joe can't obtain the 10.1.1.111 address? The security concerns section for rfc.3456 states that the assigned address MUST NOT be depended upon for security. This sort of access control can be done easily w/ Mode-Config, as IKE knows the address which should be assigned to the client and can setup the allowed Quick Mode selectors appropriately. > So to conclude: > - I don't have to touch the IKE code While this may be true, I don't believe it carries the same weight as it used to, since we're working on defining what the IKEv2 code should actually be. > - I don't have to touch IPSec code This isn't totally true, is it? You have to add the glue which inserts/extracts the DHCP traffic into the IPSEC tunnel. You also have to deal with the management of the DHCP-specific IPSEC SA and setting up of the dynamic SPD entries associated with the assigned address. > - I might have to change DHCP relay code but this technology is well > understood > - my IP parameter distribution method is in-line with the rest of the > network infrastucture and inherits an existing and rich feature set. > > Best regards - Dirk I'm struggling here because I'm not sure I totally like either solution that's being offered. My biggest complaints with RFC.3456 are the specialized IPSEC SA required for DHCP traffic and the lack of control on address assignment. Mode-Config for IKEv1 had a similar problem to rfc.3456 for SA management, as MC was a "phase 1.5" exchange, causing headaches in the IKE state tables. This seems to be solved in IKEv2 by the fact that the MC payloads are now inline in the base phase 1 exchange. I would agree, however that MC does duplicate the purpose of DHCP. The solution? The ideal solution in my mind would be to still use DHCP, but have the initial DHCP traffic pass through IKE instead of IPSEC. Either attempt to introduce the DHCP payloads directly into the phase 1 exchange (similar to what's proposed for MC), or to instantiate a new exchange for the DHCP traffic. IKE would be required to parse a minimum number of DHCP attributes in order to determine some base info, like the assigned IP address. If such a solution is not possible, then I'd prefer to keep the current Mode-Config proposal as described in the IKEv2 draft. We can keep the scope of MC to be very simple... address assignment for the remote peer. Once a VPN is established, any other network configuration parameters can be determined via the DHCPINFORM method. My $.02 worth. ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Wed Feb 5 12:58:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15KwZd28646; Wed, 5 Feb 2003 12:58:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09464 Wed, 5 Feb 2003 15:29:49 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Scott G. Kelly" Cc: Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Wed, 5 Feb 2003 15:31:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E416B5C.777F7AC0@bstormnetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Support of RFC3118 was significant enough for you to put in RFC3456, so why is an illustration of the attack refuting that support called sensationalism? See RFC3456 Section 2.1 under "Authentication". I think you're trivializing this. RFC3456 has been touted as providing all the modern and future capabilities of DHCP to IPsec clients. This is one case of how it fails to do this, and all it took to find was a few other implementers taking a quick look at it yesterday. If this attack has no technical merit then RFC3118 must not either (see section 1.1). RFC3118 exists to stop this sort of attack, so there must have been a significant need for it otherwise why would the authors waste their time writing it and advancing it to RFC? If you can get rid of the necessity of snooping yiaddr in RFC3456 you can fix this. BTW modecfg with a DHCP-proxy will not suffer from this since the DHCP-client implemented on the SGW could be provided with a single DHCP key. Darren > -----Original Message----- > From: scott@nc600c-sk [mailto:scott@nc600c-sk]On Behalf Of Scott G. > Kelly > Sent: Wednesday, February 05, 2003 2:52 PM > To: ddukes@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > RFC3456.] > > > Come on, Darren - you must be joking. What you describe is not an attack > against RFC3456 - it's an attack against DHCP/BOOTP, and this is nothing > new. If you run DHCP on your network and you have malicious insiders, > they can do all sorts of things. The same applies for most other > commonly run lan protocols. And since you've already conceded that a > scalable modecfg implementation will be running dhcp on the backend, > what is the point of this post? > > Let's stick with arguments with technical merit. > > Scott > > Darren Dukes wrote: > > > > Amendment: > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a > manufactured > > DHCP Relay Agent Information Option or one copied from a previous DHCP > > message. > > > > > -----Original Message----- > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > This attack is based on the thread defined in RFC3118 > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > new route for whatever address Eve puts in yiaddr. > > > > > > |-Eve > > > IRAC ---- SGW -| > > > |-DHCP Server > > > > > > excerpt from RFC3456: > > > To learn the internal IP address of the client in order to route > > > packets to it, the security gateway will typically snoop the yiaddr > > > field within the DHCPACK and plumb a corresponding route as part of > > > DHCP Relay processing. > > > > > > This attack is not resolved by the implementation of RFC3118 > > > unless the following changes are made to the DHCP-relay. > > > 1 - It stored a copy of all secret keys contained on the > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > copy of the master key and used that to generate the client keys > > > as described in RFC3118 Appendix A. > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > Darren > > > From owner-ipsec@lists.tislabs.com Wed Feb 5 13:08:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15L8Qd29243; Wed, 5 Feb 2003 13:08:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09532 Wed, 5 Feb 2003 15:41:36 -0500 (EST) Message-Id: <200302052043.h15Khlwj004942@thunk.east.sun.com> From: Bill Sommerfeld To: "Marcus Leech" cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-Reply-To: Your message of "Wed, 05 Feb 2003 11:21:52 EST." <3E413A20.DAAF5449@NORTELNETWORKS.COM> Reply-to: sommerfeld@east.sun.com Date: Wed, 05 Feb 2003 15:43:47 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Me too, but there was this issue of the large installed base of > MODECFG-like things in existing implementations. Since I'm not > an implementor, I'm in the situation where I have to believe that > moving away from a MODECFG-like thing is a hardship. Except that you probably *already* have a DHCP implementation already! I believe the correct comparison is the complexity of MODECFG vs the "DHCP to IPsec glue" code; the latter is likely to be significantly smaller than the former. > *If* it's acceptablet to discount such claimed hardship, then I have to > agree with Bernards assertion that the IPSRA-style DHCP approach is > cleaner, more flexible, and in the long-term, less work. indeed. - Bill From owner-ipsec@lists.tislabs.com Wed Feb 5 13:17:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15LHRd29630; Wed, 5 Feb 2003 13:17:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09576 Wed, 5 Feb 2003 15:51:03 -0500 (EST) Message-ID: <3E417967.82172F97@bstormnetworks.com> Date: Wed, 05 Feb 2003 12:51:51 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: ipsec@lists.tislabs.com Subject: Re: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Forgive my skepticism, but this is nothing but a distraction. If you have malicious insiders that will mount such attacks, you have serious problems, and should not be depending on some weak dhcp auth scheme to remedy this. Obvious solutions are to isolate the dhcp server, or to run ipsec between the sgw and the dhcp server. Why are we wasting time on this? Enough said. Scott Darren Dukes wrote: > > Support of RFC3118 was significant enough for you to put in RFC3456, so why > is an illustration of the attack refuting that support called > sensationalism? See RFC3456 Section 2.1 under "Authentication". > > I think you're trivializing this. RFC3456 has been touted as providing all > the modern and future capabilities of DHCP to IPsec clients. This is one > case of how it fails to do this, and all it took to find was a few other > implementers taking a quick look at it yesterday. > > If this attack has no technical merit then RFC3118 must not either (see > section 1.1). RFC3118 exists to stop this sort of attack, so there must > have been a significant need for it otherwise why would the authors waste > their time writing it and advancing it to RFC? > > If you can get rid of the necessity of snooping yiaddr in RFC3456 you can > fix this. > > BTW modecfg with a DHCP-proxy will not suffer from this since the > DHCP-client implemented on the SGW could be provided with a single DHCP key. > > Darren > > > -----Original Message----- > > From: scott@nc600c-sk [mailto:scott@nc600c-sk]On Behalf Of Scott G. > > Kelly > > Sent: Wednesday, February 05, 2003 2:52 PM > > To: ddukes@cisco.com > > Cc: ipsec@lists.tislabs.com > > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > > RFC3456.] > > > > > > Come on, Darren - you must be joking. What you describe is not an attack > > against RFC3456 - it's an attack against DHCP/BOOTP, and this is nothing > > new. If you run DHCP on your network and you have malicious insiders, > > they can do all sorts of things. The same applies for most other > > commonly run lan protocols. And since you've already conceded that a > > scalable modecfg implementation will be running dhcp on the backend, > > what is the point of this post? > > > > Let's stick with arguments with technical merit. > > > > Scott > > > > Darren Dukes wrote: > > > > > > Amendment: > > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a > > manufactured > > > DHCP Relay Agent Information Option or one copied from a previous DHCP > > > message. > > > > > > > -----Original Message----- > > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > > This attack is based on the thread defined in RFC3118 > > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > > new route for whatever address Eve puts in yiaddr. > > > > > > > > |-Eve > > > > IRAC ---- SGW -| > > > > |-DHCP Server > > > > > > > > excerpt from RFC3456: > > > > To learn the internal IP address of the client in order to route > > > > packets to it, the security gateway will typically snoop the yiaddr > > > > field within the DHCPACK and plumb a corresponding route as part of > > > > DHCP Relay processing. > > > > > > > > This attack is not resolved by the implementation of RFC3118 > > > > unless the following changes are made to the DHCP-relay. > > > > 1 - It stored a copy of all secret keys contained on the > > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > > copy of the master key and used that to generate the client keys > > > > as described in RFC3118 Appendix A. > > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > > > > Darren > > > > From owner-ipsec@lists.tislabs.com Wed Feb 5 15:49:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15NnEd05719; Wed, 5 Feb 2003 15:49:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09840 Wed, 5 Feb 2003 18:16:58 -0500 (EST) From: "Bepsy Paul" To: Subject: A basic question. Date: Wed, 5 Feb 2003 15:26:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am developing a VPN s/w for a small (9 engineers only) start-up company. I have developed a VPN with only 3DES and SHA-1-96 support and for TUNNEL mode. Now I am testing that with Safenet VPN client. My question is, the VPN tunnel works well with ICMP. But when I try FTP, it's not working. Can anyone point out any possible problem with FTP? I am processing ICMP, TCP and UDP packets in the same manner in IPSec output packet processing function. Your reply will be really appreciated. Bear with me for my simple question as I am just starting with VPNs. Thanks & Best Regards, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent Sent: Tuesday, February 04, 2003 6:02 PM To: John Lindal Cc: ipsec@lists.tislabs.com Subject: RE: new to VPN At 2:41 PM -0800 2/3/03, John Lindal wrote: > >> > There's a very large difference between a general purpose OS like >>>> Windows or Unix, and an embedded system OS. Large, as in several >>>> orders of magnitude. >>> >>>Unless I'm missing something fundamental, comparing the raw sizes of >>>various operating systems is misleading. Assuming that the VPN software is >>>installed at the bottom of the network stack, just above the NIC driver, >>>then it doesn't matter how big the rest of the OS is. The only thing that >>>matters is the tiny little bit of the OS that takes the packet off the NIC >>>and hands it to the VPN driver. >>> >>>Of course, this small part of the OS must not have any holes, the VPN >>>software must not have any holes, and the security policies must be set >>>correctly to weed out malicious or unwanted packets! >> >> I'm afraid you are missing something. Irrespectivbe of where the VPN >> software is installed in a general purpose platform/OS environment, >> that software can be subverted by a successful attack against any >> part of the rest of the OS. > >How can one attack the rest of the OS if the VPN component is located at >the only entry point and doesn't allow malicious packets to pass? > >> Your comment suggests that if the VPN access controls are working, then >> no evil packets can evade detection and thus be used to attack the higher >> layer software. We have lots of experience that indiactes otherwise. > >I think it's a matter of definitions. In any situation where malicious >packets get through the VPN filter, I would say that the access controls >are not working correctly :) John, I've often joked that when I was on the IAB for over a decade I missed the opportunity to define the "evil" bit in the IP header, which would flag malicious packets and make security so much easier :-) I know of no way to determine if a packet is malicious, in absolute terms. We characterize packets (or, more typically, sequences of packets) as malicious only once we understand the bad things than can happen, usually as a result of being the victim of an attack. So, detection of malicious packets is, in that sense, a two pass algorithm, with a possibly long with a possibly long interval between the passes. I didn't think that any firewall or IDS vendor really believed that it had filters or signatures or anomaly detection algorithms that were good enough to detect all malicious traffic. Thus, by your definition, ALL of these products have defective access controls. On what basis do you believe that your technology is capable of detecting and rejecting all malicious packets and thus is immune to attacks that might traverse the VPN component? Steve P.S. I think it would be better to not refer to functions like IDS as VPN components. The generally accepted terminology for VPNs is broad, bit I don't think most folks would claim that it encompasses Intrustion Detection. One may choose to provide IDS functions in the same box as IPsec, but the two are independent. From owner-ipsec@lists.tislabs.com Wed Feb 5 16:12:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h160CMd06363; Wed, 5 Feb 2003 16:12:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09870 Wed, 5 Feb 2003 18:44:22 -0500 (EST) Date: Wed, 5 Feb 2003 15:46:24 -0800 Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipsec@lists.tislabs.com To: "Theodore Ts'o" From: Derrell Piper In-Reply-To: Message-Id: <096D0EDE-3964-11D7-A519-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For purposes of consensus, here's my take on the two topics that Ted and Barbara have asked for comments on. A friend once remarked to me, "Go not to the elves for advice for they will say both 'yes' and 'no'..." RE: revised identity First, I sympathize with Cheryl and Scott in that we've been avoiding the larger problem from the start and it has continued to plague us at interoperability workshops. The lack of consideration for proper PKI integration is one of IKEv1's biggest omissions, that's clear. And yet here we are several years down the road and we still haven't been able to do anything about it. So, is now the right time and place to deal with it? Perhaps, but only if there were very strong consensus amongst existing vendors. I think revisions to the IKE ID specifications will be needed at some time in the future. The existing ID definitions are vague and ad hoc and yet we've still managed to garner a fair amount of interoperability despite it all. It hasn't necessarily been pleasant or easy, but over time most IKE implementations now do interoperate. Would the proposed identity revisions make things so much better that it would clear up some large majority of PKI interoperability problems? I don't think so. I think most of the problems are due somewhat to the inherent complexity of certificate-based PKI interoperability and, moreover, to the lack of a defined PKI profile for IKE. I happen to think there's more value in defining a PKI profile, such as the one described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need revised identities to do that. It seems similarly clear that revised identities would bring with them a new and entirely different set of interoperability issues. I have concerns that the management paradigm for many vendors is very closely tied to the existing IKE identity types, so wholesale revision in this area might well represent a serious headache for many vendors. The impact of the protocol changes is largely transparent and the other revisions ought to mostly present themselves as elimination of unnecessary configuration options. Deleting things is relative easy. But I can see how wholesale identity revision might seriously impact much of the existing management software, end-user documentation, and vendor regression testing. I think we do need to be concerned about fielded implementations. From an implementation standpoint, I also worry about combining something like identity revision with all the other IKEv2 changes. You'd essentially be starting from scratch at the next bake-off. Now I'm not going to claim lots and lots of code reuse between IKEv1 and IKEv2, yet there is some overlap. But if you completely rototill the identity processing on top of this, you're very close to starting from scratch. Anyone who lived through those early bake-off's would not want to go back there. Well, except for Big Al's BBQ Shack, perhaps. :-) Finally, if we're taking our deadline seriously, I don't think we're anywhere near consensus on what a revised identity proposal entails. Given the traffic just this week, there are many suggestions beyond what was originally discussed on the list last fall. Are there simple PKIX mappings? Are there simpler alternatives? IMHO, it's unlikely we're going to agree on such fundamental changes to identity representation in the next week. I think we should keep working on this as we should keep working on the PKI profile. But these items can occur orthogonally to IKEv2. In summary, our strategy of ignoring this has worked so well in the past that I recommend we continue it a while longer. RE: configuration mode vs. dhcp relay I'm on the fence with this one. I see good arguments for both approaches: there are simplicity arguments for MODECFG and there are richness arguments for DHCP. FWIW, the implementation I previously worked on was much closer to MODECFG. I'd welcome proposed text that explicitly shows the IKEv2 changes to support RFC3456. If we had that we could make a reasonable choice between the two. But absent that, I think we should pursue what we've got now and be willing to revisit this issue in the future. It's not an option to do nothing. IKEv2 needs a defined mechanism to dole out internal addresses to remote clients and MODECFG has been written up for IKEv2 and shown to work in IKEv1. IKEv2 is not viable without remote client support. Regards, Derrell On Thursday, January 30, 2003, at 02:57 PM, Theodore Ts'o wrote: > If you feel otherwise, please speak now. > > A) Revised identity > -------------------- > > Paul Hoffman has a proposal, draft-ietf-ipsec-revised-identity-00.txt, > which radically changes how identities are handled. Specifically, it > would eliminate the ID payload with the following types: > > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_RFC822_ADDR 3 > ID_IPV6_ADDR 5 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > > et.al, and replaces it with a FullID payload with the following types: > > 1 PKIX certificate > 2 Certificate bundle > 3 Hash-and-URL of PKIX certificate > 4 URL to a PKIX certificate bundle > 5 PKIX keyIdentifier > 6 IDForSharedSecret > > This would be fundamental change in the management and administraton of > IPSEC and IKE, so is not something to adopt lightly, and without a > clear > consensus of the working group. This was discussed in two threads on > the IPSEC mailing list: one starting on November 5th (subject Adding > revised identities to IKEv2), and one starting on December 8th > (subject: > Summary of revised identity changes). People who spoke in favor on the > mailing list included Francis Dupont and Bill Sommerfeld, with > qualified > support from Michael Richardson (if support for bare keys is added) and > Tero Kivinen (who is concerned about the complexity of the proposal). > > This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted > were left with the impression that there was not consensus among those > who met to discuss legacy authentication after the IPSEC wg meeting to > pursue adoption of Paul's proposed change. Paul believes otherwise. > Since it is the job of working group chairs to determine consensus, we > (Barbara and Ted) hereby ask that those who believe we should pursue > the > revised identity proposal to please speak up. > > It should be noted that there are some intermediate positions beyond > what is currently in draft-ietf-ipsec-ikev2-04.txt and the > revised-identies draft. For example, we could add the Hash-and-URL > type > to the Certificate payload, if the goal is shrink the size of IKE > messages (with the tradeoff of increasing complexity in IKE > implementations). We could also add a CERT hash type to the ID > payload, without nuking the traditional FQDN or IPv4/6 addresses > identity mechanisms (although again, by adding new types, we would be > increasing the complexity of the specification and implementations). > > Due the relatively small number of people who have spoken in favor of > this proposal or its less-radical alternates, the default choice for > IKEv2 has to be what is currently in ikev2-04. So those who believe we > should make this change (or those who strongly believe we should not) > are requested to speak up now, or forever hold your peace.... > > > B) DHCP-based vs. MODECFG style remote access configuration > ----------------------------------------------------------- > > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a > Configuration payload with defined attributes. An alternate mechanism > involves using tunneled DHCP requests. The latter approach is about to > be published as an RFC by the IPSRA working group. Proponents of this > method argue that it is more powerful than modecfg (because of the > extensibility and large number of options already specified for DHCP; > for example, being able to specify DNS, time, print, or WINS servers, > and so on.) It is also argued that it requires less code on the > server/firewall, since an existing DHCP server can be used. > > Proponents of the modecfg approach argue that many implementation > already have support for modecfg, and that setting up sort-lived > specialized tunnels to allow the DHCP packets to flow through the > gateway is kludgy, and requires multiple special case entries into > packet forwarding tables. Modecfg proponents also argue that it is > also > possible to transform modecfg requests into DHCP requests, so there are > implementation choices that do not require reimplementation of the > DHCP's address assignment function. They also point out that it > certainly is possible --- and in some ways easier --- to obtain the > time, print, WINS server information by using DHCP (via the DHCPINFORM > request) after the IPSEC tunnel is setup and the client address is > assigned. > > Either approach seems to be workable. It is certainly true that most > of > the people in Atlanta were implementors who were already familiar with > modecfg, representing a large implementation community. That being > said, there is also some number of working group members that are in > favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or > another, however we need to make a choice and move forward. > > Given that we have a fully specified solution in the ikev2-04 draft, > and > it would seem that while there is a sizeable minority in favor of the > ipsec-dhcp-13 approach, the majority are comfortable with the modecfg > based approach. So at this point, we, as working group chairs, judge > that the consensus is with the current approach. > > If there are those who feel otherwise, or who see fatal problems with > the current approach, please speak now. From owner-ipsec@lists.tislabs.com Wed Feb 5 17:45:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h161jUd08662; Wed, 5 Feb 2003 17:45:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10077 Wed, 5 Feb 2003 20:07:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A basic question. Date: Wed, 5 Feb 2003 17:08:49 -0800 Message-ID: <2EFAFC388B9C4C48B581846AEC20A0204A8484@scexch01.arc.com> Thread-Topic: A basic question. Thread-Index: AcLNe4PlUaE7XZJzQkeXM3yYt0pXqAAAFEwA From: "Roy, Gilles" To: "Bepsy Paul" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA10073 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You may be having MTU problems. You ICMP packets are probably all very small packets that don't need to be fragmented. The FTP packets are probably large enough that when you add the extra tunnel headers they need to be fragmented. You can confirm if fragmentation is an issue by pinging with large packets. Gilles -----Original Message----- From: Bepsy Paul [mailto:bepsy@airBB.com] Sent: Wednesday, February 05, 2003 3:26 PM To: ipsec@lists.tislabs.com Subject: A basic question. Hi, I am developing a VPN s/w for a small (9 engineers only) start-up company. I have developed a VPN with only 3DES and SHA-1-96 support and for TUNNEL mode. Now I am testing that with Safenet VPN client. My question is, the VPN tunnel works well with ICMP. But when I try FTP, it's not working. Can anyone point out any possible problem with FTP? I am processing ICMP, TCP and UDP packets in the same manner in IPSec output packet processing function. Your reply will be really appreciated. Bear with me for my simple question as I am just starting with VPNs. Thanks & Best Regards, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent Sent: Tuesday, February 04, 2003 6:02 PM To: John Lindal Cc: ipsec@lists.tislabs.com Subject: RE: new to VPN At 2:41 PM -0800 2/3/03, John Lindal wrote: > >> > There's a very large difference between a general purpose OS > like >>>> Windows or Unix, and an embedded system OS. Large, as in several >>>> orders of magnitude. >>> >>>Unless I'm missing something fundamental, comparing the raw sizes of >>>various operating systems is misleading. Assuming that the VPN >>>software is >>>installed at the bottom of the network stack, just above the NIC >>>driver, then it doesn't matter how big the rest of the OS is. The >>>only thing that >>>matters is the tiny little bit of the OS that takes the packet off >>>the NIC >>>and hands it to the VPN driver. >>> >>>Of course, this small part of the OS must not have any holes, the VPN >>>software must not have any holes, and the security policies must be >>>set correctly to weed out malicious or unwanted packets! >> >> I'm afraid you are missing something. Irrespectivbe of where the VPN >> software is installed in a general purpose platform/OS environment, >> that software can be subverted by a successful attack against any >> part of the rest of the OS. > >How can one attack the rest of the OS if the VPN component is located >at the only entry point and doesn't allow malicious packets to pass? > >> Your comment suggests that if the VPN access controls are working, >> then no evil packets can evade detection and thus be used to attack >> the higher >> layer software. We have lots of experience that indiactes otherwise. > >I think it's a matter of definitions. In any situation where malicious >packets get through the VPN filter, I would say that the access >controls are not working correctly :) John, I've often joked that when I was on the IAB for over a decade I missed the opportunity to define the "evil" bit in the IP header, which would flag malicious packets and make security so much easier :-) I know of no way to determine if a packet is malicious, in absolute terms. We characterize packets (or, more typically, sequences of packets) as malicious only once we understand the bad things than can happen, usually as a result of being the victim of an attack. So, detection of malicious packets is, in that sense, a two pass algorithm, with a possibly long with a possibly long interval between the passes. I didn't think that any firewall or IDS vendor really believed that it had filters or signatures or anomaly detection algorithms that were good enough to detect all malicious traffic. Thus, by your definition, ALL of these products have defective access controls. On what basis do you believe that your technology is capable of detecting and rejecting all malicious packets and thus is immune to attacks that might traverse the VPN component? Steve P.S. I think it would be better to not refer to functions like IDS as VPN components. The generally accepted terminology for VPNs is broad, bit I don't think most folks would claim that it encompasses Intrustion Detection. One may choose to provide IDS functions in the same box as IPsec, but the two are independent. From owner-ipsec@lists.tislabs.com Wed Feb 5 19:08:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1638Td11023; Wed, 5 Feb 2003 19:08:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10294 Wed, 5 Feb 2003 21:29:21 -0500 (EST) Message-ID: <00da01c2cd87$f4e56ab0$93f4220a@amer.cisco.com> From: "Scott Fanning" To: "Scott G. Kelly" , Cc: References: <3E416B5C.777F7AC0@bstormnetworks.com> Subject: Re: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Wed, 5 Feb 2003 18:32:12 -0800 Organization: Cisco Systems 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In actuality, most service providers use RADIUS as a server to get ip address, so how does DHCP fit in that (+ many other service provider specific attributes)? Do we have to now translate between DHCP and RADIUS? DHCP is not the only way to get addresses, but mode config allows the security GW to be flexible on how ip addresses are acquired. I also vote against the special SA. Having to create an SA, then to find out that the ip address pool is exhausted, seems like alot of state to deal with. As for inside attacks, maybe you should talk to "security" experts who seem to indicate that 59% of attacks are from the inside of the network. "In the 2002 CPI/FBI survey, for instance, 59 percent of organizations surveyed admitted to at least one internal attack." Yeah, the RADIUS server is vulnerable too, but at least you don't waste QM mode. Anyway, my two cents. I am sure you will shoot it down. This is a good debate. Too bad it was not this vigorous during the standardization process. Oh yes, it was, but it was out of scope, out of charter. Scott ----- Original Message ----- From: "Scott G. Kelly" To: Cc: Sent: Wednesday, February 05, 2003 11:51 AM Subject: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] > Come on, Darren - you must be joking. What you describe is not an attack > against RFC3456 - it's an attack against DHCP/BOOTP, and this is nothing > new. If you run DHCP on your network and you have malicious insiders, > they can do all sorts of things. The same applies for most other > commonly run lan protocols. And since you've already conceded that a > scalable modecfg implementation will be running dhcp on the backend, > what is the point of this post? > > Let's stick with arguments with technical merit. > > Scott > > Darren Dukes wrote: > > > > Amendment: > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a manufactured > > DHCP Relay Agent Information Option or one copied from a previous DHCP > > message. > > > > > -----Original Message----- > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > This attack is based on the thread defined in RFC3118 > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > new route for whatever address Eve puts in yiaddr. > > > > > > |-Eve > > > IRAC ---- SGW -| > > > |-DHCP Server > > > > > > excerpt from RFC3456: > > > To learn the internal IP address of the client in order to route > > > packets to it, the security gateway will typically snoop the yiaddr > > > field within the DHCPACK and plumb a corresponding route as part of > > > DHCP Relay processing. > > > > > > This attack is not resolved by the implementation of RFC3118 > > > unless the following changes are made to the DHCP-relay. > > > 1 - It stored a copy of all secret keys contained on the > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > copy of the master key and used that to generate the client keys > > > as described in RFC3118 Appendix A. > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > Darren > > > > From owner-ipsec@lists.tislabs.com Wed Feb 5 19:31:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h163Vod11991; Wed, 5 Feb 2003 19:31:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10348 Wed, 5 Feb 2003 22:05:34 -0500 (EST) Message-ID: <82CC1E573B94A648B87027C9419E2C055A6B5D@losgatos> From: Michael Choung Shieh To: "'sommerfeld@east.sun.com'" , Marcus Leech Cc: ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Wed, 5 Feb 2003 19:03:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, February 05, 2003 12:44 PM > To: Marcus Leech > Cc: ipsec@lists.tislabs.com > Subject: Re: Modefg considered harmful > > > > Me too, but there was this issue of the large installed base of > > MODECFG-like things in existing implementations. Since I'm not > > an implementor, I'm in the situation where I have to believe that > > moving away from a MODECFG-like thing is a hardship. > > Except that you probably *already* have a DHCP implementation already! > > I believe the correct comparison is the complexity of MODECFG vs the > "DHCP to IPsec glue" code; the latter is likely to be significantly > smaller than the former. > The comparison probably is not fair. Since most have MODE-CFG in their implementation, Most vendors probably have both MODECFG & DHCP codes. So the comparison is the complexity of adapt MODECFG to IKEv2 vs "DHCP to IPsec glue" code. The latter is much more complex and harder to get interoperable. > > *If* it's acceptablet to discount such claimed hardship, > then I have to > > agree with Bernards assertion that the IPSRA-style DHCP > approach is > > cleaner, more flexible, and in the long-term, less work. > > indeed. > > - Bill > > ======================= Michael Shieh From owner-ipsec@lists.tislabs.com Wed Feb 5 21:45:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h165jpd15275; Wed, 5 Feb 2003 21:45:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10634 Thu, 6 Feb 2003 00:08:40 -0500 (EST) Reply-To: From: "Balaji K" To: "'Roy, Gilles'" , "'Bepsy Paul'" Cc: Subject: RE: A basic question. Date: Thu, 6 Feb 2003 10:38:47 +0530 Message-Id: <000a01c2cd9d$d4e915c0$2906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2EFAFC388B9C4C48B581846AEC20A0204A8484@scexch01.arc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Disposition-Notification-To: "Balaji K" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Yes FTP are large packets. When a IPSec Router Recieves a packet of Size 1500 bytes the packet again needs to be Fragmented by IPSec because of the OverHead Added by it (Size of the Packet will exceed 1500 bytes). Safenet Client has to Reassemble the packet before decoding it. It Seem's to be problem in some versions of SafeNet Client with respcet to reassembly . SafeNet Client was not able to reassemble the Fragmented packets of Linux Router (Linux IP Stack). Even if you try a Ping from Host with more than 1500 bytes you will not get a response from Safenet Client Regards Balaji.K -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Roy, Gilles Sent: Thursday, February 06, 2003 6:39 AM To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: A basic question. You may be having MTU problems. You ICMP packets are probably all very small packets that don't need to be fragmented. The FTP packets are probably large enough that when you add the extra tunnel headers they need to be fragmented. You can confirm if fragmentation is an issue by pinging with large packets. Gilles -----Original Message----- From: Bepsy Paul [mailto:bepsy@airBB.com] Sent: Wednesday, February 05, 2003 3:26 PM To: ipsec@lists.tislabs.com Subject: A basic question. Hi, I am developing a VPN s/w for a small (9 engineers only) start-up company. I have developed a VPN with only 3DES and SHA-1-96 support and for TUNNEL mode. Now I am testing that with Safenet VPN client. My question is, the VPN tunnel works well with ICMP. But when I try FTP, it's not working. Can anyone point out any possible problem with FTP? I am processing ICMP, TCP and UDP packets in the same manner in IPSec output packet processing function. Your reply will be really appreciated. Bear with me for my simple question as I am just starting with VPNs. Thanks & Best Regards, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent Sent: Tuesday, February 04, 2003 6:02 PM To: John Lindal Cc: ipsec@lists.tislabs.com Subject: RE: new to VPN At 2:41 PM -0800 2/3/03, John Lindal wrote: > >> > There's a very large difference between a general purpose OS > like >>>> Windows or Unix, and an embedded system OS. Large, as in several >>>> orders of magnitude. >>> >>>Unless I'm missing something fundamental, comparing the raw sizes of >>>various operating systems is misleading. Assuming that the VPN >>>software is >>>installed at the bottom of the network stack, just above the NIC >>>driver, then it doesn't matter how big the rest of the OS is. The >>>only thing that >>>matters is the tiny little bit of the OS that takes the packet off >>>the NIC >>>and hands it to the VPN driver. >>> >>>Of course, this small part of the OS must not have any holes, the VPN >>>software must not have any holes, and the security policies must be >>>set correctly to weed out malicious or unwanted packets! >> >> I'm afraid you are missing something. Irrespectivbe of where the VPN >> software is installed in a general purpose platform/OS environment, >> that software can be subverted by a successful attack against any >> part of the rest of the OS. > >How can one attack the rest of the OS if the VPN component is located >at the only entry point and doesn't allow malicious packets to pass? > >> Your comment suggests that if the VPN access controls are working, >> then no evil packets can evade detection and thus be used to attack >> the higher >> layer software. We have lots of experience that indiactes otherwise. > >I think it's a matter of definitions. In any situation where malicious >packets get through the VPN filter, I would say that the access >controls are not working correctly :) John, I've often joked that when I was on the IAB for over a decade I missed the opportunity to define the "evil" bit in the IP header, which would flag malicious packets and make security so much easier :-) I know of no way to determine if a packet is malicious, in absolute terms. We characterize packets (or, more typically, sequences of packets) as malicious only once we understand the bad things than can happen, usually as a result of being the victim of an attack. So, detection of malicious packets is, in that sense, a two pass algorithm, with a possibly long with a possibly long interval between the passes. I didn't think that any firewall or IDS vendor really believed that it had filters or signatures or anomaly detection algorithms that were good enough to detect all malicious traffic. Thus, by your definition, ALL of these products have defective access controls. On what basis do you believe that your technology is capable of detecting and rejecting all malicious packets and thus is immune to attacks that might traverse the VPN component? Steve P.S. I think it would be better to not refer to functions like IDS as VPN components. The generally accepted terminology for VPNs is broad, bit I don't think most folks would claim that it encompasses Intrustion Detection. One may choose to provide IDS functions in the same box as IPsec, but the two are independent. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipsec@lists.tislabs.com Thu Feb 6 03:14:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BEFd25922; Thu, 6 Feb 2003 03:14:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11578 Thu, 6 Feb 2003 05:42:13 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F18@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Tylor Allison'" Cc: "'ddukes@cisco.com'" , Michael Richardson , ipsec@lists.tislabs.com, "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Thu, 6 Feb 2003 11:44:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Allison, See my comments below. Dirk. > -----Original Message----- > From: Tylor Allison [mailto:allison@securecomputing.com] > Sent: woensdag 5 februari 2003 20:56 > To: Van Aken Dirk > Cc: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com; > Scott G. Kelly > Subject: RE: Modefg considered harmful > > > I've been following this discussion for a bit now, but must > admit that I'm > still coming up to speed on how rfc.3456 is intended to work, > so please > bear with me. For background, I have implemented Mode-Config, but not > rfc.3456. > > On Wed, 5 Feb 2003, Van Aken Dirk wrote: > > > Hi Darren, > > > > See my comments below. > > > > > Regarding your comments about modecfg, there is no need for > > > an address pool > > > on the LargeIPsecGW since it could act as a DHCP-client when > > > it receives > > > modecfg requests from an IRAC instead of having its ipsec > > > engine sniffing > > > for inbound DHCP packets and forwarding them to the internal > > > DHCP relay. > > > > > > Darren. > > > > The IPSec engine must not sniff on DHCP packets. As said before, > > implementing RFC3456 can IMHO happen almost completely > outside the IKE and > > IPSec code! More specific, a DHCP discover arriving via an > IPSec tunnel has > > a source address (0,0) and destination address (-1,-1). > After passing > > through the SPD, this packet must be delivered locally, > that is, to the > > internal IP host of the IPSec GW (see RFC1812-section > 5.2.3). The local host > > is configured with a DHCP relay that is listening on UDP > port 67 (DHCP > > server port). This DHCP relay can either forward the > request to an internal > > DHCP server or relay it to an external DHCP server. The > only IPSec specific > > item that the relay must take care of is that replies from > the server must > > end-up in the correct "DHCP-tunnel". This can be > accomplished via the DHCP > > Relay Information Option/sub-options. i.e. The DHCP relay > must "tag" the > > DHCP requests (e.g. with the Tunnel IP address, Tunnel port > number) in the > > direction towards the DHCP server and must "untag" the DHCP > replies and use > > this tag to look-up the correct tunnel in the direction > towards the DHCP > > client (see section 4.2 of RFC3456). > > Regarding the DHCP relay to IPSEC tunnel selection, rfc.3456 > gives several > options on how this may be done... one of which is the Relay > Info Option. > The question I have is whether or not you can count on DHCP servers > supporting this option (can you count on all servers supporting this)? The DHCP Relay Agent Information Option (RFC3046) is a basic building block and must be used in combination with sub-options. such as the ones defined in the same RFC: - Agent Circuit ID Sub-option - Agent Remote ID Sub-option In following draft RFC's new suboptions are defined: () - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 - VPN Identifier sub-option for the Relay Agent Information Option - DHCP Subscriber ID Suboption for the DHCP Relay Agent Option As you will notice RFC3046 is a rather recent option i.e. looking at the date of RFC3046 (jan 2001). So it might be that you currently find limited support for this RFC. However given the fact that there are already 3 new sub-options, my feeling is that it is a matter of time whether industry strength servers will have full support for RFC3046 and its extensions. At least following servers support RFC3046: (I can't find detailed info regarding the supported options but it has been told to me RFC3046 is included) (this one is an incarnation of the ICS server). BTW: the ICS server is often used as a reference implementation. > If this option is not supported, this means another method > for determining > the tunnel selection must be used, and the only viable option > that I can > think of is for the SGW to keep the state table mentioned > which tracks the > DHCP transaction to the IPSEC tunnel. Correct. > > You state that the IKE/IPSEC engine must not sniff the DHCP > packets... but > that's in opposition to what's suggested in rfc.3456... > > "To learn the internal IP address of the client in order to route > packets to it, the security gateway will typically snoop > the yiaddr > field within the DHCPACK and plumb a corresponding route > as part of > the DHCP Relay processing." Better wording would be: the DHCP relay in the security gateway will typically snoop the yiaddr field within the DHCPACK and plumb a corresponding route as part of the DHCP Relay processing. > > My biggest concern here is where the enforcement of client to > virtual IP > mapping happening? Or is this not a desired goal/capability > for remote > access? For example, if I have Joe User who should always receive IP > 10.1.1.111, and I setup a security policy which allows the > 10.1.1.111 to > have special access privileges, how can I guarantee that > someone besides > Joe can't obtain the 10.1.1.111 address? The security > concerns section for > rfc.3456 states that the assigned address MUST NOT be > depended upon for > security. DHCP has a few mechanism for assigning a particular IP addresses to a specific client (so called static leases). > > This sort of access control can be done easily w/ > Mode-Config, as IKE knows > the address which should be assigned to the client and can setup the > allowed Quick Mode selectors appropriately. In case the relation host-VPNclient is 1:1 agree with you that on the part of access control Mode-Config can accomplish this easily just because it possesses the identity and has direct access to the SPD. But I thought IPSec was not about access control but I can be wrong on this. However I wonder how Mode-Config is going to cope with a situation where there are multiple hosts behind the VPN client (host-VPNclient relation X:1). > > > So to conclude: > > - I don't have to touch the IKE code > > While this may be true, I don't believe it carries the same > weight as it > used to, since we're working on defining what the IKEv2 code should > actually be. > > > - I don't have to touch IPSec code > > This isn't totally true, is it? You have to add the glue which > inserts/extracts the DHCP traffic into the IPSEC tunnel. IMHO not, as said in my previous email, as soon as the DHCP packets passes the SPD it is standard IP forwarding/host delivery behaviour. It depends of course how your IP stack is implemented. > You also have to > deal with the management of the DHCP-specific IPSEC SA For me this is policy that is configured in the SPD just like any other policy. and > setting up of > the dynamic SPD entries associated with the assigned address. Well the DHCP relay is a host process in the sense that it can be modified such that it has access to PF_Key (RFC2367). As you might know PF_Key is an API that allow applications to communicate with the Security Association Database (SADB). To have access the SPD we had to use the private extension of PF_Key. And indeed for the private extension we had to make minor changes to IPSec code. However if there was an PF_Policy this could have been avoided. To summarize, the DHCP relay talks to the IPSec code via well defined interfaces. I hope this clarified my point of view ? > > > - I might have to change DHCP relay code but this technology is well > > understood > > - my IP parameter distribution method is in-line with the > rest of the > > network infrastucture and inherits an existing and rich feature set. > > > > Best regards - Dirk > > I'm struggling here because I'm not sure I totally like > either solution > that's being offered. My biggest complaints with RFC.3456 are the > specialized IPSEC SA required for DHCP traffic and the lack > of control on > address assignment. This is an argument that seems to come back and I have he feeling that I miss something here. In previous emails the DHCP SA's were termed "weird". But to me it are just SA's that have specific selectors (any/any/UDP/68/67) and indeed they are short lived. But apart from that I don't consider them special; of course my background is more in networking than in IPSec so maybe you can elaborate a little bit more on this topic. e.g. It might be that IPSec "centric"-people don't feel comfortable with "any" for both source and destination address in an SPD entry. I can understand your argument on the lack of control of address assignment but this is an IKE centric view on security. > > Mode-Config for IKEv1 had a similar problem to rfc.3456 for > SA management, > as MC was a "phase 1.5" exchange, causing headaches in the IKE state > tables. This seems to be solved in IKEv2 by the fact that > the MC payloads > are now inline in the base phase 1 exchange. I would agree, > however that > MC does duplicate the purpose of DHCP. > > The solution? The ideal solution in my mind would be to > still use DHCP, > but have the initial DHCP traffic pass through IKE instead of IPSEC. > Either attempt to introduce the DHCP payloads directly into > the phase 1 > exchange (similar to what's proposed for MC), or to instantiate a new > exchange for the DHCP traffic. IKE would be required to > parse a minimum > number of DHCP attributes in order to determine some base > info, like the > assigned IP address. > > If such a solution is not possible, then I'd prefer to keep > the current > Mode-Config proposal as described in the IKEv2 draft. We can keep the > scope of MC to be very simple... address assignment for the > remote peer. > Once a VPN is established, any other network configuration > parameters can > be determined via the DHCPINFORM method. To be honest I'm very afraid of these "mixed" solutions just because of my bad experiences in PPP-IPCP combined with DHCP. Just looking at the stricking resemblance of the IKEv2 ModeCfg attributes and the PPP-IPCP options I guess we will be stuck with an identical problem. > > My $.02 worth. It was worth more than $.02 as your arguments were about pro and con of both solutions. And maybe I should analyse the IKEv1 ModeCfg implementations more in detail to show the limitations in various scenario's. However to fuel this discussion up till now, it took quite some investment from my side. i.e. I'm not just discussing; I did experiments in our labs with commercially available equipment and I don't have the time to continue like this. Anyway as a few people already expressed that both ModeCFG and DHCP might have pro's and con's I wonder whether both solutions (or at least a pointer to RFC3456) can be specified in the IKEv2 RFC. It is up to the implementers then to choose the appropriate solution (and its inherent shortcomings). > > ===================================================================== > = Tylor Allison Secure Computing Corporation ========= > ===================================================================== > > From owner-ipsec@lists.tislabs.com Thu Feb 6 03:29:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BTZd26342; Thu, 6 Feb 2003 03:29:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA11659 Thu, 6 Feb 2003 06:03:23 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F19@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Scott G. Kelly'" , ddukes@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Thu, 6 Feb 2003 12:05:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Scott, IPSec is not going to solve this kind of security issues. i.e. IPSec was not conceived to cope with the situation where the frontdoor is open and where there is no backdoor. People having access to a central offices are assumed to be trusted ! I would agree with you Darren, if this same scenario would work form the VPN client side because there is far less control on who is sitting behind the VPN client. If you can convice me that ModeCfg has no inherent limitations or that the DHCP based method has serious flaws, please tell me. If so, I'm willing to change my religion. BTW If IPSec must also cope with malicous insiders, then I know a very simple but effective attack on the security solution provided by a certain company ... > -----Original Message----- > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > Sent: woensdag 5 februari 2003 20:52 > To: ddukes@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > RFC3456.] > > > Come on, Darren - you must be joking. What you describe is > not an attack > against RFC3456 - it's an attack against DHCP/BOOTP, and this > is nothing > new. If you run DHCP on your network and you have malicious insiders, > they can do all sorts of things. The same applies for most other > commonly run lan protocols. And since you've already conceded that a > scalable modecfg implementation will be running dhcp on the backend, > what is the point of this post? > > Let's stick with arguments with technical merit. > > Scott > > Darren Dukes wrote: > > > > Amendment: > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with > a manufactured > > DHCP Relay Agent Information Option or one copied from a > previous DHCP > > message. > > > > > -----Original Message----- > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > This attack is based on the thread defined in RFC3118 > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > new route for whatever address Eve puts in yiaddr. > > > > > > |-Eve > > > IRAC ---- SGW -| > > > |-DHCP Server > > > > > > excerpt from RFC3456: > > > To learn the internal IP address of the client in > order to route > > > packets to it, the security gateway will typically > snoop the yiaddr > > > field within the DHCPACK and plumb a corresponding > route as part of > > > DHCP Relay processing. > > > > > > This attack is not resolved by the implementation of RFC3118 > > > unless the following changes are made to the DHCP-relay. > > > 1 - It stored a copy of all secret keys contained on the > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > copy of the master key and used that to generate the client keys > > > as described in RFC3118 Appendix A. > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > Darren > > > > From owner-ipsec@lists.tislabs.com Thu Feb 6 05:02:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16D2Pd05147; Thu, 6 Feb 2003 05:02:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11897 Thu, 6 Feb 2003 07:30:54 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F1B@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Scott Fanning'" , "Scott G. Kelly" , ddukes@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Thu, 6 Feb 2003 13:33:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, You are correct that RADIUS is well entrenched in the ISP world. Basically what it does is perform user authentication and depending on the user profile, assigns a specific address to the user. This address comes from a pool either managed by the RADIUS server itself or from a DHCP server that is collocated with the RADIUS server. Without RADIUS, the Access Servers must perform the user authentication because protocols such as PPP are link layer (unless tunnelled in L2TP/L2F/PPTP). Offloading this part of Access Servers is logical because Access Servers are dedicated hardware devices. In addition a Service Provider who has customers at different ISP's can centralize it's user authentication service. Of course IP addresses still must come from the individual ISP's pools in order to fit in the Internet routing structure. However I'm intrigued how VPN fits into this scenario ? i.e. Am I going to set-up a VPN session with my ISP ? In that way my traffic is encrypted between me and the ISP but how does it travel from there ? Over an MPLS cloud or is a new VPN tunnel set up to my corporate ? Additionally the Virtual IP address that is assigned to the VPN client must belong to my corporate LAN so is the ISP's RADIUS server going to manage an address pool carved out of my corporate LAN address space ? BTW, RADUIS has strong links with PPP and as said before, the IKEModeCFG attributes have sticking resemblance with PPP hence shares its limitations ... Best regards - Dirk > -----Original Message----- > From: Scott Fanning [mailto:sfanning@cisco.com] > Sent: donderdag 6 februari 2003 3:32 > To: Scott G. Kelly; ddukes@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Sensationalism? [was Re: FW: Man in the middle attack > against RFC3456.] > > > In actuality, most service providers use RADIUS as a server to get ip > address, so how does DHCP fit in that (+ many other service provider > specific attributes)? Do we have to now translate between > DHCP and RADIUS? > DHCP is not the only way to get addresses, but mode config allows the > security GW to be flexible on how ip addresses are acquired. > > I also vote against the special SA. Having to create an SA, > then to find out > that the ip address pool is exhausted, seems like alot of > state to deal > with. > > As for inside attacks, maybe you should talk to "security" > experts who seem > to indicate that 59% of attacks are from the inside of the network. > > "In the 2002 CPI/FBI survey, for instance, 59 percent of organizations > surveyed admitted to at least one internal attack." > > Yeah, the RADIUS server is vulnerable too, but at least you > don't waste QM > mode. > > Anyway, my two cents. I am sure you will shoot it down. This is a good > debate. Too bad it was not this vigorous during the > standardization process. > Oh yes, it was, but it was out of scope, out of charter. > > Scott > ----- Original Message ----- > From: "Scott G. Kelly" > To: > Cc: > Sent: Wednesday, February 05, 2003 11:51 AM > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > RFC3456.] > > > > Come on, Darren - you must be joking. What you describe is > not an attack > > against RFC3456 - it's an attack against DHCP/BOOTP, and > this is nothing > > new. If you run DHCP on your network and you have malicious > insiders, > > they can do all sorts of things. The same applies for most other > > commonly run lan protocols. And since you've already conceded that a > > scalable modecfg implementation will be running dhcp on the backend, > > what is the point of this post? > > > > Let's stick with arguments with technical merit. > > > > Scott > > > > Darren Dukes wrote: > > > > > > Amendment: > > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a > manufactured > > > DHCP Relay Agent Information Option or one copied from a > previous DHCP > > > message. > > > > > > > -----Original Message----- > > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > > > > There is a man in the middle attack on the DHCP-relay > in RFC3456. > > > > This attack is based on the thread defined in RFC3118 > > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > > source DHCPACK packets, if Eve sends a DHCPACK to a an > IRAC via a > > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > > new route for whatever address Eve puts in yiaddr. > > > > > > > > |-Eve > > > > IRAC ---- SGW -| > > > > |-DHCP Server > > > > > > > > excerpt from RFC3456: > > > > To learn the internal IP address of the client in > order to route > > > > packets to it, the security gateway will typically > snoop the yiaddr > > > > field within the DHCPACK and plumb a corresponding > route as part of > > > > DHCP Relay processing. > > > > > > > > This attack is not resolved by the implementation of RFC3118 > > > > unless the following changes are made to the DHCP-relay. > > > > 1 - It stored a copy of all secret keys contained on the > > > > DHCP-server and used them to authenticate DHCPACKs or > it stored a > > > > copy of the master key and used that to generate the client keys > > > > as described in RFC3118 Appendix A. > > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > > > > Darren > > > > > > > From owner-ipsec@lists.tislabs.com Thu Feb 6 05:54:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16DsOd09450; Thu, 6 Feb 2003 05:54:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12123 Thu, 6 Feb 2003 08:26:32 -0500 (EST) From: "Victor Volpe" To: "'Theodore Ts'o'" Cc: Subject: RE: Moving forward with IKE V2: A proposal for final edits to ikev2-04 Date: Wed, 5 Feb 2003 23:34:19 -0500 Message-ID: <03ed01c2cd99$03f95f00$6501a8c0@amer.cisco.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <096D0EDE-3964-11D7-A519-000393CDFD1A@electric-loft.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here are my thoughts on the 2 issues: 1. On the modecfg vs DHCP - I prefer modecfg. We have used it for years without issue. It is easy to implement and understand, it is self-contained, it does not require additional SAs and is easily extensible. Not only have we added many modecfg attributes to solve customer issues in the past but we have been able to easily coordinate the new attributes with RADIUS via vendor specific attributes for a complete solution. Adding LDAP to this proxy scheme has also been very easy. How easy would it be to implement a "complete" solution via DHCP. It seems to me that we would have 2 options with DHCP. We either pass DHCP through to a DHCP server and make it transparent to IKE/IPsec, or we intercept the DHCP request and proxy it to RADIUS or LDAP. In my opinion, the former option is not really an option. We can not use DHCP servers for anything other than IP address assignment. If we told our customers that they need to set up user-based configuration attributes on their DHCP server, they would quickly throw us out. The latter option (proxy) would work but is more difficult to implement than modecfg. The difficulty comes with the loose coupling to user tunnels and the additional SA. 2. I find Paul's naming convention very confusing (maybe it is because I am not up on the latest PKIX requirements). I like the old naming convention because they are core names and not abstractions of names. By this I mean that a core name can be used in several different scenarios (if all the scenarios have the same ID requirement) as long as the core ID requirement is well documented. The abstractions, at least to me, may be more intuitive, but could cause an ID explosion as more and more abstractions are introduced. The worst case is that many abstract IDs really map to the same core ID. What I would really like to see is a decrease in the number of IDS. It would be nice to cover all the bases with 2 or 3 IDs and properly document the use of the IDs. Victor > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper > Sent: Wednesday, February 05, 2003 6:46 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: Moving forward with IKE V2: A proposal for final edits to > ikev2-04 > > > For purposes of consensus, here's my take on the two topics that Ted > and Barbara have asked for comments on. A friend once > remarked to me, > "Go not to the elves for advice for they will say both 'yes' and > 'no'..." > > RE: revised identity > > First, I sympathize with Cheryl and Scott in that we've been avoiding > the larger problem from the start and it has continued to > plague us at > interoperability workshops. The lack of consideration for proper PKI > integration is one of IKEv1's biggest omissions, that's > clear. And yet > here we are several years down the road and we still haven't > been able > to do anything about it. So, is now the right time and place to deal > with it? Perhaps, but only if there were very strong > consensus amongst > existing vendors. > > I think revisions to the IKE ID specifications will be needed at some > time in the future. The existing ID definitions are vague and ad hoc > and yet we've still managed to garner a fair amount of > interoperability > despite it all. It hasn't necessarily been pleasant or easy, > but over > time most IKE implementations now do interoperate. > > Would the proposed identity revisions make things so much better that > it would clear up some large majority of PKI interoperability > problems? > I don't think so. I think most of the problems are due somewhat to > the inherent complexity of certificate-based PKI > interoperability and, > moreover, to the lack of a defined PKI profile for IKE. I happen to > think there's more value in defining a PKI profile, such as the one > described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need > revised identities to do that. It seems similarly clear that revised > identities would bring with them a new and entirely different set of > interoperability issues. > > I have concerns that the management paradigm for many vendors is very > closely tied to the existing IKE identity types, so wholesale > revision > in this area might well represent a serious headache for many > vendors. > The impact of the protocol changes is largely transparent and > the other > revisions ought to mostly present themselves as elimination of > unnecessary configuration options. Deleting things is > relative easy. > But I can see how wholesale identity revision might seriously impact > much of the existing management software, end-user documentation, and > vendor regression testing. I think we do need to be concerned about > fielded implementations. > > From an implementation standpoint, I also worry about combining > something like identity revision with all the other IKEv2 changes. > You'd essentially be starting from scratch at the next bake-off. Now > I'm not going to claim lots and lots of code reuse between IKEv1 and > IKEv2, yet there is some overlap. But if you completely rototill the > identity processing on top of this, you're very close to > starting from > scratch. Anyone who lived through those early bake-off's would not > want to go back there. Well, except for Big Al's BBQ Shack, > perhaps. > :-) > > Finally, if we're taking our deadline seriously, I don't think we're > anywhere near consensus on what a revised identity proposal entails. > Given the traffic just this week, there are many suggestions beyond > what was originally discussed on the list last fall. Are > there simple > PKIX mappings? Are there simpler alternatives? IMHO, it's unlikely > we're going to agree on such fundamental changes to identity > representation in the next week. I think we should keep working on > this as we should keep working on the PKI profile. But these > items can > occur orthogonally to IKEv2. > > In summary, our strategy of ignoring this has worked so well in the > past that I recommend we continue it a while longer. > > RE: configuration mode vs. dhcp relay > > I'm on the fence with this one. I see good arguments for both > approaches: there are simplicity arguments for MODECFG and there are > richness arguments for DHCP. FWIW, the implementation I previously > worked on was much closer to MODECFG. > > I'd welcome proposed text that explicitly shows the IKEv2 changes to > support RFC3456. If we had that we could make a reasonable choice > between the two. But absent that, I think we should pursue > what we've > got now and be willing to revisit this issue in the future. > > It's not an option to do nothing. IKEv2 needs a defined mechanism to > dole out internal addresses to remote clients and MODECFG has been > written up for IKEv2 and shown to work in IKEv1. IKEv2 is not viable > without remote client support. > > Regards, > > Derrell > > On Thursday, January 30, 2003, at 02:57 PM, Theodore Ts'o wrote: > > > If you feel otherwise, please speak now. > > > > A) Revised identity > > -------------------- > > > > Paul Hoffman has a proposal, > draft-ietf-ipsec-revised-identity-00.txt, > > which radically changes how identities are handled. > Specifically, it > > would eliminate the ID payload with the following types: > > > > ID_IPV4_ADDR 1 > > ID_FQDN 2 > > ID_RFC822_ADDR 3 > > ID_IPV6_ADDR 5 > > ID_DER_ASN1_DN 9 > > ID_DER_ASN1_GN 10 > > ID_KEY_ID 11 > > > > et.al, and replaces it with a FullID payload with the > following types: > > > > 1 PKIX certificate > > 2 Certificate bundle > > 3 Hash-and-URL of PKIX certificate > > 4 URL to a PKIX certificate bundle > > 5 PKIX keyIdentifier > > 6 IDForSharedSecret > > > > This would be fundamental change in the management and > administraton of > > IPSEC and IKE, so is not something to adopt lightly, and without a > > clear > > consensus of the working group. This was discussed in two > threads on > > the IPSEC mailing list: one starting on November 5th (subject Adding > > revised identities to IKEv2), and one starting on December 8th > > (subject: > > Summary of revised identity changes). People who spoke in > favor on the > > mailing list included Francis Dupont and Bill Sommerfeld, with > > qualified > > support from Michael Richardson (if support for bare keys > is added) and > > Tero Kivinen (who is concerned about the complexity of the > proposal). > > > > This proposal was discussed in Atlanta, but Charlie, > Barbara, and Ted > > were left with the impression that there was not consensus > among those > > who met to discuss legacy authentication after the IPSEC wg > meeting to > > pursue adoption of Paul's proposed change. Paul believes otherwise. > > Since it is the job of working group chairs to determine > consensus, we > > (Barbara and Ted) hereby ask that those who believe we > should pursue > > the > > revised identity proposal to please speak up. > > > > It should be noted that there are some intermediate positions beyond > > what is currently in draft-ietf-ipsec-ikev2-04.txt and the > > revised-identies draft. For example, we could add the Hash-and-URL > > type > > to the Certificate payload, if the goal is shrink the size of IKE > > messages (with the tradeoff of increasing complexity in IKE > > implementations). We could also add a CERT hash type to the ID > > payload, without nuking the traditional FQDN or IPv4/6 addresses > > identity mechanisms (although again, by adding new types, > we would be > > increasing the complexity of the specification and implementations). > > > > Due the relatively small number of people who have spoken > in favor of > > this proposal or its less-radical alternates, the default choice for > > IKEv2 has to be what is currently in ikev2-04. So those > who believe we > > should make this change (or those who strongly believe we > should not) > > are requested to speak up now, or forever hold your peace.... > > > > > > B) DHCP-based vs. MODECFG style remote access configuration > > ----------------------------------------------------------- > > > > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a > > Configuration payload with defined attributes. An > alternate mechanism > > involves using tunneled DHCP requests. The latter approach > is about to > > be published as an RFC by the IPSRA working group. > Proponents of this > > method argue that it is more powerful than modecfg (because of the > > extensibility and large number of options already specified > for DHCP; > > for example, being able to specify DNS, time, print, or > WINS servers, > > and so on.) It is also argued that it requires less code on the > > server/firewall, since an existing DHCP server can be used. > > > > Proponents of the modecfg approach argue that many implementation > > already have support for modecfg, and that setting up sort-lived > > specialized tunnels to allow the DHCP packets to flow through the > > gateway is kludgy, and requires multiple special case entries into > > packet forwarding tables. Modecfg proponents also argue that it is > > also > > possible to transform modecfg requests into DHCP requests, > so there are > > implementation choices that do not require reimplementation of the > > DHCP's address assignment function. They also point out that it > > certainly is possible --- and in some ways easier --- to obtain the > > time, print, WINS server information by using DHCP (via the > DHCPINFORM > > request) after the IPSEC tunnel is setup and the client address is > > assigned. > > > > Either approach seems to be workable. It is certainly true > that most > > of > > the people in Atlanta were implementors who were already > familiar with > > modecfg, representing a large implementation community. That being > > said, there is also some number of working group members that are in > > favor of an approach similar to draft-ietf-ipsec-dhcp-13, > including Van > > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or > > another, however we need to make a choice and move forward. > > > > Given that we have a fully specified solution in the > ikev2-04 draft, > > and > > it would seem that while there is a sizeable minority in > favor of the > > ipsec-dhcp-13 approach, the majority are comfortable with > the modecfg > > based approach. So at this point, we, as working group > chairs, judge > > that the consensus is with the current approach. > > > > If there are those who feel otherwise, or who see fatal > problems with > > the current approach, please speak now. > From owner-ipsec@lists.tislabs.com Thu Feb 6 08:12:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16GCkd16145; Thu, 6 Feb 2003 08:12:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12550 Thu, 6 Feb 2003 10:38:28 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F1C@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Victor Volpe'" , "'Theodore Ts'o'" Cc: ipsec@lists.tislabs.com Subject: RE: Moving forward with IKE V2: A proposal for final edits to ike v2-04 Date: Thu, 6 Feb 2003 16:40:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Victor Volpe [mailto:vvolpe@cisco.com] > Sent: donderdag 6 februari 2003 5:34 > To: 'Theodore Ts'o' > Cc: ipsec@lists.tislabs.com > Subject: RE: Moving forward with IKE V2: A proposal for final edits to > ikev2-04 > > > Here are my thoughts on the 2 issues: > > 1. On the modecfg vs DHCP - I prefer modecfg. We have used > it for years > without issue. It is easy to implement and understand, it is > self-contained, > it does not require additional SAs and is easily extensible. > Not only have > we > added many modecfg attributes to solve customer issues in the > past but we I never said ModeCfg is not easy to extend; the only problem I have with this approach is that each time I add a new option I have to retest my IKE code and go through a certification process again. RFC 3456 is a solution that is transparent to IKE; new DHCP options have to be implemented in the server and client in other words in the hosts not in the middleware device. I'm glad to hear that several new attributes have been defined for ModeCfg because: 1) it proves my point that the current options in IKEv2 are insufficient 2) I would appreciate that at least a number of these new attributes are then included in the IKEv2 draft such that other IPSec implementers can benefit from these and come up with interoperable implementations. If these options are not disclosed only the vendor that sits on both ends of the tunnel can use these hence keep competition outside. > have > been able to easily coordinate the new attributes with RADIUS > via vendor > specific > attributes for a complete solution. Adding LDAP to this > proxy scheme has > also been > very easy. > > How easy would it be to implement a "complete" solution via > DHCP. It seems > to me that > we would have 2 options with DHCP. We either pass DHCP > through to a DHCP > server and make > it transparent to IKE/IPsec, or we intercept the DHCP request > and proxy it > to RADIUS or > LDAP. In my opinion, the former option is not really an > option. We can not > use DHCP servers > for anything other than IP address assignment. If we told > our customers > that they need to > set up user-based configuration attributes on their DHCP Can you elaborate a little on this ? > server, they would > quickly throw > us out. The latter option (proxy) would work but is more difficult to > implement than modecfg. > The difficulty comes with the loose coupling to user tunnels and the > additional SA. > > 2. I find Paul's naming convention very confusing (maybe it > is because I am > not up on the latest PKIX requirements). I like the old > naming convention > because they are core names and not abstractions of names. > By this I mean > that a core name can be used in several different scenarios > (if all the > scenarios have the same ID requirement) as long as the core > ID requirement > is well > documented. The abstractions, at least to me, may be more > intuitive, but > could cause an ID explosion as more and more abstractions are > introduced. > The worst case is that many abstract IDs really map to the > same core ID. > What I would really like to see is a decrease in the number > of IDS. It > would be nice to cover all the bases with 2 or 3 IDs and > properly document > the > use of the IDs. > > Victor > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper > > Sent: Wednesday, February 05, 2003 6:46 PM > > To: Theodore Ts'o > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Moving forward with IKE V2: A proposal for > final edits to > > ikev2-04 > > > > > > For purposes of consensus, here's my take on the two topics that Ted > > and Barbara have asked for comments on. A friend once > > remarked to me, > > "Go not to the elves for advice for they will say both 'yes' and > > 'no'..." > > > > RE: revised identity > > > > First, I sympathize with Cheryl and Scott in that we've > been avoiding > > the larger problem from the start and it has continued to > > plague us at > > interoperability workshops. The lack of consideration for > proper PKI > > integration is one of IKEv1's biggest omissions, that's > > clear. And yet > > here we are several years down the road and we still haven't > > been able > > to do anything about it. So, is now the right time and > place to deal > > with it? Perhaps, but only if there were very strong > > consensus amongst > > existing vendors. > > > > I think revisions to the IKE ID specifications will be > needed at some > > time in the future. The existing ID definitions are vague > and ad hoc > > and yet we've still managed to garner a fair amount of > > interoperability > > despite it all. It hasn't necessarily been pleasant or easy, > > but over > > time most IKE implementations now do interoperate. > > > > Would the proposed identity revisions make things so much > better that > > it would clear up some large majority of PKI interoperability > > problems? > > I don't think so. I think most of the problems are due > somewhat to > > the inherent complexity of certificate-based PKI > > interoperability and, > > moreover, to the lack of a defined PKI profile for IKE. I happen to > > think there's more value in defining a PKI profile, such as the one > > described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need > > revised identities to do that. It seems similarly clear > that revised > > identities would bring with them a new and entirely different set of > > interoperability issues. > > > > I have concerns that the management paradigm for many > vendors is very > > closely tied to the existing IKE identity types, so wholesale > > revision > > in this area might well represent a serious headache for many > > vendors. > > The impact of the protocol changes is largely transparent and > > the other > > revisions ought to mostly present themselves as elimination of > > unnecessary configuration options. Deleting things is > > relative easy. > > But I can see how wholesale identity revision might seriously impact > > much of the existing management software, end-user > documentation, and > > vendor regression testing. I think we do need to be concerned about > > fielded implementations. > > > > From an implementation standpoint, I also worry about combining > > something like identity revision with all the other IKEv2 changes. > > You'd essentially be starting from scratch at the next > bake-off. Now > > I'm not going to claim lots and lots of code reuse between IKEv1 and > > IKEv2, yet there is some overlap. But if you completely > rototill the > > identity processing on top of this, you're very close to > > starting from > > scratch. Anyone who lived through those early bake-off's would not > > want to go back there. Well, except for Big Al's BBQ Shack, > > perhaps. > > :-) > > > > Finally, if we're taking our deadline seriously, I don't think we're > > anywhere near consensus on what a revised identity proposal entails. > > Given the traffic just this week, there are many suggestions beyond > > what was originally discussed on the list last fall. Are > > there simple > > PKIX mappings? Are there simpler alternatives? IMHO, it's unlikely > > we're going to agree on such fundamental changes to identity > > representation in the next week. I think we should keep working on > > this as we should keep working on the PKI profile. But these > > items can > > occur orthogonally to IKEv2. > > > > In summary, our strategy of ignoring this has worked so well in the > > past that I recommend we continue it a while longer. > > > > RE: configuration mode vs. dhcp relay > > > > I'm on the fence with this one. I see good arguments for both > > approaches: there are simplicity arguments for MODECFG and there are > > richness arguments for DHCP. FWIW, the implementation I previously > > worked on was much closer to MODECFG. > > > > I'd welcome proposed text that explicitly shows the IKEv2 changes to > > support RFC3456. If we had that we could make a reasonable choice > > between the two. But absent that, I think we should pursue > > what we've > > got now and be willing to revisit this issue in the future. > > > > It's not an option to do nothing. IKEv2 needs a defined > mechanism to > > dole out internal addresses to remote clients and MODECFG has been > > written up for IKEv2 and shown to work in IKEv1. IKEv2 is > not viable > > without remote client support. > > > > Regards, > > > > Derrell > > > > On Thursday, January 30, 2003, at 02:57 PM, Theodore Ts'o wrote: > > > > > If you feel otherwise, please speak now. > > > > > > A) Revised identity > > > -------------------- > > > > > > Paul Hoffman has a proposal, > > draft-ietf-ipsec-revised-identity-00.txt, > > > which radically changes how identities are handled. > > Specifically, it > > > would eliminate the ID payload with the following types: > > > > > > ID_IPV4_ADDR 1 > > > ID_FQDN 2 > > > ID_RFC822_ADDR 3 > > > ID_IPV6_ADDR 5 > > > ID_DER_ASN1_DN 9 > > > ID_DER_ASN1_GN 10 > > > ID_KEY_ID 11 > > > > > > et.al, and replaces it with a FullID payload with the > > following types: > > > > > > 1 PKIX certificate > > > 2 Certificate bundle > > > 3 Hash-and-URL of PKIX certificate > > > 4 URL to a PKIX certificate bundle > > > 5 PKIX keyIdentifier > > > 6 IDForSharedSecret > > > > > > This would be fundamental change in the management and > > administraton of > > > IPSEC and IKE, so is not something to adopt lightly, and without a > > > clear > > > consensus of the working group. This was discussed in two > > threads on > > > the IPSEC mailing list: one starting on November 5th > (subject Adding > > > revised identities to IKEv2), and one starting on December 8th > > > (subject: > > > Summary of revised identity changes). People who spoke in > > favor on the > > > mailing list included Francis Dupont and Bill Sommerfeld, with > > > qualified > > > support from Michael Richardson (if support for bare keys > > is added) and > > > Tero Kivinen (who is concerned about the complexity of the > > proposal). > > > > > > This proposal was discussed in Atlanta, but Charlie, > > Barbara, and Ted > > > were left with the impression that there was not consensus > > among those > > > who met to discuss legacy authentication after the IPSEC wg > > meeting to > > > pursue adoption of Paul's proposed change. Paul believes > otherwise. > > > Since it is the job of working group chairs to determine > > consensus, we > > > (Barbara and Ted) hereby ask that those who believe we > > should pursue > > > the > > > revised identity proposal to please speak up. > > > > > > It should be noted that there are some intermediate > positions beyond > > > what is currently in draft-ietf-ipsec-ikev2-04.txt and the > > > revised-identies draft. For example, we could add the > Hash-and-URL > > > type > > > to the Certificate payload, if the goal is shrink the size of IKE > > > messages (with the tradeoff of increasing complexity in IKE > > > implementations). We could also add a CERT hash type to the ID > > > payload, without nuking the traditional FQDN or IPv4/6 addresses > > > identity mechanisms (although again, by adding new types, > > we would be > > > increasing the complexity of the specification and > implementations). > > > > > > Due the relatively small number of people who have spoken > > in favor of > > > this proposal or its less-radical alternates, the default > choice for > > > IKEv2 has to be what is currently in ikev2-04. So those > > who believe we > > > should make this change (or those who strongly believe we > > should not) > > > are requested to speak up now, or forever hold your peace.... > > > > > > > > > B) DHCP-based vs. MODECFG style remote access configuration > > > ----------------------------------------------------------- > > > > > > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote > access via a > > > Configuration payload with defined attributes. An > > alternate mechanism > > > involves using tunneled DHCP requests. The latter approach > > is about to > > > be published as an RFC by the IPSRA working group. > > Proponents of this > > > method argue that it is more powerful than modecfg (because of the > > > extensibility and large number of options already specified > > for DHCP; > > > for example, being able to specify DNS, time, print, or > > WINS servers, > > > and so on.) It is also argued that it requires less code on the > > > server/firewall, since an existing DHCP server can be used. > > > > > > Proponents of the modecfg approach argue that many implementation > > > already have support for modecfg, and that setting up sort-lived > > > specialized tunnels to allow the DHCP packets to flow through the > > > gateway is kludgy, and requires multiple special case entries into > > > packet forwarding tables. Modecfg proponents also argue > that it is > > > also > > > possible to transform modecfg requests into DHCP requests, > > so there are > > > implementation choices that do not require reimplementation of the > > > DHCP's address assignment function. They also point out that it > > > certainly is possible --- and in some ways easier --- to > obtain the > > > time, print, WINS server information by using DHCP (via the > > DHCPINFORM > > > request) after the IPSEC tunnel is setup and the client address is > > > assigned. > > > > > > Either approach seems to be workable. It is certainly true > > that most > > > of > > > the people in Atlanta were implementors who were already > > familiar with > > > modecfg, representing a large implementation community. > That being > > > said, there is also some number of working group members > that are in > > > favor of an approach similar to draft-ietf-ipsec-dhcp-13, > > including Van > > > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or > > > another, however we need to make a choice and move forward. > > > > > > Given that we have a fully specified solution in the > > ikev2-04 draft, > > > and > > > it would seem that while there is a sizeable minority in > > favor of the > > > ipsec-dhcp-13 approach, the majority are comfortable with > > the modecfg > > > based approach. So at this point, we, as working group > > chairs, judge > > > that the consensus is with the current approach. > > > > > > If there are those who feel otherwise, or who see fatal > > problems with > > > the current approach, please speak now. > > > From owner-ipsec@lists.tislabs.com Thu Feb 6 08:47:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Gl3d20666; Thu, 6 Feb 2003 08:47:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12631 Thu, 6 Feb 2003 11:16:41 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Van Aken Dirk" , "'Scott G. Kelly'" Cc: Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Thu, 6 Feb 2003 11:19:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F19@TMM_EDGMSMSG01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dirk, the main point you can take from my posting this problem is that RFC3456 has had relatively little mileage and implementation experience compared to modecfg. People have had years to discover the inherent problems with modecfg and understand them, they've also had years to understand how useful it can be. RFC3456 is relatively young and not entirely understood by this working group so there are likely many scenarios where it will have problems that have not been discovered. The one I pointed out is just one of those, will there be others? Most likely. Should they be posted and discussed? Absolutely. Will they have solutions that could change our understanding or implementation of RFC3456? Who knows. Dirk, you wrote. > I would agree with you Darren, if this same scenario would work > form the VPN > client side because there is far less control on who is sitting behind the > VPN client. Why would it not work from a client? If the selectors are such that all traffic is tunnelled then a client could send DHCPACKs to the DHCP-relay on the SGW, correct? Thanks, Darren > -----Original Message----- > From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] > Sent: Thursday, February 06, 2003 6:06 AM > To: 'Scott G. Kelly'; ddukes@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack > against RFC3456.] > > > I agree with Scott, IPSec is not going to solve this kind of security > issues. > i.e. IPSec was not conceived to cope with the situation where the > frontdoor > is open and where there is no backdoor. > People having access to a central offices are assumed to be trusted ! > > I would agree with you Darren, if this same scenario would work > form the VPN > client side because there is far less control on who is sitting behind the > VPN client. > > If you can convice me that ModeCfg has no inherent limitations or that the > DHCP based method has serious flaws, please tell me. If so, I'm willing to > change my religion. > > > BTW If IPSec must also cope with malicous insiders, then I know a very > simple but effective attack on the security solution provided by a certain > company ... > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > > Sent: woensdag 5 februari 2003 20:52 > > To: ddukes@cisco.com > > Cc: ipsec@lists.tislabs.com > > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > > RFC3456.] > > > > > > Come on, Darren - you must be joking. What you describe is > > not an attack > > against RFC3456 - it's an attack against DHCP/BOOTP, and this > > is nothing > > new. If you run DHCP on your network and you have malicious insiders, > > they can do all sorts of things. The same applies for most other > > commonly run lan protocols. And since you've already conceded that a > > scalable modecfg implementation will be running dhcp on the backend, > > what is the point of this post? > > > > Let's stick with arguments with technical merit. > > > > Scott > > > > Darren Dukes wrote: > > > > > > Amendment: > > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with > > a manufactured > > > DHCP Relay Agent Information Option or one copied from a > > previous DHCP > > > message. > > > > > > > -----Original Message----- > > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > > This attack is based on the thread defined in RFC3118 > > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > > new route for whatever address Eve puts in yiaddr. > > > > > > > > |-Eve > > > > IRAC ---- SGW -| > > > > |-DHCP Server > > > > > > > > excerpt from RFC3456: > > > > To learn the internal IP address of the client in > > order to route > > > > packets to it, the security gateway will typically > > snoop the yiaddr > > > > field within the DHCPACK and plumb a corresponding > > route as part of > > > > DHCP Relay processing. > > > > > > > > This attack is not resolved by the implementation of RFC3118 > > > > unless the following changes are made to the DHCP-relay. > > > > 1 - It stored a copy of all secret keys contained on the > > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > > copy of the master key and used that to generate the client keys > > > > as described in RFC3118 Appendix A. > > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > > > > Darren > > > > > > From owner-ipsec@lists.tislabs.com Thu Feb 6 08:51:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Gpkd20787; Thu, 6 Feb 2003 08:51:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12654 Thu, 6 Feb 2003 11:20:47 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Question about IPSec and NAT X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 6 Feb 2003 17:23:35 +0100 Message-ID: Thread-Topic: Question about IPSec and NAT Thread-Index: AcLN/BinDjaEHhHwQaGFsd/FA3qQ6A== From: "BUYCK Jacky FTRD/DMI/CAE" To: X-OriginalArrivalTime: 06 Feb 2003 16:23:35.0746 (UTC) FILETIME=[192A7220:01C2CDFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA12646 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. I'm looking after the problem of using NAT and IPSec and the existing solution (implemented or draft versions). I've found some of the problem regarding IKE/NAT and IPSec/NAT but I've some trouble when I want to check if solution really anwser all problems. I think this come from a not clear understanding of IKE-NAT-T Draft. Here are my problems : - IKE/NAT imply to uses floated port. In the IKE-nat-t draft it is specify to use the UDP 500 port for NAT Detection and after using the port 4500. By passing throught NAT the port 4500 will be transform in port X. Is it this port that will be use in future IPSec exchange ? - That ike-nat-t don't appear to solve the problem of multiple IPSec client trying to connect to the same IPSec gateway. I'm true ? - If the equipment that perform NAT function don't translate port 500 UDP paquet we still have the problem of traditional IKE with NAT. Did we must always set the default IKE port to other an other value than 500 to prevent NAT problem ? A little bit strange ! For the first point I think that I must have the following exchanges : It's correct ? ==================================================================================== A NAT B - NAT Detection Using IKE nat-t -------------------------------------------------------------- SRC(@A,500);D(@B,500) ---------------------> SRC(@N,N1);D(@B,500) ---------------------> SRC(@B,500);D(@N,N1) <--------------------- SRC(@B,500);D(@A,500) <--------------------- - IKE nat-t conitnuation after nat discovering ----------------------------------------------- SRC(@A,4500);D(@B,4500) ---------------------> SRC(@N,X);D(@B,4500) ---------------------> SRC(@B,4500);D(@N,X) <--------------------- SRC(@B,4500);D(@A,4500) <--------------------- - IPSec exchange ------------------------------------------------------------------------------ IP(@A,@B)-UDP(4500,4500)-ESP ---------------------> IP(@N,@B)-UDP(X,4500)-ESP ---------------------> IP(@B,@N)-UDP(4500,X)-ESP <--------------------- IP(@B,@A)-UDP(4500,4500)-ESP <--------------------- Where IP is the IP Header with IP(SRC Addr, Dest Addr) And UDP is the UDP header with UDP(SRC Port, DST Port) The NAT will remain the following information about translation : During NAT Detection : (@A,500) is translate into (@N,N1) During final IKE negociation and IPSec (according to draft-ietf-ipsec-udp-encaps-06.txt) : (@A,4500) is translate into (@N,X) ==================================================================================== Really thanks to you. Jacky Buyck R&D Engineer - Intranet Security Services Tel : +33 2 31 75 93 61 Fax : +33 2 31 75 06 31 France Telecom R&D - DMI/SIR 42 Rue des Coutures - BP 6243 - 14066 Caen Cedex 4 - France From owner-ipsec@lists.tislabs.com Thu Feb 6 09:34:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16HYid21895; Thu, 6 Feb 2003 09:34:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12813 Thu, 6 Feb 2003 11:57:10 -0500 (EST) Message-ID: <3E4293AF.83AD18F@bstormnetworks.com> Date: Thu, 06 Feb 2003 08:56:16 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: Van Aken Dirk , ipsec@lists.tislabs.com Subject: Re: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, Again, this is incorrect. Your company may have no experience with dhcp over ipsec, but it should be clear that this is not the case for others. I have over 4 years of experience with it in real world deployments. Some of us have been doing this for as long as some others have been doing modecfg. And again, this whole MiM thing is a red herring. If this is a real concern, there are much more devastating attacks possible. Lets move on. Scott Darren Dukes wrote: > > Dirk, the main point you can take from my posting this problem is that > RFC3456 has had relatively little mileage and implementation experience > compared to modecfg. People have had years to discover the inherent > problems with modecfg and understand them, they've also had years to > understand how useful it can be. RFC3456 is relatively young and not > entirely understood by this working group so there are likely many scenarios > where it will have problems that have not been discovered. > > The one I pointed out is just one of those, will there be others? Most > likely. Should they be posted and discussed? Absolutely. Will they have > solutions that could change our understanding or implementation of RFC3456? > Who knows. > > Dirk, you wrote. > > I would agree with you Darren, if this same scenario would work > > form the VPN > > client side because there is far less control on who is sitting behind the > > VPN client. > > Why would it not work from a client? If the selectors are such that all > traffic is tunnelled then a client could send DHCPACKs to the DHCP-relay on > the SGW, correct? > > Thanks, > Darren > > > -----Original Message----- > > From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] > > Sent: Thursday, February 06, 2003 6:06 AM > > To: 'Scott G. Kelly'; ddukes@cisco.com > > Cc: ipsec@lists.tislabs.com > > Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack > > against RFC3456.] > > > > > > I agree with Scott, IPSec is not going to solve this kind of security > > issues. > > i.e. IPSec was not conceived to cope with the situation where the > > frontdoor > > is open and where there is no backdoor. > > People having access to a central offices are assumed to be trusted ! > > > > I would agree with you Darren, if this same scenario would work > > form the VPN > > client side because there is far less control on who is sitting behind the > > VPN client. > > > > If you can convice me that ModeCfg has no inherent limitations or that the > > DHCP based method has serious flaws, please tell me. If so, I'm willing to > > change my religion. > > > > > > BTW If IPSec must also cope with malicous insiders, then I know a very > > simple but effective attack on the security solution provided by a certain > > company ... > > > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > > > Sent: woensdag 5 februari 2003 20:52 > > > To: ddukes@cisco.com > > > Cc: ipsec@lists.tislabs.com > > > Subject: Sensationalism? [was Re: FW: Man in the middle attack against > > > RFC3456.] > > > > > > > > > Come on, Darren - you must be joking. What you describe is > > > not an attack > > > against RFC3456 - it's an attack against DHCP/BOOTP, and this > > > is nothing > > > new. If you run DHCP on your network and you have malicious insiders, > > > they can do all sorts of things. The same applies for most other > > > commonly run lan protocols. And since you've already conceded that a > > > scalable modecfg implementation will be running dhcp on the backend, > > > what is the point of this post? > > > > > > Let's stick with arguments with technical merit. > > > > > > Scott > > > > > > Darren Dukes wrote: > > > > > > > > Amendment: > > > > Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with > > > a manufactured > > > > DHCP Relay Agent Information Option or one copied from a > > > previous DHCP > > > > message. > > > > > > > > > -----Original Message----- > > > > > From: Darren Dukes [mailto:ddukes@cisco.com] > > > > > Sent: Wednesday, February 05, 2003 12:10 PM > > > > > To: ipsec@lists.tislabs.com > > > > > Subject: Man in the middle attack against RFC3456. > > > > > > > > > > > > > > > There is a man in the middle attack on the DHCP-relay in RFC3456. > > > > > This attack is based on the thread defined in RFC3118 > > > > > (DHCP-AUTH). In this case Eve is inside the LAN and able to > > > > > source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a > > > > > SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a > > > > > new route for whatever address Eve puts in yiaddr. > > > > > > > > > > |-Eve > > > > > IRAC ---- SGW -| > > > > > |-DHCP Server > > > > > > > > > > excerpt from RFC3456: > > > > > To learn the internal IP address of the client in > > > order to route > > > > > packets to it, the security gateway will typically > > > snoop the yiaddr > > > > > field within the DHCPACK and plumb a corresponding > > > route as part of > > > > > DHCP Relay processing. > > > > > > > > > > This attack is not resolved by the implementation of RFC3118 > > > > > unless the following changes are made to the DHCP-relay. > > > > > 1 - It stored a copy of all secret keys contained on the > > > > > DHCP-server and used them to authenticate DHCPACKs or it stored a > > > > > copy of the master key and used that to generate the client keys > > > > > as described in RFC3118 Appendix A. > > > > > 2 - DHCP-relay implements the DHCP-server replay protection. > > > > > > > > > > > > > > > Darren > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Feb 6 09:52:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Hq2d22444; Thu, 6 Feb 2003 09:52:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12913 Thu, 6 Feb 2003 12:19:26 -0500 (EST) Message-ID: <3E429952.26EF2762@bstormnetworks.com> Date: Thu, 06 Feb 2003 09:20:18 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: dhcp/modecfg summary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As Scott Fanning pointed out, it has certainly been a spirited debate. Below is a summary from my perspective. I intend this to be objective, though it probably isn't completely free of bias. As an aside, it seems clear that some posters don't have much deployment experience with modecfg *or* dhcp relay. While those folks must not be ignored, neither should they be primary drivers of this discussion. - There are three basic models: local address pool, radius server assigns addresses, and dhcp; there are two (suggested) models for dhcp: over IP, and over IKE - a local address pool does not scale; while this is sufficient for small implementations, it won't work in large deployments. Radius scales if a dhcp server is involved somehow, but not very well if per-user unique addresses must be preconfigured into radius. - some folks seem to imply that remote access entails only a pc connected to the target network over the internet; in fact, many telecommuter applications involve a personal sgw at the remote end, with a small network behind it - this should not be ignored in evaluating prospective mechanisms. - the suggested inability of dhcp-based methods to support policy based on pre-assigned ip is red herring, as an implemenation may set up template policies based on user class and then back-fill the address once assigned with either modecfg or dhcp - quite a few vendors have implemented dhcp, but apparently more have implemented modecfg - even if ike changes, dhcp implementations will remain, so modecfg2 is not quite a freebie, while dhcp is for vendors who've already implemented it; on the other hand, vendors who have not implemented dhcp relay would be impacted, but they will be impacted either way if we agree that support for dhcp-inform is required. - the dhcp model provides a great deal of flexibility due to richness of options; you have to look at how dhcp is being used in contemporary networks to understand this. Clearly, some folks have yet to do this. As for extensibility, vendor-specific options provide a clear path. - one stated aim of this wg in redesigning IKE has been to minimize impact on ike, to not add anything which is not required. If we stick to this position, this seems to imply that dhcp support will be required regardless (via dhcp inform and relay), unless we actually intend to expand modecfg2 to encompass all dhcp options plus some new ipsec-specific options. This is a critical point: some modecfg2 proponents do not just want address assignment - they seem to want policy config, along with "other things". This wg must decide if this is acceptable. - options: support both, support modecfg2 only, or support dhcp only - I would vote no on modecfg2 only, as this will forego the flexibility and power of dhcp-based methods, duplicate much of the functionality, and significantly increase the complexity of the ike implementation - a huge step backward, in my view. - I prefer dhcp only, because I know it can be done, and that it is not rocket science - no advanced calculus, no theoretical physics, just plain vanilla software engineering - complaints to the contrary not withstanding. Yes, you need to think before you start thrashing around in the code. This is not a one-afternoon hack job. No, it does not take a genius to find an elegant way to integrate this functionality. - I could be pummeled into supporting a marriage of modecfg2 and dhcp if the modecfg functionality were limited to IP address assignment only. But I would be a reluctant supporter at best, since this requires an implementation to carry both mechanisms, and I don't think it's been demonstrated that IKE should accommodate this. What I *do* think has been demonstrated is that some vendors who chose modecfg in ikev1 are reluctant to modify their implementations - a political reality I'd prefer we not weigh too heavily, but which we (unfortunately) cannot ignore. Scott From owner-ipsec@lists.tislabs.com Thu Feb 6 10:57:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Iv9d25690; Thu, 6 Feb 2003 10:57:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13116 Thu, 6 Feb 2003 13:21:26 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE576@SARATOGA> From: Gregory Lebovitz To: "'Derrell Piper'" , "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: On revised identity (was "Moving forward...final edits...) Date: Thu, 6 Feb 2003 10:21:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk splitting this thread into two subject-specific threads for easier following... On revised Identities... Having spent many many months trying to pull together all the PKI vendors and all the IPsec vendors to figure out how to better handle and deploy certificates for IPsec VPNs (Project Dploy, www.projectdploy.com), I can offer these points: (1) I'm being very generous if I say that only 10% or less of IPsec deployments use Certs. 90% or more use Pre-Share Secrets. And cert (2) The PKI vendors have mostly given up on the VPN application space. They are not doing new development, nor heavy marketing focus, to make the VPN application work better. And they will not. (3) If we want to make IPsec with Certificates easier, we have to do it within the IPsec space. (4) We need to make sure that whatever we do, preshare secrets are really easy to use, since most all the deployments use them. Identity was very troublesome in v1. It would seem a shame to miss an opportunity to simplify it. The current text is a move in the right direction. Perhaps it lacks enough explicit justification/explanation text in its current form to be fully usable. I would definitely want to see it beefed up to remove ambiguities that arose for me when I first read it. But it is a definite simplication for the part that affects over 90% of the market, those using pre-share keys. With these points in mind, here is my input on the current Revised Identities text: - Making the IDforSharedSecret a pure string is a great solution. Using four methods (IP, 822-name, FQDN, DN) in v1 was a fiasco. Regardless of what the RFCs said, some vendors checked the receiving packet/cert for a match of the ID type to the ID presented in the ID payload, and some did not. This caused a lot of problems. Decoupling the ID string from these 4 elements will help. Not that you can't still use any of these things as a sting, just that now we all agree to read it as a string in this one place alone. And that's it. Easy!! This will help both implementors and users a ton. WRT certs (which only pertains to <10% of the installations)... - the mechanism for using/sending/finding certs and chains makes it extrememly explicit which cert to use, and how get it. - the mechanisms provided will allow certs to be used for many different applications, bandwidths, memory capabilities, etc. wrt the platforms in use and their connectivity (think hand-helds, consumer electronics, etc). - the responsibility is now 100% on the part of the recipient to determine what elements within the certificate she wants to use to match identity. Interoperability issues regarding *determining* the identity will essentially go away, from an ipsec implementor perspective. Issues wrt what fields in the cert should be used and how should likewise go away. As long as the implementation can parse the cert, and provide the user with a UI that allows them to select various fields to check and enter the strings to check for, it will work. Responsibility will move to the operator of the IPsec to determine what contents in the certs (that they are creating) they want to use as identity. The implementor will need only to make sure that in the UI the user can specify any of the possible cert fields to match. - The cert itself is the identity wholly and completely. The implementation, based on configuration by the user, will check whatever fields, combination of fields, or all, of the cert in order to perform the lookup in its local db for a match on identity. It's up to the user now, not the implementation's interpretation of the RFC. It's explicit! In summary: * Let's take the opportunity now, while we can, to dramatically simplify identity proposal. This is especially true for IDforSharedSecret, which is 90%+ of the installations going out. * Let's try to add some justification/explanation text to what's there today so that people understand it better. This would especially be true for HOW TO USE the cert-included elements (options 1-5). Gregory. > -----Original Message----- > From: Derrell Piper [mailto:ddp@electric-loft.org] > Sent: Wednesday, February 05, 2003 3:46 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: Moving forward with IKE V2: A proposal for final edits to > ikev2-04 > > > For purposes of consensus, here's my take on the two topics that Ted > and Barbara have asked for comments on. A friend once > remarked to me, > "Go not to the elves for advice for they will say both 'yes' and > 'no'..." > > RE: revised identity > > First, I sympathize with Cheryl and Scott in that we've been avoiding > the larger problem from the start and it has continued to > plague us at > interoperability workshops. The lack of consideration for proper PKI > integration is one of IKEv1's biggest omissions, that's > clear. And yet > here we are several years down the road and we still haven't > been able > to do anything about it. So, is now the right time and place to deal > with it? Perhaps, but only if there were very strong > consensus amongst > existing vendors. > > I think revisions to the IKE ID specifications will be needed at some > time in the future. The existing ID definitions are vague and ad hoc > and yet we've still managed to garner a fair amount of > interoperability > despite it all. It hasn't necessarily been pleasant or easy, > but over > time most IKE implementations now do interoperate. > > Would the proposed identity revisions make things so much better that > it would clear up some large majority of PKI interoperability > problems? > I don't think so. I think most of the problems are due somewhat to > the inherent complexity of certificate-based PKI > interoperability and, > moreover, to the lack of a defined PKI profile for IKE. I happen to > think there's more value in defining a PKI profile, such as the one > described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need > revised identities to do that. It seems similarly clear that revised > identities would bring with them a new and entirely different set of > interoperability issues. > > I have concerns that the management paradigm for many vendors is very > closely tied to the existing IKE identity types, so wholesale > revision > in this area might well represent a serious headache for many > vendors. > The impact of the protocol changes is largely transparent and > the other > revisions ought to mostly present themselves as elimination of > unnecessary configuration options. Deleting things is > relative easy. > But I can see how wholesale identity revision might seriously impact > much of the existing management software, end-user documentation, and > vendor regression testing. I think we do need to be concerned about > fielded implementations. > > From an implementation standpoint, I also worry about combining > something like identity revision with all the other IKEv2 changes. > You'd essentially be starting from scratch at the next bake-off. Now > I'm not going to claim lots and lots of code reuse between IKEv1 and > IKEv2, yet there is some overlap. But if you completely rototill the > identity processing on top of this, you're very close to > starting from > scratch. Anyone who lived through those early bake-off's would not > want to go back there. Well, except for Big Al's BBQ Shack, > perhaps. > :-) > > Finally, if we're taking our deadline seriously, I don't think we're > anywhere near consensus on what a revised identity proposal entails. > Given the traffic just this week, there are many suggestions beyond > what was originally discussed on the list last fall. Are > there simple > PKIX mappings? Are there simpler alternatives? IMHO, it's unlikely > we're going to agree on such fundamental changes to identity > representation in the next week. I think we should keep working on > this as we should keep working on the PKI profile. But these > items can > occur orthogonally to IKEv2. > > In summary, our strategy of ignoring this has worked so well in the > past that I recommend we continue it a while longer. > > RE: configuration mode vs. dhcp relay > > I'm on the fence with this one. I see good arguments for both > approaches: there are simplicity arguments for MODECFG and there are > richness arguments for DHCP. FWIW, the implementation I previously > worked on was much closer to MODECFG. > > I'd welcome proposed text that explicitly shows the IKEv2 changes to > support RFC3456. If we had that we could make a reasonable choice > between the two. But absent that, I think we should pursue > what we've > got now and be willing to revisit this issue in the future. > > It's not an option to do nothing. IKEv2 needs a defined mechanism to > dole out internal addresses to remote clients and MODECFG has been > written up for IKEv2 and shown to work in IKEv1. IKEv2 is not viable > without remote client support. > > Regards, > > Derrell > > On Thursday, January 30, 2003, at 02:57 PM, Theodore Ts'o wrote: > > > If you feel otherwise, please speak now. > > > > A) Revised identity > > -------------------- > > > > Paul Hoffman has a proposal, > draft-ietf-ipsec-revised-identity-00.txt, > > which radically changes how identities are handled. > Specifically, it > > would eliminate the ID payload with the following types: > > > > ID_IPV4_ADDR 1 > > ID_FQDN 2 > > ID_RFC822_ADDR 3 > > ID_IPV6_ADDR 5 > > ID_DER_ASN1_DN 9 > > ID_DER_ASN1_GN 10 > > ID_KEY_ID 11 > > > > et.al, and replaces it with a FullID payload with the > following types: > > > > 1 PKIX certificate > > 2 Certificate bundle > > 3 Hash-and-URL of PKIX certificate > > 4 URL to a PKIX certificate bundle > > 5 PKIX keyIdentifier > > 6 IDForSharedSecret > > > > This would be fundamental change in the management and > administraton of > > IPSEC and IKE, so is not something to adopt lightly, and without a > > clear > > consensus of the working group. This was discussed in two > threads on > > the IPSEC mailing list: one starting on November 5th (subject Adding > > revised identities to IKEv2), and one starting on December 8th > > (subject: > > Summary of revised identity changes). People who spoke in > favor on the > > mailing list included Francis Dupont and Bill Sommerfeld, with > > qualified > > support from Michael Richardson (if support for bare keys > is added) and > > Tero Kivinen (who is concerned about the complexity of the > proposal). > > > > This proposal was discussed in Atlanta, but Charlie, > Barbara, and Ted > > were left with the impression that there was not consensus > among those > > who met to discuss legacy authentication after the IPSEC wg > meeting to > > pursue adoption of Paul's proposed change. Paul believes otherwise. > > Since it is the job of working group chairs to determine > consensus, we > > (Barbara and Ted) hereby ask that those who believe we > should pursue > > the > > revised identity proposal to please speak up. > > > > It should be noted that there are some intermediate positions beyond > > what is currently in draft-ietf-ipsec-ikev2-04.txt and the > > revised-identies draft. For example, we could add the Hash-and-URL > > type > > to the Certificate payload, if the goal is shrink the size of IKE > > messages (with the tradeoff of increasing complexity in IKE > > implementations). We could also add a CERT hash type to the ID > > payload, without nuking the traditional FQDN or IPv4/6 addresses > > identity mechanisms (although again, by adding new types, > we would be > > increasing the complexity of the specification and implementations). > > > > Due the relatively small number of people who have spoken > in favor of > > this proposal or its less-radical alternates, the default choice for > > IKEv2 has to be what is currently in ikev2-04. So those > who believe we > > should make this change (or those who strongly believe we > should not) > > are requested to speak up now, or forever hold your peace.... > > > > > > B) DHCP-based vs. MODECFG style remote access configuration > > ----------------------------------------------------------- > > > > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a > > Configuration payload with defined attributes. An > alternate mechanism > > involves using tunneled DHCP requests. The latter approach > is about to > > be published as an RFC by the IPSRA working group. > Proponents of this > > method argue that it is more powerful than modecfg (because of the > > extensibility and large number of options already specified > for DHCP; > > for example, being able to specify DNS, time, print, or > WINS servers, > > and so on.) It is also argued that it requires less code on the > > server/firewall, since an existing DHCP server can be used. > > > > Proponents of the modecfg approach argue that many implementation > > already have support for modecfg, and that setting up sort-lived > > specialized tunnels to allow the DHCP packets to flow through the > > gateway is kludgy, and requires multiple special case entries into > > packet forwarding tables. Modecfg proponents also argue that it is > > also > > possible to transform modecfg requests into DHCP requests, > so there are > > implementation choices that do not require reimplementation of the > > DHCP's address assignment function. They also point out that it > > certainly is possible --- and in some ways easier --- to obtain the > > time, print, WINS server information by using DHCP (via the > DHCPINFORM > > request) after the IPSEC tunnel is setup and the client address is > > assigned. > > > > Either approach seems to be workable. It is certainly true > that most > > of > > the people in Atlanta were implementors who were already > familiar with > > modecfg, representing a large implementation community. That being > > said, there is also some number of working group members that are in > > favor of an approach similar to draft-ietf-ipsec-dhcp-13, > including Van > > Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or > > another, however we need to make a choice and move forward. > > > > Given that we have a fully specified solution in the > ikev2-04 draft, > > and > > it would seem that while there is a sizeable minority in > favor of the > > ipsec-dhcp-13 approach, the majority are comfortable with > the modecfg > > based approach. So at this point, we, as working group > chairs, judge > > that the consensus is with the current approach. > > > > If there are those who feel otherwise, or who see fatal > problems with > > the current approach, please speak now. > From owner-ipsec@lists.tislabs.com Thu Feb 6 11:36:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Jahd28304; Thu, 6 Feb 2003 11:36:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13188 Thu, 6 Feb 2003 14:02:42 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE578@SARATOGA> From: Gregory Lebovitz To: "'Derrell Piper'" , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: RE: On revised identity (was "Moving forward...final edits...) Date: Thu, 6 Feb 2003 11:02:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, thanks for taking the lead to summarize this for us. Comments on your summary within... > -----Original Message----- > From: Derrell Piper [mailto:ddp@electric-loft.org] > Sent: Wednesday, February 05, 2003 3:46 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: Moving forward with IKE V2: A proposal for final edits to > ikev2-04 --SNIP-- > > Would the proposed identity revisions make things so much better that > it would clear up some large majority of PKI interoperability > problems? It would make the IDforSharedSecret completely straightforward, which addresses 90%+ of the deployments going out. For those very few deployments that use certs, it makes using certs more efficient (don't have to send the cert every IKE exchange). It also removes the issue of how to configure and what to configure in the various cert fields a non-issue for the protocol. The user can specify whatever they want wherever they want in the cert, and as long as the implementation allows them to, via UI, select and match those fields' contents, it will work. > I don't think so. I think most of the problems are due somewhat to > the inherent complexity of certificate-based PKI > interoperability and, > moreover, to the lack of a defined PKI profile for IKE. I happen to > think there's more value in defining a PKI profile, such as the one > described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need > revised identities to do that. It seems similarly clear that revised > identities would bring with them a new and entirely different set of > interoperability issues. Regardless of revised identities, we definitely need a cert profile, but the total amount of things we need to specify in the cert profile for v2 will be much less than the equivalent document for v1. > I have concerns that the management paradigm for many vendors is very > closely tied to the existing IKE identity types, so wholesale > revision > in this area might well represent a serious headache for many > vendors. > The impact of the protocol changes is largely transparent and > the other > revisions ought to mostly present themselves as elimination of > unnecessary configuration options. Deleting things is > relative easy. > But I can see how wholesale identity revision might seriously impact > much of the existing management software, end-user documentation, and > vendor regression testing. I think we do need to be concerned about > fielded implementations. This is a great point. Must of us have already developed extensive and complicated management stuff to get around the perplexity of the v1 protocol wrt identity and certs. I agree, we would have new work to do, mostly because the new way would be so much easier. Also, the UI's would become cluttered, as now we would have to have 2UI's, one for v1 support and one for v2 support. > From an implementation standpoint, I also worry about combining > something like identity revision with all the other IKEv2 changes. > You'd essentially be starting from scratch at the next bake-off. Now > I'm not going to claim lots and lots of code reuse between IKEv1 and > IKEv2, yet there is some overlap. But if you completely rototill the > identity processing on top of this, you're very close to > starting from > scratch. another good point. The only consolation is that what we'd be starting from would appear to be MUCH more direct. We would only need to focus on interop for the format of how we send options 0-5, and not so much the content of the certs themselves, as that would be an UI matching issue. > In summary, our strategy of ignoring this has worked so well in the > past that I recommend we continue it a while longer. agreed that we possibly cannot get full consensus, or fully completed text on this in one week. But I do think we should forgoe the re-work agreed to above, and fix the protocol know while we still can. Gregory. !! NETSCREEN IS MOVING !! New Contact Info starting 2/10: 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 408.543.8002 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.730.6002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Thu Feb 6 11:37:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Jbhd28326; Thu, 6 Feb 2003 11:37:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13182 Thu, 6 Feb 2003 14:01:43 -0500 (EST) Date: Thu, 6 Feb 2003 14:04:28 -0500 From: "Theodore Ts'o" To: Gregory Lebovitz Cc: "'Derrell Piper'" , ipsec@lists.tislabs.com Subject: Re: On revised identity (was "Moving forward...final edits...) Message-ID: <20030206190428.GJ18097@think.thunk.org> References: <541402FFDC56DA499E7E13329ABFEA872CE576@SARATOGA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541402FFDC56DA499E7E13329ABFEA872CE576@SARATOGA> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 06, 2003 at 10:21:12AM -0800, Gregory Lebovitz wrote: > The current text is a move in the right direction. Gregory, Could you be specific? When you say, "the current text", are you referring to the current text in the revised-identities I-D, or the current text in ikev2-04 ID? Parts of your note make me believe that you are likely referring to former instead of the latter, but I would appreciate your being explicit about your preference. In any case, thank you for speaking up. I would encourage others who are familiar with the issues surrounding identity management, both in currently deployed IKEv1 implementations, as well as the scheme in the revised-identity and in the ikev2-04 I-D's to make their opinions known, preferably by the end of the week, if at all possible. - Ted From owner-ipsec@lists.tislabs.com Thu Feb 6 11:49:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16JnWd28563; Thu, 6 Feb 2003 11:49:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13224 Thu, 6 Feb 2003 14:14:12 -0500 (EST) Message-ID: <82CC1E573B94A648B87027C9419E2C055A6B62@losgatos> From: Michael Choung Shieh To: "'Scott G. Kelly'" , ipsec@lists.tislabs.com Subject: RE: dhcp/modecfg summary Date: Thu, 6 Feb 2003 11:11:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would say the address allocation for a group of PC behind the peer gateway is out of scope of this discussion. It should be done AFTER IKE is done, not within IKE. I like the flexibility of DHCP, but the complexity of implementing RFC3456 (glue IKE/IPSEC/DHCP) scares me. The states of key exchange will need to include ike phase 1, phase 2 for dhcp sa, DHCP in IPsec, then phase 2 for data traffic. If there are any error occurs, we need to revoke all established states. It is doable, but it's hard to maintain and achieve interoperability. I wonder if there is an option for DHCP-over-IKE or DHCP over Modecfg2. If I need to pick from modecfg-only and DHCP-only, I will choose modecfg for its simplicity. just my 2 cents, ======================= Michael Shieh > -----Original Message----- > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > Sent: Thursday, February 06, 2003 9:20 AM > To: ipsec@lists.tislabs.com > Subject: dhcp/modecfg summary > > > As Scott Fanning pointed out, it has certainly been a spirited debate. > Below is a summary from my perspective. I intend this to be objective, > though it probably isn't completely free of bias. As an > aside, it seems > clear that some posters don't have much deployment experience with > modecfg *or* dhcp relay. While those folks must not be > ignored, neither > should they be primary drivers of this discussion. > > - There are three basic models: local address pool, radius server > assigns addresses, and dhcp; there are two (suggested) models > for dhcp: > over IP, and over IKE > > - a local address pool does not scale; while this is sufficient for > small implementations, it won't work in large deployments. > Radius scales > if a dhcp server is involved somehow, but not very well if per-user > unique addresses must be preconfigured into radius. > > - some folks seem to imply that remote access entails only a pc > connected to the target network over the internet; in fact, many > telecommuter applications involve a personal sgw at the > remote end, with > a small network behind it - this should not be ignored in evaluating > prospective mechanisms. > > - the suggested inability of dhcp-based methods to support > policy based > on pre-assigned ip is red herring, as an implemenation may set up > template policies based on user class and then back-fill the address > once assigned with either modecfg or dhcp > > - quite a few vendors have implemented dhcp, but apparently more have > implemented modecfg > > - even if ike changes, dhcp implementations will remain, so > modecfg2 is > not quite a freebie, while dhcp is for vendors who've already > implemented it; > on the other hand, vendors who have not implemented dhcp > relay would be > impacted, but they will be impacted either way if we agree > that support > for dhcp-inform is required. > > - the dhcp model provides a great deal of flexibility due to > richness of > options; you have to look at how dhcp is being used in contemporary > networks to understand this. Clearly, some folks have yet to > do this. As > for > extensibility, vendor-specific options provide a clear path. > > - one stated aim of this wg in redesigning IKE has been to minimize > impact on ike, to not add anything which is not required. If > we stick to > this position, this seems to imply that dhcp support will be required > regardless (via dhcp inform and relay), unless we actually intend to > expand modecfg2 to encompass all dhcp options plus some new > ipsec-specific options. This is a critical point: some modecfg2 > proponents do not just want address assignment - they seem to want > policy config, along with "other things". This wg must decide > if this is > acceptable. > > - options: support both, support modecfg2 only, or support dhcp only > > - I would vote no on modecfg2 only, as this will forego the > flexibility > and power of dhcp-based methods, duplicate much of the functionality, > and significantly increase the complexity of the ike > implementation - a > huge step backward, in my view. > > - I prefer dhcp only, because I know it can be done, and that > it is not > rocket science - no advanced calculus, no theoretical physics, just > plain vanilla software engineering - complaints to the contrary not > withstanding. Yes, you need to think before you start thrashing around > in the code. This is not a one-afternoon hack job. No, it > does not take > a genius to find an elegant way to integrate this functionality. > > - I could be pummeled into supporting a marriage of modecfg2 > and dhcp if > the modecfg functionality were limited to IP address assignment only. > But I > would be a reluctant supporter at best, since this requires an > implementation to carry both mechanisms, and I don't think it's been > demonstrated that IKE should accommodate this. What I *do* think has > been demonstrated is that some vendors who chose modecfg in ikev1 are > reluctant to modify their implementations - a political reality I'd > prefer we not weigh too heavily, but which we (unfortunately) cannot > ignore. > > > Scott > From owner-ipsec@lists.tislabs.com Thu Feb 6 14:08:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16M8Fd02946; Thu, 6 Feb 2003 14:08:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13715 Thu, 6 Feb 2003 16:35:20 -0500 (EST) From: "Stephane Beaulieu" To: "Scott G. Kelly" , Subject: RE: dhcp/modecfg summary Date: Thu, 6 Feb 2003 16:37:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E429952.26EF2762@bstormnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The bias shines through a little, but a good effort at restraint none the less ;) I'll try to do the same... > > As Scott Fanning pointed out, it has certainly been a spirited debate. > Below is a summary from my perspective. I intend this to be objective, > though it probably isn't completely free of bias. As an aside, it seems > clear that some posters don't have much deployment experience with > modecfg *or* dhcp relay. While those folks must not be ignored, neither > should they be primary drivers of this discussion. > > - There are three basic models: local address pool, radius server > assigns addresses, and dhcp; there are two (suggested) models for dhcp: > over IP, and over IKE > > - a local address pool does not scale; while this is sufficient for > small implementations, it won't work in large deployments. Radius scales > if a dhcp server is involved somehow, but not very well if per-user > unique addresses must be preconfigured into radius. > > - some folks seem to imply that remote access entails only a pc > connected to the target network over the internet; in fact, many > telecommuter applications involve a personal sgw at the remote end, with > a small network behind it - this should not be ignored in evaluating > prospective mechanisms. Agreed. Though, this can be done via either method, so I'm not sure if you were trying to make a point... > > - the suggested inability of dhcp-based methods to support policy based > on pre-assigned ip is red herring, as an implemenation may set up > template policies based on user class and then back-fill the address > once assigned with either modecfg or dhcp The ability to combine the phase 1 ID, and/or the SLA user and/or group info with your VPN policy to determine which users are permitted to do what, and on which networks is possible with mode-cfg, and is a popular method of deployment. This is especially popular used in conjunction with RADIUS and even LDAP. Though it is possible with DHCP, it is definitely not as straight-forward, nor as easy to administer. > > - quite a few vendors have implemented dhcp, but apparently more have > implemented modecfg I'm curious to know who the dhcp vendors are? and on what operating systems they've done it? Trying to figure out if any OS's are trickier than others. Were there problems in implementations that had IPsec in the stack? Do they actually use the existing DHCP code, or did it require "special cases" or a whole new implementation for VPN? I realize that it's not rocket science, or advanced calculus, or, etc, etc, etc.... I'm just trying to get a handle on how much real experience there is here. I know that we've done mode-cfg (Client side) on all MS platforms, Linux, Solaris, Mac, as well as all our homegrown OSs (IOS, PIX, VPN3000), and all have been quick and pain free > > - even if ike changes, dhcp implementations will remain, so modecfg2 is > not quite a freebie, while dhcp is for vendors who've already > implemented it; > on the other hand, vendors who have not implemented dhcp relay would be > impacted, but they will be impacted either way if we agree that support > for dhcp-inform is required. > > - the dhcp model provides a great deal of flexibility due to richness of > options; you have to look at how dhcp is being used in contemporary > networks to understand this. Clearly, some folks have yet to do this. As > for > extensibility, vendor-specific options provide a clear path. You're now putting some of your vendor-specific VPN policy on your dhcp server. VPN policy long-term belongs in the IPSP (if that ever ends up being deployed). In the short term though, I definitely feel better using mode-cfg, and having the policy stored in the VPN head-end (or RADIUS server, or LDAP), than in a DHCP server. > > - one stated aim of this wg in redesigning IKE has been to minimize > impact on ike, to not add anything which is not required. If we stick to > this position, this seems to imply that dhcp support will be required > regardless (via dhcp inform and relay), unless we actually intend to > expand modecfg2 to encompass all dhcp options plus some new > ipsec-specific options. This is a critical point: some modecfg2 > proponents do not just want address assignment - they seem to want > policy config, along with "other things". This wg must decide if this is > acceptable. I think the main goal was to increase security and interoperability. > > - options: support both, support modecfg2 only, or support dhcp only May I add an option? Support mode-cfg with DHCP-inform for those who absolutely must speak to a DHCP server for whatever feature-rich feature which is so important. Those who don't want / need anything other than basic bootstrapping don't need intercept, modify?, snoop? DHCP packets. > > - I would vote no on modecfg2 only, as this will forego the flexibility > and power of dhcp-based methods, duplicate much of the functionality, > and significantly increase the complexity of the ike implementation - a > huge step backward, in my view. I vote mode-cfg w/ DHCP-inform. My reasoning is that I haven't seen a need for the other features of DHCP in my 6 years or so of deploying mode-cfg (though I'm not in denial that it won't happen, eventually). I have however seen MANY customers feature requests for VPN policy provisioning that can VERY easily be done securely via mode-cfg. Ease of use = deployment, and I think that is the end goal here. Mode-cfg is lightweight and handles 95% of the cases. We can use DHCP-inform for the rest. > > - I prefer dhcp only, because I know it can be done, and that it is not > rocket science - no advanced calculus, no theoretical physics, just > plain vanilla software engineering - complaints to the contrary not > withstanding. Yes, you need to think before you start thrashing around > in the code. This is not a one-afternoon hack job. No, it does not take > a genius to find an elegant way to integrate this functionality. I could attempt to dig a 6 inch hole with a back-hoe too. But I'd much rather use a shovel ;) > > - I could be pummeled into supporting a marriage of modecfg2 and dhcp if > the modecfg functionality were limited to IP address assignment only. This works for me ! A very lightweight method of obtaining an IP address that still allows us to do our user based policy provisioning, and gives you the feature-richness of DHCP if you need it. All for the low, low price of 5 years of bickering... Done ! Where do I sign? Seriously, it's time to bring this to an end, and this option, I think, both camps can live with. > But I > would be a reluctant supporter at best, since this requires an > implementation to carry both mechanisms, and I don't think it's been > demonstrated that IKE should accommodate this. What I *do* think has > been demonstrated is that some vendors who chose modecfg in ikev1 are > reluctant to modify their implementations - a political reality I'd > prefer we not weigh too heavily, but which we (unfortunately) cannot > ignore. What you fail to realize is that there are 2 reasons why vendors have chosen to use mode-cfg in the past, and are reluctant to part with it. 1 - Ease of implementation (yeah, yeah, dhcp not rocket science, yada yada yada...). At my last count, which was quite a while ago...(bakeoff in San Diego, 2000?) there were something like 25 different implementations of mode-cfg w/IKEv1 by about 20 different vendors. Why mode-cfg and not DHCP? Use a small hammer for a small nail.... 2 - Extensibility This is the stuff you don't know about, because it's not public. There's more to bootstrapping a VPN RA Client than IP, WINS, DNS. There's "value add" stuff you can do too. This is a little taboo because *some* of it overlaps with IPSP. When IPSP is done and deployed, we might pull some stuff out of our mode-cfg extensions and use IPSP. But we'll never be able to do it all in IPSP, because some of it is crazy customer features (which will never be standardized...) and some of it is very implementation dependant. The point here is that though you'd like to believe we're just lazy and don't want to spend a couple of days hooking into the various DHCP implementations in the various stacks and OSs that we need to deal with (OK, I'd rather not to tell you the honest truth :), we just plain can't completely switch to *just* DHCP, because it can't do everyting we need it to do. So, we're not just pig-headed. We have real customer needs that we've solved with mode-cfg, and we can't drop those features in the upgrade to IKEv2. Stephane. > > > Scott From owner-ipsec@lists.tislabs.com Thu Feb 6 15:02:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16N2od04304; Thu, 6 Feb 2003 15:02:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13839 Thu, 6 Feb 2003 17:33:19 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: A basic question. Date: Thu, 6 Feb 2003 14:42:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <000a01c2cd9d$d4e915c0$2906140a@future.futsoft.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Thanks for all your reply. I also suspect the fragmentation/reassembly problem. Can anyone suggest another client which is a freeware or trial version for testing? On server side, I am running vxworks operating system. Thanks & Best Regards, Bepsy -----Original Message----- From: Balaji K [mailto:balajik@future.futsoft.com] Sent: Wednesday, February 05, 2003 9:09 PM To: 'Roy, Gilles'; 'Bepsy Paul' Cc: ipsec@lists.tislabs.com Subject: RE: A basic question. Hi Yes FTP are large packets. When a IPSec Router Recieves a packet of Size 1500 bytes the packet again needs to be Fragmented by IPSec because of the OverHead Added by it (Size of the Packet will exceed 1500 bytes). Safenet Client has to Reassemble the packet before decoding it. It Seem's to be problem in some versions of SafeNet Client with respcet to reassembly . SafeNet Client was not able to reassemble the Fragmented packets of Linux Router (Linux IP Stack). Even if you try a Ping from Host with more than 1500 bytes you will not get a response from Safenet Client Regards Balaji.K -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Roy, Gilles Sent: Thursday, February 06, 2003 6:39 AM To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: A basic question. You may be having MTU problems. You ICMP packets are probably all very small packets that don't need to be fragmented. The FTP packets are probably large enough that when you add the extra tunnel headers they need to be fragmented. You can confirm if fragmentation is an issue by pinging with large packets. Gilles -----Original Message----- From: Bepsy Paul [mailto:bepsy@airBB.com] Sent: Wednesday, February 05, 2003 3:26 PM To: ipsec@lists.tislabs.com Subject: A basic question. Hi, I am developing a VPN s/w for a small (9 engineers only) start-up company. I have developed a VPN with only 3DES and SHA-1-96 support and for TUNNEL mode. Now I am testing that with Safenet VPN client. My question is, the VPN tunnel works well with ICMP. But when I try FTP, it's not working. Can anyone point out any possible problem with FTP? I am processing ICMP, TCP and UDP packets in the same manner in IPSec output packet processing function. Your reply will be really appreciated. Bear with me for my simple question as I am just starting with VPNs. Thanks & Best Regards, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent Sent: Tuesday, February 04, 2003 6:02 PM To: John Lindal Cc: ipsec@lists.tislabs.com Subject: RE: new to VPN At 2:41 PM -0800 2/3/03, John Lindal wrote: > >> > There's a very large difference between a general purpose OS > like >>>> Windows or Unix, and an embedded system OS. Large, as in several >>>> orders of magnitude. >>> >>>Unless I'm missing something fundamental, comparing the raw sizes of >>>various operating systems is misleading. Assuming that the VPN >>>software is >>>installed at the bottom of the network stack, just above the NIC >>>driver, then it doesn't matter how big the rest of the OS is. The >>>only thing that >>>matters is the tiny little bit of the OS that takes the packet off >>>the NIC >>>and hands it to the VPN driver. >>> >>>Of course, this small part of the OS must not have any holes, the VPN >>>software must not have any holes, and the security policies must be >>>set correctly to weed out malicious or unwanted packets! >> >> I'm afraid you are missing something. Irrespectivbe of where the VPN >> software is installed in a general purpose platform/OS environment, >> that software can be subverted by a successful attack against any >> part of the rest of the OS. > >How can one attack the rest of the OS if the VPN component is located >at the only entry point and doesn't allow malicious packets to pass? > >> Your comment suggests that if the VPN access controls are working, >> then no evil packets can evade detection and thus be used to attack >> the higher >> layer software. We have lots of experience that indiactes otherwise. > >I think it's a matter of definitions. In any situation where malicious >packets get through the VPN filter, I would say that the access >controls are not working correctly :) John, I've often joked that when I was on the IAB for over a decade I missed the opportunity to define the "evil" bit in the IP header, which would flag malicious packets and make security so much easier :-) I know of no way to determine if a packet is malicious, in absolute terms. We characterize packets (or, more typically, sequences of packets) as malicious only once we understand the bad things than can happen, usually as a result of being the victim of an attack. So, detection of malicious packets is, in that sense, a two pass algorithm, with a possibly long with a possibly long interval between the passes. I didn't think that any firewall or IDS vendor really believed that it had filters or signatures or anomaly detection algorithms that were good enough to detect all malicious traffic. Thus, by your definition, ALL of these products have defective access controls. On what basis do you believe that your technology is capable of detecting and rejecting all malicious packets and thus is immune to attacks that might traverse the VPN component? Steve P.S. I think it would be better to not refer to functions like IDS as VPN components. The generally accepted terminology for VPNs is broad, bit I don't think most folks would claim that it encompasses Intrustion Detection. One may choose to provide IDS functions in the same box as IPsec, but the two are independent. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipsec@lists.tislabs.com Thu Feb 6 15:50:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16No1d05646; Thu, 6 Feb 2003 15:50:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13944 Thu, 6 Feb 2003 18:14:56 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE579@SARATOGA> From: Gregory Lebovitz To: "'Theodore Ts'o'" , ipsec@lists.tislabs.com Subject: RE: On revised identity (was "Moving forward...final edits...) Date: Thu, 6 Feb 2003 15:15:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Thursday, February 06, 2003 11:04 AM > To: Gregory Lebovitz > Cc: 'Derrell Piper'; ipsec@lists.tislabs.com > Subject: Re: On revised identity (was "Moving forward...final > edits...) --snip-- > Could you be specific? When you say, "the current text", are you > referring to the current text in the revised-identities I-D, or the > current text in ikev2-04 ID? I was referring to the text in ietf-ipsec-revised-identities-00 I-D, as that is what I believe ought be included (or something close, with more explanation/justification/clarification) in ikev2-04 I-D, rather than what is there today. From owner-ipsec@lists.tislabs.com Thu Feb 6 17:26:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h171Qhd08022; Thu, 6 Feb 2003 17:26:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14248 Thu, 6 Feb 2003 19:57:48 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE57A@SARATOGA> From: Gregory Lebovitz To: ipsec@lists.tislabs.com Subject: RE: dhcp/modecfg summary Date: Thu, 6 Feb 2003 16:57:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk within... > -----Original Message----- > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > Sent: Thursday, February 06, 2003 9:20 AM > To: ipsec@lists.tislabs.com > Subject: dhcp/modecfg summary > --SNIP-- > - one stated aim of this wg in redesigning IKE has been to minimize > impact on ike, to not add anything which is not required. If > we stick to > this position, this seems to imply that dhcp support will be required > regardless (via dhcp inform and relay), unless we actually intend to > expand modecfg2 to encompass all dhcp options plus some new > ipsec-specific options. I would strongly vote against modefg2 encompassing all DHCP options natively. I.E. we should not create additional modecfg2 attributes to cover all the things that DHCP does. In fact we do not need to, right? modecfg2 could be the delivery mechanism for DHCP options from a DHCP service external to the responder. Here I must confess that I should have paid more attention earlier, and spoken up sooner... and please don't hit me if I've repeated a previously proposed idea... but here goes anyway ... (1) we want to do only the things that absolutely have to be accomplished in IKE for basic client config in IKE. This means IP and DNS server, and *MAYBE* DNS, WINS. All else that DHCP might do can happen through a native DHCP request, protected by a CHILD_SA. (2) So we need a way for the client to communicate something of a DHCP-Acceptable identity (like MAC) to the responder. (3) then the responder can send a DHCP relay to the actual DHCP server, and provide back, through modecfg2 the appropriate IP and DHCP server (and maybe DNS, WINS). This gives us the scalability of having the IP assigned from the off-responder DHCP server form the start, and gets us away from only the responder having the pool of addresses. (4) the remainder of the DHCP attributes can be assigned directly between the client and DHCP server once the CHILD_SA gets established. We cannot make the above work (Modecfg2 being the conduit for initial DHCP) with the attributes currently listed in ikev2-04. We need two more things: the client needs to send identity for the DHCP server, and we need to explicitly define the DHCP relay from the responder to DHCP server. Then we can use existing modecfg2 responses to communicate the IP, DNS, WINS. Doesn't that give us the best of both worlds? We get to keep the ModeCFG formats that most of us already have. And the responder/gateway does not need to be the address POOL holder for the initial IP assignments (thought it could), so we get the scalability and control/flexibility of on-board or off-board DHCP, right? > This is a critical point: some modecfg2 > proponents do not just want address assignment - they seem to want > policy config, along with "other things". This wg must decide > if this is > acceptable. Implementors and vendors have all learned that we must have client configuration, extending to IP related configuration (e.g. IP, mask, DNS, WINS, expiry), as such are necessary to get the client's internal traffic flowing correctly through the remote gateway to the internal network. However, POLICY is a different matter, and I believe out of scope. But since we can send the DHCP server name/address in modecfg2, such a more robust DHCP exchange could occur once the CHILD_SA is established. > - options: support both, support modecfg2 only, or support dhcp only Or, as I explained, we support DHCP through modecfg2. > - I would vote no on modecfg2 only, as this will forego the > flexibility > and power of dhcp-based methods, duplicate much of the functionality, > and significantly increase the complexity of the ike > implementation - a > huge step backward, in my view. Unless "modecfgw only" means increased clarity of the INTERNAL_IP4_DHCP > - I could be pummeled into supporting a marriage of modecfg2 > and dhcp if > the modecfg functionality were limited to IP address assignment only. As proposed above? > But I > would be a reluctant supporter at best, since this requires an > implementation to carry both mechanisms, and I don't think it's been > demonstrated that IKE should accommodate this. What I *do* think has > been demonstrated is that some vendors who chose modecfg in ikev1 are > reluctant to modify their implementations - a political reality I'd > prefer we not weigh too heavily, but which we (unfortunately) cannot > ignore. I confess, we have modecfg1 already done. But I also have both DHCP client and server in my code, as well as DHCP relay. And all considered, I'd rather do as I've proposed above. Gregory. From owner-ipsec@lists.tislabs.com Thu Feb 6 17:40:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h171e8d08260; Thu, 6 Feb 2003 17:40:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14338 Thu, 6 Feb 2003 20:12:08 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE57C@SARATOGA> From: Gregory Lebovitz To: "'ipsec@lists.tislabs.com'" Subject: a few nits on pure modecfgv2 Date: Thu, 6 Feb 2003 17:12:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk NITS... I don't think that doing static assignment of v6 addressing the modecfg2 (or 1) way will really work in a genuine v6 environment. Client will likely need either DHCP6 through Modecfg2, or ability to essentially take a router advertisement type message. At least this makes more sense for genuine v6 interfaces/stacks that exist today. BTW, DHCP6 is just getting legs. Likewise, Internal_IP6_SUBNET will look something more like Path Delegation. Which, by the way, will likely occur through DHCP6 too. Last, is it worth renaming the INTERNAL_[IP4 | IP6]_NBNS values to INTERNAL_[IP4 | IP6]_WINS, as "WINS" is how most people normally refer to it? !! NETSCREEN IS MOVING !! New Contact Info starting 2/10: 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 408.543.8002 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.730.6002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Thu Feb 6 18:04:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1724Jd08787; Thu, 6 Feb 2003 18:04:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14408 Thu, 6 Feb 2003 20:33:45 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE57D@SARATOGA> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com, "'Charlie_Kaufman@notesdev.ibm.com'" Subject: RE: Ciphersuites for IKEv2, revised Date: Thu, 6 Feb 2003 17:33:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am also fine with the regrouping Charlie propsed. However, I should say that we see no big requirement for AH today, so I'm not itching for its inclusion. Given that Charlie hasn't yet proposed new suites (per above) I'll comment on thoughts wrt SHOULDS/MUSTS w/ Paul's last list. Label and thought follow each: > For Suite-ID, the following values are defined: > > Suite-ID Meaning > -------- ------- > 0 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 2 (1024-bit), defined in Appendix B.2 > HMAC-SHA1 integrity and prf MUST - interop w/ what most implementations have today. > 1 Covers: ESP > 3DES encryption with three keys > HMAC-SHA1 integrity MUST - interop w/ what most implementations have today. > 2 Covers: AH > HMAC-SHA1 integrity MAY - very few deployments actually use AH today. > 3 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 > HMAC-SHA1 integrity and prf SHOULD - interop w/ what many implementations have today. > 4 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 > HMAC-SHA1 integrity and prf MUST - A contentious move, I know. I think that from a pure security/performance perspective we should all be moving to AES. Making this a MUST will press that point. It may take some a while to get there. And that is fine. People can claim RFC compliance with a "*" and a footnote saying, "AES coming in [DATE]". as for interop, If you don't have it, say so and we'll move on to another interop test until you get it, but at least everyone will know they have to get there ASAP. > 5 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] > HMAC-SHA1 integrity and prf MAY - Beyond DH5 everything else is still pretty new and shifting. Believe we ought to update the RFC later once this space settles down a bit, and a majority have implemented. > 6 Covers: ESP > AES encryption in CBC mode with 128-bit keys > HMAC-SHA1 integrity MUST - same justification as #4 above. > 7 Covers: IKE > AES encryption in CTR mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] > AES-CBC MAC + XCBC integrity and prf MAY - WRT AES-CTR, agree w/ others' previous comments that these can be MUSTS in iSCSI RFC. WRT DH14, see #5. > 8 Covers: ESP > AES encryption in CTR mode with 128-bit keys > AES-CBC MAC + XCBC integrity MAY - Gregory. > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Sunday, February 02, 2003 11:17 AM > To: ipsec@lists.tislabs.com > Subject: Re: Ciphersuites for IKEv2, revised > > > At 6:38 PM -0500 2/1/03, Charlie_Kaufman@notesdev.ibm.com wrote: > >I believe it would be more confusing than clarifying to > >pretend that the algorithm negotiation is independent of > >whether we're talking IKE, ESP, or AH. > > I fully agree with Charlie here. > > > > >That said, I do think it would be a good idea to group > >the IKE, ESP, and AH suites both in their numbering > >ranges and as ordered in the specification. Would anyone > >object to my changing Paul's numbers? > > I think it is a good idea as well. Go for it. However, please do > *not* do anything that indicates that the private-use space has any > such breakdown, since some of the private-use uses will do things > that we probably don't expect (or want to know about...) > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu Feb 6 19:29:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h173THd10534; Thu, 6 Feb 2003 19:29:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14630 Thu, 6 Feb 2003 22:01:17 -0500 (EST) From: "Geoffrey Huang" To: "'Stephane Beaulieu'" , "'Scott G. Kelly'" , Subject: RE: dhcp/modecfg summary Date: Thu, 6 Feb 2003 19:03:37 -0800 Message-ID: <001801c2ce55$82c3b080$4dfe220a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > - the dhcp model provides a great deal of flexibility due > to richness of > > options; you have to look at how dhcp is being used in contemporary > > networks to understand this. Clearly, some folks have yet > to do this. As > > for > > extensibility, vendor-specific options provide a clear path. > > You're now putting some of your vendor-specific VPN policy on > your dhcp > server. VPN policy long-term belongs in the IPSP (if that > ever ends up > being deployed). In the short term though, I definitely feel > better using > mode-cfg, and having the policy stored in the VPN head-end (or RADIUS > server, or LDAP), than in a DHCP server. Stephane, I think this is well-put. We're used to using Radius/LDAP for policy - not so used to using DHCP. > What you fail to realize is that there are 2 reasons why > vendors have chosen > to use mode-cfg in the past, and are reluctant to part with it. > 1 - Ease of implementation (yeah, yeah, dhcp not rocket > science, yada yada > yada...). At my last count, which was quite a while > ago...(bakeoff in San > Diego, 2000?) there were something like 25 different > implementations of > mode-cfg w/IKEv1 by about 20 different vendors. Why mode-cfg > and not DHCP? > Use a small hammer for a small nail.... > 2 - Extensibility > This is the stuff you don't know about, because it's not > public. There's > more to bootstrapping a VPN RA Client than IP, WINS, DNS. > There's "value > add" stuff you can do too. This is a little taboo because > *some* of it > overlaps with IPSP. When IPSP is done and deployed, we might > pull some > stuff out of our mode-cfg extensions and use IPSP. But we'll > never be able > to do it all in IPSP, because some of it is crazy customer > features (which > will never be standardized...) and some of it is very implementation > dependant. The point here is that though you'd like to > believe we're just > lazy and don't want to spend a couple of days hooking into > the various DHCP > implementations in the various stacks and OSs that we need to > deal with (OK, > I'd rather not to tell you the honest truth :), we just plain can't > completely switch to *just* DHCP, because it can't do > everyting we need it > to do. > > So, we're not just pig-headed. We have real customer needs that we've > solved with mode-cfg, and we can't drop those features in the > upgrade to > IKEv2. Again, I think this is well-stated. We have experience with mode config - we've seen it solve problems we have. -g > Stephane. > > > > > > > Scott > > From owner-ipsec@lists.tislabs.com Thu Feb 6 20:32:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h174WXd11674; Thu, 6 Feb 2003 20:32:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14864 Thu, 6 Feb 2003 23:06:26 -0500 (EST) Message-ID: <82CC1E573B94A648B87027C9419E2C055A6B7D@losgatos> From: Michael Choung Shieh To: Gregory Lebovitz , "'Derrell Piper'" , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: RE: On revised identity (was "Moving forward...final edits...) Date: Thu, 6 Feb 2003 20:03:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have different view on this. The purpose of revised identity draft is to address the issues when using certificate. However, I think most of the confuse comes from lack of clarification on how to deal with identity payload (similar to what draft-ietf-ipsec-pki-profile-01.txt does). Replace it with new set of identity won't get any better without clear and detailed clarification of the usages. my comments on FullID payload: 1. For type 1 (standalone certificate), why it's better than ID_DER_ASN1_DN? 2. FOR type 3 (hash and URL), is it dangerous that the gateway will try to do http with innocent party with instruction of unauthenticated peer? 3. For type 6 (IDForShareSecret), if both sides know the ip address of the peer and try to convert their ip address into ascii string, they may have different translation (eg. "::3:1" vs "00::03:01" in IPv6). ======================= Michael Shieh -----Original Message----- From: Gregory Lebovitz [mailto:Gregory@netscreen.com] Sent: Thursday, February 06, 2003 11:03 AM To: 'Derrell Piper'; Theodore Ts'o; ipsec@lists.tislabs.com Subject: RE: On revised identity (was "Moving forward...final edits...) Derrell, thanks for taking the lead to summarize this for us. Comments on your summary within... > -----Original Message----- > From: Derrell Piper [mailto:ddp@electric-loft.org] > Sent: Wednesday, February 05, 2003 3:46 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: Moving forward with IKE V2: A proposal for final edits to > ikev2-04 --SNIP-- > > Would the proposed identity revisions make things so much better that > it would clear up some large majority of PKI interoperability > problems? It would make the IDforSharedSecret completely straightforward, which addresses 90%+ of the deployments going out. For those very few deployments that use certs, it makes using certs more efficient (don't have to send the cert every IKE exchange). It also removes the issue of how to configure and what to configure in the various cert fields a non-issue for the protocol. The user can specify whatever they want wherever they want in the cert, and as long as the implementation allows them to, via UI, select and match those fields' contents, it will work. > I don't think so. I think most of the problems are due somewhat to > the inherent complexity of certificate-based PKI > interoperability and, > moreover, to the lack of a defined PKI profile for IKE. I happen to > think there's more value in defining a PKI profile, such as the one > described in, draft-ietf-ipsec-pki-profile-01.txt. We don't need > revised identities to do that. It seems similarly clear that revised > identities would bring with them a new and entirely different set of > interoperability issues. Regardless of revised identities, we definitely need a cert profile, but the total amount of things we need to specify in the cert profile for v2 will be much less than the equivalent document for v1. > I have concerns that the management paradigm for many vendors is very > closely tied to the existing IKE identity types, so wholesale > revision > in this area might well represent a serious headache for many > vendors. > The impact of the protocol changes is largely transparent and > the other > revisions ought to mostly present themselves as elimination of > unnecessary configuration options. Deleting things is > relative easy. > But I can see how wholesale identity revision might seriously impact > much of the existing management software, end-user documentation, and > vendor regression testing. I think we do need to be concerned about > fielded implementations. This is a great point. Must of us have already developed extensive and complicated management stuff to get around the perplexity of the v1 protocol wrt identity and certs. I agree, we would have new work to do, mostly because the new way would be so much easier. Also, the UI's would become cluttered, as now we would have to have 2UI's, one for v1 support and one for v2 support. > From an implementation standpoint, I also worry about combining > something like identity revision with all the other IKEv2 changes. > You'd essentially be starting from scratch at the next bake-off. Now > I'm not going to claim lots and lots of code reuse between IKEv1 and > IKEv2, yet there is some overlap. But if you completely rototill the > identity processing on top of this, you're very close to > starting from > scratch. another good point. The only consolation is that what we'd be starting from would appear to be MUCH more direct. We would only need to focus on interop for the format of how we send options 0-5, and not so much the content of the certs themselves, as that would be an UI matching issue. > In summary, our strategy of ignoring this has worked so well in the > past that I recommend we continue it a while longer. agreed that we possibly cannot get full consensus, or fully completed text on this in one week. But I do think we should forgoe the re-work agreed to above, and fix the protocol know while we still can. Gregory. !! NETSCREEN IS MOVING !! New Contact Info starting 2/10: 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 408.543.8002 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.730.6002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Fri Feb 7 01:21:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h179L4d10847; Fri, 7 Feb 2003 01:21:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15516 Fri, 7 Feb 2003 03:52:33 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F1D@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , "'Scott G. Kelly'" Cc: ipsec@lists.tislabs.com Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.] Date: Fri, 7 Feb 2003 09:54:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, See my comments below. > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: donderdag 6 februari 2003 17:20 > To: Van Aken Dirk; 'Scott G. Kelly' > Cc: ipsec@lists.tislabs.com > Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack > against RFC3456.] > > > Dirk, the main point you can take from my posting this problem is that > RFC3456 has had relatively little mileage and implementation > experience > compared to modecfg. People have had years to discover the inherent > problems with modecfg and understand them, they've also had years to > understand how useful it can be. RFC3456 is relatively young and not > entirely understood by this working group so there are likely > many scenarios > where it will have problems that have not been discovered. Do not agree with the term "many" because RFC3456 is almost transparent to IKE. Setting up a tunnel for DHCP is not different from setting up a tunnel for any other protocol. The only difference is that the SPD/SAD selectors must contain the limited broadcast address (255.255.255.255) and the default address 0.0.0.0. and of course transport protocol UDP, destination ports/source port 67/68. As said before, as soon as DHCP packets pass through the SPD, it is standard IP/DHCP relay processing. If there would be a problem we would have heard it by now because this technology has been proven over the years. And that's the beauty of RFC3456, there is almost no interaction with IPSec and the interaction can be done via standardized API/interfaces. Of course on the point where there is interaction between DHCP/IKE/IPSec I agree with you that one must be careful to not introduce side effects. > The one I pointed out is just one of those, will there be > others? See my answer on your so called attack below. What you doing here is trying to put RFC3456 in a negative daylight. i.e. Using words such as "many", "one of those" and razing questions such as "will there be others ?" you just try to scare/confuse the audience. Why don't we look at the method in a positive way: the protocol is good until it is has been proven otherwise ? > Most likely. Should they be posted and discussed? Absolutely. Yes of course but in a positive way. Because up till now I heard all kind of arguments against the solution, some of these being in a different protocol layer. > Will they have > solutions that could change our understanding or > implementation of RFC3456 ? > Who knows. > Dirk, you wrote. > > I would agree with you Darren, if this same scenario would work > > form the VPN > > client side because there is far less control on who is > sitting behind the > > VPN client. > > Why would it not work from a client? If the selectors are > such that all > traffic is tunnelled then a client could send DHCPACKs to the > DHCP-relay on > the SGW, correct? Yes, but then again have look at RFC3056 and how it can be applied. FYI, - we use the Agent Circuit ID Sub-option to reference the tunnel via which DHCP requests arrived into the system - we put information into the Agent Remote ID Sub-option that is specific to the relaying system and protected via cryptographic techniques. As you will read in the RFC, the server must loop the complete contents of the DHCP relay information option. Hence if we receive DHCP acks we can easily check whether these are replies to original (relayed) requests or not. Over & out - Dirk From owner-ipsec@lists.tislabs.com Fri Feb 7 02:23:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17ANSd18145; Fri, 7 Feb 2003 02:23:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15605 Fri, 7 Feb 2003 04:56:46 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F1E@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Scott G. Kelly'" , ipsec@lists.tislabs.com Subject: RE: dhcp/modecfg summary Date: Fri, 7 Feb 2003 10:59:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Scott's (G. Kelly) summary and what I will remember most from the discussion is that at least a few people are now looking into DHCP related RFC's and beginning to realize that beside IKEModeCfg that there are other solutions available. Anyway I propose following changes to section 5.15: 1) 5.15 Configuration Payload The Configuration payload, denoted CP in this document, is used to exchange configuration information between IKE peers. Implementations MAY use other methods such as the one described in [x1]. 10 References [x1] B. Patel, B. Aboba, S. Kelly, V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4)- Configuration of IPsec Tunnel Mode. 2) I would prefer that attribute type INTERNAL_IP4_DHCP becomes a MUST support attribute. The rational behind this request is that at least I can rely upon this attribute as a way out if I can't fulfil more advanced scenario's with IKEModeCfg. Thanks in advance - Dirk > -----Original Message----- > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > Sent: donderdag 6 februari 2003 18:20 > To: ipsec@lists.tislabs.com > Subject: dhcp/modecfg summary > > > As Scott Fanning pointed out, it has certainly been a spirited debate. > Below is a summary from my perspective. I intend this to be objective, > though it probably isn't completely free of bias. As an > aside, it seems > clear that some posters don't have much deployment experience with > modecfg *or* dhcp relay. While those folks must not be > ignored, neither > should they be primary drivers of this discussion. > > - There are three basic models: local address pool, radius server > assigns addresses, and dhcp; there are two (suggested) models > for dhcp: > over IP, and over IKE > > - a local address pool does not scale; while this is sufficient for > small implementations, it won't work in large deployments. > Radius scales > if a dhcp server is involved somehow, but not very well if per-user > unique addresses must be preconfigured into radius. > > - some folks seem to imply that remote access entails only a pc > connected to the target network over the internet; in fact, many > telecommuter applications involve a personal sgw at the > remote end, with > a small network behind it - this should not be ignored in evaluating > prospective mechanisms. > > - the suggested inability of dhcp-based methods to support > policy based > on pre-assigned ip is red herring, as an implemenation may set up > template policies based on user class and then back-fill the address > once assigned with either modecfg or dhcp > > - quite a few vendors have implemented dhcp, but apparently more have > implemented modecfg > > - even if ike changes, dhcp implementations will remain, so > modecfg2 is > not quite a freebie, while dhcp is for vendors who've already > implemented it; > on the other hand, vendors who have not implemented dhcp > relay would be > impacted, but they will be impacted either way if we agree > that support > for dhcp-inform is required. > > - the dhcp model provides a great deal of flexibility due to > richness of > options; you have to look at how dhcp is being used in contemporary > networks to understand this. Clearly, some folks have yet to > do this. As > for > extensibility, vendor-specific options provide a clear path. > > - one stated aim of this wg in redesigning IKE has been to minimize > impact on ike, to not add anything which is not required. If > we stick to > this position, this seems to imply that dhcp support will be required > regardless (via dhcp inform and relay), unless we actually intend to > expand modecfg2 to encompass all dhcp options plus some new > ipsec-specific options. This is a critical point: some modecfg2 > proponents do not just want address assignment - they seem to want > policy config, along with "other things". This wg must decide > if this is > acceptable. > > - options: support both, support modecfg2 only, or support dhcp only > > - I would vote no on modecfg2 only, as this will forego the > flexibility > and power of dhcp-based methods, duplicate much of the functionality, > and significantly increase the complexity of the ike > implementation - a > huge step backward, in my view. > > - I prefer dhcp only, because I know it can be done, and that > it is not > rocket science - no advanced calculus, no theoretical physics, just > plain vanilla software engineering - complaints to the contrary not > withstanding. Yes, you need to think before you start thrashing around > in the code. This is not a one-afternoon hack job. No, it > does not take > a genius to find an elegant way to integrate this functionality. > > - I could be pummeled into supporting a marriage of modecfg2 > and dhcp if > the modecfg functionality were limited to IP address assignment only. > But I > would be a reluctant supporter at best, since this requires an > implementation to carry both mechanisms, and I don't think it's been > demonstrated that IKE should accommodate this. What I *do* think has > been demonstrated is that some vendors who chose modecfg in ikev1 are > reluctant to modify their implementations - a political reality I'd > prefer we not weigh too heavily, but which we (unfortunately) cannot > ignore. > > > Scott > From owner-ipsec@lists.tislabs.com Fri Feb 7 04:08:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17C86d24559; Fri, 7 Feb 2003 04:08:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15831 Fri, 7 Feb 2003 06:41:21 -0500 (EST) Message-Id: <200302071011.h17AB0of073670@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: dhcp/modecfg summary In-reply-to: Your message of Thu, 06 Feb 2003 09:20:18 PST. <3E429952.26EF2762@bstormnetworks.com> Date: Fri, 07 Feb 2003 11:11:00 +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: - some folks seem to imply that remote access entails only a pc connected to the target network over the internet; in fact, many telecommuter applications involve a personal sgw at the remote end, with a small network behind it - this should not be ignored in evaluating prospective mechanisms. => this is especially true in an IPv6 environment. In fact, if DHCPv6 is not the prefered address allocation mechanism (stateless autoconf is used nearly everywhere), it is the mechanism of choice for prefix allocation. I won't complain if the modecfg for IPv6 can handle only prefix allocations (note this is easier than the current option :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Feb 7 05:23:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17DNad27999; Fri, 7 Feb 2003 05:23:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16064 Fri, 7 Feb 2003 07:57:51 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A59@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Fri, 7 Feb 2003 14:00:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Dirk, since you appear to have the best implementation > understanding of > RFC3456 of the posters to this list, could you post all the > RFCs, drafts, > etc. that a person would need to know to fully implement the > DHCP-relay? > This may help others come up to speed quicker if they don't have to go > digging for them. > > Thanks, > Darren Hi Darren, Here are the RFC's and some condensed info. Cheers - Dirk I guess reading following RFC's is sufficient to implement RC3456: - RFC1542 Clarifications and Extensions for the Bootstrap Protocol --> This RFC gives the most details on a basic DHCP Relay. - RFC3046 DHCP Relay Agent Information Option --> This RFC defines the DHCP Relay Information Option which is a container option. In addition it also defines two sub options that can be used in combination with the container option. To implement RFC3456, RFC3046 sufficient. However implementers wanting to come up with sophisticated/advanced scenario's might consider reading a few drafts posted on the DHCP working group or define their own sub-options ... - RFC3546 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode. --> and of course this was the RFC which was subject of this debate. For convenience let me add a little summary on the use of DHCP relays. BOOTP/DHCP relays were conceived to make BOOTP/DHCP based address assignment scalable. Without relays a DHCP server must be located on every link layer network as limited broadcasts are not allowed to cross routers. So the main function of DHCP relays is to converts limited broadcasts into IP unicasts by relaying requests to DHCP servers. The server talks-back to the relay via the "giaddr" field in relayed DHCP packets. Prior to RFC3046, the giaddr field was overloaded with 3 functions: - it allows the server to select a client IP address within the same subnet as the port on which the request was detected - it allows the server to talk-back to the DHCP relay - it allows the DHCP relay to figure out on which link-layer-network it must relay the DHCP reply The added value of RFC3046 is that - it allows to tear these 3 functions apart - it provides a generic and extensible mechanism to add/subtract relay related options to DHCP packets - it operates in a stateless manner just because the server is required to loop RFC3046 fields A little drawback of RFC3046 is that it is written in the context of Cable Modem networks and some people might have difficulties in understanding the terminology. Apart from terminology, RFC3046 is generic and implementers have successfully applied RFC3046 to complete different situations such as MPLS based VPN's and in the context of RFC3456, to IPSec based VPN's. From owner-ipsec@lists.tislabs.com Fri Feb 7 08:21:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GLpd09818; Fri, 7 Feb 2003 08:21:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16446 Fri, 7 Feb 2003 10:46:44 -0500 (EST) Message-ID: <3E43D6BE.5080205@creeksidenet.com> Date: Fri, 07 Feb 2003 10:54:38 -0500 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ike2-v4: request or response Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After multiple reads of ike2-v4 I still cant figure out how to determine if a received message is a request or response. Clearly, I must be missing something. For example, if the original ike-sa initiator receives msg sequence N and is waiting for a response with sequence N, how does it know that it is actually a response if on the off chance the next expected request from the original responder is always sequence N? Any enlightenment would be greatly appreciated. Regards, Jeff From owner-ipsec@lists.tislabs.com Fri Feb 7 08:28:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GSAd10894; Fri, 7 Feb 2003 08:28:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16468 Fri, 7 Feb 2003 11:00:53 -0500 (EST) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899BE9FB93@01mail.nomadix.com> To: ipsec@lists.tislabs.com Date: Thu, 6 Feb 2003 17:20:16 -0800 Subject: typical IPsec-based VPNs incl. modecfg vs. DHCP MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_17_26_33_Thursday_February_06_2003_29148" X-Mailer: Internet Mail Service (5.5.2653.19) 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_ST_17_26_33_Thursday_February_06_2003_29148 Content-Type: text/plain I have a few clarifications regarding usage of IPsec for VPNs. I have been even going through the thread of Modecfg vs. DHCP and seem a little confused regarding the functionality. - This particular debate of Modecfg vs. DHCP relates only to remote access scenarios or does it extend to address management for site-to-site VPNs. I would distinguish the 2 using the following definitions- One tunnel per machine and address to be given out (whichever way - modecfg or DHCP) at tunnel setup time would be Remote Access. Site-to-site would be that tunnel is setup apriori between 2 gateways and both sides would be different private subnets. Users in site-to-site VPNs get addresses typically from their own subnet's DHCP servers. Please correct me if i am wrong.. - Is it also possible that in a site-to-site VPN the address allocation is handled by only one of the private networks (subnets). ie. DHCP is tunneled over to this network from all other private networks and responses tunneled back? Is it a typical setup? Is the discussion of modecfg vs. DHCP relevant in this case? I assume that their might be some routing issues in this setup for tunneling the responses back to the DHCP requesters through the right tunnels. Maybe some state maintenance at the gateways. - Typical IPsec implementations. Most of them are bump in the stack (software ones).. Am I correct? Does it mean that IP routing is the only way to direct traffic into the right tunnels? i.e destination address based. Are their any implementations that do not follow this paradigm. Any pointers would be helpful. thanks -Bik ---------------------------------------------------------------------------- -------------- Bik Singh 818-575-2518 (Off) Research Scientist 818-597-1502 (Fax) Product Development 31355 Agoura Road Nomadix Westlake Village, CA 91361 ----=_NextPart_ST_17_26_33_Thursday_February_06_2003_29148 Content-Type: text/html Content-Transfer-Encoding: quoted-printable I have a = few=20 clarifications regarding usage of IPsec for VPNs. I have been even going th= rough=20 the thread of Modecfg vs. DHCP and seem a little confused regarding the=20 functionality. - This pa= rticular=20 debate of Modecfg vs. DHCP relates only to remote access scenarios or does = it=20 extend to address management for site-to-site VPNs. I would distinguish the= 2=20 using the following definitions- One tunnel per machine and address to be g= iven=20 out (whichever way - modecfg or DHCP) at tunnel setup time would be Remote Access. Site-to-site would be that tunnel is setup apriori between 2 gatewa= ys=20 and both sides would be different private subnets. Users in site-to-site VP= Ns=20 get addresses typically from their own subnet's DHCP servers. Please correc= t me=20 if i am wrong.. - Is it a= lso=20 possible that in a site-to-site VPN the address allocation is handled by on= ly=20 one of the private networks (subnets). ie. DHCP is tunneled over to this ne= twork=20 from all other private networks and responses tunneled back? Is it a typica= l=20 setup? Is the discussion of modecfg vs. DHCP relevant in this case? I assum= e=20 that their might be some routing issues in this setup for tunneling the=20 responses back to the DHCP requesters through the right tunnels. Maybe some= =20 state maintenance at the gateways. - Typical= IPsec=20 implementations. Most of them are bump in the stack (software ones).. Am I correct? Does it mean that IP routing is the only way to direct traffic int= o the=20 right tunnels? i.e destination address based. Are their any implementations= that=20 do not follow this paradigm. Any pointers would be helpful. <= /DIV> thanks -Bik ------------------------------------------------------------------= ------------------------=20 Bik=20 Singh &nbs= p; &= nbsp; =20 818-575-2518 (Off) Research=20 Scientist = =20 818-597-1502 (Fax) Product=20 Development &nbs= p; 31355=20 Agoura Road Nomadix=20 =20 =20 Westlake Village, CA 91361=20 ----=_NextPart_ST_17_26_33_Thursday_February_06_2003_29148-- From owner-ipsec@lists.tislabs.com Fri Feb 7 08:30:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GUEd11260; Fri, 7 Feb 2003 08:30:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16462 Fri, 7 Feb 2003 10:59:53 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: ALAIN PATRICK AINA Organization: TRS To: Stephen Kent , John Lindal Subject: Re: new to VPN Date: Fri, 7 Feb 2003 10:43:09 +0000 X-Mailer: KMail [version 1.3.1] Cc: References: <200302032241.h13MfMn17917@localhost.localdomain> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > >How can one attack the rest of the OS if the VPN component is located at > >the only entry point and doesn't allow malicious packets to pass? Weakness in OS can make packets bypass VPN component and filters. --alain From owner-ipsec@lists.tislabs.com Fri Feb 7 09:00:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17H0bd13520; Fri, 7 Feb 2003 09:00:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16593 Fri, 7 Feb 2003 11:24:38 -0500 (EST) Date: Fri, 7 Feb 2003 11:26:45 -0500 From: "Theodore Ts'o" To: Michael Choung Shieh Cc: Gregory Lebovitz , "'Derrell Piper'" , ipsec@lists.tislabs.com Subject: Re: On revised identity (was "Moving forward...final edits...) Message-ID: <20030207162645.GA4474@think.thunk.org> References: <82CC1E573B94A648B87027C9419E2C055A6B7D@losgatos> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82CC1E573B94A648B87027C9419E2C055A6B7D@losgatos> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 06, 2003 at 08:03:43PM -0800, Michael Choung Shieh wrote: > > 2. FOR type 3 (hash and URL), is it dangerous that the gateway will try to > do http with innocent party with instruction of unauthenticated peer? Well, the server can have an access list of what web servers it will allow itself to contact on the instruction of an unauthenticated peer, but it does add additional complexity to the implementation and the configuration load of the IPSEC product. In addition, if vendors leave the default ACL such that any arbitrary URL will be visited by the server, yes, that could lead to some very entertaining opportunities from the point of view of potential attackers. However, it's actually worse than that from the client's perspective. In some cases, the client will not have access to the internet beforehand. For example, the VPN solution in use by my company, AT&T's Managed Tunnel Service, has two modes. In one mode, an existing Internet connection is used to connect to the MTS server, and the client does have the capability to make arbitrary HTTP requests before the VPN connection is made. In the other mode, the client is calling (over the POTS network) a modem bank, and is not permitted, for obvious reasons, to have general internet access before completing the initial setup with the VPN. So in this case, it cannot possibly work from the perspective of the client, since in this case the client doesn't have even an IP address (because DHCP or the Configuration payload negotation hasn't happened yet). In the case of AT&T Managed Tunnel Services, the VPN gateway could chose to use different ID types based on how the initial connection was made, but that would add complexity to its architecture/implementation --- and so I wonder if an implementor might simply chose not to use hash/URL at all, and just simply send the entire certificate chain each time. (In other cases, some company's security organizations have regulations that say that a laptop is may not make -- and must be configured to not allow --- arbitrary connections over internet while it is connected to the VPN. Whether or not the I/T security folks would be happy with the Road Warrior's laptop making unsecured connections to the Internet *just* *before* connecting through the VPN is a different questions. I suspect some might get heartburn over this issue, customers will probably demand that whether or not hash/URL scheme can be allowed at all must be a site configurable option.) Basically, a hash/URL scheme can be made to work (and could be added to either the existing ikev1/ikev2-04 framework, or in the revised identity draft. ). It is essentially a trade-off between complexity (in terms of needing an http client engine in an ipsec implementation plus some specialized rules about when it is and isn't OK to use it, and what URL's are OK to contact) and the benefit of decreasing the size of the IKE messages. Comments about whether this particular engineering trade-off is worth it is welcome. - Ted From owner-ipsec@lists.tislabs.com Fri Feb 7 09:16:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17HGId14127; Fri, 7 Feb 2003 09:16:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16689 Fri, 7 Feb 2003 11:41:58 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Scott G. Kelly" , Subject: RE: dhcp/modecfg summary Date: Fri, 7 Feb 2003 11:44:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E429952.26EF2762@bstormnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excellent summary Scott, I had a few minor disagreements with it but others have already mentioned them. You said > - I could be pummeled into supporting a marriage of modecfg2 and dhcp if > the modecfg functionality were limited to IP address assignment only. This is what I support (not necessarily the pummeling part ;), but I think modecfg should carry what it did in IKEv1 (WINS/DNS/DHCP server). Beyond that DHCPINFORM may be sent by the client to the DHCP server address in the reply CP. Is this what you had in mind? In this scenario the SGW may implement a DHCP proxy, no DHCP relay is needed. Also, Bernard brought up some IPv6 problems in IKEv2 modecfg that were not mentioned in this summary which still need to be addressed. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > Sent: Thursday, February 06, 2003 12:20 PM > To: ipsec@lists.tislabs.com > Subject: dhcp/modecfg summary > > > As Scott Fanning pointed out, it has certainly been a spirited debate. > Below is a summary from my perspective. I intend this to be objective, > though it probably isn't completely free of bias. As an aside, it seems > clear that some posters don't have much deployment experience with > modecfg *or* dhcp relay. While those folks must not be ignored, neither > should they be primary drivers of this discussion. > > - There are three basic models: local address pool, radius server > assigns addresses, and dhcp; there are two (suggested) models for dhcp: > over IP, and over IKE > > - a local address pool does not scale; while this is sufficient for > small implementations, it won't work in large deployments. Radius scales > if a dhcp server is involved somehow, but not very well if per-user > unique addresses must be preconfigured into radius. > > - some folks seem to imply that remote access entails only a pc > connected to the target network over the internet; in fact, many > telecommuter applications involve a personal sgw at the remote end, with > a small network behind it - this should not be ignored in evaluating > prospective mechanisms. > > - the suggested inability of dhcp-based methods to support policy based > on pre-assigned ip is red herring, as an implemenation may set up > template policies based on user class and then back-fill the address > once assigned with either modecfg or dhcp > > - quite a few vendors have implemented dhcp, but apparently more have > implemented modecfg > > - even if ike changes, dhcp implementations will remain, so modecfg2 is > not quite a freebie, while dhcp is for vendors who've already > implemented it; > on the other hand, vendors who have not implemented dhcp relay would be > impacted, but they will be impacted either way if we agree that support > for dhcp-inform is required. > > - the dhcp model provides a great deal of flexibility due to richness of > options; you have to look at how dhcp is being used in contemporary > networks to understand this. Clearly, some folks have yet to do this. As > for > extensibility, vendor-specific options provide a clear path. > > - one stated aim of this wg in redesigning IKE has been to minimize > impact on ike, to not add anything which is not required. If we stick to > this position, this seems to imply that dhcp support will be required > regardless (via dhcp inform and relay), unless we actually intend to > expand modecfg2 to encompass all dhcp options plus some new > ipsec-specific options. This is a critical point: some modecfg2 > proponents do not just want address assignment - they seem to want > policy config, along with "other things". This wg must decide if this is > acceptable. > > - options: support both, support modecfg2 only, or support dhcp only > > - I would vote no on modecfg2 only, as this will forego the flexibility > and power of dhcp-based methods, duplicate much of the functionality, > and significantly increase the complexity of the ike implementation - a > huge step backward, in my view. > > - I prefer dhcp only, because I know it can be done, and that it is not > rocket science - no advanced calculus, no theoretical physics, just > plain vanilla software engineering - complaints to the contrary not > withstanding. Yes, you need to think before you start thrashing around > in the code. This is not a one-afternoon hack job. No, it does not take > a genius to find an elegant way to integrate this functionality. > > - I could be pummeled into supporting a marriage of modecfg2 and dhcp if > the modecfg functionality were limited to IP address assignment only. > But I > would be a reluctant supporter at best, since this requires an > implementation to carry both mechanisms, and I don't think it's been > demonstrated that IKE should accommodate this. What I *do* think has > been demonstrated is that some vendors who chose modecfg in ikev1 are > reluctant to modify their implementations - a political reality I'd > prefer we not weigh too heavily, but which we (unfortunately) cannot > ignore. > > > Scott From owner-ipsec@lists.tislabs.com Fri Feb 7 09:27:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17HRPd14524; Fri, 7 Feb 2003 09:27:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16731 Fri, 7 Feb 2003 11:52:04 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Gregory Lebovitz" , Subject: RE: dhcp/modecfg summary Date: Fri, 7 Feb 2003 11:54:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: <541402FFDC56DA499E7E13329ABFEA872CE57A@SARATOGA> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Gregory Lebovitz > Sent: Thursday, February 06, 2003 7:58 PM > To: ipsec@lists.tislabs.com > Subject: RE: dhcp/modecfg summary > > > within... > > > -----Original Message----- > > From: Scott G. Kelly [mailto:scott@bstormnetworks.com] > > Sent: Thursday, February 06, 2003 9:20 AM > > To: ipsec@lists.tislabs.com > > Subject: dhcp/modecfg summary > > > --SNIP-- > (1) we want to do only the things that absolutely have to be > accomplished in > IKE for basic client config in IKE. This means IP and DNS server, and > *MAYBE* DNS, WINS. All else that DHCP might do can happen through a native > DHCP request, protected by a CHILD_SA. > > (2) So we need a way for the client to communicate something of a > DHCP-Acceptable identity (like MAC) to the responder. No hitting here, but if DHCPINFORM only is used by the client the chaddr and client identifier is supposed to be ignored by the DHCP server, so they're not needed. If you want more than DHCPINFORM from the client then I think you will need "DHCP-Acceptable identity" on the client (i.e., chaddr and the client identifier used by the SGW for the initial lease). > > (3) then the responder can send a DHCP relay to the actual DHCP > server, and > provide back, through modecfg2 the appropriate IP and DHCP server > (and maybe > DNS, WINS). This gives us the scalability of having the IP > assigned from the > off-responder DHCP server form the start, and gets us away from only the > responder having the pool of addresses. > > (4) the remainder of the DHCP attributes can be assigned directly between > the client and DHCP server once the CHILD_SA gets established. > > We cannot make the above work (Modecfg2 being the conduit for > initial DHCP) > with the attributes currently listed in ikev2-04. We need two more things: > the client needs to send identity for the DHCP server, and we need to > explicitly define the DHCP relay from the responder to DHCP > server. Then we > can use existing modecfg2 responses to communicate the IP, DNS, WINS. You suggest the SGW needs to be a DHCP relay, if the client has an IP address and knows the address of the DHCP server then I don't think a relay is needed. Correct? > > Doesn't that give us the best of both worlds? We get to keep the ModeCFG > formats that most of us already have. And the responder/gateway does not > need to be the address POOL holder for the initial IP assignments (thought > it could), so we get the scalability and control/flexibility of > on-board or > off-board DHCP, right? > > > This is a critical point: some modecfg2 > > proponents do not just want address assignment - they seem to want > > policy config, along with "other things". This wg must decide > > if this is > > acceptable. > > Implementors and vendors have all learned that we must have client > configuration, extending to IP related configuration (e.g. IP, mask, DNS, > WINS, expiry), as such are necessary to get the client's internal traffic > flowing correctly through the remote gateway to the internal network. > > However, POLICY is a different matter, and I believe out of > scope. But since > we can send the DHCP server name/address in modecfg2, such a more robust > DHCP exchange could occur once the CHILD_SA is established. > > > - options: support both, support modecfg2 only, or support dhcp only > > Or, as I explained, we support DHCP through modecfg2. > > > - I would vote no on modecfg2 only, as this will forego the > > flexibility > > and power of dhcp-based methods, duplicate much of the functionality, > > and significantly increase the complexity of the ike > > implementation - a > > huge step backward, in my view. > > Unless "modecfgw only" means increased clarity of the INTERNAL_IP4_DHCP > > > - I could be pummeled into supporting a marriage of modecfg2 > > and dhcp if > > the modecfg functionality were limited to IP address assignment only. > > As proposed above? > > > But I > > would be a reluctant supporter at best, since this requires an > > implementation to carry both mechanisms, and I don't think it's been > > demonstrated that IKE should accommodate this. What I *do* think has > > been demonstrated is that some vendors who chose modecfg in ikev1 are > > reluctant to modify their implementations - a political reality I'd > > prefer we not weigh too heavily, but which we (unfortunately) cannot > > ignore. > > I confess, we have modecfg1 already done. But I also have both DHCP client > and server in my code, as well as DHCP relay. And all considered, > I'd rather > do as I've proposed above. > > Gregory. From owner-ipsec@lists.tislabs.com Fri Feb 7 10:26:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17IQRd17339; Fri, 7 Feb 2003 10:26:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16979 Fri, 7 Feb 2003 12:52:00 -0500 (EST) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899BE9FBBF@01mail.nomadix.com> To: ipsec@lists.tislabs.com Cc: vpn@lists.shmoo.com Date: Fri, 7 Feb 2003 09:40:12 -0800 Subject: IPsec VPNs incl. modecfg vs. DHCP MIME-Version: 1.0 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Posting again due to bad format last time. ------------------------------------------ I have a few clarifications regarding usage of IPsec for VPNs. I have been even going through the thread of Modecfg vs. DHCP and seem a little confused regarding the functionality. - This particular debate of Modecfg vs. DHCP relates only to remote access scenarios or does it extend to address management for site-to-site VPNs. I would distinguish the 2 using the following definitions- One tunnel per machine and address to be given out (whichever way - modecfg or DHCP) at tunnel setup time would be Remote Access. Site-to-site would be that tunnel is setup apriori between 2 gateways and both sides would be different private subnets. Users in site-to-site VPNs get addresses typically from their own subnet's DHCP servers. Please correct me if I am wrong.. - Is it also possible that in a site-to-site VPN the address allocation is handled by only one of the private networks (subnets). i.e.. DHCP is tunneled over to this network from all other private networks and responses tunneled back? Is it a typical setup? Is the discussion of modecfg vs. DHCP relevant in this case? I assume that their might be some routing issues in this setup for tunneling the responses back to the DHCP requesters through the right tunnels. Maybe some state maintenance at the gateways. - Typical IPsec implementations. Most of them are bump in the stack (software ones).. Am I correct? Does it mean that IP routing is the only way to direct traffic into the right tunnels? i.e. destination address based. Are their any implementations that do not follow this paradigm. Any pointers would be helpful. thanks -Bik ---------------------------------------------------------------------------- -------------- Bik Singh 818-575-2518 (Off) Research Scientist 818-597-1502 (Fax) Product Development 31355 Agoura Road Nomadix Westlake Village, CA 91361 From owner-ipsec@lists.tislabs.com Fri Feb 7 11:49:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17JnXd21367; Fri, 7 Feb 2003 11:49:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17235 Fri, 7 Feb 2003 14:13:50 -0500 (EST) Message-Id: <200302071916.h17JGPj8027962@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: On revised identity (was "Moving forward...final edits...) In-reply-to: Your message of "Fri, 07 Feb 2003 11:26:45 EST." <20030207162645.GA4474@think.thunk.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 14:16:24 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Tunnel Services, the VPN gateway could chose to use different Theodore> ID types based on how the initial connection was made, but that Theodore> would add complexity to its architecture/implementation --- and Theodore> so I wonder if an implementor might simply chose not to use Theodore> hash/URL at all, and just simply send the entire certificate Theodore> chain each time. yes, I'm sure that this will be the case. So what? You've just argued for why we need to be able to do things inline for intra-enterprise use. Frankly, I don't know why this situation is even mentioned. The laptops have to be configured with a trusted root, and you need configure only one of these. For the static situation where you only talk to one gateway, this is trivial. For the more complicated situation where you need to be connected to the mothercorp's gateway, and the gateway of the people you've been assigned to help that week, you already have a significantly more complicated policy than you described. The ability of the laptop to refer to their certificate *chain* indirectly is of great use to the gateway, because the chain can be as sophisticated as you like. The hash/URL scheme is very useful for larger *VPN*s of equals - particularly for cross-enteprises systems. Theodore> Basically, a hash/URL scheme can be made to work (and could be Theodore> added to either the existing ikev1/ikev2-04 framework, or in Theodore> the revised identity draft. ). It is essentially a trade-off Theodore> between complexity (in terms of needing an http client engine Theodore> in an ipsec implementation plus some specialized rules about Btw, who said anything about needing the http client in the IKE? For all you know, the whole thing is passed on to a policy server that may be an order of magnitude more complex. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkQGB4qHRg3pndX9AQEESgQAr1T2xExtK0EfRTNjZ+cwL2/aQ1sKe6+s X6q2PdH9Thil1rie/SB5WkRP0JnPhXl7zIZCQbkLT1QIYdDHwlidT2++3WkHAFBM yzCdyhkkOzKhf8twu1FyFs5uo3pdhXMPzXYjb64YuXepWtm+zfeZuMO2gRTymfIL WomfBnA+/sY= =8Ddp -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Feb 7 13:47:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17LlPd25340; Fri, 7 Feb 2003 13:47:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17482 Fri, 7 Feb 2003 16:12:46 -0500 (EST) Message-ID: <3E4421AF.9B64D1DC@airespace.com> Date: Fri, 07 Feb 2003 13:14:23 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: BSingh@Nomadix.com CC: ipsec@lists.tislabs.com, vpn@lists.shmoo.com Subject: Re: IPsec VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FBBF@01mail.nomadix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2003 21:15:52.0624 (UTC) FILETIME=[185F6B00:01C2CEEE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll take a shot at answering this. Comments inline below... BSingh@Nomadix.com wrote: > > Posting again due to bad format last time. > ------------------------------------------ > > I have a few clarifications regarding usage of IPsec for VPNs. I have been > even going through the thread of Modecfg vs. DHCP and seem a little confused > regarding the functionality. > > - This particular debate of Modecfg vs. DHCP relates only to remote access > scenarios or does it extend to address management for site-to-site VPNs. I > would distinguish the 2 using the following definitions- One tunnel per > machine and address to be given out (whichever way - modecfg or DHCP) at > tunnel setup time would be Remote Access. Site-to-site would be that tunnel > is setup apriori between 2 gateways and both sides would be different > private subnets. Users in site-to-site VPNs get addresses typically from > their own subnet's DHCP servers. Please correct me if I am wrong.. This is probably a reasonable attempt at a definition, but it leaves out remote access scenarios where a personal security gateway is at the remote end. Also, remote access users do not *necessarily* need address assignment, but this is often done to simplify windows networking tasks via the vpn. > - Is it also possible that in a site-to-site VPN the address allocation is > handled by only one of the private networks (subnets). i.e.. DHCP is > tunneled over to this network from all other private networks and responses > tunneled back? Is it a typical setup? Is the discussion of modecfg vs. DHCP > relevant in this case? I assume that their might be some routing issues in > this setup for tunneling the responses back to the DHCP requesters through > the right tunnels. Maybe some state maintenance at the gateways. I've never seen this attempted, but that doesn't mean it won't be done. Obvious issues result if connectivity is lost at renewal time. I have seen it done in telecommuter scenarios where the user has a small network behind a personal sgw, but again, there are issues if connectivity is lost and lease times are small. This can be resolved by having a lightweight dhcp server on the personal sgw which doles out short-lived config when the tunnel is down, and forwards dhcp through the tunnel when it is up. Modecfg doesn't seem to make much sense in such scenarios. > - Typical IPsec implementations. Most of them are bump in the stack > (software ones).. Am I correct? Does it mean that IP routing is the only way > to direct traffic into the right tunnels? i.e. destination address based. > Are their any implementations that do not follow this paradigm. Any pointers > would be helpful. I'll leave this one for someone else to answer... Scott From owner-ipsec@lists.tislabs.com Fri Feb 7 14:50:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Mofd27250; Fri, 7 Feb 2003 14:50:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17644 Fri, 7 Feb 2003 17:17:20 -0500 (EST) Message-Id: <200302072219.h17MJLZ8003926@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IPsec VPNs incl. modecfg vs. DHCP In-reply-to: Your message of "Fri, 07 Feb 2003 09:40:12 PST." <89680B404BA1DD419E6D93B28B41899BE9FBBF@01mail.nomadix.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 17:19:20 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "BSingh" == BSingh writes: BSingh> - This particular debate of Modecfg vs. DHCP relates only to BSingh> remote access scenarios or does it extend to address management BSingh> for site-to-site VPNs. I would distinguish the 2 using the I'd like to restrict the scope to remote access. BSingh> - Is it also possible that in a site-to-site VPN the address BSingh> allocation is handled by only one of the private networks BSingh> (subnets). i.e.. DHCP is tunneled over to this network from all BSingh> other private networks and responses tunneled back? Is it a Certainly possible. No new technology needed, just deploy a DHCP relay agent on the remote subnet. It doesn't even need to know that there is a VPN. BSingh> - Typical IPsec implementations. Most of them are bump in the BSingh> stack (software ones).. Am I correct? Does it mean that IP No. Most non-Microsoft Windows ones have no choice but to be. Few dedicated gateway boxes are. Solaris, KAME (*BSD), OpenBSD, Microsoft, and Linux 2.5 IPsec are certainly built in. FreeS/WAN is ... strange. It is BITS on 2.0 kernels, kinda not on 2.2, and only so on 2.4 due to hysterical raisins. BSingh> routing is the only way to direct traffic into the right tunnels? BSingh> i.e. destination address based. Are their any implementations It may well be that some non-BITS can only deal with destination address issues, but I haven't seen any. Often, for BITS it is the case that the destination address trick only directs the traffic into the IPsec machinery, at which more complicated decisions can be made in accordance with RFC2401. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkQw5YqHRg3pndX9AQHRbAP/Z7gL4F/59Q4PJcYkwyRlmDQzWsntjUW9 e5wbpz/AHaeCgb4Srrl8qhDbTX94kpZ1aqGTgH58XqT09vCBOEJLA4vsjwbj5pyR PbhNZOINPpizEReyJi5K1OUa+05XaXlJhUITiQ+d1XZ/1X2zO2oCzWak0S5ryYL4 +BeeKl1pIwM= =QHtK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Feb 7 17:06:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1816ad02498; Fri, 7 Feb 2003 17:06:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17853 Fri, 7 Feb 2003 19:35:51 -0500 (EST) Message-Id: <200302080035.h180ZN1U011881@marajade.sandelman.ottawa.on.ca> To: Gregory Lebovitz cc: ipsec@lists.tislabs.com Subject: Re: dhcp/modecfg summary In-reply-to: Your message of "Thu, 06 Feb 2003 16:57:54 PST." <541402FFDC56DA499E7E13329ABFEA872CE57A@SARATOGA> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 19:35:23 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Gregory" == Gregory Lebovitz writes: Gregory> I would strongly vote against modefg2 encompassing all DHCP Gregory> options natively. I.E. we should not create additional modecfg2 Gregory> attributes to cover all the things that DHCP does. In fact we do Gregory> not need to, right? modecfg2 could be the delivery mechanism for Gregory> DHCP options from a DHCP service external to the responder. That's what I keep saying!!! Just take a DHCP payload, encapsulate it in an IKE phase 1 structure, and send it. That avoids reinventing all the DHCP stuff, but maintains all of the simplicity of modecfg. BITS can even, if they want, just take the DHCP payload out of the one that they would normally tunnel through a phase 2 SA. The IKE phase 1 is just being used as a DHCP relay. At the gateway end, it either becomes a real DHCP packet to a real DHCP server, or you implement it internally. Gregory> We cannot make the above work (Modecfg2 being the conduit for Gregory> initial DHCP) with the attributes currently listed in Gregory> ikev2-04. We need two more things: the client needs to send Gregory> identity for the DHCP server, and we need to explicitly define Gregory> the DHCP relay from the responder to DHCP server. Then we can Gregory> use existing modecfg2 responses to communicate the IP, DNS, Gregory> WINS. Yes. Gregory> Doesn't that give us the best of both worlds? We get to keep the Gregory> ModeCFG formats that most of us already have. And the Yes. I would be willing to help write this up. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRQyYqHRg3pndX9AQHLugQA3x2w9en3wJIRPIyc8Lac1Yu6BPJfj5R0 KoFD4PHb16ISOqrkpe99zCqKEMsOOtkkLOKW2AGMMxF4rSX6Yl22oHTfX+E5U9zl djjyBN44N4Lj0aJLP6L/3BsYB2SqJBCoVbuoPhsfpKse1qQb4/OUB6z6UkDuyngo VCb61Z5BKU0= =lbUQ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Feb 7 17:51:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h181p4d03635; Fri, 7 Feb 2003 17:51:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17965 Fri, 7 Feb 2003 20:20:07 -0500 (EST) Message-Id: <200302080122.h181MUa8013451@marajade.sandelman.ottawa.on.ca> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: dhcp/modecfg summary In-reply-to: Your message of "Thu, 06 Feb 2003 09:20:18 PST." <3E429952.26EF2762@bstormnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 20:22:29 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> - some folks seem to imply that remote access entails only a pc Scott> connected to the target network over the internet; in fact, many Scott> telecommuter applications involve a personal sgw at the remote Scott> end, with a small network behind it - this should not be ignored Scott> in evaluating prospective mechanisms. This is small office VPN to me, not a road warrior. Unless you claim that it moves around, it is really a different situation than RW. If you claim that it is in scope, then so are all "VPN"s. Scott> - one stated aim of this wg in redesigning IKE has been to Scott> minimize impact on ike, to not add anything which is not I want to emphasis that while we want to minimize impact on ike, we are changing that piece. We want *ZERO* impact on RFC2401 if possible. We may add (i.e. AES being a MUST) to 2401bis, but I think that IKEv2 should assume that IPsec is implemented in some piece of silicon and can't be changed. Scott> required. If we stick to this position, this seems to imply that Scott> dhcp support will be required regardless (via dhcp inform and Scott> relay), unless we actually intend to expand modecfg2 to encompass I agree. To me, the only question is: DHCP over IPsec vs DHCP over IKE. DHCP over IKE basically looks just like modecfg. Thank you very much for the summary. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRb1IqHRg3pndX9AQE4ngP9HiXgkhtrT930DSuLWYVAXpUVTLsgEv3A Ec5jlFtONC7xbFToVqVPMtLSuaxDJ91KE/ntA7q9X3T48c+lUCNxSoAzeSKnGW9h MrSVNARAhGVqXtziTqAKNO6Ni0NQbHg595Xp5CyjZVzFYJFCclMjt9in7GVt4/Hz Sc7cWsTdVl8= =Q82N -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Feb 7 17:51:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h181p6d03645; Fri, 7 Feb 2003 17:51:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17980 Fri, 7 Feb 2003 20:25:08 -0500 (EST) Message-Id: <200302080124.h181OjCl013525@marajade.sandelman.ottawa.on.ca> To: Michael Choung Shieh cc: ipsec@lists.tislabs.com Subject: Re: dhcp/modecfg summary In-reply-to: Your message of "Thu, 06 Feb 2003 11:11:36 PST." <82CC1E573B94A648B87027C9419E2C055A6B62@losgatos> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 20:24:44 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael Choung Shieh writes: Michael> I would say the address allocation for a group of PC behind the Michael> peer gateway is out of scope of this discussion. It should be Michael> done AFTER IKE is done, not within IKE. Yes, I agree. It is a trivial deployment of a DHCP relay. Maybe the inner IP for the DHCP relay that is co-located on the IPsec gateway has to be allocated somehow, and that is in scope. However, it is the identical problem to the laptop on the road case. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRcW4qHRg3pndX9AQGq/QP/b1HKsyn8I9NuZXxuBCcEcIlM7Cf5LNpI enEOdgRcFAPlMNsnMstypNo3rbqDkaJ4v3ETHSPRtt4jcJ+b7bA/rBSp9d865AQM t1aLhvSaw5wyG6RDorQ32FPN4ASeGFjtKnSyGl0LQ+DA8XUBevGFtxEmSSiaOqzq GEXQr/e/LI4= =1Mdy -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Feb 7 18:29:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h182TGd04964; Fri, 7 Feb 2003 18:29:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18077 Fri, 7 Feb 2003 20:59:26 -0500 (EST) Message-ID: <3E4464BC.16D417C1@airespace.com> Date: Fri, 07 Feb 2003 18:00:28 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: dhcp/modecfg summary References: <200302080122.h181MUa8013451@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2003 02:01:59.0533 (UTC) FILETIME=[10A5D9D0:01C2CF16] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Scott" == Scott G Kelly writes: > Scott> - some folks seem to imply that remote access entails only a pc > Scott> connected to the target network over the internet; in fact, many > Scott> telecommuter applications involve a personal sgw at the remote > Scott> end, with a small network behind it - this should not be ignored > Scott> in evaluating prospective mechanisms. > > This is small office VPN to me, not a road warrior. > Unless you claim that it moves around, it is really a different situation > than RW. If you claim that it is in scope, then so are all "VPN"s. I agree that the line is sometimes a little fuzzy, but what differentiates these scenarios is that the IP address of the remote user's personal sgw is not fixed, and so it cannot be preconfigured on the headend. In some cases, the small network behind gw consists of a single system: +-------+ +------------++ | user |---|personal sgw||=[internet]== +-------+ +------------++ The fact that the ipsec implementation is BITW instead of a BITS does not invalidate this as a remote access scenario. It can be implemented in such a manner as to be indistinguishable from a software implementation from the other end of the connection. I've personally worked on an implementation where the remote sgw does a ULA exchange with the user (similar to xauth) through the tunnel. This *is* a remote access scenario. Scott > > Scott> - one stated aim of this wg in redesigning IKE has been to > Scott> minimize impact on ike, to not add anything which is not > > I want to emphasis that while we want to minimize impact on ike, we are > changing that piece. We want *ZERO* impact on RFC2401 if possible. We may add > (i.e. AES being a MUST) to 2401bis, but I think that IKEv2 should assume that > IPsec is implemented in some piece of silicon and can't be changed. > > Scott> required. If we stick to this position, this seems to imply that > Scott> dhcp support will be required regardless (via dhcp inform and > Scott> relay), unless we actually intend to expand modecfg2 to encompass > > I agree. > > To me, the only question is: DHCP over IPsec vs DHCP over IKE. > DHCP over IKE basically looks just like modecfg. > > Thank you very much for the summary. > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPkRb1IqHRg3pndX9AQE4ngP9HiXgkhtrT930DSuLWYVAXpUVTLsgEv3A > Ec5jlFtONC7xbFToVqVPMtLSuaxDJ91KE/ntA7q9X3T48c+lUCNxSoAzeSKnGW9h > MrSVNARAhGVqXtziTqAKNO6Ni0NQbHg595Xp5CyjZVzFYJFCclMjt9in7GVt4/Hz > Sc7cWsTdVl8= > =Q82N > -----END PGP SIGNATURE----- -- ------------------------------------- BlackStorm Networks is now airespace ------------------------------------- From owner-ipsec@lists.tislabs.com Fri Feb 7 20:01:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1841Id06804; Fri, 7 Feb 2003 20:01:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18350 Fri, 7 Feb 2003 22:34:08 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKEV2: Issue #3: DHCP vs. Configuration Payload From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 07 Feb 2003 22:36:40 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This issue has raised perhaps the most comment on the IPSEC mailing list. Most of the arguments against the Configuration payload are that it does not support a rich enough feature set. Some of the features which it does not support include: * Support for the responder to provide a subnet to the initiator, and not just a single address. Supporters of a DHCP 3456-style exchange point to the case where a VPN might be used to provision a small remote office requiring multiple IP addresses. Supporters of the Configuration payload scheme would argue that in such as case, the addresses for a remote subnet connected via a VPN would either be likely statically, not dynamically configured, or that such information is IP Security Policy information that should not be stored in ones DHCP server, but provided via some other service. Supporters of the Configuration payload would also argue that in the vast majority of cases, such as the scenario of the road warrior with a laptop needing VPN access to connect to his or her corporate intranet, only a single address is needed, and a Configuration payload-style scheme is working very well and widely deployed today. * Support for end-to-end authentication to the DHCP server. As used to today, the Configuration payload requires either that the DHCP server provide allocation of addresses out of its own address pool, or that it contact a DHCP server (on the inside of the firewall), using either no security, or via some kind of proxy authentication based on the identity of the IPSEC gateway, and not the requesting client. If in the future, support for end-to-end authentication of address allocation is required, the a RFC-3456 based solution would be preferable. * Support for forcible reassignment of IP address. DHCP allows IP address leases to be arbitrarily and without warning yanked from underneath the client. This is considered rude and will cause client applications to break, but the DHCP server has this power. If the configuration payload method is used to hand out an address, this can not be easily achieved. The IPSEC gateway can send a DELETE SA payload, which will force the client to stop using a particular address, but there is no good way to force the IPSEC client to stop using one address and start using another address. It can be argued, however, that most VPN client applications do not require this functionality. For some applications, it is clear that the Configuration Payload is sufficient; the large deployed base of implementations using modecfg today is testimony to this. The question, however, is whether or not it will continue to be sufficient for future applications. We note that the Configuration payload is substantially simpler than modecfg in ikev1. In particular, there is no need for a "Phase 1.5"; the Configuration payload is sent as part of messages 3 and 4. Furthermore, it is legitimate for the responder to respond with an empty CFG_REPLY message, indicating that it does not support (or is not configured) to hand out IP addresses. Hence, we suggest that as a path forward, that the Configuration payload be left in ikev2-04.txt, and that people who believe that a richer feature set is necessary should be encouraged to update RFC 3456 for use with IKEv2 as an alternative mechanism. Since an implementation is allowed to respond with an empty CFG_REPLY packet, this should not prove to be an onerous implementation burden for those who are determined to only support DHCP 3456-style configuration. While this could potentially cause interoperability problems, the fact that most deployed implementations already support modecfg suggests that for the simple (common?) case where only a single IP address needs to be returned by the IPSEC gateway, it is extremely likely that most VPN-style implementations will support the Configuration payload. If we choose this path, the question of which working group should pick up the task of updating to RFC 3456 for use with IKEv2, must ultimately be answered by the Security Area Directors. However, we suggest that since RFC 3456 was worked on by the ipsra working group, and presumably the advocates and experts of this approach are in the ipsra wg, that they be given the responsibility of authoring the revision to RFC 3456. Barbara Fraser Ted Ts'o IPSEC working group chairs From owner-ipsec@lists.tislabs.com Fri Feb 7 20:01:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1841Od06820; Fri, 7 Feb 2003 20:01:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18329 Fri, 7 Feb 2003 22:31:08 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKEv2: Remaining Issues and Process From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 07 Feb 2003 22:33:24 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message, and the following four messages to follow are an attempt by the working group chairs to summarize the current state of the recently identified open issues in the IPSEC working group, and outline a path towards coming to closure on them. These issues are: 1. Secure Legacy Authentication 2. Cipher suites 3. DHCP vs. Configuration Payload 4. Revised Identity In this message, we would also like to address the process of determining consensus. According to RFC 2418, it is the working group chairs which have the duty and responsibility of determining when rough consensus has been reached. In some cases, this can be very easy. In others, making this determination is less so. Within the IETF, consensus is not just about number of people who express support or opposition to a proposal (to quote Dave Clark, "IETF rejects kings, presidents, and voting"). As a result, determining consensus requires human judgment, which is one of the reasons why the IETF has a carefully thought-through appeals process. As working group chairs, Barbara and Ted believe that the complexity and potential contentiousness of different issues may require different levels of explicitly expressed consensus on the mailing list. At one extreme, a spelling correction may not require much more than a note to document editor, and his agreement that yup, that's a spelling error. At the other extreme, suppose there is a proposal for a radical change to an already existing protocol, where deployed implementations already exist and where there is an expectation that a minor software upgrade is all that is necessary to deploy an implementation of the revised protocol. In that case, more explicit expressions of support may be required in order to determine that there is consensus for the change. As working group chairs, Barbara and Ted would prefer that our task of determining consensus be an easy decision, and not a hard one. This is why we have called upon as many people as possible, especially people who are responsible for implementing these protocols, to make their opinions on the IPSEC mailing list --- preferably backed up with technical explanations justifying their preferences. In the absence of a clear expression of support, we must note that the working group did choose IKEv2 over JFK, presumably because of a preference to conserve of the general architecture and structure of the protocol and its implementations. Hence, issues which may, in the judgment of the chairs, cause radical changes to how these protocols and the policies surrounding them are managed and administered will require a higher bar in order to prove consensus. We realize that some people may not agree with this standard, but we believe it is consistent with the practices of the IETF and with the preferences of the working group to avoid making fundamental changes unless they are clearly necessary. Ultimately, if there is strong disagreement, settling this issue may require utilization of the IETF appeals process. Happily, however, this can be avoided if as many people as possible express their clear preferences, so that the determination of consensus is made with ease and without controversy. For this reason, Barbara and Ted continue to strongly encourage all IPSEC working group members to make their opinions regarding the following issues known to the ipsec mailing list. In order to meet the challenge set by the Security Area Directors of finishing working group last call by February 15th, we intend to give Charlie Kaufman editing directions on Tuesday, February 11th. Hence, we encourage people to respond to these issues by close of business on Monday, February 10th. Obviously, minor issues can still be raised and fixed during the last call period, but we need to set a stake in a ground and make the major fundamental decisions in the next couple of days. Barbara Fraser Ted Ts'o IPSEC working group chairs From owner-ipsec@lists.tislabs.com Fri Feb 7 20:01:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1841Td06842; Fri, 7 Feb 2003 20:01:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18338 Fri, 7 Feb 2003 22:32:07 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKEV2: Issue #1: Legacy Authentication From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 07 Feb 2003 22:34:59 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been no objection to the proposal sent by Ted on January 30th that the mechanism of the secure legacy authentication based on the message sent by Derrell Piper on January 23rd, with some modifications agreed to by Charlie and Hugo to address some certificational weakness to the underlying cryptographic exchange. One remaining open point, which was raised by Hugo, is whether or not the identity of the initiator should be included in message 3 or not. If it is included there, then an active attacker who pretends to be the gateway can learn the claimed identity of the initiator. If it not included, however, then for some (most?) legacy authentication systems, an extra round-trip will be necessary so that the responder can send its certificate to the initiator and prove its identity before initiator sends it identity down the D-H tunnel. As Charlie observed, in the "normal" (non-legacy) IKE exchange, we have already decided that when trading off between exposing the identity of the initiator to an active attack, and exposing the identity of the responder to an active attack, it was more important to protect the identity of responder. The reasoning behind this is two-fold. First of all, IKE is a peer-to-peer protocol where either side can initiate, and secondly, an active attack against the responder to determine its identity merely required initiating a connection to it ("the polling attack"), whereas an active attack against the initiator required impersonating the responder's IP address, which is presumably more difficult. (Please see Radia Perlman's message of November 26, 2002 for a more detailed explanation of this reasoning.) In the case of legacy authentication, which tends to decidedly assymetric, it has been argued that perhaps it is worthwhile to protect the identity of the initiator. Unfortunately, making IDi optional in message three significantly complicates the protocol. One way of simplifying this would be to require that in the case of legacy authentication, that IDi must always be omitted in message 3, and that an extra round trip is added where IDi is sent message 5, and the EAP exchange does not begin until message 6. (This avoids needing to specify on a per authentication mechanism whether or not the IDi needs to be sent --- especially since in nearly all cases it will be required anyway.) In the recent round of discussion, no one besides Hugo has expressed a desire for providing protection of the initiator's identity against active attacks in the case of legacy authentication. Therefore, in the absence of such support, the current language in ikev2-04, which requires IDi in message 3, shall stand. If there are people who believe that this should be made optional (trading off additional complexity plus the extra round trip at setup time), please make your preferences known. Barbara Fraser Ted Ts'o IPSEC working group chairs From owner-ipsec@lists.tislabs.com Fri Feb 7 20:02:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1842Nd06869; Fri, 7 Feb 2003 20:02:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18344 Fri, 7 Feb 2003 22:33:06 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKEV2: Issue #2: Cipher suites From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 07 Feb 2003 22:35:27 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There seems general consensus over the cipher suites proposed by Paul Hoffman. However, not fully closed is the question of which ciphers ought to be mandatory, and which merely optional. The working group chairs note that this answer to these issue is very largely dependent on the application for which IPSEC is used, and a belief for when IKEv2 is likely to be available in the marketplace. People who believe that IKEv2 will be deployed rapidly, and perhaps requiring only software upgrades to existing hardware, have expressed the desire to avoid requiring AES CBC or AES counter mode, because many existing hardware accelerators do not support AES or counter mode. On the other hand, if IKEv2 does not reach maturity quickly, the lack of a required AES cipher may very well look very silly. It is also the case that IPSEC as applied to for VPN's will have very radically different cipher requirements than those already expressed for use by iSCSI. For this reason, one potential solution (originally suggested by Steve Bellovin to the working group chairs) towards achieving closure on this issue would be to separate out into a separate document --- or more likely, documents --- the specifications of which ciphers are mandatory and which are merely optional. Since which ciphers ought to be mandatory will likely change more frequently than the base document itself, combined with the need for different profiles for different applications, we propose that the IKEv2 document remain silent about which ciphers are required, and that separate documents, for VPN and iSCSI applications, be drafted that contain these requirements. Barbara Fraser Ted Ts'o IPSEC working group chairs From owner-ipsec@lists.tislabs.com Fri Feb 7 20:02:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1842gd06882; Fri, 7 Feb 2003 20:02:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18380 Fri, 7 Feb 2003 22:37:10 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKEV2: Issue #4 Revised Identity From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 07 Feb 2003 22:39:34 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This item has not received as much discussion as the working group chairs have hoped. In the past week, Paul Hoffman has sent a message questioning the process by which the working group chairs would attempt to determine the consensus position of the working group. Our position about this the process issue has been addressed in an earlier message. As far as technical discussion of this proposal, Cheryl Madson and Scott Kelley both agreed that from a requirements standpoint, the behavior under-specification of certificate handling in IKEv1 needs to be avoided. Francis Dupont noted that either revised-identity draft or sections of the draft-ietf-ipsec-pki-profile I-D would serve to fully define certificate handling. This point was echoed by Michael Choung Sheih, who pointed out that the pki-profile document would address these issues. Derrell Piper agreed, and also expressed concerns about how "the management paradigm for many vendors is tied to the existing IKE identity types, so wholesale revision on this area might well represent a serious headache for many vendors". He was also concerned that implementing revised-identity might force vendors to "start from scratch" at the next IKE bake-off. He contrasted this with the impact of the other IKEv2 protocol changes, which are largely transparent (aside from the need to delete some options) to existing management software, end-user documentation, and regression testing. Gregory Lebovitz has spoken up in favor of revised identities, agreeing with the central premise of the revised-identity I-D that by using the certificate itself as the identity, it eliminates a number of interoperability problems which original IKE implementations suffered at the bakeoffs. (This issues have largely been settled at this point, although to quote Cheryl Madson, "the WG has been extremely apathetic about any attempts to clarify things", by which presumably she is referring to the pki-profile I-D, and perhaps earlier attempts to specify certificate handling.) Gregory also argued that most deployed uses of IPSEC are using shared secrets, and are not certificates, and that that therefore this is an opportunity to simplify how certificates and identity are handled. While it is certainly a true statement that IKEv2 represents an opportunity to change how certificates are handled, the deployment status of certificate-based IPSEC clients/servers seems to be mostly irrelevant to the question at hand, since nearly all or most IPSEC implementations support certificates. Gregory's observation does imply, however, that the number of customers/administrators that might require retraining is small; however, it does not change the work required of IPSEC implementors to make (perhaps significant) changes to the implementation, documentation, and training to support the revised identities. The choice between the working group, then is between using language taken from pki-profile-01 to make explicit when certificate payloads are sent, or choosing the revised-identity proposal. More comments about the tradeoffs inherent between these two choices are hereby requested. Barbara Fraser Ted Ts'o IPSEC working group chairs From owner-ipsec@lists.tislabs.com Fri Feb 7 21:14:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h185Ehd08406; Fri, 7 Feb 2003 21:14:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18686 Fri, 7 Feb 2003 23:45:12 -0500 (EST) Message-Id: <200302080448.h184mBiW020531@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload In-reply-to: Your message of "Fri, 07 Feb 2003 22:36:40 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 23:48:10 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> * Support for forcible reassignment of IP address. DHCP allows Theodore> IP address leases to be arbitrarily and without warning yanked Theodore> from underneath the client. This is considered rude and will Theodore> cause client applications to break, but the DHCP server has Theodore> this power. If the configuration payload method is used to I do not think that this isn't quite correct. It can refuse to renew a lease. As such, the phase 2 lifetime should be bounded by the DHCP lease time. The IPv6/DNS folks are currently discussing whether DHCPv6 or another mechanism should be used for information discovery. I believe that the IAB may express a clear opinion at some point. I suggest that IKE has less reason than IPv6 to diverge from DHCP. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkSMCYqHRg3pndX9AQHhlQP+Me4YMQW/tjHOY3g2aOuY6xdlcyBiQt5f C+IhkdK4zJuGohl0yn33hU/o0E7mSSG4k3gCK6Anmfna/sxujrroryoe4wlZVpYl 7/eKuOZ0PGOs15sgetGK1/cNGWvTuJ/4zYpGY7QHurztkQ5Vlwy/dM1iXNku9Cny jmCu5b7/e4E= =seJU -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Feb 8 10:56:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h18Iuvd08684; Sat, 8 Feb 2003 10:56:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20107 Sat, 8 Feb 2003 13:19:45 -0500 (EST) Date: Sat, 8 Feb 2003 10:22:20 -0800 Subject: Re: IKEV2: Issue #1: Legacy Authentication Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipsec@lists.tislabs.com To: "Theodore Ts'o" From: Derrell Piper In-Reply-To: Message-Id: <4332DD91-3B92-11D7-BF56-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For the record then, I would prefer that we protect against this but it does seem that this is the minority view. Derrell On Friday, February 7, 2003, at 07:34 PM, Theodore Ts'o wrote: > In the recent round of discussion, no one besides Hugo has expressed a > desire for providing protection of the initiator's identity against > active attacks in the case of legacy authentication. Therefore, in > the absence of such support, the current language in ikev2-04, which > requires IDi in message 3, shall stand. If there are people who > believe that this should be made optional (trading off additional > complexity plus the extra round trip at setup time), please make your > preferences known. From owner-ipsec@lists.tislabs.com Sat Feb 8 18:10:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h192AFd16080; Sat, 8 Feb 2003 18:10:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20648 Sat, 8 Feb 2003 20:30:08 -0500 (EST) To: Charlie_Kaufman@notesdev.ibm.com Cc: Derrell Piper , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: Secure legacy authentication for IKEv2 References: Date: 08 Feb 2003 20:17:03 -0500 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for the delayed reply.... Charlie_Kaufman@notesdev.ibm.com writes: > > This question is really directed at folks who have implementation > > experience with EAP. Is it the case that existing EAP implementations > > generally do not require the optional identity exchange when they have > > an identity available from some other out-of-band source? I was hoping > > some EAP folks would speak up here... Or do you sometimes masquerade > > in an EAP hat? :-) > > I checked my hat collection and none say EAP. I agree it would be nice to > get feedback. Anyone??? I do not claim to be an EAP expert, but I have been working on a Kerberos EAP method (so I do have some EAP experience printed on my hat). The answer is yes, the Identity is not required. If the server can somehow deduce the client's identity then it can initiate the EAP Challenge directly to the client without the Identity Request. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Sun Feb 9 08:48:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19GmNd15412; Sun, 9 Feb 2003 08:48:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21645 Sun, 9 Feb 2003 10:50:25 -0500 (EST) Message-Id: <200302091550.h19Fosof082727@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: BSingh@Nomadix.com cc: ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP In-reply-to: Your message of Thu, 06 Feb 2003 17:20:16 PST. <89680B404BA1DD419E6D93B28B41899BE9FB93@01mail.nomadix.com> Date: Sun, 09 Feb 2003 16:50:54 +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: I have a few clarifications regarding usage of IPsec for VPNs. I have been even going through the thread of Modecfg vs. DHCP and seem a little confused regarding the functionality. - This particular debate of Modecfg vs. DHCP relates only to remote access scenarios or does it extend to address management for site-to-site VPNs. I would distinguish the 2 using the following definitions- One tunnel per machine and address to be given out (whichever way - modecfg or DHCP) at tunnel setup time would be Remote Access. Site-to-site would be that tunnel is setup apriori between 2 gateways and both sides would be different private subnets. Users in site-to-site VPNs get addresses typically from their own subnet's DHCP servers. Please correct me if i am wrong.. => this is less and less true because someone can use a home-to-office VPN from a or a few home networks. This is not very common with IPv4 (not enough addresses -> NATs :-) but should be very common with IPv6 where a home user can get between a /64 and a /48. - Is it also possible that in a site-to-site VPN the address allocation is handled by only one of the private networks (subnets). ie. DHCP is tunneled over to this network from all other private networks and responses tunneled back? Is it a typical setup? Is the discussion of modecfg vs. DHCP relevant in this case? I assume that their might be some routing issues in this setup for tunneling the responses back to the DHCP requesters through the right tunnels. Maybe some state maintenance at the gateways. => for IPv6 a prefix allocation/assignment should be used (DHPCv6-lite) for instance. - Typical IPsec implementations. Most of them are bump in the stack (software ones).. Am I correct? Does it mean that IP routing is the only way to direct traffic into the right tunnels? i.e destination address based. Are their any implementations that do not follow this paradigm. Any pointers would be helpful. => I disagree: at the initiator side the only needed thing is a SPD with some entries to disable infinite recursive protection and an entry for everything else. The SPD is used before routing so the routes are the same in general with and without the VPN. At the responder/SG side, the only problem is the reverse routing. Proxy ARP/ND works well for VPNs to hosts but for VPNs to subnetworks only reverse route injection does the job. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Feb 9 08:59:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19Gxvd19570; Sun, 9 Feb 2003 08:59:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21672 Sun, 9 Feb 2003 11:20:47 -0500 (EST) Message-Id: <200302091622.h19GMFof083059@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: IKEv2: Remaining Issues and Process In-reply-to: Your message of Fri, 07 Feb 2003 22:33:24 EST. Date: Sun, 09 Feb 2003 17:22:15 +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: Obviously, minor issues can still be raised and fixed during the last call period, but we need to set a stake in a ground and make the major fundamental decisions in the next couple of days. => I don't know if the mobility & co support is a minor issue or not, but as the NAT traversal is in the WG charter and is currently half broken, I believe we should improve/fix all the issues relative to peer address management before the WG last call. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Feb 9 09:35:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19HZ8d22050; Sun, 9 Feb 2003 09:35:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21695 Sun, 9 Feb 2003 11:56:30 -0500 (EST) Message-Id: <5.2.0.9.2.20030209115530.03539398@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Feb 2003 11:58:30 -0500 To: "Theodore Ts'o" , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: IKEV2: Issue #2: Cipher suites 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: The S/MIME WG has separated algorithm requirements from the base protocol too. This was done so that the algorithms could be updated without "opening up" the base protocol document. This is more important when the base protocol becomes a Draft Standard or a Full Standard. I belive that the algorithms proposed by Paul are the right ones for today. One think I really like about the rationale is that it warns marketing folks and product planners which algorithms are likely to become mandatory to implement in a future update. Russ At 10:35 PM 2/7/2003 -0500, Theodore Ts'o wrote: >There seems general consensus over the cipher suites proposed by Paul >Hoffman. However, not fully closed is the question of which ciphers >ought to be mandatory, and which merely optional. > >The working group chairs note that this answer to these issue is very >largely dependent on the application for which IPSEC is used, and a >belief for when IKEv2 is likely to be available in the marketplace. >People who believe that IKEv2 will be deployed rapidly, and perhaps >requiring only software upgrades to existing hardware, have expressed >the desire to avoid requiring AES CBC or AES counter mode, because >many existing hardware accelerators do not support AES or counter >mode. On the other hand, if IKEv2 does not reach maturity quickly, >the lack of a required AES cipher may very well look very silly. > >It is also the case that IPSEC as applied to for VPN's will have very >radically different cipher requirements than those already expressed >for use by iSCSI. > >For this reason, one potential solution (originally suggested by >Steve Bellovin to the working group chairs) towards achieving closure >on this issue would be to separate out into a separate document --- or >more likely, documents --- the specifications of which ciphers are >mandatory and which are merely optional. Since which ciphers ought to >be mandatory will likely change more frequently than the base document >itself, combined with the need for different profiles for different >applications, we propose that the IKEv2 document remain silent about >which ciphers are required, and that separate documents, for VPN and >iSCSI applications, be drafted that contain these requirements. > > Barbara Fraser > Ted Ts'o > IPSEC working group chairs From owner-ipsec@lists.tislabs.com Sun Feb 9 12:28:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19KSpd27078; Sun, 9 Feb 2003 12:28:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21977 Sun, 9 Feb 2003 14:55:32 -0500 (EST) Message-ID: <3E46B245.6DFCC693@airespace.com> Date: Sun, 09 Feb 2003 11:55:49 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: BSingh@Nomadix.com, ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <200302091550.h19Fosof082727@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2003 19:57:27.0173 (UTC) FILETIME=[78881350:01C2D075] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > - Typical IPsec implementations. Most of them are bump in the stack > (software ones).. Am I correct? Does it mean that IP routing is the only way > to direct traffic into the right tunnels? i.e destination address based. Are > their any implementations that do not follow this paradigm. Any pointers > would be helpful. > > => I disagree: at the initiator side the only needed thing is a SPD > with some entries to disable infinite recursive protection and an entry > for everything else. The SPD is used before routing so the routes are > the same in general with and without the VPN. > At the responder/SG side, the only problem is the reverse routing. > Proxy ARP/ND works well for VPNs to hosts but for VPNs to subnetworks > only reverse route injection does the job. > I'm not sure I fully understand what you just said, but one of the things I think I just read is that routing happens after SPD use. I think this is highly implementation specific. I've created an implementation which supports per-interface policies. In this implementation, the SPD for the ingress interface is consulted upon receiving a packet, and the appropriate policy is applied. After this step, a routing lookup is performed to determine the exit interface, and then the SPD associated with that interface is consulted. This is a powerful model with interesting properties. Now, you could say that the SPD is used before routing, as the one on the ingress interface certainly is, but what about the one on the egress interface? As for routes being the same with or without the VPN, this is typically true for exiting packets, although not necessarily in cases where an encapsulation occurs due to policy related operations. Scott Scott From owner-ipsec@lists.tislabs.com Mon Feb 10 02:25:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AAPhd16049; Mon, 10 Feb 2003 02:25:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23137 Mon, 10 Feb 2003 04:46:19 -0500 (EST) Message-Id: <200302100947.h1A9lYof085642@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Scott G. Kelly" cc: BSingh@Nomadix.com, ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP In-reply-to: Your message of Sun, 09 Feb 2003 11:55:49 PST. <3E46B245.6DFCC693@airespace.com> Date: Mon, 10 Feb 2003 10:47:34 +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: I'm not sure I fully understand what you just said, but one of the things I think I just read is that routing happens after SPD use. => yes, policies are applied before the real routing happens. Often there is a route lookup at the entry of IP output routine but real routing can be done only at the end because of all the special cases (multicast, routing headers, policies, etc). I think this is highly implementation specific. I've created an implementation which supports per-interface policies. In this implementation, the SPD for the ingress interface is consulted upon receiving a packet, and the appropriate policy is applied. => I considered only the egress processing (routing in the ingress processing is marginal). After this step, a routing lookup is performed to determine the exit interface, and then the SPD associated with that interface is consulted. This is a powerful model with interesting properties. => this is the standard way but this routing lookup doesn't do the real routing, i.e., another route can be used to send the packet. Now, you could say that the SPD is used before routing, as the one on the ingress interface certainly is, but what about the one on the egress interface? As for routes being the same with or without the VPN, this is typically true for exiting packets, although not necessarily in cases where an encapsulation occurs due to policy related operations. => if there is an encapsulation, the route has to be reevaluated so in this way the SPD is used before final routing. Especially in common implementations the IPsec decision is from a SPD match, not a route table one. But this is really implementation dependent and RFC 2401 is not the clearest document we can find (:-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Feb 10 08:37:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AGbJd05106; Mon, 10 Feb 2003 08:37:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23745 Mon, 10 Feb 2003 11:00:58 -0500 (EST) Message-ID: <3E47CD3F.CBA98160@NORTELNETWORKS.COM> Date: Mon, 10 Feb 2003 11:03:11 -0500 From: "Marcus Leech" Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #1: Legacy Authentication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > > In the recent round of discussion, no one besides Hugo has expressed a > desire for providing protection of the initiator's identity against > active attacks in the case of legacy authentication. Therefore, in > the absence of such support, the current language in ikev2-04, which > requires IDi in message 3, shall stand. If there are people who > believe that this should be made optional (trading off additional > complexity plus the extra round trip at setup time), please make your > preferences known. > I'm all for reducing complexity in the protocol, even if it means that there's an identity-disclosing active attack possible. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Mon Feb 10 11:59:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AJxld16269; Mon, 10 Feb 2003 11:59:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25198 Mon, 10 Feb 2003 14:10:52 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.2.0.9.2.20030209115530.03539398@mail.binhost.com> References: <5.2.0.9.2.20030209115530.03539398@mail.binhost.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: Mon, 10 Feb 2003 11:13:50 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKEV2: Issue #2: Cipher suites Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Splitting out the list of ciphersuites and the list of which ones are MUSTs and SHOULDs would also bring us into line more with the IETF. The lists of MUSTs that the WG chairs have proposed do not follow the rules of RFC 2119, which is a normative reference in IKEv2. All the other MUSTs and SHOULDs in IKEv2 do follow the rules in RFC 2119, but these do not. It would be nice to have the main IKEv2 document actually conform to the IETF rules. Another reason to split out the algorithms is that this WG has done a lousy job of keeping its list for IKEv1 up-to-date. DES (not TripleDES) is still a MUST. TIGER is still a SHOULD. If we can't even fix obvious problems like that in a timely fashion for IKEv1, we should not expect to do so for IKEv2. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 10 12:08:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AK89d16485; Mon, 10 Feb 2003 12:08:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25437 Mon, 10 Feb 2003 14:38:16 -0500 (EST) To: Dan McDonald Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: Ciphersuites for IKEv2, revised References: <200301311750.h0VHoQDt014278@kebe.east.sun.com> Date: 10 Feb 2003 14:33:57 -0500 In-Reply-To: <200301311750.h0VHoQDt014278@kebe.east.sun.com> Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald writes: > Thanks for this most recent update. Yes, thank you for the update.. > I'm still not convinced of the goodness of suites in general, but if the WG > insists, I have to fall in with Michael that you should cordon off sections > for IKE, AH, and ESP. I, too, am not convinced of the goodness of suites _in the protocol_. I completely agree that suites should be defined in the user interface presented to the user, but on-the-wire I still believe that all the algorithms should be negotiated a-la-carte. I've been catching up on wg mail over the last few days, and this WG seems to continually flip-flop between suites and a-la-carte. I had _THOUGHT_ that we had concensus on: 1) the on-the-wire protocol would negotiate a-la-carte 2) the UI would present suites to the user What happened to this concensus that we had in December? As an implementor, it's significantly easier to design plug-and-play algorithms. I see no reason to constrain an implementation to some set of suites. I don't believe it will hurt interoperability to negotiate a-la-carte, and in fact I think it makes for a simpler specification to do so. But again, the user interface can lump these choices into named suites for the user to choose. I have no problem with creating a set of known, named suites for users. Can someone explain the benefit of forcing negotiation by suites? The only argument I've heard is hardware crypto -- but in that case it can just make a set of a-la-carte proposals that meet its capabilities. > Dan -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 10 15:45:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ANjcd22893; Mon, 10 Feb 2003 15:45:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27173 Mon, 10 Feb 2003 18:08:17 -0500 (EST) To: "Scott G. Kelly" Cc: Michael Richardson , ipsec@lists.tislabs.com, sommerfeld@east.sun.com From: Derek Atkins Subject: Re: Modefg considered harmful References: <200301311626.h0VGQfM5004172@marajade.sandelman.ottawa.on.ca> <3E3ABC2A.1DC28C04@bstormnetworks.com> Date: 10 Feb 2003 18:10:52 -0500 In-Reply-To: <3E3ABC2A.1DC28C04@bstormnetworks.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" writes: > Hi Michael, > > Michael Richardson wrote: > > > > The degenerate case is a client connecting to a security-gateway/firewall > > of a small organization. It should get the same inner-address as when it is > > plugged into the organization LAN. > > In my experience, this leads to routing issues that are most easily > resolved by ensuring that remote access client addresses are *never* > assigned internally. But that's not what I want.. I want my statically-assigned DHCP address regardless of whether I'm on the 100BaseT internal LAN, the 802.11 wireless lan, or connected via IPsec VPN. I don't want to enforce an architecture where this is no longer possible. I see no reason it SHOULDN'T be possible to allow this to work. DCHP will already assign me the same address on the wired or wireless interface. The only issue is getting that address via the IPsec gateway. > Scott -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 10 15:48:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ANmMd22953; Mon, 10 Feb 2003 15:48:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27274 Mon, 10 Feb 2003 18:20:28 -0500 (EST) To: Van Aken Dirk Cc: "'ddukes@cisco.com'" , Michael Richardson , ipsec@lists.tislabs.com, "Scott G. Kelly" From: Derek Atkins Subject: Re: Modefg considered harmful References: <421CB3B9B2D2F645B548D213C0A90E55090F15@TMM_EDGMSMSG01> Date: 10 Feb 2003 18:23:11 -0500 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F15@TMM_EDGMSMSG01> Message-ID: Lines: 102 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dirk, Unfortunately IPsec MUST know the IP Address that is assigned to the client. In particular, the IPsec GATEWAY must know what selectors to apply when creating the tunnel, and must know the address in an authenticated manner. If the gateway is not involved in the IP Address configuration, then it has to trust the client to act responsible. This may not be a reasonable choice: a) it opens you up to address-stealing attacks b) it opens you up to address-spoofing attacks Here's why. A client connects to a gateway but doesn't agree on an IP Address. The client then says "ok, I'm 1.2.3.4". The IPsec gateway has no way to know that this client is authorized to use 1.2.3.4 -- it's just trusting the client, which is bad. Think PPVPN! If my company and your company share a VPN node, I could gain access to your vpn this way. Address spoofing is much the same way -- if you leave the selectors open then even though I've got address 1.2.3.4, I could send a packet claiming to be from 1.2.3.5 into the network. The only way to fix this is for the IPsec gateway to be involved in the address assignment (even if it's just reading the DHCP responses). IPsec cannot be used in a vacuum. -derek Van Aken Dirk writes: > The IPSec engine must not sniff on DHCP packets. As said before, > implementing RFC3456 can IMHO happen almost completely outside the IKE and > IPSec code! More specific, a DHCP discover arriving via an IPSec tunnel has > a source address (0,0) and destination address (-1,-1). After passing > through the SPD, this packet must be delivered locally, that is, to the > internal IP host of the IPSec GW (see RFC1812-section 5.2.3). The local host > is configured with a DHCP relay that is listening on UDP port 67 (DHCP > server port). This DHCP relay can either forward the request to an internal > DHCP server or relay it to an external DHCP server. The only IPSec specific > item that the relay must take care of is that replies from the server must > end-up in the correct "DHCP-tunnel". This can be accomplished via the DHCP > Relay Information Option/sub-options. i.e. The DHCP relay must "tag" the > DHCP requests (e.g. with the Tunnel IP address, Tunnel port number) in the > direction towards the DHCP server and must "untag" the DHCP replies and use > this tag to look-up the correct tunnel in the direction towards the DHCP > client (see section 4.2 of RFC3456). > > So to conclude: > - I don't have to touch the IKE code > - I don't have to touch IPSec code > - I might have to change DHCP relay code but this technology is well > understood > - my IP parameter distribution method is in-line with the rest of the > network infrastucture and inherits an existing and rich feature set. > > > Best regards - Dirk > > > For your convenience excerpted the relevant section on local delivery of > RFC1812 - Requirements for IP Version 4 Routers. > > 5.2.3 Local Delivery Decision > > When a router receives an IP packet, it must decide whether the > packet is addressed to the router (and should be delivered locally) > or the packet is addressed to another system (and should be handled > by the forwarder). There is also a hybrid case, where certain IP > broadcasts and IP multicasts are both delivered locally and > forwarded. A router MUST determine which of the these three cases > applies using the following rules. > > > o An unexpired source route option is one whose pointer value does > not point past the last entry in the source route. If the packet > contains an unexpired source route option, the pointer in the > option is advanced until either the pointer does point past the > last address in the option or else the next address is not one of > the router's own addresses. In the latter (normal) case, the > packet is forwarded (and not delivered locally) regardless of the > rules below. > > o The packet is delivered locally and not considered for forwarding > in the following cases: > > - The packet's destination address exactly matches one of the > router's IP addresses, > > - The packet's destination address is a limited broadcast address > ({-1, -1}), or > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 10 16:04:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B04Ad23254; Mon, 10 Feb 2003 16:04:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27427 Mon, 10 Feb 2003 18:41:00 -0500 (EST) Message-ID: <3E483834.C4C0FE5E@airespace.com> Date: Mon, 10 Feb 2003 15:39:32 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: Michael Richardson , ipsec@lists.tislabs.com, sommerfeld@east.sun.com Subject: Re: Modefg considered harmful References: <200301311626.h0VGQfM5004172@marajade.sandelman.ottawa.on.ca> <3E3ABC2A.1DC28C04@bstormnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2003 23:41:14.0086 (UTC) FILETIME=[E6022860:01C2D15D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, Comments inline below... Derek Atkins wrote: > > "Scott G. Kelly" writes: > > > Hi Michael, > > > > Michael Richardson wrote: > > > > > > The degenerate case is a client connecting to a security-gateway/firewall > > > of a small organization. It should get the same inner-address as when it is > > > plugged into the organization LAN. > > > > In my experience, this leads to routing issues that are most easily > > resolved by ensuring that remote access client addresses are *never* > > assigned internally. > > But that's not what I want.. I want my statically-assigned DHCP > address regardless of whether I'm on the 100BaseT internal LAN, the > 802.11 wireless lan, or connected via IPsec VPN. I don't want to > enforce an architecture where this is no longer possible. Then you need to set up your routing infrastructure accordingly. I didn't mean to imply that this cannot be done. What I meant is that in most of the remote access vpn deployments I've seen, the routing infrastructure was not very amenable to this. > I see no reason it SHOULDN'T be possible to allow this to work. DCHP > will already assign me the same address on the wired or wireless > interface. The only issue is getting that address via the IPsec > gateway. Actually, the issue for any given system that wants to talk to yours is in determining the MAC address packets destined for you should be forwarded to. In complex topologies where the same IP can pop up behind router a, router b, or sometimes be directly connected, this can get to be ...interesting. The mobile IP guys have been dealing with this from day one. Again, I didn't mean to say that it can't be done - only that it can be problematic. It is *easier* if this can be avoided in remote access vpn scenarios, and avoiding it is not difficult. Scott From owner-ipsec@lists.tislabs.com Mon Feb 10 16:05:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B05id23290; Mon, 10 Feb 2003 16:05:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27455 Mon, 10 Feb 2003 18:43:03 -0500 (EST) Message-ID: <3E483959.5D2D8DF1@airespace.com> Date: Mon, 10 Feb 2003 15:44:25 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: BSingh@Nomadix.com CC: Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2003 23:46:07.0298 (UTC) FILETIME=[94C6C220:01C2D15E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk BSingh@Nomadix.com wrote: > But I guess this is not what RFC2401 says and it leaves it open for various > implementations to have different SPD methodology.. Can you update me on > what other ways SPD entries are looked up for tunnel selection.. I am more > interested in the source address or some source parameter being included as > the criteria for tunnel selection or an SPD interface that lets me make > policies based on the source of the packets.. Is it possible? If you can > guide me there I would really appreciate it.. I think RFC2401 is quite explicit about what selectors are used in SPD lookups. Based on this, the virtual interface approach suffers from (at least) two problems: first, routing lookups are most specific to least specific (i.e. "best match"), meaning the administrator may not be able to strictly control the ordering of SPD elements. Secondly, it does not support protocol and/or ports as selectors. Scott From owner-ipsec@lists.tislabs.com Mon Feb 10 16:08:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B08Rd23352; Mon, 10 Feb 2003 16:08:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27478 Mon, 10 Feb 2003 18:44:04 -0500 (EST) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> To: Francis.Dupont@enst-bretagne.fr, scott@airespace.com Cc: ipsec@lists.tislabs.com Date: Mon, 10 Feb 2003 15:16:54 -0800 Subject: RE: typical IPsec-based VPNs incl. modecfg vs. DHCP MIME-Version: 1.0 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for your responses.. I have another query regarding this. I have a question about the IPsec SPD.. I had worked a long time back on Linux freeswan.. What I do remember from that is that each tunnel on the outbound side was represented as a virtual interface like ipsec0. So the ipsec engine would insert routes in the routing tables on setup ( I wasn't doing IKE) for these entries leading to my question in the first place because I got the impression that IP routing is necessary and the most typical demultiplexing method to insert packets into different tunnels.. i.e somehow SPD policies map to a routing entry which would mean the destination address being the sole criterion for tunnel selection. But I guess this is not what RFC2401 says and it leaves it open for various implementations to have different SPD methodology.. Can you update me on what other ways SPD entries are looked up for tunnel selection.. I am more interested in the source address or some source parameter being included as the criteria for tunnel selection or an SPD interface that lets me make policies based on the source of the packets.. Is it possible? If you can guide me there I would really appreciate it.. Thanks -Bik From owner-ipsec@lists.tislabs.com Mon Feb 10 16:52:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B0q5d24709; Mon, 10 Feb 2003 16:52:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27927 Mon, 10 Feb 2003 19:23:31 -0500 (EST) To: "Scott G. Kelly" Cc: Michael Richardson , ipsec@lists.tislabs.com, sommerfeld@east.sun.com From: Derek Atkins Subject: Re: Modefg considered harmful References: <200301311626.h0VGQfM5004172@marajade.sandelman.ottawa.on.ca> <3E3ABC2A.1DC28C04@bstormnetworks.com> <3E483834.C4C0FE5E@airespace.com> Date: 10 Feb 2003 19:23:01 -0500 In-Reply-To: <3E483834.C4C0FE5E@airespace.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" writes: > > But that's not what I want.. I want my statically-assigned DHCP > > address regardless of whether I'm on the 100BaseT internal LAN, the > > 802.11 wireless lan, or connected via IPsec VPN. I don't want to > > enforce an architecture where this is no longer possible. > > Then you need to set up your routing infrastructure accordingly. I > didn't mean to imply that this cannot be done. What I meant is that in > most of the remote access vpn deployments I've seen, the routing > infrastructure was not very amenable to this. I just want to make sure that the IPsec configuration system can handle this. As it is, my network handles it just fine (mostly because it's one bridged network). If the IPsec Gateway can provide the same address and proxyarp, it all works. I just wanted to make sure that this architecture was not disallowed. > Again, I didn't mean to say that it can't be done - only that it can be > problematic. It is *easier* if this can be avoided in remote access vpn > scenarios, and avoiding it is not difficult. Ok, that was unclear. It SOUNDED like you said it couldn't be done. If it _can_ be done then I'm happy. > Scott -der -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 10 20:34:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B4Y2d29755; Mon, 10 Feb 2003 20:34:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28971 Mon, 10 Feb 2003 23:01:00 -0500 (EST) To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: Reply-To: EKR From: Eric Rescorla Date: 10 Feb 2003 19:05:47 -0800 In-Reply-To: Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't see how we can reasonably move forward with the revised identity proposal as is, for a number of reasons: (1) There's no way to use caching without having HTTP access. This is quite undesirable since these two issues are actually unrelated and it's reasonable to believe that there will be a significant number of agents which don't have HTTP access but can cache. Even if one believes that all agents have HTTP access, the need to do an HTTP fetch adds significant additional latency. What you actually want is for peer A to say "I have the following cert cached for you. Either send me an OK or send me a new cert." But there's no way to do that with this proposal. (2) It's underspecified. (a) The actual contents and encodings of TrustedRoot and IDAccepted payloads are not specified. (b) The actual data that's at the target of the URL is left unclear. What's the MIME type? What is the actual ASN.1 type of the data? (b) New error codes are invented but not actually assigned. (3) Removal of semantically meaningful IDs. There are a number of different ways in which it might be meaningful to name a peer (e.g. IP address, FQDN, etc.) This proposal reduces the names to whatever happens to appear in the certificate. Since certificates often have multiple name forms of different types, or worse yet, everything compressed into the CN, this proposal is going to make it very hard for a verifier to figure out what the peer's identity is. (4) It invents new mechanisms to do things that do things that are already done (confusingly) in IKEv1. The problem with IKEv1 certificate handling is largely that it's underspecified. Keeping essentially the same certificate handling in IKEv2 but clarifying the semantics allows us to tighten IKEv1 as well. This is a good thing since we are probably stuck with IKEv1 for a while. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Feb 10 21:43:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B5hjd01312; Mon, 10 Feb 2003 21:43:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29599 Tue, 11 Feb 2003 00:16:15 -0500 (EST) 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: Mon, 10 Feb 2003 21:19:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKEV2: Issue #4 Revised Identity Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:05 PM -0800 2/10/03, Eric Rescorla wrote: >(1) There's no way to use caching without having HTTP access. Sure you can. You can cache earlier receipt of a full cert in IKE messages. > This is quite undesirable since these two issues are > actually unrelated and it's reasonable to believe that > there will be a significant number of agents which don't > have HTTP access but can cache. See above. > Even if one believes that > all agents have HTTP access, the need to do an HTTP > fetch adds significant additional latency. Which is why it is not mandatory. Gateways that are not concerned about latency on the first hit use it, others don't. They can even change based on current latency times. > What you actually want is for peer A to say "I have the > following cert cached for you. Either send me an OK > or send me a new cert." But there's no way to do that > with this proposal. But that's a reasonable counter-proposal that gets to the same end: not having to send certs each time, and therefore avoid the failure in routers and firewalls that don't pass fragmented UDP. Without a hash-of-cert mechanism, implementations will continue to suffer this silent failure. >(2) It's underspecified. > > (a) The actual contents and encodings of TrustedRoot and IDAccepted > payloads are not specified. This is trivial to fix, and was supposed to be done if the WG showed more interest. > (b) The actual data that's at the target of the URL is left > unclear. What's the MIME type? What is the actual ASN.1 type > of the data? Not true; this has been fully specified in the PKIX and OpenPGP WGs for many years. > (b) New error codes are invented but not actually assigned. I don't understand this. >(3) Removal of semantically meaningful IDs. There are a number of > different ways in which it might be meaningful to name a > peer (e.g. IP address, FQDN, etc.) This proposal reduces > the names to whatever happens to appear in the certificate. Not true at all. It works exactly like IKEv1 works, except that you don't have the ID payload. If the receiver knows that Joe is identified by his IP address, regardless of what is in the certificate, the receiver uses that information. > Since certificates often have multiple name forms of > different types, or worse yet, everything compressed into > the CN, this proposal is going to make it very hard > for a verifier to figure out what the peer's identity is. To recap: IKEv1 implementers cannot decide what to do with the information in the ID payload when used with certificates. Does the receiver have to use it as the identifier? What if the ID payload contains something that isn't in the certificate? What if the ID payload matches something in the certificate but the receiver uses some other type of identification? There are almost as many answers to these questions as there are implementations. Different profiles have attempted to pick a single meaning, and each proposal has had a shower of complaints because it doesn't match with what many implementers are already doing while following the lack of information in IKEv1. I take it that you think this is just fine for IKEv2. Others, particularly implementers who have been hurt by the lack of interoperability, have said they disagree. >(4) It invents new mechanisms to do things that do things that > are already done (confusingly) in IKEv1. Fully agree. > The problem with > IKEv1 certificate handling is largely that it's underspecified. Right. > Keeping essentially the same certificate handling in IKEv2 > but clarifying the semantics allows us to tighten IKEv1 > as well. But this is not what the WG chairs have proposed. There is no proposal for clarifying the semantics in IKEv2 on the table. We are left with the same nothing as in IKEv1. Why would an implementer go to IKEv2 if the major user problems with IKEv1 are left the same? > This is a good thing since we are probably stuck with > IKEv1 for a while. Folks who have been badly hurt by the lack of interoperability might disagree with that assessment. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 10 23:36:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B7aLd12303; Mon, 10 Feb 2003 23:36:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00300 Tue, 11 Feb 2003 01:59:58 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: Reply-To: EKR From: Eric Rescorla Date: 10 Feb 2003 23:07:13 -0800 In-Reply-To: Message-ID: Lines: 101 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 7:05 PM -0800 2/10/03, Eric Rescorla wrote: > >(1) There's no way to use caching without having HTTP access. > > Sure you can. You can cache earlier receipt of a full cert in IKE messages. How do you tell the peer that you don't want to get the cert in the revised identity scheme? > > What you actually want is for peer A to say "I have the > > following cert cached for you. Either send me an OK > > or send me a new cert." But there's no way to do that > > with this proposal. > > But that's a reasonable counter-proposal that gets to the same end: > not having to send certs each time, and therefore avoid the failure in > routers and firewalls that don't pass fragmented UDP. Without a > hash-of-cert mechanism, implementations will continue to suffer this > silent failure. You need some kind of mechanism. It doesn't necessarily have to be hash-of-cert. Section 3.3.11.2 of draft-ietf-ipsec-pki-profile describes how to make this work with the current CERTREQ payload (using the DN). > >(2) It's underspecified. > > > > (a) The actual contents and encodings of TrustedRoot and IDAccepted > > payloads are not specified. > > This is trivial to fix, and was supposed to be done if the WG showed > more interest. It may or may not be trivial to fix. I generally prefer to see protocols fully specified before I draw that kind of conclusion. > > (b) The actual data that's at the target of the URL is left > > unclear. What's the MIME type? What is the actual ASN.1 type > > of the data? > > Not true; this has been fully specified in the PKIX and OpenPGP WGs > for many years. I don't recall such a mechanism, and Russ was in the WG meeting when TLS was thrashing around for one. You have a reference? In any case, the revised identity draft doesn't reference it. > > (b) New error codes are invented but not actually assigned. > > I don't understand this. Section 4 of your document names a bunch of new errors but doesn't give them codes. The point isn't that one couldn't specify this stuff, but merely that your proposal isn't finished. Given that we're proposing being done in 4-5 days, that's pretty scary. > >(3) Removal of semantically meaningful IDs. There are a number of > > different ways in which it might be meaningful to name a > > peer (e.g. IP address, FQDN, etc.) This proposal reduces > > the names to whatever happens to appear in the certificate. > > Not true at all. It works exactly like IKEv1 works, except that you > don't have the ID payload. If the receiver knows that Joe is > identified by his IP address, regardless of what is in the > certificate, the receiver uses that information. In IKEv1 the authenticating party tells the client what its identity is and then the verifying party compares the ID payload to the certificate. In your scheme the verifying party has to guess based on the certificate, which is a potential problem if the cert has ambiguous identity information. [IKEv1 is underspecified] > I take it that you think this is just fine for IKEv2. Others, > particularly implementers who have been hurt by the lack of > interoperability, have said they disagree. No, I don't think it's just fine. I think that it needs to be nailed down. > > > Keeping essentially the same certificate handling in IKEv2 > > but clarifying the semantics allows us to tighten IKEv1 > > as well. > > But this is not what the WG chairs have proposed. There is no proposal > for clarifying the semantics in IKEv2 on the table. We are left with > the same nothing as in IKEv1. Why would an implementer go to IKEv2 if > the major user problems with IKEv1 are left the same? As far as I can tell, it is what they've proposed. Quoting from Ted's message: The choice between the working group, then is between using language taken from pki-profile-01 to make explicit when certificate payloads are sent, or choosing the revised-identity proposal. More comments about the tradeoffs inherent between these two choices are hereby requested. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Tue Feb 11 01:04:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B94cd28554; Tue, 11 Feb 2003 01:04:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01185 Tue, 11 Feb 2003 03:30:40 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A63@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Tue, 11 Feb 2003 09:29:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, See my comments below, > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: dinsdag 11 februari 2003 0:23 > To: Van Aken Dirk > Cc: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com; > Scott G. Kelly > Subject: Re: Modefg considered harmful > > > Dirk, > > Unfortunately IPsec MUST know the IP Address that is assigned to > the client. In particular, the IPsec GATEWAY must know what > selectors to apply when creating the tunnel, and must know > the address in an authenticated manner. > > If the gateway is not involved in the IP Address configuration, > then it has to trust the client to act responsible. This may not > be a reasonable choice: > > a) it opens you up to address-stealing attacks > b) it opens you up to address-spoofing attacks I agree on this; these kind of attacks must be countered ! > > Here's why. > > A client connects to a gateway but doesn't agree on an IP Address. > The client then says "ok, I'm 1.2.3.4". The IPsec gateway has no way > to know that this client is authorized to use 1.2.3.4 -- it's just > trusting the client, which is bad. Think PPVPN! If my company and > your company share a VPN node, I could gain access to your vpn this > way. If this can happen then I would say that the design of this IPSec VPN node is inherently insecure ! In this context, you might have a look at RFC2547 (BGP/MPLS VPNs): - this kind of VPN uses the concept of virtual routers such that traffic from one VPN cannot leak into another VPN - it defines the VPN-IPv4 address family such that identical address pools can be used per VPN. Consequently a VPN client can execute the aforementioned attacks but within its own VPN; not in a "neighbor" VPN. > > Address spoofing is much the same way -- if you leave the selectors > open then even though I've got address 1.2.3.4, I could send a packet > claiming to be from 1.2.3.5 into the network. > > The only way to fix this is for the IPsec gateway to be involved in > the address assignment (even if it's just reading the DHCP responses). > I assume there is a misunderstanding here: I agree that the IPSec gateway MUST be involved but it must not necessarily be done directly by the IKE module and it does not necessarily impacts existing IPSec code. My reasoning is the following: 1) IKE takes care of the identification/authentication of the client and allows it to set-up an RFC3456 phase2 2) the client issues DHCP requests in the RFC3456 tunnel 3) a DHCP server responds as it can assume that the client went through the IKE identification/authentication procedure 4) a module (such as a DHCP relay that is outside the IPSec code) analyses these DHCP responses and via an API such as PF_Key or PF_Policy it injects the necessary entries into the SPD 5) in addition, depending on the IPSec implementation, the DHCP relay uses the PF_Route API to add the necessary routes into the forwarding information base 6) finally the client establishes a second SA and announces its IP address via IDci 7) IDci must match the entries added to the SPD and/or FIB in the previous step If the client uses another address, its IDci attribute does not match the SPD rule hence the SA does not get established. Of course depending on the paranoia level, the communication between the client and the DHCP server over the DHCP relay can be further secured; plenty of solutions there. > > IPsec cannot be used in a vacuum. I totally agree with this statement! However in the RFC3456 solution IKE is used for the identification/authentication part but autherization is performed by other modules in coorperation with IKE/IPSec of course. In this way I have a clean separation of different functions and still I don't compromize my security solution. BTW Derec, the attacks you mentioned can be launched successfully against most existing IKEModeCfg solutions for two reasons: - IPSec clients must be able to operate behind NAT/NAPT routers hence a VPN gateway must tolerate multiple modecfg requests from the same peer address which makes attack a) quite easy - most IPSec clients are able to operate with a static IP address which opens possibilities for attack b) You might do a few experiments on this it will confirm my findings ... Cheers - Dirk > > -derek > > Van Aken Dirk writes: > > > The IPSec engine must not sniff on DHCP packets. As said before, > > implementing RFC3456 can IMHO happen almost completely > outside the IKE and > > IPSec code! More specific, a DHCP discover arriving via an > IPSec tunnel has > > a source address (0,0) and destination address (-1,-1). > After passing > > through the SPD, this packet must be delivered locally, > that is, to the > > internal IP host of the IPSec GW (see RFC1812-section > 5.2.3). The local host > > is configured with a DHCP relay that is listening on UDP > port 67 (DHCP > > server port). This DHCP relay can either forward the > request to an internal > > DHCP server or relay it to an external DHCP server. The > only IPSec specific > > item that the relay must take care of is that replies from > the server must > > end-up in the correct "DHCP-tunnel". This can be > accomplished via the DHCP > > Relay Information Option/sub-options. i.e. The DHCP relay > must "tag" the > > DHCP requests (e.g. with the Tunnel IP address, Tunnel port > number) in the > > direction towards the DHCP server and must "untag" the DHCP > replies and use > > this tag to look-up the correct tunnel in the direction > towards the DHCP > > client (see section 4.2 of RFC3456). > > > > So to conclude: > > - I don't have to touch the IKE code > > - I don't have to touch IPSec code > > - I might have to change DHCP relay code but this technology is well > > understood > > - my IP parameter distribution method is in-line with the > rest of the > > network infrastucture and inherits an existing and rich feature set. > > > > > > Best regards - Dirk > > > > > > For your convenience excerpted the relevant section on > local delivery of > > RFC1812 - Requirements for IP Version 4 Routers. > > > > 5.2.3 Local Delivery Decision > > > > When a router receives an IP packet, it must decide whether the > > packet is addressed to the router (and should be > delivered locally) > > or the packet is addressed to another system (and should > be handled > > by the forwarder). There is also a hybrid case, where certain IP > > broadcasts and IP multicasts are both delivered locally and > > forwarded. A router MUST determine which of the these > three cases > > applies using the following rules. > > > > > > o An unexpired source route option is one whose pointer > value does > > not point past the last entry in the source route. > If the packet > > contains an unexpired source route option, the pointer in the > > option is advanced until either the pointer does > point past the > > last address in the option or else the next address > is not one of > > the router's own addresses. In the latter (normal) case, the > > packet is forwarded (and not delivered locally) > regardless of the > > rules below. > > > > o The packet is delivered locally and not considered for > forwarding > > in the following cases: > > > > - The packet's destination address exactly matches one of the > > router's IP addresses, > > > > - The packet's destination address is a limited > broadcast address > > ({-1, -1}), or > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > From owner-ipsec@lists.tislabs.com Tue Feb 11 05:14:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BDECd17869; Tue, 11 Feb 2003 05:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03380 Tue, 11 Feb 2003 07:41:19 -0500 (EST) Message-Id: <200302111242.h1BCgBof091204@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: BSingh@Nomadix.com cc: scott@airespace.com, ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP In-reply-to: Your message of Mon, 10 Feb 2003 15:16:54 PST. <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> Date: Tue, 11 Feb 2003 13:42:11 +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: I have a question about the IPsec SPD.. I had worked a long time back on Linux freeswan.. What I do remember from that is that each tunnel on the outbound side was represented as a virtual interface like ipsec0. So the ipsec engine would insert routes in the routing tables on setup ( I wasn't doing IKE) for these entries leading to my question in the first place because I got the impression that IP routing is necessary and the most typical demultiplexing method to insert packets into different tunnels.. i.e somehow SPD policies map to a routing entry which would mean the destination address being the sole criterion for tunnel selection. => first routes are not enough because they work only on destinations. Second there is nothing about the nature (i.e., interface or not) of IPsec tunnels in RFCs. But I guess this is not what RFC2401 says and it leaves it open for various implementations to have different SPD methodology.. Can you update me on what other ways SPD entries are looked up for tunnel selection. => usually SPD entries are standard filters (i.e., same than for QoS) on the 5-tuple (addresses, protocol, ports) with some restrictions for forwarded packets (because deep parts of the 5-tuple can be hard or impossible to get, for instance for fragments). I am more interested in the source address or some source parameter being included as the criteria for tunnel selection or an SPD interface that lets me make policies based on the source of the packets.. Is it possible? => yes. For instance if you'd like to encode the SPD for a mobile VPN, a source= destination= protocol= ports= will do the job: any packet using the VPN address (i.e., not the local address) will be encapsulated. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Feb 11 10:07:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BI74d08340; Tue, 11 Feb 2003 10:07:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05634 Tue, 11 Feb 2003 12:31:07 -0500 (EST) To: Van Aken Dirk Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" From: "Derek Atkins" Subject: Re: Modefg considered harmful References: <421CB3B9B2D2F645B548D213C0A90E5501168A63@TMM_EDGMSMSG01> Date: 11 Feb 2003 12:34:16 -0500 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5501168A63@TMM_EDGMSMSG01> Message-ID: Lines: 130 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Van Aken Dirk writes: > If this can happen then I would say that the design of this IPSec VPN node > is inherently insecure ! It's not the road-warrior node; it's the gateway. If the GATEWAY is not involved in the address configuration of the road-warrior, then it cannot protect the network. By routing around IPsec (which is exactly what you are proposing by selecting DHCP outside IKE), you are in effect REMOVING the ip address protections from the tunnel. > In this context, you might have a look at RFC2547 (BGP/MPLS VPNs): > - this kind of VPN uses the concept of virtual routers such that traffic > from one VPN cannot leak into another VPN I've looked at this. Unfortunately your analysis is incorrect -- it is possible to leak information from one vpn to another in a BGP/MPLS VPN if you share an entry point to the MPLS network, which maps quite nicely into the attack I'm worried about. > - it defines the VPN-IPv4 address family such that identical address pools > can be used per VPN. > Consequently a VPN client can execute the aforementioned attacks but within > its own VPN; not in a "neighbor" VPN. It depends completely on the implementation. If there is a shared wire between my network edge, your network edge, and the MPLS fabric, then packets can bleed across. MPLS "fixes" this problem by requiring physical point-to-point links between the edge node and the MPLS gateway. That way it can differentiate the traffic based on which physical interface it arrived on. The EXACT SAME THING is true for IPsec -- if IPsec knew the allocated address then it can act in the same way. If the IPsec gateway knows that you are only allowed 1.2.3.4, then if it sees a packet claiming to be from 1.2.3.5 it can drop it. However, if the gateway is not involved in the road-warrior configuration, if it does NOT know what addresses are configured, the is has NO CLUE what addresses are allowed to traverse the tunnel. In effect, it's the same as if you used an ethernet rather than point-to-point links between the edge gateways and MPLS. Sure, the traffic is encrypted, but there is no guarantee it is correct. This is why you MUST include the IPsec gateway in your address configuration. > I assume there is a misunderstanding here: I agree that the IPSec gateway > MUST be involved but it must not necessarily be done directly by the IKE > module and it does not necessarily impacts existing IPSec code. > > My reasoning is the following: > 1) IKE takes care of the identification/authentication of the client and > allows it to set-up an RFC3456 phase2 > 2) the client issues DHCP requests in the RFC3456 tunnel > 3) a DHCP server responds as it can assume that the client went through the > IKE identification/authentication procedure > 4) a module (such as a DHCP relay that is outside the IPSec code) analyses > these DHCP responses and via an API such as PF_Key or PF_Policy it injects > the necessary entries into the SPD > 5) in addition, depending on the IPSec implementation, the DHCP relay uses > the PF_Route API to add the necessary routes into the forwarding information > base > 6) finally the client establishes a second SA and announces its IP address > via IDci > 7) IDci must match the entries added to the SPD and/or FIB in the previous > step UMM, your steps 4 and 5 here have just proven my point. If you are going to require a "special" DHCP relay that knows about IPsec, why not just make that IKE? > BTW Derec, the attacks you mentioned can be launched successfully against > most existing IKEModeCfg solutions for two reasons: My name is "Derek", thank you... > - IPSec clients must be able to operate behind NAT/NAPT routers hence a VPN > gateway must tolerate multiple modecfg requests from the same peer address > which makes attack a) quite easy Operating from behind a NAT has nothing to do with this. We're talking about tunnel-mode address configuration. The fact that the outer address is natted has nothing to do with it. Indeed, this just proves my argument. You necessarily WANT to tie the phase-1 IKE identity to the phase-2 tunnel addresses (i.e. the INSIDE address). Even through a NAT you can still differentiate flows. A gateway ties Flow A to IKE-ID A and ties Flow B to IKE-ID B. When a packet arrives at the gateway on Flow A, the gateway needs to know which address(es) were configured to client-A to make policy acceptance decisions. But you necessarily want to make those policy decisions with full knowledge of the ike id. This is exactly the same problem that MGCP has using IPsec for security. MGCP has in-band endpoint identifiers that name the end points. The problem is that this identifier is NOT tied to the IPsec security, so just because a flow is protected by IPsec does NOT imply that you can believe the MGCP identifier. As a real-world example, your neighbor could connect to your neighborhood MGCP gateway but claim to be you within MGCP. Sure, IPsec would know its your neighbor, but MGCP would not. This is why you need to tie the identifiers together. In MGCP you need to tie the MGCP identifier into IKE/IPsec. In the IPsec VPN you need to tie the Tunneled IP Addresses to the IKE ID. This means that the IKE policy (on the gateway) needs to know what address(es) are assigned to the road-warrior client. > - most IPSec clients are able to operate with a static IP address which > opens possibilities for attack b) In which case the IPsec Gateway should know which address the client is connecting from, and that becomes part of the policy. > You might do a few experiments on this it will confirm my findings ... I have performed these experiments, and they don't confirm your findings. Perhaps there are some (broken) implementation of IPsec that have these failings, but this is a bug. A working IPsec implementation is easily capable of protecting against these attacks. > Cheers - Dirk -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 11 11:09:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BJ9sd10625; Tue, 11 Feb 2003 11:09:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06221 Tue, 11 Feb 2003 13:41:30 -0500 (EST) 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, 11 Feb 2003 10:34:48 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKEV2: Issue #4 Revised Identity Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:07 PM -0800 2/10/03, Eric Rescorla wrote: >In IKEv1 the authenticating party tells the client what its identity is >and then the verifying party compares the ID payload to the >certificate. That is one interpretation; there are many others. As others have said before on this thread, anyone who has gone to the bakeoffs knows this. > In your scheme the verifying party has to >guess based on the certificate, which is a potential problem >if the cert has ambiguous identity information. There is no such thing as a certificate with ambiguous identifying information. You inherently trust the certificate issuer to give the right information. > > But this is not what the WG chairs have proposed. There is no proposal >> for clarifying the semantics in IKEv2 on the table. We are left with >> the same nothing as in IKEv1. Why would an implementer go to IKEv2 if >> the major user problems with IKEv1 are left the same? >As far as I can tell, it is what they've proposed. Quoting from >Ted's message: > > The choice between the working group, then is between using > language taken from pki-profile-01 to make explicit when > certificate payloads are sent, or choosing the > revised-identity proposal. More comments about the tradeoffs > inherent between these two choices are hereby requested. So, let's ask the WG chairs then: is Eric's interpretation correct? Is this also a WG last call on pki-profile-01? If not, then IKEv2 will be plagued with the same interop problems that IKEv1 has. If it is a last call, the WG should be discussing the document, which has gotten no traffic to date. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Feb 11 14:05:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BM5Bd17859; Tue, 11 Feb 2003 14:05:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07795 Tue, 11 Feb 2003 16:32:41 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: Reply-To: EKR From: Eric Rescorla Date: 11 Feb 2003 13:40:04 -0800 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 11:07 PM -0800 2/10/03, Eric Rescorla wrote: > >In IKEv1 the authenticating party tells the client what its identity is > >and then the verifying party compares the ID payload to the > >certificate. > > That is one interpretation; there are many others. As others have said > before on this thread, anyone who has gone to the bakeoffs knows this. I agree that it's ambiguous. I'm concerned to clarify it. I believe the interpretation i just provided is the most straightforward one. > > In your scheme the verifying party has to > >guess based on the certificate, which is a potential problem > >if the cert has ambiguous identity information. > > There is no such thing as a certificate with ambiguous identifying > information. I'm afraid that's not true. Consider what happens when you get a certificate with CN="www.rtfm.com". Is that a domain name? Someone's name? Something else? -Ekr From owner-ipsec@lists.tislabs.com Tue Feb 11 18:34:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C2Y3d24698; Tue, 11 Feb 2003 18:34:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10144 Tue, 11 Feb 2003 21:04:10 -0500 (EST) Reply-To: From: "Greg Carter" To: Subject: RE: IKEV2: Issue #4 Revised Identity Date: Tue, 11 Feb 2003 21:11:35 -0500 Message-ID: <003301c2d23c$12aeee00$1e02a8c0@entrust.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mucho comments below... >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC >Sent: February 11, 2003 1:35 PM >To: ipsec@lists.tislabs.com >Subject: Re: IKEV2: Issue #4 Revised Identity >At 11:07 PM -0800 2/10/03, Eric Rescorla wrote: >>In IKEv1 the authenticating party tells the client what its identity is >>and then the verifying party compares the ID payload to the >>certificate. >That is one interpretation; there are many others. As others have >said before on this thread, anyone who has gone to the bakeoffs knows >this. Yeah they know it is the correct way to do it. And if they were not doing it before now, the pkix profile draft makes it explicitly clear. I remembered talking about this a lot 'back in the day', and here is a message from 1998 that I wrote to the list: http://www.sandelman.ottawa.on.ca/ipsec/1998/07/msg00074.html and another from 1999 http://www.sandelman.ottawa.on.ca/ipsec/1999/10/msg00212.html I am sure I mentioned it in other emails, but I am guessing that was to the ANX bakeoff (bakeoff!) list. At the bakeoffs I know I told anyone who would listen. >But that's a reasonable counter-proposal that gets to the same end: >not having to send certs each time, and therefore avoid the failure >in routers and firewalls that don't pass fragmented UDP. Without a >hash-of-cert mechanism, implementations will continue to suffer this >silent failure Just so I am clear, with your Revised ID proposal the only way to achieve certificate caching is if the IKE implementation supports retrieval of certificates via http URLs? Further the only way to prevent IKE UDP packet fragmentation is via out of band certificate/chain retrieval (http)? So the problems solved are caching and UDP fragmentation (BTW the latter is not a stated goal of your draft). I am not a router guru so I don't know the details of the fragmentation issue. I guess I would like to see a better description of the UDP fragmentation problem if that is one of the goals. I think I did see it once at a bakeoff but that was with large CRLs, and at the time was dismissed as a problem with the receiver. Problems with the Revised Identity proposal: - mandates HTTP to retrieve the certificate. What about the rest of the chain (intermediate CAs and CRLs)? Ideally you would allow either LDAP or HTTP. If I can do full path building via a repository it will most likely be via LDAP (well that is my experience), not HTTP. With the risk of being stoned to death I'll mention WAP defined a decent certificate URL format for both HTTP and LDAP. So if this proposal goes further you might want to look at it. - does not allow CRLs in band. Whether or not IKEv1 implementations use this feature today isn't the issue, the fact is you can do this in IKEv1 and it handles the VPN case nicely. Gateway pushes down its certificate, any intermediate certificates, and any CRLs needed over IKE. Client has everything it needs to validate, doesn't have to go to any remote repository or validation server (which presumably it couldn't even if it wanted to). - Certificate bundling - The end of section 3.1 implies that a certificate bundle will contain end entity certificates with different IDs (CAs?). How am I supposed to know which certificate to use (look in the ID payload haha)? I assume they will all have different key pairs, so the process of choosing one becomes "attempt signature validation for cert N, repeat". This seems a bit at odds with the notion of "The certificate is the ID" philosophy. I would rather see a definition that limited the cert bundle to only one end entity certificate (or only one with the correct key usage). Along the same lines, I don't understand this statement from section 3.1: "If a system can resolve URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have the certificate of the other side, such as if it has just recovered from a crash and its cache is empty." If it can resolve URLs, it can resolve URLs, it doesn't matter if the cache is empty. If the cache is empty then it, oddly enough, resolves the URL :) Maybe I am missing something. Caching Alternatives I haven't put too much thought into this, and I expect it is too late to define something like this but here goes: One way to add explicit caching would be to have a new payload "CERT_HASH" which would optionally be sent in messages 1 & 2. The payload would contain a list of hash values of the end entity certificates you could possibly send to the other end. If the receiver of the "CERT_HASH" payload doesn't have one of those hash values in it's cache then it sends the cert request payload in message 3 or 4. If you do not receive a CERT_REQ payload, do not send your certificate. This mechanism could be defined to indicate what CERT type is associated with the hash (caching CRLs etc). IDs remain as in IKEv1. Not sure if this will leak identity... Of course the another alternative is to do nothing. A clever implementation could keep state associated with the peer (works for clients, not the VPN gateway), or define your own vendor payload ("Hey I connected yesterday, so you probably have my cert cached so don't ask for it unless you think you need it"). UDP Fragmentation Neither of the above alternatives would help with fragmentation, but I don't know enough about the problem. One last thing... in another email to the list you mentioned the problems of IKEv2 referencing the profile draft. Putting aside IETF protocol, the difference between referencing it and the Revised ID draft is that the profile draft clarifies how existing implementations should already be working, not defining new behaviour. Greg Carter From owner-ipsec@lists.tislabs.com Tue Feb 11 20:24:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C4O9d26990; Tue, 11 Feb 2003 20:24:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11054 Tue, 11 Feb 2003 22:57:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <003301c2d23c$12aeee00$1e02a8c0@entrust.com> References: <003301c2d23c$12aeee00$1e02a8c0@entrust.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: Tue, 11 Feb 2003 19:58:46 -0800 To: , From: Paul Hoffman / VPNC Subject: RE: IKEV2: Issue #4 Revised Identity Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:11 PM -0500 2/11/03, Greg Carter wrote: >Just so I am clear, with your Revised ID proposal the only way to achieve >certificate caching is if the IKE implementation supports retrieval of >certificates via http URLs? Nope, nothing in the document says that. You can cache any certs you know about from any means, such as from people who sent them to you in IKE. > Further the only way to prevent IKE UDP packet >fragmentation is via out of band certificate/chain retrieval (http)? Nope, nothing in the document says this either. The only way to prevent IKE UDP packet fragmentation is to make the fragments small enough not to fragment. URL-and-hash will help that. Sending only a single small cert will help that. Sending raw RSA keys will help that. >So the problems solved are caching and UDP fragmentation (BTW the latter is >not a stated goal of your draft). I am not a router guru so I don't know >the details of the fragmentation issue. I guess I would like to see a >better description of the UDP fragmentation problem if that is one of the >goals. I think I did see it once at a bakeoff but that was with large CRLs, >and at the time was dismissed as a problem with the receiver. This has been discussed in the WG a few times. Basically, some devices will drop any fragmented UDP packets either all the time or when their reassembly buffers are full. >Problems with the Revised Identity proposal: > - mandates HTTP to retrieve the certificate. What about the rest of the >chain (intermediate CAs and CRLs)? Ideally you would allow either LDAP or >HTTP. Ideally for whom? That is certainly not ideal for IPsec implementers. > If I can do full path building via a repository it will most likely >be via LDAP (well that is my experience), not HTTP. With the risk of being >stoned to death I'll mention WAP defined a decent certificate URL format for >both HTTP and LDAP. So if this proposal goes further you might want to look >at it. IPsec vendors have looked at it, and they came to a different conclusion than the PKI vendors. No surprise there. > - does not allow CRLs in band. Whether or not IKEv1 implementations use >this feature today isn't the issue, the fact is you can do this in IKEv1 and >it handles the VPN case nicely. Gateway pushes down its certificate, any >intermediate certificates, and any CRLs needed over IKE. Client has >everything it needs to validate, doesn't have to go to any remote repository >or validation server (which presumably it couldn't even if it wanted to). See above. > - Certificate bundling - The end of section 3.1 implies that a certificate >bundle will contain end entity certificates with different IDs (CAs?). How >am I supposed to know which certificate to use (look in the ID payload >haha)? The ID payload wouldn't help you there, obviously. You parse the certificates looking for CAs you trust. If multiple certs match, you parse them for IDs that you trust. Done. > I assume they will all have different key pairs, so the process of >choosing one becomes "attempt signature validation for cert N, repeat". Spoken like a true PKI vendor. :-) >This seems a bit at odds with the notion of "The certificate is the ID" >philosophy. I would rather see a definition that limited the cert bundle to >only one end entity certificate (or only one with the correct key usage). That's a possibility. Well, it was a possibility before the proposal was axed. >One last thing... in another email to the list you mentioned the problems of >IKEv2 referencing the profile draft. Putting aside IETF protocol, Er, this is a WG in the IETF. We don't get to "put aside IETF protocol". > the >difference between referencing it and the Revised ID draft is that the >profile draft clarifies how existing implementations should already be >working, not defining new behaviour. ...and thereby screwing all the vendors who implemented IKEv1 in good faith, following what little it said and making guesses about the rest. The IETF has rules about not doing that. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Feb 11 23:30:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C7URd08290; Tue, 11 Feb 2003 23:30:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12394 Wed, 12 Feb 2003 01:59:52 -0500 (EST) To: Paul Hoffman / VPNC Cc: , Subject: Re: IKEV2: Issue #4 Revised Identity References: <003301c2d23c$12aeee00$1e02a8c0@entrust.com> Reply-To: EKR From: Eric Rescorla Date: 11 Feb 2003 23:07:33 -0800 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 9:11 PM -0500 2/11/03, Greg Carter wrote: > >Just so I am clear, with your Revised ID proposal the only way to achieve > >certificate caching is if the IKE implementation supports retrieval of > >certificates via http URLs? > > Nope, nothing in the document says that. You can cache any certs you > know about from any means, such as from people who sent them to you in > IKE. Right, but how do you arrange to communicate what you've cached to the peer so that they send you the right certificate if your cache is invalid for some reason (assuming that you can't retrieve the right one with HTTP)? -Ekr From owner-ipsec@lists.tislabs.com Wed Feb 12 01:50:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C9oQd28507; Wed, 12 Feb 2003 01:50:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13611 Wed, 12 Feb 2003 04:22:29 -0500 (EST) Message-Id: <200302120925.h1C9PXWs010812@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-reply-to: Your message of "11 Feb 2003 23:07:33 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Feb 2003 04:25:32 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Eric" == Eric Rescorla writes: Eric> Paul Hoffman / VPNC writes: >> At 9:11 PM -0500 2/11/03, Greg Carter wrote: >Just so I am clear, with >> your Revised ID proposal the only way to achieve >certificate caching >> is if the IKE implementation supports retrieval of >certificates via >> http URLs? >> >> Nope, nothing in the document says that. You can cache any certs you >> know about from any means, such as from people who sent them to you in >> IKE. Eric> Right, but how do you arrange to communicate what you've cached to Eric> the peer so that they send you the right certificate if your cache Eric> is invalid for some reason (assuming that you can't retrieve the Eric> right one with HTTP)? That's really not a problem for IKE. If the right goop isn't there, you loose. That's why we want to just send the URL (or URN if you want) where the certificate, whatever chain you need, and maybe the CRL, can be found. Sending the whole thing makes total sense for TLS, and it works well for HTTPS, SMTP(STARTTLS), but not for IKE over UDP. Maybe IKE v3 will run over SCTP... maybe not. Honestly. With something like 80% of VPNs running pre-shared secrets because there are multiple implementations out there that can't even cope with importing or exporting even a self-signed certificate (or making it so hard nobody bothers), I really do not think that we need any more esoteric situations. Once we have 90% of deployment running with public keys, and the rest doing legacy auth, maybe with public keys assymetrically, then it will be time worry about extended chain resolution etc... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkoTC4qHRg3pndX9AQHn3AP/cgnyLPnqxb90C4f2PXsyH2oHgoZjPkCY Ee+kWZlhIVn9LIwsMiM9usuwZZXhV3JUI2f4j2ab9Qb7n7oJsXDlbBKtvInIHhq5 ckdSbxAYVm4vf6wdSXfyZ/h7W7gWwyJJKIstWblUHcWiL6sEV1jK27TMvI/rz8ND tPSmphVdIXs= =kLmg -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 12 01:50:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C9oVd28519; Wed, 12 Feb 2003 01:50:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13633 Wed, 12 Feb 2003 04:23:32 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A6C@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Wed, 12 Feb 2003 10:26:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dereck ;-) See my comments below. ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: dinsdag 11 februari 2003 18:34 > To: Van Aken Dirk > Cc: ipsec@lists.tislabs.com; Scott G. Kelly > Subject: Re: Modefg considered harmful > > > Van Aken Dirk writes: > > > If this can happen then I would say that the design of this > IPSec VPN node > > is inherently insecure ! > > It's not the road-warrior node; it's the gateway. I was indeed referring to the gateway. > If the GATEWAY is not involved in the address configuration of the road-warrior, then it > cannot protect the network. RFC3456 is about assigning addresses via tunnels; its not about routing (actually forwarding). > By routing around IPsec (which is exactly > what you are proposing by selecting DHCP outside IKE), you are in > effect REMOVING the ip address protections from the tunnel. > > > In this context, you might have a look at RFC2547 (BGP/MPLS VPNs): > > - this kind of VPN uses the concept of virtual routers such > that traffic > > from one VPN cannot leak into another VPN > > I've looked at this. Unfortunately your analysis is incorrect -- it > is possible to leak information from one vpn to another in a BGP/MPLS > VPN if you share an entry point to the MPLS network, which maps quite > nicely into the attack I'm worried about. I would advise: post this paragraph to the PPVPN working group mailing list ! > > It depends completely on the implementation. If there is a shared > wire between my network edge, your network edge, and the MPLS fabric, > then packets can bleed across. MPLS "fixes" this problem by requiring > physical point-to-point links between the edge node and the MPLS > gateway. That way it can differentiate the traffic based on which > physical interface it arrived on. Not correct: is this would be a RFC2547 requirement than it would result in an architecture that cannot scale. MPLS routers have typically a few 155 MBit/s Sonet/ATM links but with literally thousands of virtual channels. Doing this with physical links would result in large boxes don't you think ? For your convenience I copied section 1.2 of RFC2547 and RFC2547bis below: 1.2. Edge Devices (RFC2547) We suppose that at each site, there are one or more Customer Edge (CE) devices, each of which is attached via some sort of data link (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers. Nothing in here about "physical" point-to-point links. Actually regarding terminology, RFC2547bis is a little bit better on this point: 1.2. Customer Edge and Provider Edge (RFC2547 - draft-ietf-ppvpn-rfc2547bis-03.txt) Routers can be attached to each other, or to end systems, in a variety of different ways: PPP connections, ATM VCs, Frame Relay DLCIs, ethernet interfaces, VLANs on ethernet interfaces, GRE tunnels, L2TP tunnels, IPsec tunnels, etc. We will use the term "attachment circuit" to refer generally to some such means of attaching to a router. An attachment circuit may be the sort of connection that is usually thought of as a "data link", or it may be a tunnel of some sort; what matters is that it be possible for two devices to be network layer peers over the attachment circuit. Each VPN site must contain one or more Customer Edge (CE) devices. Each CE device is attached, via some sort of attachment circuit, to one or more Provider Edge (PE) routers. > > I assume there is a misunderstanding here: I agree that the > IPSec gateway > > MUST be involved but it must not necessarily be done > directly by the IKE > > module and it does not necessarily impacts existing IPSec code. > > > > My reasoning is the following: > > 1) IKE takes care of the identification/authentication of > the client and > > allows it to set-up an RFC3456 phase2 > > 2) the client issues DHCP requests in the RFC3456 tunnel > > 3) a DHCP server responds as it can assume that the client > went through the > > IKE identification/authentication procedure > > 4) a module (such as a DHCP relay that is outside the IPSec > code) analyses > > these DHCP responses and via an API such as PF_Key or > PF_Policy it injects > > the necessary entries into the SPD > > 5) in addition, depending on the IPSec implementation, the > DHCP relay uses > > the PF_Route API to add the necessary routes into the > forwarding information > > base > > 6) finally the client establishes a second SA and announces > its IP address > > via IDci > > 7) IDci must match the entries added to the SPD and/or FIB > in the previous > > step > > UMM, your steps 4 and 5 here have just proven my point. If you are > going to require a "special" DHCP relay that knows about IPsec, why > not just make that IKE? Well as said before, removing peer configuration from IKE and talking via an API (which is an abstraction of the IKE functionality) yields: 1) I don't need an IKE expert for this module and 2) each time a new attribute is defined I don't have to go through an certification process (such as ICSA's). Yet I can assure my customer that still my IPSec solution is not compromised although I added/changed functionality. BTW, after 20 years of BOOTP/DHCP new options are still being defined due to the ever changing network environment. Why would this not be the case for IKEModeCfg ? > > I have performed these experiments, and they don't confirm your > findings. Perhaps there are some (broken) implementation of IPsec > that have these failings, but this is a bug. Might be the case ... A working IPsec > implementation is easily capable of protecting against these attacks. I think everything is said on this subject and I guess it is up to the wise men on the IPSec list to formulate recommendations for the IKEv2 draft. Over & Out - Dirk From owner-ipsec@lists.tislabs.com Wed Feb 12 02:21:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CALvd04037; Wed, 12 Feb 2003 02:21:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14031 Wed, 12 Feb 2003 04:57:44 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A6D@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Wed, 12 Feb 2003 10:59:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, An afterthaugth .. > > This is why you need to tie the identifiers together. In MGCP you > need to tie the MGCP identifier into IKE/IPsec. In the IPsec VPN you > need to tie the Tunneled IP Addresses to the IKE ID. This means that > the IKE policy (on the gateway) needs to know what address(es) are > assigned to the road-warrior client. I share your concern regarding tying the Tunneled IP address to the remote peer identity. But isn't this accomplished by ESP ? i.e I copied folllowing paragraph from the second version of ESP: () Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity." (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. For me a secure solution is not only about IKE but it encompasses IKE, SPD, SAD ESP and cryptography. ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain From owner-ipsec@lists.tislabs.com Wed Feb 12 03:55:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CBtmd09240; Wed, 12 Feb 2003 03:55:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15001 Wed, 12 Feb 2003 06:26:26 -0500 (EST) Message-Id: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-reply-to: Your message of Wed, 12 Feb 2003 04:25:32 EST. <200302120925.h1C9PXWs010812@marajade.sandelman.ottawa.on.ca> Date: Wed, 12 Feb 2003 12:27:00 +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: That's why we want to just send the URL (or URN if you want) where the certificate, whatever chain you need, and maybe the CRL, can be found. => I agree: even if the revised identity proposal seems a bit drastic it fully solved the issue (this is why I support it). Sending the whole thing makes total sense for TLS, and it works well for HTTPS, SMTP(STARTTLS), but not for IKE over UDP. Maybe IKE v3 will run over SCTP... maybe not. => in my IPsec for Mobile IPv6 experiments, the message with the whole thing *never* reached the other end at the first try! I agree IKE should run over SCTP (with funny consequences on peer addresses :-) but perhaps it is too soon to propose this? IMHO IKE is a signaling protocol so should use SCTP... Honestly. With something like 80% of VPNs running pre-shared secrets => unfortunately with weak implementations of XAUTH for mobile clients... because there are multiple implementations out there that can't even cope with importing or exporting even a self-signed certificate (or making it so hard nobody bothers), I really do not think that we need any more esoteric situations. => I can't parse your conclusion: do you support or not the revised identity proposal for IKEv2? Once we have 90% of deployment running with public keys, and the rest doing legacy auth, maybe with public keys assymetrically, then it will be time worry about extended chain resolution etc... => IMHO a large part of the issue comes from the network access control (the AAA) done by IKE when IKE has no native interface with an AAA system. The PKI stuff should be integrated with legacy authentication in order to provide a native AAA interface in charge of the strong authentication with authorization and accounting as goodies... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Feb 12 05:17:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CDHAd13305; Wed, 12 Feb 2003 05:17:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15880 Wed, 12 Feb 2003 07:50:53 -0500 (EST) Message-ID: <3E49E71A.57D2666C@briank.com> Date: Tue, 11 Feb 2003 22:18:04 -0800 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: <003301c2d23c$12aeee00$1e02a8c0@entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Comments below... -brian briank@briank.com Paul Hoffman / VPNC wrote: > At 9:11 PM -0500 2/11/03, Greg Carter wrote: > >Just so I am clear, with your Revised ID proposal the only way to achieve > >certificate caching is if the IKE implementation supports retrieval of > >certificates via http URLs? > > Nope, nothing in the document says that. You can cache any certs you > know about from any means, such as from people who sent them to you > in IKE. Of course you can cache anything you want, but what the Revised ID proposal is missing is a way to specify to a peer that it needn't resend the already-cached items. Certs and CRLs are large, processing them is costly, and IKE is over UDP, so some see not having to resend these as a real benefit. YMMV. > > Further the only way to prevent IKE UDP packet > >fragmentation is via out of band certificate/chain retrieval (http)? > > Nope, nothing in the document says this either. The only way to > prevent IKE UDP packet fragmentation is to make the fragments small > enough not to fragment. URL-and-hash will help that. Sending only a > single small cert will help that. Sending raw RSA keys will help that. > > >So the problems solved are caching and UDP fragmentation (BTW the latter is > >not a stated goal of your draft). I am not a router guru so I don't know > >the details of the fragmentation issue. I guess I would like to see a > >better description of the UDP fragmentation problem if that is one of the > >goals. I think I did see it once at a bakeoff but that was with large CRLs, > >and at the time was dismissed as a problem with the receiver. > > This has been discussed in the WG a few times. Basically, some > devices will drop any fragmented UDP packets either all the time or > when their reassembly buffers are full. > > >Problems with the Revised Identity proposal: > > - mandates HTTP to retrieve the certificate. What about the rest of the > >chain (intermediate CAs and CRLs)? Ideally you would allow either LDAP or > >HTTP. > > Ideally for whom? That is certainly not ideal for IPsec implementers. That the caching mechanism does not support CRLs does seem like a shortcoming. Regarding LDAP, I think Greg might have a good point here, at least one that deserves more discussion. > > > If I can do full path building via a repository it will most likely > >be via LDAP (well that is my experience), not HTTP. With the risk of being > >stoned to death I'll mention WAP defined a decent certificate URL format for > >both HTTP and LDAP. So if this proposal goes further you might want to look > >at it. > > IPsec vendors have looked at it, and they came to a different > conclusion than the PKI vendors. No surprise there. > > > - does not allow CRLs in band. Whether or not IKEv1 implementations use > >this feature today isn't the issue, the fact is you can do this in IKEv1 and > >it handles the VPN case nicely. Gateway pushes down its certificate, any > >intermediate certificates, and any CRLs needed over IKE. Client has > >everything it needs to validate, doesn't have to go to any remote repository > >or validation server (which presumably it couldn't even if it wanted to). > > See above. > > > - Certificate bundling - The end of section 3.1 implies that a certificate > >bundle will contain end entity certificates with different IDs (CAs?). How > >am I supposed to know which certificate to use (look in the ID payload > >haha)? > > The ID payload wouldn't help you there, obviously. You parse the > certificates looking for CAs you trust. If multiple certs match, you > parse them for IDs that you trust. Done. > > > I assume they will all have different key pairs, so the process of > >choosing one becomes "attempt signature validation for cert N, repeat". > > Spoken like a true PKI vendor. :-) > > >This seems a bit at odds with the notion of "The certificate is the ID" > >philosophy. I would rather see a definition that limited the cert bundle to > >only one end entity certificate (or only one with the correct key usage). > > That's a possibility. Well, it was a possibility before the proposal was axed. > > >One last thing... in another email to the list you mentioned the problems of > >IKEv2 referencing the profile draft. Putting aside IETF protocol, > > Er, this is a WG in the IETF. We don't get to "put aside IETF protocol". > > > the > >difference between referencing it and the Revised ID draft is that the > >profile draft clarifies how existing implementations should already be > >working, not defining new behaviour. > > ...and thereby screwing all the vendors who implemented IKEv1 in good > faith, following what little it said and making guesses about the > rest. The IETF has rules about not doing that. The pki-profile draft is currently being revised due to comments that were posted to the list, so now is an excellent time to submit feedback describing how the draft could be improved. BTW, the currently draft is advertised as a straw man, so no one should feel "screwed" by it. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 12 05:17:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CDHDd13318; Wed, 12 Feb 2003 05:17:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15869 Wed, 12 Feb 2003 07:49:53 -0500 (EST) Message-Id: <200302111833.h1BIXZ2E020585@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com From: "Michael Richardson" Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP In-reply-to: Your message of "Mon, 10 Feb 2003 15:16:54 PST." <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Feb 2003 13:33:35 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "BSingh" == BSingh writes: BSingh> Thanks for your responses.. I have another query regarding this. BSingh> I have a question about the IPsec SPD.. I had worked a long time BSingh> back on Linux freeswan.. What I do remember from that is that BSingh> each tunnel on the outbound side was represented as a virtual BSingh> interface like ipsec0. So the ipsec engine would insert routes in No, each tunnel does not have a virtual interface in FreeS/WAN. Each *physical* interface has a virtual interface, like "ipsec0" associated with it. We steal the packets via routing, and then insert them into the real interface using magic. We are heading towards a situation where each tunnel could have a virtual interface (it will be an option). We are heading away from having an the virtual interfaces have anything to do with the physical interfaces. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPklB/YqHRg3pndX9AQEpFgQAv5QHr7OvrtBOtITWa9pbSHT5zFlYhkSl TKs35WtfDW0P4eLsLa1qo/tIE3xu4RGe+xo1R/SlM/7e0WUbK2QzedSHjQOgBBw9 LoMfYkbocesMuSkSfb3wUFNTr4A70sFe8mKp2FpjxTgxwMjPt/ZwviRpc+DAjbu1 /SNPOTmZIac= =qsu3 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 12 05:17:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CDHKd13333; Wed, 12 Feb 2003 05:17:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15853 Wed, 12 Feb 2003 07:48:53 -0500 (EST) Message-ID: <20030211161530.65874.qmail@web9407.mail.yahoo.com> Date: Tue, 11 Feb 2003 08:15:30 -0800 (PST) From: Suresh Kumar Subject: IPSec/IKE Implementaion on Solaris 8.0 To: ipsec@lists.tislabs.com In-Reply-To: <200302111242.h1BCgBof091204@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-376482387-1044980130=:63158" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-376482387-1044980130=:63158 Content-Type: text/plain; charset=us-ascii Hello IPSec Gurus, Any public domain/portable or commerical implemenation of IKE available for Solaris 8.0. If any of you have ported any freeware to solaris please share your experience with me. Suresh. --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day --0-376482387-1044980130=:63158 Content-Type: text/html; charset=us-ascii

Hello IPSec Gurus,

Any public domain/portable or commerical implemenation of IKE available for Solaris 8.0.  If any of you have ported any freeware to solaris please share your experience with me.

Suresh.

 



Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day --0-376482387-1044980130=:63158-- From owner-ipsec@lists.tislabs.com Wed Feb 12 07:36:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFa6d20789; Wed, 12 Feb 2003 07:36:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17193 Wed, 12 Feb 2003 09:59:20 -0500 (EST) Date: Wed, 12 Feb 2003 10:01:39 -0500 From: "Theodore Ts'o" To: Pekka Riikonen Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity Message-ID: <20030212150139.GG8238@think.thunk.org> References: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Feb 12, 2003 at 02:36:51PM +0100, Pekka Riikonen wrote: > > The revised identity can solve the problem of defining what the ID > actually is and when not to send certificates. Well, the revised identity draft does solve the problem, essentially be eliminating the ID and CERT payloads altogether, conflating the IKEv1 concept of identity and certificate, and instead always requiring both sides to send a certificate, which *is* the identity. > However, having read the draft it is in my opinion clear that same > features can be accomplished without introducing new payloads, but > using the Certificate Request (CR) payload, and revising the > specification for this payload. Well, yes, and that's what the pki-profile document does, and without needing to change the IKEv1 specification (but instead making the specification tighter): 3.3.7. Presence or Absence of Certificate Request Payloads When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. An implementation which does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads. ... 3.3.8.1. Specifying Certificate Authorities Implementations MUST generate CERTREQs for every peer root that local policy explicitly deems trusted during a given exchange. Implementa- tions MUST populate the Certificate Authority field with the Subject Name of the trusted root, populated such that binary comparison of the Subject Name and the Certificate Authority will succeed. Upon receipt of a CERTREQ where the Certificate Type is either "X.509 Certificate - Signature" or "X.509 Certificate - Key Exchange", 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. Imple- mentations MAY send other certificates from the chain. The IKEv1 interoperability problems arose because IKEv1 underspecified how the payloads should be used. > What is nice about revised identity draft (as opposed to pki-profile) is > that it allows the use of URL to tell where the cert is available. This > too could be done by revising the Certificate payload by adding new > encoding types (like URL) if this feature is really needed. As I have pointed out in the past, this could be added to IKEv2 (and IKEv1) for that matter, simply by defining a new certificate encoding type to the CERT payload. This issue is independent of whether to use a IKEv1 or Revisied identity-style approach. The tradeoffs are reducing the UDP packet size, versus additional complexity caused by (a) needing to have some kind of access controls since you don't want to responder to visit an arbitrary URL based on an unauthenticated request from the initiator, and (b) dealing with the case where the initiator doesn't have access to the global internet (i.e., in the dialup VPN case), and is presented with a certificate URL. - Ted From owner-ipsec@lists.tislabs.com Wed Feb 12 07:42:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFg7d21006; Wed, 12 Feb 2003 07:42:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17304 Wed, 12 Feb 2003 10:11:37 -0500 (EST) To: Paul Hoffman / VPNC Cc: , Subject: Re: IKEV2: Issue #4 Revised Identity References: <003301c2d23c$12aeee00$1e02a8c0@entrust.com> Reply-To: EKR From: Eric Rescorla Date: 12 Feb 2003 07:18:39 -0800 In-Reply-To: Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 9:11 PM -0500 2/11/03, Greg Carter wrote: > > the > >difference between referencing it and the Revised ID draft is that the > >profile draft clarifies how existing implementations should already be > >working, not defining new behaviour. > > ...and thereby screwing all the vendors who implemented IKEv1 in good > faith, following what little it said and making guesses about the > rest. The IETF has rules about not doing that. I disagree. In fact, it's SOP to publish new drafts that clarify behavior that was underspecified in previous drafts. Naturally, this occasionally screws people who took the interpretation not chosen and that's a strong incentive to choose carefully. But at the end of the day there has to be one interpretation and that means that someone has to change. >From RFC 2026: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. ... Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Feb 12 07:42:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFgZd21027; Wed, 12 Feb 2003 07:42:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17342 Wed, 12 Feb 2003 10:14:41 -0500 (EST) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: <200302120925.h1C9PXWs010812@marajade.sandelman.ottawa.on.ca> Reply-To: EKR From: Eric Rescorla Date: 12 Feb 2003 07:22:10 -0800 In-Reply-To: <200302120925.h1C9PXWs010812@marajade.sandelman.ottawa.on.ca> Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > That's really not a problem for IKE. > If the right goop isn't there, you loose. Uh, then why bother having caching at all? If you're going to have caching you have to have cache invalidation. > That's why we want to just send the URL (or URN if you want) where the > certificate, whatever chain you need, and maybe the CRL, can be > found. And if the implementation can't do HTTP you're completely SOL--or rather you have to send the whole chain over UDP, which is what you say you're trying to avoid. > Honestly. With something like 80% of VPNs running pre-shared secrets > because there are multiple implementations out there that can't even cope > with importing or exporting even a self-signed certificate (or making it > so hard nobody bothers), I really do not think that we need any more > esoteric situations. It's my view that part of REASON that so many implementations run shared secrets is that IKE certificate handling is so screwed up. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Feb 12 07:58:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFw8d21411; Wed, 12 Feb 2003 07:58:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17472 Wed, 12 Feb 2003 10:25:04 -0500 (EST) Date: Wed, 12 Feb 2003 10:27:43 -0500 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity Message-ID: <20030212152743.GH8238@think.thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Feb 11, 2003 at 10:34:48AM -0800, Paul Hoffman / VPNC wrote: > > The choice between the working group, then is between using > > language taken from pki-profile-01 to make explicit when > > certificate payloads are sent, or choosing the > > revised-identity proposal. More comments about the tradeoffs > > inherent between these two choices are hereby requested. > > So, let's ask the WG chairs then: is Eric's interpretation correct? > Is this also a WG last call on pki-profile-01? If not, then IKEv2 > will be plagued with the same interop problems that IKEv1 has. If it > is a last call, the WG should be discussing the document, which has > gotten no traffic to date. If you take a close look at the pki-profile ID, you will find that it is really two documents in one. Following the introduction and the background information, section 3 is a profile of ISAKMP/IKEv1, and section 4 is a profile of PKIX/x.509 certificates. If you then take a closer look at section 3, a good part of the material in section 3 are definitions already found in the IKEv1 and IKEv2 drafts (but which were necessary to make pki-profile a standalone document), and the rest are a tightening up of the requirements, because IKEv1 was too loose in its specifications. For example, pki-profile states that if in-band certificats are expected, implementations MUST inform the peer of this by sending at least one CERTREQ, and that implementations MUST respond to CERTREQ's by sending a CERT payload with the appropriate certificate. This is all arguably good stuff that should have been in the original IKEv1 specification, but which was very unfortunately missing. If it had been there, I suspect most of the interoperability headaches that IKEv1 implementors suffered from could have been avoided --- and I believe a goood part of what is in the pki-profile is essentially summarizing what IKEv1 implementors have had to discover the hard way from bakeoffs, and codifying it into a specification. In essense, pki-profile supplies the semantics to IKEv1, which in the case of the CERT and ID payload, very unfortunately had synxtax only, but no semantics in its original specification. In our summary of the revised identity issue, we pointed to comments made by at least two working group members, who stated that an alternative to revised identity would be to adopt text from the pki-profile ID to fully define certificate handling. Presumably, this would be taking selected text from section 3 of this document, which arguably should have been in IKEv1 in the first place, and not in a separate profile document. Fortunately, we have an opportunity to fix this in IKEv1, and Francis Dupont stated that if we didn't incorporate the revised-identity proposal, that taking text from pki-profile-01 would be a requirement. Hence, our sumary of the discussion on this issue pointed out what we believe are the alternatives facing the working group: #1) adopting text from the revised-idendity I-D and including it into the ikev2 I-D #2) adopting text from the pki-profile I-D and including it into ikev2 I-D I am in agreement with you in that I wish there had been more discussion on both proposals. Howeer, neither I-D is new, and to my knowledge no one has shown substantive, show-stopping technical problems with either text. They have tradeoffs, to be sure, and indeed the dispute seems to center around preferences towards one engineering tradeoff versus the other. But one way or another, we need to decide. - Ted From owner-ipsec@lists.tislabs.com Wed Feb 12 13:32:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLWGd07072; Wed, 12 Feb 2003 13:32:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00383 Wed, 12 Feb 2003 15:53:14 -0500 (EST) Message-Id: <200302122055.h1CKtmWH002978@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-reply-to: Your message of "Wed, 12 Feb 2003 12:27:00 +0100." <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Feb 2003 15:55:48 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Francis" == Francis Dupont writes: mcr> because there are multiple implementations out there that can't mcr> even cope with importing or exporting even a self-signed mcr> certificate (or making it so hard nobody bothers), I really do mcr> not think that we need any more esoteric situations. Francis> => I can't parse your conclusion: do you support or not the Francis> revised identity proposal for IKEv2? I support: http://www.sandelman.ca/ipsec/2002/12/msg00250.html I specifically am not interesting in tilting at the wind "what if" for certificate retrival. I.e. the problems that Eric described. I'm sure that they are real problems. They are just so far away from where we are now, that I do not think that we can engineer a proper solution to them. Francis> => IMHO a large part of the issue comes from the network access Francis> control (the AAA) done by IKE when IKE has no native interface Francis> with an AAA system. The PKI stuff should be integrated with Francis> legacy authentication in order to provide a native AAA interface Francis> in charge of the strong authentication with authorization and Francis> accounting as goodies... An IKE gateway can talk AAA, or radius, or COPS, or whatever it likes. We suffer greatly because there are vendors who think that they can read one document and implement an entire solution to a wide set of problems. Actually, I doubt any of the real problem ones are still in business :-) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkq00oqHRg3pndX9AQFFXQQA1LnbIGB6var2FJ7C3OiuCIEBCbpEMZpa ciBJz8/M2mRX979uxjvT7IMLrUZP1PZPK6dCef2NcbDrJOq5xPeENTyfqdBrIayI pT3xqXGFdspOz9EwQ22QxDqlpVuXOyeNCyb6KcqG8FNNT4IzXSPrJlTJUnR97EUL uXLgTU2OOig= =hCWI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 12 13:32:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CLWGd07079; Wed, 12 Feb 2003 13:32:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00389 Wed, 12 Feb 2003 15:59:18 -0500 (EST) Message-Id: <200302122101.h1CL1JNM003124@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-reply-to: Your message of "12 Feb 2003 07:22:10 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Feb 2003 16:01:18 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Eric" == Eric Rescorla writes: Eric> Michael Richardson writes: >> That's really not a problem for IKE. If the right goop isn't there, >> you loose. Eric> Uh, then why bother having caching at all? If you're going to have Eric> caching you have to have cache invalidation. Don't all these fancy certificates come with expiry dates? Maybe the HTTP URL access mechanism means to do: s/(.*)\.cert$/\1.crl$/ and that's where you find the crl. I don't know. I punt to pkix to decide what the "URL" means. I think that there are documents now that tell me how to get stuff via HTTP, right? >> That's why we want to just send the URL (or URN if you want) where the >> certificate, whatever chain you need, and maybe the CRL, can be found. Eric> And if the implementation can't do HTTP you're completely SOL--or Eric> rather you have to send the whole chain over UDP, which is what you Eric> say you're trying to avoid. No, if the implementation can't do HTTP, then I buy another implementation, or I preconfigure the appropriate chain, or I simplify the trust model. The problem that people doing certificates keep running into is that they keep thinking that they are building the "global PKI" and run into how do two random people communicate securely, even though there isn't a global PKI. This is why you say things like this - you assume that the two parties are random people and don't have any clue about each other's situation. So far, there isn't anyone that wants to do this kind of thing that is using pkix certificates. 90% of deployed certificate based VPNs are inside a single enterprise. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkq2HYqHRg3pndX9AQH77QP/bli4+FYhmJHuDUzJduT2e8vfTfS7vt8K lIwWpTfWYnrPc38KNi0Duh22Wi7nwoSmNaCxRAqtz5misXvJhCGXOyeTJE2s591+ KHSVfA+KPKGzIBVbbeP7ddfBLTzgGwDxVCjGuFUsrSIhL1vHL7PtoLMVyMelPKhm tRL9Z94qNTE= =bVXd -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 12 14:38:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CMcpd08830; Wed, 12 Feb 2003 14:38:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00566 Wed, 12 Feb 2003 17:07:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Feb 2003 14:07:30 -0800 To: smb@att.com, jis@mit.edu From: Barbara Fraser Subject: Ready for IETF Last Call draft-ietf-ipsec-dpd-01.txt Cc: ipsec@lists.tislabs.com, "Geoffrey Huang" , byfraser@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Jeff, The I-D draft-ietf-ipsec-dpd-01.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call for informational RFC. thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Wed Feb 12 15:28:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CNStd10377; Wed, 12 Feb 2003 15:28:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00711 Wed, 12 Feb 2003 18:04:18 -0500 (EST) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: <200302122101.h1CL1JNM003124@marajade.sandelman.ottawa.on.ca> Reply-To: EKR From: Eric Rescorla Date: 12 Feb 2003 15:11:54 -0800 In-Reply-To: <200302122101.h1CL1JNM003124@marajade.sandelman.ottawa.on.ca> Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > >>>>> "Eric" == Eric Rescorla writes: > Eric> Michael Richardson writes: > >> That's really not a problem for IKE. If the right goop isn't there, > >> you loose. > > Eric> Uh, then why bother having caching at all? If you're going to have > Eric> caching you have to have cache invalidation. > > Don't all these fancy certificates come with expiry dates? Not all rollovers or reconfigurations happen on expiry dates. > >> That's why we want to just send the URL (or URN if you want) where the > >> certificate, whatever chain you need, and maybe the CRL, can be found. > > Eric> And if the implementation can't do HTTP you're completely SOL--or > Eric> rather you have to send the whole chain over UDP, which is what you > Eric> say you're trying to avoid. > > No, if the implementation can't do HTTP, then I buy another implementation, > or I preconfigure the appropriate chain, or I simplify the trust model. Why not just get the design right in the first place?: > The problem that people doing certificates keep running into is that they > keep thinking that they are building the "global PKI" and run into how do > two random people communicate securely, even though there isn't a global PKI. > > This is why you say things like this - you assume that the two parties are > random people and don't have any clue about each other's situation. So far, > there isn't anyone that wants to do this kind of thing that is using pkix > certificates. This works just fine with TLS. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Feb 12 15:37:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CNbKd10552; Wed, 12 Feb 2003 15:37:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00739 Wed, 12 Feb 2003 18:12:21 -0500 (EST) To: "Theodore Ts'o" Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: <20030212152743.GH8238@think.thunk.org> Reply-To: EKR From: Eric Rescorla Date: 12 Feb 2003 15:19:41 -0800 In-Reply-To: <20030212152743.GH8238@think.thunk.org> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" writes: > Hence, our sumary of the discussion on this issue pointed out what we > believe are the alternatives facing the working group: > > #1) adopting text from the revised-idendity I-D and including it into > the ikev2 I-D > > #2) adopting text from the pki-profile I-D and including it into ikev2 I-D Regrettably, I don't think that either of these possibilities is ready for prime time. Although the I-Ds have been out there for a while, neither has seen much review and I'm not convinced that either is finished enough to go to WG last call at this time. If you're a pki-profile guy (which I clearly am), then the obvious thing to do is go ahead with IKEv2 as is and then publish the pki-profile document ASAP (where ASAP is "as soon as the WG really reviews it"). Since it's just a clarification/profile for IKE, this shouldn't be a problem. The other alternative, of course, is to actually let the IKE authors merge one of the proposals into IKE and then give it some time to be reviewed, but this blows your deadline. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Feb 12 15:39:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CNdod10613; Wed, 12 Feb 2003 15:39:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00740 Wed, 12 Feb 2003 18:12:21 -0500 (EST) Message-Id: <200302122314.h1CNEVwj028118@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-Reply-To: Your message of "Wed, 12 Feb 2003 16:01:18 EST." <200302122101.h1CL1JNM003124@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Wed, 12 Feb 2003 18:14:31 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > and that's where you find the crl. I don't know. I punt to pkix to decide > what the "URL" means. I think that there are documents now that tell me > how to get stuff via HTTP, right? Yes, and there's also apparently some way to embed URLs pointing to (multiple) CRL distribution points into certificates. - Bill From owner-ipsec@lists.tislabs.com Wed Feb 12 16:20:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D0KEd11547; Wed, 12 Feb 2003 16:20:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00901 Wed, 12 Feb 2003 18:56:38 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #2: Cipher suites References: Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: 13 Feb 2003 01:58:50 +0200 In-Reply-To: tytso@mit.edu's message of "Sat, 8 Feb 2003 04:24:53 +0000 (UTC)" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk tytso@mit.edu ("Theodore Ts'o") writes: > There seems general consensus over the cipher suites proposed by Paul > Hoffman. However, not fully closed is the question of which ciphers > ought to be mandatory, and which merely optional. There was also proposal to split the suites to IKE and IPsec suites, i.e put all IKE suites to have numbers 0-8191 and IPsec suites from 8192-16383 or similar. Making that split will make the table easier to implement and read. -- 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 Feb 12 18:23:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D2Nld14257; Wed, 12 Feb 2003 18:23:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01241 Wed, 12 Feb 2003 20:54:21 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 References: <200301271515.h0RFFMof029737@givry.rennes.enst-bretagne.fr> Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: 13 Feb 2003 03:57:06 +0200 In-Reply-To: Francis.Dupont@enst-bretagne.fr's message of "Mon, 27 Jan 2003 16:55:49 +0000 (UTC)" Message-ID: Lines: 114 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > 2.1.4 Extensions of the IKEv2 draft > > The first things to fix in the current IKEv2 draft [1] are the > notifications for NAT traversal (NAT-DETECTION-*-IP): > > - They use a hash of the SPIs, address and port, following > a specification for IKEv1. This makes no sense for IKEv2. Why not? The reason they are hashed, is that some users do not want to give out information about the addresses used inside internal net. They might want to give that information out AFTER the authentication (i.e after phase 1 has completed, not during the phase 1), and they may want to give that information out only when using transport mode (there is no need to give the ip address and port out in case of tunnel mode). > - There is no specified way to request the inclusion of > these notifications in messages. In the IKEv1 they were always included if the support for NAT-T was detected by vendor-IDs, in IKEv2 I would say we MUST always include them. > 2.2 NAT traversal requirements > > - When there are several VPN clients behind a NAT, the ability to > request a three way handshake (a.k.a. a return routability > check) is needed [6]. three way handshake does not really help here nor is it needed. It will make the attackers job little bit harder, but if the attacker can modify the packets on the wire, he can also redirect and modify the packets used by the three way handshake. The reason for that is that there is no way we can authenticate the outer address of the NAT, and no matter how many packets we send it will not help there. > 3.4 Implicit address update > > For address update, there is a choice between implicit and > explicit mechanisms for IPsec SAs and IKE SAs. > > We claim that the implicit mechanism for IPsec SAs is far too > unsecure: this mechanism is very (too?) simple. When a packet is > received from another address, the peer addresses of the IPsec SA > pair are updated. This opens the door to easy denial of service > attacks and assumes extra-processing by the receiver device. Note, that the attacker needs to continue attacking before he can gain anything. If he only modifies one packet the correct address will be updated back when the next packet is sent. I.e for the attacker to cause denial of service attack he needs to along the path and modify every single packet going on one direction. In most cases if he can do that he can also remove all the packets and that is much easier denial of service attack, than modifying the packets. > For the implicit mechanism for IKE SAs the things are even > simpler. The implicit mechanism is mainly activated by keepalive > exchanges: to switch from the implicit mechanism to the explicit > one, only an update notification has to be included. The real > difference is in the explicit case an observed peer address change > is only a trigger. And the attacker can still take the explicit return routability test packet and forward it to proper place and finish the 3 way handshake to get the same attack. Again he needs to stay in the path and he needs to do some extra work, but I don't really think that will be that much harder to do. > 3.5 Explicit address update > The explicit mechanism MUST be used. A new notification has to > be defined. We propose to copy it from the delete notification. I disagree. > When the receiver of an update request has to check the validity > of the new peer address, it MAY use a return routability check > sending an informational request at the new address and waiting > for an answer. As informational exchanges are protected no more is > needed. No, informational exchanges are not protected, because the IP address of the packet are not protected, thus this does not protect anything. > Example of a return routability check: > > I --- address update request --> R > I <-- informational RR request - R > I --- informational RR reply --> R > now the responder knows the initiator should be where it said. > I <--- address update reply ---- R And the attack against this is that the attacker takes the informational RR request from the point it was going and sends it to the I, and then it will modify the reply by the I to have the ip address where the original RR request was going. > 4. Security Considerations ... > The second (a.k.a. the return routability check) works only with at > least three messages, i.e., for the initial exchange (with the > address stability requirement) and for the explicit optional > checks. IMHO these checks SHOULD be required by default. As those checks are easy to spoof also, they do not really offer any more protection. Instead of modifying 1 packet, we need to modify 3. -- 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 Feb 12 18:33:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D2X3d14398; Wed, 12 Feb 2003 18:33:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01346 Wed, 12 Feb 2003 21:11:01 -0500 (EST) Message-ID: <3E4A8C08.984985BC@airespace.com> Date: Wed, 12 Feb 2003 10:01:44 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: Van Aken Dirk , ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: <421CB3B9B2D2F645B548D213C0A90E5501168A6C@TMM_EDGMSMSG01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2003 18:03:33.0852 (UTC) FILETIME=[0ECB49C0:01C2D2C1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > > Similarly, I see nothing wrong with ModeCfg just configuring the IP > Address, and then using DHCP to obtain all the other configuration > once the network is up. Indeed, modecfg could even provide the dhcp > address ;) > I have come to think that this probably represents the best solution. If the Cfg payload provides the same parameters as IPCP does, then configuration can proceed similarly to other remote access mechanisms. And as Darren pointed out, the remote client can talk directly to the DHCP server. This obviates the need for dhcp relay on the sgw, though if Derek isn't alone in desiring the same IP address inside and outside, then there must be some coordination between IKE and the DHCP server (e.g. dhcp proxy), or else there will be ease of use and scalability issues. I think there is something to be said for approximating the functionality of existing remote access configuration models (e.g. ppp/l2tp). Scott From owner-ipsec@lists.tislabs.com Wed Feb 12 18:33:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D2Xpd14429; Wed, 12 Feb 2003 18:33:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01393 Wed, 12 Feb 2003 21:11:17 -0500 (EST) To: Van Aken Dirk Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" From: "Derek Atkins" Subject: Re: Modefg considered harmful References: <421CB3B9B2D2F645B548D213C0A90E5501168A6C@TMM_EDGMSMSG01> Date: 12 Feb 2003 12:32:42 -0500 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5501168A6C@TMM_EDGMSMSG01> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Van Aken Dirk writes: > Hi Dereck ;-) Close, but no cigar. Try agian.. > BTW, after 20 years of BOOTP/DHCP new options are still being defined due to > the ever changing network environment. Why would this not be the case for > IKEModeCfg ? I'm not necessarily arguing for IKEModeCfg. I'm arguing that IKE needs to be involved in the configuration process. I have no qualms with tunelling DHCP via IKE. I.e., the IKE daemon on the road-warrior has a DHCP client, and the IKE daemon the gateway has a DHCP server or relay, and the DHCP messages are forwarded under the protection of the IKE phase-1. I'm just saying that you SHOULD NOT create an ESP tunnel for DHCP and then just use the results, because there is no binding of the IKE Phase-1 address to the results of the DHCP. The one argument I have heard about why ModeCfg is better is that it is bounded. Necessarily because it is only negotiating an IP address it can always complete in two messages. Can you guarantee that DHCP will always complete in two messages? in four? Similarly, I see nothing wrong with ModeCfg just configuring the IP Address, and then using DHCP to obtain all the other configuration once the network is up. Indeed, modecfg could even provide the dhcp address ;) -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 12 18:47:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D2lad14709; Wed, 12 Feb 2003 18:47:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01544 Wed, 12 Feb 2003 21:24:56 -0500 (EST) Date: Wed, 12 Feb 2003 14:36:51 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-Reply-To: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> Message-ID: References: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The revised identity can solve the problem of defining what the ID actually is and when not to send certificates. However, having read the draft it is in my opinion clear that same features can be accomplished without introducing new payloads, but using the Certificate Request (CR) payload, and revising the specification for this payload. The name Certificate Request payload already implies or could be made to imply that if sent, a certificate is requested, otherwise not. Some scenarios (-> initiator, <- responder): - I don't have remote cert -> send CR with the CA <- send cert - I don't have remote cert and I don't know the CA (or don't care, ie. I just want to get your cert) -> send empty CR, indicating send all certs, any cert, or what ever cert you are about to use with me <- send all, any or local policy dictated cert - I have a cert for remote -> do not send CR at all <- do not send cert It would be nice to be able to say that "I have _this_ cert cached, is that ok?". This could be done with CR payload as well, if it is revised so that it can include the subject (or hash) of an end entity cert (by adding new encoding type). If it matches no cert is sent back, otherwise local policy can rule, which then tells that cert cache must be updated. What is nice about revised identity draft (as opposed to pki-profile) is that it allows the use of URL to tell where the cert is available. This too could be done by revising the Certificate payload by adding new encoding types (like URL) if this feature is really needed. All this would require revising the specs for CR payload handling, and addition of new Certificate Encoding types. The benefits is that no new payloads are introduced, the use of CR payload is made explicit, new encoding types are easy to add, and the verification of whether the cached cert is correct or not can be done. Whether or not changing/adding this sort of thing would be acceptable, I don't know. :) Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Wed Feb 12 18:53:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D2rHd14836; Wed, 12 Feb 2003 18:53:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01633 Wed, 12 Feb 2003 21:28:35 -0500 (EST) Reply-To: From: "Greg Carter" To: Subject: RE: IKEV2: Issue #4 Revised Identity Date: Wed, 12 Feb 2003 10:50:04 -0500 Message-ID: <003d01c2d2ae$69d78670$1e02a8c0@entrust.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Nope, nothing in the document says that. You can cache any certs you >know about from any means, such as from people who sent them to you >in IKE. Yeah but the only way for it to be useful is if you support URL retrieval. If the only way I can obtain a certificate is in band IKE but I say I support URL retrieval (the only way to get the hash) and therefore you send me a URL how do I get your certificate? Does this mean that you propose that I first send an IDAccept of URL then if I can't find it in the cache then fail IKE, and retry with an IDAccept of Certificate? Otherwise I don't see how to get around the start-up problem. >> Further the only way to prevent IKE UDP packet >>fragmentation is via out of band certificate/chain retrieval (http)? >Nope, nothing in the document says this either. The only way to Yeah I know nothing in the document says that, in fact there is no mention of UDP fragmentation in the document at all. >>Problems with the Revised Identity proposal: >> - mandates HTTP to retrieve the certificate. What about the rest of the >>chain (intermediate CAs and CRLs)? Ideally you would allow either LDAP or >>HTTP. >Ideally for whom? That is certainly not ideal for IPsec implementers. So here we are defining mechanisms for X.509 and you don't even want to consider the optional use of a DIRECTORY for retrieval of certificate information. Great. So instead you'll dupe IPSec vendors into believing that if they implement HTTP that they will magically have everything they need to do certificate validation. This would only work for rather simple certificate chain validation (or handing it off to some as of yet not defined certificate validation server). I don't know of any CA that will publish a cert chain bundle to an HTTP server, however I have been lead to believe that LDAP client code is in a fair amount of router code. >>deleted crl stuff >See above. I don't follow. If you are going to spec out a solution for X.509 you can't ignore CRLs. I haven't seen any discussion on this list. >> - Certificate bundling - The end of section 3.1 implies that a certificate >>bundle will contain end entity certificates with different IDs (CAs?). How >>am I supposed to know which certificate to use (look in the ID payload >>haha)? >The ID payload wouldn't help you there, obviously. You parse the Hence the haha, since your proposal does away with it in its current form. >certificates looking for CAs you trust. If multiple certs match, you >parse them for IDs that you trust. Done. But that would mean multiple queries to a policy database looking for a match. With the IKEv1 style you explicitly have an ID (in the ID Payload) which to match on. With your method you would have to look for matches in your policy db for each ID in a certificate, and then possibly do that for multiple certificates. Yes I know you said that the implementer is free to chose which ever ID they want to then use in the certificate, but I fail to see how this helps interoperability. If I choose to only accept DNs, and you choose to only accept DNS (in the subjectAltName) as "ID" how do we interoperate? In the current scheme an implementation would have to accept any of the ID types as input to the policy engine, so theoretically you could at least configure my DN as acceptable. >Spoken like a true PKI vendor. :-) Actually I have no affiliation. >>IKEv2 referencing the profile draft. Putting aside IETF protocol, >Er, this is a WG in the IETF. We don't get to "put aside IETF protocol". Yeah when logic and reason fail... >...and thereby screwing all the vendors who implemented IKEv1 in good >faith, following what little it said and making guesses about the >rest. The IETF has rules about not doing that. >From the DOI: "When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange." Yes it didn't hand hold the implementer of how to actually do the mapping, they would have had to pick up a copy of the PKIX or X.509 specs to find where to look for IDs (with only two places, the DN or subjectAltName). At every bakeoff from about Sept '97 I had a CA there with instructions on how to put IPSec ID information in a certificate, I also had a free test site up at http://freecerts.entrust.com/vpncerts/certreq.htm (even appears to still work, damn) which I sent emails to the IPSec list altering any implementers to. And even you pointed out a 'problem' as early as 1999 to the list (and I replied). So if they implemented in good faith they missed a lot of opportunities to get it right. For the sake of argument I'll even concede my point and agree that it was possible to get it wrong if implemented in good faith. However I do not see how the profile draft will punish those people who got it wrong. Yes they will have to fix it, but by doing so they end up with an implementation that is secure and interoperable, that doesn't sound like screwing anyone to me. Greg From owner-ipsec@lists.tislabs.com Wed Feb 12 19:00:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D30jd14984; Wed, 12 Feb 2003 19:00:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01831 Wed, 12 Feb 2003 21:39:16 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <20030212152743.GH8238@think.thunk.org> 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: Wed, 12 Feb 2003 18:36:48 -0800 To: EKR , "Theodore Ts'o" From: Paul Hoffman / VPNC Subject: Re: IKEV2: Issue #4 Revised Identity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:19 PM -0800 2/12/03, Eric Rescorla wrote: >"Theodore Ts'o" writes: >> Hence, our sumary of the discussion on this issue pointed out what we >> believe are the alternatives facing the working group: >> >> #1) adopting text from the revised-idendity I-D and including it into >> the ikev2 I-D >> >> #2) adopting text from the pki-profile I-D and including it into ikev2 I-D > >Regrettably, I don't think that either of these possibilities is >ready for prime time. Although the I-Ds have been out there for >a while, neither has seen much review and I'm not convinced that >either is finished enough to go to WG last call at this time. Fully agree. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 12 19:01:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D31Wd15017; Wed, 12 Feb 2003 19:01:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01847 Wed, 12 Feb 2003 21:40:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.com> References: <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.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: Wed, 12 Feb 2003 18:42:01 -0800 To: Barbara Fraser , smb@att.com, jis@mit.edu From: Paul Hoffman / VPNC Subject: Re: Ready for IETF Last Call draft-ietf-ipsec-dpd-01.txt Cc: ipsec@lists.tislabs.com, "Geoffrey Huang" , byfraser@cisco.com, tytso@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:07 PM -0800 2/12/03, Barbara Fraser wrote: >Hi Steve, Jeff, > > The I-D draft-ietf-ipsec-dpd-01.txt has been through >working group last call, and with no comments against it, it is ready to >go to IETF last call for informational RFC. There was a set of useful comments on the list from Hilarie Orman, and a response on the list from the draft's author that he will make changes based on those comments. Maybe the ADs will want to wait for the revised draft (-02) before going to the IETF last call. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 12 20:16:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D4G5d16843; Wed, 12 Feb 2003 20:16:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02697 Wed, 12 Feb 2003 22:51:11 -0500 (EST) To: Pekka Riikonen Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> Reply-To: EKR From: Eric Rescorla Date: 12 Feb 2003 19:59:05 -0800 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pekka Riikonen writes: > All this would require revising the specs for CR payload handling, and > addition of new Certificate Encoding types. The benefits is that no new > payloads are introduced, the use of CR payload is made explicit, new > encoding types are easy to add, and the verification of whether the cached > cert is correct or not can be done. Whether or not changing/adding this > sort of thing would be acceptable, I don't know. :) I think this is a good idea. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu Feb 13 00:08:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D88Yd03386; Thu, 13 Feb 2003 00:08:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04925 Thu, 13 Feb 2003 02:29:32 -0500 (EST) Date: Thu, 13 Feb 2003 08:31:59 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Feb 2003, Theodore Ts'o wrote: : > The revised identity can solve the problem of defining what the ID : > actually is and when not to send certificates. : : Well, the revised identity draft does solve the problem, essentially : be eliminating the ID and CERT payloads altogether, conflating the : IKEv1 concept of identity and certificate, and instead always : requiring both sides to send a certificate, which *is* the identity. : The revised identity draft effectively creates same payloads but named differently. We already have those but only their definition has been sloppy. It would seem simple to just fix where we have gone wrong instead of replacing them. I know what I wrote is much the same pki-profile has, except for the specific points I tried to make: : 3.3.8.1. Specifying Certificate Authorities : Upon receipt of a CERTREQ where the Certificate Type is either "X.509 : Certificate - Signature" or "X.509 Certificate - Key Exchange", : 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. Imple- : mentations MAY send other certificates from the chain. : : The IKEv1 interoperability problems arose because IKEv1 underspecified : how the payloads should be used. : If the CA in CR is wrong, then it's probable that implementation will not reply with any cert. If you have never connected with remote, don't know who it trusts, and only thing you want is to just probe (or connect opportunisticly) to get the remote's cert so that you can make the decision whether you trust it or not (say, ask it from user), would not work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty CR. For IKEv1 we agreed several times over the years that receiving empty CR means sending all your local certs, or what ever your local policy happens to dictate. This is very good since it allows to get remote's certificate regardless whether or not you know who it trusts, but the problem was that it was never written down anywhere. I'd like very much to see the MUST NOT lifted from IKEv2 and specify that if empty CR is received the receiver SHOULD send local cert(s). The section 3.3.8.2 in pki-profile "maybe or maybe not" allows this with "non-conformant" implementations. I think it should be either it's not allowed or it's allowed and it's correct behavior. Now it's like, "ok, you can't really do this, but, hey if you do it work with it anyway"... The second point was the ability to check whether cached cert is correct or not. This is very simple to do just by allowing the CR payload (by adding new cert encoding type) to have the cert information (subject, hash, what ever) in the CR data. OTOH, same feature could work with revised identity draft too (in either TrustedRoot or IDAccepted)... Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Feb 13 09:14:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHEZd14905; Thu, 13 Feb 2003 09:14:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09902 Thu, 13 Feb 2003 11:37:27 -0500 (EST) Message-ID: <3E4BCA40.6202A85E@alcatel.be> Date: Thu, 13 Feb 2003 17:39:28 +0100 From: jeremy.de_clercq@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: derek@ihtfp.com, vanakend@thmulti.com CC: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/13/2003 17:39:29, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/13/2003 17:39:38, Serialize complete at 02/13/2003 17:39:38 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, Dirk, all, jumping in on an earlier comment: > A client connects to a gateway but doesn't agree on an IP Address. > The client then says "ok, I'm 1.2.3.4". The IPsec gateway has no way > to know that this client is authorized to use 1.2.3.4 -- it's just > trusting the client, which is bad. Think PPVPN! If my company and > your company share a VPN node, I could gain access to your vpn this > way. In a scenario where sites are allowed to connect to the PPVPN using an IPsec tunnel with the PE (which serves different VPNs), the SP's PE would need to be pre-configured with the necessary information to authenticate connecting sites as belonging to a specific PPVPN (I don't believe it to be related with the customer's private addresses). Once the (dynamically established IPsec) virtual interface (virtual interfaces are really what's needed in the PPVPN context) is mapped to a specific Virtual Router (or VRF in BGP/MPLS VPNs), from a customer transparency requirement point of view, using DHCP for both IP address assignment and for the other configuration information assignment looks like the preferred approach. I believe it to be more transparant (e.g. inter-working with a DHCP infrastructure), in-line with PPVPN's use of virtual interfaces and more easily extensible; I therefore support the requests as formulated by Bernard Aboba and Dirk Van Aken to include the RFC3456 approach in IKEv2. One way forward could be to list both solutions and clearly describe their applicability. Jeremy De Clercq. From owner-ipsec@lists.tislabs.com Thu Feb 13 10:37:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DIbQd19960; Thu, 13 Feb 2003 10:37:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10706 Thu, 13 Feb 2003 13:04:32 -0500 (EST) Message-Id: <200302131805.h1DI57of000461@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-reply-to: Your message of 13 Feb 2003 03:57:06 +0200. Date: Thu, 13 Feb 2003 19:05:07 +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: Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes: > 2.1.4 Extensions of the IKEv2 draft > > The first things to fix in the current IKEv2 draft [1] are the > notifications for NAT traversal (NAT-DETECTION-*-IP): > > - They use a hash of the SPIs, address and port, following > a specification for IKEv1. This makes no sense for IKEv2. Why not? The reason they are hashed, is that some users do not want to give out information about the addresses used inside internal net. They might want to give that information out AFTER the authentication (i.e after phase 1 has completed, not during the phase 1), and they may want to give that information out only when using transport mode (there is no need to give the ip address and port out in case of tunnel mode). => I don't buy this argument because it implies there is a known NAT on the path. In this case any address which cannot be the address seen by the other peer does the job. Same for the port (even I can't find a reason to keep the port secret). > - There is no specified way to request the inclusion of > these notifications in messages. In the IKEv1 they were always included if the support for NAT-T was detected by vendor-IDs, in IKEv2 I would say we MUST always include them. => I don't know if we can reach a consensus about this in an IPv6 context (where there should be no NATs :-)... > 2.2 NAT traversal requirements > > - When there are several VPN clients behind a NAT, the ability to > request a three way handshake (a.k.a. a return routability > check) is needed [6]. three way handshake does not really help here nor is it needed. It will make the attackers job little bit harder, but if the attacker can modify the packets on the wire, he can also redirect and modify the packets used by the three way handshake. The reason for that is that there is no way we can authenticate the outer address of the NAT, and no matter how many packets we send it will not help there. => the purpose of the RR check is mainly operational according to Jayant Shukla. There are other cases where an RR check improves a bit the security, as it is cheap IMHO we should keep a way to perform it. > 3.4 Implicit address update > > For address update, there is a choice between implicit and > explicit mechanisms for IPsec SAs and IKE SAs. > > We claim that the implicit mechanism for IPsec SAs is far too > unsecure: this mechanism is very (too?) simple. When a packet is > received from another address, the peer addresses of the IPsec SA > pair are updated. This opens the door to easy denial of service > attacks and assumes extra-processing by the receiver device. Note, that the attacker needs to continue attacking before he can gain anything. If he only modifies one packet the correct address will be updated back when the next packet is sent. I.e for the attacker to cause denial of service attack he needs to along the path and modify every single packet going on one direction. => no, you forgot the reverse way (the other SA of the pair) which is updated too. In most cases if he can do that he can also remove all the packets and that is much easier denial of service attack, than modifying the packets. => your argument assumes the routing is symmetrical. If it is not an attacker on one path can mess the reverse path. > For the implicit mechanism for IKE SAs the things are even > simpler. The implicit mechanism is mainly activated by keepalive > exchanges: to switch from the implicit mechanism to the explicit > one, only an update notification has to be included. The real > difference is in the explicit case an observed peer address change > is only a trigger. And the attacker can still take the explicit return routability test packet and forward it to proper place and finish the 3 way handshake to get the same attack. Again he needs to stay in the path and he needs to do some extra work, but I don't really think that will be that much harder to do. => this attack works *only* when the NAT traversal feature is enabled (and I argued that in this case you have near no defense, look at draft-dupont-transient-pseudonat-01.txt). For mobility or multihoming any peer address modification en route is easily detected by peer address notification. > 3.5 Explicit address update > The explicit mechanism MUST be used. A new notification has to > be defined. We propose to copy it from the delete notification. I disagree. => about the idea of an explicit mechanism itself or about the details? > When the receiver of an update request has to check the validity > of the new peer address, it MAY use a return routability check > sending an informational request at the new address and waiting > for an answer. As informational exchanges are protected no more is > needed. No, informational exchanges are not protected, because the IP address of the packet are not protected, thus this does not protect anything. => the peer addresses are protected by the peer address notification when the NAT traversal feature is disable (see a previous answer). > Example of a return routability check: > > I --- address update request --> R > I <-- informational RR request - R > I --- informational RR reply --> R > now the responder knows the initiator should be where it said. > I <--- address update reply ---- R And the attack against this is that the attacker takes the informational RR request from the point it was going and sends it to the I, and then it will modify the reply by the I to have the ip address where the original RR request was going. => idem. I never pretended to have a solution to the NAT traversal feature intrinsic security flaw. Thanks for many examples of it (:-). Now, if the NAT traversal feature is disabled, do you believe there are remaining new security threats? > 4. Security Considerations ... > The second (a.k.a. the return routability check) works only with at > least three messages, i.e., for the initial exchange (with the > address stability requirement) and for the explicit optional > checks. IMHO these checks SHOULD be required by default. As those checks are easy to spoof also, they do not really offer any more protection. Instead of modifying 1 packet, we need to modify 3. => I agree the RR check provides only weak security (please don't forward this to the mobile-ip WG list :-). But without it in the mobility or multihoming cases, we can only trust your peer... With it, you can catch some config errors and the attack has to be an active one. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Feb 13 11:25:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJPSd21606; Thu, 13 Feb 2003 11:25:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11239 Thu, 13 Feb 2003 13:59:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030213071815.02ed0550@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Feb 2003 07:22:19 -0800 To: Paul Hoffman / VPNC From: Barbara Fraser Subject: Re: Ready for IETF Last Call draft-ietf-ipsec-dpd-01.txt Cc: smb@att.com, jis@mit.edu, ipsec@lists.tislabs.com, "Geoffrey Huang" , tytso@mit.edu In-Reply-To: References: <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.com> <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_40554233==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_40554233==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Paul, Yup. Geoff already reminded us of this mistake. He's going to address the comments and then we'll submit for the last call. thanks, Barb At 06:42 PM 2/12/2003, Paul Hoffman / VPNC wrote: >At 2:07 PM -0800 2/12/03, Barbara Fraser wrote: >>Hi Steve, Jeff, >> >> The I-D draft-ietf-ipsec-dpd-01.txt has been through >>working group last call, and with no comments against it, it is ready to >>go to IETF last call for informational RFC. > >There was a set of useful comments on the list from Hilarie Orman, and a >response on the list from the draft's author that he will make changes >based on those comments. Maybe the ADs will want to wait for the revised >draft (-02) before going to the IETF last call. > >--Paul Hoffman, Director >--VPN Consortium --=====================_40554233==_.ALT Content-Type: text/html; charset="us-ascii" Hi Paul,

Yup. Geoff already reminded us of this mistake. He's going to address the comments and then we'll submit for the last call.

thanks,
Barb

At 06:42 PM 2/12/2003, Paul Hoffman / VPNC wrote:
At 2:07 PM -0800 2/12/03, Barbara Fraser wrote:
Hi Steve, Jeff,

        The I-D draft-ietf-ipsec-dpd-01.txt has been through
working group last call, and with no comments against it, it is ready to
go to IETF last call for informational RFC.

There was a set of useful comments on the list from Hilarie Orman, and a response on the list from the draft's author that he will make changes based on those comments. Maybe the ADs will want to wait for the revised draft (-02) before going to the IETF last call.

--Paul Hoffman, Director
--VPN Consortium
--=====================_40554233==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Feb 13 11:25:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJPVd21619; Thu, 13 Feb 2003 11:25:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11242 Thu, 13 Feb 2003 13:59:30 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity References: Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: 13 Feb 2003 02:29:14 +0200 In-Reply-To: ekr@rtfm.com's message of "Wed, 12 Feb 2003 16:10:34 +0000 (UTC)" Message-ID: Lines: 37 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ekr@rtfm.com (Eric Rescorla) writes: > > That's why we want to just send the URL (or URN if you want) where the > > certificate, whatever chain you need, and maybe the CRL, can be > > found. > And if the implementation can't do HTTP you're completely SOL--or > rather you have to send the whole chain over UDP, which is > what you say you're trying to avoid. For the client / remote access case you do following: If you have certificate for the other end you ask only the hash and url of the certificate from the other end. If you do not have certificate for the other end then you request either PKIX certificate or certificate bundle. If the other end replies to your hash + URL request with hash that you do not have in your cache (for example the key of the other end has changed), you remove (or mark the key to be old) the old key from the cache and restart (i.e start over and then you notice that you do not have key for the other end and request full certificate). When you receive PKIX certificate or bundle from the other end you store that certificate to your cache and associate it with the gateway, so you know next time that you have key for that site. The gateway side normally will have connection to the internet and can use http, thus it can always request hash + URL and cache the certificates it fetches using http. > It's my view that part of REASON that so many implementations run shared > secrets is that IKE certificate handling is so screwed up. And thats why we should fix it and take the text from the revised-identity draft. -- 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 Feb 13 11:26:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJQ2d21647; Thu, 13 Feb 2003 11:26:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11262 Thu, 13 Feb 2003 14:00:32 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #2: Cipher suites References: Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: 13 Feb 2003 03:22:56 +0200 In-Reply-To: kivinen@ssh.fi's message of "Thu, 13 Feb 2003 00:41:38 +0000 (UTC)" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk kivinen@ssh.fi (Tero Kivinen) writes: > There was also proposal to split the suites to IKE and IPsec suites, > i.e put all IKE suites to have numbers 0-8191 and IPsec suites from > 8192-16383 or similar. To reply my own comment, I think it would be even better to split those tables completely. The crypto suite numbers should be allocated in two different pools, one for the phase 1 and one for the phase 2. This would remove prolems and errors where someone includes suite for ESP in the phase 1 or IKE suite for child_sa. The parsing of SA payload can be identical but the meaning of the values in the payloads should depend on if it is phase 1 or 2 SA negotiation payload. -- 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 Feb 13 11:26:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJQLd21665; Thu, 13 Feb 2003 11:26:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11259 Thu, 13 Feb 2003 14:00:30 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload References: Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: 13 Feb 2003 02:34:26 +0200 In-Reply-To: tytso@mit.edu's message of "Sat, 8 Feb 2003 04:25:07 +0000 (UTC)" Message-ID: Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk tytso@mit.edu ("Theodore Ts'o") writes: > Hence, we suggest that as a path forward, that the Configuration payload > be left in ikev2-04.txt, and that people who believe that a richer > feature set is necessary should be encouraged to update RFC 3456 for use > with IKEv2 as an alternative mechanism. Since an implementation is I do not really think it is good idea to force everybody to implement both RFC 3456 and configuration payload. The client will need to implement both, because if the server replies with empty CFG_REPLY then it needs to retry with RFC 3456 or similar. > allowed to respond with an empty CFG_REPLY packet, this should not prove > to be an onerous implementation burden for those who are determined to > only support DHCP 3456-style configuration. While this could > potentially cause interoperability problems, the fact that most deployed > implementations already support modecfg suggests that for the simple > (common?) case where only a single IP address needs to be returned by > the IPSEC gateway, it is extremely likely that most VPN-style > implementations will support the Configuration payload. Allowing two things to do the same thing is bad. How about the mcr's proposal of having dhcp over IKE, i.e take dhcp payload and put it inside the some IKE payload (we can name it to be configuration payload, so the configuration payload people will be happy too, just change the format to follow the dhcp packet). -- 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 Feb 13 11:28:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJSpd21810; Thu, 13 Feb 2003 11:28:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11323 Thu, 13 Feb 2003 14:03:34 -0500 (EST) Date: Wed, 12 Feb 2003 17:20:26 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-Reply-To: <20030212150139.GG8238@think.thunk.org> Message-ID: References: <200302121127.h1CBR0of094935@givry.rennes.enst-bretagne.fr> <20030212150139.GG8238@think.thunk.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Feb 2003, Theodore Ts'o wrote: : > The revised identity can solve the problem of defining what the ID : > actually is and when not to send certificates. : : Well, the revised identity draft does solve the problem, essentially : be eliminating the ID and CERT payloads altogether, conflating the : IKEv1 concept of identity and certificate, and instead always : requiring both sides to send a certificate, which *is* the identity. : The revised identity draft effectively creates same payloads but named differently. We already have those but only their definition has been sloppy. It would seem simple to just fix where we have gone wrong instead of replacing them. I know what I wrote is much the same pki-profile has, except for the specific points I tried to make: : 3.3.8.1. Specifying Certificate Authorities : Upon receipt of a CERTREQ where the Certificate Type is either "X.509 : Certificate - Signature" or "X.509 Certificate - Key Exchange", : 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. Imple- : mentations MAY send other certificates from the chain. : : The IKEv1 interoperability problems arose because IKEv1 underspecified : how the payloads should be used. : If the CA in CR is wrong, then it's probable that implementation will not reply with any cert. If you have never connected with remote, don't know who it trusts, and only thing you want is to just probe (or connect opportunisticly) to get the remote's cert so that you can make the decision whether you trust it or not (say, ask it from user), would not work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty CR. For IKEv1 we agreed several times over the years that receiving empty CR means sending all your local certs, or what ever your local policy happens to dictate. This is very good since it allows to get remote's certificate regardless whether or not you know who it trusts, but the problem was that it was never written down anywhere. I'd like very much to see the MUST NOT lifted from IKEv2 and specify that if empty CR is received the receiver SHOULD send local cert(s). The section 3.3.8.2 in pki-profile "maybe or maybe not" allows this with "non-conformant" implementations. I think it should be either it's not allowed or it's allowed and it's correct behavior. Now it's like, "ok, you can't really do this, but, hey if you do it work with it anyway"... The second point was the ability to check whether cached cert is correct or not. This is very simple to do just by allowing the CR payload (by adding new cert encoding type) to have the cert information (subject, hash, what ever) in the CR data. OTOH, same feature could work with revised identity draft too (in either TrustedRoot or IDAccepted)... Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Feb 13 11:32:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJWCd22214; Thu, 13 Feb 2003 11:32:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11375 Thu, 13 Feb 2003 14:06:34 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A77@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" Subject: RE: Modefg considered harmful Date: Thu, 13 Feb 2003 10:00:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, See my comments below. ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: woensdag 12 februari 2003 18:33 > To: Van Aken Dirk > Cc: ipsec@lists.tislabs.com; Scott G. Kelly > Subject: Re: Modefg considered harmful > > > Van Aken Dirk writes: > > > Hi Dereck ;-) > > Close, but no cigar. Try agian.. > > > BTW, after 20 years of BOOTP/DHCP new options are still > being defined due to > > the ever changing network environment. Why would this not > be the case for > > IKEModeCfg ? > > I'm not necessarily arguing for IKEModeCfg. I'm arguing that IKE > needs to be involved in the configuration process. I can understand your argument in the sense that IKE is doing the authentication of the identity and that somehow we want to bind this identity to an inner IP address. But on the other hand for static configurations this binding is not performed. e.g. Assume two SGW's talking to each other, both proxying for static networks behind them. An IKE phase 1 is set-up, authentication of identity is performed, phase 2 ID's are exchanged and if these match SPD entries, the SA's are established. Spoofing inner IP addresses can easily accomplish in this situation too don't you think ? Why should the road warrior/dynamic IP case be more secure than the SGW/static case ? Of course we should try to achieve the most secure solution however IMHO it might not be the main driver behind protocol choices; I agree that it might influence this kind of choice marginally no ? As an afterthought we are more comfortable with static IP config and somehow we intuitively attribute better security to this and we are even take less precautions in static configurations. > I'm just saying that you SHOULD NOT create an ESP tunnel for DHCP and > then just use the results, because there is no binding of the IKE > Phase-1 address to the results of the DHCP. > > The one argument I have heard about why ModeCfg is better is that it > is bounded. Necessarily because it is only negotiating an IP address > it can always complete in two messages. Can you guarantee that DHCP > will always complete in two messages? in four? I agree with you that as long as communication channels are insecure, a key establishment protocol must use the least amount of messages as possible to arrive at a secure channel. As soon as the channel is secure, I'm less concerned about how many messages are needed for full IP configuration. Again I agree with you that regarding IP address assignment IKEModeCFG is more efficient compared to DHCP. However I took a few traces and was a little bit surprised about the amount of information that is also distributed via IKEModeCfg messages. In the end both protocols might need the same bandwidth. > > Similarly, I see nothing wrong with ModeCfg just configuring the IP > Address, and then using DHCP to obtain all the other configuration > once the network is up. Indeed, modecfg could even provide the dhcp > address ;) I guess there is consensus on this point; great ! So at least let's make the DHCP server attribute in IKEModeCfg as a MUST implement otherwise people cannot rely on it. Thanks - Dirk > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > From owner-ipsec@lists.tislabs.com Thu Feb 13 11:32:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJWCd22216; Thu, 13 Feb 2003 11:32:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11320 Thu, 13 Feb 2003 14:03:33 -0500 (EST) Date: Wed, 12 Feb 2003 20:05:01 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmm.. looks like my email never made it to the list, so let's resend with better luck. ---------- Forwarded message ---------- Date: Wed, 12 Feb 2003 14:36:51 +0100 (CET) From: Pekka Riikonen To: Theodore Ts'o Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity The revised identity can solve the problem of defining what the ID actually is and when not to send certificates. However, having read the draft it is in my opinion clear that same features can be accomplished without introducing new payloads, but using the Certificate Request (CR) payload, and revising the specification for this payload. The name Certificate Request payload already implies or could be made to imply that if sent, a certificate is requested, otherwise not. Some scenarios (-> initiator, <- responder): - I don't have remote cert -> send CR with the CA <- send cert - I don't have remote cert and I don't know the CA (or don't care, ie. I just want to get your cert) -> send empty CR, indicating send all certs, any cert, or what ever cert you are about to use with me <- send all, any or local policy dictated cert - I have a cert for remote -> do not send CR at all <- do not send cert It would be nice to be able to say that "I have _this_ cert cached, is that ok?". This could be done with CR payload as well, if it is revised so that it can include the subject (or hash) of an end entity cert (by adding new encoding type). If it matches no cert is sent back, otherwise local policy can rule, which then tells that cert cache must be updated. What is nice about revised identity draft (as opposed to pki-profile) is that it allows the use of URL to tell where the cert is available. This too could be done by revising the Certificate payload by adding new encoding types (like URL) if this feature is really needed. All this would require revising the specs for CR payload handling, and addition of new Certificate Encoding types. The benefits is that no new payloads are introduced, the use of CR payload is made explicit, new encoding types are easy to add, and the verification of whether the cached cert is correct or not can be done. Whether or not changing/adding this sort of thing would be acceptable, I don't know. :) Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Feb 13 11:38:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJcOd22686; Thu, 13 Feb 2003 11:38:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11437 Thu, 13 Feb 2003 14:11:37 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C8A0@corpmx14.us.dg.com> To: tytso@mit.edu, ipsec@lists.tislabs.com Subject: RE: IKEV2: Issue #2: Cipher suites Date: Thu, 13 Feb 2003 14:12:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It is also the case that IPSEC as applied to for VPN's will have very > radically different cipher requirements than those already expressed > for use by iSCSI. > > For this reason, one potential solution (originally suggested by > Steve Bellovin to the working group chairs) towards achieving closure > on this issue would be to separate out into a separate document --- or > more likely, documents --- the specifications of which ciphers are > mandatory and which are merely optional. Since which ciphers ought to > be mandatory will likely change more frequently than the base document > itself, combined with the need for different profiles for different > applications, we propose that the IKEv2 document remain silent about > which ciphers are required, and that separate documents, for VPN and > iSCSI applications, be drafted that contain these requirements. The "iSCSI" cipher requirements actually apply to all of the IP Storage (ips) protocols (iSCSI, FCIP, iFCP, iSNS). They aren't that radically different from the VPN requirements, and I think that future implementers would benefit from a single requirements document. This would not be that difficult: - 3DES-CBC and HMAC-SHA1 are MUSTs for both IP Storage and VPN. - AES-CBC (w/HMAC-SHA1) is a SHOULD for VPN - AES-CTR and AES-CBC-MAC w/XCBC are SHOULDs for IP Storage - An implementation intended for both VPN and IP Storage SHOULD support all three AES modes (CBC, CTR, CBC MAC w/XCBC). I note that the VPN requirements leave implementations that follow the above SHOULDs exposed to a disastrous (but rather unlikely) weakness discovery in HMAC-SHA1, as there is no alternate integrity algorithm recommendation. I strongly agree with Paul Hoffman's view that a separate requirements document will be easier to update so that things like the current DES and TIGER embarrassments can be avoided in the future. This was one of many reasons why the ips WG found it necessary to extensively re-profile IPsec for our usage - a MUST for DES would only escape the ips WG over my dead body ... Thanks, --David (ips WG co-chair) ---------------------------------------------------- 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 Feb 13 11:56:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DJuDd23560; Thu, 13 Feb 2003 11:56:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11673 Thu, 13 Feb 2003 14:29:01 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C8A1@corpmx14.us.dg.com> To: tytso@mit.edu, ipsec@lists.tislabs.com Subject: IKEv2: Remaining Issues - ECNFIX Date: Thu, 13 Feb 2003 14:29:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In order to meet the challenge set by the Security Area Directors of > finishing working group last call by February 15th, we intend to give > Charlie Kaufman editing directions on Tuesday, February 11th. Hence, > we encourage people to respond to these issues by close of business on > Monday, February 10th. Obviously, minor issues can still be raised > and fixed during the last call period, but we need to set a stake in a > ground and make the major fundamental decisions in the next couple of > days. I apologize for missing the Tuesday deadline due to a death in my family. I believe the current ecnfix draft (draft-ietf-ipsec-ikev2-ecnfix-00.txt) reflects list discussion prior to its submission. Having seen little discussion since then, I propose to remove the open issue text in Section 5.2 of the ecnfix draft and ask that the IKEv2 draft require the ECN behavior specified in the ecnfix draft for all tunnel-mode SAs (including NAT-traversal tunnel-mode but not NAT-traversal transport- mode) negotiated via IKEv2. On a related note, the current IKEv1 DOI does not specify an interoperable default encapsulation mode (transport vs. tunnel) in the absence of negotiation. The description of the IKEv2 USE-TRANSPORT-MODE notify message type in Section 5.10.1 should be extended to say that if that notify message is not present in a request, the resulting SA MUST use tunnel mode in order to avoid a continuation of this situation. 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 Feb 13 12:10:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DKALd25149; Thu, 13 Feb 2003 12:10:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11918 Thu, 13 Feb 2003 14:43:29 -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: <15947.60568.261489.957133@ryijy.hel.fi.ssh.com> Date: Thu, 13 Feb 2003 21:06:00 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-Reply-To: <200302131805.h1DI57of000461@givry.rennes.enst-bretagne.fr> References: <200302131805.h1DI57of000461@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 31 min X-Total-Time: 33 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => I don't buy this argument because it implies there is a known NAT > on the path. In this case any address which cannot be the address > seen by the other peer does the job. Yes, the other end will know there is nat between, but he does not know which address is actually used by the host behind NAT. Some IT-adminstrators want to keep the internal addresses hidden. The example case is when someone is using host behind corporate firewall which also does the NAT for all the addresses, and connects to some known service in the external net (say www.cnn.com). The IT-adminstrator does not want to give out the information about the internal ip-address, to this external machine. They might not want to give out information that this connection is coming from the same host than the previous connection few days earlier (i.e privacy issues). If the ip-address is public or if there is no randomness in it (spi/cookie/nonce or similar) then the other end (www.cnn.com) can track the users behind the corporate firewall because their internal ip-addresses are typically static. > Same for the port (even I can't find a reason to keep the port > secret). For source ports there is no need to keep it secret, and in most cases it will be always same. If the users want to have better privacy protection, they can always use random source port to make the brute force attack harder. The attacker can do brute force attack against hash. I.e take the other stuff and try all possible ip-addresses. As the ip-address space is usually quite small for ipv4 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 == 17891328 hosts) the attacker can break the hash, but it requires active expensive attack against each hash separately. The hashing does not help for attacker who has enough computing power, but it does make passive tracking of users impossible. > In the IKEv1 they were always included if the support for NAT-T was > detected by vendor-IDs, in IKEv2 I would say we MUST always include > them. > => I don't know if we can reach a consensus about this in an IPv6 > context (where there should be no NATs :-)... True, but I think that making the protocol simplier has more value than the cost caused by extra hash in the packet. And I do not know what all kind of 6to4 etc conversions will do for the packets, and I think they will be detected as NATs so having them in the ipv6 space also would help in those cases. I do not know enough about those issues to be sure. > => the purpose of the RR check is mainly operational according > to Jayant Shukla. There are other cases where an RR check improves > a bit the security, as it is cheap IMHO we should keep a way to > perform it. As the IKEv2 peer can always send empty notification to other end assume to get reply back, there is always a way to do it. I.e we do not need to specify anything for it, it is simply a implementation issue (i.e implementation might want to do it, or it might not do it). It does not affect interoperability. > Note, that the attacker needs to continue attacking before he can gain > anything. If he only modifies one packet the correct address will be > updated back when the next packet is sent. I.e for the attacker to > cause denial of service attack he needs to along the path and modify > every single packet going on one direction. > > => no, you forgot the reverse way (the other SA of the pair) which > is updated too. True, but it is updated back immediately when the first non-modified packet is left through to the other end. Also usually if the attacker can modify/remove packets in one direction he can modify/remove packets in the other direction too. > => your argument assumes the routing is symmetrical. If it is not > an attacker on one path can mess the reverse path. I think symmetrical routing is the most common case, and even if it is not, the attacker can send the first packet so that the return routability check packet comes to place where he can reach it. > And the attacker can still take the explicit return routability test > packet and forward it to proper place and finish the 3 way handshake > to get the same attack. Again he needs to stay in the path and he > needs to do some extra work, but I don't really think that will be > that much harder to do. > > => this attack works *only* when the NAT traversal feature is enabled > (and I argued that in this case you have near no defense, look at > draft-dupont-transient-pseudonat-01.txt). For mobility or multihoming > any peer address modification en route is easily detected by peer > address notification. I am only talking about the cases where we have detected NAT, and enabled NAT traversal. The IKEv1 NAT draft tries to be clear that any of these are only done if the other end behind the NAT (i.e if you have client behind NAT and server is directly connected, then only server will update the peer addresses, the client will never do it). > > 3.5 Explicit address update > > The explicit mechanism MUST be used. A new notification has to > > be defined. We propose to copy it from the delete notification. > I disagree. > => about the idea of an explicit mechanism itself or about the details? About the MUST. I think it can be MAY, i.e the implemenation MAY do the return routability check, but in most cases there is no need for it, and it does not offer more protection against denial of service attacks. What the host behind NAT might want to do is to make sure it sends some packets to the other end every now and then, especially if it has not received anything back (i.e if the attacker modified the packet and the other end updated peer address, the client should send some packets every now and then to fix the situation when the attacker stops active attack). > => the peer addresses are protected by the peer address notification > when the NAT traversal feature is disable (see a previous answer). If NAT traversal feature is disabled then I do not think we should ever update the other ends address (execpt for mobile-ip, but I everything I have been saying only handles NAT-T). For mobile-ip this kind of thing is usefull, but we cannot use the same mechanism in the NAT-T, thus I think we should keep them separate. > => idem. I never pretended to have a solution to the NAT traversal > feature intrinsic security flaw. Thanks for many examples of it (:-). > Now, if the NAT traversal feature is disabled, do you believe there > are remaining new security threats? I haven't considered the case without NAT-T, so I cannot say for sure, but I think there explicit return routability check is MUST. -- 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 Feb 13 13:56:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DLuEd27823; Thu, 13 Feb 2003 13:56:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13033 Thu, 13 Feb 2003 16:18:19 -0500 (EST) Date: Thu, 13 Feb 2003 22:20:44 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Brian Korver Cc: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : > opportunisticly) to get the remote's cert so that you can make the : > decision whether you trust it or not (say, ask it from user), would not : > work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty : > CR. : : Could you provide a use case where this is a problem? Let's say that I : know I trust CAs A and B, and I tell you that I trust them by sending : you CERTREQ payloads containing the DNs of these two CAs. If you don't : have a certificate backed by A or B, we have no common ground and I : cannot hope to authenticate you, so IKE fails. Are you thinking : opportunistic IPSec? : One case is opportunistic IPSec, second is use of self-signed certs. Assuming your friend has only a self-signed cert it would be nice to get that cert in IKE so that you could cache it (and verify it, sign it, etc). Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Feb 13 14:27:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DMRTd28552; Thu, 13 Feb 2003 14:27:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13432 Thu, 13 Feb 2003 17:01:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3E483959.5D2D8DF1@airespace.com> References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> Date: Thu, 13 Feb 2003 17:02:37 -0500 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP Cc: BSingh@Nomadix.com, Francis.Dupont@enst-bretagne.fr, 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 3:44 PM -0800 2/10/03, Scott G. Kelly wrote: >BSingh@Nomadix.com wrote: > >> But I guess this is not what RFC2401 says and it leaves it open for various >> implementations to have different SPD methodology.. Can you update me on >> what other ways SPD entries are looked up for tunnel selection.. I am more >> interested in the source address or some source parameter being included as >> the criteria for tunnel selection or an SPD interface that lets me make >> policies based on the source of the packets.. Is it possible? If you can >> guide me there I would really appreciate it.. > >I think RFC2401 is quite explicit about what selectors are used in SPD >lookups. Based on this, the virtual interface approach suffers from (at >least) two problems: first, routing lookups are most specific to least >specific (i.e. "best match"), meaning the administrator may not be able >to strictly control the ordering of SPD elements. Secondly, it does not >support protocol and/or ports as selectors. > >Scott The notion that I've been developing for separating routing from access control in IPsec, and which was discussed among a set of folks interested in overlay nets and PPVPNs, is to make a call to a routing function prior to SPD lookup. The function would return a virtual interface ID (VID) and that can be used to select an SPD if one has a set of SPDs, one per virtual interface. In a very simple context this call always returns the same VID and there is only one SPD. In a more complex environment the function returns meaningfully different results, and one can have multiple SPDs, or one SPD in which the VID is yet another selector (if you want to think of it that way). Steve From owner-ipsec@lists.tislabs.com Thu Feb 13 15:01:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DN1bd29316; Thu, 13 Feb 2003 15:01:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13717 Thu, 13 Feb 2003 17:28:08 -0500 (EST) Message-ID: <3E4C1C33.7FD7F995@airespace.com> Date: Thu, 13 Feb 2003 14:29:07 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: BSingh@Nomadix.com, Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2003 22:31:02.0077 (UTC) FILETIME=[96B1D6D0:01C2D3AF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Comments below... Stephen Kent wrote: > >I think RFC2401 is quite explicit about what selectors are used in SPD > >lookups. Based on this, the virtual interface approach suffers from (at > >least) two problems: first, routing lookups are most specific to least > >specific (i.e. "best match"), meaning the administrator may not be able > >to strictly control the ordering of SPD elements. Secondly, it does not > >support protocol and/or ports as selectors. > > > >Scott > > The notion that I've been developing for separating routing from > access control in IPsec, and which was discussed among a set of folks > interested in overlay nets and PPVPNs, is to make a call to a routing > function prior to SPD lookup. The function would return a virtual > interface ID (VID) and that can be used to select an SPD if one has a > set of SPDs, one per virtual interface. In a very simple context > this call always returns the same VID and there is only one SPD. In a > more complex environment the function returns meaningfully different > results, and one can have multiple SPDs, or one SPD in which the VID > is yet another selector (if you want to think of it that way). > > Steve As a matter of clarification, the "virtual interfaces" I refer to above are also called "tunnel interfaces" in some implementations. I saw some early open source ipsec implementations which used this approach (maybe bsd-based). Basically, a tunnel is established, and then the tunnel is treated as an interface (a virtual interface). There is no SPD/SAD selection, per se; rather, a standard routing lookup determines which interface a packet exits via, and ipsec tunnels have vif entries in the routing table, making them look like "exit interfaces". In such cases, no SPD entries are consulted following the routing lookup, and the routing table (effectively) becomes the SAD/SPD. I think this has obvious issues in terms of satisfying the selector criteria you outlined in RFC2401, for the reasons I enumerated above. I also think this is significantly different than what you are referring to above (the design you are developing), and I think you refer to the same sort of design I described as having implemented in order to support independent, per-interface policies. I hope you didn't think I intended to criticize your approach. On the contrary, I think this model is very powerful. Scott From owner-ipsec@lists.tislabs.com Thu Feb 13 15:19:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DNJCd29630; Thu, 13 Feb 2003 15:19:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14009 Thu, 13 Feb 2003 17:51:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3E4C1C33.7FD7F995@airespace.com> References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> <3E4C1C33.7FD7F995@airespace.com> Date: Thu, 13 Feb 2003 17:48:47 -0500 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP Cc: BSingh@Nomadix.com, Francis.Dupont@enst-bretagne.fr, 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 2:29 PM -0800 2/13/03, Scott G. Kelly wrote: > > >As a matter of clarification, the "virtual interfaces" I refer to above >are also called "tunnel interfaces" in some implementations. I saw some >early open source ipsec implementations which used this approach (maybe >bsd-based). Basically, a tunnel is established, and then the tunnel is >treated as an interface (a virtual interface). There is no SPD/SAD >selection, per se; rather, a standard routing lookup determines which >interface a packet exits via, and ipsec tunnels have vif entries in the >routing table, making them look like "exit interfaces". > >In such cases, no SPD entries are consulted following the routing >lookup, and the routing table (effectively) becomes the SAD/SPD. I think >this has obvious issues in terms of satisfying the selector criteria you >outlined in RFC2401, for the reasons I enumerated above. > >I also think this is significantly different than what you are referring >to above (the design you are developing), and I think you refer to the >same sort of design I described as having implemented in order to >support independent, per-interface policies. I hope you didn't think I >intended to criticize your approach. On the contrary, I think this model >is very powerful. > No problem, Scott. I was catching up on mail and got things out of order. I understand the differences between what you described and what I have suggested. My message was really a clarification for the list, nothing more. Steve From owner-ipsec@lists.tislabs.com Thu Feb 13 19:42:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E3gHd07138; Thu, 13 Feb 2003 19:42:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16162 Thu, 13 Feb 2003 22:12:39 -0500 (EST) To: Van Aken Dirk Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" From: "Derek Atkins" Subject: Re: Modefg considered harmful References: <421CB3B9B2D2F645B548D213C0A90E5501168A77@TMM_EDGMSMSG01> Date: 13 Feb 2003 22:15:10 -0500 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5501168A77@TMM_EDGMSMSG01> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Van Aken Dirk writes: > I can understand your argument in the sense that IKE is doing the > authentication of the identity and that somehow we want to bind this > identity to an inner IP address. But on the other hand for static > configurations this binding is not performed. e.g. Assume two SGW's talking In a static configuration this binding is done statically. For example, you say in your policy: IKE-ID "alice" has address "1.2.3.4", IKE-ID "bob" has addresses "2.3.4.16/28", and so on. When you are statically configured, you still get this binding -- it's just performed, well, statically... > Why should the road warrior/dynamic IP case be more secure than the > SGW/static case ? It's not "more secure". I'm trying to make sure it is "as secure" as a static configuration. Without this binding it is most certainly "less secure", because you may be letting invalid traffic through. > > Similarly, I see nothing wrong with ModeCfg just configuring the IP > > Address, and then using DHCP to obtain all the other configuration > > once the network is up. Indeed, modecfg could even provide the dhcp > > address ;) > > I guess there is consensus on this point; great ! So at least let's make the > DHCP server attribute in IKEModeCfg as a MUST implement otherwise people > cannot rely on it. That's perfectly fine with me. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Feb 13 19:47:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E3l6d07196; Thu, 13 Feb 2003 19:47:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16178 Thu, 13 Feb 2003 22:18:39 -0500 (EST) To: jeremy.de_clercq@alcatel.be Cc: vanakend@thmulti.com, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: Modefg considered harmful References: <3E4BCA40.6202A85E@alcatel.be> Date: 13 Feb 2003 22:21:45 -0500 In-Reply-To: <3E4BCA40.6202A85E@alcatel.be> Message-ID: Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, you lost me in the sea of acronyms. Could you please expand PE and SP? Provider Equipment and ...??? more inline.. jeremy.de_clercq@alcatel.be writes: > Hi Derek, Dirk, all, > > jumping in on an earlier comment: > > > A client connects to a gateway but doesn't agree on an IP Address. > > The client then says "ok, I'm 1.2.3.4". The IPsec gateway has no way > > to know that this client is authorized to use 1.2.3.4 -- it's just > > trusting the client, which is bad. Think PPVPN! If my company and > > your company share a VPN node, I could gain access to your vpn this > > way. > > In a scenario where sites are allowed to connect to the PPVPN using an > IPsec tunnel with the PE (which serves different VPNs), the SP's PE > would need to be pre-configured with the necessary information to > authenticate connecting sites as belonging to a specific PPVPN (I don't > believe it to be related with the customer's private addresses). This is only one possible scenario. In your scenario you may not care about ip address policy inside the tunnel, in which case you can leave the policy as 0/0 <-> 0/0, which is perfectly fine. However, just because YOUR architecture doesn't need this feature does not imply that others can live without it. > Once the (dynamically established IPsec) virtual interface (virtual > interfaces are really what's needed in the PPVPN context) is mapped to a Again, this may be fine in a PPVPN world, but the world is not just PPVPN. I want to set of host-to-gateway road-warrior VPNs, or even host-to-host protections. I need to be able to dynamically set policies on what address to expect on any particular SPI, and I want these policies tied to the IKE ID. Pehaps your world does not require this level of protection. Then again, I do not have to answer to your boss. ;) -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Feb 13 19:49:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E3npd07247; Thu, 13 Feb 2003 19:49:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16230 Thu, 13 Feb 2003 22:25:40 -0500 (EST) To: "Scott G. Kelly" Cc: Stephen Kent , BSingh@Nomadix.com, Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> <3E4C1C33.7FD7F995@airespace.com> Date: 13 Feb 2003 22:28:25 -0500 In-Reply-To: <3E4C1C33.7FD7F995@airespace.com> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" writes: > In such cases, no SPD entries are consulted following the routing > lookup, and the routing table (effectively) becomes the SAD/SPD. I think > this has obvious issues in terms of satisfying the selector criteria you > outlined in RFC2401, for the reasons I enumerated above. This works fine for output processing, but not necessarily for input processing. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Thu Feb 13 20:00:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E40Td07400; Thu, 13 Feb 2003 20:00:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16263 Thu, 13 Feb 2003 22:36:44 -0500 (EST) To: Tero Kivinen Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload References: Date: 13 Feb 2003 22:25:30 -0500 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: > Allowing two things to do the same thing is bad. I agree... > How about the mcr's proposal of having dhcp over IKE, i.e take dhcp > payload and put it inside the some IKE payload (we can name it to be > configuration payload, so the configuration payload people will be > happy too, just change the format to follow the dhcp packet). I see this as one of two reasonable approaches. I'm happy with the "tunnel DHCP in IKE" approach. The other approach with which I'm also happy is "use ModeCfg for IP address, then use DHCP later for additional configuration". The one benefit of the latter approach is that IKE with ModeCfg is guaranteed to complete in 4/6 messages, whereas IKE with tunneled DHCP is not. However, I can live with either approach. > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Feb 14 01:41:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E9fUd11271; Fri, 14 Feb 2003 01:41:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA19725 Fri, 14 Feb 2003 04:12:03 -0500 (EST) Message-ID: <3E4CB398.890268D9@alcatel.be> Date: Fri, 14 Feb 2003 10:15:04 +0100 From: jeremy.de_clercq@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins Cc: vanakend@thmulti.com, ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful References: <3E4BCA40.6202A85E@alcatel.be> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2003 10:15:09, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2003 10:15:12, Serialize complete at 02/14/2003 10:15:12 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Sorry, you lost me in the sea of acronyms. Could you please expand > PE and SP? Provider Equipment and ...??? sorry... (as you say, we live in different worlds ;); PE stands for Provider Edge device and SP for Service Provider. > > In a scenario where sites are allowed to connect to the PPVPN using an > > IPsec tunnel with the PE (which serves different VPNs), the SP's PE > > would need to be pre-configured with the necessary information to > > authenticate connecting sites as belonging to a specific PPVPN (I don't > > believe it to be related with the customer's private addresses). > > This is only one possible scenario. In your scenario you may not care > about ip address policy inside the tunnel, in which case you can leave > the policy as 0/0 <-> 0/0, which is perfectly fine. However, just > because YOUR architecture doesn't need this feature does not imply > that others can live without it. I agree. We'll have to find a solution where all architectures that are impacted can be satisfied. (isn't that what applicability statements are for ?) > > Once the (dynamically established IPsec) virtual interface (virtual > > interfaces are really what's needed in the PPVPN context) is mapped to a > > Again, this may be fine in a PPVPN world, but the world is not just > PPVPN. I want to set of host-to-gateway road-warrior VPNs, or even > host-to-host protections. I need to be able to dynamically set > policies on what address to expect on any particular SPI, and I want > these policies tied to the IKE ID. I understand, I'm not disputing that different worlds may have different requirements. Jeremy. From owner-ipsec@lists.tislabs.com Fri Feb 14 01:45:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1E9j9d11553; Fri, 14 Feb 2003 01:45:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA19825 Fri, 14 Feb 2003 04:21:03 -0500 (EST) Message-Id: <200302140922.h1E9MDof003209@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-reply-to: Your message of Thu, 13 Feb 2003 21:06:00 +0200. <15947.60568.261489.957133@ryijy.hel.fi.ssh.com> Date: Fri, 14 Feb 2003 10:22:13 +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: Francis Dupont writes: > => I don't buy this argument because it implies there is a known NAT > on the path. In this case any address which cannot be the address > seen by the other peer does the job. Yes, the other end will know there is nat between, but he does not know which address is actually used by the host behind NAT. Some IT-adminstrators want to keep the internal addresses hidden. => it seems we agree. If you believe this is a common case, I can add some text about this, for instance making the unspecified peer address the value to use when the peer wants to keep it address secret. The example case is when someone is using host behind corporate firewall which also does the NAT for all the addresses, and connects to some known service in the external net (say www.cnn.com). The IT-adminstrator does not want to give out the information about the internal ip-address, to this external machine. They might not want to give out information that this connection is coming from the same host than the previous connection few days earlier (i.e privacy issues). => for privacy issues, a standard secret peer address is better than a hash because it obviously never lacks knowledge. If the ip-address is public or if there is no randomness in it (spi/cookie/nonce or similar) then the other end (www.cnn.com) can track the users behind the corporate firewall because their internal ip-addresses are typically static. > Same for the port (even I can't find a reason to keep the port > secret). For source ports there is no need to keep it secret, and in most cases it will be always same. If the users want to have better privacy protection, they can always use random source port to make the brute force attack harder. The attacker can do brute force attack against hash. I.e take the other stuff and try all possible ip-addresses. As the ip-address space is usually quite small for ipv4 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 == 17891328 hosts) the attacker can break the hash, but it requires active expensive attack against each hash separately. The hashing does not help for attacker who has enough computing power, but it does make passive tracking of users impossible. => look at my previous answer. > In the IKEv1 they were always included if the support for NAT-T was > detected by vendor-IDs, in IKEv2 I would say we MUST always include > them. > => I don't know if we can reach a consensus about this in an IPv6 > context (where there should be no NATs :-)... True, but I think that making the protocol simplier has more value than the cost caused by extra hash in the packet. And I do not know what all kind of 6to4 etc conversions will do for the packets, and I think they will be detected as NATs so having them in the ipv6 space also would help in those cases. I do not know enough about those issues to be sure. => I don't need to be convinced. My concern is I don't know if it will be easy to convinced others. > => the purpose of the RR check is mainly operational according > to Jayant Shukla. There are other cases where an RR check improves > a bit the security, as it is cheap IMHO we should keep a way to > perform it. As the IKEv2 peer can always send empty notification to other end assume to get reply back, there is always a way to do it. I.e we do not need to specify anything for it, it is simply a implementation issue (i.e implementation might want to do it, or it might not do it). It does not affect interoperability. => the RR text is mainly an example (I don't use new things), I have just to make it more clearly an example, haven't I? > Note, that the attacker needs to continue attacking before he can gain > anything. If he only modifies one packet the correct address will be > updated back when the next packet is sent. I.e for the attacker to > cause denial of service attack he needs to along the path and modify > every single packet going on one direction. > > => no, you forgot the reverse way (the other SA of the pair) which > is updated too. True, but it is updated back immediately when the first non-modified packet is left through to the other end. Also usually if the attacker can modify/remove packets in one direction he can modify/remove packets in the other direction too. => I disagree, your argument assumes that both paths go through same routers and links and that intervals between packets are equivalent in both ways. > => your argument assumes the routing is symmetrical. If it is not > an attacker on one path can mess the reverse path. I think symmetrical routing is the most common case, => I believe that most of NANOG people will object. Unfortunately it seems that symmetrical routing is no more the common case. and even if it is not, the attacker can send the first packet so that the return routability check packet comes to place where he can reach it. => I used the asymmetrical routing argument for two points: - implicit IPsec SA update - return routability check. I shan't really defend the RR check with this argument because the RR check is known to provide weak security. But for the implicit IPsec SA routing the argument is far stronger. In fact, I don't believe you can argue the implicit IPsec SA update has no security problems, i.e., you can sell it to the IPsec WG. > And the attacker can still take the explicit return routability test > packet and forward it to proper place and finish the 3 way handshake > to get the same attack. Again he needs to stay in the path and he > needs to do some extra work, but I don't really think that will be > that much harder to do. > > => this attack works *only* when the NAT traversal feature is enabled > (and I argued that in this case you have near no defense, look at > draft-dupont-transient-pseudonat-01.txt). For mobility or multihoming > any peer address modification en route is easily detected by peer > address notification. I am only talking about the cases where we have detected NAT, and enabled NAT traversal. The IKEv1 NAT draft tries to be clear that any of these are only done if the other end behind the NAT (i.e if you have client behind NAT and server is directly connected, then only server will update the peer addresses, the client will never do it). => the purpose of my address management proposal is mainly the support of mobility and multihoming. As the NAT traversal feature shares many points with it and was too quickly copied from the IKEv1 NAT draft, I took the opportunity to fix and extend it, but for the security point of view I didn't fix the NAT traversal security flaw (IMHO it cannot be fixed by simple solutions), I tried to avoid new security problems for mobility and multihoming. > > 3.5 Explicit address update > > The explicit mechanism MUST be used. A new notification has to > > be defined. We propose to copy it from the delete notification. > I disagree. > => about the idea of an explicit mechanism itself or about the details? About the MUST. => it is more a MUST NOT for implicit IPsec SA update. I think it can be MAY, i.e the implemenation MAY do the return routability check, but in most cases there is no need for it, and it does not offer more protection against denial of service attacks. => I have no requirement for the RR check but I should add some: - MUST support it (but in fact this is an empty requirement because the RR check is not a new specification) - MAY use it - default config SHOULD enable it. What the host behind NAT might want to do is to make sure it sends some packets to the other end every now and then, especially if it has not received anything back (i.e if the attacker modified the packet and the other end updated peer address, the client should send some packets every now and then to fix the situation when the attacker stops active attack). > => the peer addresses are protected by the peer address notification > when the NAT traversal feature is disable (see a previous answer). If NAT traversal feature is disabled then I do not think we should ever update the other ends address (execpt for mobile-ip, but I everything I have been saying only handles NAT-T). => this is the difference between us. I want the support of mobility and multihoming, you want the support of NAT-T. I believe we can get both if we agree about the security stuff. For mobile-ip this kind of thing is usefull, but we cannot use the same mechanism in the NAT-T, thus I think we should keep them separate. => I disagree. The same mechanism could be used in both cases. > => idem. I never pretended to have a solution to the NAT traversal > feature intrinsic security flaw. Thanks for many examples of it (:-). > Now, if the NAT traversal feature is disabled, do you believe there > are remaining new security threats? I haven't considered the case without NAT-T, so I cannot say for sure, but I think there explicit return routability check is MUST. => support or use? Don't forget the only guy who can put a bad address is the peer itself. Regards Francis.Dupont@enst-bretagne.fr PS: the main question is about the implicit IPsec SA update mechanism that I rejected and you seem to like to keep. What is the opinion of the IPsec WG people? To summary it, the peer address of the other end is the external address of the last received valid packet of the (incoming) SA. The security issue is that at the exception of AH SAs, this address is not protected at all and a change has an effect on other SAs (for instance the other SA of the pair). IMHO there are some implementation efficiency issues too... Note that if such a mechanism is accepted there is no more need for an (other) address management in IKEv2 and I'll have to revised my proposal (i.e., flush large parts of it). From owner-ipsec@lists.tislabs.com Fri Feb 14 05:33:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EDXnd26654; Fri, 14 Feb 2003 05:33:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22038 Fri, 14 Feb 2003 08:04:54 -0500 (EST) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Fri, 14 Feb 2003 07:07:20 -0600 (CST) From: Tylor Allison X-X-Sender: To: Tero Kivinen cc: Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 Feb 2003, Tero Kivinen wrote: > tytso@mit.edu ("Theodore Ts'o") writes: > > Hence, we suggest that as a path forward, that the Configuration payload > > be left in ikev2-04.txt, and that people who believe that a richer > > feature set is necessary should be encouraged to update RFC 3456 for use > > with IKEv2 as an alternative mechanism. Since an implementation is > > I do not really think it is good idea to force everybody to implement > both RFC 3456 and configuration payload. The client will need to > implement both, because if the server replies with empty CFG_REPLY > then it needs to retry with RFC 3456 or similar. I absolutely agree with this statement... if we don't move forward with a single selection, we'll end up having to support both... and most likely not just in the client. I can see SGW's needing to implement both to work with the popular clients. > > allowed to respond with an empty CFG_REPLY packet, this should not prove > > to be an onerous implementation burden for those who are determined to > > only support DHCP 3456-style configuration. While this could > > potentially cause interoperability problems, the fact that most deployed > > implementations already support modecfg suggests that for the simple > > (common?) case where only a single IP address needs to be returned by > > the IPSEC gateway, it is extremely likely that most VPN-style > > implementations will support the Configuration payload. > > Allowing two things to do the same thing is bad. > > How about the mcr's proposal of having dhcp over IKE, i.e take dhcp > payload and put it inside the some IKE payload (we can name it to be > configuration payload, so the configuration payload people will be > happy too, just change the format to follow the dhcp packet). This is about the third or fourth proposal to use IKE as the DHCP transport, but I haven't seen much discussion as to whether or not this is a viable option. Personally, I believe this has merit, any other opinions? > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Fri Feb 14 06:00:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EE0md27840; Fri, 14 Feb 2003 06:00:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22365 Fri, 14 Feb 2003 08:34:06 -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: <15948.61587.381624.607395@ryijy.hel.fi.ssh.com> Date: Fri, 14 Feb 2003 15:35:15 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-Reply-To: <200302140922.h1E9MDof003209@givry.rennes.enst-bretagne.fr> References: <15947.60568.261489.957133@ryijy.hel.fi.ssh.com> <200302140922.h1E9MDof003209@givry.rennes.enst-bretagne.fr> 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 Francis Dupont writes: > => for privacy issues, a standard secret peer address is better than > a hash because it obviously never lacks knowledge. If the this stays static it will leak out information (i.e make the tracking of user easy). Also you assume that the client will know if there is NAT beteen (i.e use secret peer address only when there is NAT, and otherwise use normal address). If there is no NAT then client must use his own address otherwise we enable NAT-T every time. > PS: the main question is about the implicit IPsec SA update mechanism > that I rejected and you seem to like to keep. What is the opinion of > the IPsec WG people? I think that implicit mechanism is very important and usefull for NAT-T case, and SHOULD or MUST NOT be used in the mobile-ip or multihoming case (where we can get proper security by explicit update). -- 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 Feb 14 07:23:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EFNYd04050; Fri, 14 Feb 2003 07:23:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23147 Fri, 14 Feb 2003 09:52:07 -0500 (EST) Message-ID: <3E4C10BE.2050608@creeksidenet.com> Date: Thu, 13 Feb 2003 16:40:14 -0500 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: Re: ike2-v4: request or response] == major issue Content-Type: multipart/alternative; boundary="------------070109030604000205070105" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070109030604000205070105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I do not believe that the I bit in the ikev2 header provides its stated function of allowing a recipient to determine if a pdu is a request or response. I believe that the header needs to be augmented with an R (request) bit. -------- Original Message -------- Subject: Re: ike2-v4: request or response Date: Tue, 11 Feb 2003 10:45:56 +0100 From: Francis Dupont To: jeff pickering In your previous mail you wrote: I really appreciate your response. This is exacltly the statement in the spec that seems to be self-contradictory: - I-bit is set by oriiginal IKE-SA initiator. (Alice) - Original responder (Bob)can also be the sender of a request. => Therefore, I-bit contains no information about which end initiated a particular request. OR am I crazy?? => no, I believe you're right and there is a real problem. A request bit should solve the issue. Note the I bit is still needed if the IKEv1 order of the SPIs (aka cookies) is kept. Regards Francis.Dupont@enst-bretagne.fr PS: please ask for a request bit in the message header! --------------070109030604000205070105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I do not believe that the I bit in the ikev2 header provides its stated function
of allowing a recipient to determine if a pdu is a request or response. I
believe that the header needs to be augmented with an R (request) bit.

-------- Original Message --------
Subject: Re: ike2-v4: request or response
Date: Tue, 11 Feb 2003 10:45:56 +0100
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: jeff pickering <jpickering@creeksidenet.com>


 In your previous mail you wrote:

   I really appreciate your response.
   This is exacltly the statement in the spec that seems to be
   self-contradictory:
   
   - I-bit is set by oriiginal IKE-SA initiator. (Alice)
   - Original responder (Bob)can also be the sender of a request.
   => Therefore, I-bit contains no information about which end initiated a
   particular request.
   
   OR am I crazy??
   
=> no, I believe you're right and there is a real problem.
A request bit should solve the issue. Note the I bit is still
needed if the IKEv1 order of the SPIs (aka cookies) is kept.

Regards

Francis.Dupont@enst-bretagne.fr

PS: please ask for a request bit in the message header!



--------------070109030604000205070105-- From owner-ipsec@lists.tislabs.com Fri Feb 14 07:23:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EFNYd04056; Fri, 14 Feb 2003 07:23:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23174 Fri, 14 Feb 2003 09:54:03 -0500 (EST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 13 Feb 2003 12:58:42 -0800 Subject: Re: IKEV2: Issue #4 Revised Identity From: Brian Korver To: Pekka Riikonen CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 2/12/03 8:20 AM, "Pekka Riikonen" wrote: > The revised identity draft effectively creates same payloads but named > differently. We already have those but only their definition has been > sloppy. It would seem simple to just fix where we have gone wrong instead > of replacing them. I know what I wrote is much the same pki-profile has, > except for the specific points I tried to make: > > : The IKEv1 interoperability problems arose because IKEv1 underspecified > : how the payloads should be used. > : > If the CA in CR is wrong, then it's probable that implementation will not > reply with any cert. If you have never connected with remote, don't know > who it trusts, and only thing you want is to just probe (or connect > opportunisticly) to get the remote's cert so that you can make the > decision whether you trust it or not (say, ask it from user), would not > work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty > CR. Could you provide a use case where this is a problem? Let's say that I know I trust CAs A and B, and I tell you that I trust them by sending you CERTREQ payloads containing the DNs of these two CAs. If you don't have a certificate backed by A or B, we have no common ground and I cannot hope to authenticate you, so IKE fails. Are you thinking opportunistic IPSec? > > For IKEv1 we agreed several times over the years that receiving empty CR > means sending all your local certs, or what ever your local policy happens > to dictate. This is very good since it allows to get remote's certificate > regardless whether or not you know who it trusts, but the problem was that > it was never written down anywhere. I'd like very much to see the MUST > NOT lifted from IKEv2 and specify that if empty CR is received the > receiver SHOULD send local cert(s). The section 3.3.8.2 in pki-profile > "maybe or maybe not" allows this with "non-conformant" implementations. > I think it should be either it's not allowed or it's allowed and it's > correct behavior. Now it's like, "ok, you can't really do this, but, hey > if you do it work with it anyway"... > > The second point was the ability to check whether cached cert is correct > or not. This is very simple to do just by allowing the CR payload (by > adding new cert encoding type) to have the cert information (subject, > hash, what ever) in the CR data. OTOH, same feature could work with > revised identity draft too (in either TrustedRoot or IDAccepted)... > > Pekka > ___________________________________________________________________________ > Pekka Riikonen | Email: priikone@iki.fi > SILC - http://silcnet.org/ | http://iki.fi/priikone/ > Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio > PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc > - brian briank@briank.com From owner-ipsec@lists.tislabs.com Fri Feb 14 07:23:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EFNYd04049; Fri, 14 Feb 2003 07:23:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23146 Fri, 14 Feb 2003 09:52:02 -0500 (EST) Message-ID: <3E4C0847.1070800@mit.edu> Date: Thu, 13 Feb 2003 16:04:07 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barbara Fraser CC: smb@att.com, ipsec@lists.tislabs.com, Geoffrey Huang , tytso@mit.edu Subject: Re: Ready for IETF Last Call draft-ietf-ipsec-dpd-01.txt References: <4.3.2.7.2.20030212135903.04c54d50@mira-sjc5-4.cisco.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F5D0253C3256580B62123E1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F5D0253C3256580B62123E1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Informational documents do not need to be last called. I will read it and send it on to the IESG for consideration directly. -Jeff Barbara Fraser wrote: > Hi Steve, Jeff, > > The I-D draft-ietf-ipsec-dpd-01.txt has been through > working group last call, and with no comments against it, it is ready to > go to IETF last call for informational RFC. > > thanks, > Barb and Ted > --------------enig1F5D0253C3256580B62123E1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+TAhH8CBzV/QUlSsRAlpvAKDqpZm1vUy7wZaUU2KqKp/n9mmr7ACfUHbF f1jZwv2U7bhasvK+5BCYKNA= =G7CH -----END PGP SIGNATURE----- --------------enig1F5D0253C3256580B62123E1-- From owner-ipsec@lists.tislabs.com Fri Feb 14 09:11:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EHBod08528; Fri, 14 Feb 2003 09:11:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24192 Fri, 14 Feb 2003 11:32:52 -0500 (EST) Message-ID: <3E4D1A4F.E997CFDA@airespace.com> Date: Fri, 14 Feb 2003 08:33:19 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tylor Allison CC: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 16:35:16.0322 (UTC) FILETIME=[0E0BDC20:01C2D447] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tylor Allison wrote: > This is about the third or fourth proposal to use IKE as the DHCP > transport, but I haven't seen much discussion as to whether or not this is > a viable option. Personally, I believe this has merit, any other opinions? I agree with Tylor on this point: we really should discuss this before proceeding. Personally, I have not been too fond of this approach, but it has been suggested by a number of long-time wg participants, and seems to have some significant amount of vendor support. It deserves examination. In considering this approach, the things I dislike are these: - it requires the dhcp daemon/application to interface with IKE rather than sit on a native socket; this may be no big deal for implementations which cannot use a native dhcp client, but for those which can, this may be significant. - it increases the complexity of the ike implementation significantly more than the other two proposals, as an indeterminate amount of dhcp traffic must now be tunneled over ike, and ike must provide a dhcp interface for both the dhcp client (IRAC) and the dhcp proxy/relay (IRAS). What I like is this: - it is a single mechanism which provides modecfg-style support *and* dhcp support I'd be very interested to hear the assessments of both modecfg and rfc3456 implementers. Scott From owner-ipsec@lists.tislabs.com Fri Feb 14 09:11:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EHBod08529; Fri, 14 Feb 2003 09:11:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24267 Fri, 14 Feb 2003 11:38:57 -0500 (EST) Message-ID: <3E4D1BCB.FFFC4E1D@airespace.com> Date: Fri, 14 Feb 2003 08:39:39 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: ipsec@lists.tislabs.com Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> <3E4C1C33.7FD7F995@airespace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 16:41:36.0725 (UTC) FILETIME=[F0C8C050:01C2D447] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, [recipient list trimmed...] Derek Atkins wrote: > > "Scott G. Kelly" writes: > > > In such cases, no SPD entries are consulted following the routing > > lookup, and the routing table (effectively) becomes the SAD/SPD. I think > > this has obvious issues in terms of satisfying the selector criteria you > > outlined in RFC2401, for the reasons I enumerated above. > > This works fine for output processing, but not necessarily for input > processing. I guess I don't understand what you mean. I don't think it works according to what is specified in RFC2401, as (1) you cannot control the SPD ordering due to the fact that route selection is best match (unless your SPD happens to be ordered from most specific to least specific), and (2) you cannot select traffic based on protocols/ports. So, it doesn't really work right (where "right" means "in accordance with RFC2401") for either egress or ingress, does it? Scott From owner-ipsec@lists.tislabs.com Fri Feb 14 09:26:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EHQqd08908; Fri, 14 Feb 2003 09:26:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24502 Fri, 14 Feb 2003 12:00:12 -0500 (EST) Date: Fri, 14 Feb 2003 18:03:01 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tylor Allison Cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : > How about the mcr's proposal of having dhcp over IKE, i.e take dhcp : > payload and put it inside the some IKE payload (we can name it to be : > configuration payload, so the configuration payload people will be : > happy too, just change the format to follow the dhcp packet). : : This is about the third or fourth proposal to use IKE as the DHCP : transport, but I haven't seen much discussion as to whether or not this is : a viable option. Personally, I believe this has merit, any other opinions? : It would be nice to have as short IKE exchange as possible. I do however like DHCP over IPSEC because it's simple and easy to implement. In IKE DHCP would cause one extra round trip because client and server need to ack each other. However, if the client knows previous configuration it may attempt a shorter DHCP exchange by directly sending DHCP REQUEST. In this case the length would be equal to cfgmode. OTOH, if that fails then it's again long exchange (plus the first REQUEST, making it even longer). There are plenty of implementations of cfgmode for sure, but there are plenty more DHCP servers out there (ie. everywhere) so using DHCP in IKEv2 is very tempting. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Fri Feb 14 09:28:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EHSad09091; Fri, 14 Feb 2003 09:28:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24516 Fri, 14 Feb 2003 12:01:14 -0500 (EST) Date: Fri, 14 Feb 2003 18:04:04 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #4 Revised Identity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : On 2/13/03 1:20 PM, "Pekka Riikonen" wrote: : > One case is opportunistic IPSec, second is use of self-signed certs. : > Assuming your friend has only a self-signed cert it would be nice to get : > that cert in IKE so that you could cache it (and verify it, sign it, etc). : > : Ok, but could you be more specific about the self-signed cert : (in the non-opportunistic case)? Either I already know about : your certificate and trust it, or I don't and never will. : If I already trust it, I don't need it. If I don't trust : it and never will, then I'm not going to do IKE with you. : You cannot think like "I already trust you, or never will", if the ability to create the trust depends on ability of getting the certificate you want to trust. Since certificates are sent in IKE it would seem the logical place to get the remote's certificate, verify it (ask it from user perhaps), cache it, sign it perhaps with your self-signed cert and then use that from that point on. But if you never get it, or you rely it on getting it through some external means then it's not working really well in my opinion. Certs are not pre-shared-keys so there's no need to pre-share them, we can get them in IKE. There's at least three cases with self-signed cert and they don't have to relate to opportunistic crypto. a) you have self-signed cert, and you don't trust any CA, ie. you want to get the remote's cert so that you can sign it and create the trust by that, b) your friend has only self-signed cert and you want to connect to your friend, you need her certificate, c) both of you have only self-signed certs and in order to ever create the very first connection you need to create trust to each other, and this could be done by verifying each others certs you receive in IKE. If the CR never allows on getting anything else except certs issued by the specific CA you send, then use of self-signed certs is not possible, or you leave it to the fact that you must know the issuer name (subject name) of the self-signed cert which by the nature of self-signed certs (the possibility that new cert is created easily) may be difficult. The analogy is the SSH keys; when you connect to SSH server for the very first time you verify and cache the server key. From that point on you don't need to do that anymore. Self-signed certs in IPSEC can work the same way; you get it for the first connection and don't worry about it after that point on. This is why I'd like to see the CR payload's MUST NOT for empty CR lifted instead of leaving a loophole which is there now: if your implementation is broken (the "non-conformant") others SHOULD work with you anyway, although previous sentence says it's a MUST NOT. The way to go in my opinion is to either disallow it entirely or allow empty CR payloads. The "non-conformant" is a relic from IKEv1 where this issue was never written down although it was agreed on between vendors. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SILC - http://silcnet.org/ | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Fri Feb 14 09:38:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EHcSd10478; Fri, 14 Feb 2003 09:38:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24650 Fri, 14 Feb 2003 12:11:21 -0500 (EST) To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: typical IPsec-based VPNs incl. modecfg vs. DHCP References: <89680B404BA1DD419E6D93B28B41899BE9FC88@01mail.nomadix.com> <3E483959.5D2D8DF1@airespace.com> <3E4C1C33.7FD7F995@airespace.com> <3E4D1BCB.FFFC4E1D@airespace.com> Date: 14 Feb 2003 12:13:37 -0500 In-Reply-To: <3E4D1BCB.FFFC4E1D@airespace.com> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" writes: > > > In such cases, no SPD entries are consulted following the routing > > > lookup, and the routing table (effectively) becomes the SAD/SPD. I think > > > this has obvious issues in terms of satisfying the selector criteria you > > > outlined in RFC2401, for the reasons I enumerated above. > > > > This works fine for output processing, but not necessarily for input > > processing. > > I guess I don't understand what you mean. I don't think it works > according to what is specified in RFC2401, as (1) you cannot control the > SPD ordering due to the fact that route selection is best match (unless > your SPD happens to be ordered from most specific to least specific), > and (2) you cannot select traffic based on protocols/ports. So, it > doesn't really work right (where "right" means "in accordance with > RFC2401") for either egress or ingress, does it? Well, you can.. The point that was being made was that you'd have a SPD "per route". So, after you choose the route you're going to take you lookup the SPD and choose the SA to use (if any). The traffic could be dropped at this point, too. My only point was that on input you don't necessarily have the "input routing" information, so you may not know which virtual route was used, so searching input SPDs are much more difficult. > Scott -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Feb 14 11:06:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EJ6sd16295; Fri, 14 Feb 2003 11:06:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25647 Fri, 14 Feb 2003 13:38:34 -0500 (EST) Message-Id: <200302141840.h1EIekwj009845@thunk.east.sun.com> From: Bill Sommerfeld To: Tylor Allison cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload In-Reply-To: Your message of "Fri, 14 Feb 2003 07:07:20 CST." Reply-to: sommerfeld@east.sun.com Date: Fri, 14 Feb 2003 13:40:46 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is about the third or fourth proposal to use IKE as the DHCP > transport, but I haven't seen much discussion as to whether or not this is > a viable option. Personally, I believe this has merit, any other opinions? I agree. I'd rather see something DHCP-derived than modecfg-like. While i'd prefer just treating the tunnel like a regular interface and doing IPsec-protected DHCP, encapsulating DHCP inside IKE is acceptable to me. - Bill From owner-ipsec@lists.tislabs.com Sun Feb 16 08:23:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1GGNhd12773; Sun, 16 Feb 2003 08:23:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28342 Sun, 16 Feb 2003 10:29:16 -0500 (EST) Message-Id: <200302161529.h1GFTRof012177@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-reply-to: Your message of Fri, 14 Feb 2003 15:35:15 +0200. <15948.61587.381624.607395@ryijy.hel.fi.ssh.com> Date: Sun, 16 Feb 2003 16:29:27 +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: Francis Dupont writes: > => for privacy issues, a standard secret peer address is better than > a hash because it obviously never lacks knowledge. If the this stays static it will leak out information (i.e make the tracking of user easy). Also you assume that the client will know if there is NAT beteen (i.e use secret peer address only when there is NAT, and otherwise use normal address). If there is no NAT then client must use his own address otherwise we enable NAT-T every time. => if there is no NAT the secret address will be as it in the packet header and no more secret. So I assume that when someone wants to keep it address secret it begins by insert a NAT in the path... > PS: the main question is about the implicit IPsec SA update mechanism > that I rejected and you seem to like to keep. What is the opinion of > the IPsec WG people? I think that implicit mechanism is very important and usefull for NAT-T case, and SHOULD or MUST NOT be used in the mobile-ip or multihoming case (where we can get proper security by explicit update). => IMHO we should avoid to have two worlds, one with NAT-T enabled, one with NAT-T disabled but with a dedicated mechanism for mobility and multi-homing. But this is an architectural issue: it is not in the scope of the IPsec WG and should be submitted to the IESG/IAB. Until we get an advice from them, can we try to fix all the other minor details (in fact what I suggested for this pre-last call)? Thanks Francis.Dupont@enst-bretagne.fr PS: have we enough numbers about renumbering of flows through NATs. For instance, the mean delay between two renumberings. From owner-ipsec@lists.tislabs.com Sun Feb 16 08:55:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1GGtZd16265; Sun, 16 Feb 2003 08:55:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28884 Sun, 16 Feb 2003 11:27:30 -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: <15951.48175.718606.292982@ryijy.hel.fi.ssh.com> Date: Sun, 16 Feb 2003 18:28:31 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-Reply-To: <200302161529.h1GFTRof012177@givry.rennes.enst-bretagne.fr> References: <15948.61587.381624.607395@ryijy.hel.fi.ssh.com> <200302161529.h1GFTRof012177@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > If the this stays static it will leak out information (i.e make the > tracking of user easy). Also you assume that the client will know if > there is NAT beteen (i.e use secret peer address only when there is > NAT, and otherwise use normal address). If there is no NAT then client > must use his own address otherwise we enable NAT-T every time. > > => if there is no NAT the secret address will be as it in the packet > header and no more secret. So I assume that when someone wants to > keep it address secret it begins by insert a NAT in the path... Yes, but the client does not know if there is NAT between before it is tested, and it might not know if the address is secret or not if it is given by dhcp. If we give out the static address always in the nat discovery protocol then there is no way to keep that address secret. That was the reason the addresses are hashed in the NAT-T draft. -- 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 Feb 16 09:58:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1GHw4d21431; Sun, 16 Feb 2003 09:58:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29523 Sun, 16 Feb 2003 12:32:50 -0500 (EST) Message-Id: <200302161733.h1GHXpof013107@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-reply-to: Your message of Sun, 16 Feb 2003 18:28:31 +0200. <15951.48175.718606.292982@ryijy.hel.fi.ssh.com> Date: Sun, 16 Feb 2003 18:33:51 +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: > If the this stays static it will leak out information (i.e make the > tracking of user easy). Also you assume that the client will know if > there is NAT beteen (i.e use secret peer address only when there is > NAT, and otherwise use normal address). If there is no NAT then client > must use his own address otherwise we enable NAT-T every time. > > => if there is no NAT the secret address will be as it in the packet > header and no more secret. So I assume that when someone wants to > keep it address secret it begins by insert a NAT in the path... Yes, but the client does not know if there is NAT between before it is tested, and it might not know if the address is secret or not if it is given by dhcp. => now I can see your problem. If we give out the static address always in the nat discovery protocol then there is no way to keep that address secret. => so obviously the address should not be in the discovery request. That was the reason the addresses are hashed in the NAT-T draft. => I still don't believe this is the good solution. In fact the initiator knows there is a NAT only with the reply: my proposal is to keep the unspecified address as the secret one and to rely on the reply (which will contain the address received by the responder). The only difference is the responder can believe there is a NAT in the path when there is none but we have to handle the case where a NAT is inserted or removed from the path so this is not a problem... BTW what is the best mechanism for the switch between ports 500 and 4500? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Feb 17 06:16:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HEGnd24358; Mon, 17 Feb 2003 06:16:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09968 Mon, 17 Feb 2003 08:41:36 -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: <15952.59132.644024.307161@ryijy.hel.fi.ssh.com> Date: Mon, 17 Feb 2003 15:43:24 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: a proposal of address management for IKEv2 In-Reply-To: <200302161733.h1GHXpof013107@givry.rennes.enst-bretagne.fr> References: <15951.48175.718606.292982@ryijy.hel.fi.ssh.com> <200302161733.h1GHXpof013107@givry.rennes.enst-bretagne.fr> 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 Francis Dupont writes: > => I still don't believe this is the good solution. In fact the initiator > knows there is a NAT only with the reply: my proposal is to keep the > unspecified address as the secret one and to rely on the reply (which > will contain the address received by the responder). The only difference Note, that either one of the ends can be behind NAT. We need to detect which one (or both) is behind the NAT, to enable keepalives. > is the responder can believe there is a NAT in the path when there is none > but we have to handle the case where a NAT is inserted or removed from > the path so this is not a problem... I don't think there are cases where NAT is inserted or removed in the path during the IPsec connection, thus we do not need to take care of those cases. There are cases where the other ends IP address either changes or does not change (i.e mobile ip) in transit, but those cases are NOT NAT cases, as we do know when the address changes and we can send explicit notification about that. In my talks NAT is the box in the path that will not give out any notifications and there is no way to modify its functionality. The Mobile IP cases are not NAT cases, as we can get information when and how they modify the ip-addresses. To fix various attacks, the NAT-T handling MUST NOT be enabled if there is no NAT between. > BTW what is the best mechanism for the switch between ports 500 and 4500? Immediately when the NAT is detected we switch to 4500 and we stay there as long as the connection is open (i.e all rekeying etc happens in that port). When the IKE SA is deleted we SHOULD still remember to use port 4500 for few minutes (i.e in case we reconnect we should use the port 4500 for reconnection for next few minutes). After few minutes there is no need to remember to use port 4500 as the NAT has already deleted the mapping because we do not send keepalives anymore. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Feb 17 06:46:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HEk4d25374; Mon, 17 Feb 2003 06:46:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10062 Mon, 17 Feb 2003 09:20:45 -0500 (EST) Message-ID: From: Harshwardhan Mittal To: "'ipsec@lists.tislabs.com'" Subject: IKE-hybrid mode authentication Date: Mon, 17 Feb 2003 19:31:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, Can someone please throw some light on "Hybrid mode authentication for IKE"? Is it a standard or a draft? Where can I find latest info on XAUTH and Hybrid mode? Thanks in advance. Regards, Harsh ------------------------------------------------------------------------ Harsh Mittal Software Engineer Motorola India Electronics Ltd. H.No. 6-3-1090, TSR Towers, Rajbhavan Road, Somajiguda, Hyderabad-500082 Phone: +91-040-3308090 Ex.2026 Email: mittal@mihy.mot.com ************************************************ [ ] General Business Information [X] Motorola Internal Use only [ ] Motorola Confidential Proprietary ************************************************ From owner-ipsec@lists.tislabs.com Mon Feb 17 08:39:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HGdhd01009; Mon, 17 Feb 2003 08:39:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10352 Mon, 17 Feb 2003 11:07:08 -0500 (EST) From: "Stephane Beaulieu" To: "Harshwardhan Mittal" , Subject: RE: IKE-hybrid mode authentication Date: Mon, 17 Feb 2003 11:09:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk drafts are expired. I'll them both to you in a private email. You can also send questions to ietf-xauth@vpnc.org. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Harshwardhan Mittal > Sent: Monday, February 17, 2003 9:01 AM > To: 'ipsec@lists.tislabs.com' > Subject: IKE-hybrid mode authentication > > > Hi All, > > Can someone please throw some light on "Hybrid mode authentication for > IKE"? > > Is it a standard or a draft? > > Where can I find latest info on XAUTH and Hybrid mode? > > Thanks in advance. > > > Regards, > Harsh > > ------------------------------------------------------------------------ > Harsh Mittal > Software Engineer > Motorola India Electronics Ltd. > H.No. 6-3-1090, TSR Towers, > Rajbhavan Road, Somajiguda, > Hyderabad-500082 > Phone: +91-040-3308090 Ex.2026 > Email: mittal@mihy.mot.com > > > ************************************************ > [ ] General Business Information > [X] Motorola Internal Use only > [ ] Motorola Confidential Proprietary > ************************************************ > > > From owner-ipsec@lists.tislabs.com Mon Feb 17 12:12:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HKCAd07778; Mon, 17 Feb 2003 12:12:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10849 Mon, 17 Feb 2003 14:44:02 -0500 (EST) Message-Id: <5.2.0.9.2.20030217144435.03894150@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 17 Feb 2003 14:46:31 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: IKEV2: Issue #4 Revised Identity In-Reply-To: <200302122314.h1CNEVwj028118@thunk.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > and that's where you find the crl. I don't know. I punt to pkix to decide > > what the "URL" means. I think that there are documents now that tell me > > how to get stuff via HTTP, right? > >Yes, and there's also apparently some way to embed URLs pointing to >(multiple) CRL distribution points into certificates. See RFC 3280, section 4.2.1.14, on CRL Distribution Points. The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile RECOMMENDS support for this extension by CAs and applications. Russ From owner-ipsec@lists.tislabs.com Tue Feb 18 10:36:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IIabd10783; Tue, 18 Feb 2003 10:36:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13180 Tue, 18 Feb 2003 12:55:39 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3E4C10BE.2050608@creeksidenet.com> Subject: Re: [Fwd: Re: ike2-v4: request or response] == major issue To: "jpickering@creeksidenet.com" , Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 15 Feb 2003 18:52:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/18/2003 12:58:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're right! And I'm embarrassed that such an obvious error could have persisted so late into the review process. But much better to find it now than after it goes RFC... I've added a R (response) bit (must be cleared for requests, must be set for responses). --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). > I do not believe that the I bit in the ikev2 header provides its > stated function > of allowing a recipient to determine if a pdu is a request or response. I > believe that the header needs to be augmented with an R (request) bit. > > -------- Original Message -------- > > Subject: > > Re: ike2-v4: request or response > > Date: > > Tue, 11 Feb 2003 10:45:56 +0100 > > From: > > Francis Dupont > > To: > > jeff pickering > > > In your previous mail you wrote: > > I really appreciate your response. > This is exacltly the statement in the spec that seems to be > self-contradictory: > > - I-bit is set by oriiginal IKE-SA initiator. (Alice) > - Original responder (Bob)can also be the sender of a request. > => Therefore, I-bit contains no information about which end initiated a > particular request. > > OR am I crazy?? > > => no, I believe you're right and there is a real problem. > A request bit should solve the issue. Note the I bit is still > needed if the IKEv1 order of the SPIs (aka cookies) is kept. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: please ask for a request bit in the message header! > > > From owner-ipsec@lists.tislabs.com Tue Feb 18 10:36:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IIagd10804; Tue, 18 Feb 2003 10:36:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13181 Tue, 18 Feb 2003 12:55:40 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F04@TMM_EDGMSMSG01> Subject: Re: IKEv2 Terms & Definitions To: Van Aken Dirk Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 15 Feb 2003 19:01:29 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/18/2003 12:58:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > When I started reading about IKEv1 a few years ago, I was happy that section > "3.2 Notation" was included in RFC2409. > Although I assume I had a good a good background in IP protocol engineering > it was a complete different world to me back then. > Without section 3.2. it would have been even more difficult for me to master > this protocol (also because the complete IKEv1 specification is dispersed > over 3 documents: IKE, ISAKMP and DOI). As an example, the symbol "|" was an > OR function for me but in IKEv1 it means concatenation .. > > So I find it a little bit odd that this part is left out especially as it is > stated that one of the goals of IKEv2 is to define the entire protocol into > one document. > People new to IKE will have to refer to IKEv1 for terms and definitions. > So I wonder whether a similar section can still be included in IKEv2 ? While a lot of the definitions of the notation are scattered throughout the document, your point is well taken. I started to draft such a section but decided to put it off to "the last minute" because the terms kept changing and I feared I wouldn't keep it up to date. But now "the last minute" has arrived and there may not be time. Would anyone like to volunteer to either draft a section or would multiple people like to make suggestions for terms to define and definitions that I could try to merge and include. I suspect this will have to be put off to the next revision, but even so I think I could keep track of the contributed text. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Tue Feb 18 10:36:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IIabd10784; Tue, 18 Feb 2003 10:36:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13182 Tue, 18 Feb 2003 12:55:43 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: IKEV2: Issue #2: Cipher suites To: Tero Kivinen Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Fri, 14 Feb 2003 21:05:12 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/18/2003 12:58:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: > This would remove prolems and errors where someone includes suite for > ESP in the phase 1 or IKE suite for child_sa. The parsing of SA > payload can be identical but the meaning of the values in the payloads > should depend on if it is phase 1 or 2 SA negotiation payload. While negotiating ESP in phase 1 would be illegal, IKE can be negotiated an a child_sa exchange, and is used to roll over keys. So the SA payload needs an indicator somewhere of whether the proposed SA type is IKE or not. (If not implicitly in the suite ID, then in a separate field). --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Tue Feb 18 14:06:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IM6vd17027; Tue, 18 Feb 2003 14:06:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13640 Tue, 18 Feb 2003 16:35:47 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302182138.h1ILcKM10761@sydney.East.Sun.COM> Date: Tue, 18 Feb 2003 16:39:05 -0500 To: , , "jpickering@creeksidenet.com" Cc: Reply-To: Subject: Re: [Fwd: Re: ike2-v4: request or response] == major issue X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suspect this error was introduced as a result of going back to having the cookies be in the order (IKE initiator's cookie, IKE responder's cookie) rather than (receiver's SPI, transmitter's SPI) (a change made for NAT traversal). So, yes, we need a bit, but does it have to be called "R"? I'll never remember if it's for "request" or "response". How about "C" (for command vs response). Or perhaps "A" (for "acknowledgement, sent on the response). Radia wrote: > > > > >You're right! And I'm embarrassed that such an obvious error could have >persisted so late into the review process. But much better to find it now >than after it goes RFC... I've added a R (response) bit (must be cleared >for requests, must be set for responses). > > --Charlie > >Opinions expressed may not even be mine by the time you read them, and >certainly don't reflect those of any other entity (legal or otherwise). > >> I do not believe that the I bit in the ikev2 header provides its >> stated function >> of allowing a recipient to determine if a pdu is a request or response. I >> believe that the header needs to be augmented with an R (request) bit. >> >> -------- Original Message -------- >> >> Subject: >> >> Re: ike2-v4: request or response >> >> Date: >> >> Tue, 11 Feb 2003 10:45:56 +0100 >> >> From: >> >> Francis Dupont >> >> To: >> >> jeff pickering >> >> > >> In your previous mail you wrote: >> >> I really appreciate your response. >> This is exacltly the statement in the spec that seems to be >> self-contradictory: >> >> - I-bit is set by oriiginal IKE-SA initiator. (Alice) >> - Original responder (Bob)can also be the sender of a request. >> => Therefore, I-bit contains no information about which end initiated >a >> particular request. >> >> OR am I crazy?? >> >> => no, I believe you're right and there is a real problem. >> A request bit should solve the issue. Note the I bit is still >> needed if the IKEv1 order of the SPIs (aka cookies) is kept. >> >> Regards >> >> Francis.Dupont@enst-bretagne.fr >> >> PS: please ask for a request bit in the message header! >> >> >> > From owner-ipsec@lists.tislabs.com Wed Feb 19 07:23:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JFNId22036; Wed, 19 Feb 2003 07:23:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15612 Wed, 19 Feb 2003 09:48:21 -0500 (EST) Message-ID: <3E539B22.7040403@creeksidenet.com> Date: Wed, 19 Feb 2003 09:56:34 -0500 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: radia.perlman@sun.com CC: Charlie_Kaufman@notesdev.ibm.com, Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com Subject: Re: [Fwd: Re: ike2-v4: request or response] == major issue References: <200302182138.h1ILcKM10761@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess getting it fixed is really my concern, but if we really want a single letter, 'A' gets my vote. Jeff Radia Perlman - Boston Center for Networking wrote: > I suspect this error was introduced as a result of > going back to having the cookies be in the order > (IKE initiator's cookie, IKE responder's cookie) rather > than (receiver's SPI, transmitter's SPI) (a change > made for NAT traversal). > > So, yes, we need a bit, but does it have to be called > "R"? I'll never remember if it's for "request" or > "response". > > How about "C" (for command vs response). > Or perhaps "A" (for "acknowledgement, sent on > the response). > > Radia > > > wrote: > >> >> >> >> You're right! And I'm embarrassed that such an obvious error could have >> persisted so late into the review process. But much better to find it now >> than after it goes RFC... I've added a R (response) bit (must be cleared >> for requests, must be set for responses). >> >> --Charlie >> >> Opinions expressed may not even be mine by the time you read them, and >> certainly don't reflect those of any other entity (legal or otherwise). >> >>> I do not believe that the I bit in the ikev2 header provides its >>> stated function >>> of allowing a recipient to determine if a pdu is a request or response. I >>> believe that the header needs to be augmented with an R (request) bit. >>> >>> -------- Original Message -------- >>> >>> Subject: >>> >>> Re: ike2-v4: request or response >>> >>> Date: >>> >>> Tue, 11 Feb 2003 10:45:56 +0100 >>> >>> From: >>> >>> Francis Dupont >>> >>> To: >>> >>> jeff pickering >>> >>> >>> In your previous mail you wrote: >>> >>> I really appreciate your response. >>> This is exacltly the statement in the spec that seems to be >>> self-contradictory: >>> >>> - I-bit is set by oriiginal IKE-SA initiator. (Alice) >>> - Original responder (Bob)can also be the sender of a request. >>> => Therefore, I-bit contains no information about which end initiated >> >> a >> >>> particular request. >>> >>> OR am I crazy?? >>> >>> => no, I believe you're right and there is a real problem. >>> A request bit should solve the issue. Note the I bit is still >>> needed if the IKEv1 order of the SPIs (aka cookies) is kept. >>> >>> Regards >>> >>> Francis.Dupont@enst-bretagne.fr >>> >>> PS: please ask for a request bit in the message header! >>> >>> >>> From owner-ipsec@lists.tislabs.com Thu Feb 20 06:36:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KEadd11202; Thu, 20 Feb 2003 06:36:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18745 Thu, 20 Feb 2003 08:56:34 -0500 (EST) Message-Id: <200302201237.HAA09312@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-ecnfix-01.txt Date: Thu, 20 Feb 2003 07:37:23 -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 : IKEv2: ECN Requirements for IPsec Tunnels Author(s) : D. Black Filename : draft-ietf-ipsec-ikev2-ecnfix-01.txt Pages : 7 Date : 2003-2-19 IPsec (IP Security) tunnel encapsulation and decapsulation were specified prior to the addition of ECN (Explicit Congestion Notification) to IP, with the potential result that ECN congestion indications could be discarded by IPsec tunnel decapsulators. The current ECN specification includes two ECN operating modes for IPsec tunnels to avoid this situation, and IKEv1/ISAKMP (Internet Key Exchange/Internet Security Association and Key Management Protocol) negotiation extensions to enable ECN to be used correctly with IPsec tunnels. To simplify this situation, IKEv2 requires changes to tunnel decapsulation that prevent discarding of ECN congestion indication, obviating the need for multiple ECN operating modes and associated negotiation support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-ecnfix-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-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-2-19142154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-ecnfix-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142154.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Feb 21 13:09:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LL9Nd24288; Fri, 21 Feb 2003 13:09:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22222 Fri, 21 Feb 2003 15:26:42 -0500 (EST) Message-ID: <3E568BF2.8040904@kolumbus.fi> Date: Fri, 21 Feb 2003 22:28:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: (fwd) Last Call: Using IPsec to Protect MIPv6 Signaling to Proposed Standard References: <200302211740.MAA08408@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This may be of interest here as well: > The IESG has received a request from the IP Routing for Wireless/Mobile > Hosts Working Group to consider Using IPsec to Protect Mobile IPv6 > Signaling between Mobile Nodes and Home Agents > 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-3-7. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-03.txt From owner-ipsec@lists.tislabs.com Sat Feb 22 22:15:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1N6FGd28315; Sat, 22 Feb 2003 22:15:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25440 Sun, 23 Feb 2003 00:29:44 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302230532.h1N5WeM03077@sydney.East.Sun.COM> Date: Sun, 23 Feb 2003 00:32:47 -0500 To: Reply-To: Subject: Question about EAP payload X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been reading the new draft of IKEv2, which has not yet been announced, but has been submitted. Anyway, under EAP payload, there seems to be "OTP", "MD5-challenge", and "generic token card". But there doesn't seem to be anything there for just plain sending a name and password. Is this intentional, perhaps because MD5-challenge is considered better? (though it requires the server to store a password-equivalent, whereas sending password in-the-clear allows the server to store hashes of passwords) Or is name/password really covered under "generic token card", because EAP just passes text back and forth, and the server could ask for name and password, and the client could send it? Radia From owner-ipsec@lists.tislabs.com Sun Feb 23 05:15:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1NDFHd12341; Sun, 23 Feb 2003 05:15:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26200 Sun, 23 Feb 2003 07:45:12 -0500 (EST) X-Originating-IP: [217.29.140.15] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: Software Library for programatic implementation of IPSec/IKE Date: Sun, 23 Feb 2003 14:48:32 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2003 12:48:32.0834 (UTC) FILETIME=[DF741220:01C2DB39] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I'm trying to implement some of the IKE messages and Ipsec functions programatically, for research purposes. Is there available any ready software libraries for the core operations?, i.e. ready codes implementing the algorithms of authentication and encryption for IPsec/IKE messages? Thank you v.much. Mohammad Awad Computer Engineering Dept, Faculty of Engineering, Ain Shams University. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Sun Feb 23 06:34:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1NEYfd14848; Sun, 23 Feb 2003 06:34:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26352 Sun, 23 Feb 2003 09:05:22 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: 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: Fri, 21 Feb 2003 10:17:41 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / IMC Subject: Fwd: Last Call: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an IETF last call that is quite relevant to the WG. >To: IETF-Announce: ; >Cc: mobile-ip@sunroof.eng.sun.com >From: The IESG >SUBJECT: Last Call: Using IPsec to Protect Mobile IPv6 Signaling > between Mobile Nodes and Home Agents to Proposed Standard >Reply-to: iesg@ietf.org >Date: Fri, 21 Feb 2003 12:40:53 -0500 >Sender: owner-ietf-announce@ietf.org > > >The IESG has received a request from the IP Routing for Wireless/Mobile >Hosts Working Group to consider Using IPsec to Protect Mobile IPv6 >Signaling between Mobile Nodes and Home Agents > 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-3-7. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-03.txt From owner-ipsec@lists.tislabs.com Sun Feb 23 06:44:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1NEiSd15494; Sun, 23 Feb 2003 06:44:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26404 Sun, 23 Feb 2003 09:16:23 -0500 (EST) content-class: urn:content-classes:message Subject: What is the relation between IKE and MIKEY? MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Date: Sun, 23 Feb 2003 20:07:31 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0ECD92AD3DC97C4686C7C172D347FA1A0EF538@nml.netmedia.kjist.ac.kr> Thread-Topic: What is the relation between IKE and MIKEY? Thread-Index: AcLbK8m/YWhTW1aRREyTMhF41sJLaQ== From: "Deuk-Whee Kwak" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA26045 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi What is the relation between IKE and MIKEY? As far as I understand, IKE is mainly used for network-level peer-to-peer key exchange protocol and MIKEY is mainly used for application-level multicast key exchange protocol. Then, is it impossible to use IKE for application-level multicast key exchange protocol? If so, why? Thanks From owner-ipsec@lists.tislabs.com Sun Feb 23 13:32:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1NLWJd07629; Sun, 23 Feb 2003 13:32:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27118 Sun, 23 Feb 2003 16:00:17 -0500 (EST) Message-ID: <002101c2db73$c2527120$58bcfea9@amanda2> Reply-To: "Ahmed Bin Abbas Ahmed Ali Adas" From: "Ahmed Bin Abbas Ahmed Ali Adas" To: "Mohammad Awad" , Cc: References: Subject: Re: Software Library for programatic implementation of IPSec/IKE Date: Sun, 23 Feb 2003 22:42:51 +0300 Organization: KAAU MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mr. Awad First you must be an experienced C++ programmer, second you have to look all the IETF drafts on IPSEC and IKE. As every vendor is trying to keep its secrets away from customers Regards Ahmed Bin Abbas Ahmed Ali Adas Professor of Computer Engineering PH.D.E.E. The University of Colorado at Boulder, Colorado, USA. M.Sc.E.E. The University of Birmingham, Birmingham, U.K. Department of Electrical & Computer Engineering Faculty of Engineering, Kaau, P.O.Box. 35496 Jeddah 21488, AlHIJJAZ, Saudi Arabia. e-mail: alaadas@kaau.edu.sa vox. 966-5-4628251 mobile vox. 966-2-6210008 villa fax. 966-2-6242810 villa vox. 966-2-6952813 EE Secretary fax. 966-2-6401686 faculty ----- Original Message ----- From: "Mohammad Awad" To: Sent: Sunday, February 23, 2003 3:48 PM Subject: Software Library for programatic implementation of IPSec/IKE > Hi all, > I'm trying to implement some of the IKE messages and Ipsec functions > programatically, for research purposes. Is there available any ready > software libraries for the core operations?, i.e. ready codes implementing > the algorithms of authentication and encryption for IPsec/IKE messages? > Thank you v.much. > > Mohammad Awad > Computer Engineering Dept, > Faculty of Engineering, > Ain Shams University. > > > > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > From owner-ipsec@lists.tislabs.com Sun Feb 23 20:24:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1O4OQd16075; Sun, 23 Feb 2003 20:24:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28041 Sun, 23 Feb 2003 22:55:21 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302240358.h1O3wJM12145@sydney.East.Sun.COM> Date: Sun, 23 Feb 2003 22:58:27 -0500 To: Reply-To: Subject: RE: Question about EAP payload X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Clarification...when I said "password in the clear", it isn't really "in the clear". It's encrypted using the IKE key created in messages 1 and 2. But from Bob's point of view, Alice is just sending a raw password, and Bob has a database of hashed passwords. I think Phil's response was based on my being less than clear in my original post (below). Radia Radia Perlman - Boston Center for Networking wrote: > I've been reading the new draft of IKEv2, which > has not yet been announced, but has been submitted. > > Anyway, under EAP payload, there seems to be > "OTP", "MD5-challenge", and "generic token card". > But there doesn't seem to be anything there > for just plain sending a name and password. > > Is this intentional, perhaps because MD5-challenge > is considered better? (though it requires the > server to store a password-equivalent, whereas > sending password in-the-clear allows the > server to store hashes of passwords) > > Or is name/password really covered under "generic > token card", because EAP just passes text back > and forth, and the server could ask for name > and password, and the client could send it? > > Radia From owner-ipsec@lists.tislabs.com Sun Feb 23 21:04:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1O54ud16839; Sun, 23 Feb 2003 21:04:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28110 Sun, 23 Feb 2003 23:40:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <002101c2db73$c2527120$58bcfea9@amanda2> References: <002101c2db73$c2527120$58bcfea9@amanda2> 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, 23 Feb 2003 20:43:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Software Library for programatic implementation of IPSec/IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:42 PM +0300 2/23/03, Ahmed Bin Abbas Ahmed Ali Adas wrote: >First you must be an experienced C++ programmer, second you have to look all >the IETF drafts on IPSEC and IKE. As every vendor is trying to keep its >secrets away from customers Sorry, but this is simply not true. There are three well-known open source implementations of IKE and IPsec (KAME/*BSD, OpenBSD, and FreeSWAN/Linux), and probably a handful of lesser-known ones. Many IPsec VPN vendors have based their code on one or more these. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 24 06:59:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OExRd07607; Mon, 24 Feb 2003 06:59:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29214 Mon, 24 Feb 2003 09:21:07 -0500 (EST) Message-ID: From: "Hallam-Baker, Phillip" To: "'radia.perlman@sun.com'" , ipsec@lists.tislabs.com Subject: RE: Question about EAP payload Date: Sun, 23 Feb 2003 19:45:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0024_01C2DB8D.4792CD30"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C2DB8D.4792CD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Is this intentional, perhaps because MD5-challenge > is considered better? (though it requires the > server to store a password-equivalent, whereas > sending password in-the-clear allows the > server to store hashes of passwords) I have not looked at the MD5 challenge, but I did write the original HTTP digest scheme, we had these arguments ad nauseam and lost, so HTTP throws out base 64 passwords... It makes little sense to attempt to secure a network protocol with a technique that is vulnerable to a network attack. If your network is secure enough to send the password enclair then you do not need IPSEC. There is no way you can have secure password storage and network security unless you go to public key. The one way encrypted password technique adds some security but not really very much. The password file will always be vulnerable to a dictionary attack, a salt only causes minor inconvenience at this point. So the real tradeoff is a choice between strong on the wire protection and depending on the security of the password file and zero security on the wire and depending a heck of a lot but not quite so much on the security of the password file. The digest scheme has one other feature that is worth making an effort to preserve, the domain is used to salt the hash. This means that if a password file is compromised it does not compromise any zone other than the one that compilled it even though we know that the users will share all their passwords on all their accounts. Phill ------=_NextPart_000_0024_01C2DB8D.4792CD30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIyNDAz NDUzNVowIwYJKoZIhvcNAQkEMRYEFNXRR+kKM7bt7obaI21IeGMnDStvMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAMxQzIYUqmJRDIc8U39q03fofGC20vASWkISSZLeqpxQbSrw+ 82RLh7uwmwb6jIG4daei1L++poIysJXJCC7f0u6vJpElaB8pCAH6eMD9qFBWpDqteV3kVo0kHqDK GJAvVc96DJ2tDHn1lC9DFjoVZcCRdpQHZfzSkZ6HzmeDxugAAAAAAAA= ------=_NextPart_000_0024_01C2DB8D.4792CD30-- From owner-ipsec@lists.tislabs.com Mon Feb 24 07:48:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OFmdd11996; Mon, 24 Feb 2003 07:48:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29338 Mon, 24 Feb 2003 10:20:24 -0500 (EST) From: "Yoav Nir" To: , Subject: RE: Question about EAP payload Date: Mon, 24 Feb 2003 17:23:18 +0200 Message-ID: <001701c2dc18$a9327fa0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200302230532.h1N5WeM03077@sydney.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Radia, IANA holds a list of all EAP types here: http://www.iana.org/assignments/ppp-numbers You can scroll down to the section "PPP EAP REQUEST/RESPONSE TYPES" None of these types is a simple passing of username and password akin to, say, PAP authentication. This IMO is a limitation of EAP, because it makes it very difficult to integrate it with various user/password schemes such as Operating System password, RADIUS authentication and others. "Generic token card" was intended for those beeper-sized devices that have a little display with number that changes every minute or so. The user would copy the number from the device to the input field, and this would authenticate him. Since nothing enforces the use of such a device, you could use this to have generic passwords that would be authenticated by whatever method the gateway uses. It just seems like a subversion of the original intent. I am sure other implementations will also use this in a similar way, which is not so bad as long as the so-called clear password is encrypted by IKE. Yoav Nir -----Original Message----- Subject: Question about EAP payload I've been reading the new draft of IKEv2, which has not yet been announced, but has been submitted. Anyway, under EAP payload, there seems to be "OTP", "MD5-challenge", and "generic token card". But there doesn't seem to be anything there for just plain sending a name and password. Is this intentional, perhaps because MD5-challenge is considered better? (though it requires the server to store a password-equivalent, whereas sending password in-the-clear allows the server to store hashes of passwords) Or is name/password really covered under "generic token card", because EAP just passes text back and forth, and the server could ask for name and password, and the client could send it? Radia From owner-ipsec@lists.tislabs.com Mon Feb 24 20:49:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P4nud13904; Mon, 24 Feb 2003 20:49:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA00818 Mon, 24 Feb 2003 23:18:45 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302250421.h1P4LmM03246@sydney.East.Sun.COM> Date: Mon, 24 Feb 2003 23:21:58 -0500 To: Reply-To: Subject: Some IKE/NAT questions X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm reading my sneak preview soon-to-be-available version of IKEv2, and also trying to write a tutorial. Anyway, that's caused me to think deeply about NATs and IKE. Here are some questions. 1) Why are there NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IPs in message 1, since Bob isn't going to do anything with them? It's only those notify payloads in message 2 that affect the protocol, if I'm reading the spec correctly. 2) Would it be useful to do a "You Tarzan" optional payload in message 1? That would allow Alice to initiate communication with a node behind a NAT box that doesn't have a global IP address, but does have a name. The NAT gateway could look for this field in IKE messages and translate the destination IP address to be Bob's (Tarzan's) inner IP address. 3) There's some conniptions going on because helpful NAT boxes are doing strange things with packets on UDP port 500, because of how IKEv1 was specified. (If I'm understanding things, life would have been simpler if IKEv1 simply said to reply to the UDP port from which the packet was received, but instead it said reply to 500). But IKEv1 didn't so NATs look for port 500 and do weird things. As a result, IKEv2 seems to be trying to detect whether there's a NAT, and if so, to use port 3500 so that IKEv2 can do the right thing, i.e., if a NAT has translated the UDP port, simply reply to whatever port you get the packet on. Anyway, why not always use port 3500, and stop using 500 for IKEv2 (other than perhaps trying port 500 in case you're talking to an IKEv1-only node). Radia From owner-ipsec@lists.tislabs.com Mon Feb 24 21:27:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P5RXd14887; Mon, 24 Feb 2003 21:27:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA00861 Mon, 24 Feb 2003 23:33:53 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302250437.h1P4bCM03826@sydney.East.Sun.COM> Date: Mon, 24 Feb 2003 23:37:22 -0500 To: Reply-To: Subject: Another NAT Traversal question X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm worried about UDP/TCP checksums. In tunnel mode, it's not a problem, since the inner IP header doesn't get modified by the NAT. In UDP-encapsulation, it's not a problem, since the inner IP header doesn't get modified, and the outer UDP header is unencrypted and the NAT can fix the checksum. What seems to be a problem is Transport mode. I thought I remembered some sort of payload type that would say "my IP address as I sent it is XXX", so that the receiving ESP could adjust the TCP checksum appropriately once it decrypts the packet. However, I don't see that in the current IKEv2 spec. Instead I see this NAT-DETECTION-SOURCE-IP payload, but that's a hash of the IP address, not the actual address. Now I suppose with only 32 bits of address, the receiver could calculate the actual address on the other side, but that seems needlessly computationally expensive. So...have we given up on Transport mode (would be fine with me), or does this really work somehow and I don't understand it? Radia From owner-ipsec@lists.tislabs.com Mon Feb 24 21:38:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P5cDd15066; Mon, 24 Feb 2003 21:38:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00957 Tue, 25 Feb 2003 00:10:04 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302250513.h1P5DLM05285@sydney.East.Sun.COM> Date: Tue, 25 Feb 2003 00:13:31 -0500 To: Reply-To: Subject: Re: Another NAT Traversal question X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, on an archeological dig in my house I found the original NAT-Traversal internet draft for working with IKEv1 and there was a payload called NAT-OA which had the actual IP address (the thing I said I remembered in my message below). It was indeed used, as I remembered, for fixing the checksums. So why isn't it in IKEv2? Is it an oversight? Radia wrote: >I'm worried about UDP/TCP checksums. > >In tunnel mode, it's not a problem, since >the inner IP header doesn't get modified >by the NAT. > >In UDP-encapsulation, it's not a problem, >since the inner IP header doesn't get modified, >and the outer UDP header is unencrypted and >the NAT can fix the checksum. > >What seems to be a problem is Transport mode. >I thought I remembered some sort of payload >type that would say "my IP address as I >sent it is XXX", so that the receiving ESP >could adjust the TCP checksum appropriately >once it decrypts the packet. However, I >don't see that in the current IKEv2 spec. Instead >I see this NAT-DETECTION-SOURCE-IP payload, >but that's a hash of the IP address, not >the actual address. Now I suppose with only >32 bits of address, the receiver could calculate >the actual address on the other side, but that >seems needlessly computationally expensive. > >So...have we given up on Transport mode (would >be fine with me), or does this really work >somehow and I don't understand it? > >Radia > From owner-ipsec@lists.tislabs.com Mon Feb 24 22:39:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P6dsd16837; Mon, 24 Feb 2003 22:39:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01119 Tue, 25 Feb 2003 01:09:20 -0500 (EST) Reply-To: From: "Sandeep Sakhuja" To: Subject: IPSec over GRE why ? Date: Tue, 25 Feb 2003 11:42:35 +0530 Message-ID: <009c01c2dc94$e5b6ace0$a3074d0a@apac.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I am Sandeep. I am working on implementing IPSec lab. When implementing IPSec across different routing domains we need to use GRE or IIPTran. My Question is why do I have to use the same. IPSec does not support multicast packets that is known, but then my interesting traffic which I need to be protected is not the routing updates, so why do I have to use GRE ? Thanks - Sandeep From owner-ipsec@lists.tislabs.com Tue Feb 25 01:43:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P9hOd17994; Tue, 25 Feb 2003 01:43:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01647 Tue, 25 Feb 2003 04:13:54 -0500 (EST) Message-Id: <200302250913.h1P9DIof057340@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: radia.perlman@sun.com cc: ipsec@lists.tislabs.com Subject: Re: Some IKE/NAT questions In-reply-to: Your message of Mon, 24 Feb 2003 23:21:58 EST. <200302250421.h1P4LmM03246@sydney.East.Sun.COM> Date: Tue, 25 Feb 2003 10:13:18 +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: I'm reading my sneak preview soon-to-be-available version of IKEv2, and also trying to write a tutorial. Anyway, that's caused me to think deeply about NATs and IKE. Here are some questions. => you should read my "address management for IKEv2" proposal (draft-dupont-ikev2-addrmgmt-00.txt). I am working on a second version, I'll send it to you in private. 1) Why are there NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IPs in message 1, => they can't be in message 1 because the used hash is not yet negociated... since Bob isn't going to do anything with them? It's only those notify payloads in message 2 that affect the protocol, if I'm reading the spec correctly. => the specs seems to have many little issues, this is why I wrote my proposal. 2) Would it be useful to do a "You Tarzan" optional payload in message 1? That would allow Alice to initiate communication with a node behind a NAT box that doesn't have a global IP address, but does have a name. The NAT gateway could look for this field in IKE messages and translate the destination IP address to be Bob's (Tarzan's) inner IP address. => the only reasonable help you can get from NATs is their auto-destruction (:-). IMHO I don't believe this (NAT name to address translation) will work or is desirable. 3) There's some conniptions going on because helpful NAT boxes are doing strange things with packets on UDP port 500, because of how IKEv1 was specified. (If I'm understanding things, life would have been simpler if IKEv1 simply said to reply to the UDP port from which the packet was received, but instead it said reply to 500). => yes, this is the issue. In IKEv2 there is an absolute rule about this: replies use reversed addresses and ports.a But IKEv1 didn't so NATs look for port 500 and do weird things. => more weird things (:-). As a result, IKEv2 seems to be trying to detect whether there's a NAT, and if so, to use port 3500 so that IKEv2 => 4500 can do the right thing, i.e., if a NAT has translated the UDP port, simply reply to whatever port you get the packet on. => yes, the NAT traversal itself is well defined in IKEv2. The issue is there are some little details (as you've found according to your next messages) which need to be improved/fixed. Anyway, why not always use port 3500, and stop using 500 for IKEv2 (other than perhaps trying port 500 in case you're talking to an IKEv1-only node). => we had already this discussion (port 500 or a new port). BTW NAT traversal has a major security problem and it is very fine to be able to associate the port 4500 to IPsec (i.e., not only IKE) with active NAT traversal. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Feb 25 01:57:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P9vud19370; Tue, 25 Feb 2003 01:57:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01684 Tue, 25 Feb 2003 04:31:53 -0500 (EST) Message-Id: <200302250932.h1P9W8of057378@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: radia.perlman@sun.com cc: ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Mon, 24 Feb 2003 23:37:22 EST. <200302250437.h1P4bCM03826@sydney.East.Sun.COM> Date: Tue, 25 Feb 2003 10:32: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: I'm worried about UDP/TCP checksums. ... What seems to be a problem is Transport mode. I thought I remembered some sort of payload type that would say "my IP address as I sent it is XXX", so that the receiving ESP => this is the NAT-OA (NAT Original Address) of draft-ietf-ipsec-nat-t-ike-05.txt. could adjust the TCP checksum appropriately once it decrypts the packet. However, I don't see that in the current IKEv2 spec. => yes, someone forgot this... Instead I see this NAT-DETECTION-SOURCE-IP payload, => NAT-D (NAT discovery) from the same draft. but that's a hash of the IP address, not the actual address. Now I suppose with only 32 bits of address, the receiver could calculate the actual address on the other side, but that seems needlessly computationally expensive. => this is why I proposed to replace the hash by the full address. In fact, the hash is useful only when the peer wants to keep its address secret. So...have we given up on Transport mode (would be fine with me), => NO, Transport mode is still very important. or does this really work somehow and I don't understand it? => it doesn't work yet. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Feb 25 07:01:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PF1ed07470; Tue, 25 Feb 2003 07:01:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02296 Tue, 25 Feb 2003 09:20:21 -0500 (EST) Message-Id: <200302251145.GAA24853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-05.txt Date: Tue, 25 Feb 2003 06:45:55 -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 : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-05.txt Pages : 83 Date : 2003-2-24 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-24142455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Feb 25 09:17:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PHHwd16143; Tue, 25 Feb 2003 09:17:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02782 Tue, 25 Feb 2003 11:40:43 -0500 (EST) From: "Jayant Shukla" To: , Subject: RE: Another NAT Traversal question Date: Tue, 25 Feb 2003 08:42:00 -0800 Message-ID: <01d901c2dcec$d1789b50$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200302250437.h1P4bCM03826@sydney.East.Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The checksum is being fixed according to the new IP addresses in the IP header and therefore you don't need the original IP address. >From what I recall, the authors had given up on the transport mode and one of them had stated on this list that only 'tunnel mode' will be pushed for v2. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Radia Perlman - Boston Center for Networking > Sent: Monday, February 24, 2003 8:37 PM > To: ipsec@lists.tislabs.com > Subject: Another NAT Traversal question > > I'm worried about UDP/TCP checksums. > > In tunnel mode, it's not a problem, since > the inner IP header doesn't get modified > by the NAT. > > In UDP-encapsulation, it's not a problem, > since the inner IP header doesn't get modified, > and the outer UDP header is unencrypted and > the NAT can fix the checksum. > > What seems to be a problem is Transport mode. > I thought I remembered some sort of payload > type that would say "my IP address as I > sent it is XXX", so that the receiving ESP > could adjust the TCP checksum appropriately > once it decrypts the packet. However, I > don't see that in the current IKEv2 spec. Instead > I see this NAT-DETECTION-SOURCE-IP payload, > but that's a hash of the IP address, not > the actual address. Now I suppose with only > 32 bits of address, the receiver could calculate > the actual address on the other side, but that > seems needlessly computationally expensive. > > So...have we given up on Transport mode (would > be fine with me), or does this really work > somehow and I don't understand it? > > Radia From owner-ipsec@lists.tislabs.com Tue Feb 25 09:18:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PHI4d16170; Tue, 25 Feb 2003 09:18:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02806 Tue, 25 Feb 2003 11:45:49 -0500 (EST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Subject: RE: Some IKE/NAT questions Date: Tue, 25 Feb 2003 11:48:46 -0500 Message-ID: Thread-Topic: Some IKE/NAT questions thread-index: AcLcuyvUHoo9y6s1QQegGtlYjBcQxQAMQGLV From: "Fridie, Brian" To: "Francis Dupont" Cc: X-OriginalArrivalTime: 25 Feb 2003 16:48:46.0923 (UTC) FILETIME=[C3BF01B0:01C2DCED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA02803 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk => we had already this discussion (port 500 or a new port). BTW NAT traversal has a major security problem and it is very fine to be able to associate the port 4500 to IPsec (i.e., not only IKE) with active NAT traversal. What is the major security problem? Thx -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Tue 2/25/2003 4:13 AM To: radia.perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: Re: Some IKE/NAT questions In your previous mail you wrote: I'm reading my sneak preview soon-to-be-available version of IKEv2, and also trying to write a tutorial. Anyway, that's caused me to think deeply about NATs and IKE. Here are some questions. => you should read my "address management for IKEv2" proposal (draft-dupont-ikev2-addrmgmt-00.txt). I am working on a second version, I'll send it to you in private. 1) Why are there NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IPs in message 1, => they can't be in message 1 because the used hash is not yet negociated... since Bob isn't going to do anything with them? It's only those notify payloads in message 2 that affect the protocol, if I'm reading the spec correctly. => the specs seems to have many little issues, this is why I wrote my proposal. 2) Would it be useful to do a "You Tarzan" optional payload in message 1? That would allow Alice to initiate communication with a node behind a NAT box that doesn't have a global IP address, but does have a name. The NAT gateway could look for this field in IKE messages and translate the destination IP address to be Bob's (Tarzan's) inner IP address. => the only reasonable help you can get from NATs is their auto-destruction (:-). IMHO I don't believe this (NAT name to address translation) will work or is desirable. 3) There's some conniptions going on because helpful NAT boxes are doing strange things with packets on UDP port 500, because of how IKEv1 was specified. (If I'm understanding things, life would have been simpler if IKEv1 simply said to reply to the UDP port from which the packet was received, but instead it said reply to 500). => yes, this is the issue. In IKEv2 there is an absolute rule about this: replies use reversed addresses and ports.a But IKEv1 didn't so NATs look for port 500 and do weird things. => more weird things (:-). As a result, IKEv2 seems to be trying to detect whether there's a NAT, and if so, to use port 3500 so that IKEv2 => 4500 can do the right thing, i.e., if a NAT has translated the UDP port, simply reply to whatever port you get the packet on. => yes, the NAT traversal itself is well defined in IKEv2. The issue is there are some little details (as you've found according to your next messages) which need to be improved/fixed. Anyway, why not always use port 3500, and stop using 500 for IKEv2 (other than perhaps trying port 500 in case you're talking to an IKEv1-only node). => we had already this discussion (port 500 or a new port). BTW NAT traversal has a major security problem and it is very fine to be able to associate the port 4500 to IPsec (i.e., not only IKE) with active NAT traversal. Thanks Francis.Dupont@enst-bretagne.fr *** CONFIDENTIALITY NOTICE *** This email and any files transmitted with it are confidential and intended for the listed recipient(s). If you have received this email in error please notify the sender by return mail. Opinions, conclusions and other information in this message that do not relate to official company business shall be understood as neither given nor endorsed by Datavision, Inc. From owner-ipsec@lists.tislabs.com Tue Feb 25 09:50:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PHoad18523; Tue, 25 Feb 2003 09:50:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02862 Tue, 25 Feb 2003 12:21:11 -0500 (EST) To: Cc: From: Derek Atkins Subject: Re: IPSec over GRE why ? References: <009c01c2dc94$e5b6ace0$a3074d0a@apac.cisco.com> Date: 25 Feb 2003 12:23:44 -0500 In-Reply-To: <009c01c2dc94$e5b6ace0$a3074d0a@apac.cisco.com> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why don't you ask the person who told you to use GRE? -derek "Sandeep Sakhuja" writes: > Hi > > I am Sandeep. I am working on implementing IPSec lab. When implementing IPSec > across different routing domains we need to use GRE or IIPTran. My Question is > why do I have to use the same. IPSec does not support multicast packets that is > known, but then my interesting traffic which I need to be protected is not the > routing updates, so why do I have to use GRE ? > > Thanks > - Sandeep > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 25 11:38:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PJcRd25088; Tue, 25 Feb 2003 11:38:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03263 Tue, 25 Feb 2003 14:01:44 -0500 (EST) To: ipsec@lists.tislabs.com Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-ctr-03.txt From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Feb 2003 14:04:49 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments for the ciph-aes-ctr internet draft, for progression to Proposed Standard. This last call will expire on March 4th. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Feb 25 12:12:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PKCud25962; Tue, 25 Feb 2003 12:12:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03343 Tue, 25 Feb 2003 14:40:05 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IPSec over GRE why ? Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 25 Feb 2003 13:43:19 -0600 Message-ID: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> Thread-Topic: IPSec over GRE why ? Thread-Index: AcLdBNpRQN9iTpYAStisz4uZdBrjjQAAONlA From: "Shelton, Raymond A." To: "Derek Atkins" , Cc: X-OriginalArrivalTime: 25 Feb 2003 19:43:20.0214 (UTC) FILETIME=[26506360:01C2DD06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA03340 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wasn't that person, but let's pretend I play him on T.V. for a moment... imagine that I have a GRE tunnel to a remote clinic; further suppose I need the traffic to be IPSec b/c of HIPPA regs. Should I have more accurately asked for IPSec in GRE, as opposed to GRE w/in IPSec? ras -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Tuesday, February 25, 2003 11:24 AM To: ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: Re: IPSec over GRE why ? Why don't you ask the person who told you to use GRE? -derek "Sandeep Sakhuja" writes: > Hi > > I am Sandeep. I am working on implementing IPSec lab. When implementing IPSec > across different routing domains we need to use GRE or IIPTran. My Question is > why do I have to use the same. IPSec does not support multicast packets that is > known, but then my interesting traffic which I need to be protected is not the > routing updates, so why do I have to use GRE ? > > Thanks > - Sandeep > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 25 12:15:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PKFud26095; Tue, 25 Feb 2003 12:15:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03352 Tue, 25 Feb 2003 14:42:07 -0500 (EST) To: ipsec@lists.tislabs.com cc: byfraser@cisco.com Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Feb 2003 14:45:31 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie Kaufman has released the next version of IKEv2 (draft-ietf-ipsec-ikev2-05.txt) and we are slowly but surely getting closer to completion. Many thanks to Charlie and those who contributed text, ideas, and bug fixes to this new version of the ikev2 I-D. At the time when Charlie began his revisions to produce the 05 I-D, there were still a few open issues. In the meantime, some additional issues have opened up, including the discussion between Tero, Francis, and Radia regarding address management and whether IKE v2 adequately handles NAT traversal (particularly in transport mode). Furthermore, ikev2-05 has changed significantly and has much new material to address various concerns addressed by those on the list, including the addition of the agreed-upon handling of legacy authentication, more explicit specifications about when the CERT and CERTREQ packets much be sent and how they should be handled, the addition of crypto suites, and so on. Because of the large amount of changes, and a few remaining open issues, it is clear that it would be premature to issue a last call on the ikev2-05 document. However, in order to continue to make forward progress, what Barbara and I would like to do is to issue a last call on open issues and specific proposals for edits to the ikev2 specification. Specifically, in the next two weeks, we request all members of the IPSEC working group to carefully read and digest the ikev2 specification, and make known any issues they may have with the document, complete with specific changes to the document which they believe would resolve those issues. For example, in the case of the open issue on how to handle configuration, the choices to the working group are: * Keep configuration payload * Remove configuration payload and pursue RFC 3456-style configuration * Keep configuration payload and allow optional RFC 3456-style configuration Depending on how the working group decides this issue in San Francisco, the net effect on the IKE v2 document will ultimately be whether or not section 3.15 (Configuration payload) is removed, and whether or not either the ipsec or ipsra working group shall pursue an update to RFC 3456 to support IKEv2. So we hereby issue a "last call" for open issues regarding the ikev2 I-D that need to be addressed by this working group. This last call will terminate in two weeks, at the commencement of the San Francisco IETF meeting. During this last call period, we will be collecting and summarizing open issues which are brought up, with the goal of resolving all of these issues either before or at the IPSEC working group meeting in San Francisco. After this "issues last call" is completed, the working group will not entertain any additional new issues unless they represent a fundamental flaw to the IKEv2 protocol, and we will be issuing final editing directions to the ikev2 document editor so that we can finish this specification as soon as possible after the San Francisco meeting. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Feb 25 12:26:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PKQNd26401; Tue, 25 Feb 2003 12:26:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03381 Tue, 25 Feb 2003 14:51:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030225114809.024febe0@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 11:51:50 -0800 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: IETF56 - Call for Agenda Items Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We expect much of the SF meeting to be focused on resolving open issues with IKEv2, but if you have other agenda items, please submit them to us. thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Tue Feb 25 13:33:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PLXwd29965; Tue, 25 Feb 2003 13:33:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03646 Tue, 25 Feb 2003 15:59:22 -0500 (EST) To: "Shelton, Raymond A." Cc: , From: "Derek Atkins" Subject: Re: IPSec over GRE why ? References: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> Date: 25 Feb 2003 16:01:20 -0500 In-Reply-To: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> Message-ID: Lines: 59 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, a better question back at you. If you're using IPsec, why do you need a GRE tunnel? What's wrong with just using the IPsec tunnel? Tunneling IPsec within GRE would still leave you open to attack, because you'd have to block all non-IPsec traffic anyways (to make sure someone couldn't insert traffic into your VPN). So what purpose is the GRE serving at that point? Tunneling GRE within IPsec would work, but I would only suggest it if you are trying to tunnel non-IP packets. If you're just trying to tunnel IP packets, then just use IPsec's tunnel-mode and be done with it. -derek "Shelton, Raymond A." writes: > I wasn't that person, but let's pretend I play him on T.V. for a moment... > imagine that I have a GRE tunnel to a remote clinic; further suppose I need the traffic to be IPSec b/c of HIPPA regs. Should I have more accurately asked for IPSec in GRE, as opposed to GRE w/in IPSec? > > ras > > > > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, February 25, 2003 11:24 AM > To: ssakhuja@cisco.com > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSec over GRE why ? > > > Why don't you ask the person who told you to use GRE? > > -derek > > "Sandeep Sakhuja" writes: > > > Hi > > > > I am Sandeep. I am working on implementing IPSec lab. When implementing IPSec > > across different routing domains we need to use GRE or IIPTran. My Question is > > why do I have to use the same. IPSec does not support multicast packets that is > > known, but then my interesting traffic which I need to be protected is not the > > routing updates, so why do I have to use GRE ? > > > > Thanks > > - Sandeep > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 25 14:32:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PMW3d02110; Tue, 25 Feb 2003 14:32:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03788 Tue, 25 Feb 2003 17:01:45 -0500 (EST) To: Lars Eggert Cc: "Shelton, Raymond A." , ssakhuja@cisco.com, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: IPSec over GRE why ? References: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> <3E5BE013.7000809@isi.edu> Date: 25 Feb 2003 16:53:43 -0500 In-Reply-To: <3E5BE013.7000809@isi.edu> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, Lars Eggert writes: > On 2/25/2003 1:01 PM, Derek Atkins wrote: > > Tunneling GRE within IPsec would work, but I would only suggest it if > > you are trying to tunnel non-IP packets. If you're just trying to > > tunnel IP packets, then just use IPsec's tunnel-mode and be done with > > it. > > Not if existing dynamic routing protocols are required inside the > virtual topology. See draft-touch-ipsec. (Details in my earlier reply.) The requirement to run dynamic routing protocols was NOT the question asked. Please re-read Shelton's question before commenting on my answer. Quoting my answer out of context and applying alternate requirements is both rude and unhelpful. In particular, he asked: > imagine that I have a GRE tunnel to a remote clinic; further suppose I > need the traffic to be IPSec b/c of HIPPA regs. Should I have more > accurately asked for IPSec in GRE, as opposed to GRE w/in IPSec? I see nothing in here about dynamic routing protocols. Do you? > Lars -derek PS: I see no earlier reply in this thread. What is the subject and messageID of your earlier reply? -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 25 15:33:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PNXed03586; Tue, 25 Feb 2003 15:33:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03953 Tue, 25 Feb 2003 18:03:16 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66A33@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Theodore Ts'o'" , ipsec@lists.tislabs.com Cc: byfraser@cisco.com Subject: RE: Configuration portion of OPEN ISSUES... Date: Tue, 25 Feb 2003 15:02:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Tuesday, February 25, 2003 11:46 AM > To: ipsec@lists.tislabs.com > Cc: byfraser@cisco.com > Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt > --SNIP-- > > For example, in the case of the open issue on how to handle > configuration, the choices to the working group are: > > * Keep configuration payload > * Remove configuration payload and pursue RFC > 3456-style configuration > * Keep configuration payload and allow optional > RFC 3456-style configuration If I'm reading your options correctly, we (I THINK) had some consensus (or at least strong interest) on the list for the last option, and some folks are working on text to clarify it. Did you mean to capture with the last bullet the case where we use a ModeCFG-like format to run a DHCP (or other) discovery/request in IKE? This would be very different than "3456-style" configuration, as 3456 occurs in Phase2. Just trying to clarify what you meant... thanks, Gregory. From owner-ipsec@lists.tislabs.com Tue Feb 25 16:44:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q0iKd05309; Tue, 25 Feb 2003 16:44:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04049 Tue, 25 Feb 2003 19:18:32 -0500 (EST) Message-Id: <200302260018.h1Q0I0of060264@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Fridie, Brian" cc: ipsec@lists.tislabs.com Subject: Re: Some IKE/NAT questions In-reply-to: Your message of Tue, 25 Feb 2003 11:48:46 EST. Date: Wed, 26 Feb 2003 01:18:00 +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: => we had already this discussion (port 500 or a new port). BTW NAT traversal has a major security problem and it is very fine to be able to associate the port 4500 to IPsec (i.e., not only IKE) with active NAT traversal. What is the major security problem? => draft-dupont-transient-pseudonat-01.txt (the easy fix is to enable NAT traversal only when it is needed) Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Feb 25 16:44:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q0iKd05308; Tue, 25 Feb 2003 16:44:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04043 Tue, 25 Feb 2003 19:15:31 -0500 (EST) Message-Id: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: radia.perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Tue, 25 Feb 2003 08:42:00 PST. <01d901c2dcec$d1789b50$5803a8c0@trlhpc1> Date: Wed, 26 Feb 2003 01:15:13 +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: The checksum is being fixed according to the new IP addresses in the IP header and therefore you don't need the original IP address. => so you give up the transport checksum ? >From what I recall, the authors had given up on the transport mode and one of them had stated on this list that only 'tunnel mode' will be pushed for v2. => I am afraid that there is no consensus to drop the transport mode, so as the NAT traversal is in the charter, there is a problem to really solve. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Feb 25 18:35:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q2Zed08020; Tue, 25 Feb 2003 18:35:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04421 Tue, 25 Feb 2003 20:57:17 -0500 (EST) Message-Id: <200302260159.h1Q1xvIo031850@marajade.sandelman.ottawa.on.ca> To: Barbara Fraser cc: ipsec@lists.tislabs.com, tytso@mit.edu Subject: Re: IETF56 - Call for Agenda Items In-reply-to: Your message of "Tue, 25 Feb 2003 11:51:50 PST." <4.3.2.7.2.20030225114809.024febe0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 25 Feb 2003 20:59:57 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Barbara" == Barbara Fraser writes: Barbara> We expect much of the SF meeting to be focused on resolving open Barbara> issues with IKEv2, but if you have other agenda items, please Barbara> submit them to us. I have a compromise proposal between dhcp-over-ipsec and modecfg, which is out there as: draft-richardson-ipsec-dhcp-over-ike-00.txt ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Feb 25 18:59:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q2xOd08567; Tue, 25 Feb 2003 18:59:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04504 Tue, 25 Feb 2003 21:19:24 -0500 (EST) Message-Id: <200302260222.h1Q2MClE032467@marajade.sandelman.ottawa.on.ca> To: Gregory Lebovitz cc: ipsec@lists.tislabs.com Subject: Re: dhcp-over-ike.txt In-reply-to: Your message of "Tue, 25 Feb 2003 15:26:20 PST." <541402FFDC56DA499E7E13329ABFEA87E66A35@SARATOGA.netscreen.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 25 Feb 2003 21:22:11 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Gregory" == Gregory Lebovitz writes: Gregory> Maybe I should post this discussion to the list since the draft Gregory> is now published? Yes. >> -----Original Message----- From: Michael Richardson >> [mailto:mcr@sandelman.ottawa.on.ca] Sent: Sunday, February 16, 2003 >> 7:40 AM To: Gregory Lebovitz; Scott Kelly; Ted.Lemon@nominum.com >> Subject: dhcp-over-ike.txt Gregory> --SNIP-- Gregory> sect 2 >> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, DHCP(disc)} --> >> Gregory> Am I correct in ascerting that at this point the Security Gregory> Gateway would need to do a policy check on the IDi to ensure Gregory> that (a) user is acceptable, (b) users request should/is Gregory> permitted to be forwarded to configuration server? I would think so, yes. Gregory> Your draft is specifically for DHCP. However, there may be other Gregory> mechanisms that large enterprises/xSPs want to use to do address Gregory> assignment/client config, including RADIUS, PPPoE (which Gregory> backends to a RADIUS server), ActiveDirectory, LDAP (though less Gregory> common). Is there a way we could make the actual request more Gregory> generic to accomodate more responder types, including DCHP? None of those other protocols involve the actual client. I.e. they do not involve communication with the client. PPPoE, as you point out, is really RADIUS or AAA. There are no DHCP servers that I'm aware of that communicate with any of those protocols for provisioning. I don't see why there shouldn't be. This implies that the gateway needs to understand the DHCP request, and needs to know how to translate this to RADIUS, COPS, etc.. Gregory> This is the idea I voiced earlier of using the ModeCFG formats, Gregory> but being able to have the Gateway use any number of back-end Gregory> mechanisms, including on-board services, to actually serve the That's fine, but you are now forcing the client to speak two protocols: 1) modeCfg 2) DHCP over something Gregory> configuration elements. Those not covered by ModeCFG could then Gregory> be acquired by the client via a DHCP request (or [whatever] Gregory> request) directly to the CONFIGURATION server once the CHILD-SA Gregory> is established. Does this make any sense? Yes, it certainly could be a solution. It seems to just involve more code. >> 3. Comparisons with mode-cfg Gregory> --SNIP-- >> The major advantage of DHCP-over-IKE vs mode-cfg is that it leverages >> all of the DHCP protocol infrastructure for configuration of the end >> host. Further, it naturally interacts with the DHCP infrastructure at >> the enterprise end. Gregory> And the major disadvantage is that it limits us to DHCP only, Gregory> whereas others may want to use other forms of client Gregory> configuration. I just don't see this. *Some* trusted entity will have to query the X/FOO/BAR server and translate the result to DHCP so that the client can understand it. Gregory> --SNIP-- >> DHCP-over-IPsec requires that a very strange IPsec SA be configured >> for: 0.0.0.0/0:udp/67 <->0.0.0.0/0:udp/68. Note that extreme care >> must be taken to make sure that this does not also catch packets >> destined to the DHCP server on the physical wire. This SA MUST be be >> torn down before any traffic is mis-directed on it. Further, it is >> very difficult to configure a mobile system that must maintain tunnels >> to two enterprises. Gregory> So it takes longer than if we did it in IKE, because we have to Gregory> set up a CHILD-SA, do the special DHCP, tear it down, and set up Gregory> another CHILD-SA before we can begin sending application Gregory> traffic. Yes. AND, it really is a fundamental change from 2401. Particularly difficult for the gateway, which can have a lot of these strange 0.0.0.0/0:68 SPDs at the same time. I can't imagine what would happen on a box that runs IKE on a different processor than the IPsec. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPlwk0YqHRg3pndX9AQFbkwQA475O/JlZky1PJ86wANYEuLJRF5stjwQa OnqTn7KNb7J4o7/AkYxWhJAycWuDol0BdyZwgAmfOrCtF3kfossTI/OuizaUWIUw Xlok3Y5UH1oooGzYpAl70V1LtMzR9kvxKilikUxT8GVE0iPpdOjBr8lSsgdLdXVq 3+QwuM6gq1w= =X5R7 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 25 21:32:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q5WDd12827; Tue, 25 Feb 2003 21:32:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA04896 Tue, 25 Feb 2003 23:53:07 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302260455.h1Q4tqM01659@sydney.East.Sun.COM> Date: Tue, 25 Feb 2003 23:56:04 -0500 To: Reply-To: Subject: Now a question on legacy authentication X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems like EAP is just sending a string to be displayed at the client end, and the client (with the help of the human) constructs a string to be sent back. So, why is it necessary to have the legacy authentication type sent by Bob in message 4? It doesn't look like the client does anything different based on the legacy authentication type. Radia From owner-ipsec@lists.tislabs.com Wed Feb 26 00:53:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q8rEd07982; Wed, 26 Feb 2003 00:53:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05230 Wed, 26 Feb 2003 03:20:32 -0500 (EST) Message-ID: <3E5C7970.5000306@kolumbus.fi> Date: Wed, 26 Feb 2003 10:23:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: radia.perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: Re: Now a question on legacy authentication References: <200302260455.h1Q4tqM01659@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking wrote: > It seems like EAP is just sending a string > to be displayed at the client end, and > the client (with the help of the human) > constructs a string to be sent back. > > So, why is it necessary to have the legacy > authentication type sent by Bob in message 4? > It doesn't look like the client does anything > different based on the legacy authentication type. I'm not sure I understand the question. Are we talking about ikev2-05 and its use of EAP? EAP authentication methods are not just strings to be displayed to the user. As a result of executing some password authentication, the user could be prompted for a password. But the password could also be stored, or the authentication could be done by some card, and the card could verify the user's presence at device boot-up time with a PIN. The EAP protocol does have a Notification message which contains a string to be displayed to the user, but that message has no side-effects to the operation of the protocol as such. With "legacy authentication type", do you mean the Type field in the EAP header? This value is really only used on the first request, but is still copied on all subsequent responses and further requests, if any. Also, now that I took a quick look at the EAP support in the IKEv2 document, I have a few questions and comments of my own: - Section 2.16 text "... be added in the future without updating this specification, the protocols expected to be used most commonly are fully documented here ..." I'm not sure this is the case (the most commonly used claim). Also, None of the EAP methods seem to have been documented in this draft. It mentions the type numbers for some methods, but not the normative behaviour. See Section 3 of RFC 2284. - Section 2.16, AUTH rules: "For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both ..." This rule has to be more specific. In particular, the shared key is typically not available starting from the first message. It may be available somewhere in the middle of the method or at the end. My suggestion would be to require the AUTH payload only on the messages that come after the EAP method has finished, and forbid it on other ones. - Section 2.16, the message diagram could probably be clearer on what it means when the number of messages in EAP varies. - Section 2.16 text: "The Initiator of an IKE-SA using EAP SHOULD be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the Responder sends notification messages and/or retries the authentication prompt." Why ten? Actually, this sounds a bit small to cover all possible methods. Is there a reason why we could not just wait until a timeout occurs or something like that? - Section 2.16 text "The protocol terminates when the Responder sends the Initiator and EAP payload containing either a success or failure type." A suggested rewrite: "Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any terminate the IKE exchange by sending an EAP payload containing the Failure message. The initiator MUST fail the IKE exchange, if the chosen EAP authentication method terminates unsuccessfully, or if an EAP payload with the Failure message has been received. The IKE exchange is successfully terminated if the authentication method terminates successfully, and an EAP payload with the Success message has been received." - Section 3.16 s/NAC/Nak/ - Section 3.16 Type-Data field explanation. Now I'm starting to see the reason for your questions... Uh... this explanation is wrong. The contents of the Type-Data field depend entirely on the selected authentication mechanism. For EAP TLS or EAP AKA, for instance, the contents are method specific cryptographic messages. Also, while the Nak case for Type-Data is more or less inline with RFC 2284, this behaviour has been clarified and extended in RFC 2284bis. Suggested rewrite: "Type-Data The Type-Data field varies with the Type of Request and the associated Response. For the documentation of the EAP methods, see [RFC2284bis]." - Section 3.16, it says: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." This behaviour is fine, but I'd like to rewrite this in a slightly more specific way: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, requests with Type set to Identity SHOULD NOT be sent. Requests received with this type SHOULD be silently discarded." Hmm... it still isn't clear to me how this would work if someone actually wants to go against the SHOULD NOT. Is there an attack if we allow initiators to respond to identity requests? I'm not familiar enough with IKEv2 to understand whether the identity passed in it is protected or not. If it is, maybe we should just use MUST NOT. - Perhaps a reference to 2284bis would be more appropriate (draft-ietf-eap-rfc2284bis-01.txt). This document expected to be done sometime after the next IETF meeting. Jari From owner-ipsec@lists.tislabs.com Wed Feb 26 00:53:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q8rEd07981; Wed, 26 Feb 2003 00:53:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05236 Wed, 26 Feb 2003 03:24:32 -0500 (EST) Message-ID: <3E5C7A66.902@f-secure.com> Date: Wed, 26 Feb 2003 10:27:18 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Jayant Shukla , radia.perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question References: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 08:27:19.0712 (UTC) FILETIME=[E0C8B200:01C2DD70] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > >From what I recall, the authors had given up on the transport mode and > one of them had stated on this list that only 'tunnel mode' will be > pushed for v2. > > => I am afraid that there is no consensus to drop the transport mode, > so as the NAT traversal is in the charter, there is a problem to > really solve. Let's ask it this way: what is the real need for transport mode ESP to work over NAT? You can do everything with tunnel mode ESP, including L2TP/IPsec. ps. I do not represent anybody else except me personally on this issue. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Feb 26 01:24:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q9Ord12471; Wed, 26 Feb 2003 01:24:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05325 Wed, 26 Feb 2003 03:57:42 -0500 (EST) From: "Yoav Nir" To: "'Ari Huttunen'" , Subject: RE: Another NAT Traversal question Date: Wed, 26 Feb 2003 11:00:23 +0200 Message-ID: <001201c2dd75$7fd65420$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3E5C7A66.902@f-secure.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sure you can do L2TP/IPsec with tunnel mode, but that wastes another 20 bytes for the extra IP header. This is AFAIK the only reason to prefer transport mode. I also believe that transport mode is not worth the trouble, but other people disagree. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen Sent: Wednesday, February 26, 2003 10:27 AM To: Francis Dupont Cc: Jayant Shukla; radia.perlman@sun.com; ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question Francis Dupont wrote: > >From what I recall, the authors had given up on the transport mode and > one of them had stated on this list that only 'tunnel mode' will be > pushed for v2. > > => I am afraid that there is no consensus to drop the transport mode, > so as the NAT traversal is in the charter, there is a problem to > really solve. Let's ask it this way: what is the real need for transport mode ESP to work over NAT? You can do everything with tunnel mode ESP, including L2TP/IPsec. ps. I do not represent anybody else except me personally on this issue. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Feb 26 01:58:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q9wUd16708; Wed, 26 Feb 2003 01:58:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA05411 Wed, 26 Feb 2003 04:24:48 -0500 (EST) From: "Yoav Nir" To: Subject: RE: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt Date: Wed, 26 Feb 2003 11:27:51 +0200 Message-ID: <001301c2dd79$565d4690$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Seems that only a week ago there was a wide-spread agreement on using the configuration payload as it is in -05, with the client later completing any missing data using tunneled DHCP informs. This would mean that the security gateway would not have to know the DHCP protocol. Both RFC 3456 and the dhcp-over-ike drafts make sense only if IP addresses are allocated by a DHCP server. Of the two, I prefer the dhcp-over-ike draft, but I still see some drawbacks: - If the gateway has an internal pool or if it obtains the addresses from a RADIUS server, it will have to translate the requests and replies from and to DHCP format. DHCP format is not simple and contains many irrelevant fields. Even if allocation is done using a DHCP server, the gateway will need to learn to be a DHCP relay agent. The configuration payload is much simpler. - DHCP packets are large (over 300 bytes) and unbounded in size. The IKE packets are already large enough to cause trouble occasionally. We don't need this extra baggage. Configuration payloads are small by comparison. - DHCP tunneling in IKE requires at least 4 packets, 6 if the client makes an attempt to obtain a previous address. This will make the IKE negotiation go to 6 or 8 packets as opposed to 4 in -05. I am in favor of the first option: use CP to pass IP address, subnet mask and DHCP server address (optionally also NBNS, DNS) and optionally use DHCP inform for all the rest. Yoav Nir -----Original Message----- Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt For example, in the case of the open issue on how to handle configuration, the choices to the working group are: * Keep configuration payload * Remove configuration payload and pursue RFC 3456-style configuration * Keep configuration payload and allow optional RFC 3456-style configuration ========================================================================= The content of this message may contain private views and opinions which do not constitute a formal disclosure or commitment. From owner-ipsec@lists.tislabs.com Wed Feb 26 03:31:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QBVld26015; Wed, 26 Feb 2003 03:31:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05653 Wed, 26 Feb 2003 05:42:02 -0500 (EST) Message-Id: <200302261042.h1QAgEof062239@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ari Huttunen cc: Jayant Shukla , radia.perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Wed, 26 Feb 2003 10:27:18 +0200. <3E5C7A66.902@f-secure.com> Date: Wed, 26 Feb 2003 11:42:14 +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: Francis Dupont wrote: > >From what I recall, the authors had given up on the transport mode and > one of them had stated on this list that only 'tunnel mode' will be > pushed for v2. > > => I am afraid that there is no consensus to drop the transport mode, > so as the NAT traversal is in the charter, there is a problem to > really solve. Let's ask it this way: what is the real need for transport mode ESP to work over NAT? => we have no choice : we need transport mode and there are NATs (including in the charter)... You can do everything with tunnel mode ESP, including L2TP/IPsec. => there are two important differences between tunnel and transport modes: overhead and selector checking. The first one can be removed with good compression, including header compression, but the second cannot: tunnel mode and transport mode over a tunnel will be ever different. IMHO if we have to give up something, it should be the NAT traversal... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Feb 26 04:02:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QC2kd27836; Wed, 26 Feb 2003 04:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05783 Wed, 26 Feb 2003 06:30:18 -0500 (EST) Date: Wed, 26 Feb 2003 12:33:32 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: The CR payload still In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : explicit specifications about when the CERT and CERTREQ packets much : be sent and how they should be handled, the addition of crypto suites, : I would still raise the issue of CR payload usage I mentioned a while back. The ability for initiator to request 'any' cert from responder (regardless of the CA) would be in my opinion important to have. The way specs seems to suggest implementation to work is that CERT is not sent if CERTREQ is not sent, if CERTREQ was sent but no such CA was found CERT is still not sent. This means that you must know the CA before hand or you must have the cert cached for the exchange to ever succeed (since you won't have the public key to verify the AUTH). Now, maybe in ideal world everyone always know who everyone else trusts or everybody trusts always the same CAs but I think in real world this won't be the case. The way in IKEv1 this was done was to unofficially agree between vendors (eg. in every bakeoff for past several years I've attended to) that empty CR payload means kind of "any" request. IKEv2 does not allow this, but pki-profile provides a loophole for it anyway. What I am suggesting is that empty CR payloads would be allowed in IKEv2 (explicitly), or by some other mechanism (eg. ANY cert encoding (but I don't like this very much)). The second issue that would be nice to consider and decide is the expansion of usage of CERTREQ to allow the verification of whether a cached cert is the correct or not by including eg. the hash of the cert in CERTREQ. This also relates to the earlier revised identity discussion on the list. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Wed Feb 26 04:42:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QCgxd29936; Wed, 26 Feb 2003 04:42:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05884 Wed, 26 Feb 2003 07:01:18 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302261204.h1QC4DS03751@sydney.East.Sun.COM> Date: Wed, 26 Feb 2003 07:04:25 -0500 To: Reply-To: Subject: Re: Now a question on legacy authentication X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ah. I thought about it a bit, and I'll reply to my own question. wrote: >It seems like EAP is just sending a string >to be displayed at the client end, and >the client (with the help of the human) >constructs a string to be sent back. > >So, why is it necessary to have the legacy >authentication type sent by Bob in message 4? >It doesn't look like the client does anything >different based on the legacy authentication type. > It's not true that EAP just passes strings back and forth. The client does have 3 distinct types of behavior with the current EAP payloads: 1) MD5-challenge: has to hash the user's password and the challenge 2) OTP: perhaps just pass strings back and forth like 3), but perhaps calculate the nth hash of the user's password and salt, in which case it would be a distinct behavior 3) passing strings back and forth. In answer to my question about sending password (encrypted with the Diffie-Hellman key), Yoav Nir said: >>"Generic token card" was intended for those beeper-sized devices that have a >>little display with number that changes every minute or so. The user would >>copy the number from the device to the input field, and this would >>authenticate him. Since nothing enforces the use of such a device, you >>could use this to have generic passwords that would be authenticated by >>whatever method the gateway uses. It just seems like a subversion of the >>original intent. I am sure other implementations will also use this in a >>similar way, which is not so bad as long as the so-called clear password is >>encrypted by IKE. So, it seems like calling this 3rd method "transparent string passing" rather than "generic token card" would have avoided confusing me on both issues. Any interest on renaming that EAP payload, and making it clear that a new EAP type is only required if it changes client behavior? Radia From owner-ipsec@lists.tislabs.com Wed Feb 26 07:47:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QFlYd11077; Wed, 26 Feb 2003 07:47:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06439 Wed, 26 Feb 2003 10:12:05 -0500 (EST) Message-ID: <0A11633F61BD9F40B43ABCC694004F93D80269@zsc3c026.us.nortel.com> From: "Shashi Kiran" To: "'Shelton, Raymond A.'" , Derek Atkins , ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: IPSec over GRE why ? Date: Tue, 25 Feb 2003 14:58:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DD21.752B9F0C" 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_01C2DD21.752B9F0C Content-Type: text/plain Presumably because it's the way Cisco treats Ipsec which is as an encapsulation. This means you cannot run your routing protocols over it directly. Cisco requires GRE for that, which though good in certain cases, is mostly an overhead. Many other vendors treat Ipsec as an interface, modelling it as a logical construct, enabling running routing protocols directly over the Ipsec interfaces. Rgds Shashi Kiran -----Original Message----- From: Shelton, Raymond A. [mailto:SheltonR@health.missouri.edu] Sent: Tuesday, February 25, 2003 11:43 AM To: Derek Atkins; ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: IPSec over GRE why ? I wasn't that person, but let's pretend I play him on T.V. for a moment... imagine that I have a GRE tunnel to a remote clinic; further suppose I need the traffic to be IPSec b/c of HIPPA regs. Should I have more accurately asked for IPSec in GRE, as opposed to GRE w/in IPSec? ras -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Tuesday, February 25, 2003 11:24 AM To: ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: Re: IPSec over GRE why ? Why don't you ask the person who told you to use GRE? -derek "Sandeep Sakhuja" writes: > Hi > > I am Sandeep. I am working on implementing IPSec lab. When implementing IPSec > across different routing domains we need to use GRE or IIPTran. My Question is > why do I have to use the same. IPSec does not support multicast packets that is > known, but then my interesting traffic which I need to be protected is not the > routing updates, so why do I have to use GRE ? > > Thanks > - Sandeep > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com ------_=_NextPart_001_01C2DD21.752B9F0C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IPSec over GRE why ? Presumably because it's the way Cisco treats Ipsec = which is as an encapsulation. This means you cannot run your routing = protocols over it directly. Cisco requires GRE for that, which though = good in certain cases, is mostly an overhead. Many other vendors treat = Ipsec as an interface, modelling it as a logical construct, enabling = running routing protocols directly over the Ipsec = interfaces. Rgds Shashi Kiran -----Original Message----- From: Shelton, Raymond A. [<3d.htm>mailto:SheltonR@health.miss= ouri.edu] Sent: Tuesday, February 25, 2003 11:43 AM To: Derek Atkins; ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: IPSec over GRE why ? I wasn't that person, but let's pretend I play him on = T.V. for a moment... imagine that I have a GRE tunnel to a remote clinic; = further suppose I need the traffic to be IPSec b/c of HIPPA regs. = Should I have more accurately asked for IPSec in GRE, as opposed to GRE = w/in IPSec? ras -----Original Message----- From: Derek Atkins [<3d.htm>mailto:derek@ihtfp.com] Sent: Tuesday, February 25, 2003 11:24 AM To: ssakhuja@cisco.com Cc: ipsec@lists.tislabs.com Subject: Re: IPSec over GRE why ? Why don't you ask the person who told you to use = GRE? -derek "Sandeep Sakhuja" = writes: > Hi > > I am Sandeep. I am working on implementing = IPSec lab. When implementing IPSec > across different routing domains we need to use = GRE or IIPTran. My Question is > why do I have to use the same. IPSec does not = support multicast packets that is > known, but then my interesting traffic which I = need to be protected is not the > routing updates, so why do I have to use GRE = ? > > Thanks > - Sandeep > -- Derek = Atkins Computer and = Internet Security Consultant = derek@ihtfp.com &nb= sp; www.ihtfp.com ------_=_NextPart_001_01C2DD21.752B9F0C-- From owner-ipsec@lists.tislabs.com Wed Feb 26 07:47:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QFlYd11079; Wed, 26 Feb 2003 07:47:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06433 Wed, 26 Feb 2003 10:11:05 -0500 (EST) Message-ID: <3E5BEA31.8090608@isi.edu> Date: Tue, 25 Feb 2003 14:12:01 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins CC: "Shelton, Raymond A." , ssakhuja@cisco.com, ipsec@lists.tislabs.com Subject: Re: IPSec over GRE why ? References: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> <3E5BE013.7000809@isi.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050606030407010104080504" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050606030407010104080504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 2/25/2003 1:53 PM, Derek Atkins wrote: > > The requirement to run dynamic routing protocols was NOT the question > asked. Please re-read Shelton's question before commenting on my > answer. Quoting my answer out of context and applying alternate > requirements is both rude and unhelpful. > > In particular, he asked: > >>imagine that I have a GRE tunnel to a remote clinic; further suppose I >>need the traffic to be IPSec b/c of HIPPA regs. Should I have more >>accurately asked for IPSec in GRE, as opposed to GRE w/in IPSec? > > I see nothing in here about dynamic routing protocols. Do you? Sorry. I missed that it was Raymond and not Sandeep (the sender of the original email) who sent the email you replied to. I agree that Raymond's requirements are probably different from Sandeep's. > PS: I see no earlier reply in this thread. What is the subject and > messageID of your earlier reply? Message-ID: <3E5B1BA1.6050406@isi.edu> Date: Mon, 24 Feb 2003 23:30:41 -0800 From: Lars Eggert To: ssakhuja@cisco.com CC: ipsec@lists.tislabs.com, xbone Subject: Re: IPSec over GRE why ? Lars -- Lars Eggert USC Information Sciences Institute --------------ms050606030407010104080504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDIyNTIyMTIwMVowIwYJKoZIhvcNAQkEMRYEFJEYERMp9zu+b5WLFKVX Quy53ojnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAaN708/9MSPoic/36ZXTzhskS2FxxgWqZFH3r gROdRCkXVoMCPaacZlm35tNa0n+DLzWPR9DqRhqfX2l0zcJjlQy5plISjyyFh0aAQwJ4EIy9 cnqCV3ViXaBmyAGYimyXgYffCWLVtLm8Fla6U9dtqtz1uheoMX1tB4txReUpmLDMELxqHWWT CG795GLohGD3Cu31pfKjVKYnvkP9ELxujzMUbeD06lKm8jzCc8LqLHAL77nfc1E0zKSBzbcT kpBU6Vgwk9+aqqGEb72Vmnn587j80n8/pyHlsiEeFSYoQ2iyY9MTrnr3o+SaPFTij72rbgqQ Qcj7dEBIeW02rfoEuQAAAAAAAA== --------------ms050606030407010104080504-- From owner-ipsec@lists.tislabs.com Wed Feb 26 07:48:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QFmCd11123; Wed, 26 Feb 2003 07:48:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06421 Wed, 26 Feb 2003 10:10:02 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168A9F@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Gregory Lebovitz'" , "'Theodore Ts'o'" , ipsec@lists.tislabs.com Cc: byfraser@cisco.com Subject: RE: Configuration portion of OPEN ISSUES... Date: Wed, 26 Feb 2003 13:22:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Theodore, see my comment below. > --SNIP-- > > > > For example, in the case of the open issue on how to handle > > configuration, the choices to the working group are: > > > > * Keep configuration payload > > * Remove configuration payload and pursue RFC > > 3456-style configuration > > * Keep configuration payload and allow optional > > RFC 3456-style configuration > > If I'm reading your options correctly, we (I THINK) had some > consensus (or > at least strong interest) on the list for the last option, > and some folks > are working on text to clarify it. Did you mean to capture > with the last > bullet the case where we use a ModeCFG-like format to run a > DHCP (or other) > discovery/request in IKE? This would be very different than > "3456-style" > configuration, as 3456 occurs in Phase2. > > Just trying to clarify what you meant... thanks, > > Gregory. > To clarify this open issue can we modify the list as follows (in order to not have any confusion on what we are discussing about): 1) Keep configuration payload 2) Remove configuration payload and pursue RFC 3456-style configuration 3) Keep configuration payload and allow optional RFC 3456-style configuration 4) Remove configuration payload and pursue an DHCP-over-IKE style configuration I'm in favour of 2) and can live with 3). Dirk ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain From owner-ipsec@lists.tislabs.com Wed Feb 26 07:48:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QFmOd11152; Wed, 26 Feb 2003 07:48:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06432 Wed, 26 Feb 2003 10:11:04 -0500 (EST) Message-ID: <3E5BE013.7000809@isi.edu> Date: Tue, 25 Feb 2003 13:28:51 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins CC: "Shelton, Raymond A." , ssakhuja@cisco.com, ipsec@lists.tislabs.com Subject: Re: IPSec over GRE why ? References: <4B0153B1561FE9439AB8F37A447B4BC601125B@UMH-EMAIL2.umh.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040306080203010409010802" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040306080203010409010802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 2/25/2003 1:01 PM, Derek Atkins wrote: > > Tunneling GRE within IPsec would work, but I would only suggest it if > you are trying to tunnel non-IP packets. If you're just trying to > tunnel IP packets, then just use IPsec's tunnel-mode and be done with > it. Not if existing dynamic routing protocols are required inside the virtual topology. See draft-touch-ipsec. (Details in my earlier reply.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms040306080203010409010802 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDIyNTIxMjg1MVowIwYJKoZIhvcNAQkEMRYEFI+cp71ZB9wbuS9OAN+3 d9PTh0QLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAC+BXiVNG2Hj9xsKJfWRZYu976JqTvsDqgJmL +PjHINq1AwYXs/7ymdCsCZ7zwJB9lxN+aJVDCJkzKSU7u8czg4CyKAhCB/EZXJYDP2E5/flb ijA7WiX/F8UsAgnhk/Gf0jhTTPR1yF1DiLC8QeX9WSnwq1Ktat1DC4JenAaczRZqey/4qA8j NSG0uwGQoHc8Bl1sK5mYW3tn+gCrS0Cq+Jopw4F1hBh/8HW4Geho//3TMTZJVGeKG/Ld/8Vq CwuyOTH5VdiJVeYq5R1eHdXMF9tjxu4U1ZuX+sqx5u0YndegMD4l04gcEszV6zcyuVCzCeB5 rEeG/CpOpBOMAWOS0QAAAAAAAA== --------------ms040306080203010409010802-- From owner-ipsec@lists.tislabs.com Wed Feb 26 08:14:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QGECd12507; Wed, 26 Feb 2003 08:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06572 Wed, 26 Feb 2003 10:44:41 -0500 (EST) Date: Wed, 26 Feb 2003 10:47:05 -0500 From: "Theodore Ts'o" To: Gregory Lebovitz Cc: ipsec@lists.tislabs.com, byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... Message-ID: <20030226154705.GE23962@think.thunk.org> References: <541402FFDC56DA499E7E13329ABFEA87E66A33@SARATOGA.netscreen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66A33@SARATOGA.netscreen.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Feb 25, 2003 at 03:02:40PM -0800, Gregory Lebovitz wrote: > > * Keep configuration payload and allow optional > > RFC 3456-style configuration > > If I'm reading your options correctly, we (I THINK) had some consensus (or > at least strong interest) on the list for the last option, and some folks > are working on text to clarify it. I THOUGHT we had some consensus for that as well, but right after Barbara and I gave Charlie editing directions for ikev2-05, and several days after I conclusion of the comment period for how to resolve these issues, a number of implementors, including Tero, Derek, Tylor Allison, argued against this position. And others, including Scott Kelly and Pekka Riikonen, suggested a DHCP-over-IKE. (Sorry for not including it in our original list.) And none of the people in favor of keeping configuration payload spoke up. One of the frustrating things about trying to determine consensus in the IPSEC wg is that the consensus seems to change from week to week, perhaps (in part) because some wg contributors are not reading this mailing list regularly. Another frustration is that some people will suggest an idea, such as DHCP over IKE, but not necessarily propose specific text to implement such an idea. So, I hereby call upon: 1) People who are in favor of DHCP-over-IKE to submit proposed text that explicit documents their proposal 2) People who are in favor of keeping configuration payload to speak up. And more generally, people with any opinion on any of the options to speak up, listing the tradeoffs to the various options and explaining why they prefer one option over another. - Ted P.S. The following very amusing "version" of RFC 2418 Section 6 was written by Jari Arkko as part of a discussion on the I-D draft-hardie-wg-stuckees-00.txt. For the humor impaired, this was a joke, but in all seriousness, we could really use more "stuckees" in this working group. (We're almost done, folks; it just requires one last hard push to finish the ikev2 document.) And now, for your reading pleasure... 6.1. PHB (Pointy Haired Boss) The PHB is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The PHB must ensure that a number of tasks are performed, either directly or by others assigned to the tasks. Unlike their corporate counterparts, however, IETF PHBs do not actually have authority to command specific persons to perform specific tasks. 6.2. Slave Most IETF working groups focus their efforts on a document, or set of documents. A working group generally designates a person or persons to serve as the Slave or Slaves for a particular document. The Slave is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group. Until very recently, Slaves also had to carry all the water to the IETF hotel, dig holes in the ground using their bare hands, and edit their documents using nroff. 6.3. Stuckee In order to make progress, working groups need to establish an understanding of technical alternatives, evaluate the feasibility of the proposed solutions in a variety of environments, and carefully review their documents. Furthermore, consensus is more fun when there are more participants than just the PHBs and the Slaves. Stuckees are expected to participate in the discussions, perform timely reviews of documents, and express their opinions when decisions are being made. Like others, Stuckees are volunteers. However, Stuckees do not get their name in any of the publications. 6.4. Tourist Most IETF working group meetings are held in big rooms. Experience has shown that the number of Slaves and Stuckees rarely exceeds ten for any working group. This would look bad for any potential observers trying to gauge the interest level of the new technology. In order to solve this problem, working groups arrange for a number of designated Tourists to participate the meetings. By definition, all other participants other than the PHBs, Slaves, Stuckees, and Area Dictators are Tourists. It is inappropriate for a Tourist to participate in discussions, whether live or on the list. Tourists are volunteers as well, but they get free Internet access while in the room. 6.5. Area Dictator Area Dictators are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. Additionally, given that Slaves are often illiterate and Stuckees lazy, the Area Dictators have formed the Internet Engineers Spelling Group (IESG), which helps the working groups to correct the grammar mistakes from their documents. ;-) From owner-ipsec@lists.tislabs.com Wed Feb 26 09:33:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHXId15167; Wed, 26 Feb 2003 09:33:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06777 Wed, 26 Feb 2003 11:49:46 -0500 (EST) From: "Stephane Beaulieu" To: "Theodore Ts'o" , "Gregory Lebovitz" Cc: , Subject: RE: Configuration portion of OPEN ISSUES... Date: Wed, 26 Feb 2003 11:53:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030226154705.GE23962@think.thunk.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > One of the frustrating things about trying to determine consensus in > the IPSEC wg is that the consensus seems to change from week to week, > perhaps (in part) because some wg contributors are not reading this > mailing list regularly. Sometimes, the same question gets asked over and over and over.... and it gets tiring of restating your opinions over and over and over... Not a personal dig here Ted, just a fact of life in the IETF. Some of us had agreed that a good path forward would be to keep the configuration payload for initial very basic configuration (IP, WINS, DNS, DHCP-SERVER-IP). This would satisfy a VERY LARGE number of existing deployments (100% that I've seen so far, though I'm not naive enough to think that it won't change ;). It would also allow you to use a RADIUS or LDAP server in the back-end (rather than DHCP). *IF* other DHCP specific information is required, a remote Client MAY send a DHCP packet (via a valid IPsec SA) directly to the DHCP server to get the rest of the configuration. I *thought* this was the agreement, but somewhere along the way, this changed to > > * Keep configuration payload and allow optional > > RFC 3456-style configuration Nobody wants to do this because this basically says you need to support both CP and RFC3456. Where it should have said *Keep configuration payload and allow optional unicast DHCP configuration after phase 1 is complete. I *think* everyone can live with this. Some have expressed a desire for other solutions (DHCP in IKE for example), but I have not heard anyone say that the above solution is not acceptable. > > Another frustration is that some people will suggest an idea, such as > DHCP over IKE, but not necessarily propose specific text to implement > such an idea. > > So, I hereby call upon: > > 1) People who are in favor of DHCP-over-IKE to submit proposed text > that explicit documents their proposal > > 2) People who are in favor of keeping configuration payload to speak > up. And more generally, people with any opinion on any of the options > to speak up, listing the tradeoffs to the various options and > explaining why they prefer one option over another. > > - Ted > > > P.S. The following very amusing "version" of RFC 2418 Section 6 was > written by Jari Arkko as part of a discussion on the I-D > draft-hardie-wg-stuckees-00.txt. For the humor impaired, this was a > joke, but in all seriousness, we could really use more "stuckees" in > this working group. (We're almost done, folks; it just requires one > last hard push to finish the ikev2 document.) > > And now, for your reading pleasure... > > 6.1. PHB (Pointy Haired Boss) > > The PHB is concerned with making forward progress through a > fair and open process, and has wide discretion in the > conduct of WG business. The PHB must ensure that a number > of tasks are performed, either directly or by others > assigned to the tasks. Unlike their corporate counterparts, > however, IETF PHBs do not actually have authority to > command specific persons to perform specific tasks. > > 6.2. Slave > > Most IETF working groups focus their efforts on a document, > or set of documents. A working group generally designates a > person or persons to serve as the Slave or Slaves for a > particular document. The Slave is responsible for ensuring > that the contents of the document accurately reflect the > decisions that have been made by the working group. Until > very recently, Slaves also had to carry all the water to the > IETF hotel, dig holes in the ground using their bare hands, > and edit their documents using nroff. > > 6.3. Stuckee > > In order to make progress, working groups need to establish > an understanding of technical alternatives, evaluate the > feasibility of the proposed solutions in a variety of > environments, and carefully review their documents. > Furthermore, consensus is more fun when there are more > participants than just the PHBs and the Slaves. Stuckees are > expected to participate in the discussions, perform timely > reviews of documents, and express their opinions when > decisions are being made. > > Like others, Stuckees are volunteers. However, Stuckees do > not get their name in any of the publications. > > 6.4. Tourist > > Most IETF working group meetings are held in big rooms. > Experience has shown that the number of Slaves and Stuckees > rarely exceeds ten for any working group. This would look bad > for any potential observers trying to gauge the interest > level of the new technology. In order to solve this problem, > working groups arrange for a number of designated Tourists to > participate the meetings. By definition, all other > participants other than the PHBs, Slaves, Stuckees, and Area > Dictators are Tourists. It is inappropriate for a Tourist to > participate in discussions, whether live or on the list. > > Tourists are volunteers as well, but they get free Internet > access while in the room. > > 6.5. Area Dictator > > Area Dictators are responsible for ensuring that working > groups in their area produce coherent, coordinated, > architecturally consistent and timely output as a > contribution to the overall results of the > IETF. Additionally, given that Slaves are often illiterate > and Stuckees lazy, the Area Dictators have formed the > Internet Engineers Spelling Group (IESG), which helps the > working groups to correct the grammar mistakes from their > documents. > > ;-) > From owner-ipsec@lists.tislabs.com Wed Feb 26 09:34:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHYhd15215; Wed, 26 Feb 2003 09:34:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06828 Wed, 26 Feb 2003 11:59:57 -0500 (EST) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 26 Feb 2003 11:01:29 -0600 (CST) From: Tylor Allison X-X-Sender: To: Van Aken Dirk cc: "'Gregory Lebovitz'" , "'Theodore Ts'o'" , , Subject: RE: Configuration portion of OPEN ISSUES... In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5501168A9F@TMM_EDGMSMSG01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 26 Feb 2003, Van Aken Dirk wrote: > Hi Theodore, see my comment below. > > > --SNIP-- > > > > > > For example, in the case of the open issue on how to handle > > > configuration, the choices to the working group are: > > > > > > * Keep configuration payload > > > * Remove configuration payload and pursue RFC > > > 3456-style configuration > > > * Keep configuration payload and allow optional > > > RFC 3456-style configuration > > > > If I'm reading your options correctly, we (I THINK) had some > > consensus (or > > at least strong interest) on the list for the last option, > > and some folks > > are working on text to clarify it. Did you mean to capture > > with the last > > bullet the case where we use a ModeCFG-like format to run a > > DHCP (or other) > > discovery/request in IKE? This would be very different than > > "3456-style" > > configuration, as 3456 occurs in Phase2. > > > > Just trying to clarify what you meant... thanks, > > > > Gregory. > > > > To clarify this open issue can we modify the list as follows (in order to > not have any confusion on what we are discussing about): > > 1) Keep configuration payload > 2) Remove configuration payload and pursue RFC 3456-style configuration > 3) Keep configuration payload and allow optional RFC 3456-style > configuration > 4) Remove configuration payload and pursue an DHCP-over-IKE style > configuration > > I'm in favour of 2) and can live with 3). > > Dirk I agree with this distinction in the options... I'd prefer to see option 1 or 4... don't really care which one. I strongly disagree with option 3... leaving this optional really means implementing both if you want to be interoperable with all vendors. ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Wed Feb 26 09:50:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHoid17299; Wed, 26 Feb 2003 09:50:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06904 Wed, 26 Feb 2003 12:15:12 -0500 (EST) From: "Jayant Shukla" To: "'Francis Dupont'" Cc: Subject: RE: Another NAT Traversal question Date: Wed, 26 Feb 2003 09:16:25 -0800 Message-ID: <021001c2ddba$caf64d30$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Francis Dupont > Sent: Tuesday, February 25, 2003 4:15 PM > To: Jayant Shukla > Cc: radia.perlman@sun.com; ipsec@lists.tislabs.com > Subject: Re: Another NAT Traversal question > > In your previous mail you wrote: > > The checksum is being fixed according to the new IP addresses in the IP > header and therefore you don't need the original IP address. > > => so you give up the transport checksum ? > Hi Francis, I am not sure I understand what you mean. My explanation is based on the draft. > >From what I recall, the authors had given up on the transport mode and > one of them had stated on this list that only 'tunnel mode' will be > pushed for v2. > > => I am afraid that there is no consensus to drop the transport mode, > so as the NAT traversal is in the charter, there is a problem to > really solve. > fair enough! Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Wed Feb 26 10:23:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QINUd19212; Wed, 26 Feb 2003 10:23:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06985 Wed, 26 Feb 2003 12:40:41 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66A45@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Stephane Beaulieu'" , "Theodore Ts'o" Cc: ipsec@lists.tislabs.com, byfraser@cisco.com, "Darren Dukes (E-mail)" Subject: RE: Configuration portion of OPEN ISSUES... Date: Wed, 26 Feb 2003 09:37:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk within... > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Wednesday, February 26, 2003 8:53 AM > To: Theodore Ts'o; Gregory Lebovitz > Cc: ipsec@lists.tislabs.com; byfraser@cisco.com > Subject: RE: Configuration portion of OPEN ISSUES... > --SNIP-- > > Some of us had agreed that a good path forward would be to keep the > configuration payload for initial very basic configuration > (IP, WINS, DNS, > DHCP-SERVER-IP). This would satisfy a VERY LARGE number of existing > deployments (100% that I've seen so far, though I'm not naive > enough to > think that it won't change ;). It would also allow you to > use a RADIUS or > LDAP server in the back-end (rather than DHCP). We have probably understated how important it is to the installed base to be able to use RADIUS and LDAP for client configuration backend server. Most of my organziation's large enterprise and xSP customers use RADIUS today, not DHCP for client configuration. That is why so many of us implementors are in consensus about the solution I and Stephane are describing: it would offer the network operators the most flexibility to leverage their current configuration infrastructure, be it DHCP, RADIUS or LDAP. > *IF* other > DHCP specific > information is required, a remote Client MAY send a DHCP > packet (via a valid > IPsec SA) directly to the DHCP server to get the rest of the > configuration. > > I *thought* this was the agreement, but somewhere along the way, this > changed to > > > > * Keep configuration payload and allow optional > > > RFC 3456-style configuration > > Nobody wants to do this because this basically says you need > to support both > CP and RFC3456. > > Where it should have said > > *Keep configuration payload and allow optional unicast DHCP > configuration > after phase 1 is complete. Or maybe: * Keep configuration payload, and show (possibly in Appendix or another document) how it works with various backend config servers, i.e. DHCP, RADIUS, LDAP. BTW, Darren Dukes and I are working right now on some text for this. Stay tuned. > I *think* everyone can live with this. Some have expressed a > desire for > other solutions (DHCP in IKE for example), but I have not > heard anyone say > that the above solution is not acceptable. This is the consensus I thought we had reached. Gregory. From owner-ipsec@lists.tislabs.com Wed Feb 26 11:08:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJ8Xd23701; Wed, 26 Feb 2003 11:08:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07189 Wed, 26 Feb 2003 13:40:46 -0500 (EST) Message-ID: <3E5D0A2B.DD5DA8F1@airespace.com> Date: Wed, 26 Feb 2003 10:40:43 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: Gregory Lebovitz , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... References: <541402FFDC56DA499E7E13329ABFEA87E66A33@SARATOGA.netscreen.com> <20030226154705.GE23962@think.thunk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 18:43:29.0663 (UTC) FILETIME=[F49788F0:01C2DDC6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments below... Theodore Ts'o wrote: > > On Tue, Feb 25, 2003 at 03:02:40PM -0800, Gregory Lebovitz wrote: > > > * Keep configuration payload and allow optional > > > RFC 3456-style configuration > > > > If I'm reading your options correctly, we (I THINK) had some consensus (or > > at least strong interest) on the list for the last option, and some folks > > are working on text to clarify it. > > I THOUGHT we had some consensus for that as well, but right after > Barbara and I gave Charlie editing directions for ikev2-05, and > several days after I conclusion of the comment period for how to > resolve these issues, a number of implementors, including Tero, Derek, > Tylor Allison, argued against this position. And others, including > Scott Kelly and Pekka Riikonen, suggested a DHCP-over-IKE. (Sorry for > not including it in our original list.) And none of the people in > favor of keeping configuration payload spoke up. For the record, I did not suggest DHCP-over-IKE, and I think Tero, Derek, and Tylor did (and maybe Pekka too). There were a number of others as well, including Gregory Lebovitz and Michael Richardson. For my part, I suggested that it should be *discussed* as one possible alternative, and I am glad to see that the discussion has not been summarily abbreviated. Arguably, one of the reasons we are still discussing remote access issues after 4 years of bickering is that the discussion process has not truly been open. Directives have come down from the AD's and/or the wg chairs without adequate open discussion of the issues and alternatives. Remote access has been treated as an unwanted stepchild of ipsec, when in fact, it is one to the primary commercial deployment scenarios for ipsec today. Everyone here who has been participating must agree that at some times, some topics have been off-limits - and it is not clear that this has been appropriate. We will only reach an agreement (which may turn out to be one that is distasteful in equal parts for all concerned) if the process is open. Clearly it must be a bounded discussion in terms of time, but it must be had in full regardless of its impact upon artificial deadlines. Even though we all want to get this behind us asap and move on, the discussion will never finally be closed until we all agree that all realistic approaches have been fairly evaluated. > One of the frustrating things about trying to determine consensus in > the IPSEC wg is that the consensus seems to change from week to week, > perhaps (in part) because some wg contributors are not reading this > mailing list regularly. I think a few of us have flip-flopped or otherwise significantly altered our positions in the last month (or at least, I know that I have). For my part, it has been largely due to running out of energy, and tiring of the squabbling after so many years. I still have strong opinions about how little need there is to impact ipsec/ike with remote access configuration, but I am clearly in the minority, and in the interest of forward progress, I have demonstrated my willingness to acknowledge my fallibility, and to compromise and move forward. I would hope others would do the same, and that the comment above is not intended to criticize those who might do so. Scott From owner-ipsec@lists.tislabs.com Wed Feb 26 11:08:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJ8Xd23702; Wed, 26 Feb 2003 11:08:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07163 Wed, 26 Feb 2003 13:33:41 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: Now a question on legacy authentication Date: Wed, 26 Feb 2003 13:27:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Feb 2003 18:27:52.0852 (UTC) FILETIME=[C6358540:01C2DDC4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk - Section 2.16 text: "The Initiator of an IKE-SA using EAP SHOULD be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the Responder sends notification messages and/or retries the authentication prompt." Why ten? Actually, this sounds a bit small to cover all possible methods. Is there a reason why we could not just wait until a timeout occurs or something like that? => Some implementations are likely to rely on hard timeouts for session establishment. E.g. If an exchange is not complete within 1 minute then consider it failed. Timing conditions are one of the most difficult things to get right. Constraining the number of messages is one way to achieve predictability. As for the responder retrying the authentication, clean handling of that case was one of the advantages of a phase 1.5. (I guess the phase 1.5 didn't add significant complexity after all.) Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-ipsec@lists.tislabs.com Wed Feb 26 11:31:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJVld24703; Wed, 26 Feb 2003 11:31:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07299 Wed, 26 Feb 2003 14:06:11 -0500 (EST) Cc: "'Ari Huttunen'" , ipsec@lists.tislabs.com Message-ID: <3E5D0FAD.4070804@bell-labs.com> Disposition-Notification-To: Uri Blumenthal Date: Wed, 26 Feb 2003 14:04:13 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Yoav Nir Original-CC: "'Ari Huttunen'" , ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question References: <001201c2dd75$7fd65420$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > Sure you can do L2TP/IPsec with tunnel mode......... > I also believe that transport mode is not worth the trouble, but other > people disagree. I second this opinion. From owner-ipsec@lists.tislabs.com Wed Feb 26 11:41:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJfCd25112; Wed, 26 Feb 2003 11:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07334 Wed, 26 Feb 2003 14:12:16 -0500 (EST) To: Tylor Allison Cc: Van Aken Dirk , "'Gregory Lebovitz'" , "'Theodore Ts'o'" , , From: Derek Atkins Subject: Re: Configuration portion of OPEN ISSUES... References: Date: 26 Feb 2003 14:12:49 -0500 In-Reply-To: Message-ID: Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tylor Allison writes: > > To clarify this open issue can we modify the list as follows (in order to > > not have any confusion on what we are discussing about): > > > > 1) Keep configuration payload > > 2) Remove configuration payload and pursue RFC 3456-style configuration > > 3) Keep configuration payload and allow optional RFC 3456-style > > configuration > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > configuration > > > > I'm in favour of 2) and can live with 3). > > > > Dirk > > I agree with this distinction in the options... > > I'd prefer to see option 1 or 4... don't really care which one. I strongly > disagree with option 3... leaving this optional really means implementing > both if you want to be interoperable with all vendors. I think option 3 needs to be clarified some before it's written off completely. My reading of option 3 is that you use the config payload for the IP Address, netmask, and a few, limited other options, and then optionally the client can use DHCP to obtain _other_ configuration informtation. Perhaps we need a "3a" and "3b" to define the different interpretations of what you have in option 3? If my interpretation of #3 is "correct", then I have no problem with it, because it does not affect the IPsec/IKE implementation at all. It's just a hook on the client to run the DHCP client once you're up on the net. The (standalone) DHCP client can perform further configuration (beyond IP Address leases, which you get from the config payload). Personally I don't have a strong opinion between 1, my interpretation of 3, and 4. I would lean towards 1 or my interpretation of 3, only because DHCP is larger and less bounded, so it would be nice to know we can complete the configuration process in 2 messages (via config) rather than 4-6 additional messages (via encapsulated DHCP). Size and latency do matter, to some extent. I think that all of it is dwarfed by RSA/DH operations, but the number of round trips does matter. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 26 13:18:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QLImd28724; Wed, 26 Feb 2003 13:18:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07682 Wed, 26 Feb 2003 15:41:16 -0500 (EST) Message-Id: <200302262043.h1QKhOaj010531@thunk.east.sun.com> From: Bill Sommerfeld To: "Stephane Beaulieu" cc: "Theodore Ts'o" , "Gregory Lebovitz" , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... In-Reply-To: Your message of "Wed, 26 Feb 2003 11:53:13 EST." Reply-to: sommerfeld@east.sun.com Date: Wed, 26 Feb 2003 15:43:24 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > *Keep configuration payload and allow optional unicast DHCP configuration > after phase 1 is complete. > > I *think* everyone can live with this. Some have expressed a desire for > other solutions (DHCP in IKE for example), but I have not heard anyone say > that the above solution is not acceptable. You should have heard people (including myself) say that any configuration scheme within IKE should reuse as much of DHCP syntax and option codes as possible rather than defining a wholly new parameter space. - Bill From owner-ipsec@lists.tislabs.com Wed Feb 26 14:42:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QMgMd03978; Wed, 26 Feb 2003 14:42:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07863 Wed, 26 Feb 2003 17:11:00 -0500 (EST) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 26 Feb 2003 16:11:55 -0600 (CST) From: Tylor Allison X-X-Sender: To: Derek Atkins cc: Van Aken Dirk , "'Gregory Lebovitz'" , "'Theodore Ts'o'" , , Subject: Re: Configuration portion of OPEN ISSUES... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Feb 2003, Derek Atkins wrote: > Tylor Allison writes: > > > > To clarify this open issue can we modify the list as follows (in order to > > > not have any confusion on what we are discussing about): > > > > > > 1) Keep configuration payload > > > 2) Remove configuration payload and pursue RFC 3456-style configuration > > > 3) Keep configuration payload and allow optional RFC 3456-style > > > configuration > > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > > configuration > > > > > > I'm in favour of 2) and can live with 3). > > > > > > Dirk > > > > I agree with this distinction in the options... > > > > I'd prefer to see option 1 or 4... don't really care which one. I strongly > > disagree with option 3... leaving this optional really means implementing > > both if you want to be interoperable with all vendors. > > I think option 3 needs to be clarified some before it's written off > completely. My reading of option 3 is that you use the config payload > for the IP Address, netmask, and a few, limited other options, and > then optionally the client can use DHCP to obtain _other_ > configuration informtation. Perhaps we need a "3a" and "3b" to define > the different interpretations of what you have in option 3? > > If my interpretation of #3 is "correct", then I have no problem with > it, because it does not affect the IPsec/IKE implementation at all. > It's just a hook on the client to run the DHCP client once you're up > on the net. The (standalone) DHCP client can perform further > configuration (beyond IP Address leases, which you get from the config > payload). > > Personally I don't have a strong opinion between 1, my interpretation > of 3, and 4. I would lean towards 1 or my interpretation of 3, only > because DHCP is larger and less bounded, so it would be nice to know > we can complete the configuration process in 2 messages (via config) > rather than 4-6 additional messages (via encapsulated DHCP). Size and > latency do matter, to some extent. I think that all of it is dwarfed > by RSA/DH operations, but the number of round trips does matter. > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com Yep, I agree that even further clarification is needed for option 3, as my read on it was exactly opposite of yours. I was pretty much lumping your interpretation of option 3 in with option 1. I'll step back from what I stated before... I'd prefer to see the MC as is (with optional client use of DHCP to retrieve other config options)... the reason I was entertaining DHCP-over-IKE was that it was an option that I felt I could live with, and at the time it was offered, it wasn't clear to me that any consensus had been made. I was thinking perhaps more people would prefer on DHCP-over-IKE vs. MC as is... it looks like this is not the case. ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Wed Feb 26 15:36:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QNaGd05402; Wed, 26 Feb 2003 15:36:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07981 Wed, 26 Feb 2003 18:09:41 -0500 (EST) Message-Id: <200302262313.h1QND0Im030476@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Configuration portion of OPEN ISSUES... In-reply-to: Your message of "Wed, 26 Feb 2003 15:43:24 EST." <200302262043.h1QKhOaj010531@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 26 Feb 2003 18:12:59 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: >> *Keep configuration payload and allow optional unicast DHCP >> configuration after phase 1 is complete. >> >> I *think* everyone can live with this. Some have expressed a desire >> for other solutions (DHCP in IKE for example), but I have not heard >> anyone say that the above solution is not acceptable. Bill> You should have heard people (including myself) say that any Bill> configuration scheme within IKE should reuse as much of DHCP syntax Bill> and option codes as possible rather than defining a wholly new Bill> parameter space. I want to emphasis that just because one says "DHCP-over-IKE", that does not mean that such a system has to talk to a DHCP server. Decoding DHCP messages is no more difficult than radius, PPP or IKEv2. (Maybe a lot easier than IKEv1) You can implement the relevant pieces in the gateway. DHCP vs modecfg can be just about syntax. I will fill the state machine changes, and suggest text for dhcp-over-ike, but I won't bother if there is no interest. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPl1J+YqHRg3pndX9AQHMRgP9EEaKTJVVrKoz+P87fsj52uFIq0uKTdSW 8lvf89beo60rPR4sxIQwXptmYEMbCQqqgvNJR4eHf1fhZ64PhAY4/cWK1VgMjnZn fqxoSdEobN2fTiDQILqhUBGnQFhu7cpoxoNxhbpPzcFoxjRZ01P4p67NHCoi9JtX tQQiE/IrQkI= =m1sI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Feb 27 02:33:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RAXXY21631; Thu, 27 Feb 2003 02:33:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09249 Thu, 27 Feb 2003 05:03:34 -0500 (EST) From: "Yoav Nir" To: Subject: RE: Configuration portion of OPEN ISSUES... Date: Thu, 27 Feb 2003 12:06:47 +0200 Message-ID: <004d01c2de47$f10ed2c0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200302262313.h1QND0Im030476@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Seems like we're converging again... :-) It is about syntax, but there are disadvantages to using DHCP. Decoding DHCP messages is not difficult. One problem with it is that DHCP packets are considerably longer than Config payloads. With all the payloads we already have, it is always a good idea to reduce the size of the packets. I am in favor of Config Payloads as they are specified in -05 and as implemented by some vendors. Further configuration using DHCP is OK, if needed, but does not affect the IKE protocol. Yoav Nir -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson Subject: Re: Configuration portion of OPEN ISSUES... I want to emphasis that just because one says "DHCP-over-IKE", that does not mean that such a system has to talk to a DHCP server. Decoding DHCP messages is no more difficult than radius, PPP or IKEv2. (Maybe a lot easier than IKEv1) You can implement the relevant pieces in the gateway. DHCP vs modecfg can be just about syntax. I will fill the state machine changes, and suggest text for dhcp-over-ike, but I won't bother if there is no interest. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ ============================================================================ ============== The opinions expressed here are my own and do not necessarily reflect those of my employer From owner-ipsec@lists.tislabs.com Thu Feb 27 02:56:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RAuJY22199; Thu, 27 Feb 2003 02:56:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09342 Thu, 27 Feb 2003 05:32:38 -0500 (EST) Message-Id: <200302271032.h1RAWGof067116@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Wed, 26 Feb 2003 09:16:25 PST. <021001c2ddba$caf64d30$5803a8c0@trlhpc1> Date: Thu, 27 Feb 2003 11:32:16 +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: > In your previous mail you wrote: > > The checksum is being fixed according to the new IP addresses in the IP > header and therefore you don't need the original IP address. > > => so you give up the transport checksum ? I am not sure I understand what you mean. My explanation is based on the draft. => my concern is that I believe the way you fix the checksum will give a correct checksum from a wrong one, i.e., you loose the detection of errors which is the purpose of the checksum. IMHO the checksum must be fixed using the original and new IP addresses, i.e., you add the original addresses and substract the new addresses in an one-complement arithmetic (the checksum is the opposite of the sum of the pseudo-header and the transport message in one-complement. At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used. What I propose is a direct application of RFC 1624 which requires the original addresses). Regards Francis.Dupont@enst-bretagne.fr PS (for the list): should we be more accurate in IKEv2 draft? Current text in draft-ietf-ipsec-nat-t-ike-05.txt is: The original source and destination addresses are used in transport mode to incrementally update the TCP/IP checksums so that they will match after the NAT transform (The NAT cannot do this, because the TCP/IP checksum is inside the UDP encapsulated IPsec packet). (BTW this text is fine for me, the issue is that it is not in both drafts). From owner-ipsec@lists.tislabs.com Thu Feb 27 14:09:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RM9HY08619; Thu, 27 Feb 2003 14:09:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10760 Thu, 27 Feb 2003 16:25:33 -0500 (EST) Message-ID: <3E5E831D.9080809@nortelnetworks.com> Date: Thu, 27 Feb 2003 16:29:01 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: KE payload Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I may have missed the discussion on it, but why can't the Suite-ID in the KE payload be "DH group #"? regards, Lakshminath 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Suite-ID ! RESERVED (MBZ) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Exchange Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Key Exchange Payload Format From owner-ipsec@lists.tislabs.com Thu Feb 27 18:23:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2NLY14626; Thu, 27 Feb 2003 18:23:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11277 Thu, 27 Feb 2003 20:51:38 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Theodore Ts'o" , "Gregory Lebovitz" Cc: , Subject: RE: Configuration portion of OPEN ISSUES... Date: Thu, 27 Feb 2003 20:54:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030226154705.GE23962@think.thunk.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll speak up with my preference for the Configuration Payload and DHCPINFORM. Pros/cons to come after the CP to dhcp/radius/ldap doc is done. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > Sent: Wednesday, February 26, 2003 10:47 AM > To: Gregory Lebovitz > Cc: ipsec@lists.tislabs.com; byfraser@cisco.com > Subject: Re: Configuration portion of OPEN ISSUES... > > > On Tue, Feb 25, 2003 at 03:02:40PM -0800, Gregory Lebovitz wrote: > > > * Keep configuration payload and allow optional > > > RFC 3456-style configuration > > > > If I'm reading your options correctly, we (I THINK) had some > consensus (or > > at least strong interest) on the list for the last option, and > some folks > > are working on text to clarify it. > > I THOUGHT we had some consensus for that as well, but right after > Barbara and I gave Charlie editing directions for ikev2-05, and > several days after I conclusion of the comment period for how to > resolve these issues, a number of implementors, including Tero, Derek, > Tylor Allison, argued against this position. And others, including > Scott Kelly and Pekka Riikonen, suggested a DHCP-over-IKE. (Sorry for > not including it in our original list.) And none of the people in > favor of keeping configuration payload spoke up. > > One of the frustrating things about trying to determine consensus in > the IPSEC wg is that the consensus seems to change from week to week, > perhaps (in part) because some wg contributors are not reading this > mailing list regularly. > > Another frustration is that some people will suggest an idea, such as > DHCP over IKE, but not necessarily propose specific text to implement > such an idea. > > So, I hereby call upon: > > 1) People who are in favor of DHCP-over-IKE to submit proposed text > that explicit documents their proposal > > 2) People who are in favor of keeping configuration payload to speak > up. And more generally, people with any opinion on any of the options > to speak up, listing the tradeoffs to the various options and > explaining why they prefer one option over another. > > - Ted > > > P.S. The following very amusing "version" of RFC 2418 Section 6 was > written by Jari Arkko as part of a discussion on the I-D > draft-hardie-wg-stuckees-00.txt. For the humor impaired, this was a > joke, but in all seriousness, we could really use more "stuckees" in > this working group. (We're almost done, folks; it just requires one > last hard push to finish the ikev2 document.) > > And now, for your reading pleasure... > > 6.1. PHB (Pointy Haired Boss) > > The PHB is concerned with making forward progress through a > fair and open process, and has wide discretion in the > conduct of WG business. The PHB must ensure that a number > of tasks are performed, either directly or by others > assigned to the tasks. Unlike their corporate counterparts, > however, IETF PHBs do not actually have authority to > command specific persons to perform specific tasks. > > 6.2. Slave > > Most IETF working groups focus their efforts on a document, > or set of documents. A working group generally designates a > person or persons to serve as the Slave or Slaves for a > particular document. The Slave is responsible for ensuring > that the contents of the document accurately reflect the > decisions that have been made by the working group. Until > very recently, Slaves also had to carry all the water to the > IETF hotel, dig holes in the ground using their bare hands, > and edit their documents using nroff. > > 6.3. Stuckee > > In order to make progress, working groups need to establish > an understanding of technical alternatives, evaluate the > feasibility of the proposed solutions in a variety of > environments, and carefully review their documents. > Furthermore, consensus is more fun when there are more > participants than just the PHBs and the Slaves. Stuckees are > expected to participate in the discussions, perform timely > reviews of documents, and express their opinions when > decisions are being made. > > Like others, Stuckees are volunteers. However, Stuckees do > not get their name in any of the publications. > > 6.4. Tourist > > Most IETF working group meetings are held in big rooms. > Experience has shown that the number of Slaves and Stuckees > rarely exceeds ten for any working group. This would look bad > for any potential observers trying to gauge the interest > level of the new technology. In order to solve this problem, > working groups arrange for a number of designated Tourists to > participate the meetings. By definition, all other > participants other than the PHBs, Slaves, Stuckees, and Area > Dictators are Tourists. It is inappropriate for a Tourist to > participate in discussions, whether live or on the list. > > Tourists are volunteers as well, but they get free Internet > access while in the room. > > 6.5. Area Dictator > > Area Dictators are responsible for ensuring that working > groups in their area produce coherent, coordinated, > architecturally consistent and timely output as a > contribution to the overall results of the > IETF. Additionally, given that Slaves are often illiterate > and Stuckees lazy, the Area Dictators have formed the > Internet Engineers Spelling Group (IESG), which helps the > working groups to correct the grammar mistakes from their > documents. > > ;-) > From owner-ipsec@lists.tislabs.com Fri Feb 28 04:53:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SCr5Y10403; Fri, 28 Feb 2003 04:53:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12317 Fri, 28 Feb 2003 07:21:02 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168AA6@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Scott G. Kelly'" , "Theodore Ts'o" Cc: Gregory Lebovitz , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: RE: Configuration portion of OPEN ISSUES... Date: Fri, 28 Feb 2003 10:33:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Folks, See my comments inline. > > For the record, I did not suggest DHCP-over-IKE, and I think Tero, > Derek, and Tylor did (and maybe Pekka too). There were a number of > others as well, including Gregory Lebovitz and Michael Richardson. For > my part, I suggested that it should be *discussed* as one possible > alternative, and I am glad to see that the discussion has not been > summarily abbreviated. > > Arguably, one of the reasons we are still discussing remote access > issues after 4 years of bickering is that the discussion > process has not > truly been open. Directives have come down from the AD's and/or the wg > chairs without adequate open discussion of the issues and > alternatives. > Remote access has been treated as an unwanted stepchild of ipsec, when > in fact, it is one to the primary commercial deployment scenarios for > ipsec today. Same opinion! I'm active in the DSL router space and due the fact that DSL is unlocking bandwidth at a very cheap price/fee we see central office LAN's constantly expanding via WAN DSL links and a churn from expensive leased lines towards DSL. IPSec complements this move as it provides for security. Of course some people will again say this is out of the ipsra scope ... > > Everyone here who has been participating must agree that at > some times, > some topics have been off-limits - and it is not clear that this has > been appropriate. We will only reach an agreement (which may > turn out to > be one that is distasteful in equal parts for all concerned) if the > process is open. Clearly it must be a bounded discussion in terms of > time, but it must be had in full regardless of its impact upon > artificial deadlines. Even though we all want to get this > behind us asap > and move on, the discussion will never finally be closed until we all > agree that all realistic approaches have been fairly evaluated. Correct ! The discussion on RFC3456 proves this point: some people seemed not familiar with DHCP so how can one discuss a proposal as one does not understand the basic architecture. Of course the same applies to me: I'm not that familiar with IPSec ;-) ... Dirk > > > One of the frustrating things about trying to determine consensus in > > the IPSEC wg is that the consensus seems to change from > week to week, > > perhaps (in part) because some wg contributors are not reading this > > mailing list regularly. > > I think a few of us have flip-flopped or otherwise > significantly altered > our positions in the last month (or at least, I know that I have). For > my part, it has been largely due to running out of energy, > and tiring of > the squabbling after so many years. I still have strong opinions about > how little need there is to impact ipsec/ike with remote access > configuration, but I am clearly in the minority, and in the > interest of > forward progress, I have demonstrated my willingness to acknowledge my > fallibility, and to compromise and move forward. I would hope others > would do the same, and that the comment above is not intended to > criticize those who might do so. > > Scott > ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain From owner-ipsec@lists.tislabs.com Fri Feb 28 04:53:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SCr9Y10417; Fri, 28 Feb 2003 04:53:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12318 Fri, 28 Feb 2003 07:21:03 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168AA5@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Tylor Allison'" Cc: "'Gregory Lebovitz'" , "'Theodore Ts'o'" , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: RE: Configuration portion of OPEN ISSUES... Date: Fri, 28 Feb 2003 09:45:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tylor, See my comments below. > > > > To clarify this open issue can we modify the list as > follows (in order to > > not have any confusion on what we are discussing about): > > > > 1) Keep configuration payload > > 2) Remove configuration payload and pursue RFC 3456-style > configuration > > 3) Keep configuration payload and allow optional RFC 3456-style > > configuration > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > configuration > > > > I'm in favour of 2) and can live with 3). > > > > Dirk > > I agree with this distinction in the options... > > I'd prefer to see option 1 or 4... don't really care which > one. I strongly > disagree with option 3... leaving this optional really means > implementing > both if you want to be interoperable with all vendors. Initially, I started the "DHCP vs IKEModeCfg" discussion with following proposal: Specify in IKEv2 either of: *) Configuration payload *) RFC3456-style configuration At that time I was also in favour of only one mechanism) however this choice was too aggressive so I changed my opnion into: *) Keep configuration payload and allow OPTIONAL RFC 3456-style configuration I could even live with the MUST keyword for IKEModeCfg and the MAY keyword for RFC3456-style. And yes I agree with you that to be interoperable a vendor has to implement both. On the other hand due to advantages of one method over the other only one method would become popular (i.e. let the best win ...). It seems that today there are now 4 proposals on the table. I list them below with prefixed +/- indicators. 1) Keep configuration payload ++ implemented for IKEv1 (although there are still many IPSec implementations are out there without IKEModeCfg) -- limited in functionality compared to DHCP In the assumption that a stand-alone DHCP server will be used for address assignment 1) has following negative points: -- how to couple the IKEModeCfg & IKE state machine to a DHCP Client/Server's state machine ? -- how to match IKEModeCfg payloads with DHCP payloads ? 2) Remove configuration payload and pursue RFC 3456-style configuration -- IKEModeCfg implementers have to start all over again. However better to decide on it now; within a few years it is too late. ++ assuming the solution is based on the construct DHCPclient-DHCPRelay-DHCPServer it inherits all the properties of what is possible in non-VPN LANs today ++ simplicity (of course if one is familiar with the DHCP architecture) -- scalable in the sense that multiple VPN clients can request IP configurations 3) Keep configuration payload and allow optional RFC 3456-style configuration Same remarks as 1) and 2) 4) Remove configuration payload and pursue an DHCP-over-IKE style configuration ++ it removes the limitations that IKEModeCfg has ++ depending on how IKEModeCfg is implemented it might require less rework. i.e. If IKEModeCfg is implemented as follows: IKEMoceCFG-DHCPClient-DHCPServer, implementing DHCP-over-IKE merely comes down to reformatting IKE messages -- it has a similar limitation as 1): the IKE state machine is completely different from that of a DHCP client To conclude: I prefer 3) and have mixed feelings about 4). Best regards - Dirk > > ===================================================================== > = Tylor Allison Secure Computing Corporation ========= > ===================================================================== > > ----------------------------------------------------------- As of February 12, 2003 Thomson unifies its email addresses on a worldwide basis.Please note my new email address: dirk.vanaken@thomson.net Thomson is the leader in solutions and technologies for the entertainment and media industries and serves its customers under its four strategic brands: Technicolor, Grass Valley, RCA and THOMSON. More about Thomson: http://www.thomson.net/videochain From owner-ipsec@lists.tislabs.com Fri Feb 28 05:03:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SD3lY10680; Fri, 28 Feb 2003 05:03:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12368 Fri, 28 Feb 2003 07:39:06 -0500 (EST) Message-Id: <200302281226.HAA22864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-tutorial-00.txt Date: Fri, 28 Feb 2003 07:26:16 -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 : Understanding IKEv2: Tutorial, and rationale for decisions Author(s) : R. Perlman Filename : draft-ietf-ipsec-ikev2-tutorial-00.txt Pages : 0 Date : 2003-2-27 The main job of a protocol specification is to document how the protocol works. It is sometimes difficult to learn how a protocol works from such a document, because there are so many details, and the necessary formalism for accuracy makes a specification long and intimidating to read. What also is usually lost in the process of creating an RFC for a protocol is documentation of the tradeoffs that were considered when making controversial choices. Sometimes it is possible to find this information on the email archives, but that is a daunting task. This document is intended to work both as a tutorial to understanding IKEv2, and a summary of the controversial issues, with the reasoning on all sides of each issue. If any differences in details exist between this document and the IKEv2 specification, the IKEv2 specification is authoritative. This document is intended only to make the IKEv2 specification more understandable on the first reading, as well as documenting reasoning behind decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-tutorial-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-ikev2-tutorial-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-ikev2-tutorial-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-2-27133010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-tutorial-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-tutorial-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27133010.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Feb 28 09:43:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHhvY25671; Fri, 28 Feb 2003 09:43:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12998 Fri, 28 Feb 2003 11:59:22 -0500 (EST) From: "Jayant Shukla" To: "'Francis Dupont'" Cc: Subject: RE: Another NAT Traversal question Date: Fri, 28 Feb 2003 08:59:50 -0800 Message-ID: <02c501c2df4a$ce821240$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200302271032.h1RAWGof067116@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Francis Dupont > > => my concern is that I believe the way you fix the checksum will give > a correct checksum from a wrong one, i.e., you loose the detection > of errors which is the purpose of the checksum. > IMHO the checksum must be fixed using the original and new IP addresses, > i.e., you add the original addresses and substract the new addresses > in an one-complement arithmetic (the checksum is the opposite of the > sum of the pseudo-header and the transport message in one-complement. > At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used. > What I propose is a direct application of RFC 1624 which requires > the original addresses). > I don't think you need to do what you have explained. Since you will authenticate and decrypt the packet, it guarantees that you don't have any flipped bits in the body of the encapsulated data. If you want, test the checksum before you authenticate/decrypt the packet. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Fri Feb 28 09:57:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHvNY26513; Fri, 28 Feb 2003 09:57:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13101 Fri, 28 Feb 2003 12:29:46 -0500 (EST) Message-Id: <200302281707.h1SH7LE64056@homebrew.trpz.com> To: ipsec@lists.tislabs.com Subject: comments on IKEv2-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64053.1046452041.1@trpz.com> Date: Fri, 28 Feb 2003 09:07:21 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have several comments on IKEv2 that I'm going to spread across different messages to keep from sending on huge post. I'll start here with minor nits: - Section 2.13 describes a Diffie-Hellman group as a cryptographic algorithm that takes fixed size key. That is wrong. - page 82 and the TOC: s/Author/Editor/ - Section 8.1 should include a normative reference to RFC2451. (A good way to tell whether it's normative or informative is to check if implementation of the requirement can be visible externally and if it has an impact on interoperability. Yes on both counts: normative). - Section 1.4 The Informational Exchange says, "When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPcomp, then with ESP, and finally with AH between the same pair of endpoints...." How does one negotiate such nested SAs using IKEv2? I don't think it's possible. - page breaks need to be thought through more. For instance, the Authentication Payload in section 3.8 is bisected by a page break. thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Feb 28 09:57:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHvRY26527; Fri, 28 Feb 2003 09:57:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13119 Fri, 28 Feb 2003 12:30:51 -0500 (EST) Message-Id: <200302281712.h1SHCrE64086@homebrew.trpz.com> To: ipsec@lists.tislabs.com Subject: CREATE_CHILD_SA exchange in IKEv2-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64083.1046452373.1@trpz.com> Date: Fri, 28 Feb 2003 09:12:53 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Towards the end of section 1.3 it says, "Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE-SA." What about the suite? Doesn't that determine whether the request is being used to change the key of the IKE SA? What would happend if the SA specified an ESP suite but there were no Traffic Selectors? Also, can the suite change from one IKE SA to the next? Suggested verbage: "When the CREATE_CHILD_SA request is used to rekey the IKE SA Traffic Selectors MUST be omitted and the suite used to negotiate the IKE SA MUST be the same as that from the IKE_SA_INIT exchange that created the SA being rekeyed." thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Feb 28 09:58:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHwCY26587; Fri, 28 Feb 2003 09:58:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13130 Fri, 28 Feb 2003 12:31:50 -0500 (EST) Message-Id: <200302281718.h1SHItE64113@homebrew.trpz.com> To: ipsec@lists.tislabs.com Subject: the encrypted payload in IKEv2-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64110.1046452735.1@trpz.com> Date: Fri, 28 Feb 2003 09:18:55 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Parsing IKEv2 messages is straightforward because if you're at the current payload, curr, the next payload is at curr + curr->length and the type of that payload will be curr->next_payload. And all the payloads have the same generic format so parsing is easy. Except for the Encrypted Payload. It's "next payload" is, in fact, the first interior payload. So this is alot like the clumsy IKEv1 construction of SA, proposal and transform. This is the sort of stuff we were supposed to get rid of in IKEv2. It's an exception to an otherwise nice and clean rule. And that makes for bad code. I missed when this got added but I recommend it be removed and we go back to the way it used to be-- IV is part of the IKE Header iff the rest of the message is encrypted, and there is a "trailer" appended which includes the padding, pad length, and auth data. thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Feb 28 09:58:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHwlY26676; Fri, 28 Feb 2003 09:58:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13118 Fri, 28 Feb 2003 12:30:51 -0500 (EST) Message-Id: <200302281717.h1SHHAE64102@homebrew.trpz.com> To: ipsec@lists.tislabs.com Subject: suites vs. a la carte and IPcomp in IKEv2-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64099.1046452630.1@trpz.com> Date: Fri, 28 Feb 2003 09:17:10 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It appears that IPcomp was forgotten about when the decision was made to go to suites. IPcomp was later grafted into IKEv2 such that it is negotiated with NOTIFY payloads in an a la carte fashion. This is the worst possible scenario! We now have both suites AND a la carte. And, again, this-- notify payloads after the SA payload in the CREATE_CHILD_EXCHANGE-- is one of those things that everyone is going to have to support. Another mandatory option. The kind of thing we were supposed to get rid of in IKEv2. If we're going to have suites then we should go full bore and define some with and without IPcomp, and with is LZS and deflate. And get rid of the a la carte negotiation with NOTIFY payloads. Either that or go completely back to a la carte. Also, the suites for IPsec do not contain D-H groups. How does the responder in the CREATE_CHILD_SA exchange know what group the KEi payload is from? Guess from the length? That doesn't sound right. I recommend suites with the 1536 and 2048 bit groups be added. Either that or go back to a la carte. I really prefer a la carte. The argument against-- that all combinations are not tested-- is really specious. The argument against suites is that they multiply like rabbits. Supporting IPcomp means 6 more. Adding 2 D-H groups to the IPsec suites means 8 more. thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Feb 28 09:58:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHwvY26713; Fri, 28 Feb 2003 09:58:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13110 Fri, 28 Feb 2003 12:30:48 -0500 (EST) Message-Id: <200302281709.h1SH9kE64070@homebrew.trpz.com> To: ipsec@lists.tislabs.com Subject: "Me Tarzan, You Jane" in IKEv2-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64067.1046452186.1@trpz.com> Date: Fri, 28 Feb 2003 09:09:46 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When we began the IKEv2 effort we looked at things in IKEv1 that at the time sounded like good ideas but in practice were rarely, if ever, used-- e.g. phase 1 negotiation (hence the 4/6 exchange), complex SA offers of (((A & B) | (C & D)) | E), etc.-- and we decided to get rid of them in IKEv2. While these things were rarely used they had to be supported by all. They're mandatory options. I think "Me Tarzan, You Jane" will be another one. It is also poorly defined. What sort of identity is used as the hint? What if the TR payloads are coarse and the identity is fine, how does the SPD make sure that no packets mix that aren't from that identity? When you have a pcb (or like data structure) to hang on to it's possible but not all SAs will necessarily be tied to pcbs. This is IP we're talking about anyway and identities and applications are not in the realm of IP. Securing things based on identities or applications is best left to protocol that have that context, like TLS/SSL. This is a cute feature but I doubt it would be used in practice and therefore it's just another mandatory option that everyone has to implement but never use. It's the kind of thing we were supposed to get rid of in IKEv2. Let's get rid of it. thanks, Dan. From owner-ipsec@lists.tislabs.com Fri Feb 28 09:59:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SHx8Y26737; Fri, 28 Feb 2003 09:59:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13131 Fri, 28 Feb 2003 12:31:53 -0500 (EST) Message-ID: <6204FDDE129D364D8040A98BCCB290EF045035B0@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: Derek Atkins , Tylor Allison , ipsec@lists.tislabs.com Cc: Van Aken Dirk , "'Gregory Lebovitz'" , "'Theodore Ts'o'" , byfraser@cisco.com, jxiang@nortelnetworks.com Subject: RE: Configuration portion of OPEN ISSUES... Date: Fri, 28 Feb 2003 11:57:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF4A.83658E40" 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_01C2DF4A.83658E40 Content-Type: text/plain; charset="iso-8859-1" I am afraid my previous post was unsuccessful. (I apologize if you've seen it twice) I would also like to argue we go with 1) or Derek's interpretation of 3) on the basis that *)Configuration Payload satisfies the basic needs(IP address, DNS, WINS) *)Most install base I am aware of uses ldap or RADIUS not DHCP as address server Regards! /Jing Jing Xiang, jxiang@nortelnetworks.com Nortel Networks Contivity Engineering -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Wednesday, February 26, 2003 2:13 PM To: Tylor Allison Cc: Van Aken Dirk; 'Gregory Lebovitz'; 'Theodore Ts'o'; ipsec@lists.tislabs.com; byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... Tylor Allison writes: > > To clarify this open issue can we modify the list as follows (in order to > > not have any confusion on what we are discussing about): > > > > 1) Keep configuration payload > > 2) Remove configuration payload and pursue RFC 3456-style configuration > > 3) Keep configuration payload and allow optional RFC 3456-style > > configuration > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > configuration > > > > I'm in favour of 2) and can live with 3). > > > > Dirk > > I agree with this distinction in the options... > > I'd prefer to see option 1 or 4... don't really care which one. I strongly > disagree with option 3... leaving this optional really means implementing > both if you want to be interoperable with all vendors. I think option 3 needs to be clarified some before it's written off completely. My reading of option 3 is that you use the config payload for the IP Address, netmask, and a few, limited other options, and then optionally the client can use DHCP to obtain _other_ configuration informtation. Perhaps we need a "3a" and "3b" to define the different interpretations of what you have in option 3? If my interpretation of #3 is "correct", then I have no problem with it, because it does not affect the IPsec/IKE implementation at all. It's just a hook on the client to run the DHCP client once you're up on the net. The (standalone) DHCP client can perform further configuration (beyond IP Address leases, which you get from the config payload). Personally I don't have a strong opinion between 1, my interpretation of 3, and 4. I would lean towards 1 or my interpretation of 3, only because DHCP is larger and less bounded, so it would be nice to know we can complete the configuration process in 2 messages (via config) rather than 4-6 additional messages (via encapsulated DHCP). Size and latency do matter, to some extent. I think that all of it is dwarfed by RSA/DH operations, but the number of round trips does matter. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com ------_=_NextPart_001_01C2DF4A.83658E40 Content-Type: text/html; charset="iso-8859-1" I am afraid my previous post was unsuccessful. (I apologize if you've seen it twice) I would also like to argue we go with 1) or Derek's interpretation of 3) on the basis that *)Configuration Payload satisfies the basic needs(IP address, DNS, WINS) *)Most install base I am aware of uses ldap or RADIUS not DHCP as address server Regards! /Jing Jing Xiang, jxiang@nortelnetworks.com Nortel Networks Contivity Engineering -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Wednesday, February 26, 2003 2:13 PM To: Tylor Allison Cc: Van Aken Dirk; 'Gregory Lebovitz'; 'Theodore Ts'o'; ipsec@lists.tislabs.com; byfraser@cisco.com Subject: Re: Configuration portion of OPEN ISSUES... Tylor Allison writes: > > To clarify this open issue can we modify the list as follows (in order to > > not have any confusion on what we are discussing about): > > > > 1) Keep configuration payload > > 2) Remove configuration payload and pursue RFC 3456-style configuration > > 3) Keep configuration payload and allow optional RFC 3456-style > > configuration > > 4) Remove configuration payload and pursue an DHCP-over-IKE style > > configuration > > > > I'm in favour of 2) and can live with 3). > > > > Dirk > > I agree with this distinction in the options... > > I'd prefer to see option 1 or 4... don't really care which one. I strongly > disagree with option 3... leaving this optional really means implementing > both if you want to be interoperable with all vendors. I think option 3 needs to be clarified some before it's written off completely. My reading of option 3 is that you use the config payload for the IP Address, netmask, and a few, limited other options, and then optionally the client can use DHCP to obtain _other_ configuration informtation. Perhaps we need a "3a" and "3b" to define the different interpretations of what you have in option 3? If my interpretation of #3 is "correct", then I have no problem with it, because it does not affect the IPsec/IKE implementation at all. It's just a hook on the client to run the DHCP client once you're up on the net. The (standalone) DHCP client can perform further configuration (beyond IP Address leases, which you get from the config payload). Personally I don't have a strong opinion between 1, my interpretation of 3, and 4. I would lean towards 1 or my interpretation of 3, only because DHCP is larger and less bounded, so it would be nice to know we can complete the configuration process in 2 messages (via config) rather than 4-6 additional messages (via encapsulated DHCP). Size and latency do matter, to some extent. I think that all of it is dwarfed by RSA/DH operations, but the number of round trips does matter. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com ------_=_NextPart_001_01C2DF4A.83658E40-- From owner-ipsec@lists.tislabs.com Fri Feb 28 10:30:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SIUeY29179; Fri, 28 Feb 2003 10:30:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13249 Fri, 28 Feb 2003 13:02:08 -0500 (EST) To: Dan Harkins Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200302281717.h1SHHAE64102@homebrew.trpz.com> Date: 28 Feb 2003 13:00:20 -0500 In-Reply-To: <200302281717.h1SHHAE64102@homebrew.trpz.com> Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > I really prefer a la carte. The argument against-- that all combinations > are not tested-- is really specious. The argument against suites is > that they multiply like rabbits. Supporting IPcomp means 6 more. > Adding 2 D-H groups to the IPsec suites means 8 more. As an implementor I, too, prefer a la carte. I agree with your particular arguments. I happen to disagree with Hugo on the testing point. If you've tested 3DES, AES, HMAC-MD5, and HMAC-SHA1 in unit testing, I don't think you need a complete security analysis of the full matrix of possibilities. A block cipher is a block cipher, and are generally interchangable. The only argument I've heard that favors suits is from hardware vendors. Hardware is not as plug-and-play as software, so you can't necessarily do any combination. My answer to that concern is to just advertize the list of things you support. You can spell out the "supported harware suites" using the a la carte methods. I missed the Atlanta meeting where this was decided (I was chairing IMPP at the time). Before the meeting there was a fairly clear concensus on this list (IMNSHO, after reading ALL the mail on this list from May 2002 through January 2003 in one sitting) to use a la carte on the wire but suggest named suites for the (configuration) user interface. Indeed, I was shocked to see the mail after the Atlanta meeting that reversed what I thought was a clear consensus on the list. I still maintain that is the "best of all worlds". > thanks, > > Dan. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Feb 28 10:43:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SIhPY29837; Fri, 28 Feb 2003 10:43:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13309 Fri, 28 Feb 2003 13:12:18 -0500 (EST) To: Dan Harkins Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 References: <200302281709.h1SH9kE64070@homebrew.trpz.com> Date: 28 Feb 2003 13:11:33 -0500 In-Reply-To: <200302281709.h1SH9kE64070@homebrew.trpz.com> Message-ID: Lines: 62 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I happen to disagree with you here. Consider a situation where you have a single IPsec security gateway sitting at a single IP Address serving a bunch of separate VPNs. The Me Tarzan, You Jane concept allows the client to hint to the VPN server who it is and who it thinks it is. For example: Me warlord.laptop.ihtfp.com; You sgw.ihtfp.com Your client could say: Me harkins.trpz.com; You gateway.trpz.com Someone else could say: Me myname; You yourname In all cases it provides a hint of which identity to use, which is absolutely vital in a multi-identity situation. It's also extremely useful in the case of pre-shared (cached) RSA keys, to know which key to lookup to verify the rest of the exchange. Note that a number of IKEv1 implementations already have something like this (I know that both FreeS/WAN and KAME (racoon) have this kind of feature). Also, I personally happen to use it. -derek Dan Harkins writes: > When we began the IKEv2 effort we looked at things in IKEv1 that > at the time sounded like good ideas but in practice were rarely, > if ever, used-- e.g. phase 1 negotiation (hence the 4/6 exchange), > complex SA offers of (((A & B) | (C & D)) | E), etc.-- and we > decided to get rid of them in IKEv2. While these things were rarely > used they had to be supported by all. They're mandatory options. > I think "Me Tarzan, You Jane" will be another one. > > It is also poorly defined. What sort of identity is used as the > hint? What if the TR payloads are coarse and the identity is fine, > how does the SPD make sure that no packets mix that aren't from that > identity? When you have a pcb (or like data structure) to hang on > to it's possible but not all SAs will necessarily be tied to pcbs. > This is IP we're talking about anyway and identities and applications > are not in the realm of IP. Securing things based on identities or > applications is best left to protocol that have that context, like > TLS/SSL. > > This is a cute feature but I doubt it would be used in practice > and therefore it's just another mandatory option that everyone > has to implement but never use. It's the kind of thing we were > supposed to get rid of in IKEv2. Let's get rid of it. > > thanks, > > Dan. > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Feb 28 11:37:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJbSY06125; Fri, 28 Feb 2003 11:37:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13550 Fri, 28 Feb 2003 14:06:14 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200302281747.h1SHlej13565@sydney.East.Sun.COM> Date: Fri, 28 Feb 2003 12:47:57 -0500 To: Reply-To: Subject: Re: I-D ACTION:draft-ietf-ipsec-ikev2-tutorial-00.txt X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Don't read this one! I have a new version. This one I had to submit on time, but I was struggling with nroff which was truncating the document (because of a spurious period at the beginning of a line). I will submit the new one today, but if anyone wants me to email them the latest one, ask me, with a subject line of "please send" Radia From owner-ipsec@lists.tislabs.com Fri Feb 28 11:41:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJfFY06359; Fri, 28 Feb 2003 11:41:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13571 Fri,