From owner-ietf-ipsra@mail.vpnc.org Tue Nov 6 15:00:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00845 for ; Tue, 6 Nov 2001 15:00:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6JCr104552 for ietf-ipsra-bks; Tue, 6 Nov 2001 11:12:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6JCp804543 for ; Tue, 6 Nov 2001 11:12:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27926; Tue, 6 Nov 2001 14:12:50 -0500 (EST) Message-Id: <200111061912.OAA27926@ietf.org> To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: The IESG SUBJECT: Last Call: Requirements for IPsec Remote Access Scenarios to Informational Reply-to: iesg@ietf.org Date: Tue, 06 Nov 2001 14:12:50 -0500 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the IP Security Remote Access Working Group to consider Requirements for IPsec Remote Access Scenarios as an Informational RFC. 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 November 20, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-04.txt From owner-ietf-ipsra@mail.vpnc.org Wed Nov 7 19:48:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27262 for ; Wed, 7 Nov 2001 19:48:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA802qg19504 for ietf-ipsra-bks; Wed, 7 Nov 2001 16:02:52 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA802p819499 for ; Wed, 7 Nov 2001 16:02:51 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 7 Nov 2001 16:02:49 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Finishing PIC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks to all the people who participated in the post-IETF-last-call discussion. Based on the messages from the list and the couple of off-list messages I got: - Yaron and Hugo should revise the protocol to include the anti-DOS extra round trip. - There is an open question about TCP or UDP, but no consensus on what we should do. We should thus stay with UDP, but I will bring this issue to the attention of the IESG. Yaron and Hugo: please update the document as soon as possible, and certainly before the draft cutoff date. We should informally look at it in the WG after you do, and then I'll pass it on to the IESG noting that changes were made based on the IETF last call. Further, please remember that you were going to make some explanatory changes based on the messages between William Dixon and Yaron. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu Nov 8 23:01:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16610 for ; Thu, 8 Nov 2001 23:01:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA93GJW25732 for ietf-ipsra-bks; Thu, 8 Nov 2001 19:16:19 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA93GI825725; Thu, 8 Nov 2001 19:16:18 -0800 (PST) Received: from gwzpc ([10.21.100.21] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA11302; Thu, 8 Nov 2001 19:16:16 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Paul Hoffman / VPNC" , Subject: RE: Finishing PIC Date: Thu, 8 Nov 2001 19:16:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > Thanks to all the people who participated in the post-IETF-last-call > discussion. Based on the messages from the list and the couple of > off-list messages I got: > > - Yaron and Hugo should revise the protocol to include the anti-DOS > extra round trip. If the protocol is being modified, doesn't that send it back to WG Last Call? > > - There is an open question about TCP or UDP, but no consensus on > what we should do. We should thus stay with UDP, but I will bring > this issue to the attention of the IESG. > > Yaron and Hugo: please update the document as soon as possible, and > certainly before the draft cutoff date. We should informally look at > it in the WG after you do, and then I'll pass it on to the IESG > noting that changes were made based on the IETF last call. Further, > please remember that you were going to make some explanatory changes > based on the messages between William Dixon and Yaron. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Thu Nov 8 23:20:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16781 for ; Thu, 8 Nov 2001 23:20:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA93dfT26317 for ietf-ipsra-bks; Thu, 8 Nov 2001 19:39:41 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA93db826309; Thu, 8 Nov 2001 19:39:37 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 8 Nov 2001 19:39:39 -0800 To: , From: Paul Hoffman / VPNC Subject: RE: Finishing PIC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:16 PM -0800 11/8/01, Glen Zorn wrote: >If the protocol is being modified, doesn't that send it back to WG Last >Call? I don't think so. Where does it say that? Further, note that my message also said: > > We should informally look at > > it in the WG after you do, and then I'll pass it on to the IESG > > noting that changes were made based on the IETF last call. Did you want something more than that? --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 01:18:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19926 for ; Fri, 9 Nov 2001 01:18:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA95ddW28612 for ietf-ipsra-bks; Thu, 8 Nov 2001 21:39:39 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA95dc828606; Thu, 8 Nov 2001 21:39:38 -0800 (PST) Received: from gwzpc ([10.21.100.21] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA20921; Thu, 8 Nov 2001 21:39:37 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Paul Hoffman / VPNC" , Subject: RE: Finishing PIC Date: Thu, 8 Nov 2001 21:39:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > At 7:16 PM -0800 11/8/01, Glen Zorn wrote: > >If the protocol is being modified, doesn't that send it back to WG Last > >Call? > > I don't think so. Where does it say that? Touchy, touchy! :-) I was just asking... > > Further, note that my message also said: > > > > We should informally look at > > > it in the WG after you do, and then I'll pass it on to the IESG > > > noting that changes were made based on the IETF last call. > > Did you want something more than that? Well, I would think that if substantive technical changes have been made to the document then at least another trip through IETF Last Call would be in order. After all, in theory at least this protocol will be deployed on millions of workstations around the world... > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 04:15:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05270 for ; Fri, 9 Nov 2001 04:15:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA98cXQ17682 for ietf-ipsra-bks; Fri, 9 Nov 2001 00:38:33 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA98cV817672 for ; Fri, 9 Nov 2001 00:38:31 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 00:38:13 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Nov 2001 00:38:13 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 00:38:13 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 00:38:05 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Fri, 9 Nov 2001 00:37:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message Subject: RE: Moving PIC forwards Date: Fri, 9 Nov 2001 00:37:24 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68C2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Moving PIC forwards thread-index: AcFiZ3x7EDzFdu7OQ9Ccck+eaiQfcwGhz7Hw From: "William Dixon" To: "Yaron Sheffer" , "Markus Stenberg" , X-OriginalArrivalTime: 09 Nov 2001 08:37:25.0338 (UTC) FILETIME=[C1F663A0:01C168F9] Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maybe I'm just rehashing my earlier points, but it seems some folks aren't convinced about fragments being a problem. Let me first say a new thought: TCP may allow the PIC exchange to be more easily proxied, which means VPN client installation could be done, and PIC to get or renew the cert, from just about anywhere. The fragmentation problems I've seen result from passing certs in IKE, thus 3-4kbyte PKCS#7 blobs. These blobs contain the end-entity cert and the intermediate CA certs, possibly including the root cert. Yes, customers probably will use your dedicate VPN PKI if you make them and make it easy by integrating it into the VPN box. But the customers I've talked to don't want to deploy a separate PKI for VPN if they already have one. If PKI is done for a large enterprise, then they have a root and at least 2 intermediate CAs. Outsourcing PKI often means at least 1 or 2 intermediate CAs under a public PKI provider root, and access policy to trust just the issuer CA or intermediate CA, not trusting all certs from the public root. Yes, IKE can pass just the end-entity cert. But actually PIC must pass the whole chain and possibly the private root, so when the gateway passes the end-entity cert, it can be verified. So yes, fragmentation is a serious issue, even more serious for PIC than for IKE. My IKE deployment experience shows that in some way, some how, excessive fragments (like 4-5 fragments) will cause problems for clients connecting at some point in time. :Begin Story: Most recently I saw 3 weeks of time spent finding a "braindead" switch that dropped the 4th fragment out of 5, usually but not always. IKE retransmissions half of the time got the full ID exchange through, but retrans on both sides were required. The switch was sitting in a data center somewhere so it took quite a long time to locate, monitor, and repeat the test. Different owners of network equipment under different orgs, scheduling tests, bypassing the suspected device during the test while it was fully loaded, finally replacing/upgrading the equipment, etc. Lots of email, status reports, tracking and eliminating all the possible problems. So sure, that's one braindead switch, but one switch that affected half of the customer's VPN traffic, due to the way it was routed in from the Internet. They spent a month or so just hoping it would go away, dealing with the intermittent delay and loss of connectivity behavior, because clearly some clients had no problems and some did. They could not group the clients and understand why some did and didn't until they investigated traceroutes from 10-20 clients once the client part of the investigation got under way. They didn't immediately or even later, suspect it was their own switch in their own data center. It was unclear when investigating the problem whether it's a faulty switch, or a packet filter that doesn't track fragments. Filtering is very common at network boundaries. Ultimately every owner of every box in the path needed to be contacted and the configuration examined to determine what should have been passing through. All we knew from the start was the sniffs from the client showing fragments sent, and from the gateway, showing that they weren't making it. Thankfully return traffic from the gateway was routed along the same path as incoming traffic. :End Story: You might say this is a mute issue since PICs purpose is to provision IKE which might see the same fragmentation when it uses the cert, and along the same path. But I'd expect PIC will be re-purposed as a general secure encapsulation of cert request and response, which means that PIC won't necessarily go to the VPN gateway, it will go to the 3rd party Internet issuing CA, or the customer's issuing CA internally or their VPN provider's issuing CA on the Internet, along a much different path that the IKE negotiation to the IPSec GW. Certainly these non-VPN device Internet CAs would support TCP, and the client would support TCP. Other TCP based security protocols like SSL use certificates. 802.1x wireless authentication uses certificates. And EAP-TLS uses client certificates for Win2k's PPP dial, PPTP and L2TP user authentication. And of course PIC might even be useful for enrolling for a cert for S/MIME. Bernard already mentioned the perf impact of tracking fragments on border router filters. So if you can avoid fragmentation by allowing PIC over TCP, please do, OR, define a multiple payload continue method that IKE might even adopt :-) I think TCP is imminently more deployable. I guess the only thing I haven't rehashed from my last post was that PIC protocol extensions really must be provided for, like additional authentication data, and NAT traversal and DOS prevention. Wm -----Original Message----- From: Yaron Sheffer [mailto:yaronf@gmx.net] Sent: Wednesday, October 31, 2001 3:36 PM To: Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Actually, "kludging around existing crap" is very much in line with what we've been doing. After all, the whole point of IPSRA is to use *legacy* authentication methods... More to the point, a bare-bones PIC exchange is 2 RTT. For example, if you're only doing a simple challenge-response. Adding the DOS prevention round bring us to 3 RTT. While a TCP implementation adds 2 RTT for connection setup, bringing the number to 4 - TCP takes care of ensuring the originating address can be routed to, and you don't need a dedicated mechanism. An advantage of TCP is the well defined retry mechanism, compared with the fuzzy definition in ISAKMP (Sec. 5.1 of the RFC has some minimal details. The rest is left to your imagination.) A disadvantage is the complexity of dealing with TCP disconnects. But in our case we can simply drop the whole exchange. DOS-resistance is more of an issue. Nobody is going to implement a DOS-resistant TCP package on their hardware VPN, just to accommodate PIC. It all boils down to whether we expect separate PIC and IKE endpoints (in which case IKE/UDP with PIC/TCP make sense) or we expect them to be collocated. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg Sent: Wednesday, October 31, 2001 7:15 PM To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards aboba@internaut.com (Bernard Aboba) writes: > The fragmentation I've observed is already intentional. If people > aren't up for TCP, then another alternative would be support of a > "continuation" mechanism to spread the cert payload across multiple > UDP packets. What MTU should we use then? 576? Doesn't this triple+ number of packets in normal case and it'd happen only thanks to braindead routers? [ one can argue that 1500-byte packets are de facto, but one can also argue that is using ADSL+PPPoE with low MTU.. ] (Secondary alternative, own PMTU-detection scheme by trial-and-error, I won't even go to.. nor user configuration :P) Is the problem _really_ out there? I personally haven't encountered it much, but my cert chains have been mostly on short side. - If the problem is broken configuration of a firewall (i.e. I know of firewalls that have been configured with insanely low number of fragments to keep / time to keep them), then it can be amended (hopefully) by cluebrick. - If it's matter of product, we should just embrace some form of 'IPsec compatible' term to differentiate between broken and working firewalls. Admittedly, I know firsthand the pain of "we do not want to change " in organizations, but still, I find it interesting that some parties in IETF push for weird (and of course useful) stuff like IPv6 which requires total change of hardware et al, and others (like us, it seems) are mostly concerned in getting SOMETHING working by kludging around existing crap out there. (and to be politically correct, no offense, for the humor impaired that happen to have/work on firewall which is broken) -Markus From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 04:48:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05797 for ; Fri, 9 Nov 2001 04:48:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA99Drv22336 for ietf-ipsra-bks; Fri, 9 Nov 2001 01:13:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA99Do822320 for ; Fri, 9 Nov 2001 01:13:51 -0800 (PST) Received: (qmail 16582 invoked by uid 0); 9 Nov 2001 09:13:41 -0000 Received: from c3600-1-119.bezeqnet135.netvision.net.il (HELO oemcomputer) (62.0.186.121) by mail.gmx.net (mp004-rz3) with SMTP; 9 Nov 2001 09:13:41 -0000 From: "Yaron Sheffer" To: "William Dixon" , "Markus Stenberg" , Subject: RE: Moving PIC forwards Date: Fri, 9 Nov 2001 11:13:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" 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: <2E33960095B58E40A4D3345AB9F65EC102EE68C2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi William, fragmentation is obviously a serious issue. However, I'm worried that moving PIC to TCP could mean the death of this protocol, at least in the VPN space. Hardware VPN vendors don't trust TCP, because of the amount of state involved and the associated DOS exposure. And until PIC is "re-purposed", this is an important deployment segment. An admittedly ugly way around this issue is to make *both* UDP and TCP MUST on the client, and only UDP MUST on the server, with TCP being SHOULD or MAY. This would add complexity to the implementation and probably to configuration, too. Regarding your other points: PIC is extensible in the legacy authentication space, using EAP extensions. PIC has its own extension mechanisms for additional credential and credential request types. PIC does mention the issue of NAT, anticipating the solution that will probably be adopted by IKE (i.e. to float the port, the rest of the IKE NAT issues don't exist in PIC). On DOS prevention: if you guys want another round just to verify routability of the initiator, fine. I hope Paul is right and we can get by without a second WG last call. Paul, once this issue is resolved we will publish a new version, hopefully in the next week, and certainly before Nov. 21. Thanks, Yaron -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Friday, November 09, 2001 10:37 AM To: Yaron Sheffer; Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Maybe I'm just rehashing my earlier points, but it seems some folks aren't convinced about fragments being a problem. Let me first say a new thought: TCP may allow the PIC exchange to be more easily proxied, which means VPN client installation could be done, and PIC to get or renew the cert, from just about anywhere. The fragmentation problems I've seen result from passing certs in IKE, thus 3-4kbyte PKCS#7 blobs. These blobs contain the end-entity cert and the intermediate CA certs, possibly including the root cert. Yes, customers probably will use your dedicate VPN PKI if you make them and make it easy by integrating it into the VPN box. But the customers I've talked to don't want to deploy a separate PKI for VPN if they already have one. If PKI is done for a large enterprise, then they have a root and at least 2 intermediate CAs. Outsourcing PKI often means at least 1 or 2 intermediate CAs under a public PKI provider root, and access policy to trust just the issuer CA or intermediate CA, not trusting all certs from the public root. Yes, IKE can pass just the end-entity cert. But actually PIC must pass the whole chain and possibly the private root, so when the gateway passes the end-entity cert, it can be verified. So yes, fragmentation is a serious issue, even more serious for PIC than for IKE. My IKE deployment experience shows that in some way, some how, excessive fragments (like 4-5 fragments) will cause problems for clients connecting at some point in time. :Begin Story: Most recently I saw 3 weeks of time spent finding a "braindead" switch that dropped the 4th fragment out of 5, usually but not always. IKE retransmissions half of the time got the full ID exchange through, but retrans on both sides were required. The switch was sitting in a data center somewhere so it took quite a long time to locate, monitor, and repeat the test. Different owners of network equipment under different orgs, scheduling tests, bypassing the suspected device during the test while it was fully loaded, finally replacing/upgrading the equipment, etc. Lots of email, status reports, tracking and eliminating all the possible problems. So sure, that's one braindead switch, but one switch that affected half of the customer's VPN traffic, due to the way it was routed in from the Internet. They spent a month or so just hoping it would go away, dealing with the intermittent delay and loss of connectivity behavior, because clearly some clients had no problems and some did. They could not group the clients and understand why some did and didn't until they investigated traceroutes from 10-20 clients once the client part of the investigation got under way. They didn't immediately or even later, suspect it was their own switch in their own data center. It was unclear when investigating the problem whether it's a faulty switch, or a packet filter that doesn't track fragments. Filtering is very common at network boundaries. Ultimately every owner of every box in the path needed to be contacted and the configuration examined to determine what should have been passing through. All we knew from the start was the sniffs from the client showing fragments sent, and from the gateway, showing that they weren't making it. Thankfully return traffic from the gateway was routed along the same path as incoming traffic. :End Story: You might say this is a mute issue since PICs purpose is to provision IKE which might see the same fragmentation when it uses the cert, and along the same path. But I'd expect PIC will be re-purposed as a general secure encapsulation of cert request and response, which means that PIC won't necessarily go to the VPN gateway, it will go to the 3rd party Internet issuing CA, or the customer's issuing CA internally or their VPN provider's issuing CA on the Internet, along a much different path that the IKE negotiation to the IPSec GW. Certainly these non-VPN device Internet CAs would support TCP, and the client would support TCP. Other TCP based security protocols like SSL use certificates. 802.1x wireless authentication uses certificates. And EAP-TLS uses client certificates for Win2k's PPP dial, PPTP and L2TP user authentication. And of course PIC might even be useful for enrolling for a cert for S/MIME. Bernard already mentioned the perf impact of tracking fragments on border router filters. So if you can avoid fragmentation by allowing PIC over TCP, please do, OR, define a multiple payload continue method that IKE might even adopt :-) I think TCP is imminently more deployable. I guess the only thing I haven't rehashed from my last post was that PIC protocol extensions really must be provided for, like additional authentication data, and NAT traversal and DOS prevention. Wm -----Original Message----- From: Yaron Sheffer [mailto:yaronf@gmx.net] Sent: Wednesday, October 31, 2001 3:36 PM To: Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Actually, "kludging around existing crap" is very much in line with what we've been doing. After all, the whole point of IPSRA is to use *legacy* authentication methods... More to the point, a bare-bones PIC exchange is 2 RTT. For example, if you're only doing a simple challenge-response. Adding the DOS prevention round bring us to 3 RTT. While a TCP implementation adds 2 RTT for connection setup, bringing the number to 4 - TCP takes care of ensuring the originating address can be routed to, and you don't need a dedicated mechanism. An advantage of TCP is the well defined retry mechanism, compared with the fuzzy definition in ISAKMP (Sec. 5.1 of the RFC has some minimal details. The rest is left to your imagination.) A disadvantage is the complexity of dealing with TCP disconnects. But in our case we can simply drop the whole exchange. DOS-resistance is more of an issue. Nobody is going to implement a DOS-resistant TCP package on their hardware VPN, just to accommodate PIC. It all boils down to whether we expect separate PIC and IKE endpoints (in which case IKE/UDP with PIC/TCP make sense) or we expect them to be collocated. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg Sent: Wednesday, October 31, 2001 7:15 PM To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards aboba@internaut.com (Bernard Aboba) writes: > The fragmentation I've observed is already intentional. If people > aren't up for TCP, then another alternative would be support of a > "continuation" mechanism to spread the cert payload across multiple > UDP packets. What MTU should we use then? 576? Doesn't this triple+ number of packets in normal case and it'd happen only thanks to braindead routers? [ one can argue that 1500-byte packets are de facto, but one can also argue that is using ADSL+PPPoE with low MTU.. ] (Secondary alternative, own PMTU-detection scheme by trial-and-error, I won't even go to.. nor user configuration :P) Is the problem _really_ out there? I personally haven't encountered it much, but my cert chains have been mostly on short side. - If the problem is broken configuration of a firewall (i.e. I know of firewalls that have been configured with insanely low number of fragments to keep / time to keep them), then it can be amended (hopefully) by cluebrick. - If it's matter of product, we should just embrace some form of 'IPsec compatible' term to differentiate between broken and working firewalls. Admittedly, I know firsthand the pain of "we do not want to change " in organizations, but still, I find it interesting that some parties in IETF push for weird (and of course useful) stuff like IPv6 which requires total change of hardware et al, and others (like us, it seems) are mostly concerned in getting SOMETHING working by kludging around existing crap out there. (and to be politically correct, no offense, for the humor impaired that happen to have/work on firewall which is broken) -Markus From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 05:55:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06328 for ; Fri, 9 Nov 2001 05:55:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9A3So29415 for ietf-ipsra-bks; Fri, 9 Nov 2001 02:03:28 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9A3Q829408 for ; Fri, 9 Nov 2001 02:03:26 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 02:03:08 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Nov 2001 02:03:08 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 02:03:08 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 02:03:04 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Fri, 9 Nov 2001 02:02:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Moving PIC forwards Date: Fri, 9 Nov 2001 02:02:22 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68C3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Moving PIC forwards thread-index: AcFo/rf9TxWcD4DcSkm0/OzEe2nqOAAAcr1A From: "William Dixon" To: "Yaron Sheffer" , "Markus Stenberg" , X-OriginalArrivalTime: 09 Nov 2001 10:02:23.0590 (UTC) FILETIME=[A0C1E860:01C16905] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fA9A3Q829409 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yaron, I think it's fine for PIC to use UDP as in can obviously work for single cert retrieval from a VPN box that is the issuing CA or Proxy Registration Authority for a dedicated root CA. And of course it could fragment like IKE does if/as needed. I just don't want to prohibit the use of TCP for clients and servers that can use it, and deployments that need it. Fine to include a security caution or special section listing the potential drawbacks to using TCP. Re: extensions - the only clarification needed, and I guess agreed to, is that one MUST ignore unrecognized payload types, but calculate the hash correctly to include them, which you do say in the HASH definition. I just doubt that people will really support that for extension payloads they don't understand. Yes, I forgot for a moment that EAP was the full encapsulation for exchange of authentication info. -----Original Message----- From: Yaron Sheffer [mailto:yaronf@gmx.net] Sent: Friday, November 09, 2001 1:13 AM To: William Dixon; Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Hi William, fragmentation is obviously a serious issue. However, I'm worried that moving PIC to TCP could mean the death of this protocol, at least in the VPN space. Hardware VPN vendors don't trust TCP, because of the amount of state involved and the associated DOS exposure. And until PIC is "re-purposed", this is an important deployment segment. An admittedly ugly way around this issue is to make *both* UDP and TCP MUST on the client, and only UDP MUST on the server, with TCP being SHOULD or MAY. This would add complexity to the implementation and probably to configuration, too. Regarding your other points: PIC is extensible in the legacy authentication space, using EAP extensions. PIC has its own extension mechanisms for additional credential and credential request types. PIC does mention the issue of NAT, anticipating the solution that will probably be adopted by IKE (i.e. to float the port, the rest of the IKE NAT issues don't exist in PIC). On DOS prevention: if you guys want another round just to verify routability of the initiator, fine. I hope Paul is right and we can get by without a second WG last call. Paul, once this issue is resolved we will publish a new version, hopefully in the next week, and certainly before Nov. 21. Thanks, Yaron -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Friday, November 09, 2001 10:37 AM To: Yaron Sheffer; Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Maybe I'm just rehashing my earlier points, but it seems some folks aren't convinced about fragments being a problem. Let me first say a new thought: TCP may allow the PIC exchange to be more easily proxied, which means VPN client installation could be done, and PIC to get or renew the cert, from just about anywhere. The fragmentation problems I've seen result from passing certs in IKE, thus 3-4kbyte PKCS#7 blobs. These blobs contain the end-entity cert and the intermediate CA certs, possibly including the root cert. Yes, customers probably will use your dedicate VPN PKI if you make them and make it easy by integrating it into the VPN box. But the customers I've talked to don't want to deploy a separate PKI for VPN if they already have one. If PKI is done for a large enterprise, then they have a root and at least 2 intermediate CAs. Outsourcing PKI often means at least 1 or 2 intermediate CAs under a public PKI provider root, and access policy to trust just the issuer CA or intermediate CA, not trusting all certs from the public root. Yes, IKE can pass just the end-entity cert. But actually PIC must pass the whole chain and possibly the private root, so when the gateway passes the end-entity cert, it can be verified. So yes, fragmentation is a serious issue, even more serious for PIC than for IKE. My IKE deployment experience shows that in some way, some how, excessive fragments (like 4-5 fragments) will cause problems for clients connecting at some point in time. :Begin Story: Most recently I saw 3 weeks of time spent finding a "braindead" switch that dropped the 4th fragment out of 5, usually but not always. IKE retransmissions half of the time got the full ID exchange through, but retrans on both sides were required. The switch was sitting in a data center somewhere so it took quite a long time to locate, monitor, and repeat the test. Different owners of network equipment under different orgs, scheduling tests, bypassing the suspected device during the test while it was fully loaded, finally replacing/upgrading the equipment, etc. Lots of email, status reports, tracking and eliminating all the possible problems. So sure, that's one braindead switch, but one switch that affected half of the customer's VPN traffic, due to the way it was routed in from the Internet. They spent a month or so just hoping it would go away, dealing with the intermittent delay and loss of connectivity behavior, because clearly some clients had no problems and some did. They could not group the clients and understand why some did and didn't until they investigated traceroutes from 10-20 clients once the client part of the investigation got under way. They didn't immediately or even later, suspect it was their own switch in their own data center. It was unclear when investigating the problem whether it's a faulty switch, or a packet filter that doesn't track fragments. Filtering is very common at network boundaries. Ultimately every owner of every box in the path needed to be contacted and the configuration examined to determine what should have been passing through. All we knew from the start was the sniffs from the client showing fragments sent, and from the gateway, showing that they weren't making it. Thankfully return traffic from the gateway was routed along the same path as incoming traffic. :End Story: You might say this is a mute issue since PICs purpose is to provision IKE which might see the same fragmentation when it uses the cert, and along the same path. But I'd expect PIC will be re-purposed as a general secure encapsulation of cert request and response, which means that PIC won't necessarily go to the VPN gateway, it will go to the 3rd party Internet issuing CA, or the customer's issuing CA internally or their VPN provider's issuing CA on the Internet, along a much different path that the IKE negotiation to the IPSec GW. Certainly these non-VPN device Internet CAs would support TCP, and the client would support TCP. Other TCP based security protocols like SSL use certificates. 802.1x wireless authentication uses certificates. And EAP-TLS uses client certificates for Win2k's PPP dial, PPTP and L2TP user authentication. And of course PIC might even be useful for enrolling for a cert for S/MIME. Bernard already mentioned the perf impact of tracking fragments on border router filters. So if you can avoid fragmentation by allowing PIC over TCP, please do, OR, define a multiple payload continue method that IKE might even adopt :-) I think TCP is imminently more deployable. I guess the only thing I haven't rehashed from my last post was that PIC protocol extensions really must be provided for, like additional authentication data, and NAT traversal and DOS prevention. Wm -----Original Message----- From: Yaron Sheffer [mailto:yaronf@gmx.net] Sent: Wednesday, October 31, 2001 3:36 PM To: Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards Actually, "kludging around existing crap" is very much in line with what we've been doing. After all, the whole point of IPSRA is to use *legacy* authentication methods... More to the point, a bare-bones PIC exchange is 2 RTT. For example, if you're only doing a simple challenge-response. Adding the DOS prevention round bring us to 3 RTT. While a TCP implementation adds 2 RTT for connection setup, bringing the number to 4 - TCP takes care of ensuring the originating address can be routed to, and you don't need a dedicated mechanism. An advantage of TCP is the well defined retry mechanism, compared with the fuzzy definition in ISAKMP (Sec. 5.1 of the RFC has some minimal details. The rest is left to your imagination.) A disadvantage is the complexity of dealing with TCP disconnects. But in our case we can simply drop the whole exchange. DOS-resistance is more of an issue. Nobody is going to implement a DOS-resistant TCP package on their hardware VPN, just to accommodate PIC. It all boils down to whether we expect separate PIC and IKE endpoints (in which case IKE/UDP with PIC/TCP make sense) or we expect them to be collocated. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg Sent: Wednesday, October 31, 2001 7:15 PM To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards aboba@internaut.com (Bernard Aboba) writes: > The fragmentation I've observed is already intentional. If people > aren't up for TCP, then another alternative would be support of a > "continuation" mechanism to spread the cert payload across multiple > UDP packets. What MTU should we use then? 576? Doesn't this triple+ number of packets in normal case and it'd happen only thanks to braindead routers? [ one can argue that 1500-byte packets are de facto, but one can also argue that is using ADSL+PPPoE with low MTU.. ] (Secondary alternative, own PMTU-detection scheme by trial-and-error, I won't even go to.. nor user configuration :P) Is the problem _really_ out there? I personally haven't encountered it much, but my cert chains have been mostly on short side. - If the problem is broken configuration of a firewall (i.e. I know of firewalls that have been configured with insanely low number of fragments to keep / time to keep them), then it can be amended (hopefully) by cluebrick. - If it's matter of product, we should just embrace some form of 'IPsec compatible' term to differentiate between broken and working firewalls. Admittedly, I know firsthand the pain of "we do not want to change " in organizations, but still, I find it interesting that some parties in IETF push for weird (and of course useful) stuff like IPv6 which requires total change of hardware et al, and others (like us, it seems) are mostly concerned in getting SOMETHING working by kludging around existing crap out there. (and to be politically correct, no offense, for the humor impaired that happen to have/work on firewall which is broken) -Markus From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 10:53:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16332 for ; Fri, 9 Nov 2001 10:53:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9F6Ei19704 for ietf-ipsra-bks; Fri, 9 Nov 2001 07:06:14 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9F6D819699 for ; Fri, 9 Nov 2001 07:06:13 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA59700; Fri, 9 Nov 2001 06:56:27 -0800 (PST) (envelope-from aboba@internaut.com) Date: Fri, 9 Nov 2001 06:56:27 -0800 (PST) From: Bernard Aboba To: Yaron Sheffer cc: William Dixon , Markus Stenberg , ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > fragmentation is obviously a serious issue. However, I'm worried that moving > PIC to TCP could mean the death of this protocol, at least in the VPN space. > Hardware VPN vendors don't trust TCP, because of the amount of state > involved and the associated DOS exposure. And until PIC is "re-purposed", > this is an important deployment segment. OK. So what about a "cert continuation" payload? I'd note that PIC already supports multiple round-trips, and EAP methods can already support such continuations (see RFC 2716). From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 11:19:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17118 for ; Fri, 9 Nov 2001 11:19:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9FbHS21546 for ietf-ipsra-bks; Fri, 9 Nov 2001 07:37:17 -0800 (PST) Received: from redcreek4.redcreek.com (fw.redcreek.com [209.218.199.28] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9FbG821542 for ; Fri, 9 Nov 2001 07:37:16 -0800 (PST) Received: by redcreek4.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 07:37:11 -0800 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WMRSA66N; Fri, 9 Nov 2001 07:38:57 -0800 Message-ID: <3BEBF836.5D73175A@redcreek.com> Date: Fri, 09 Nov 2001 07:37:26 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: Yaron Sheffer , William Dixon , Markus Stenberg , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with both points below. I think UDP should be a MUST, implying that we need a cert continuation mechanism of some sort. I also think we should make TCP a MAY, and reserve a port for it. Scott Bernard Aboba wrote: > > > fragmentation is obviously a serious issue. However, I'm worried that moving > > PIC to TCP could mean the death of this protocol, at least in the VPN space. > > Hardware VPN vendors don't trust TCP, because of the amount of state > > involved and the associated DOS exposure. And until PIC is "re-purposed", > > this is an important deployment segment. > > OK. So what about a "cert continuation" payload? I'd note that PIC already > supports multiple round-trips, and EAP methods can already support such > continuations (see RFC 2716). From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 12:48:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20722 for ; Fri, 9 Nov 2001 12:48:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9H2OI29922 for ietf-ipsra-bks; Fri, 9 Nov 2001 09:02:24 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9H2M829918 for ; Fri, 9 Nov 2001 09:02:22 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Fri, 9 Nov 2001 09:02:15 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: RE: Finishing PIC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 9:39 PM -0800 11/8/01, Glen Zorn wrote: >Well, I would think that if substantive technical changes have been made to >the document then at least another trip through IETF Last Call would be in >order. That is a decision for the ADs, not for the WG chairs. As I said, I will point out the protocol change when I send it on to the ADs, and they can decide whether or not that warrants another IETF last call. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Nov 9 15:33:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26850 for ; Fri, 9 Nov 2001 15:33:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9JrSM09105 for ietf-ipsra-bks; Fri, 9 Nov 2001 11:53:28 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9JrR809099; Fri, 9 Nov 2001 11:53:27 -0800 (PST) Received: from gwzpc (rtp-vpn2-108.cisco.com [10.82.240.108]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA28718; Fri, 9 Nov 2001 11:53:23 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Paul Hoffman / VPNC" , Subject: RE: Finishing PIC Date: Fri, 9 Nov 2001 11:53:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > At 9:39 PM -0800 11/8/01, Glen Zorn wrote: > >Well, I would think that if substantive technical changes have > been made to > >the document then at least another trip through IETF Last Call > would be in > >order. > > That is a decision for the ADs, not for the WG chairs. Note that I said "at least another trip through IETF Last Call"; I would actually expect that you would want another WG Last Call, but that appears not to be the case. This, of course, begs the question, "What's the hurry?". I can't imagine that the same vendors which have spent so much time and money "differentiating" their products by creating pair-wise mtually incompatible versions of xauth & mode config (except for the "bake-off versions", which actually interoperate -- sometimes) are frothing at the mouth to embrace a new "standard". Is everybody just too tired to go on, or what? > As I said, I > will point out the protocol change when I send it on to the ADs, and > they can decide whether or not that warrants another IETF last call. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Mon Nov 12 06:08:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24552 for ; Mon, 12 Nov 2001 06:08:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACANat14934 for ietf-ipsra-bks; Mon, 12 Nov 2001 02:23:36 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACANY814929 for ; Mon, 12 Nov 2001 02:23:34 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fACANRC19493; Mon, 12 Nov 2001 11:23:28 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fACANNB12876; Mon, 12 Nov 2001 12:23:24 +0200 (EET) Message-ID: <3BEFA31B.5E9D3AF9@lmf.ericsson.se> Date: Mon, 12 Nov 2001 12:23:23 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Bernard Aboba , Yaron Sheffer , William Dixon , Markus Stenberg , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: <3BEBF836.5D73175A@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds good! > I agree with both points below. I think UDP should be a MUST, implying > that we need a cert continuation mechanism of some sort. I also think we > should make TCP a MAY, and reserve a port for it. > > Scott > > Bernard Aboba wrote: > > > > > fragmentation is obviously a serious issue. However, I'm worried that moving > > > PIC to TCP could mean the death of this protocol, at least in the VPN space. > > > Hardware VPN vendors don't trust TCP, because of the amount of state > > > involved and the associated DOS exposure. And until PIC is "re-purposed", > > > this is an important deployment segment. > > > > OK. So what about a "cert continuation" payload? I'd note that PIC already > > supports multiple round-trips, and EAP methods can already support such > > continuations (see RFC 2716). From owner-ietf-ipsra@mail.vpnc.org Fri Nov 16 15:45:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24730 for ; Fri, 16 Nov 2001 15:45:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGJQfU06579 for ietf-ipsra-bks; Fri, 16 Nov 2001 11:26:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAGJQc806571 for ; Fri, 16 Nov 2001 11:26:39 -0800 (PST) Received: (qmail 13086 invoked by uid 0); 16 Nov 2001 19:26:32 -0000 Received: from c3600-2-59.bezeqnet135.netvision.net.il (HELO oemcomputer) (62.0.186.183) by mail.gmx.net (mp011-rz3) with SMTP; 16 Nov 2001 19:26:32 -0000 From: "Yaron Sheffer" To: "William Dixon" , "Markus Stenberg" , Subject: RE: Moving PIC forwards Date: Fri, 16 Nov 2001 21:26:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" 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 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102EE68C2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In a previous mail replying to William I mentioned that PIC can be extended via the use of additional payload types. However PIC is layered on top of ISAKMP, and at least my reading of ISAKMP is that if an unknown payload is received, the entire message is discarded - you don't just "silently ignore" the payload. Quoting from ISAKMP: "[Under "Payload Processing":] Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken..." This obviously makes it hard to use new payload types to extend PIC, in particular for the first message, before a Vendor ID payload can be sent. Am I misreading ISAKMP? Are real-life IKE implementations different? Please enlighten me. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of William Dixon Sent: Friday, November 09, 2001 10:37 AM To: Yaron Sheffer; Markus Stenberg; ietf-ipsra@vpnc.org Subject: RE: Moving PIC forwards [Long discussion deleted] I guess the only thing I haven't rehashed from my last post was that PIC protocol extensions really must be provided for, like additional authentication data, and NAT traversal and DOS prevention. Wm From owner-ietf-ipsra@mail.vpnc.org Tue Nov 20 17:43:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09623 for ; Tue, 20 Nov 2001 17:43:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKLtE725009 for ietf-ipsra-bks; Tue, 20 Nov 2001 13:55:14 -0800 (PST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLtA825003 for ; Tue, 20 Nov 2001 13:55:11 -0800 (PST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.10.2+Sun/8.10.2) with ESMTP id fAKLtM706904 for ; Tue, 20 Nov 2001 23:55:22 +0200 (IST) Date: Tue, 20 Nov 2001 23:55:22 +0200 (IST) From: Hugo Krawczyk To: IPSRA WG Subject: PIC version 04 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We have submitted version 04 of the PIC draft draft-ietf-ipsra-pic-04.txt Main changes are: - added an optional round trip for cookie protection against DoS - optional transport over TCP to avoid packet fragmentation - full ISAKMP headers added under HASH These are all changes requested during last call. An additional last call (or extension) would be in place, for people to review these changes (in particular the proposed DoS protection and cookie mechanism) For those that cannot wait until the busy I-D editor publishes the draft, here is a temporary url with the draft: http://tiger.technion.ac.il/~hugo/draft-ietf-ipsra-pic-04.txt Enjoy... Hugo From owner-ietf-ipsra@mail.vpnc.org Wed Nov 21 17:17:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11131 for ; Wed, 21 Nov 2001 17:17:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALLYRB21769 for ietf-ipsra-bks; Wed, 21 Nov 2001 13:34:27 -0800 (PST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLYQ821765 for ; Wed, 21 Nov 2001 13:34:26 -0800 (PST) Received: from netmail1.ca.alcatel.com (netmail1.ca.alcatel.com [138.120.105.104]) by netmail.alcatel.com (8.9.1/8.9.1) with SMTP id PAA18625 for ; Wed, 21 Nov 2001 15:34:19 -0600 (CST) Received: (qmail 9580 invoked from network); 21 Nov 2001 19:49:36 -0000 Received: from kanmail02.ca.alcatel.com (HELO kanmail02.ca.newbridge.com) (138.120.118.14) by netmail1.ca.alcatel.com with SMTP; 21 Nov 2001 19:49:36 -0000 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3AB3; Wed, 21 Nov 2001 14:48:47 -0500 Reply-To: From: "Andrew Krywaniuk" To: "'Yaron Sheffer'" , Subject: RE: Moving PIC forwards Date: Wed, 21 Nov 2001 14:46:35 -0500 Message-ID: <000301c172c5$3b05e390$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think most people will abort the negotiation if they receive an unknown payload type. This caused a problem for some implementers when the vendor id payload was added. But without a critical bit, how do you know if it is safe to ignore them? However, most people decided not to reject unknown attribute types in an SA proposal that they don't accept. It seemed the sensible thing to do, since the inclusion of alternate proposals implies that the attibute is not critical. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Yaron Sheffer > Sent: Friday, November 16, 2001 2:26 PM > To: William Dixon; Markus Stenberg; ietf-ipsra@vpnc.org > Subject: RE: Moving PIC forwards > > > > In a previous mail replying to William I mentioned that PIC > can be extended > via the use of additional payload types. However PIC is > layered on top of > ISAKMP, and at least my reading of ISAKMP is that if an > unknown payload is > received, the entire message is discarded - you don't just > "silently ignore" > the payload. Quoting from ISAKMP: > > "[Under "Payload Processing":] Check the Next Payload field > to confirm it is > valid. If the Next Payload field validation fails, the > message is discarded > and the following actions are taken..." > > This obviously makes it hard to use new payload types to > extend PIC, in > particular for the first message, before a Vendor ID payload > can be sent. > > Am I misreading ISAKMP? Are real-life IKE implementations > different? Please > enlighten me. > > Thanks, > Yaron > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of William Dixon > Sent: Friday, November 09, 2001 10:37 AM > To: Yaron Sheffer; Markus Stenberg; ietf-ipsra@vpnc.org > Subject: RE: Moving PIC forwards > > [Long discussion deleted] > > I guess the only thing I haven't rehashed from my last post > was that PIC > protocol extensions really must be provided for, like additional > authentication data, and NAT traversal and DOS prevention. > > Wm > > > From owner-ietf-ipsra@mail.vpnc.org Wed Nov 28 06:44:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01358 for ; Wed, 28 Nov 2001 06:44:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASAsoV00416 for ietf-ipsra-bks; Wed, 28 Nov 2001 02:54:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASAsm800408 for ; Wed, 28 Nov 2001 02:54:49 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28260; Wed, 28 Nov 2001 05:54:44 -0500 (EST) Message-Id: <200111281054.FAA28260@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-pic-04.txt Date: Wed, 28 Nov 2001 05:54:44 -0500 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Remote Access Working Group of the IETF. Title : PIC, A Pre-IKE Credential Provisioning Protocol Author(s) : Y. Sheffer, H. Krawczyk, B. Aboba Filename : draft-ietf-ipsra-pic-04.txt Pages : 23 Date : 27-Nov-01 This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsra-pic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsra-pic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127134454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-pic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-pic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134454.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Wed Nov 28 12:30:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23675 for ; Wed, 28 Nov 2001 12:30:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASGnuf29280 for ietf-ipsra-bks; Wed, 28 Nov 2001 08:49:56 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASGns829267 for ; Wed, 28 Nov 2001 08:49:54 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 28 Nov 2001 08:49:39 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: New last call for PIC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. The PIC authors have revised their document and their protocol; it is available at . Please read the document carefully again, particularly the protocol changes. Make any comments on the document to the WG mailing list soon so that we can discuss the comments fully. If there is rough consensus that the document is good, we'll pass it to the IESG in three weeks (December 19). If there is not rough consensus, we'll do another round on the document and another last call. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Wed Nov 28 13:28:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27686 for ; Wed, 28 Nov 2001 13:28:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fASHepZ02386 for ietf-ipsra-bks; Wed, 28 Nov 2001 09:40:51 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASHeo802379; Wed, 28 Nov 2001 09:40:50 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA00723; Wed, 28 Nov 2001 09:29:36 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 28 Nov 2001 09:29:36 -0800 (PST) From: Bernard Aboba To: Paul Hoffman / VPNC cc: ietf-ipsra@vpnc.org Subject: Re: New last call for PIC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some comments: Section 4.2 does not seem to reflect the addition of TCP transport support. The discussion should therefore be prefaced with a statement such as "For PIC operating over UDP..." Since there was a concern expressed about RST attacks, it might be worth considering whether there is a way to protect the TCP session using the TCP MD5 option (RFC 2385). Prior to the key exchange, this is not possible, but afterward a "session authentication key" could be derived and used for this purpose. Just a thought. As for the NAT issues, while it is probably not appropriate to incorporate the NAT/IKE functionality at the moment, some important things have been learned from the testing that has been done. One of these is that NATs typically cannot handle fragments; another is that NATs frequently de-multiplex packets sent to port 501, using the IKE cookies. So rather than saying that "PIC temporarily uses port 501" I would say "PIC uses port both for TCP and UDP", just so people don't get confused. On Wed, 28 Nov 2001, Paul Hoffman / VPNC wrote: > > Greetings again. The PIC authors have revised their document and > their protocol; it is available at > . > > Please read the document carefully again, particularly the protocol > changes. Make any comments on the document to the WG mailing list > soon so that we can discuss the comments fully. > > If there is rough consensus that the document is good, we'll pass it > to the IESG in three weeks (December 19). If there is not rough > consensus, we'll do another round on the document and another last > call. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Fri Nov 30 12:24:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22763 for ; Fri, 30 Nov 2001 12:24:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAUGSxn07342 for ietf-ipsra-bks; Fri, 30 Nov 2001 08:28:59 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUGSx807338 for ; Fri, 30 Nov 2001 08:28:59 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA19693; Fri, 30 Nov 2001 11:34:00 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma019678; Fri, 30 Nov 01 11:33:15 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fAUGSFJ24166 for ietf-ipsra@vpnc.org; Fri, 30 Nov 2001 11:28:15 -0500 (EST) Date: Fri, 30 Nov 2001 11:28:15 -0500 (EST) Message-Id: <200111301628.fAUGSFJ24166@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-ipsra@vpnc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications.