From owner-ipsec@lists.tislabs.com Fri Sep 1 02:13:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA13745; Fri, 1 Sep 2000 02:13:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04001 Fri, 1 Sep 2000 03:27:28 -0400 (EDT) Message-ID: From: Michel de Koning To: "'Strahm, Bill'" , Michel de Koning , "'John C. Day'" , ipsec@lists.tislabs.com Subject: RE: Looking for info on ipsec passthrough (or passthru?) Date: Fri, 1 Sep 2000 09:36:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed ; boundary="----_=_NextPart_000_01C013E7.6D4CC618" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C013E7.6D4CC618 Content-Type: text/plain; charset="iso-8859-1" Bill, It's an Altiga / Cisco propietary solution. Check out the link to the pdf. Some information about it is in 12-11 of this user guide. Kind Regards, Michel de Koning Tel: +31 341 37 5427 Fax: +31 341 37 5433 Mobile: +31 651 44 68 51 E-mail: mdkoning@vanenburg.com -----Original Message----- From: Strahm, Bill [mailto:bill.strahm@intel.com] Sent: Thursday, August 31, 2000 5:57 PM To: 'Michel de Koning'; 'John C. Day'; Strahm, Bill; ipsec@lists.tislabs.com Subject: RE: Looking for info on ipsec passthrough (or passthru?) Ok, I am confused... IPsec used ESP or AH packets, not TCP or UDP (they can be encapsulated of course) What do you mean by your first paragraph ??? Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Michel de Koning [mailto:mdkoning@vanenburg.com] > Sent: Wednesday, August 30, 2000 1:59 PM > To: 'John C. Day'; Strahm, Bill; ipsec@lists.tislabs.com > Subject: RE: Looking for info on ipsec passthrough (or passthru?) > > > Hi John, > > currently we are testing (playing with) an Altiga / Cisco 3000 vpn > concentrator. It allows IPsec Passthru Nat. haven't read > everything yet, but > the principle is that is uses UDP instead of TCP for the > IPSec packets. As > soon as we have tested it I will let you know. > > Must say this Altiga box is really great so far, the bad > thing is it does > not support win2000 clients unless you use certificates, this because > win2000 client does not support mode-config. Cisco says "the > altiga client > for win2000 will ship in october"...... > > Usually when cisco buys something you have to wait for > version 2 before it > will really work :-), let's wait and see.. > > We had the Altiga up and running with NT4 using PPTP and > after that IPSec > within an afternoon. And this was before reading the > documentation! Look at > it I would say > > > Michel > > -----Oorspronkelijk bericht----- > Van: John C. Day [mailto:JCDay@JCDay.com] > Verzonden: Wednesday, August 30, 2000 6:03 PM > Aan: Strahm, Bill; ipsec@lists.tislabs.com > Onderwerp: RE: Looking for info on ipsec passthrough (or passthru?) > > > Thanks for the response, Bill. > > What I'm looking for is something which will enable me to use > an IPSec VPN > client (Cisco/Altiga) from a privately addressed machine at > home which sits > behind the Linksys device which in turn is connected to my DSL > bridge. The VPN server sits (or will sit, to be more > accurate - it's > ordered but not in hand yet) on our corporate DMZ . > > Would you guess this passthru feature enables such a > connection? I.e., it > NATs everything other than what it sees on the VPN port? > While a hack, > that would seem to accomplish what we need. Is there better > way to do > it? Thanks. > > John > > > > > At 08:45 AM 8/30/00, you wrote: > >Ok, I looked it up and think I know what "passthru" is. > > > >Getting IPsec through NAT is a VERY hard problem. There > isn't an easy way > >of associating (on the wire) that a packet with an SPI of > this value needs > >to be demultiplexed to this destination because a packet > with another SPI > >went through the NAT gateway... > > > >Passthru is one way of solving this, basically saying all > IPsec traffic > >flows through the NAT to this 1 destination. > > > >Passthru is a hack until something like RSIP becomes a reality. > > > >Bill > > > >______________________________________________ > >Bill Strahm Programming today is a race between > >bill.strahm@ software engineers striving to build > >intel.com bigger and better idiot-proof programs, > >(503) 264-4632 and the Universe trying to produce > > bigger and better idiots. So far, the > > Universe is winning.--Rich Cook > >I am not speaking for Intel. And Intel rarely speaks for me > > > > > > > -----Original Message----- > > > From: John C. Day [mailto:JCDay@JCDay.com] > > > Sent: Tuesday, August 29, 2000 3:56 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Looking for info on ipsec passthrough (or passthru?) > > > > > > > > > Greetings. I'm poking around looking for information on > > > "IPSec passthru", > > > which I saw mentioned on http://www.linksys.com ("Firmware > > > upgrade - IPSec > > > passthru now supported"). > > > > > > I searched the archive files of > > > ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through > ipsec.0008 but I > > > couldn't locate the string "passthr" anywhere in those. I > > > also checked > > > rfc2401 without success, but I'm guessing it's a feature/spec > > > that's been > > > introduced recently. > > > > > > Using google I did find a couple of mentions of it in news > > > groups, but I > > > wasn't able to locate an rfc or other doc which describes > > > what it's for and > > > how it's to be implemented. > > > > > > Any pointers? Thanks. > > > > > > John > > > > > > -- > > > > > > John C. Day > > > Gilroy, CA > > > http://www.JCDay.com > > > > > > > > > -- > > John C. Day > Gilroy, CA > http://www.JCDay.com > The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. ------_=_NextPart_000_01C013E7.6D4CC618 Content-Type: application/octet-stream; name="VPN 3000 Concentrator Series User Guide.url" Content-Disposition: attachment; filename="VPN 3000 Concentrator Series User Guide.url" [InternetShortcut] URL=http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpncon/vcoug/vcoug25.pdf Modified=B01DB6F6E613C00133 ------_=_NextPart_000_01C013E7.6D4CC618-- From owner-ipsec@lists.tislabs.com Mon Sep 4 08:09:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05273; Mon, 4 Sep 2000 08:09:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03207 Mon, 4 Sep 2000 09:12:54 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A967D@eseis06nok> To: ipsec@lists.tislabs.com Subject: Protocol specific and port specific SAs Date: Mon, 4 Sep 2000 16:23:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How does exacly this IPSEC features work? I've been testing some IPSEC/IKE software and I'm not sure if the results are correct. For example if I have this environment: ------ How do I specifiy a SHARED SA for protocols TCP & ICMP only for example? (I'm not sure if I'm doing it the wrong way or it's just a small bug in the other code.) The configuration I use is this: My end host (E), Gateway (GW), Host behind GW (H) H ------ GW ======= E SA (shared for tcp & icmp) 2 policies specifying: Selector 1: H <-> E icmp Selector 2: H <-> E tcp (through the tunnel GW) (Both using same IPSEC and IKE SAs!) If GW acts as a INITIATOR, it sends the protocol number (i.e tcp(6)) with the Phase II IDs when it shouldn't (Or yes?). That makes E think it's trying to negotiate a TCP specific SA and updates the SA database as so. After that the packets are discarded because they don't match the SA spec configured in E that says that the SA is shared (not protocol-specific as I use it). If GW acts as a RESPONDER, E sends phase II IDs WITHOUT setting the protocol ID, but then GW complains that this doesn't match the policy where tcp is set. ----- So the thing here is: Should IKE send the protocol number specified in the selector when the SA is shared? I thing no because then the othar side doesn't know if we want to negotiate a protocol-specific SA (1 new SA for each new protocol) or a shared SA (1 SA for all the protocols, TCP and ICMP here) If the protocol is always sent how do we know if we are negotiating an SA that will be shared among different protocols. Thanks a lot. Toni From owner-ipsec@lists.tislabs.com Mon Sep 4 10:05:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11787; Mon, 4 Sep 2000 10:05:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03809 Mon, 4 Sep 2000 11:53:08 -0400 (EDT) Message-ID: <39B3C75B.83A94CA4@helios.iihe.ac.be> Date: Mon, 04 Sep 2000 18:01:31 +0200 From: Alain Jourez X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: antonio.barrera@nokia.com, ipsec@lists.tislabs.com Subject: Re: Protocol specific and port specific SAs References: <0B3F42CA1FB6D2118FE50008C7894B0A051A967D@eseis06nok> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id LAA03806 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, someone corrects me If I'm wrong (there are may be some new exchanges defined in a draft of which I'm unaware) but you cannot have a shared SA that is based only on two protocols. From RFC 2407 (IPsec DOI) § 4.6.2 : RFC2407>> Protocol ID (1 octet) Value specifying an associated IP protocol ID (e.g. UDP/TCP). RFC2407>> A value of zero means that the protocol ID field should be ignored. I interpret that this way : If I want to specify that all protocols should be protected by this SA I put a zero into this field. A value here should mean that only the protocol specified will be protected by this SA. As a side effect I don't see a way to specify that an SA should protect two or more specific protocols (except for the case of protecting all protocols or maybe manual keying). It could be possible to specify something like that using numerous ID payloads but as far as I know, there may only be one such pair by Quick Mode negotiation. I hope this helps. Regards, Alain. antonio.barrera@nokia.com wrote: > How does exacly this IPSEC features work? > I've been testing some IPSEC/IKE software and I'm not sure if the results > are correct. > For example if I have this environment: > ------ > How do I specifiy a SHARED SA for protocols TCP & ICMP only for > example? > (I'm not sure if I'm doing it the wrong way or it's just a small bug in the > other code.) > The configuration I use is this: > > My end host (E), Gateway (GW), Host behind GW (H) > > H ------ GW ======= E SA (shared for tcp & icmp) > > > 2 policies specifying: > > Selector 1: H <-> E icmp > Selector 2: H <-> E tcp > > (through the tunnel GW) > (Both using same IPSEC and IKE SAs!) > > If GW acts as a INITIATOR, it sends the protocol number (i.e tcp(6)) > with the Phase II IDs when it shouldn't (Or yes?). That makes E think it's > trying to negotiate a TCP specific SA and updates the SA database as so. > After that the packets are discarded because they don't match the SA spec > configured in E that says that the SA is shared (not protocol-specific as I > use it). > If GW acts as a RESPONDER, E sends phase II IDs WITHOUT setting the > protocol ID, but then GW complains that this doesn't match the > policy where tcp is set. > ----- > So the thing here is: Should IKE send the protocol number specified > in the selector when the SA is shared? I thing no because then the othar > side doesn't know if we want to negotiate a protocol-specific SA (1 new SA > for each new protocol) or a shared SA (1 SA for all the protocols, TCP and > ICMP here) > If the protocol is always sent how do we know if we are negotiating > an SA that will be shared among different protocols. > > Thanks a lot. > > Toni -- Alain Jourez Service Télématique et Communication Université Libre de Bruxelles Tél. +32 (0) 2 650 57 04 Boulevard du Triomphe, CP 230 Fax +32 (0) 2 629 38 16 B-1050 Bruxelles - Belgium mailto:alain.jourez@helios.iihe.ac.be From owner-ipsec@lists.tislabs.com Mon Sep 4 10:14:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11921; Mon, 4 Sep 2000 10:14:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03839 Mon, 4 Sep 2000 12:06:39 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9680@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Protocol specific and port specific SAs Date: Mon, 4 Sep 2000 19:17:15 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA03836 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But what if I only want my IPSEC to be applied to TCP & ICMP (only 2 selectors defined)? Then shouldn't IKE also fill the Protocol ID field with a 0? In this way the when Pfkey is updated no protocol is specified and any packet matching the selectors would use this negotiated SA, that is TCP and ICMP as I intended. As my SA spec has defined a shared SA when a new packet matches the selector it won't compare the protocol field with the SA and so only TCP and ICMP would be protected by this SA because theses 2 are the only one to match the selector. Toni -----Original Message----- From: EXT Alain Jourez [mailto:Alain.Jourez@helios.iihe.ac.be] Sent: 04. September 2000 19:02 To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com Subject: Re: Protocol specific and port specific SAs Well, someone corrects me If I'm wrong (there are may be some new exchanges defined in a draft of which I'm unaware) but you cannot have a shared SA that is based only on two protocols. From RFC 2407 (IPsec DOI) § 4.6.2 : RFC2407>> Protocol ID (1 octet) Value specifying an associated IP protocol ID (e.g. UDP/TCP). RFC2407>> A value of zero means that the protocol ID field should be ignored. I interpret that this way : If I want to specify that all protocols should be protected by this SA I put a zero into this field. A value here should mean that only the protocol specified will be protected by this SA. As a side effect I don't see a way to specify that an SA should protect two or more specific protocols (except for the case of protecting all protocols or maybe manual keying). It could be possible to specify something like that using numerous ID payloads but as far as I know, there may only be one such pair by Quick Mode negotiation. I hope this helps. Regards, Alain. antonio.barrera@nokia.com wrote: > How does exacly this IPSEC features work? > I've been testing some IPSEC/IKE software and I'm not sure if the results > are correct. > For example if I have this environment: > ------ > How do I specifiy a SHARED SA for protocols TCP & ICMP only for > example? > (I'm not sure if I'm doing it the wrong way or it's just a small bug in the > other code.) > The configuration I use is this: > > My end host (E), Gateway (GW), Host behind GW (H) > > H ------ GW ======= E SA (shared for tcp & icmp) > > > 2 policies specifying: > > Selector 1: H <-> E icmp > Selector 2: H <-> E tcp > > (through the tunnel GW) > (Both using same IPSEC and IKE SAs!) > > If GW acts as a INITIATOR, it sends the protocol number (i.e tcp(6)) > with the Phase II IDs when it shouldn't (Or yes?). That makes E think it's > trying to negotiate a TCP specific SA and updates the SA database as so. > After that the packets are discarded because they don't match the SA spec > configured in E that says that the SA is shared (not protocol-specific as I > use it). > If GW acts as a RESPONDER, E sends phase II IDs WITHOUT setting the > protocol ID, but then GW complains that this doesn't match the > policy where tcp is set. > ----- > So the thing here is: Should IKE send the protocol number specified > in the selector when the SA is shared? I thing no because then the othar > side doesn't know if we want to negotiate a protocol-specific SA (1 new SA > for each new protocol) or a shared SA (1 SA for all the protocols, TCP and > ICMP here) > If the protocol is always sent how do we know if we are negotiating > an SA that will be shared among different protocols. > > Thanks a lot. > > Toni -- Alain Jourez Service Télématique et Communication Université Libre de Bruxelles Tél. +32 (0) 2 650 57 04 Boulevard du Triomphe, CP 230 Fax +32 (0) 2 629 38 16 B-1050 Bruxelles - Belgium mailto:alain.jourez@helios.iihe.ac.be From owner-ipsec@lists.tislabs.com Mon Sep 4 21:17:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06130; Mon, 4 Sep 2000 21:17:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05285 Mon, 4 Sep 2000 22:39:11 -0400 (EDT) Message-Id: <200009050249.WAA21535@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Protocol specific and port specific SAs In-Reply-To: Your message of "Mon, 04 Sep 2000 19:17:15 +0300." <0B3F42CA1FB6D2118FE50008C7894B0A051A9680@eseis06nok> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Sep 2000 22:49:46 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "antonio" == antonio barrera writes: antonio> But what if I only want my IPSEC to be applied to TCP & ICMP (only 2 antonio> selectors defined)? As soon as the WG decides how to handle ICMP, we can resolve this question. There are two possibilities: 1) ICMP error codes are considered to be a meta-protocol (which is architecturally correct), and thus they "fit" into TCP-only protocols because ICMP error codes contain an IP/TCP header that (once Src<->Dst swapped) fits into that SA. 2) We modify IKE in some way to permit multiple sets of selectors to be negotiated for a single SA. I.e. union, enumerations, etc. of selectors in a proposal. Of course, we could decide to do #1, and have a special proposal type that indicates that one should do this, so that we can be backwards compatible. You could even do this in your product using Vendor IDs and private proposal numbers. See http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec/icmp/top.html http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-options-01.txt http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-handle-v4-01.txt Also: http://www.sandelman.ottawa.on.ca/cgi-bin/webglimpse/n/ietf/ipsec?localcopy=n&query=icmp&errors=0&age= :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Sep 5 06:02:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09543; Tue, 5 Sep 2000 06:02:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06512 Tue, 5 Sep 2000 07:34:50 -0400 (EDT) Message-Id: <3.0.5.32.20000904172019.033dac40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 04 Sep 2000 17:20:19 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Protocol specific and port specific SAs In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A967D@eseis06nok> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA03631 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:23 4.9.2000 +0300, Antonia wrote: > So the thing here is: Should IKE send the protocol number specified >in the selector when the SA is shared? No. If you set it to tcp, you can only transmit tcp data through it. Lots of us will filter on protocols, lists of port ranges, tcp directions and whatever. But you can't negotiate or announce that kind of filtering in IKE. Use zeros in this case. Jörn From owner-ipsec@lists.tislabs.com Tue Sep 5 06:02:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09544; Tue, 5 Sep 2000 06:02:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06554 Tue, 5 Sep 2000 07:39:51 -0400 (EDT) Message-ID: <002401c0172e$24340fa0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPsec Global Summit Date: Tue, 5 Sep 2000 13:40:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C0173E.E70D65C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C0173E.E70D65C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IPsec Global Summit, second edition, Paris 24-27 October Please get more details at: http://www.upperside.fr/baipsecy2k.htm ------=_NextPart_000_0021_01C0173E.E70D65C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IPsec Global Summit, second edition, = Paris 24-27=20 October Please get more details at: <3d.htm>http://www.upperside.fr/b= aipsecy2k.<3d.htm>htm ------=_NextPart_000_0021_01C0173E.E70D65C0-- From owner-ipsec@lists.tislabs.com Tue Sep 5 17:10:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15934; Tue, 5 Sep 2000 17:10:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08754 Tue, 5 Sep 2000 18:45:23 -0400 (EDT) From: "sankar ramamoorthi" To: Subject: ipsec interoperability questions Date: Tue, 5 Sep 2000 15:52:41 -0700 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.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, A question on 'INITIAL-CONTACT' notification. Is it okay to send 'INITIAL-CONTACT' as a payload in the Quick Mode exchange. (It seems to be so as per RFC 2407 section 4.6.3 - actually as per-the-rfc it seems to be the preferred method given the potential active substitution attack on notify messages with Main Mode). Would there be any interoperability problems if 'INITIAL-CONTACT' is implemented as a Quick-Mode payload? Thanks for any input, -- sankar ramamoorthi -- From owner-ipsec@lists.tislabs.com Wed Sep 6 01:41:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12095; Wed, 6 Sep 2000 01:41:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10128 Wed, 6 Sep 2000 03:12:23 -0400 (EDT) From: "Markku Savela" To: Subject: ICMP Error replies and IPSEC Date: Wed, 6 Sep 2000 10:22:58 +0300 Message-ID: <000001c017d3$48d1a110$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <200009050249.WAA21535@solidum.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: EXT Michael Richardson [mailto:mcr@solidum.com] > There are two possibilities: > 1) ICMP error codes are considered to be a > meta-protocol (which is > architecturally correct), and thus they "fit" into TCP-only > protocols because ICMP error codes contain an IP/TCP > header that > (once Src<->Dst swapped) fits into that SA. I experimentally changed my IPSEC to handle IPv4 ICMP errors as above. IPv4 has no clear separation between ICMP error types and others, but I used the following: Unreachable = 3; SourceQuench = 4; Redirect = 5; TimeExceeded = 11; ParameterProblem = 12; Did I miss any? And when picking up the information to match the IPSEC selectors, if the protocol is ICMP and the type is one of the above, I use the protocol and ports from the inner IPv4 header (swapped) to find the selector and bundle to apply. (btw. as far as I can see, swapped inner src/dst should in most cases be the same as the src/dst in the outer header anyway). Anyone else trying this? From owner-ipsec@lists.tislabs.com Wed Sep 6 08:46:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12181; Wed, 6 Sep 2000 08:46:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12280 Wed, 6 Sep 2000 09:59:25 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A96A2@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE Delete payloads (clarification) Date: Wed, 6 Sep 2000 17:09:56 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When I said "Or IKE assumes that the destination address is the LOCAL address?" I say it from the sender point of view, from the receiver it would be the REMOTE address, of course. Toni -----Original Message----- From: Barrera Antonio (NRC/Helsinki) Sent: 06. September 2000 17:06 To: ipsec@lists.tislabs.com Subject: IKE Delete payloads If IKE wants to send a Delete payload for an IPSEC SA it can only specify the SPI and protocol but not the destination address. - These are the 3 things that identify a IPSEC SA so how can IKE know which one should be erased? - Or IKE assumes that the destination address is the LOCAL address? (Then the remote end will never try to send using an SA that is no longer in the local machine. There shouldn't be a problem for the other direction it just it would be hanging there until it expires (no more used because no longer in the local side and is only for incoming traffic)) Toni From owner-ipsec@lists.tislabs.com Wed Sep 6 08:54:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12958; Wed, 6 Sep 2000 08:54:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12422 Wed, 6 Sep 2000 10:51:16 -0400 (EDT) Message-Id: <200009060318.XAA09868@flash.research.telcordia.com> To: ipsec@lists.tislabs.com Cc: narain@research.telcordia.com Subject: Connecting IPSec tunnels Date: Tue, 05 Sep 2000 23:18:21 -0400 From: Sanjai Narain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suppose a customer has three sites with gateway routers, respectively A, B, C. He rents two tunnels A-B and B-C so that traffic between A hosts and B hosts and between B hosts and C hosts is protected. Now, the customer decides to protect traffic between A hosts and C hosts. Instead of incurring the expense of renting a separate tunnel A-C, the customer tries to "connect" the two tunnels. This should be possible by modifying access lists. For example, at B, forward traffic from C hosts to A hosts along the A-B tunnel. Unfortunately, an initial experiment has been unsuccessful. We are continuing our investigation but in the meantime, I would greatly appreciate any feedback. Thanks. Sanjai Narain Telcordia Technologies From owner-ipsec@lists.tislabs.com Wed Sep 6 08:59:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13346; Wed, 6 Sep 2000 08:59:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12395 Wed, 6 Sep 2000 10:45:30 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A96A0@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE Delete payloads Date: Wed, 6 Sep 2000 17:06:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If IKE wants to send a Delete payload for an IPSEC SA it can only specify the SPI and protocol but not the destination address. - These are the 3 things that identify a IPSEC SA so how can IKE know which one should be erased? - Or IKE assumes that the destination address is the LOCAL address? (Then the remote end will never try to send using an SA that is no longer in the local machine. There shouldn't be a problem for the other direction it just it would be hanging there until it expires (no more used because no longer in the local side and is only for incoming traffic)) Toni From owner-ipsec@lists.tislabs.com Wed Sep 6 09:16:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14319; Wed, 6 Sep 2000 09:16:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12506 Wed, 6 Sep 2000 11:07:50 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 06 Sep 2000 08:18:24 -0700 Subject: Re: Connecting IPSec tunnels From: Lars Eggert To: Sanjai Narain , Message-ID: In-Reply-To: <200009060318.XAA09868@flash.research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Suppose a customer has three sites with gateway routers, respectively > A, B, C. He rents two tunnels A-B and B-C so that traffic between A > hosts and B hosts and between B hosts and C hosts is protected. Now, > the customer decides to protect traffic between A hosts and C hosts. > Instead of incurring the expense of renting a separate tunnel A-C, the > customer tries to "connect" the two tunnels. This should be possible > by modifying access lists. For example, at B, forward traffic from C > hosts to A hosts along the A-B tunnel. Unfortunately, an initial > experiment has been unsuccessful. We are continuing our investigation > but in the meantime, I would greatly appreciate any feedback. Could you please post your IPsec rules? Hard to tell what the problem is without more detail. Also, IPsec rules alone may not be enough. Enable IP forwarding on B and try using a static route. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Wed Sep 6 09:26:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14829; Wed, 6 Sep 2000 09:26:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12565 Wed, 6 Sep 2000 11:20:51 -0400 (EDT) To: Lars Eggert Cc: Sanjai Narain , Subject: Re: Connecting IPSec tunnels References: From: Derek Atkins Date: 06 Sep 2000 11:31:24 -0400 In-Reply-To: Lars Eggert's message of "Wed, 06 Sep 2000 08:18:24 -0700" Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Another potential problem is if you are using tunnel IP selectors then IPSec may be limiting the packets that traverse the tunnel to only those IP addresses specified in the selector. This is actually a feature, to limit the traffic through a tunnel to only 'authorized' addresses. -derek Lars Eggert writes: > > Suppose a customer has three sites with gateway routers, respectively > > A, B, C. He rents two tunnels A-B and B-C so that traffic between A > > hosts and B hosts and between B hosts and C hosts is protected. Now, > > the customer decides to protect traffic between A hosts and C hosts. > > Instead of incurring the expense of renting a separate tunnel A-C, the > > customer tries to "connect" the two tunnels. This should be possible > > by modifying access lists. For example, at B, forward traffic from C > > hosts to A hosts along the A-B tunnel. Unfortunately, an initial > > experiment has been unsuccessful. We are continuing our investigation > > but in the meantime, I would greatly appreciate any feedback. > > Could you please post your IPsec rules? Hard to tell what the problem is > without more detail. > > Also, IPsec rules alone may not be enough. Enable IP forwarding on B and try > using a static route. > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Sep 6 11:54:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20250; Wed, 6 Sep 2000 11:54:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13034 Wed, 6 Sep 2000 13:33:26 -0400 (EDT) Date: Wed, 6 Sep 2000 13:43:34 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IKE Delete payloads In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A96A0@eseis06nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 6 Sep 2000 antonio.barrera@nokia.com wrote: > If IKE wants to send a Delete payload for an IPSEC SA it can only > specify the SPI and protocol but not the destination address. > - These are the 3 things that identify a IPSEC SA so how can IKE know which > one should be erased? > - Or IKE assumes that the destination address is the LOCAL address? The wording here is not very clear, but the statement that the SPI is "the sending entity's SPI", and the following NOTE indicating that receiver->sender communication will fail if the Delete is ignored, makes it pretty much necessary that the implicit destination address is that of the sender. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Sep 7 11:50:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24246; Thu, 7 Sep 2000 11:50:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17163 Thu, 7 Sep 2000 12:59:35 -0400 (EDT) Message-ID: <496A8683261CD211BF6C0008C733261A9635AC@email.quarrytech.com> From: "Ballou, Ken" To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Wed, 6 Sep 2000 20:16:18 -0400 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 Overall, I think this is a good idea. It's extremely useful to be able to avoid the overhead of a separate ISAKMP SA for each VPN. But, I'm a little surprised to see that you're defining an entirely new DOI, rather than extending the IPsec DOI. Is that because there is no provision for a DOI version number? I'm concerned because I can envision multiple DOIs derived from the IPsec DOI, all differing ever so slightly. For example, this draft adds new ID types. Another DOI might add a new security protocol (other than AH and ESP). Now, what happens when an implementation wants to support both extensions? Is it feasible to extend the IPsec DOI? If ISAKMP is ever revisited, is there a possibility of adding a version field to the security association payload? - Ken From owner-ipsec@lists.tislabs.com Thu Sep 7 15:22:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28300; Thu, 7 Sep 2000 15:22:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18366 Thu, 7 Sep 2000 17:02:05 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F0865658F@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: "'Ballou, Ken'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Thu, 7 Sep 2000 17:07:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ken, Comments below... > -----Original Message----- > From: Ballou, Ken [SMTP:kballou@quarrytech.com] > Sent: Wednesday, September 06, 2000 8:16 PM > To: ipsec@lists.tislabs.com > Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > Overall, I think this is a good idea. It's extremely useful to be able > to avoid the overhead of a separate ISAKMP SA for each VPN. > > But, I'm a little surprised to see that you're defining an entirely new > DOI, rather than extending the IPsec DOI. Is that because there is no > provision for a DOI version number? > There is no DOI version number but there is a DOI number. I believe you are differentiating DOI version numbers from DOI numbers by implying that a higher version automattically supports all extensions defined in lower versions while that's not automatically assumed with DOI numbers. Well, that's why the VPN DOI inherits the existing DOI: to be just like a version 2. Regarding extending the existing IPsec DOI, there are many implementations out there which are using the existing DOI and changing it would cause a major impact and I don't think is feasible. A new DOI is OK because ISAKMP dictates what to do with negotiations that request a DOI which you do not support. > I'm concerned because I can envision multiple DOIs derived from the IPsec > DOI, all differing ever so slightly. For example, this draft adds new ID > types. Another DOI might add a new security protocol (other than AH and > ESP). Now, what happens when an implementation wants to support both > extensions? > Well, the application can negotiate some phase 2 SA's using the VPN DOI and others phase 2 SA's with the NewProtocol DOI. > Is it feasible to extend the IPsec DOI? If ISAKMP is ever revisited, is > there a possibility of adding a version field to the security association > payload? > If ISAKMP is ever revisited... > - Ken > Claudio From owner-ipsec@lists.tislabs.com Thu Sep 7 18:59:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01841; Thu, 7 Sep 2000 18:59:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19024 Thu, 7 Sep 2000 20:31:11 -0400 (EDT) Date: Fri, 8 Sep 2000 03:41:51 +0300 (EET DST) Message-Id: <200009080041.DAA27125@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: Claudio Lordello Cc: "'Ballou, Ken'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt In-Reply-To: <53D69AD06EFAD311842300A0C99B4F0865658F@ticsmtp2.innovation.siemens.ca> References: <53D69AD06EFAD311842300A0C99B4F0865658F@ticsmtp2.innovation.siemens.ca> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Claudio Lordello writes: > > But, I'm a little surprised to see that you're defining an entirely new > > DOI, rather than extending the IPsec DOI. Is that because there is no > > provision for a DOI version number? There is no need to DOI version number. Most of the items in the DOI are allocated from the IANA, and there is no need to allocate new DOI number if you do just additive change to DOI, i.e if you just add some new numbers. If you modify the payload formats (ID, SA etc) then you MUST allocate new DOI number, but version number would not help in that case, because the old implementation would not understand SA etc payloads at all. > There is no DOI version number but there is a DOI number. I believe you are > differentiating DOI version numbers from DOI numbers by implying that a > higher version automattically supports all extensions defined in lower > versions while that's not automatically assumed with DOI numbers. Well, > that's why the VPN DOI inherits the existing DOI: to be just like a version > 2. If you just define some new numbers from the IANA, there is no need to define new DOI number. Just allocate the numbers from the IANA and create the rfc that will update the current IPsec DOI. If implementations will receive your newly allocated numbers, they will send notification back saying that they didn't understand them, and you can fall back to version which does not use them. >From my draft-ietf-ipsec-ike-ext-meth-03.txt (expired): ---------------------------------------------------------------------- ... 14. Identity Type The identity type is used to specify the interpretation of the identity payload contents. The identity type is specified in the DOI document, but the generic structure is defined in the ISAKMP document. This generic structure contains this identity type value. When a new identity type is specified, the minor version number or the phase 1 transform identifier SHOULD NOT be incremented. If an old version receives an unknown identity type, it MUST fail the negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification back. A new version MAY always start with the new identity type and fall back to a previous more standard identity type separately each time, or it MAY cache this information for some time, or it MAY manually configure the identity type to be used. ... 17. Domain of Interpretation Each SA payload (and some others like notify and delete payloads) specifies the domain of interpretation for the exchange. There is no version numbers in the DOI, so if a new version of DOI is incompatible with the previous version, a new DOI number MUST be allocated. In the normal case, there is no need to have a version number in the DOI, and additions to it may be done without updating the DOI number. ... > Regarding extending the existing IPsec DOI, there are many implementations > out there which are using the existing DOI and changing it would cause a > major impact and I don't think is feasible. A new DOI is OK because ISAKMP > dictates what to do with negotiations that request a DOI which you do not > support. We are going to change IPsec DOI anyways, when we want to add for example the AES ciphers etc. If some implementation will break because of that, then they need to fix their implementation. There is a defined notification INVALID-ID-INFORMATION that can be used to notify the other end that I don't support that new ID type (from the draft-ietf-ipsec-notifymsg-03.txt): ---------------------------------------------------------------------- ... 3.18 INVALID-ID-INFORMATION The INVALID-ID-INFORMATION error message may be used to communicate that the identification type of the ID payload is not supported. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, ID payload Payloads: ID When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from subject SA if phase 2, else set to protocol PROTO_ISAKMP o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) o Notify Message Type - set to INVALID-ID-INFORMATION o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; otherwise, contains SPI associated with Protocol ID if applicable, or nothing. o Notification Data - SHOULD contain the offending payload, the error position offset, and the message ID of the offending negotiation. It MAY contain error text describing the problem. ... -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Sep 7 21:09:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03245; Thu, 7 Sep 2000 21:09:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19398 Thu, 7 Sep 2000 22:51:28 -0400 (EDT) Message-ID: <005301c01942$01a5c170$d1d77018@cr592232-a.flfrd1.on.wave.home.com> Reply-To: "Claudio Lordello" From: "Claudio Lordello" To: "Tero Kivinen" , "Claudio Lordello" Cc: "'Ballou, Ken'" , Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Thu, 7 Sep 2000 23:08:04 -0400 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Tero Kivinen writes: > >> There is no DOI version number but there is a DOI number. I believe you are >> differentiating DOI version numbers from DOI numbers by implying that a >> higher version automattically supports all extensions defined in lower >> versions while that's not automatically assumed with DOI numbers. Well, >> that's why the VPN DOI inherits the existing DOI: to be just like a version >> 2. > >If you just define some new numbers from the IANA, there is no need to >define new DOI number. Just allocate the numbers from the IANA and >create the rfc that will update the current IPsec DOI. I am not clear on what you mean by "create a rfc that will update the current IPsec DOI". The DOI is a RFC, therefore untouchable. Are you proposing that my draft cut-and-paste the whole IPsec DOI, add the new VPN ID types and, if it reaches rfc status, obsoletes RFC2407, taking its place instead ? Claudio. From owner-ipsec@lists.tislabs.com Fri Sep 8 01:25:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08292; Fri, 8 Sep 2000 01:25:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA19795 Fri, 8 Sep 2000 02:18:21 -0400 (EDT) Reply-To: From: "Rohit Khosla" To: Subject: IPSec interop workshop Schedule Date: Fri, 8 Sep 2000 12:08:54 +0530 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 CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, would appreciate any info regarding IPSec interop workshop schedule. Thanks, Rohit -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Claudio Lordello Sent: Friday, September 08, 2000 2:38 AM To: 'Ballou, Ken'; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Ken, Comments below... > -----Original Message----- > From: Ballou, Ken [SMTP:kballou@quarrytech.com] > Sent: Wednesday, September 06, 2000 8:16 PM > To: ipsec@lists.tislabs.com > Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > Overall, I think this is a good idea. It's extremely useful to be able > to avoid the overhead of a separate ISAKMP SA for each VPN. > > But, I'm a little surprised to see that you're defining an entirely new > DOI, rather than extending the IPsec DOI. Is that because there is no > provision for a DOI version number? > There is no DOI version number but there is a DOI number. I believe you are differentiating DOI version numbers from DOI numbers by implying that a higher version automattically supports all extensions defined in lower versions while that's not automatically assumed with DOI numbers. Well, that's why the VPN DOI inherits the existing DOI: to be just like a version 2. Regarding extending the existing IPsec DOI, there are many implementations out there which are using the existing DOI and changing it would cause a major impact and I don't think is feasible. A new DOI is OK because ISAKMP dictates what to do with negotiations that request a DOI which you do not support. > I'm concerned because I can envision multiple DOIs derived from the IPsec > DOI, all differing ever so slightly. For example, this draft adds new ID > types. Another DOI might add a new security protocol (other than AH and > ESP). Now, what happens when an implementation wants to support both > extensions? > Well, the application can negotiate some phase 2 SA's using the VPN DOI and others phase 2 SA's with the NewProtocol DOI. > Is it feasible to extend the IPsec DOI? If ISAKMP is ever revisited, is > there a possibility of adding a version field to the security association > payload? > If ISAKMP is ever revisited... > - Ken > Claudio From owner-ipsec@lists.tislabs.com Mon Sep 11 09:58:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18640; Mon, 11 Sep 2000 09:58:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23944 Mon, 11 Sep 2000 11:05:33 -0400 (EDT) Date: Mon, 11 Sep 2000 18:16:10 +0300 (EET DST) Message-Id: <200009111516.SAA11489@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: "Claudio Lordello" Cc: "Claudio Lordello" , "'Ballou, Ken'" , Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt In-Reply-To: <005301c01942$01a5c170$d1d77018@cr592232-a.flfrd1.on.wave.home.com> References: <005301c01942$01a5c170$d1d77018@cr592232-a.flfrd1.on.wave.home.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Claudio Lordello writes: > I am not clear on what you mean by "create a rfc that will update > the current IPsec DOI". The DOI is a RFC, therefore untouchable. Are RFCs is not untouchable, even when the text itself cannot be edited. You can just create new RFC which will get new number, that will update the old RFC. > you proposing that my draft cut-and-paste the whole IPsec DOI, add > the new VPN ID types and, if it reaches rfc status, obsoletes > RFC2407, taking its place instead ? That is one option, and that is usually done when there are too many updates to the RFC (i.e when the update chain gets too long). You can also just create RFC that contains the newly defined values and update the old IPsec DOI. For example RFC 2794 (Mobile IP Network Access Identifier Extension for IPv4) updates the RFC 2290 (Mobile-IPv4 Configuration Option for PPP IPCP), which updates RFC 2002 (IP Mobility Support). Here we have base RFC 2002, that updated by adding configuration option support in RFC 2290, and then the RFC 2794 added one more option to configuration option support. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 12 07:58:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18862; Tue, 12 Sep 2000 07:58:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15362 Tue, 12 Sep 2000 09:18:58 -0400 (EDT) X-Originating-IP: [146.225.202.55] From: "Dinesh Jaiswal" To: ipsec@lists.tislabs.com Subject: Does ESP do Data Origin Authentication ... Date: Tue, 12 Sep 2000 18:47:38 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Sep 2000 13:17:38.0791 (UTC) FILETIME=[D2D37770:01C01CBB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am a newbie to the whole concept of IP-Sec, so please excuse me if I my question is naive. In RFC2401,Sec 3.2, ESP is defined as a protocol that in addition to other things can provide data origin authentication. In RFC2406, in Sec 3.1, I find that ESP can authenticate everything in the packet except the IP header. However, in tunnel mode, since the packet is tunneled, so ESP can authenticate the original IP header but not the new IP header. So, when we say that ESP provides data origin authentication, the statement is applicable only for tunnel mode and not for transport mode. Is my understanding of this concept correct or did I miss something? Thanks, -Dinesh _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-ipsec@lists.tislabs.com Tue Sep 12 08:40:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21444; Tue, 12 Sep 2000 08:40:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15578 Tue, 12 Sep 2000 10:19:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 12 Sep 2000 10:26:32 -0400 To: "Dinesh Jaiswal" From: Stephen Kent Subject: Re: Does ESP do Data Origin Authentication ... Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1243353357==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1243353357==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Dinesh, >Hi, > > I am a newbie to the whole concept of IP-Sec, so please excuse me >if I my question is naive. > > In RFC2401,Sec 3.2, ESP is defined as a protocol that in addition >to other things can provide data origin authentication. In RFC2406, >in Sec 3.1, I find that ESP can authenticate everything in the >packet except the IP header. However, in tunnel mode, since the >packet is tunneled, so ESP can authenticate the original IP header >but not the new IP header. > > So, when we say that ESP provides data origin authentication, the >statement is applicable only for tunnel mode and not for transport >mode. > > Is my understanding of this concept correct or did I miss something? > Data Origin authentication in ESP (and AH) is provided for the IP payload, based on the identity verified during SA establishment, e.g., via IKE. Thus, this service is offered in both tunnel and transport modes. Recall that the receiver checks the selectors from the IP header against the appropriate SAD entries after IPsec processing, which ensures that those values are consistent with the ones established during SA establishment. So, there is some implicit integrity and authenticity checking applied to those fields in transport mode. Steve --============_-1243353357==_ma============ Content-Type: text/enriched; charset="us-ascii" Dinesh, Hi, I am a newbie to the whole concept of IP-Sec, so please excuse me if I my question is naive. In RFC2401,Sec 3.2, ESP is defined as a protocol that in addition to other things can provide data origin authentication. In RFC2406, in Sec 3.1, I find that ESP can authenticate everything in the packet except the IP header. However, in tunnel mode, since the packet is tunneled, so ESP can authenticate the original IP header but not the new IP header. So, when we say that ESP provides data origin authentication, the statement is applicable only for tunnel mode and not for transport mode. Is my understanding of this concept correct or did I miss something? Data Origin authentication in ESP (and AH) is provided for the IP payload, based on the identity verified during SA establishment, e.g., via IKE. Thus, this service is offered in both tunnel and transport modes. Recall that the receiver checks the selectors from the IP header against the appropriate SAD entries after IPsec processing, which ensures that those values are consistent with the ones established during SA establishment. So, there is some implicit integrity and authenticity checking applied to those fields in transport mode. Steve --============_-1243353357==_ma============-- From owner-ipsec@lists.tislabs.com Tue Sep 12 15:00:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02864; Tue, 12 Sep 2000 15:00:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16899 Tue, 12 Sep 2000 16:34:47 -0400 (EDT) Message-ID: <20000912204518.21090.qmail@web1005.mail.yahoo.com> Date: Tue, 12 Sep 2000 13:45:18 -0700 (PDT) From: Steven Rosonina Subject: Re: Does ESP do Data Origin Authentication ... To: Dinesh Jaiswal Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hey Dinesh, Data origin authentication happens as follows. There is a derivitive of the master session key created in Phase 1 of IKE negotiation, I believe this key is the skeyid_a. The skeyid_a is the key used in the HMAC version of the hash algorithm in IPSEC that is combined with the initial message before it is put through that hash algorithm. Since there is an identification of peers that happens before the master sessin key is created, either through shared secret or digital certs etc.. you must have authenticated yourself before that key was generated. Therfore when a sender hash is compared against recipient hash and matches, you have authenticated your peer. I think this is how it works. If I am wrong someone please chime in. Cheers :-) --- Dinesh Jaiswal wrote: > Hi, > > I am a newbie to the whole concept of IP-Sec, so > please excuse me if I my > question is naive. > > In RFC2401,Sec 3.2, ESP is defined as a protocol > that in addition to other > things can provide data origin authentication. In > RFC2406, in Sec 3.1, I > find that ESP can authenticate everything in the > packet except the IP > header. However, in tunnel mode, since the packet > is tunneled, so ESP can > authenticate the original IP header but not the new > IP header. > > So, when we say that ESP provides data origin > authentication, the > statement is applicable only for tunnel mode and not > for transport mode. > > Is my understanding of this concept correct or > did I miss something? > > Thanks, > -Dinesh > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > Share information about yourself, create your own > public profile at > http://profiles.msn.com. > > __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Sep 13 05:20:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA01901; Wed, 13 Sep 2000 05:20:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA19407 Wed, 13 Sep 2000 06:45:08 -0400 (EDT) Message-Id: <200009131055.GAA04038@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hoffman-ipsec-testing-01.txt Date: Wed, 13 Sep 2000 06:55:53 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Steps for IPsec Interoperability Testing Author(s) : P. Hoffman, M. Richardson Filename : draft-hoffman-ipsec-testing-01.txt Pages : 9 Date : 12-Sep-00 Bringing up IPsec gateways, clients and end systems is a hard task. There are the numerous configurations issues that occur when doing this. Techniques for diagnosing regular nodes may not yeild understandable results when one or both nodes have network security features. There is a further difficulty presented by the number of configuration options presented by a typical IPsec gateway implementation, and the lack of consistent diagnostics from gateways. The network administrator, field engineers and product support staff are faced with multiple indistinguishable failure modes: is the client unable to connect because of a network outage, or because the two products have never actually tested in that scenario? Or is the naive user unaware that they are behind a network address translator? A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-ipsec-testing-01.txt 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-hoffman-ipsec-testing-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-hoffman-ipsec-testing-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: <20000912130946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hoffman-ipsec-testing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-hoffman-ipsec-testing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000912130946.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Sep 13 09:26:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13408; Wed, 13 Sep 2000 09:26:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20771 Wed, 13 Sep 2000 10:44:46 -0400 (EDT) From: hsenk@Telenisus.com X-Server-Uuid: ecb72b56-2dc3-11d2-bc91-002094082d29 Message-ID: <03E29E2A5833D411A5AC00508BC98E53259B0F@MAIN> To: ipsec@lists.tislabs.com Subject: XAUTH Date: Wed, 13 Sep 2000 10:00:36 -0500 MIME-Version: 1.0 X-WSS-ID: 15A1494F183017-01-02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First let me apologize for the broadcast. I have tried to access the IPsec mailing list archive, but have had no success. I am trying to find out what happened to XAUTH. I seem to remember that this was to be deferred to the IP Security Remote Access WG, but I am not sure. The only draft that even mentions xauth is the hybrid auth draft (draft-ietf-ipsec-isakmp-hybrid-auth-05.txt. Can anyone shed some light? Thanks, Henry... From owner-ipsec@lists.tislabs.com Wed Sep 13 10:23:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16080; Wed, 13 Sep 2000 10:23:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21188 Wed, 13 Sep 2000 12:18:56 -0400 (EDT) Date: Wed, 13 Sep 2000 12:29:16 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: TOS copying considered harmful Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2401's discussion of how to prepare the outer headers in tunnel mode (5.1.2.1) is quite explicit that the TOS field is copied from the inner header to the outer header. In the grand tradition of IPsec RFCs, there is no rationale -- no explanation or discussion of tradeoffs. I suggest that this copying is a mistake -- that the TOS of the outer header should be forced to a specific value, probably 0 -- unless, perhaps, all traffic carried by the tunnel has the same TOS. (How that would be known is less clear, although conceivably one could copy TOS for the first packet and just use that value for all subsequent packets.) At the very least, the spec should allow implementations to do this if they wish. Why? Two reasons. First, copying TOS is a security leak: it permits an eavesdropper to categorize packets, which may aid traffic analysis or cryptanalysis. One major reason for routing different types of traffic through the same tunnel is specifically to *interfere* with such analysis, but the gain from doing so is compromised by this information leak. Second, as noted in recent work by the diffserv WG, packets with different TOS values may be re-ordered en route, and "slow" packets on a busy path can end up outside the AH/ESP anti-replay window. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Sep 13 11:08:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17817; Wed, 13 Sep 2000 11:08:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21323 Wed, 13 Sep 2000 12:54:45 -0400 (EDT) X-Originating-IP: [209.191.137.2] From: "mufti ahmed" To: ipsec@lists.tislabs.com Subject: 128Bit Encryption Date: Wed, 13 Sep 2000 13:05:06 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Sep 2000 17:05:07.0052 (UTC) FILETIME=[C43C92C0:01C01DA4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know if 128Bit Encryption is allowed outside teh US yet? Are there any issues that ISPs hace to face whether it is or not? And does anyone know where i can get info on this if it is allowed? - (Rules & Regulations if any)? Thanks In Addvance Mufti Nayeem Ahmed Network Systems Engineer Market Data Networks Reuters America Inc (212-603-3595 _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-ipsec@lists.tislabs.com Wed Sep 13 12:19:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20116; Wed, 13 Sep 2000 12:19:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21674 Wed, 13 Sep 2000 14:06:21 -0400 (EDT) Message-ID: <009a01c01dae$f7322eb0$fad62ca1@cisco.com> From: "Stephane Beaulieu" To: , References: <03E29E2A5833D411A5AC00508BC98E53259B0F@MAIN> Subject: Re: XAUTH Date: Wed, 13 Sep 2000 14:18:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It expired, and is currently in limbo.... I'll send you a copy in a private email. Stephane. ----- Original Message ----- From: To: Sent: Wednesday, September 13, 2000 11:00 AM Subject: XAUTH > First let me apologize for the broadcast. I have tried to access the IPsec > mailing list archive, but have had no success. > > I am trying to find out what happened to XAUTH. I seem to remember that this > was to be deferred to the IP Security Remote Access WG, but I am not sure. > The only draft that even mentions xauth is the hybrid auth draft > (draft-ietf-ipsec-isakmp-hybrid-auth-05.txt. Can anyone shed some light? > > Thanks, > > Henry... > > From owner-ipsec@lists.tislabs.com Wed Sep 13 12:31:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20328; Wed, 13 Sep 2000 12:31:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21759 Wed, 13 Sep 2000 14:25:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 13 Sep 2000 11:35:33 -0700 To: "mufti ahmed" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: 128Bit Encryption Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:05 PM -0400 9/13/00, mufti ahmed wrote: >Does anyone know if 128Bit Encryption is allowed outside teh US yet? It has *always* been allowed in most countries. The question was whether or not US companies were allowed to export it outside the US. This is not an appropriate forum for amateur lawyers to give you advice on whether or not it is allowed today, and under what circumstances. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Sep 13 14:27:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23053; Wed, 13 Sep 2000 14:27:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22149 Wed, 13 Sep 2000 15:59:41 -0400 (EDT) Date: Wed, 13 Sep 2000 16:10:27 -0400 From: "Michael H. Warfield" To: mufti ahmed Cc: ipsec@lists.tislabs.com Subject: Re: 128Bit Encryption Message-ID: <20000913161027.A2004@alcove.wittsend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: ; from ipsecnayeem@hotmail.com on Wed, Sep 13, 2000 at 01:05:06PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 13, 2000 at 01:05:06PM -0400, mufti ahmed wrote: > Does anyone know if 128Bit Encryption is allowed outside teh US yet? Depends on the country (and not whether that country is the US). 128bit encryption is allowed in A LOT of countries and has been for a LONG time. Some countries prohibit their citizens from posession crypto (more on that below) but they are few, with one or two highly notable examples. Now... If perchance, you missworded your question and you were really asking if it was allowed to export 128bit encryption software from the US to other countries, then you have a different question. Then the answer is a very strong "maybe". Open source encryption software is pretty much fair game, as long as BXA has been notified first. If it is downloaded off of web sites or ftp sites, you don't even have to screen for T-7 (Terrorist 7) countries. If you are shipping software overseas, you have to be a little more diligent, but not much. If it's closed source software, the rules are a lot more complicated and some key length issues still exist. But I personally would not trust closed source crypto, anyways, no matter what the key length was. > Are there any issues that ISPs hace to face whether it is or not? And > does anyone know where i can get info on this if it is allowed? - (Rules > & Regulations if any)? If you are in the US and you are not shipping software, then no, you really don't have to worry. If you are in the US and shipping open source crypto software, then you only have a little bit to worry about. If you are in the US and shipping closed source crypto, you have a lot more to worry about (and the regs are just a part of the story). People in other countries still have to worry about their own country's regulations. France has opened things up a lot but use to prohibit private use of crypto. Great Britian seems to be trying to go in the opposite direction with several bills to force people to reveal keys while prohibiting them from revealing that their keys have been compromised. Technically, Russia and China both prohibit strong cryptography, but I just came back from two weeks in China as a member of the professional delegation representing the Internet Society (ISOC) at the invite of the Chinese Association for Science and Technology (CAST). What I saw there amazed me. Government leaders are promoting the idea that security, and privacy, and strong cryptography are necessary and good for the Internet and for E-Commerce (both of which they want very much). At a meeting at the Xi'an Institute of Post and Telecommunications, I met a professor there who introduced himself to us as a cryptographer. I thought that in China, that would be like introducing yourself as a pedophile. The times they are a changing! Since then, I have heard from several of my Russian colleages who tell me the same story about Russia. It is technically, on the books, illegal to use strong crypto in Russia. In fact, the Russians are encouraging the use of strong crypto. > Thanks In Addvance I'm not sure I answered your questions, but I'm not sure they can be truely answered as they were put. Can you be more specific about what you are worried about and what you are trying to do? > Mufti Nayeem Ahmed > Network Systems Engineer > Market Data Networks > Reuters America Inc > (212-603-3595 -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Wed Sep 13 16:34:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24999; Wed, 13 Sep 2000 16:34:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22830 Wed, 13 Sep 2000 18:17:44 -0400 (EDT) Message-ID: <39BFFFA6.F7D37C40@storm.ca> Date: Wed, 13 Sep 2000 18:28:54 -0400 From: Sandy Harris Organization: Global Village Idiots X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mufti ahmed CC: ipsec@lists.tislabs.com Subject: Re: 128Bit Encryption References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mufti ahmed wrote: > > Does anyone know if 128Bit Encryption is allowed outside teh US yet? > Are there any issues that ISPs hace to face whether it is or not? And > does anyone know where i can get info on this if it is allowed? - (Rules > & Regulations if any)? A paper with links to several other info sources: http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/exportlaws.html An international survey of crypto law: http://cwis.kub.nl/~FRW/PEOPLE/koops/lawsurvy.htm From owner-ipsec@lists.tislabs.com Wed Sep 13 21:23:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA00525; Wed, 13 Sep 2000 21:23:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23344 Wed, 13 Sep 2000 23:01:27 -0400 (EDT) From: ji@research.att.com Date: Wed, 13 Sep 2000 23:12:19 -0400 (EDT) Message-Id: <200009140312.XAA15589@bual.research.att.com> To: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: TOS copying considered harmful Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > First, copying TOS is a security leak: it permits an eavesdropper to Not more so than keeping the same packet size (rounded up to a multiple of 8). To the extent that someone wants to rely on the TOS field, they should be able to do so. ANyone running a tunnel paranoid enough to be worried about potential TA based on the TOS field will also know enough to pad packets and blot out the TOS field. I say leave it alone. /ji -- /\ ASCII ribbon | John Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) From owner-ipsec@lists.tislabs.com Wed Sep 13 21:23:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA00524; Wed, 13 Sep 2000 21:23:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23338 Wed, 13 Sep 2000 22:58:12 -0400 (EDT) From: ji@research.att.com Date: Wed, 13 Sep 2000 23:09:00 -0400 (EDT) Message-Id: <200009140309.XAA15384@bual.research.att.com> To: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: TOS copying considered harmful Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Second, as noted in recent work by the diffserv WG, packets with different > TOS values may be re-ordered en route, and "slow" packets on a busy path > can end up outside the AH/ESP anti-replay window. We know there is a severe amount of packet reordering going on (see Sigcomm papers from 2-3 years ago). The AH/ESP anti-replay window size is a matter of implementation, and increasing its size does not affect the correctness of the protocol, merely the speed of the implementation. Does anyone have measurements indicating that such packet reordering is interfering with the current-practice 32-position antireplay window? /ji -- /\ ASCII ribbon | John Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) From owner-ipsec@lists.tislabs.com Wed Sep 13 21:26:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA00581; Wed, 13 Sep 2000 21:26:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23398 Wed, 13 Sep 2000 23:23:50 -0400 (EDT) Message-Id: <4.1.20000913154756.00a6a6c0@diablo.cisco.com> Message-Id: <4.1.20000913154756.00a6a6c0@diablo.cisco.com> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 13 Sep 2000 16:04:00 -0500 To: "mufti ahmed" , ipsec@lists.tislabs.com From: "James M. Polk" Subject: Re: 128Bit Encryption In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_212051==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_212051==_.ALT Content-Type: text/plain; charset="us-ascii" Mufti The answer is Yes, to most countries with 128bit keys. I know of several that US companies cannot deal and the reasons: US State Department won't let us "export" to: Cuba Serb-Bosnia Libya North Korea Algeria (I'm pretty sure) I've heard some know of a couple more countries, but I haven't been able to confirm each yet. Outside Countries won't let us "import" into: France - They will allow up to 128bit Encryption in Products shipped into their country if that company has submitted a waiver, per product (per code revision number) and had that approved; China - This is an excerpt from ( http://dailynews.yahoo.com/h/nm/20000127/tc/usa_encryption_1.html ): “All foreign and Chinese companies or individuals using encryption technology, which protects electronic communication from eavesdropping, must register with the government. The registration is the first step in a move to force foreign companies to reveal their encryption secrets and possibly an outright ban on the sale of foreign encryption products in China.” This list obviously changes often depending on who's happy with who this week vs. last week, so this might be a little bit short on 100% accurate..... At 01:05 PM 9/13/2000 -0400, mufti ahmed wrote: >Does anyone know if 128Bit Encryption is allowed outside teh US yet? >Are there any issues that ISPs hace to face whether it is or not? And >does anyone know where i can get info on this if it is allowed? - (Rules >& Regulations if any)? > >Thanks In Addvance > >Mufti Nayeem Ahmed >Network Systems Engineer >Market Data Networks >Reuters America Inc >(212-603-3595 >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > >Share information about yourself, create your own public profile at >http://profiles.msn.com. > ************************************* "At the end of the day... the most committed win!" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_212051==_.ALT Content-Type: text/html; charset="us-ascii" Mufti

The answer is Yes, to most countries with 128bit keys. I know of several that US companies cannot deal and the reasons:

US State Department won't let us "export" to:
        Cuba
        Serb-Bosnia
        Libya
        North Korea
        Algeria (I'm pretty sure)
        I've heard some know of a couple more countries, but I haven't been able to confirm each yet.

Outside Countries won't let us "import" into:
        France  -       They will allow up to 128bit Encryption in Products shipped into their country if that company has submitted a waiver, per product (per code revision number) and had that approved;
        China -         This is an excerpt from ( http://dailynews.yahoo.com/h/nm/20000127/tc/usa_encryption_1.html ):
“All foreign and Chinese companies or individuals using encryption technology, which protects electronic communication from eavesdropping, must register with the government. The registration is the first step in a move to force foreign companies to reveal their encryption secrets and possibly an outright ban on the sale of foreign encryption products in China.”
This list obviously changes often depending on who's happy with who this week vs. last week, so this might be a little bit short on 100% accurate.....

At 01:05 PM 9/13/2000 -0400, mufti ahmed wrote:
>Does anyone know if 128Bit Encryption is allowed outside teh US yet?
>Are there any issues that ISPs hace to face whether it is or not? And
>does anyone know where i can get info on this if it is allowed? - (Rules
>& Regulations if  any)?
>
>Thanks In Addvance
>
>Mufti Nayeem Ahmed
>Network Systems Engineer
>Market Data Networks
>Reuters America Inc
>(212-603-3595
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>Share information about yourself, create your own public profile at
>http://profiles.msn.com.
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_212051==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Sep 13 22:09:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01105; Wed, 13 Sep 2000 22:09:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23486 Thu, 14 Sep 2000 00:05:09 -0400 (EDT) Date: Thu, 14 Sep 2000 00:15:24 -0400 (EDT) From: Henry Spencer To: ji@research.att.com cc: ipsec@lists.tislabs.com Subject: Re: TOS copying considered harmful In-Reply-To: <200009140312.XAA15589@bual.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 13 Sep 2000 ji@research.att.com wrote: > > First, copying TOS is a security leak... > > Not more so than keeping the same packet size (rounded up to a multiple > of 8)... ANyone running a tunnel paranoid enough to > be worried about potential TA based on the TOS field will also know enough > to pad packets and blot out the TOS field. There is provision in ESP for adding extra padding to disguise packet size, should an implementation wish to do so. There is no equivalent authorization to obscure the TOS -- any such "blotting out" is currently a violation of the IPsec specifications, and it is conceivable that odd implementations could somehow rely on it not being done. I can understand not making it mandatory (although IPsec already has too many optional behaviors), but it should at least be permitted. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Sep 14 00:45:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05040; Thu, 14 Sep 2000 00:45:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23812 Thu, 14 Sep 2000 02:45:00 -0400 (EDT) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A0704100F8D@corpmx9.isus.emc.com> To: henry@spsystems.net, ipsec@lists.tislabs.com Subject: RE: TOS copying considered harmful Date: Thu, 14 Sep 2000 02:55:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See draft-ietf-diffserv-tunnels-02.txt (IESG-approved to be issued as an informational RFC) for more discussion of this and related issues. Forcing the DS codepoint to a known value such as 0 is one way to deal with this sort of situation, but not the only one, and could be very wrong in some situations. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Henry Spencer [SMTP:henry@spsystems.net] > Sent: Wednesday, September 13, 2000 12:29 PM > To: IP Security List > Subject: TOS copying considered harmful > > RFC 2401's discussion of how to prepare the outer headers in tunnel mode > (5.1.2.1) is quite explicit that the TOS field is copied from the inner > header to the outer header. In the grand tradition of IPsec RFCs, there > is no rationale -- no explanation or discussion of tradeoffs. > > I suggest that this copying is a mistake -- that the TOS of the outer > header should be forced to a specific value, probably 0 -- unless, > perhaps, all traffic carried by the tunnel has the same TOS. (How that > would be known is less clear, although conceivably one could copy TOS > for the first packet and just use that value for all subsequent packets.) > At the very least, the spec should allow implementations to do this if > they wish. > > Why? Two reasons. > > First, copying TOS is a security leak: it permits an eavesdropper to > categorize packets, which may aid traffic analysis or cryptanalysis. One > major reason for routing different types of traffic through the same > tunnel is specifically to *interfere* with such analysis, but the gain > from doing so is compromised by this information leak. > > Second, as noted in recent work by the diffserv WG, packets with different > TOS values may be re-ordered en route, and "slow" packets on a busy path > can end up outside the AH/ESP anti-replay window. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Thu Sep 14 05:28:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15077; Thu, 14 Sep 2000 05:28:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA24649 Thu, 14 Sep 2000 06:56:37 -0400 (EDT) To: ji@research.att.com cc: henry@spsystems.net, ipsec@lists.tislabs.com In-reply-to: ji's message of Wed, 13 Sep 2000 23:12:19 -0400. <200009140312.XAA15589@bual.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: TOS copying considered harmful From: itojun@iijlab.net Date: Thu, 14 Sep 2000 20:05:53 +0900 Message-ID: <18138.968929553@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> First, copying TOS is a security leak: it permits an eavesdropper to >Not more so than keeping the same packet size (rounded up to a multiple >of 8). To the extent that someone wants to rely on the TOS field, they >should be able to do so. ANyone running a tunnel paranoid enough to >be worried about potential TA based on the TOS field will also know enough >to pad packets and blot out the TOS field. > >I say leave it alone. i think it makes more sense for tunnel ingress node to construct the TOS field value. also, we should look at draft-ietf-ipsec-ecn-02.txt (what is the status of this one? it looks expired) are there any implementation which checks, on IPsec tunneled packet egress processing, if inner TOS value == outer TOS value? I bet there's none, and it is impossible as outer TOS may be overwritten by diffserv/ECN-capable intermediate devices. so even if (1) we change the spec or (2) no spec change, but some implementation did non-conformant outer TOS initialization on ingress, noone will notice. itojun From owner-ipsec@lists.tislabs.com Thu Sep 14 11:37:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28018; Thu, 14 Sep 2000 11:37:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26139 Thu, 14 Sep 2000 12:59:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 14 Sep 2000 13:03:01 -0400 To: Henry Spencer From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, In the revision of 2401 we plan to modify the text somewhat. This issue was discussed before and we took notes on the changes to be made, but have not distributed them to the list. We would like an IPsec implementation to be configurable re how it processes the TOS field for tunnel mode for transmitted and received packets. One configuration setting would operate as the current spec requires. Another would allow the field to be mapped to a fixed value, on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows folks, on a local basis, to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. For inbound traffic, the QoS folks have requested that we allow copying of the bits, which are currently discarded. One configuration option here would permit this, the other would maintain the status quo, i.e., discard. Would this set of options, plus the accompanying rationale, address your concerns? Steve From owner-ipsec@lists.tislabs.com Thu Sep 14 13:25:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02208; Thu, 14 Sep 2000 13:25:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26736 Thu, 14 Sep 2000 15:25:12 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14785.10341.109211.298676@thomasm-u1.cisco.com> Date: Thu, 14 Sep 2000 12:35:01 -0700 (PDT) To: Stephen Kent Cc: Henry Spencer , IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What I don't understand is how this differs from plain old DSCP remapping that can happen for any u-flow or aggregated flow on any incoming/outgoing interface. If you look at a tunnel as a virtual interface, I don't think that IPsec needs to recommend much of anything other than noting the traffic analysis as a potential consideration when deciding how to remark traffic. Mike Stephen Kent writes: > Henry, > > In the revision of 2401 we plan to modify the text somewhat. This > issue was discussed before and we took notes on the changes to be > made, but have not distributed them to the list. > > We would like an IPsec implementation to be configurable re how it > processes the TOS field for tunnel mode for transmitted and received > packets. One configuration setting would operate as the current spec > requires. Another would allow the field to be mapped to a fixed > value, on a per SA basis. (The value might really be fixed for all > traffic outbound from a device, but per SA granularity allows that as > well.) This configuration option allows folks, on a local basis, to > decide whether the covert channel provided by copying these bits > outweighs the benefits of copying. > > For inbound traffic, the QoS folks have requested that we allow > copying of the bits, which are currently discarded. One configuration > option here would permit this, the other would maintain the status > quo, i.e., discard. > > Would this set of options, plus the accompanying rationale, address > your concerns? > > Steve > > From owner-ipsec@lists.tislabs.com Thu Sep 14 13:43:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02787; Thu, 14 Sep 2000 13:43:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26774 Thu, 14 Sep 2000 15:38:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14785.10341.109211.298676@thomasm-u1.cisco.com> References: <14785.10341.109211.298676@thomasm-u1.cisco.com> Date: Thu, 14 Sep 2000 15:47:02 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, >What I don't understand is how this differs from >plain old DSCP remapping that can happen for any >u-flow or aggregated flow on any incoming/outgoing >interface. > >If you look at a tunnel as a virtual interface, >I don't think that IPsec needs to recommend much >of anything other than noting the traffic analysis >as a potential consideration when deciding how to >remark traffic. IPsec is a security protocol, thus it is appropriate for it to include explicit controls when security-relevant mapping takes place relevant to a tunnel. By the way, it's not traffic analysis per se that is the major concern. The concern is that a Trojan Horse "behind" the IPsec implementation uses the TOS field to exfiltrate data. Steve From owner-ipsec@lists.tislabs.com Thu Sep 14 14:46:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05101; Thu, 14 Sep 2000 14:46:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26909 Thu, 14 Sep 2000 16:46:08 -0400 (EDT) Date: Thu, 14 Sep 2000 16:56:18 -0400 (EDT) From: Henry Spencer To: Stephen Kent cc: IP Security List Subject: Re: TOS copying 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 On Thu, 14 Sep 2000, Stephen Kent wrote: > ...One configuration setting would operate as the current spec > requires. Another would allow the field to be mapped to a fixed > value, on a per SA basis... > For inbound traffic, the QoS folks have requested that we allow > copying of the bits... One configuration option here would permit > this, the other would maintain the status quo, i.e., discard. > Would this set of options, plus the accompanying rationale, address > your concerns? Yes, that would deal with the issue quite satisfactorily. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Sep 14 18:29:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11181; Thu, 14 Sep 2000 18:29:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27491 Thu, 14 Sep 2000 20:06:12 -0400 (EDT) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A0704C35555@corpmx9.isus.emc.com> To: itojun@iijlab.net, ji@research.att.com Cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: RE: TOS copying considered harmful Date: Thu, 14 Sep 2000 20:16:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > i think it makes more sense for tunnel ingress node to construct > the TOS field value. also, we should look at > draft-ietf-ipsec-ecn-02.txt (what is the status of this one? > it looks expired) Approved by the IESG for publication as an RFC in late August. There's some sort of issue about whether it's going to be Informational or Proposed Standard. My understanding of the discussion in the ipsec WG is that Proposed Standard was intended. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Sep 14 19:51:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13782; Thu, 14 Sep 2000 19:51:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27696 Thu, 14 Sep 2000 21:49:54 -0400 (EDT) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A0704100F95@corpmx9.isus.emc.com> To: kent@bbn.com, mat@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: TOS copying considered harmful Date: Thu, 14 Sep 2000 22:00:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk h> IPsec is a security protocol, thus it is appropriate for it to > include explicit controls when security-relevant mapping takes place > relevant to a tunnel. By the way, it's not traffic analysis per se > that is the major concern. The concern is that a Trojan Horse > "behind" the IPsec implementation uses the TOS field to exfiltrate > data. And if the network beyond the tunnel egress is using that field to determine which packets get what QoS-based services, there are also possible denial of service attacks based on modifying the field in the outer header of tunneled traffic. For the record, I like Steve's proposal for modifications to RFC 2401's rules for tunnel header processing, and there's text in a number of diffserv RFCs that was written in anticipation/hope of such changes (e.g., see p.30 of RFC 2475). I would expect that specification of these changes would be accompanied by guidance on their proper use and warning about security risks that may make them inappropriate to configure/use in some situations, right? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Sep 15 02:45:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01559; Fri, 15 Sep 2000 02:45:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA28453 Fri, 15 Sep 2000 04:19:00 -0400 (EDT) Message-ID: <39C1DE00.9E1BE645@F-Secure.com> Date: Fri, 15 Sep 2000 11:29:52 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: draft-huttunen-ipsec-esp-in-udp-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some time ago I mentioned that we're working on an alternative proposal for doing UDP encapsulation of ESP messages. The first version of the draft is now ready, and I submitted it just a moment ago. I've never done such a thing before, so I'll send it to this list as well. Sorry if this causes inconvenience. I'll be available in the San Diego interop workshop, in case anybody wishes to talk about this draft. The reason this draft talks about CheckPoint is that our implementations should be really similar. After we'll do some testing, we'll know better ;). A later version will of course drop any specific company names from it. Comments are appreciated! Ari Internet Engineering Task Force Ari Huttunen Internet-Draft Joern Sierwald Expires: March 2001 F-Secure Corporation ESP Encapsulation in UDP Packets draft-huttunen-ipsec-esp-in-udp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines a method to encapsulate ESP in UDP, and a method to negotiate this encapsulation using IKE. The primary motivation for such encapsulation is to allow ESP traffic pass through NATs. However, it is also possible to use it without NATs. This document defines methods for determining the need for UDP encapsulation, both in the presence of Basic NAT (i.e. without port translation) and in the presence of NAPT (with port translation). This is done by the receiver, based on the information available in standard IKE packets. ESPUDP in both tunnel mode and transport mode are defined. Tunnel mode ESPUDP through NAT is seen easier to implement, but transport mode ESPUDP can also be made to go through NAT. Definitions Basic NAT With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated. [RFC 2663] Network Address Port Translation (NAPT) NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation. [RFC 2663] ESP encapsulated in UDP (ESPUDP) An encapsulation mechanism defined by this draft. 1. Introduction This document defines a method to encapsulate ESP in UDP, and a method to negotiate this encapsulation using IKE. The primary motivation for such encapsulation is to allow ESP traffic to pass through NATs. However, it is also possible to use it without NATs. The reasons for needing a mechanism to traverse NATs are discussed in [ABOBA]. The main driving principle in creating this document has been simplicity. The defined mechanisms can be implemented and deployed rapidly, and they are believed to solve all important practical problems. This document defines methods for determining the need for UDP encapsulation, both in the presence of Basic NAT (i.e. without port translation) and in the presence of NAPT (with port translation). This is done by the receiver, based on the information available in standard IKE packets. ESPUDP in both tunnel mode and transport mode are defined. Tunnel mode ESPUDP through NAT is seen easier to implement, but transport mode ESPUDP can also be made to go through NAT. The overhead over ordinary ESP modes is 8 bytes for the UDP header. 2. Design Choices This document does not define a method to pass AH packets through NATs. The reason is that such mechanism is seen unnecessary. No negotiation protocol for ESPUDP is defined. This is for simplicity, since practical problems are solvable without such a mechanism. If such a mechanism is wanted, something like in [STENBERG] could be deployed. ESPUDP uses a different port than IKE. This is to enable firewalls to differentiate between these two types of traffic. 3. Header Formats This section contains definitions for IP, UDP and ESP packet formats for easy reference. IP header is defined in [RFC 791]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The checksum in the IP header encompasses only the IP header. UDP header is defined in [RFC 768]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The checksum in the UDP header encompasses parts of the IP header, the UDP header, and the UDP payload. With ESPUDP the UDP cheksum is disabled. There's no need for it here because ESP authentication goes between the same network entities. The ESPUDP source and destination ports have the value 2797 (or 2746, undecided) when sent by the initiator inside a private addressing realm. Reference: cpudpencap 2746/tcp CPUDPENCAP cpudpencap 2746/udp CPUDPENCAP # Tamir Zegman esp-encap 2797/tcp esp-encap esp-encap 2797/udp esp-encap # Jorn Sierwald ESP header is defined in [RFC 2406]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Auth. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |erage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |erage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESPUDP has the following packet structures. Transport mode: --------------------------------------------------------- IPv4 |orig IP hdr | UDP | ESP | | ESP | ESP| |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth| --------------------------------------------------------- |<------- encrypted ---->| |<-------- authenticated ----->| Tunnel mode: ---------------------------------------------------------------------- IPv4 | new IP hdr* | UDP | ESP | orig IP hdr* | | ESP | ESP| |(any options)| HDr | Hdr | (any options) | Payload Data|Trailer|Auth| ---------------------------------------------------------------------- |<--------- encrypted --------------->| |<----------- authenticated --------------->| NAT translation keepalive: --------------------- IPv4 |orig IP hdr | UDP | |(any options)| Hdr | --------------------- 4. IKE Negotiation The peers SHOULD exchange the VID "draft-huttunen-ipsec-esp-in-udp-00.txt" in the first two IKE phase I messages if they support this draft. If this is not done, the initiator SHOULD NOT use the private encapsulation attributes during phase II. ESPUDP is negotiated by using one of the following encapsulation attributes in an ESP proposal: 61440 ESPUDP in tunnel mode 61441 ESPUDP in transport mode <> 61440 ==> UDP encapsulation + ESP in tunnel mode (CheckPoint) 63337 ==> UDP encapsulation + ESP in tunnel mode (F-Secure) 63338 ==> UDP encapsulation + ESP in transport mode (F-Secure) The responder SHOULD choose ESPUDP proposals if the packets are determined to have come through NAT, even if VIDs were not exchanged during phase I. This determination can be done in two ways: a) If the IKE source port in the received packet is not 500. b) If the phase II identity is an IP address from a private address range that is different from the source IP address in the IKE packet, and the policy defines a connection from a host. See [RFC1918]. Method a) allows determining NAT traversal in all situations when NAT is of type NAPT, assuming the initiator used the source port 500. Method b) allows determining NAT traversal in host-to-X situations in the presence of Basic NAT. If the proposal list contains only ESPUDP proposals that are otherwise acceptable, one of them SHOULD be chosen even if NAT has not been determined to exist between the peers. These methods are not foolproof. If it is determined incorrectly that NAT exists, an overhead of 8 bytes is incurred. This can be avoided by the initiator by not providing ESPUDP proposals. On the other hand, if incorrect determination is made that NAT doesn't exist, the connection will fail. This can be avoided by the initiator by providing only ESPUDP encapsulated proposals. An implementation confirming to this draft MUST implement tunnel mode, and MAY implement transport mode. (If and when transport mode operation through NAT is specified more fully, this should be reviewed.) The source IP address or the source port of the initiator, as seen by the responder, MUST NOT change during the connection. When ESPUDP is used to traverse NATs, IP address -based phase I identities MUST NOT be used to identify entities inside private addressing spaces. IP address based identities are used in ESPUDP tunnel mode according to standard IKE rules. In ESPUDP transport mode the responder SHOULD accept a phase II IP address identity that is different from the IP packet source address, iff the phase II identity is a single IP address from a private address space. 5. ESPUDP NAT Translation Keepalive A peer MAY choose to send a UDP packet using the same ports as ESPUDP with no data contained in the UDP packet. The typical reason to do this would be to keep the NAT translation table(s) active when no user data is being transferred. The receiver of such an empty ESPUDP packet MUST silently ignore the packet. Such empty ESPUDP packets SHOULD NOT force the link to stay up, and they SHOULD NOT be counted as user traffic. (They are also not a candidate mechanism for IKE/IPsec heartbeats.) A peer MAY also choose to send an empty UDP packet using the IKE port numbers. This packet is an illegal IKE packet and will be discarded by the recipient. No sane IKE implementation will terminate a connection due to this, since such packets are so easy to forge. The reason for this would be to keep the NAT translation tables for IKE messages active. 6. Address Translation Options Since separate addressing spaces are being used, addresses must be translated by someone. ESPUDP ignores the address translations that occur along its route, and thus either of the endpoints must do this. In ESPUDP tunnel mode, either of the following MUST be done: a) The initiator MUST obtain an IP address from the peer, and use this IP address in all tunneled packets being sent. b) The responder MUST do NAT translation on incoming packets. In ESPUDP transport mode, the initiator MUST correct the cheksums in the packets being received through NAT. Their checksums will be incorrect, since NAT has changed the IP address. Similarly the responder MUST correct the checksums. The responder MUST also do NAT translation, so that two clients using the same source port do not clash. 7. Deployment Considerations 7.1 Client <-> Gateway +----+ \ / +----+ +----+ | |-------------|----------------| |----------| | +----+ / \ +----+ +----+ Alice's NAT GW Suzy's Laptop Server ESPUDP (tunnel mode) ================================ The effect of ESPUDP is to allow the protected packets to pass through the tunnel. However, the contained IP addresses are not affected. Since Alice's laptop may have any IP address in its current residing network, there must be some method of converting that IP address to be usable in Suzy's network. Two methods exist: a) The GW can assign Alice's laptop an intranet address using some mechanism like DHCP or ConfigMode. b) The GW can internally assign Alice's laptop an intranet address and do NAT translation as the packets pass through the GW. Payload protocols carrying IP addresses, like FTP, continue to work because the NAT translation for those is done either at Alice's laptop (method a) or at the GW (method b). 7.2 Client <-> Client +----+ \ / +----+ | |-------------|--------------------| | +----+ / \ +----+ Alice's NAT Suzy's Laptop Server ESPUDP (tunnel/ transport mode) ==================================== Transport mode ESPUDP requires that both Alice's laptop and Suzy's server contain functionality to correct checksums that are invalidated by the source IP address being changed. Suzy's server must also do NAT to allow several clients using the same UDP source port to connect. For this reason, ESPUDP in transport mode is not recommended when NAT traversal is required. The recommended choice is to use tunnel mode ESP over UDP in this situation. Similarly to the Client<->GW case, the contained protocols like FTP continue to work. 7.3 Gateway <-> Gateway +----+ +----+ \ / +----+ +----+ | |------| |-------|----------------| |----------| | +----+ +----+ / \ +----+ +----+ Alice's GW NAT GW Suzy's Laptop Server ESPUDP (tunnel mode) ============================ The GW<->GW case is similar to the Client<->GW case; ESPUDP allows the connection to pass NAT, but a method to convert Alice's laptop's address to be suitable in Suzy's network is necessary. The only viable option is to do NAT at either of the GWs, since no address assignment protocol is defined to work between GWs. Contained protocols like FTP continue to work because NAT can be performed on unencrypted packets. 7.4 Client <-> Gateway with End-to-end encryption +----+ \ / +----+ +----+ | |-------------|----------------| |----------| | +----+ / \ +----+ +----+ Alice's NAT GW Suzy's Laptop Server ESPUDP (tunnel mode) ================================ ESP (transport mode) ================================================ One way to make this work is for the GW to provide Alice's laptop a suitable address, so that the GW need not do any NAT to the contained packets. 7.5 L2TP over ESPUDP This section has not been written/studied yet. What will it require to be able to do FTP through all these protocol layers? Volunteers? 8. Security Considerations On some systems ESPUDP may have DoS attack consequences, especially if ordinary operating system UDP-functionality is being used. It may be recommended not to open an ordinary UDP-port for this. Implementors are warned that it is possible for remote peers to negotiate entries that overlap in the GW. +----+ \ / | |-------------|----\ +----+ / \ \ Alice's NAT 1 \ Laptop \ 10.1.2.3 \ +----+ \ / \ +----+ +----+ | |-------------|----------+------| |----------| | +----+ / \ +----+ +----+ Bob's NAT 2 GW Suzy's Laptop Server 10.1.2.3 Because GW will now see two possible SAs that lead to 10.1.2.3, it can become confused where to send packets coming from Suzy's server. Implementations MUST devise ways of preventing such a thing from occurring; either by disallowing such connections or by other means. It is not possible for a hacker to obtain an arbitrary address in the intranet being protected by the GW. If address assignment by the GW is provided, only the address assigned to the hacker is allowed to pass through the GW. In the other case, address is always assigned to the hacker internally by the GW and the (arbitrary) IP address of the hacker is always translated by a NAT functionality in the GW. Acknowledgements Tamir Zegman of CheckPoint, and William Dixon of Microsoft have provided helpful advice for producing this draft. References [RFC 1918] Address Allocation for Private Internets [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [ABOBA] Aboba, B., "NAT and IPSEC", Internet draft (work in progress), draft-aboba-nat-ipsec-02.txt, July 2000 [STENBERG] Stenberg, M. et. al. IPsec NAT-Traversal, Internet draft (work in progress), draft-stenberg-ipsec-nat-traversal-00.txt, July 2000 -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Sep 15 08:15:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20965; Fri, 15 Sep 2000 08:15:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02198 Fri, 15 Sep 2000 09:30:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704100F95@corpmx9.isus.emc.com> References: <0F31E5C394DAD311B60C00E029101A0704100F95@corpmx9.isus.emc.com> Date: Fri, 15 Sep 2000 09:32:24 -0400 To: Black_David@emc.com From: Stephen Kent Subject: RE: TOS copying considered harmful Cc: mat@cisco.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:00 PM -0400 9/14/00, Black_David@emc.com wrote: >h> IPsec is a security protocol, thus it is appropriate for it to > > include explicit controls when security-relevant mapping takes place > > relevant to a tunnel. By the way, it's not traffic analysis per se > > that is the major concern. The concern is that a Trojan Horse > > "behind" the IPsec implementation uses the TOS field to exfiltrate > > data. > >And if the network beyond the tunnel egress is using that field to >determine which packets get what QoS-based services, there >are also possible denial of service attacks based on modifying >the field in the outer header of tunneled traffic. > >For the record, I like Steve's proposal for modifications to RFC 2401's >rules for tunnel header processing, and there's text in a number of >diffserv RFCs that was written in anticipation/hope of such changes >(e.g., see p.30 of RFC 2475). I would expect that specification of >these changes would be accompanied by guidance on their proper >use and warning about security risks that may make them >inappropriate to configure/use in some situations, right? Right. Steve From owner-ipsec@lists.tislabs.com Fri Sep 15 12:29:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00643; Fri, 15 Sep 2000 12:29:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04037 Fri, 15 Sep 2000 13:50:33 -0400 (EDT) Message-ID: <39C263DA.F3CF11A8@isi.edu> Date: Fri, 15 Sep 2000 11:00:58 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Black_David@emc.com CC: kent@bbn.com, mat@cisco.com, ipsec@lists.tislabs.com Subject: Re: TOS copying considered harmful References: <0F31E5C394DAD311B60C00E029101A0704100F95@corpmx9.isus.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com wrote: > > h> IPsec is a security protocol, thus it is appropriate for it to > > include explicit controls when security-relevant mapping takes place > > relevant to a tunnel. By the way, it's not traffic analysis per se > > that is the major concern. The concern is that a Trojan Horse > > "behind" the IPsec implementation uses the TOS field to exfiltrate > > data. > > And if the network beyond the tunnel egress is using that field to > determine which packets get what QoS-based services, there > are also possible denial of service attacks based on modifying > the field in the outer header of tunneled traffic. > > For the record, I like Steve's proposal for modifications to RFC 2401's > rules for tunnel header processing, and there's text in a number of > diffserv RFCs that was written in anticipation/hope of such changes > (e.g., see p.30 of RFC 2475). I would expect that specification of > these changes would be accompanied by guidance on their proper > use and warning about security risks that may make them > inappropriate to configure/use in some situations, right? RFC2003 specifies that the TOS bit is copied from the inner header. Could we either: - not create a new spec or - synchronize these modifications with existing specs (get an update to 2003 in the works) PS - ditto for the IPSEC rules for DF. 2003 says 'copy or SET', but 'CLEAR' is not an option. It would be generally preferable for the IPSEC specs to NOT summarize other (possibly changing) specs, but refer to them, and highlight changes required only. Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 13:13:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01554; Fri, 15 Sep 2000 13:13:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04298 Fri, 15 Sep 2000 14:58:16 -0400 (EDT) Message-Id: <3.0.32.20000915121151.009e5bb0@cymail.cylink.com> X-Sender: jburke@cymail.cylink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 15 Sep 2000 12:11:52 -0700 To: ipsec@lists.tislabs.com From: jburke@cylink.com (John Burke) Subject: IPSEC and Common Criteria Protection Profile? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re the multinational effort active lately on "Common Criteria" with "Protection Profiles": is anyone in the IPSEC community aware of any work to produce a Common Criteria Protection Profile for IPSEC/ISAKMP/IKE, or some of the material that should go into such a profile? Would such work be appropriate for IPSEC to take up? Thanks, - John Burke Cylink, Santa Clara, CA From owner-ipsec@lists.tislabs.com Fri Sep 15 13:15:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01596; Fri, 15 Sep 2000 13:15:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04303 Fri, 15 Sep 2000 14:58:29 -0400 (EDT) Date: Fri, 15 Sep 2000 15:08:49 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: <39C263DA.F3CF11A8@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 15 Sep 2000, Joe Touch wrote: > RFC2003 specifies that the TOS bit is copied from the inner header. RFC 2003 is a different standard with different priorities. Note that RFC 2401 is quite careful to say that IPsec tunneling is "modeled after" 2003 tunneling, not that it *is* 2003 tunneling. > Could we either: > - not create a new spec We already have a new spec. IPsec tunneling is specified (albeit not as clearly as it should be) in RFC 2401. > or > - synchronize these modifications with existing specs > (get an update to 2003 in the works) Why is an update to 2003 required? 2003 remains perfectly satisfactory for the purposes it was intended for, security not being one of them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Sep 15 13:52:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02064; Fri, 15 Sep 2000 13:52:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04479 Fri, 15 Sep 2000 15:49:12 -0400 (EDT) Message-ID: <39C27F72.382CD499@isi.edu> Date: Fri, 15 Sep 2000 12:58:42 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: TOS copying considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Fri, 15 Sep 2000, Joe Touch wrote: > > RFC2003 specifies that the TOS bit is copied from the inner header. > > RFC 2003 is a different standard with different priorities. Note that > RFC 2401 is quite careful to say that IPsec tunneling is "modeled after" > 2003 tunneling, not that it *is* 2003 tunneling. OK, then I'll restate. Don't invent a new mechanism for which an existing system is already proposed, EXCEPT where necessary. At the least, the differences should be highlighted, and the reasons for the differences described and justified. It isn't clear there is the need for a separate system here. > > - synchronize these modifications with existing specs > > (get an update to 2003 in the works) > > Why is an update to 2003 required? 2003 remains perfectly satisfactory > for the purposes it was intended for, security not being one of them. Tunneling is tunneling. If there is a reason for allowing the DF bit to be cleared, or for using different TOS bits in IPSEC, there may be equivalent reasons for allowing them in 2003. If there are reasons they are prohibited in 2003, then those reasons should be addressed in any new mechanisms. Having two specifications for packets with protocol type 4 inside IP should be avoided if at all possible. Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 14:25:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02613; Fri, 15 Sep 2000 14:25:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04584 Fri, 15 Sep 2000 16:18:47 -0400 (EDT) Date: Fri, 15 Sep 2000 16:27:55 -0400 (EDT) From: Henry Spencer To: Joe Touch cc: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: <39C27F72.382CD499@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 15 Sep 2000, Joe Touch wrote: > > RFC 2401 is quite careful to say that IPsec tunneling is "modeled after" > > 2003 tunneling, not that it *is* 2003 tunneling. > > ...At the least, the differences should be highlighted, > and the reasons for the differences described and justified. > It isn't clear there is the need for a separate system here. I suspect there is... but I agree that the justification needs to be made explicit. > > Why is an update to 2003 required? ... > > Tunneling is tunneling. If there is a reason for allowing the DF > bit to be cleared, or for using different TOS bits in IPSEC, there > may be equivalent reasons for allowing them in 2003. The presence of encryption makes a fundamental difference. 2003, which sends the inner header in cleartext, does not have these concerns. > Having two specifications for packets with protocol type 4 inside IP > should be avoided if at all possible. Now this I agree with. Especially since the IPsec RFCs themselves seem to be very confused about this. 2401 is where IPsec tunneling is defined and discussed... but just *try* to find mention in it of which protocol number should be used. (It is alluded to in a couple of footnotes addressing other matters, but is never explicitly defined.) Over in 2406, defining ESP, it says most explicitly that the Next Header field is interpreted as in "Assigned Numbers"... but Assigned Numbers says that protocol number 4 is assigned to RFC 2003, period. Not to some other protocol "modeled after" 2003. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Sep 15 14:25:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02627; Fri, 15 Sep 2000 14:25:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04621 Fri, 15 Sep 2000 16:27:51 -0400 (EDT) Date: Fri, 15 Sep 2000 16:37:06 -0400 (EDT) From: Henry Spencer To: Joe Touch cc: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: <39C28761.A612B88E@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 15 Sep 2000, Joe Touch wrote: > > The presence of encryption makes a fundamental difference. 2003, which > > sends the inner header in cleartext, does not have these concerns. > > Doesn't IPSEC send the inner header in cleartext (in 'null' mode?) too? Occasionally, but that is not the worst case for design purposes. > It may be sufficient to indicate in 2003bis that DF may be cleared, but > 'here are the consequences', and same for TOS changes. It can then point > to its use in IPSEC, and the redundent text can be excised from 2401bis. I think 2401bis would still have to mention it, if only to discuss the security consequences of the different choices. (Remember, IPsec is a *security* standard, not just an *encryption* standard -- it has to touch all the bases and get all the details right.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Sep 15 14:26:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02641; Fri, 15 Sep 2000 14:26:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04602 Fri, 15 Sep 2000 16:22:44 -0400 (EDT) Message-ID: <39C28761.A612B88E@isi.edu> Date: Fri, 15 Sep 2000 13:32:33 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: TOS copying considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Fri, 15 Sep 2000, Joe Touch wrote: > > > RFC 2401 is quite careful to say that IPsec tunneling is "modeled after" > > > 2003 tunneling, not that it *is* 2003 tunneling. > > > > ...At the least, the differences should be highlighted, > > and the reasons for the differences described and justified. > > It isn't clear there is the need for a separate system here. > > I suspect there is... but I agree that the justification needs to be > made explicit. > > > > Why is an update to 2003 required? ... > > > > Tunneling is tunneling. If there is a reason for allowing the DF > > bit to be cleared, or for using different TOS bits in IPSEC, there > > may be equivalent reasons for allowing them in 2003. > > The presence of encryption makes a fundamental difference. 2003, which > sends the inner header in cleartext, does not have these concerns. Doesn't IPSEC send the inner header in cleartext (in 'null' mode?) too? > > Having two specifications for packets with protocol type 4 inside IP > > should be avoided if at all possible. > > Now this I agree with. Especially since the IPsec RFCs themselves seem to > be very confused about this. > > 2401 is where IPsec tunneling is defined and discussed... but just *try* > to find mention in it of which protocol number should be used. (It is > alluded to in a couple of footnotes addressing other matters, but is never > explicitly defined.) > > Over in 2406, defining ESP, it says most explicitly that the Next Header > field is interpreted as in "Assigned Numbers"... but Assigned Numbers says > that protocol number 4 is assigned to RFC 2003, period. Not to some other > protocol "modeled after" 2003. To be clear, I'm saying only that: - if there are mods to how 2003 works, maybe an update of 2003 is useful - putting mods to 2003 (effectively) inside a different spec is confusing It may be sufficient to indicate in 2003bis that DF may be cleared, but 'here are the consequences', and same for TOS changes. It can then point to its use in IPSEC, and the redundent text can be excised from 2401bis. Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 14:37:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02796; Fri, 15 Sep 2000 14:37:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04678 Fri, 15 Sep 2000 16:37:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39C28761.A612B88E@isi.edu> References: <39C28761.A612B88E@isi.edu> Date: Fri, 15 Sep 2000 16:44:49 -0400 To: Joe Touch From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, I agree with Henry here. We have security issues that influence whether, when, and how we copy data between the red and black IP headers, in tunnel mode. 2003 is not attuned to the issues, nor should it be. In the rewrite of 2401, we will try to do a much better job of describing these mappings, and the rationale behind each. We didn't get all of them right last time and will try to do better this time around. Steve From owner-ipsec@lists.tislabs.com Fri Sep 15 14:39:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02831; Fri, 15 Sep 2000 14:39:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04637 Fri, 15 Sep 2000 16:29:09 -0400 (EDT) Message-ID: <39C288E0.1BAA44AE@isi.edu> Date: Fri, 15 Sep 2000 13:38:56 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: TOS copying considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Fri, 15 Sep 2000, Joe Touch wrote: > > > The presence of encryption makes a fundamental difference. 2003, which > > > sends the inner header in cleartext, does not have these concerns. > > > > Doesn't IPSEC send the inner header in cleartext (in 'null' mode?) too? > > Occasionally, but that is not the worst case for design purposes. > > > It may be sufficient to indicate in 2003bis that DF may be cleared, but > > 'here are the consequences', and same for TOS changes. It can then point > > to its use in IPSEC, and the redundent text can be excised from 2401bis. > > I think 2401bis would still have to mention it, if only to discuss the > security consequences of the different choices. (Remember, IPsec is a > *security* standard, not just an *encryption* standard -- it has to touch > all the bases and get all the details right.) Of course - it can recap the security implications of certain settings. It would be useful to avoid otherwise re-specifying 2003bis, though. Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 15:07:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03243; Fri, 15 Sep 2000 15:07:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04762 Fri, 15 Sep 2000 17:00:01 -0400 (EDT) Message-ID: <39C2903A.2E97E059@isi.edu> Date: Fri, 15 Sep 2000 14:10:18 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: IP Security List Subject: Re: TOS copying considered harmful References: <39C28761.A612B88E@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Joe, > > I agree with Henry here. We have security issues that influence > whether, when, and how we copy data between the red and black IP > headers, in tunnel mode. 2003 is not attuned to the issues, nor > should it be. > > In the rewrite of 2401, we will try to do a much better job of > describing these mappings, and the rationale behind each. We didn't > get all of them right last time and will try to do better this time > around. Would it not be preferable to get those issues in to 2003bis, in one place? (they _are_ security considerations). (I'm not proposing to omit the changes, just to roll them, and their protocol implications, into 2003bis) Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 15:45:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03719; Fri, 15 Sep 2000 15:45:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04850 Fri, 15 Sep 2000 17:36:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39C2903A.2E97E059@isi.edu> References: <39C28761.A612B88E@isi.edu> <39C2903A.2E97E059@isi.edu> Date: Fri, 15 Sep 2000 17:46:20 -0400 To: Joe Touch From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, >Stephen Kent wrote: > > > > Joe, > > > > I agree with Henry here. We have security issues that influence > > whether, when, and how we copy data between the red and black IP > > headers, in tunnel mode. 2003 is not attuned to the issues, nor > > should it be. > > > > In the rewrite of 2401, we will try to do a much better job of > > describing these mappings, and the rationale behind each. We didn't > > get all of them right last time and will try to do better this time > > around. > >Would it not be preferable to get those issues in to 2003bis, in one >place? >(they _are_ security considerations). > >(I'm not proposing to omit the changes, just to roll them, and their >protocol implications, into 2003bis) the security issues surrounding mapping of header fields are relevant only if one is encrypting the tunneled packet, so I don't understand why 2003bis would want to include this info. Could you clarify? thanks, Steve From owner-ipsec@lists.tislabs.com Fri Sep 15 15:47:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03739; Fri, 15 Sep 2000 15:47:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04888 Fri, 15 Sep 2000 17:45:18 -0400 (EDT) Message-ID: <39C29AEE.AC6171D@isi.edu> Date: Fri, 15 Sep 2000 14:55:58 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: IP Security List , touch@ISI.EDU Subject: Re: TOS copying considered harmful References: <39C28761.A612B88E@isi.edu> <39C2903A.2E97E059@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Joe, > > >Stephen Kent wrote: > > > > > > Joe, > > > > > > I agree with Henry here. We have security issues that influence > > > whether, when, and how we copy data between the red and black IP > > > headers, in tunnel mode. 2003 is not attuned to the issues, nor > > > should it be. > > > > > > In the rewrite of 2401, we will try to do a much better job of > > > describing these mappings, and the rationale behind each. We didn't > > > get all of them right last time and will try to do better this time > > > around. > > > >Would it not be preferable to get those issues in to 2003bis, in one > >place? > >(they _are_ security considerations). > > > >(I'm not proposing to omit the changes, just to roll them, and their > >protocol implications, into 2003bis) > > the security issues surrounding mapping of header fields are relevant > only if one is encrypting the tunneled packet, so I don't understand > why 2003bis would want to include this info. Could you clarify? (warning - potential heresey to follow :-) IPSEC may not be the only protocol for encrypting IP packets. 2003bis should refer to the general idea that, if the interior payload is otherwise encrypted, then there are security considerations to copying certain bits, rather than fixing their value. Joe From owner-ipsec@lists.tislabs.com Fri Sep 15 16:07:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04029; Fri, 15 Sep 2000 16:07:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04933 Fri, 15 Sep 2000 17:56:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39C29AEE.AC6171D@isi.edu> References: <39C28761.A612B88E@isi.edu> <39C2903A.2E97E059@isi.edu> <39C29AEE.AC6171D@isi.edu> Date: Fri, 15 Sep 2000 18:01:54 -0400 To: Joe Touch From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List U Content-Type: multipart/alternative; boundary="============_-1243066721==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1243066721==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Joe, Oh yeah, serious heresy! At the IP layer, IPsec is the only IETF standard, so until there is another standard, or even another WG chartered to develop such a standard, I can't see why it makes sense to put this info into 2003bis vs. 2401bis. Steve --============_-1243066721==_ma============ Content-Type: text/enriched; charset="us-ascii" Joe, Oh yeah, serious heresy! At the IP layer, IPsec is the only IETF standard, so until there is another standard, or even another WG chartered to develop such a standard, I can't see why it makes sense to put this info into 2003bis vs. 2401bis. Steve --============_-1243066721==_ma============-- From owner-ipsec@lists.tislabs.com Fri Sep 15 17:02:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05152; Fri, 15 Sep 2000 17:02:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05058 Fri, 15 Sep 2000 18:59:43 -0400 (EDT) From: "Svenning Soerensen" To: "Joe Touch" , "Stephen Kent" Cc: "IP Security List" Subject: RE: TOS copying considered harmful Date: Sat, 16 Sep 2000 01:13:33 +0200 Message-ID: <003e01c01f6a$917aea40$1400a8c0@sss.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <39C29AEE.AC6171D@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Joe Touch > Sent: Friday, September 15, 2000 11:56 PM > To: Stephen Kent > Cc: IP Security List; touch@ISI.EDU > Subject: Re: TOS copying considered harmful [...] > > > the security issues surrounding mapping of header fields are relevant > > only if one is encrypting the tunneled packet, so I don't understand > > why 2003bis would want to include this info. Could you clarify? > > (warning - potential heresey to follow :-) > > IPSEC may not be the only protocol for encrypting IP packets. > > 2003bis should refer to the general idea that, if the interior payload > is otherwise encrypted, then there are security considerations to > copying certain bits, rather than fixing their value. > Joe Hmm, since ESP encapsulation will be applied *after* IPIP encapsulation, I think that it should be the ESP encapsulation's decision what to do with the outer TOS field. Svenning From owner-ipsec@lists.tislabs.com Fri Sep 15 17:02:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05155; Fri, 15 Sep 2000 17:02:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05107 Fri, 15 Sep 2000 19:03:54 -0400 (EDT) From: "Joseph D. Harwood" To: "Ipsec" Subject: FW: TOS copying considered harmful Date: Fri, 15 Sep 2000 16:15:03 -0700 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 V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are the planned modifications available somewhere? An early look at them, even if they're subject to change, would be great. Best Regards, Joseph D. Harwood -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent Sent: Thursday, September 14, 2000 10:03 AM To: Henry Spencer Cc: IP Security List Subject: Re: TOS copying considered harmful Henry, In the revision of 2401 we plan to modify the text somewhat. This issue was discussed before and we took notes on the changes to be made, but have not distributed them to the list. We would like an IPsec implementation to be configurable re how it processes the TOS field for tunnel mode for transmitted and received packets. One configuration setting would operate as the current spec requires. Another would allow the field to be mapped to a fixed value, on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows folks, on a local basis, to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. For inbound traffic, the QoS folks have requested that we allow copying of the bits, which are currently discarded. One configuration option here would permit this, the other would maintain the status quo, i.e., discard. Would this set of options, plus the accompanying rationale, address your concerns? Steve From owner-ipsec@lists.tislabs.com Fri Sep 15 17:02:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05153; Fri, 15 Sep 2000 17:02:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05018 Fri, 15 Sep 2000 18:48:21 -0400 (EDT) Message-ID: <39C2A9B4.71DA0669@isi.edu> Date: Fri, 15 Sep 2000 15:59:00 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: IP Security List U Subject: Re: TOS copying considered harmful References: <39C28761.A612B88E@isi.edu> <39C2903A.2E97E059@isi.edu> <39C29AEE.AC6171D@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Joe, > > Oh yeah, serious heresy! > > At the IP layer, IPsec is the only IETF standard, > so until there is another standard, or even another > WG chartered to develop such a standard, I can't > see why it makes sense to put this info into 2003bis vs. 2401bis. In 2003bis because: a. RFCs should anticipate the future, to some extent i.e., not necessarily that there WILL be an alternate to IPSEC, but that there CAN be b. 2003 is the RFC of note when the IP proto field is itself 4 (as mentioned before) Again, tunneling is tunneling. Let's get it right and documented in one place, and point to it and elaborate on it elsewhere. Joe From owner-ipsec@lists.tislabs.com Sat Sep 16 02:32:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12648; Sat, 16 Sep 2000 02:32:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06561 Sat, 16 Sep 2000 03:59:25 -0400 (EDT) To: Henry Spencer cc: Joe Touch , IP Security List In-reply-to: henry's message of Fri, 15 Sep 2000 16:27:55 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: TOS copying considered harmful From: itojun@iijlab.net Date: Sat, 16 Sep 2000 17:09:26 +0900 Message-ID: <10929.969091766@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Having two specifications for packets with protocol type 4 inside IP >> should be avoided if at all possible. >Now this I agree with. Especially since the IPsec RFCs themselves seem to >be very confused about this. for reference, here's a little list of specs which talks about protocol type 4/41 encapsulation. not sure if it is complete. (from KAME sys/netinet/ip_encap.c) itojun /* * My grandfather said that there's a devil inside tunnelling technology... * * We have surprisingly many protocols that want packets with IP protocol * #4 or #41. Here's a list of protocols that want protocol #41: * RFC1933 configured tunnel * RFC1933 automatic tunnel * RFC2401 IPsec tunnel * RFC2473 IPv6 generic packet tunnelling * RFC2529 6over4 tunnel * mobile-ip6 (uses RFC2473) * 6to4 tunnel * Here's a list of protocol that want protocol #4: * RFC1853 IPv4-in-IPv4 tunnelling * RFC2003 IPv4 encapsulation within IPv4 * RFC2344 reverse tunnelling for mobile-ip4 * RFC2401 IPsec tunnel * Well, what can I say. They impose different en/decapsulation mechanism * from each other, so they need separate protocol handler. The only one * we can easily determine by protocol # is IPsec, which always has * AH/ESP/IPComp header right after outer IP header. * * So, clearly good old protosw does not work for protocol #4 and #41. * The code will let you match protocol via src/dst address pair. */ From owner-ipsec@lists.tislabs.com Sat Sep 16 08:04:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18442; Sat, 16 Sep 2000 08:04:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06882 Sat, 16 Sep 2000 09:42:19 -0400 (EDT) Date: Sat, 16 Sep 2000 09:54:22 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.44) Reply-To: Jim Tiller Organization: Belenos, Inc. X-Priority: 3 (Normal) Message-ID: <3861667092.20000916095422@belenosinc.com> To: Ari Huttunen CC: ipsec Subject: Re: draft-huttunen-ipsec-esp-in-udp-00.txt In-reply-To: <39C1DE00.9E1BE645@F-Secure.com> References: <39C1DE00.9E1BE645@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Ari, A long time ago I attempted to draft something very similar to this, I'm glad to see the subject has received some attention again. I have a comment about the port number selection I would like to get some feedback on. This is a point where Check Point and I disagreed in the compilation of a draft. AH> The ESPUDP source and destination ports have the value 2797 AH> (or 2746, undecided) when sent by the initiator inside a private AH> addressing realm. Why can't this be negotiated? It can be argued that many of the systems that are performing NAT are firewalls, or the like. In these scenarios (where a filtering device is performing NAT) it is very common for the firewall to be limiting the type of traffic permitted. It can also be assumed that a system wanting to create an IPSec VPN through the NAT'ing device has no influence in the modification of the filtering policies. So, the use of a fixed port could foreseeable hinder many of the implementations. I agree that the solution in nature is simplified and should be - but there would be little effort in providing the port as an option in a proposal, or similar. I have other issues that I would like to discuss, but it is this one I would like some comments on. -jim Friday, September 15, 2000, 4:29:52 AM, you wrote: AH> Some time ago I mentioned that we're working on an alternative proposal AH> for doing UDP encapsulation of ESP messages. The first version of AH> the draft is now ready, and I submitted it just a moment ago. I've never AH> done such a thing before, so I'll send it to this list as well. AH> Sorry if this causes inconvenience. AH> I'll be available in the San Diego interop workshop, in case anybody AH> wishes to talk about this draft. AH> The reason this draft talks about CheckPoint is that our implementations AH> should be really similar. After we'll do some testing, we'll know better AH> ;). AH> A later version will of course drop any specific company names from it. AH> Comments are appreciated! AH> Ari AH> Internet Engineering Task Force Ari Huttunen AH> Internet-Draft Joern Sierwald AH> Expires: March 2001 F-Secure Corporation AH> ESP Encapsulation in UDP Packets AH> draft-huttunen-ipsec-esp-in-udp-00.txt AH> Status of this Memo AH> This document is an Internet-Draft and is in full conformance with AH> all provisions of Section 10 of RFC2026. AH> Internet-Drafts are working documents of the Internet Engineering AH> Task Force (IETF), its areas, and its working groups. Note that AH> other groups may also distribute working documents as AH> Internet-Drafts. AH> Internet-Drafts are draft documents valid for a maximum of six AH> months and may be updated, replaced, or obsoleted by other documents AH> at any time. It is inappropriate to use Internet-Drafts as reference AH> material or to cite them other than as "work in progress." AH> The list of current Internet-Drafts can be accessed at AH> http://www.ietf.org/ietf/1id-abstracts.txt. AH> The list of Internet-Draft Shadow Directories can be accessed at AH> http://www.ietf.org/shadow.html. AH> This Internet-Draft will expire on January 12, 2001. AH> Copyright Notice AH> Copyright (C) The Internet Society (2000). All Rights Reserved. AH> Abstract AH> This document defines a method to encapsulate ESP in UDP, and a AH> method AH> to negotiate this encapsulation using IKE. AH> The primary motivation for such encapsulation is to allow ESP traffic AH> pass through NATs. However, it is also possible to use it without AH> NATs. AH> This document defines methods for determining the need for AH> UDP encapsulation, both in the presence of Basic NAT (i.e. without AH> port translation) and in the presence of NAPT (with port AH> translation). AH> This is done by the receiver, based on the information available AH> in standard IKE packets. AH> ESPUDP in both tunnel mode and transport mode are defined. Tunnel AH> mode AH> ESPUDP through NAT is seen easier to implement, but transport mode AH> ESPUDP AH> can also be made to go through NAT. AH> Definitions AH> Basic NAT AH> With Basic NAT, a block of external addresses are set aside for AH> translating addresses of hosts in a private domain as they AH> originate AH> sessions to the external domain. For packets outbound from the AH> private network, the source IP address and related fields such as AH> IP, AH> TCP, UDP and ICMP header checksums are translated. For inbound AH> packets, the destination IP address and the checksums as listed AH> above AH> are translated. [RFC 2663] AH> Network Address Port Translation (NAPT) AH> NAPT extends the notion of translation one step further by also AH> translating transport identifier (e.g., TCP and UDP port numbers, AH> ICMP query identifiers). This allows the transport identifiers of AH> a AH> number of private hosts to be multiplexed into the transport AH> identifiers of a single external address. NAPT allows a set of AH> hosts AH> to share a single external address. Note that NAPT can be combined AH> with Basic NAT so that a pool of external addresses are used in AH> conjunction with port translation. [RFC 2663] AH> ESP encapsulated in UDP (ESPUDP) AH> An encapsulation mechanism defined by this draft. AH> 1. Introduction AH> This document defines a method to encapsulate ESP in UDP, and a AH> method AH> to negotiate this encapsulation using IKE. AH> The primary motivation for such encapsulation is to allow ESP traffic AH> to pass through NATs. However, it is also possible to use it without AH> NATs. AH> The reasons for needing a mechanism to traverse NATs are discussed AH> in [ABOBA]. AH> The main driving principle in creating this document has been AH> simplicity. The defined mechanisms can be implemented and deployed AH> rapidly, and they are believed to solve all important practical AH> problems. AH> This document defines methods for determining the need for AH> UDP encapsulation, both in the presence of Basic NAT (i.e. without AH> port translation) and in the presence of NAPT (with port AH> translation). AH> This is done by the receiver, based on the information available AH> in standard IKE packets. AH> ESPUDP in both tunnel mode and transport mode are defined. Tunnel AH> mode AH> ESPUDP through NAT is seen easier to implement, but transport mode AH> ESPUDP AH> can also be made to go through NAT. AH> The overhead over ordinary ESP modes is 8 bytes for the UDP header. AH> 2. Design Choices AH> This document does not define a method to pass AH packets through AH> NATs. The reason is that such mechanism is seen unnecessary. AH> No negotiation protocol for ESPUDP is defined. This is for AH> simplicity, AH> since practical problems are solvable without such a mechanism. If AH> such a mechanism is wanted, something like in [STENBERG] could AH> be deployed. AH> ESPUDP uses a different port than IKE. This is to enable firewalls AH> to differentiate between these two types of traffic. AH> 3. Header Formats AH> This section contains definitions for IP, UDP and ESP packet formats AH> for easy reference. AH> IP header is defined in [RFC 791]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Version| IHL |Type of Service| Total Length | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Identification |Flags| Fragment Offset | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Time to Live | Protocol | Header Checksum | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Source Address | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Destination Address | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Options | Padding | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> The checksum in the IP header encompasses only the IP header. AH> UDP header is defined in [RFC 768]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Source Port | Destination Port | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Length | Checksum | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> The checksum in the UDP header encompasses parts of the IP header, AH> the UDP header, and the UDP payload. AH> With ESPUDP the UDP cheksum is disabled. There's no need for it here AH> because ESP authentication goes between the same network entities. AH> The ESPUDP source and destination ports have the value 2797 AH> (or 2746, undecided) when sent by the initiator inside a private AH> addressing realm. AH> Reference: AH> cpudpencap 2746/tcp CPUDPENCAP AH> cpudpencap 2746/udp CPUDPENCAP AH> # Tamir Zegman AH> esp-encap 2797/tcp esp-encap AH> esp-encap 2797/udp esp-encap AH> # Jorn Sierwald AH> AH> ESP header is defined in [RFC 2406]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ---- AH> | Security Parameters Index (SPI) | AH> ^Auth. AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Cov- AH> | Sequence Number | AH> |erage AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AH> ---- AH> | Payload Data* (variable) | | AH> ^ AH> ~ ~ | AH> | AH> | | AH> |Conf. AH> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Cov- AH> | | Padding (0-255 bytes) | AH> |erage* AH> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AH> | AH> | | Pad Length | Next Header | v AH> v AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ------ AH> | Authentication Data (variable) | AH> ~ ~ AH> | | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ESPUDP has the following packet structures. AH> Transport mode: AH> --------------------------------------------------------- AH> IPv4 |orig IP hdr | UDP | ESP | | ESP | ESP| AH> |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth| AH> --------------------------------------------------------- AH> |<------- encrypted ---->| AH> |<-------- authenticated ----->| AH> Tunnel mode: AH> ---------------------------------------------------------------------- AH> IPv4 | new IP hdr* | UDP | ESP | orig IP hdr* | | ESP | AH> ESP| AH> |(any options)| HDr | Hdr | (any options) | Payload AH> Data|Trailer|Auth| AH> ---------------------------------------------------------------------- AH> |<--------- encrypted --------------->| AH> |<----------- authenticated --------------->| AH> NAT translation keepalive: AH> --------------------- AH> IPv4 |orig IP hdr | UDP | AH> |(any options)| Hdr | AH> --------------------- AH> 4. IKE Negotiation AH> The peers SHOULD exchange the VID AH> "draft-huttunen-ipsec-esp-in-udp-00.txt" AH> in the first two IKE phase I messages if they support this draft. If AH> this AH> is not done, the initiator SHOULD NOT use the private encapsulation AH> attributes during phase II. AH> ESPUDP is negotiated by using one of the following encapsulation AH> attributes in an ESP proposal: AH> 61440 ESPUDP in tunnel mode AH> 61441 ESPUDP in transport mode AH> <> 61440 ==>> UDP encapsulation + ESP in tunnel mode (CheckPoint) 63337 ==>> UDP encapsulation + ESP in tunnel mode (F-Secure) 63338 ==>> UDP encapsulation + ESP in transport mode (F-Secure) AH> The responder SHOULD choose ESPUDP proposals if the packets are AH> determined to have come through NAT, even if VIDs were not exchanged AH> during phase I. This determination can be done in two ways: AH> a) If the IKE source port in the received packet is not 500. AH> b) If the phase II identity is an IP address from a private address AH> range that is different from the source IP address in the IKE AH> packet, AH> and the policy defines a connection from a host. AH> See [RFC1918]. AH> Method a) allows determining NAT traversal in all situations when NAT AH> is of type NAPT, assuming the initiator used the source port 500. AH> Method b) allows determining NAT traversal in host-to-X situations AH> in the presence of Basic NAT. AH> If the proposal list contains only ESPUDP proposals AH> that are otherwise acceptable, one of them SHOULD be chosen even AH> if NAT has not been determined to exist between the peers. AH> These methods are not foolproof. If it is determined incorrectly AH> that NAT exists, an overhead of 8 bytes is incurred. This can be AH> avoided AH> by the initiator by not providing ESPUDP proposals. AH> On the other hand, if incorrect determination is made that NAT AH> doesn't AH> exist, the connection will fail. This can be avoided by the initiator AH> by AH> providing only ESPUDP encapsulated proposals. AH> An implementation confirming to this draft MUST implement tunnel AH> mode, AH> and MAY implement transport mode. (If and when transport mode AH> operation AH> through NAT is specified more fully, this should be reviewed.) AH> The source IP address or the source port of the initiator, as seen by AH> the responder, MUST NOT change during the connection. AH> When ESPUDP is used to traverse NATs, IP address -based phase I AH> identities AH> MUST NOT be used to identify entities inside private addressing AH> spaces. AH> IP address based identities are used in ESPUDP tunnel mode according AH> to AH> standard IKE rules. In ESPUDP transport mode the responder SHOULD AH> accept AH> a phase II IP address identity that is different from the IP packet AH> source AH> address, iff the phase II identity is a single IP address from a AH> private AH> address space. AH> 5. ESPUDP NAT Translation Keepalive AH> A peer MAY choose to send a UDP packet using the same ports as AH> ESPUDP with no data contained in the UDP packet. The typical AH> reason to do this would be to keep the NAT translation table(s) AH> active when no user data is being transferred. AH> The receiver of such an empty ESPUDP packet MUST silently AH> ignore the packet. AH> Such empty ESPUDP packets SHOULD NOT force the link to stay AH> up, and they SHOULD NOT be counted as user traffic. (They are AH> also not a candidate mechanism for IKE/IPsec heartbeats.) AH> A peer MAY also choose to send an empty UDP packet using AH> the IKE port numbers. This packet is an illegal IKE packet AH> and will be discarded by the recipient. No sane IKE implementation AH> will terminate a connection due to this, since such packets AH> are so easy to forge. The reason for this would be to keep AH> the NAT translation tables for IKE messages active. AH> 6. Address Translation Options AH> Since separate addressing spaces are being used, addresses must AH> be translated by someone. ESPUDP ignores the address translations AH> that occur along its route, and thus either of the endpoints AH> must do this. AH> In ESPUDP tunnel mode, either of the following MUST be done: AH> a) The initiator MUST obtain an IP address from the peer, and AH> use this IP address in all tunneled packets being sent. AH> b) The responder MUST do NAT translation on incoming packets. AH> In ESPUDP transport mode, the initiator MUST correct the cheksums AH> in the packets being received through NAT. Their checksums will AH> be incorrect, since NAT has changed the IP address. Similarly AH> the responder MUST correct the checksums. The responder MUST also AH> do NAT translation, so that two clients using the same source port AH> do not clash. AH> 7. Deployment Considerations AH> 7.1 Client <-> Gateway AH> +----+ \ / +----+ +----+ AH> | |-------------|----------------| |----------| | AH> +----+ / \ +----+ +----+ AH> Alice's NAT GW Suzy's AH> Laptop Server AH> ESPUDP (tunnel mode) AH> ================================ AH> The effect of ESPUDP is to allow the protected packets to pass AH> through the tunnel. However, the contained IP addresses are not AH> affected. AH> Since Alice's laptop may have any IP address in its current residing AH> network, there must be some method of converting that IP address AH> to be usable in Suzy's network. AH> Two methods exist: AH> a) The GW can assign Alice's laptop an intranet address using some AH> mechanism like DHCP or ConfigMode. AH> b) The GW can internally assign Alice's laptop an intranet address AH> and do NAT translation as the packets pass through the GW. AH> Payload protocols carrying IP addresses, like FTP, continue to work AH> because the NAT translation for those is done either at Alice's AH> laptop AH> (method a) or at the GW (method b). AH> 7.2 Client <-> Client AH> +----+ \ / +----+ AH> | |-------------|--------------------| | AH> +----+ / \ +----+ AH> Alice's NAT Suzy's AH> Laptop Server AH> ESPUDP (tunnel/ AH> transport mode) AH> ==================================== AH> Transport mode ESPUDP requires that both Alice's laptop and Suzy's AH> server contain functionality to correct checksums that are AH> invalidated AH> by the source IP address being changed. Suzy's server must also do AH> NAT to allow several clients using the same UDP source port to AH> connect. AH> For this reason, ESPUDP in transport mode is not recommended when AH> NAT traversal is required. AH> The recommended choice is to use tunnel mode ESP over UDP AH> in this situation. Similarly to the Client<->GW case, the contained AH> protocols like FTP continue to work. AH> 7.3 Gateway <-> Gateway AH> +----+ +----+ \ / +----+ AH> +----+ AH> | |------| |-------|----------------| |----------| AH> | AH> +----+ +----+ / \ +----+ AH> +----+ AH> Alice's GW NAT GW AH> Suzy's AH> Laptop AH> Server AH> ESPUDP (tunnel mode) AH> ============================ AH> The GW<->GW case is similar to the Client<->GW case; ESPUDP allows AH> the connection to pass NAT, but a method to convert Alice's laptop's AH> address to be suitable in Suzy's network is necessary. The only AH> viable AH> option is to do NAT at either of the GWs, since no address assignment AH> protocol is defined to work between GWs. AH> Contained protocols like FTP continue to work because NAT can be AH> performed on unencrypted packets. AH> 7.4 Client <-> Gateway with End-to-end encryption AH> +----+ \ / +----+ +----+ AH> | |-------------|----------------| |----------| | AH> +----+ / \ +----+ +----+ AH> Alice's NAT GW Suzy's AH> Laptop Server AH> ESPUDP (tunnel mode) AH> ================================ AH> ESP (transport mode) AH> ================================================ AH> One way to make this work is for the GW to provide Alice's laptop AH> a suitable address, so that the GW need not do any NAT to AH> the contained packets. AH> 7.5 L2TP over ESPUDP AH> This section has not been written/studied yet. What will it require AH> to be able to do FTP through all these protocol layers? Volunteers? AH> 8. Security Considerations AH> On some systems ESPUDP may have DoS attack consequences, AH> especially if ordinary operating system UDP-functionality is AH> being used. It may be recommended not to open an ordinary UDP-port AH> for this. AH> Implementors are warned that it is possible for remote peers to AH> negotiate entries that overlap in the GW. AH> +----+ \ / AH> | |-------------|----\ AH> +----+ / \ \ AH> Alice's NAT 1 \ AH> Laptop \ AH> 10.1.2.3 \ AH> +----+ \ / \ +----+ +----+ AH> | |-------------|----------+------| |----------| | AH> +----+ / \ +----+ +----+ AH> Bob's NAT 2 GW Suzy's AH> Laptop Server AH> 10.1.2.3 AH> Because GW will now see two possible SAs that lead to 10.1.2.3, it AH> can become confused where to send packets coming from Suzy's server. AH> Implementations MUST devise ways of preventing such a thing from AH> occurring; either by disallowing such connections or by other means. AH> It is not possible for a hacker to obtain an arbitrary address in the AH> intranet being protected by the GW. If address assignment by the GW AH> is provided, only the address assigned to the hacker is allowed to AH> pass AH> through the GW. In the other case, address is always assigned to AH> the hacker internally by the GW and the (arbitrary) IP address of the AH> hacker is always translated by a NAT functionality in the GW. AH> Acknowledgements AH> Tamir Zegman of CheckPoint, and William Dixon of Microsoft have AH> provided helpful advice for producing this draft. AH> References AH> [RFC 1918] Address Allocation for Private Internets AH> [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address AH> Translator (NAT) Terminology and Considerations", RFC AH> 2663, August 1999. AH> [ABOBA] Aboba, B., "NAT and IPSEC", Internet draft (work AH> in progress), draft-aboba-nat-ipsec-02.txt, July 2000 AH> [STENBERG] Stenberg, M. et. al. IPsec NAT-Traversal, Internet draft AH> (work in progress), AH> draft-stenberg-ipsec-nat-traversal-00.txt, AH> July 2000 From owner-ipsec@lists.tislabs.com Mon Sep 18 12:37:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23313; Mon, 18 Sep 2000 12:37:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13842 Mon, 18 Sep 2000 13:30:49 -0400 (EDT) Message-ID: <39C6538D.824A2169@isi.edu> Date: Mon, 18 Sep 2000 10:40:29 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: itojun@iijlab.net CC: Henry Spencer , IP Security List Subject: Re: TOS copying considered harmful References: <10929.969091766@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun@iijlab.net wrote: > > >> Having two specifications for packets with protocol type 4 inside IP > >> should be avoided if at all possible. > >Now this I agree with. Especially since the IPsec RFCs themselves seem to > >be very confused about this. > > for reference, here's a little list of specs which talks about > protocol type 4/41 encapsulation. not sure if it is complete. > (from KAME sys/netinet/ip_encap.c) This, together with Harry's earlier observation that Assigned Numbers points back to 2003 regarding IP protocol type = 4, are very good reasons for incorporating as much as possible into 2003bis. Regarding Ran's note about IPSEC, I'm proposing only that 2003bis allow everything that IPSEC requires, so that when IPSEC refers to tunneling, it can say "implement 2003bis", and then put additional _restrictions_, e.g., regarding the copying or not of the TOS and DF bits. It's fine for subsequent documents to limit optional components of a spec. > * Here's a list of protocol that want protocol #4: > * RFC1853 IPv4-in-IPv4 tunnelling > * RFC2003 IPv4 encapsulation within IPv4 > * RFC2344 reverse tunnelling for mobile-ip4 > * RFC2401 IPsec tunnel 2003 is the one that's recognized in Assigned Numbers, as Henry noted earlier. 1853 is effectively superceded by 2003, even though it's only implicit (in the Acks of 2003) 2344 refers back to 2003; a new variant is not proposed it is only 2401 that conflicts with 2003, and only on TOS and DF 2003bis should discuss the clearing of these bits as an option, and discuss the implications of using that option, precisely because it is needed, e.g., for 2401 (or 2401bis). Then 2401bis can refer back to 2003bis for the specification of the tunnel headers, and indicate that 'clearing the bits' may be required for security reasons, and that it can use exactly the header specified by 2003bis. Joe From owner-ipsec@lists.tislabs.com Mon Sep 18 12:37:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23325; Mon, 18 Sep 2000 12:37:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14059 Mon, 18 Sep 2000 14:23:41 -0400 (EDT) Message-ID: <39C66020.94829FCC@isi.edu> Date: Mon, 18 Sep 2000 11:34:08 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: IP Security List Subject: Re: TOS copying considered harmful References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Joe, > > As the author for 2401 (bis) I am not comfortable trying to > coordinate with a revised 2003. It makes life much harder, creates > more cross reference problems, etc. We'll see how this progresses, > but I'm not commiting to this strategy at this time. How about at least referring to 2003 as much as possible, and highlighting where the divergence is? The goal is to get 2401bis to spec as little 'new' as possible here. The only divergence is in the treatment of the TOS and DF fields. In that case, 2401bis should indicate that: - it uses 2003 tunnel headers - it needs to allow clearing the TOS or DF bits, if indicated in an SA, however this conflicts with the specification in 2003 The only coordination here is that 2003bis should indicate that clearing the TOS and/or DF bits MAY occur, and what the consequences are. I don't see a tight coupling required. Joe From owner-ipsec@lists.tislabs.com Mon Sep 18 12:37:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23345; Mon, 18 Sep 2000 12:37:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14023 Mon, 18 Sep 2000 14:15:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39C6538D.824A2169@isi.edu> References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> Date: Mon, 18 Sep 2000 14:23:28 -0400 To: Joe Touch From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, As the author for 2401 (bis) I am not comfortable trying to coordinate with a revised 2003. It makes life much harder, creates more cross reference problems, etc. We'll see how this progresses, but I'm not commiting to this strategy at this time. Steve From owner-ipsec@lists.tislabs.com Mon Sep 18 12:46:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23475; Mon, 18 Sep 2000 12:46:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14095 Mon, 18 Sep 2000 14:35:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39C66020.94829FCC@isi.edu> References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> <39C66020.94829FCC@isi.edu> Date: Mon, 18 Sep 2000 14:44:45 -0400 To: Joe Touch From: Stephen Kent Subject: Re: TOS copying considered harmful Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, >Stephen Kent wrote: > > > > Joe, > > > > As the author for 2401 (bis) I am not comfortable trying to > > coordinate with a revised 2003. It makes life much harder, creates > > more cross reference problems, etc. We'll see how this progresses, > > but I'm not commiting to this strategy at this time. > >How about at least referring to 2003 as much as possible, >and highlighting where the divergence is? > >The goal is to get 2401bis to spec as little 'new' as possible here. >The only divergence is in the treatment of the TOS and DF fields. > >In that case, 2401bis should indicate that: > > - it uses 2003 tunnel headers > - it needs to allow clearing the TOS or DF bits, if > indicated in an SA, however this conflicts with > the specification in 2003 > >The only coordination here is that 2003bis should indicate that clearing >the TOS and/or DF bits MAY occur, and what the consequences are. I don't >see a tight coupling required. That sounds more manageable. We'll see how the text works out. Steve From owner-ipsec@lists.tislabs.com Mon Sep 18 14:20:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25295; Mon, 18 Sep 2000 14:20:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14350 Mon, 18 Sep 2000 16:04:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 18 Sep 2000 16:14:58 -0400 To: "Joseph D. Harwood" From: Stephen Kent Subject: Re: FW: TOS copying considered harmful Cc: "Ipsec" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, Sorry, nothing available for review yet. Steve From owner-ipsec@lists.tislabs.com Tue Sep 19 01:21:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11188; Tue, 19 Sep 2000 01:21:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16389 Tue, 19 Sep 2000 02:41:26 -0400 (EDT) Message-ID: <39C71A97.EF6613F@sxb.bsf.alcatel.fr> Date: Tue, 19 Sep 2000 08:49:43 +0100 From: Olivier Kreet X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IP Security List Subject: Re: TOS copying considered harmful References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: [...] > 2003bis should discuss the clearing of these bits as an option, and > discuss the implications of using that option, precisely because it is > needed, e.g., for 2401 (or 2401bis). > > Then 2401bis can refer back to 2003bis for the specification of the > tunnel headers, and indicate that 'clearing the bits' may be required > for security reasons, and that it can use exactly the header specified > by 2003bis. > > Joe As stated in the first post of this discussion thread, besides security reasons, clearing the TOS field may also be required when QoS is to be applied on the path of the tunnel. The packet reordering may cause the anti-replay mechanism to reject low prio packets that were (strongly) delayed due to QoS. See draft-ietf-diffserv-tunnels-02.txt, section 5.1. This is related to ESP and AH sequence numbers, that are specific to IPSec and not an IP in IP encapsulation problem. This point should go to RFC2401, right? Olivier. From owner-ipsec@lists.tislabs.com Tue Sep 19 01:21:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11190; Tue, 19 Sep 2000 01:21:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16674 Tue, 19 Sep 2000 03:12:16 -0400 (EDT) Message-Id: <200009190722.e8J7Mlo05795@itojun.org> To: Olivier Kreet cc: IP Security List In-reply-to: olivier.kreet's message of Tue, 19 Sep 2000 08:49:43 +0100. <39C71A97.EF6613F@sxb.bsf.alcatel.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: TOS copying considered harmful From: Jun-ichiro itojun Hagino Date: Tue, 19 Sep 2000 16:22:46 +0900 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >As stated in the first post of this discussion thread, besides security reasons, >clearing the TOS field may also be required when QoS is to be applied on the path >of the tunnel. The packet reordering may cause the anti-replay mechanism to >reject low prio packets that were (strongly) delayed due to QoS. See >draft-ietf-diffserv-tunnels-02.txt, section 5.1. >This is related to ESP and AH sequence numbers, that are specific to IPSec and >not an IP in IP encapsulation problem. This point should go to RFC2401, right? I don't understand the last sentence. why sequence numbers are the issue? they are defined per SA (= unique to src, and normally identifies single dst), and should not matter even if we add a tunnel encapsulation. could you tell us more? I personally still believe that we should separately define tunnelling separately from IPsec itself (like RFC182x did), but given the way IKE is defined today and is used to negotiate IPsec tunnels, i think it's too late. itojun From owner-ipsec@lists.tislabs.com Tue Sep 19 01:47:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12009; Tue, 19 Sep 2000 01:47:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16843 Tue, 19 Sep 2000 03:32:02 -0400 (EDT) Message-ID: <39C7268C.A089CF55@sxb.bsf.alcatel.fr> Date: Tue, 19 Sep 2000 09:40:44 +0100 From: Olivier Kreet X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: IP Security List Subject: Re: TOS copying considered harmful References: <200009190722.e8J7Mlo05795@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > >As stated in the first post of this discussion thread, besides security reasons, > >clearing the TOS field may also be required when QoS is to be applied on the path > >of the tunnel. The packet reordering may cause the anti-replay mechanism to > >reject low prio packets that were (strongly) delayed due to QoS. See > >draft-ietf-diffserv-tunnels-02.txt, section 5.1. > >This is related to ESP and AH sequence numbers, that are specific to IPSec and > >not an IP in IP encapsulation problem. This point should go to RFC2401, right? > > I don't understand the last sentence. why sequence numbers are the > issue? they are defined per SA (= unique to src, and normally > identifies single dst), and should not matter even if we add a tunnel > encapsulation. could you tell us more? The anti-replay mechanism is based on these sequence numbers. Replayed packets but also packets arriving on the left of the sliding window used to implement this mechanism are thrown away. If the TOS is copied from inner to outer header and you have different classes of service inside a single tunnel (a single SA), then you are subject to packet reordering if some nodes on the tunnel path do QoS based on the tos (or dscp). At a certain level of reordering, low prio packets will arrive too late at dst, i.e. on the left of the window and be deleted. This is not expected. Once again, this is discussed in the draft I mentionned above. > I personally still believe that we should separately define tunnelling > separately from IPsec itself (like RFC182x did), but given the way IKE > is defined today and is used to negotiate IPsec tunnels, i think it's > too late. > > itojun From owner-ipsec@lists.tislabs.com Tue Sep 19 08:09:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25857; Tue, 19 Sep 2000 08:09:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18360 Tue, 19 Sep 2000 10:00:53 -0400 (EDT) Message-Id: <200009191411.e8JEBRo06581@itojun.org> To: Olivier Kreet cc: IP Security List In-reply-to: olivier.kreet's message of Tue, 19 Sep 2000 09:40:44 +0100. <39C7268C.A089CF55@sxb.bsf.alcatel.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: TOS copying considered harmful From: Jun-ichiro itojun Hagino Date: Tue, 19 Sep 2000 23:11:26 +0900 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I don't understand the last sentence. why sequence numbers are the >> issue? they are defined per SA (= unique to src, and normally >> identifies single dst), and should not matter even if we add a tunnel >> encapsulation. could you tell us more? > >The anti-replay mechanism is based on these sequence numbers. Replayed packets but >also packets arriving on the left of the sliding window used to implement this >mechanism are thrown away. If the TOS is copied from inner to outer header and you >have different classes of service inside a single tunnel (a single SA), then you are >subject to packet reordering if some nodes on the tunnel path do QoS based on the tos >(or dscp). At a certain level of reordering, low prio packets will arrive too late at >dst, i.e. on the left of the window and be deleted. This is not expected. Once again, >this is discussed in the draft I mentionned above. I see. RFC2402 mandates 32bit bitmap, and recommends 64bit bitmap. - is 64bit not enough for normal nodes? - if larger window size helps, how big do you suggest? - if not, what other mechanism do you suggest? itojun From owner-ipsec@lists.tislabs.com Tue Sep 19 08:10:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25913; Tue, 19 Sep 2000 08:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18103 Tue, 19 Sep 2000 09:29:33 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Olivier Kreet" , "Jun-ichiro itojun Hagino" Cc: "IP Security List" Subject: RE: TOS copying considered harmful Date: Tue, 19 Sep 2000 06:25:22 -0700 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.00.2615.200 In-reply-to: <39C7268C.A089CF55@sxb.bsf.alcatel.fr> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Olivier Kreet [mailto://olivier.kreet@sxb.bsf.alcatel.fr] writes: > Jun-ichiro itojun Hagino wrote: > > > >As stated in the first post of this discussion thread, besides > security reasons, > > >clearing the TOS field may also be required when QoS is to be > applied on the path > > >of the tunnel. The packet reordering may cause the anti-replay > mechanism to > > >reject low prio packets that were (strongly) delayed due to QoS. See > > >draft-ietf-diffserv-tunnels-02.txt, section 5.1. > > >This is related to ESP and AH sequence numbers, that are > specific to IPSec and > > >not an IP in IP encapsulation problem. This point should go to > RFC2401, right? > > > > I don't understand the last sentence. why sequence > numbers are the > > issue? they are defined per SA (= unique to src, and normally > > identifies single dst), and should not matter even if > we add a tunnel > > encapsulation. could you tell us more? > > The anti-replay mechanism is based on these sequence numbers. > Replayed packets but > also packets arriving on the left of the sliding window used to > implement this > mechanism are thrown away. If the TOS is copied from inner to > outer header and you > have different classes of service inside a single tunnel (a > single SA), then you are > subject to packet reordering if some nodes on the tunnel path do > QoS based on the tos > (or dscp). At a certain level of reordering, low prio packets > will arrive too late at > dst, i.e. on the left of the window and be deleted. This is not > expected. Please forgive my ignorance, but I don't quite understand the last sentence. Ignoring the presence of both IPSec and the tunnel, isn't the occasional dropping of low priority packets exactly what one would expect on an under-provisioned network using QOS? > Once again, > this is discussed in the draft I mentionned above. > > > > I personally still believe that we should separately > define tunnelling > > separately from IPsec itself (like RFC182x did), but > given the way IKE > > is defined today and is used to negotiate IPsec > tunnels, i think it's > > too late. > > > > itojun > > > > From owner-ipsec@lists.tislabs.com Tue Sep 19 08:21:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28604; Tue, 19 Sep 2000 08:21:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18378 Tue, 19 Sep 2000 10:05:41 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14791.29996.65463.323612@thomasm-u1.cisco.com> Date: Tue, 19 Sep 2000 07:16:12 -0700 (PDT) To: Olivier Kreet Cc: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: <39C71A97.EF6613F@sxb.bsf.alcatel.fr> References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> <39C71A97.EF6613F@sxb.bsf.alcatel.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Olivier Kreet writes: > Joe Touch wrote: > [...] > > > 2003bis should discuss the clearing of these bits as an option, and > > discuss the implications of using that option, precisely because it is > > needed, e.g., for 2401 (or 2401bis). > > > > Then 2401bis can refer back to 2003bis for the specification of the > > tunnel headers, and indicate that 'clearing the bits' may be required > > for security reasons, and that it can use exactly the header specified > > by 2003bis. > > > > Joe > > As stated in the first post of this discussion thread, besides security reasons, > clearing the TOS field may also be required when QoS is to be applied on the path > of the tunnel. The packet reordering may cause the anti-replay mechanism to > reject low prio packets that were (strongly) delayed due to QoS. See > draft-ietf-diffserv-tunnels-02.txt, section 5.1. > This is related to ESP and AH sequence numbers, that are specific to IPSec and > not an IP in IP encapsulation problem. This point should go to RFC2401, right? I'm not sure how this is especially different than how you would deal with any other interface with a fixed -- and perhaps too short -- queue length. You either need to: 1) deal with whatever is causing the congestive loss (best) 2) don't mix the BE traffic with the other traffic by placing different classes in their own tunnels (better) 3) increase the depth of the queue (not especially good for EF marked traffic, typically) Mike From owner-ipsec@lists.tislabs.com Tue Sep 19 08:36:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00832; Tue, 19 Sep 2000 08:36:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18472 Tue, 19 Sep 2000 10:18:37 -0400 (EDT) Message-ID: <39C7857E.2E7E3B7E@sxb.bsf.alcatel.fr> Date: Tue, 19 Sep 2000 16:25:50 +0100 From: Olivier Kreet X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com CC: Jun-ichiro itojun Hagino , IP Security List Subject: Re: TOS copying considered harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glen Zorn wrote: > Olivier Kreet [mailto://olivier.kreet@sxb.bsf.alcatel.fr] writes: > > > Jun-ichiro itojun Hagino wrote: > > > > > >As stated in the first post of this discussion thread, besides > > security reasons, > > > >clearing the TOS field may also be required when QoS is to be > > applied on the path > > > >of the tunnel. The packet reordering may cause the anti-replay > > mechanism to > > > >reject low prio packets that were (strongly) delayed due to QoS. See > > > >draft-ietf-diffserv-tunnels-02.txt, section 5.1. > > > >This is related to ESP and AH sequence numbers, that are > > specific to IPSec and > > > >not an IP in IP encapsulation problem. This point should go to > > RFC2401, right? > > > > > > I don't understand the last sentence. why sequence > > numbers are the > > > issue? they are defined per SA (= unique to src, and normally > > > identifies single dst), and should not matter even if > > we add a tunnel > > > encapsulation. could you tell us more? > > > > The anti-replay mechanism is based on these sequence numbers. > > Replayed packets but > > also packets arriving on the left of the sliding window used to > > implement this > > mechanism are thrown away. If the TOS is copied from inner to > > outer header and you > > have different classes of service inside a single tunnel (a > > single SA), then you are > > subject to packet reordering if some nodes on the tunnel path do > > QoS based on the tos > > (or dscp). At a certain level of reordering, low prio packets > > will arrive too late at > > dst, i.e. on the left of the window and be deleted. This is not > > expected. > > Please forgive my ignorance, but I don't quite understand the last sentence. > Ignoring the presence of both IPSec and the tunnel, isn't the occasional > dropping of low priority packets exactly what one would expect on an > under-provisioned network using QOS? > Of course it is, but my understanding is that low priority packets should be thrown away at nodes enforcing the QoS, not at the IPSec gateways, which knows nothing about QoS. If a packet arrives at the destination IPSec gateway, it means that it did somehow conform to the QoS rules of the network is went through. A drop due to the IPSec anti-replay mechanism just makes quality of service even lower for these packets, though it is not its original purpose... Hope this makes sense... > > > Once again, > > this is discussed in the draft I mentionned above. > > > > > > > I personally still believe that we should separately > > define tunnelling > > > separately from IPsec itself (like RFC182x did), but > > given the way IKE > > > is defined today and is used to negotiate IPsec > > tunnels, i think it's > > > too late. > > > > > > itojun > > > > > > > > -- Olivier Kreet Alcatel (ESD/SME) tel: +33 (0)3 90 67 68 52 1, rte du Dr Schweitzer fax: +33 (0)3 90 67 77 93 67408 Illkirch cedex email: olivier.kreet@sxb.bsf.alcatel.fr France From owner-ipsec@lists.tislabs.com Tue Sep 19 08:45:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01012; Tue, 19 Sep 2000 08:45:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18540 Tue, 19 Sep 2000 10:33:40 -0400 (EDT) Message-ID: <39C7895E.D04366DA@sxb.bsf.alcatel.fr> Date: Tue, 19 Sep 2000 16:42:22 +0100 From: Olivier Kreet X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: IP Security List Subject: Re: TOS copying considered harmful References: <200009191411.e8JEBRo06581@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > >> I don't understand the last sentence. why sequence numbers are the > >> issue? they are defined per SA (= unique to src, and normally > >> identifies single dst), and should not matter even if we add a tunnel > >> encapsulation. could you tell us more? > > > >The anti-replay mechanism is based on these sequence numbers. Replayed packets but > >also packets arriving on the left of the sliding window used to implement this > >mechanism are thrown away. If the TOS is copied from inner to outer header and you > >have different classes of service inside a single tunnel (a single SA), then you are > >subject to packet reordering if some nodes on the tunnel path do QoS based on the tos > >(or dscp). At a certain level of reordering, low prio packets will arrive too late at > >dst, i.e. on the left of the window and be deleted. This is not expected. Once again, > >this is discussed in the draft I mentionned above. > > I see. RFC2402 mandates 32bit bitmap, and recommends 64bit bitmap. > - is 64bit not enough for normal nodes? > - if larger window size helps, how big do you suggest? > - if not, what other mechanism do you suggest? > > itojun I admit I did not test and I'm not aware of any study done on the window size vs packet loss due to reordering. On the theorical point of view, the problem will still be there whatever the size of the window, but yes, probably hidden by a large enough window size. The best thing would probably be to have one tunnel per class of service, but it is not always possible to set up parallel tunnels on today's IPSec implementations (e.g. linux Freeswan). From owner-ipsec@lists.tislabs.com Tue Sep 19 10:21:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04179; Tue, 19 Sep 2000 10:21:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18898 Tue, 19 Sep 2000 12:09:09 -0400 (EDT) Date: Tue, 19 Sep 2000 12:19:31 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: <39C7895E.D04366DA@sxb.bsf.alcatel.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Sep 2000, Olivier Kreet wrote: > The best thing would probably be to have one tunnel per class of > service, but it is not always possible to set up parallel tunnels on > today's IPSec implementations (e.g. linux Freeswan). Also, whether this is "best" depends on your priorities. Making the TOS field visible -- whether in one tunnel or parallel tunnels -- provides a hint to traffic analysts and a covert channel for Trojan horses, so the underlying assumption that this should be done is itself questionable. (This is another instance of the standard tradeoff: security versus user convenience.) I note, also, that TOS isn't in 2401's list of packet selectors, so there is no requirement in the current IPsec architecture that such parallel tunnels be supported. (FreeS/WAN currently doesn't do parallel tunnels *at all*, for implementation reasons which will eventually be fixed... but support for TOS-based tunnel selection would require non-standard extensions to IPsec.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Sep 20 06:41:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24092; Wed, 20 Sep 2000 06:41:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22044 Wed, 20 Sep 2000 07:58:46 -0400 (EDT) Message-Id: <200009200348.e8K3lPf23177@pzero.sandelman.ottawa.on.ca> To: IP Security List Subject: Re: TOS copying considered harmful In-reply-to: Your message of "Tue, 19 Sep 2000 12:19:31 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Sep 2000 21:46:58 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Tue, 19 Sep 2000, Olivier Kreet wrote: >> The best thing would probably be to have one tunnel per class of >> service, but it is not always possible to set up parallel tunnels on >> today's IPSec implementations (e.g. linux Freeswan). Henry> Also, whether this is "best" depends on your priorities. Making the TOS Henry> field visible -- whether in one tunnel or parallel tunnels -- provides a Henry> hint to traffic analysts and a covert channel for Trojan horses, so the Henry> underlying assumption that this should be done is itself The hint for traffic analysers is moot. The *purpose* of copying the TOS/DSCP+ECM byte is so that packet will get treated differently. The streams with higher priority will get noticed. QoS and immunity to traffic analysis are fundamentally compatible. QoS is about highlighting which traffic is which. This is a security vs convenience argument with varrying degrees of paranoia. This is simply a binary choice. If you want to your activities to remain unnoticed to traffic analysis, you must send all data with the same quality of service. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems/while this plane is 45 |problem with[ ] mcr@solidum.com www.solidum.com\minutes late and cramped|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Sep 20 09:18:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01810; Wed, 20 Sep 2000 09:18:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22552 Wed, 20 Sep 2000 10:43:37 -0400 (EDT) Message-Id: <01C02340.46360B80.awank@future.futsoft.com> From: Awan Kumar Sharma Reply-To: "awank@future.futsoft.com" To: "ipsec@lists.tislabs.com" Subject: SA byte lifetime Date: Wed, 20 Sep 2000 20:20:47 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am having some doubts regarding the use of SA byte lifetime. Specifically for the case in which an SA bundle has been negotiated, say AH and ESP, the number of bytes processed by the AH SA will be different from the number of bytes processed by the ESP SA. Normally, for SA bundle case, ESP packet is encapsulated by AH, so the number of bytes processed by the AH SA will always be more than the ESP SA. So, in that case, the AH SA will expire before the AH SA. Now the problem is : 1) Once the AH SA soft byte lifetime expires, should we : a) negotiate for the bundle again.- In this we are assuming that the ESP SA has also expired. b) negotiate for AH SA only - In this case, how ? 2) Once the AH SA hard byte lifetime has expired, should we delete the ESP SA also. Thanks in Advance. Awan Kumar Sharma Software Engg., Future Software Ltd., Chennai - India From owner-ipsec@lists.tislabs.com Wed Sep 20 10:06:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02723; Wed, 20 Sep 2000 10:06:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22825 Wed, 20 Sep 2000 11:53:12 -0400 (EDT) Message-Id: <01C0234A.06A802C0.awank@future.futsoft.com> From: Awan Kumar Sharma Reply-To: "awank@future.futsoft.com" To: "Ipsec (E-mail)" Subject: ISAKMP Delete Payload Date: Wed, 20 Sep 2000 21:30:37 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am having a doubt in ISAKMP delete payload. One of the field specifies the number of SPI's in the delete payload. According to my understanding there will be two SPIs in the Delete payload for IPSec SA. One for the Inbound SA and the other for the Outbound SA. Please correct me if I am wrong. Thanks in advance. Awan Kumar Sharma Software Engg. Future Software Ltd. Chennai - India From owner-ipsec@lists.tislabs.com Wed Sep 20 11:35:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04056; Wed, 20 Sep 2000 11:35:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23101 Wed, 20 Sep 2000 13:02:12 -0400 (EDT) Date: Wed, 20 Sep 2000 13:12:38 -0400 (EDT) From: Henry Spencer To: Awan Kumar Sharma cc: "Ipsec (E-mail)" Subject: Re: ISAKMP Delete Payload In-Reply-To: <01C0234A.06A802C0.awank@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Sep 2000, Awan Kumar Sharma wrote: > I am having a doubt in ISAKMP delete payload. One of the field specifies > the number of SPI's in the delete payload. According to my understanding > there will be two SPIs in the Delete payload for IPSec SA. One for the > Inbound SA and the other for the Outbound SA. Please correct me if I am > wrong. Although the wording in the RFCs is confusing, I believe you're wrong. IPsec SAs in Delete payloads are inbound (toward the sender of the Delete) only. Delete is an announcement ("I'm no longer accepting traffic on these SAs"), not a request. Note that the destination address is not specified in Delete, so it must be taken to be the sender. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Sep 20 12:46:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05286; Wed, 20 Sep 2000 12:46:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23474 Wed, 20 Sep 2000 14:28:19 -0400 (EDT) Message-Id: <3.0.5.32.20000920173927.033cba30@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 20 Sep 2000 17:39:27 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: SA byte lifetime In-Reply-To: <01C02340.46360B80.awank@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA22739 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 20:20 20.9.2000 +0530, you wrote: >Hi, > I am having some doubts regarding the use of SA byte lifetime. >Specifically for the case in which an SA bundle has been negotiated, say AH >and ESP, the number of bytes processed by the AH SA will be different from >the number of bytes processed by the ESP SA. Normally, for SA bundle case, >ESP packet is encapsulated by AH, so the number of bytes processed by the >AH SA will always be more than the ESP SA. So, in that case, the AH SA will >expire before the AH SA. Now the problem is : >1) Once the AH SA soft byte lifetime expires, should we : > a) negotiate for the bundle again.- In this we are assuming that the ESP >SA has also expired. > b) negotiate for AH SA only - In this case, how ? > >2) Once the AH SA hard byte lifetime has expired, should we delete the ESP >SA also. > >Thanks in Advance. > >Awan Kumar Sharma >Software Engg., >Future Software Ltd., >Chennai - India > > > 1) the answer is a) 2) of course. Please link SAs together and treat them as a unit. Somehow. Image a case where you have IPCOMP+ESP+AH. That's 6 SAs in total. Now you receive _one_ single delete notification for the, say, incoming ESP. What do you do? Delete just that SA? No, you delete all 6 SAs. Jörn From owner-ipsec@lists.tislabs.com Wed Sep 20 12:48:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05329; Wed, 20 Sep 2000 12:48:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23453 Wed, 20 Sep 2000 14:20:17 -0400 (EDT) Message-ID: <39C90206.77CFF007@isi.edu> Date: Wed, 20 Sep 2000 11:29:26 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Olivier Kreet CC: IP Security List Subject: Re: TOS copying considered harmful References: <10929.969091766@coconut.itojun.org> <39C6538D.824A2169@isi.edu> <39C71A97.EF6613F@sxb.bsf.alcatel.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Olivier Kreet wrote: > > Joe Touch wrote: > [...] > > > 2003bis should discuss the clearing of these bits as an option, and > > discuss the implications of using that option, precisely because it is > > needed, e.g., for 2401 (or 2401bis). > > > > Then 2401bis can refer back to 2003bis for the specification of the > > tunnel headers, and indicate that 'clearing the bits' may be required > > for security reasons, and that it can use exactly the header specified > > by 2003bis. > > > > Joe > > As stated in the first post of this discussion thread, besides security reasons, > clearing the TOS field may also be required when QoS is to be applied on the path > of the tunnel. The packet reordering may cause the anti-replay mechanism to > reject low prio packets that were (strongly) delayed due to QoS. See > draft-ietf-diffserv-tunnels-02.txt, section 5.1. > This is related to ESP and AH sequence numbers, that are specific to IPSec and > not an IP in IP encapsulation problem. This point should go to RFC2401, right? That specific point, yes. The fact that TOS may need to be cleared should go in 2003bis, including some reference as to why, but not necessarily that level of detail. Joe From owner-ipsec@lists.tislabs.com Wed Sep 20 18:48:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12342; Wed, 20 Sep 2000 18:48:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24740 Wed, 20 Sep 2000 20:20:52 -0400 (EDT) To: joern.sierwald@F-Secure.com Cc: ipsec@lists.tislabs.com Subject: Re: SA byte lifetime In-Reply-To: Your message of "Wed, 20 Sep 2000 17:39:27 +0200" <3.0.5.32.20000920173927.033cba30@smtp.datafellows.com> References: <3.0.5.32.20000920173927.033cba30@smtp.datafellows.com> X-Mailer: Cue version 0.6 (000609-1000/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20000921082341N.sakane@ydc.co.jp> Date: Thu, 21 Sep 2000 08:23:41 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Image a case where you have IPCOMP+ESP+AH. > That's 6 SAs in total. > Now you receive _one_ single delete notification for > the, say, incoming ESP. > What do you do? Delete just that SA? No, you delete all 6 SAs. In this case, it is better to send three delete notification. From owner-ipsec@lists.tislabs.com Thu Sep 21 01:49:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20564; Thu, 21 Sep 2000 01:49:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25579 Thu, 21 Sep 2000 03:10:50 -0400 (EDT) From: "Markku Savela" To: , Subject: RE: SA byte lifetime Date: Thu, 21 Sep 2000 10:21:41 +0300 Message-ID: <000001c0239c$97b13fa0$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <01C02340.46360B80.awank@future.futsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1) Once the AH SA soft byte lifetime expires, should we : > a) negotiate for the bundle again.- In this we are > assuming that the ESP > SA has also expired. > b) negotiate for AH SA only - In this case, how ? If using IKE as a key negotiation, it only supports (a), because current IKE implementations cannot negotiate "unbundled" SA's (nor SA's that could be shared between bundles). As far as RFC-2401 is concerned, both (a) and (b) could be possible. From owner-ipsec@lists.tislabs.com Thu Sep 21 08:14:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01308; Thu, 21 Sep 2000 08:14:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27107 Thu, 21 Sep 2000 09:30:33 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9752@eseis06nok> To: ipsec@lists.tislabs.com Subject: ISAKMP Delete Payload (2) Date: Thu, 21 Sep 2000 16:41:33 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, If IKE receives a Delete payload for an ISAKMP SA does it imply that the IPSEC SA negotiated by this ISAKMP SA must be deleted as well, or they can be left in use until they expire? Toni From owner-ipsec@lists.tislabs.com Thu Sep 21 09:16:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05771; Thu, 21 Sep 2000 09:16:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27411 Thu, 21 Sep 2000 10:49:21 -0400 (EDT) Message-ID: <39CA22B0.F1403932@F-Secure.com> Date: Thu, 21 Sep 2000 18:01:04 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shoichi 'Ne' Sakane" CC: joern.sierwald@F-Secure.com, ipsec@lists.tislabs.com Subject: deleting bundles (Re: SA byte lifetime) References: <3.0.5.32.20000920173927.033cba30@smtp.datafellows.com> <20000921082341N.sakane@ydc.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shoichi 'Ne' Sakane wrote: > > > Image a case where you have IPCOMP+ESP+AH. > > That's 6 SAs in total. > > Now you receive _one_ single delete notification for > > the, say, incoming ESP. > > What do you do? Delete just that SA? No, you delete all 6 SAs. > > In this case, it is better to send three delete notification. We were discussing this in the San Diego interop Wednesday. No consensus emerged, but here's what I think. Imagine AH/ESP/IPCOMP (IPCOMP innermost). It seems to me that a) you should forbid using IPCOMP without a preceeding AH or ESP header b) you might allow using well-known CPI values, using Hugh Redelmeyer's proposal of identifying the exact instance by the enclosing SA c) you shouldn't send delete notifications for IPCOMP SAs using well-known CPI values This might not be according to current RFCs, but it would work. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Sep 21 09:33:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06034; Thu, 21 Sep 2000 09:33:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27453 Thu, 21 Sep 2000 11:06:01 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9758@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: ISAKMP Delete Payload (2) Date: Thu, 21 Sep 2000 18:16:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds reasonable, however I thought about delaying slightly the expiration in case I receive a delete notification for an IPSEC SA AFTER receiving the one for the ISAKMP. I think it shouldn't happen but I've seen some implementation that for some reason do that. I simply set the ISAKMP as dead to be able to decode a possible late notification and destroy it after a small delay. Toni -----Original Message----- From: EXT Scott G. Kelly [mailto:skelly@redcreek.com] Sent: 21. September 2000 17:57 To: antonio.barrera@nokia.com Subject: Re: ISAKMP Delete Payload (2) antonio.barrera@nokia.com wrote: > > Hi, > If IKE receives a Delete payload for an ISAKMP SA does it imply that > the IPSEC SA negotiated by this ISAKMP SA must be deleted as well, or they > can be left in use until they expire? While this has been a somewhat contentious point in the past, I believe the consensus is that the IKE SAs and IPsec SAs are independent, and so the IPsec SAs are not automatically deleted when the IKE SAs are. Scott From owner-ipsec@lists.tislabs.com Thu Sep 21 09:45:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06594; Thu, 21 Sep 2000 09:45:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27492 Thu, 21 Sep 2000 11:20:50 -0400 (EDT) To: Ari Huttunen cc: "Shoichi 'Ne' Sakane" , joern.sierwald@F-Secure.com, ipsec@lists.tislabs.com In-reply-to: Ari.Huttunen's message of Thu, 21 Sep 2000 18:01:04 +0300. <39CA22B0.F1403932@F-Secure.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: deleting bundles (Re: SA byte lifetime) From: itojun@iijlab.net Date: Fri, 22 Sep 2000 00:31:40 +0900 Message-ID: <14289.969550300@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >We were discussing this in the San Diego interop Wednesday. No consensus >emerged, but here's what I think. > >Imagine AH/ESP/IPCOMP (IPCOMP innermost). It seems to me that >a) you should forbid using IPCOMP without a preceeding AH or ESP header my understanding is the opposite, I say IKE should not forbid it. having such knowledge into IKE protocol itself looks wrong to me. I don't think "IPCOMP must come with AH or ESP" belong to IKE spec, it belongs to elsewhere like your IKE policy. if you reject certain combination of phase 2 proposal based on your policy (or intentionally reject it), that's no problem for me. >b) you might allow using well-known CPI values, using Hugh Redelmeyer's > proposal of identifying the exact instance by the enclosing SA There were two strawpoll targets; (1) okay to negotiate with well-known CPI value, but don't negotiate lifetime and other attributes (2) identify IPCOMP with wellknown CPI as part of bundle. I would like to put another one: (3) for IKE negotiation wellknown CPI should not be used in IKE proposal, use >256 values. (3) looks similar to (1), but simpler. itojun From owner-ipsec@lists.tislabs.com Thu Sep 21 11:23:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08623; Thu, 21 Sep 2000 11:23:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27760 Thu, 21 Sep 2000 12:58:24 -0400 (EDT) Message-ID: <39CA40A3.E2E7B0E2@austin.ibm.com> Date: Thu, 21 Sep 2000 12:08:51 -0500 From: Parag Salvi Organization: IBM X-Mailer: Mozilla 4.51i [en_US] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: antonio.barrera@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: ISAKMP Delete Payload (2) References: <0B3F42CA1FB6D2118FE50008C7894B0A051A9752@eseis06nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think they (IPSEC SA) can be left in use until they expire. I don't see any security harm in doing so. Parag Salvi IBM AIX IPSecurity. antonio.barrera@nokia.com wrote: > Hi, > If IKE receives a Delete payload for an ISAKMP SA does it imply that > the IPSEC SA negotiated by this ISAKMP SA must be deleted as well, or they > can be left in use until they expire? > > Toni From owner-ipsec@lists.tislabs.com Thu Sep 21 14:17:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11208; Thu, 21 Sep 2000 14:17:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28298 Thu, 21 Sep 2000 15:46:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20000921155311.00b62138@localhost> X-Sender: mmilbach@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 15:55:03 -0400 To: ipsec@lists.tislabs.com From: Michael Milbach Subject: ipsec and win2k Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can anyone please point me to some documentation on IPsec Tunneling between to win2k boxes. I already have been through M$'s support, and have some information, but the one Tunneling example given is for one unique circumstance with little explanation. Any direction would be appreciated. TIA Michael ******************* Michael Milbach Mentor Technologies Group Cell: 240-460-0073 Office: 301-680-3562 ******************* Mentor Technologies Group: We're high tech, high touch, high performance; the total learning solutions company. From owner-ipsec@lists.tislabs.com Thu Sep 21 15:21:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12558; Thu, 21 Sep 2000 15:21:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28531 Thu, 21 Sep 2000 17:13:11 -0400 (EDT) Date: Thu, 21 Sep 2000 17:23:20 -0400 (EDT) From: Henry Spencer To: antonio.barrera@nokia.com cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP Delete Payload (2) In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A9752@eseis06nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 21 Sep 2000 antonio.barrera@nokia.com wrote: > If IKE receives a Delete payload for an ISAKMP SA does it imply that > the IPSEC SA negotiated by this ISAKMP SA must be deleted as well, or they > can be left in use until they expire? Generally, the latter. In particular, identity PFS (section 8 of RFC 2409) *requires* that IPsec SAs persist beyond the ISAKMP SA used to create them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Sep 26 09:07:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23147; Tue, 26 Sep 2000 09:07:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14728 Tue, 26 Sep 2000 10:15:03 -0400 (EDT) Message-ID: <001a01c027c6$24c063d0$0101a8c0@mv.lucent.com> From: "David W. Faucher" To: Subject: QM optional payloads Date: Tue, 26 Sep 2000 09:28:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This came up at the San Diego bakeoff. Are optional payloads covered by the HASH3 payload in a quick mode exchange? If commit bit processing is used, are they covered by HASH4? The text for HASH1 and HASH2 explicitly states that it covers the entire message but no such text exists for HASH3 (and HASH4). thanks, Dave Faucher From owner-ipsec@lists.tislabs.com Tue Sep 26 11:51:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26182; Tue, 26 Sep 2000 11:51:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15709 Tue, 26 Sep 2000 13:39:30 -0400 (EDT) Message-ID: <002601c027e2$05628a10$2c2745ab@cisco.com> From: "Scott Fanning" To: "'IPsec List'" Subject: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 10:48:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C027A7.58DFD660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C027A7.58DFD660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, I thought I would start a thread on one issue that came up at the = VPN Workshop, and that is the usage of the CERT_REQ_PAYLOAD or CRP. RFC 2408 states The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. =20 and If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. =20 The behaviour I saw was one of the following. 1) Initiator sends CRP per cert required, and responder replies with the = appropriate certificates. 2) Initiator sends 1 CRP, and the responder sends all certs. 3) Initiator does not send CRP, but wants all certs because RSA was = negotiated. I am sure there are others. I would like to recommend that option 1 is = the best option, and the simplest. This has caused many interop issues, = and the vague wording does not help. I would like to tighten up the = rules if possible. Comments? Regards Scott Fanning ------=_NextPart_000_0023_01C027A7.58DFD660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Well, I thought I would start a thread = on one issue=20 that came up at the VPN Workshop, and that is the usage of the = CERT_REQ_PAYLOAD=20 or CRP.
 
RFC 2408 states
 
   The Certificate Request = Payload=20 provides a means to request
   certificates via ISAKMP and = can=20 appear in any message.  Certificate
   Request = payloads SHOULD=20 be included in an exchange whenever an
   appropriate = directory=20 service (e.g.  Secure DNS [DNSSEC]) is not
   = available to=20 distribute certificates. 
 
and
 
  If multiple certificates are=20 required,
   then multiple Certificate Request payloads = SHOULD be=20 transmitted.
  
 
The behaviour I saw was one of the=20 following.
 
1) Initiator sends CRP per cert = required, and=20 responder replies with the appropriate certificates.
 
2) Initiator sends 1 CRP, and the = responder sends=20 all certs.
 
3) Initiator does not send CRP, but = wants all certs=20 because RSA was negotiated.
 
I am sure there are others. I would = like to=20 recommend that option 1 is the best option, and the simplest. This has = caused=20 many interop issues, and the vague wording does not help. I would like = to=20 tighten up the rules if possible.
 
Comments?
 
Regards
Scott = Fanning
------=_NextPart_000_0023_01C027A7.58DFD660-- From owner-ipsec@lists.tislabs.com Tue Sep 26 14:43:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01475; Tue, 26 Sep 2000 14:43:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16124 Tue, 26 Sep 2000 16:22:34 -0400 (EDT) Date: Tue, 26 Sep 2000 23:33:42 +0300 (EET DST) Message-Id: <200009262033.XAA26987@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: "David W. Faucher" Cc: Subject: QM optional payloads In-Reply-To: <001a01c027c6$24c063d0$0101a8c0@mv.lucent.com> References: <001a01c027c6$24c063d0$0101a8c0@mv.lucent.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David W. Faucher writes: > Are optional payloads covered by the HASH3 payload > in a quick mode exchange? The RFC is quite clear that the HASH(3) only contains value zero, message id, and two nonces. It does not contain anything from the actual final packet itself. So I think it currently does not include any extra payloads you might put in the third message. > If commit bit processing is used, are they covered by HASH4? There is no HASH(4) in that case. There will be normal HASH of rest of the payloads, so that will include all payloads included in the packet. > The text for HASH1 and HASH2 explicitly states that > it covers the entire message but no such text exists > for HASH3 (and HASH4). The text doesn't say anything about HASH(4), and it doesn't even say if the notification is going to be sent as part of quick mode or as a separate informational exchange. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 26 14:43:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01495; Tue, 26 Sep 2000 14:43:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16171 Tue, 26 Sep 2000 16:32:32 -0400 (EDT) Message-ID: <5F235E8F67EAD311993200D0B708A6D80E8FE5@email.rapidstream.com> From: kaijun gu To: "'Scott Fanning'" , "'IPsec List'" Subject: RE: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 13:42:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C027FA.5A952A2A" 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_01C027FA.5A952A2A Content-Type: text/plain; charset="iso-8859-1" In my opinion, CRP provides a way to establish a trusted CA domain so that both the initiator and responder can understand they have the ability to validate the certificate send over through the certificate payload. As the initiator, if it has multiple certificates issued by different CA's, it SHOULD send multiple CRPs which contain the different CA DN. As a responder, when it receives the CRPs, it SHOULD check if it holds any certificate issued by those CA's, then it has the option to send the certificates which may be validated by initiator. Otherwise, a certificate received in the certificate payload may not be validated because the other party doesn't have the right CA certificate. Regards! Kaijun -----Original Message----- From: Scott Fanning [mailto:sfanning@cisco.com] Sent: Tuesday, September 26, 2000 10:49 AM To: 'IPsec List' Subject: CERT_REQ_PAYLOAD usage Well, I thought I would start a thread on one issue that came up at the VPN Workshop, and that is the usage of the CERT_REQ_PAYLOAD or CRP. RFC 2408 states The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. and If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. The behaviour I saw was one of the following. 1) Initiator sends CRP per cert required, and responder replies with the appropriate certificates. 2) Initiator sends 1 CRP, and the responder sends all certs. 3) Initiator does not send CRP, but wants all certs because RSA was negotiated. I am sure there are others. I would like to recommend that option 1 is the best option, and the simplest. This has caused many interop issues, and the vague wording does not help. I would like to tighten up the rules if possible. Comments? Regards Scott Fanning ------_=_NextPart_001_01C027FA.5A952A2A Content-Type: text/html; charset="iso-8859-1"
In my opinion, CRP provides a way to establish a trusted CA domain so that both the initiator and responder can understand they have the ability to validate the certificate send over through the certificate payload. As the initiator, if it has multiple certificates issued by different CA's, it SHOULD send multiple CRPs which contain the different CA DN. As a responder, when it receives the CRPs, it SHOULD check if it holds any certificate issued by those CA's, then it has the option to send the certificates which may be validated by initiator. Otherwise, a certificate received in the certificate payload may not be validated because the other party doesn't have the right CA certificate.
 
Regards!
Kaijun
-----Original Message-----
From: Scott Fanning [mailto:sfanning@cisco.com]
Sent: Tuesday, September 26, 2000 10:49 AM
To: 'IPsec List'
Subject: CERT_REQ_PAYLOAD usage

 
Well, I thought I would start a thread on one issue that came up at the VPN Workshop, and that is the usage of the CERT_REQ_PAYLOAD or CRP.
 
RFC 2408 states
 
   The Certificate Request Payload provides a means to request
   certificates via ISAKMP and can appear in any message.  Certificate
   Request payloads SHOULD be included in an exchange whenever an
   appropriate directory service (e.g.  Secure DNS [DNSSEC]) is not
   available to distribute certificates. 
 
and
 
  If multiple certificates are required,
   then multiple Certificate Request payloads SHOULD be transmitted.
  
 
The behaviour I saw was one of the following.
 
1) Initiator sends CRP per cert required, and responder replies with the appropriate certificates.
 
2) Initiator sends 1 CRP, and the responder sends all certs.
 
3) Initiator does not send CRP, but wants all certs because RSA was negotiated.
 
I am sure there are others. I would like to recommend that option 1 is the best option, and the simplest. This has caused many interop issues, and the vague wording does not help. I would like to tighten up the rules if possible.
 
Comments?
 
Regards
Scott Fanning
------_=_NextPart_001_01C027FA.5A952A2A-- From owner-ipsec@lists.tislabs.com Tue Sep 26 14:43:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01509; Tue, 26 Sep 2000 14:43:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16198 Tue, 26 Sep 2000 16:35:47 -0400 (EDT) Date: Tue, 26 Sep 2000 23:47:00 +0300 (EET DST) Message-Id: <200009262047.XAA10637@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: "Scott Fanning" Cc: "'IPsec List'" Subject: CERT_REQ_PAYLOAD usage In-Reply-To: <002601c027e2$05628a10$2c2745ab@cisco.com> References: <002601c027e2$05628a10$2c2745ab@cisco.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fanning writes: > RFC 2408 states > > The Certificate Request Payload provides a means to request > certificates via ISAKMP and can appear in any message. Certificate > Request payloads SHOULD be included in an exchange whenever an > appropriate directory service (e.g. Secure DNS [DNSSEC]) is not > available to distribute certificates. > > and > > If multiple certificates are required, > then multiple Certificate Request payloads SHOULD be transmitted. The RFC 2408 also says: ---------------------------------------------------------------------- 3.9 Certificate Payload ... Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload. ... ---------------------------------------------------------------------- > The behaviour I saw was one of the following. > 1) Initiator sends CRP per cert required, and responder replies with > the appropriate certificates. This is propably the best approach. > 2) Initiator sends 1 CRP, and the responder sends all certs. This is same as case 1, except the responder also choose to send some extra certificates that it think might be usefull for the initiator. There are some usages for this, for example it might send encryption capable certificate also in signature authentication just to preload that certificate to initiator, so the initiator can use rsa encryption next time. > 3) Initiator does not send CRP, but wants all certs because RSA was > negotiated. This I think is bad. If you dont send certificate request payload at all that should mean that you don't want to have any certificates, you think you already have the ones needed. The responder might still send you a certificate just in case in some cases. For example the responder might send it certificate to you if it just enrolled new one and is going to use that one instead of the old one that the initiator has. > I am sure there are others. I would like to recommend that option 1 > is the best option, and the simplest. This has caused many interop > issues, and the vague wording does not help. I would like to tighten > up the rules if possible. I would think the rules will be: 1) If you absolutely need certificates from the other side for the authentication to work, you MUST send certificate request payload. 2) If the authentication can succeed without the other end sending certificates (you have some certificate for the other end, or you can fetch the certificate from the certificate repository), you MAY send certificate request. 3) If you just want any certificate without specifying the CA root, send certificate request having empty CA name. 4) When you receive certificate request you MUST send your own certificate for that CA. 5) If you receive empty certificate request you MUST send the certificate you are going use in the authentication. If you have multiple certificates for the same private key, you SHOULD send all of them. 6) If you do not receive certificate request, you SHOULD NOT send any certificates, unless you have reason to belive that the other end has wrong certificate for you (for example you have enrolled a new certificate recently). 7) You MAY include extra certificates, CRLs etc if you have them available (I.e include your other certificates also (certificate pre-loading), include sub-CA certificates, include CRLs etc. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 26 17:00:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03707; Tue, 26 Sep 2000 17:00:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16648 Tue, 26 Sep 2000 18:53:56 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 16:04:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0280E.1C8564F2" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC609@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAn/EI2xu2wjDiuR1WLASSgZ+3+AAADaAsA From: "William Dixon" To: "kaijun gu" , "Scott Fanning" , "IPsec List" X-OriginalArrivalTime: 26 Sep 2000 23:04:00.0746 (UTC) FILETIME=[0EB044A0:01C0280E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0280E.1C8564F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, my comments on CRPs below, but before agreeing on CRPs, we really should agree on end-entity certs. The result of the bakeoff was that people didn't want to do that, even minimally which is really unfortunate. Rodney's, Paul & Charles' draft tried to get some sanity defined, which included at least in which exchanges CRPs were sent. Perhaps we can weed out what is contentious and agree on a few things. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-05.txt =20 =20 Unfortunately the IKE peers have no way to indicate that they need more than one end-entity certificate, or to indicate a particular type of cert or content in the end-entity cert. There is also no way for the gateway to tell a client that it needs extra non-identity based certs - like attribute certs for gateway authorization. =20 The convention I know is: simply send CRPs to request the peer send you back an end-entity cert that chains to that root. You are not limited on what you can send, send whatever CRP you want, including a CRPs for the same root twice, and for a root that you yourself don't trust - the latter case is required to support certificate validations when cross-certs have been issued. =20 The peer may reply by sending all certs that chain to 1 root if there are multiple certs, the peer may send only 1 end-entity cert. The peer may send one or all certs for each CRP providing they exist. And the peer may send an end-entity cert that didn't chain to any of your CRP roots. The only real limitation appears to be how much will fit into a UDP payload - since there is a define place to send Certs in the ID payload - at least in IKE Identity Protect Mode (Main Mode). Up to you if you want to create a UDP packet big enough that it will fragment - so the FW's & routers doing port filtering allowing only port 500 can have fun tracking fragments if they allow them at all. =20 The problem with your option #1 is that you may truly require only 1 end-entity cert to authenticate main mode - but you SHOULD send multiple CRPs so there is a higher likelihood that the peer can find one valid end-entity cert that chains to one of the roots. A gateway which is servicing Internet clients from multiple PKI domains will have to send one CRP for each PKI domain to each client, unless you somehow know that only certain PKI domain clients are coming from some range of IP addresses, or use the MM ID payload to determine which PKI domain the client might be a member of. Alternately, the clients could just ignore all the gateway CRPs and send the only end-entity cert they have which the gateway will validate. But which cert will the gateway send the client? Obviously only one which the client can validate. So the client needs to tell the gateway which PKI domain he can validate, which means sending at least one CRP to the gateway - since the gateway may have end-entity certs issued from each PKI domain. =20 Wm -----Original Message----- From: kaijun gu [mailto:kaijun_gu@rapidstream.com] Sent: Tuesday, September 26, 2000 1:43 PM To: 'Scott Fanning'; 'IPsec List' Subject: RE: CERT_REQ_PAYLOAD usage In my opinion, CRP provides a way to establish a trusted CA domain so that both the initiator and responder can understand they have the ability to validate the certificate send over through the certificate payload. As the initiator, if it has multiple certificates issued by different CA's, it SHOULD send multiple CRPs which contain the different CA DN. As a responder, when it receives the CRPs, it SHOULD check if it holds any certificate issued by those CA's, then it has the option to send the certificates which may be validated by initiator. Otherwise, a certificate received in the certificate payload may not be validated because the other party doesn't have the right CA certificate. =20 Regards! Kaijun -----Original Message----- From: Scott Fanning [mailto:sfanning@cisco.com] Sent: Tuesday, September 26, 2000 10:49 AM To: 'IPsec List' Subject: CERT_REQ_PAYLOAD usage =20 Well, I thought I would start a thread on one issue that came up at the VPN Workshop, and that is the usage of the CERT_REQ_PAYLOAD or CRP. =20 RFC 2408 states =20 The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. =20 =20 and =20 If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. =20 =20 The behaviour I saw was one of the following. =20 1) Initiator sends CRP per cert required, and responder replies with the appropriate certificates. =20 2) Initiator sends 1 CRP, and the responder sends all certs. =20 3) Initiator does not send CRP, but wants all certs because RSA was negotiated. =20 I am sure there are others. I would like to recommend that option 1 is the best option, and the simplest. This has caused many interop issues, and the vague wording does not help. I would like to tighten up the rules if possible. =20 Comments? =20 Regards Scott Fanning ------_=_NextPart_001_01C0280E.1C8564F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Scott,=20 my comments on CRPs below, but before agreeing on CRPs, we really=20 should agree on end-entity certs.  The result of the bakeoff = was that=20 people didn't want to do that, even minimally which is really = unfortunate. =20 Rodney's, Paul & Charles' draft tried to get some sanity = defined, which=20 included at least in which exchanges CRPs were sent.  Perhaps = we can=20 weed out what is contentious and agree on a few = things.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-05.txt
 
Unfortunately the IKE peers have no way = to=20 indicate that they need more than one end-entity certificate, or to = indicate a particular type of cert or content in the end-entity = cert. =20 There is also no way for the gateway to tell a client that = it needs=20 extra non-identity based certs - like attribute certs for gateway=20 authorization.
 
The=20 convention I know is: simply send CRPs to request the peer send you = back an=20 end-entity cert that chains to that root.  You are not limited on what = you can=20 send, send whatever CRP you want, including a CRPs for the same = root twice,=20 and for a root that you yourself don't trust - the latter case is = required=20 to support certificate validations when cross-certs have been=20 issued.
 
The=20 peer may reply by sending all certs that chain to 1 root if there are = multiple=20 certs, the peer may send only 1 end-entity cert.  The peer may=20 send one or all certs for each CRP providing they exist.  And = the peer=20 may send an end-entity cert that didn't chain to any of your CRP = roots. =20 The only real limitation appears to be how much will fit into a UDP = payload -=20 since there is a define place to send Certs in the ID payload - at least = in IKE=20 Identity Protect Mode (Main Mode).  Up to you if you want to create = a UDP=20 packet big enough that it will fragment - so the FW's & routers = doing port=20 filtering allowing only port 500 can have fun tracking fragments if they = allow=20 them at all.
 
The=20 problem with your option #1 is that you may truly require only 1 = end-entity cert=20 to authenticate main mode - but you SHOULD send multiple CRPs so there = is a=20 higher likelihood that the peer can find one valid end-entity cert that = chains=20 to one of the roots.  A gateway which is servicing Internet clients = from=20 multiple PKI domains will have to send one CRP for each PKI = domain to each=20 client, unless you somehow know that only certain PKI domain clients are = coming=20 from some range of IP addresses, or use the MM ID payload to determine = which PKI=20 domain the client might be a member of.  Alternately, the clients = could=20 just ignore all the gateway CRPs and send the only end-entity cert they = have=20 which the gateway will validate.  But which cert will the gateway = send the=20 client?  Obviously only one which the client can validate. =20 So the client needs to tell the gateway which PKI domain he can = validate,=20 which means sending at least one CRP to the gateway - since the gateway = may have=20 end-entity certs issued from each PKI domain.
 
Wm
-----Original Message-----
From: kaijun gu=20 [mailto:kaijun_gu@rapidstream.com]
Sent: Tuesday, September = 26, 2000=20 1:43 PM
To: 'Scott Fanning'; 'IPsec List'
Subject: = RE:=20 CERT_REQ_PAYLOAD usage

In=20 my opinion, CRP provides a way to establish a trusted CA domain so = that both=20 the initiator and responder can understand they have the ability to = validate=20 the certificate send over through the certificate payload. As the = initiator,=20 if it has multiple certificates issued by different CA's, it SHOULD = send=20 multiple CRPs which contain the different CA DN. As a responder, when = it=20 receives the CRPs, it SHOULD check if it holds any certificate issued = by those=20 CA's, then it has the option to send the certificates which may be = validated=20 by initiator. Otherwise, a certificate received in the certificate = payload may=20 not be validated because the other party doesn't have the right CA=20 certificate.
 
Regards!
Kaijun
-----Original Message-----
From: Scott Fanning=20 [mailto:sfanning@cisco.com]
Sent: Tuesday, September 26, = 2000=20 10:49 AM
To: 'IPsec List'
Subject: = CERT_REQ_PAYLOAD=20 usage

 
Well, I thought I would start a = thread on one=20 issue that came up at the VPN Workshop, and that is the usage of the = CERT_REQ_PAYLOAD or CRP.
 
RFC 2408 states
 
   The Certificate = Request Payload=20 provides a means to request
   certificates via ISAKMP = and can=20 appear in any message.  Certificate
   Request = payloads=20 SHOULD be included in an exchange whenever an
   = appropriate=20 directory service (e.g.  Secure DNS [DNSSEC]) is = not
  =20 available to distribute certificates. 
 
and
 
  If multiple certificates are = required,
   then multiple Certificate Request payloads = SHOULD=20 be transmitted.
  
 
The behaviour I saw was one of the=20 following.
 
1) Initiator sends CRP per cert = required, and=20 responder replies with the appropriate certificates.
 
2) Initiator sends 1 CRP, and the = responder=20 sends all certs.
 
3) Initiator does not send CRP, but = wants all=20 certs because RSA was negotiated.
 
I am sure there are others. I would = like to=20 recommend that option 1 is the best option, and the simplest. This = has=20 caused many interop issues, and the vague wording does not help. I = would=20 like to tighten up the rules if possible.
 
Comments?
 
Regards
Scott=20 Fanning
------_=_NextPart_001_01C0280E.1C8564F2-- From owner-ipsec@lists.tislabs.com Tue Sep 26 17:19:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04011; Tue, 26 Sep 2000 17:19:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16750 Tue, 26 Sep 2000 19:20:10 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 16:30:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02811.B1910440" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC60A@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAn/JVEjdweSxv8TGu56cmUn+CyygAEcIlA From: "William Dixon" To: "Tero Kivinen" , "Scott Fanning" Cc: "IPsec List" X-OriginalArrivalTime: 26 Sep 2000 23:29:39.0915 (UTC) FILETIME=[A41AD1B0:01C02811] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C02811.B1910440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tero, good ideas, one issue though: 4) When you receive certificate request you MUST send your own certificate for that CA. Your own IPSec policy typically includes what roots to use or what certs to send - so you have to enforce that, regardless of what the peer sends you. If the CRP's don't match the roots you are configured to use, then you are saying here you MUST fail. And that means that the peer MUST send a correct CRP for the credential you have - which of course isn't always possible. ------_=_NextPart_001_01C02811.B1910440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CERT_REQ_PAYLOAD usage

Tero, good ideas, one issue though:

        4) When you = receive certificate request you MUST send your own
        certificate for that CA.

Your own IPSec policy typically includes what roots to = use or what certs to send - so you have to enforce that, regardless of = what the peer sends you.  If the CRP's don't match the roots you = are configured to use, then you are saying here you MUST fail.  And = that means that the peer MUST send a correct CRP for the credential you = have - which of course isn't always possible.


------_=_NextPart_001_01C02811.B1910440-- From owner-ipsec@lists.tislabs.com Tue Sep 26 17:37:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04525; Tue, 26 Sep 2000 17:37:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16799 Tue, 26 Sep 2000 19:40:38 -0400 (EDT) Date: Tue, 26 Sep 2000 16:50:47 -0700 (PDT) From: Jan Vilhuber To: William Dixon cc: Tero Kivinen , Scott Fanning , IPsec List Subject: RE: CERT_REQ_PAYLOAD usage In-Reply-To: <6A05D00595BE644E9F435BE5947423F2FFC60A@fifi.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 26 Sep 2000, William Dixon wrote: > Tero, good ideas, one issue though: > > 4) When you receive certificate request you MUST send your own > certificate for that CA. > > Your own IPSec policy typically includes what roots to use or what certs > to send - so you have to enforce that, regardless of what the peer sends > you. If the CRP's don't match the roots you are configured to use, then > you are saying here you MUST fail. And that means that the peer MUST > send a correct CRP for the credential you have - which of course isn't > always possible. > Not sure I follow that: Why is this not possible? Common sense tells me that I should send a CRP for ALL roots I know about (or all roots that I'm allowed to use by some obscure local policy, or whatever). If you answer with the ones that YOU have, we've got a non-empty intersection. If there's no overlap, then the intersection IS empty, and we must fail, because we don't share a root. Is there something I'm missing? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Sep 26 17:41:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04577; Tue, 26 Sep 2000 17:41:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16776 Tue, 26 Sep 2000 19:36:09 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02812.2D148B7B" Subject: RE: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 16:33:29 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740C5F09@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAoEBKDtuZU7MzPQkKCQrMUGsOgpQAASZ0A From: "Brian Swander" To: "William Dixon" , "kaijun gu" , "Scott Fanning" , "IPsec List" X-OriginalArrivalTime: 26 Sep 2000 23:46:18.0633 (UTC) FILETIME=[F7631790:01C02813] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C02812.2D148B7B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unless I'm missing something, it seems pretty hacky to send multiple end entity cert chains. Say my peer sends me 3 CRPs for different roots, root A,B,C. I have 3 cert chains that chain to these roots. Chain1: A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0, and C0 are the end entity certs. =20 Say I send all of these certs in random order (A0,B1,A1,B0,C0 etc). Now, the peer has to pick out the chains, and piece them back together. Worse yet, I also have to send 3 sig payloads since in general A0,B0 and C0 will all have different private keys. There is no way in IKE to map the chain to the sig payload, so IKE has to guess what the chains are, guess what the end entity certs are, and go with trial and error to find the correct sig payloads. =20 =20 Thus, sending a single chain and a single sig payload seem to me to be the only reasonable alternative. Of course, if we mandated that people sent an individual chain as its own PKCS7 and that all end entity certs MUST have the basic constraint saying that they are end entity, and defined some way in IKE to map PKCS blobs to sig payloads (maybe with mandatory payload ordering), then perhaps we could build an interoperable way to send multiple chains. But as William points out, we'd still have the problem of fragmented IKE payloads. =20 bs -----Original Message----- From: William Dixon=20 Sent: Tuesday, September 26, 2000 4:04 PM To: kaijun gu; Scott Fanning; IPsec List Subject: RE: CERT_REQ_PAYLOAD usage Scott, my comments on CRPs below, but before agreeing on CRPs, we really should agree on end-entity certs. The result of the bakeoff was that people didn't want to do that, even minimally which is really unfortunate. Rodney's, Paul & Charles' draft tried to get some sanity defined, which included at least in which exchanges CRPs were sent. Perhaps we can weed out what is contentious and agree on a few things. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-05.txt =20 =20 Unfortunately the IKE peers have no way to indicate that they need more than one end-entity certificate, or to indicate a particular type of cert or content in the end-entity cert. There is also no way for the gateway to tell a client that it needs extra non-identity based certs - like attribute certs for gateway authorization. =20 The convention I know is: simply send CRPs to request the peer send you back an end-entity cert that chains to that root. You are not limited on what you can send, send whatever CRP you want, including a CRPs for the same root twice, and for a root that you yourself don't trust - the latter case is required to support certificate validations when cross-certs have been issued. =20 The peer may reply by sending all certs that chain to 1 root if there are multiple certs, the peer may send only 1 end-entity cert. The peer may send one or all certs for each CRP providing they exist. And the peer may send an end-entity cert that didn't chain to any of your CRP roots. The only real limitation appears to be how much will fit into a UDP payload - since there is a define place to send Certs in the ID payload - at least in IKE Identity Protect Mode (Main Mode). Up to you if you want to create a UDP packet big enough that it will fragment - so the FW's & routers doing port filtering allowing only port 500 can have fun tracking fragments if they allow them at all. =20 The problem with your option #1 is that you may truly require only 1 end-entity cert to authenticate main mode - but you SHOULD send multiple CRPs so there is a higher likelihood that the peer can find one valid end-entity cert that chains to one of the roots. A gateway which is servicing Internet clients from multiple PKI domains will have to send one CRP for each PKI domain to each client, unless you somehow know that only certain PKI domain clients are coming from some range of IP addresses, or use the MM ID payload to determine which PKI domain the client might be a member of. Alternately, the clients could just ignore all the gateway CRPs and send the only end-entity cert they have which the gateway will validate. But which cert will the gateway send the client? Obviously only one which the client can validate. So the client needs to tell the gateway which PKI domain he can validate, which means sending at least one CRP to the gateway - since the gateway may have end-entity certs issued from each PKI domain. =20 Wm -----Original Message----- From: kaijun gu [mailto:kaijun_gu@rapidstream.com] Sent: Tuesday, September 26, 2000 1:43 PM To: 'Scott Fanning'; 'IPsec List' Subject: RE: CERT_REQ_PAYLOAD usage In my opinion, CRP provides a way to establish a trusted CA domain so that both the initiator and responder can understand they have the ability to validate the certificate send over through the certificate payload. As the initiator, if it has multiple certificates issued by different CA's, it SHOULD send multiple CRPs which contain the different CA DN. As a responder, when it receives the CRPs, it SHOULD check if it holds any certificate issued by those CA's, then it has the option to send the certificates which may be validated by initiator. Otherwise, a certificate received in the certificate payload may not be validated because the other party doesn't have the right CA certificate. =20 Regards! Kaijun -----Original Message----- From: Scott Fanning [mailto:sfanning@cisco.com] Sent: Tuesday, September 26, 2000 10:49 AM To: 'IPsec List' Subject: CERT_REQ_PAYLOAD usage =20 Well, I thought I would start a thread on one issue that came up at the VPN Workshop, and that is the usage of the CERT_REQ_PAYLOAD or CRP. =20 RFC 2408 states =20 The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. =20 =20 and =20 If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. =20 =20 The behaviour I saw was one of the following. =20 1) Initiator sends CRP per cert required, and responder replies with the appropriate certificates. =20 2) Initiator sends 1 CRP, and the responder sends all certs. =20 3) Initiator does not send CRP, but wants all certs because RSA was negotiated. =20 I am sure there are others. I would like to recommend that option 1 is the best option, and the simplest. This has caused many interop issues, and the vague wording does not help. I would like to tighten up the rules if possible. =20 Comments? =20 Regards Scott Fanning ------_=_NextPart_001_01C02812.2D148B7B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unless=20 I'm missing something, it seems pretty hacky to send multiple end entity = cert=20 chains.  Say my peer sends me 3 CRPs for different roots, root = A,B,C. =20 I have 3 cert chains that chain to these roots.  Chain1: =20 A0,A1,A  Chain2: B0,B1,B2,B  Chain3:  C0,C1,C  where = A0, B0,=20 and C0 are the end entity certs.
 
Say I=20 send all of these certs in random order (A0,B1,A1,B0,C0 etc).  Now, = the=20 peer has to pick out the chains, and piece them back together.  = Worse yet,=20 I also have to send 3 sig payloads since in general A0,B0 and C0 will = all have=20 different private keys.  There is no way in IKE to map the chain to = the sig=20 payload, so IKE has to guess what the chains are, guess what the end = entity=20 certs are, and go with trial and error to find the correct sig = payloads. =20
 
Thus,=20 sending a single chain and a single sig payload seem to me to be = the only=20 reasonable alternative.  Of course, if we mandated that people sent = an=20 individual chain as its own PKCS7 and that all end entity certs MUST = have the=20 basic constraint saying that they are end entity, and defined some way = in IKE to=20 map PKCS blobs to sig payloads (maybe with mandatory payload ordering), = then=20 perhaps we could build an interoperable way to send multiple = chains.  But=20 as William points out, we'd still have the problem of fragmented IKE=20 payloads.
 
bs
-----Original Message-----
From: William Dixon=20
Sent: Tuesday, September 26, 2000 4:04 PM
To: = kaijun gu;=20 Scott Fanning; IPsec List
Subject: RE: CERT_REQ_PAYLOAD=20 usage

Scott, my comments on CRPs below, but = before agreeing=20 on CRPs, we really should agree on end-entity certs.  The = result of=20 the bakeoff was that people didn't want to do that, even minimally = which is=20 really unfortunate.  Rodney's, Paul & Charles' draft = tried to=20 get some sanity defined, which included at least in which = exchanges CRPs=20 were sent.  Perhaps we can weed out what is contentious and agree = on a=20 few things.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-05.txt
 
Unfortunately the IKE peers have no = way to=20 indicate that they need more than one end-entity certificate, or = to=20 indicate a particular type of cert or content in the end-entity = cert. =20 There is also no way for the gateway to tell a client that = it needs=20 extra non-identity based certs - like attribute certs for gateway = authorization.
 
The=20 convention I know is: simply send CRPs to request the peer send = you back=20 an end-entity cert that chains to that root.  You are not = limited on what=20 you can send, send whatever CRP you want, including a CRPs for = the same=20 root twice, and for a root that you yourself don't trust - the latter=20 case is required to support certificate validations when = cross-certs have=20 been issued.
 
The=20 peer may reply by sending all certs that chain to 1 root if there are = multiple=20 certs, the peer may send only 1 end-entity cert.  The peer may=20 send one or all certs for each CRP providing they exist.  = And the=20 peer may send an end-entity cert that didn't chain to any of your CRP=20 roots.  The only real limitation appears to be how much will fit = into a=20 UDP payload - since there is a define place to send Certs in the ID = payload -=20 at least in IKE Identity Protect Mode (Main Mode).  Up to you if = you want=20 to create a UDP packet big enough that it will fragment - so the FW's = &=20 routers doing port filtering allowing only port 500 can have fun = tracking=20 fragments if they allow them at all.
 
The=20 problem with your option #1 is that you may truly require only 1 = end-entity=20 cert to authenticate main mode - but you SHOULD send multiple CRPs so = there is=20 a higher likelihood that the peer can find one valid end-entity cert = that=20 chains to one of the roots.  A gateway which is servicing = Internet=20 clients from multiple PKI domains will have to send one CRP for each = PKI=20 domain to each client, unless you somehow know that only certain = PKI=20 domain clients are coming from some range of IP addresses, or use the = MM ID=20 payload to determine which PKI domain the client might be a member = of. =20 Alternately, the clients could just ignore all the gateway CRPs and = send the=20 only end-entity cert they have which the gateway will validate.  = But=20 which cert will the gateway send the client?  Obviously only one = which=20 the client can validate.  So the client needs to tell the = gateway=20 which PKI domain he can validate, which means sending at least one CRP = to the=20 gateway - since the gateway may have end-entity certs issued from each = PKI=20 domain.
 
Wm
-----Original Message-----
From: kaijun gu=20 [mailto:kaijun_gu@rapidstream.com]
Sent: Tuesday, = September 26,=20 2000 1:43 PM
To: 'Scott Fanning'; 'IPsec = List'
Subject:=20 RE: CERT_REQ_PAYLOAD usage

In=20 my opinion, CRP provides a way to establish a trusted CA domain so = that both=20 the initiator and responder can understand they have the ability to = validate=20 the certificate send over through the certificate payload. As the = initiator,=20 if it has multiple certificates issued by different CA's, it SHOULD = send=20 multiple CRPs which contain the different CA DN. As a responder, = when it=20 receives the CRPs, it SHOULD check if it holds any certificate = issued by=20 those CA's, then it has the option to send the certificates which = may be=20 validated by initiator. Otherwise, a certificate received in the = certificate=20 payload may not be validated because the other party doesn't have = the right=20 CA certificate.
 
Regards!
Kaijun
-----Original Message-----
From: Scott Fanning=20 [mailto:sfanning@cisco.com]
Sent: Tuesday, September 26, = 2000=20 10:49 AM
To: 'IPsec List'
Subject: = CERT_REQ_PAYLOAD=20 usage

 
Well, I thought I would start a = thread on one=20 issue that came up at the VPN Workshop, and that is the usage of = the=20 CERT_REQ_PAYLOAD or CRP.
 
RFC 2408 states
 
   The Certificate = Request Payload=20 provides a means to request
   certificates via = ISAKMP and=20 can appear in any message.  Certificate
   = Request=20 payloads SHOULD be included in an exchange whenever = an
  =20 appropriate directory service (e.g.  Secure DNS [DNSSEC]) is=20 not
   available to distribute certificates. =20
 
and
 
  If multiple certificates = are=20 required,
   then multiple Certificate Request = payloads=20 SHOULD be transmitted.
  
 
The behaviour I saw was one of = the=20 following.
 
1) Initiator sends CRP per cert = required, and=20 responder replies with the appropriate certificates.
 
2) Initiator sends 1 CRP, and the = responder=20 sends all certs.
 
3) Initiator does not send CRP, = but wants all=20 certs because RSA was negotiated.
 
I am sure there are others. I = would like to=20 recommend that option 1 is the best option, and the simplest. This = has=20 caused many interop issues, and the vague wording does not help. I = would=20 like to tighten up the rules if possible.
 
Comments?
 
Regards
Scott=20 = Fanning
= ------_=_NextPart_001_01C02812.2D148B7B-- From owner-ipsec@lists.tislabs.com Tue Sep 26 19:06:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06619; Tue, 26 Sep 2000 19:06:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17029 Tue, 26 Sep 2000 20:40:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: CERT_REQ_PAYLOAD usage Date: Tue, 26 Sep 2000 17:51:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0281D.058BF0D6" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC60B@fifi.platinum.corp.microsoft.com> Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAoFKlBEFYCxuEtRCq+2fMlkbcD8wAAPvUw From: "William Dixon" To: "Jan Vilhuber" Cc: "Tero Kivinen" , "Scott Fanning" , "IPsec List" X-OriginalArrivalTime: 27 Sep 2000 00:50:44.0468 (UTC) FILETIME=[F79AB340:01C0281C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0281D.058BF0D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It boils down to what is the meaning & utility of IPSec policy specifying roots or credentials to use. IPSec implementations typically do two things -=20 1. configure a specific end-entity cert to use, and/or 2. configure a root which: a. is the root of a credential you will offer and/or b. is the root to include in CRPs sent to the peer The PKI certificate store can be configured two ways: 1. trust the peer's root, either for all purposes or a specific purpose (e.g. IPSec) 2. don't trust the peer's root, but an admin can cross certify the peer's root for all purpose or a specific purpose (e.g. IPSec). My first point in the comment below was that your local IPSec policy config tells you what roots & certs to use. So the fact that I get a CRP from the peer helps me chose the right cert if I am allowed to use several which may be under different roots. But the CRP must not contain the only root from which I am required to provide an end-entity cert. The second point is that I shouldn't have to know what root to request from the peer. This is to enable IPSec to work in the cases where PKI cross-certification never establishes a common root that IKE could negotiate in CRPs, but does establish PKI trust for specific purposes which IKE should be able to use to successfully authenticate. The IPSec policy shouldn't have to fully duplicate the PKI trust policy - as IKE is just a vehicle to exchange identities which in the end are validated by the receivers PKI rules & store configuration.=20 If you receive a CRP and MUST supply a credential that matches that CRP - then it mandates the policy configuration on the other side so that it "knows" the right root DN to send which matches the client's cert issuer root. It is unnecessary to know a-priori in IPSec policy which root DN to send - in one case above the peer should be able to and certainly can send the credential it's configured to use, regardless of CRPs received. In the network model of PKI trust - where multiple roots exist, two systems have credentials from different roots, yet an admin can cross certify the other root, either for all purposes or for a specific purpose (e.g. IPSec). What comes out of this admin action is a "cross-certification certificate" - which may not even be stored on your local system - but stored in a directory some where. =20 Thus you don't have the peer's root in your IPSec policy because in fact you don't trust the root entirely - your policy says simply that you trust only your own root entirely. =20 But yet the peer's certificate will be valid if IKE calls the PKI library with because of the PKI chaining code finds the cross-cert & returns success. A practical example - business to business Company A's end-system clients have certs from Root A, and Company B's end-system servers have certs from Root B. So each IPSec policy is configured to use either the one end-entity cert that the machine has and/or send CRPs just for the one root. The clients & servers within each company can use the company's certificates for trusted IPSec communication. Now Company A wants to give company B's systems access to Company A's DMZ servers. Clearly if the IPSec policy on every one of Company B's end-systems needed to change, so that it had to send a CRP to Company A servers to request Company A based certs, this would be difficult, if not impossible depending on the IPSec policy implementation. But assume it was possible, it's still not enough to make this scenario work. Company B systems PKI library would need to know how to validate Company A server end-entity certificates & vice versa. The PKI world provides the capability of Company B saying it trusts Root A for IPSec - this is a cross-cert between Root B & Root A. Likewise Company A says it trusts Root B for IPSec. So now B systems can validate A end-entity certs, and A's system can validate B's end-entity certs - but neither have a common root to negotiate. And they don't need one. Each side provides the end-entity cert it is configured to use, each side may send CRPs for it's own corresponding root. But when you receive a CRP containing a root which you a. don't have in your IPSec policy, b. don't have in your list of trusted roots, and c. don't have a cert from, you disregard the CRP and send your own cert and the receiver PKI can validate it. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Tuesday, September 26, 2000 4:51 PM To: William Dixon Cc: Tero Kivinen; Scott Fanning; IPsec List Subject: RE: CERT_REQ_PAYLOAD usage On Tue, 26 Sep 2000, William Dixon wrote: > Tero, good ideas, one issue though: >=20 > 4) When you receive certificate request you MUST send your own > certificate for that CA. >=20 > Your own IPSec policy typically includes what roots to use or what certs > to send - so you have to enforce that, regardless of what the peer sends > you. If the CRP's don't match the roots you are configured to use, then > you are saying here you MUST fail. And that means that the peer MUST > send a correct CRP for the credential you have - which of course isn't > always possible. >=20 Not sure I follow that: Why is this not possible? Common sense tells me that I should send a CRP for ALL roots I know about (or all roots that I'm allowed to use by some obscure local policy, or whatever). If you answer with the ones that YOU have, we've got a non-empty intersection. If there's no overlap, then the intersection IS empty, and we must fail, because we don't share a root. Is there something I'm missing? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 ------_=_NextPart_001_01C0281D.058BF0D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CERT_REQ_PAYLOAD usage

It boils down to what is the meaning & utility of = IPSec policy specifying roots or credentials to use.

IPSec implementations typically do two things - =
1. configure a specific end-entity cert to use, = and/or
2. configure a root which:
  a. is the root of a credential you will offer = and/or
  b. is the root to include in CRPs sent to the = peer

The PKI certificate store can be configured two = ways:
1. trust the peer's root, either for all purposes or = a specific purpose (e.g. IPSec)
2. don't trust the peer's root, but an admin can = cross certify the peer's root for all purpose or a specific purpose = (e.g. IPSec).

My first point in the comment below was that your = local IPSec policy config tells you what roots & certs to use.  = So the fact that I get a CRP from the peer helps me chose the right cert = if I am allowed to use several which may be under different roots. But = the CRP must not contain the only root from which I am required to = provide an end-entity cert.

The second point is that I shouldn't have to know what = root to request from the peer.  This is to enable IPSec to work in = the cases where PKI cross-certification never establishes a common root = that IKE could negotiate in CRPs, but does establish PKI trust for = specific purposes which IKE should be able to use to successfully = authenticate.  The IPSec policy shouldn't have to fully duplicate = the PKI trust policy - as IKE is just a vehicle to exchange identities = which in the end are validated by the receivers PKI rules & store = configuration.

If you receive a CRP and MUST supply a credential that = matches that CRP - then it mandates the policy configuration on the = other side so that it "knows" the right root DN to send which = matches the client's cert issuer root.  It is unnecessary to know = a-priori in IPSec policy which root DN to send - in one case above the = peer should be able to and certainly can send the credential it's = configured to use, regardless of CRPs received. 

In the network model of PKI trust - where multiple = roots exist, two systems have credentials from different roots, yet an = admin can cross certify the other root, either for all purposes or for a = specific purpose (e.g. IPSec).  What comes out of this admin action = is a "cross-certification certificate" - which may not even be = stored on your local system - but stored in a directory some = where. 

Thus you don't have the peer's root in your IPSec = policy because in fact you don't trust the root entirely - your policy = says simply that you trust only your own root entirely.  =

But yet the peer's certificate will be valid if IKE = calls the PKI library with because of the PKI chaining code finds the = cross-cert & returns success.

A practical example - business to business
  Company A's end-system clients have certs from = Root A, and Company B's end-system servers have certs from Root B.  = So each IPSec policy is configured to use either the one end-entity cert = that the machine has and/or send CRPs just for the one root.  The = clients & servers within each company can use the company's = certificates for trusted IPSec communication.

  Now Company A wants to give company B's systems = access to Company A's DMZ servers.  Clearly if the IPSec policy on = every one of Company B's end-systems needed to change, so that it had to = send a CRP to Company A servers to request Company A based certs, this = would be difficult, if not impossible depending on the IPSec policy = implementation.  But assume it was possible, it's still not enough = to make this scenario work.  Company B systems PKI library would = need to know how to validate Company A server end-entity certificates = & vice versa.  The PKI world provides the capability of Company = B saying it trusts Root A for IPSec - this is a cross-cert between Root = B & Root A.  Likewise Company A says it trusts Root B for = IPSec.  So now B systems can validate A end-entity certs, and A's = system can validate B's end-entity certs - but neither have a common = root to negotiate.  And they don't need one.  Each side = provides the end-entity cert it is configured to use, each side may send = CRPs for it's own corresponding root.  But when you receive a CRP = containing a root which you a. don't have in your IPSec policy, b. don't = have in your list of trusted roots, and c. don't have a cert from, you = disregard the CRP and send your own cert and the receiver PKI can = validate it.


-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, September 26, 2000 4:51 PM
To: William Dixon
Cc: Tero Kivinen; Scott Fanning; IPsec List
Subject: RE: CERT_REQ_PAYLOAD usage


On Tue, 26 Sep 2000, William Dixon wrote:

> Tero, good ideas, one issue though:
>
>       4) When you = receive certificate request you MUST send your own
>       certificate for = that CA.
>
> Your own IPSec policy typically includes what = roots to use or what certs
> to send - so you have to enforce that, = regardless of what the peer sends
> you.  If the CRP's don't match the roots = you are configured to use, then
> you are saying here you MUST fail.  And = that means that the peer MUST
> send a correct CRP for the credential you have - = which of course isn't
> always possible.
>
Not sure I follow that: Why is this not possible? = Common sense tells me that
I should send a CRP for ALL roots I know about (or = all roots that I'm allowed
to use by some obscure local policy, or whatever). If = you answer with the
ones that YOU have, we've got a non-empty = intersection. If there's no
overlap, then the intersection IS empty, and we must = fail, because we don't
share a root.

Is there something I'm missing?

jan
 --
Jan = Vilhuber           = ;            =             &= nbsp;        = vilhuber@cisco.com
Cisco Systems, San = Jose           &nb= sp;           &nbs= p;            = ; (408) 527-0847

------_=_NextPart_001_01C0281D.058BF0D6-- From owner-ipsec@lists.tislabs.com Tue Sep 26 20:06:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07338; Tue, 26 Sep 2000 20:06:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17339 Tue, 26 Sep 2000 22:06:51 -0400 (EDT) Date: Wed, 27 Sep 2000 05:18:04 +0300 (EET DST) Message-Id: <200009270218.FAA31465@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: My summary from the VPN Interoperability Workshop in San Diego Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 14 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Summary ======= Misc ---- About 90% of those I asked had found out bug(s) in their own code. About 90% of those having bugs fixed them here... 100% of those I asked said this was useful. 100% of those I asked said they will come to the next meeting WHEN there is going to be one. IKE problems ------------ - Bundles and protection suites - SA bundles and multiple SAs - IP+AH+IP+ESP+IP+packet or IP+AH+ESP+IP+packet - Rekeying problems. Both in phase 1 and 2. - Nat traversal, not enough time to address it because this was so soon after ietf. - Agreeing on PFS (no negotiation there) - Using DOI 0. - Vendors requiring payloads being in specific order. - Vendors not able to handle long proposal lists. - Signature authentication. - Starting proposal numbers from zero. Document issues --------------- - What identity types are allowed in phase 1 and 2. - Give example of RSA signature exchange. - Add more examples how to behave in the different situations. - Dynamic address box solution is missing for subnet vpn. Commit bit ---------- - Commit bit issues, it is not very clear. - What spi we use in the SPI field in the connected notification if we are negotiation AH+ESP etc. Supporting things ----------------- - Vendors not doing group 1. - Vendors not doing DES. - Vendors not supporting aggressive mode - Vendors not supporting FQDN as identity for phase 1. - Vendors not supporting tunnel mode. Notifications ------------- - SPI inside the initial contact notification - Does the initial contact must be encrypted. - Vendors not implementing notification payloads. - Some vendors do not support main mode and they dont send proper notification (invalid exchange type), but they send some other error message. - Delete payload problems, can we send delete payloads in all packets? - Does the delete for phase 1 SA need the protection from the phase 1 SA - Clarify what SPI to send in the Delete payload. Certificates ------------ - Multiple certificate formats - Vendors require ip-address in certificates - Vendors not putting ip-address in certificates - How to bind certificate and ID together - UTF 8 encoding in certificates - Vendors not able to handle several certificate requests - Vendors requiring certificates to be on specific order. - Vendors not able to handle certificates having multiple subject alt names Son of the IKE -------------- - Vendors implementing parts of the son of the IKE draft, but it is expired. For example SPI size. New notifications, using old exchange number. - What is the status of this. Lifetime -------- - Lifetime problems (configuring them) - Lifetime what are the defaults, we need defaults - When we use defaults. Only if no lifetime attributes, or only when one of them is missing. - Phase 1 SA lifetimes in kilobytes. - Using variable length encoding for kilobyte lifetimes. IPComp ------ - The IKE does not work well with only ipcomp and with well known cpis - CPI size (2 or 4). - IPComp problems. ---------------------------------------------------------------------- Comments about the plans to combine ISAKMP+IKE+IPSEC DOI to one document: ---------------------------------------------------------------------- Q: 7) If we are going to do that are we allowed to change the bits in the wire? A: 9 yes ---------------------------------------------------------------------- Q: 8) What would you like to REMOVE from the IKE during that? A: - Too much options, Agressive mode, New group - Remove the original RSA encryption mode - PFS, Dangling SAs, Commit bit, Aggressive mode replaced with base mode, quick mode 3 or 4 packets, Change to cookies to just message ids, removing differencens in the SKEYID generation for different modes. - Only one RSA mode, propably revised - Negotiating PRF, add phase 1 responder lifetime - Reduce number of algorithms - Email address, remove extra identities (In this question I just wanted to know what people would like to remove, they didn't see the list below when answering to this, the answers in this item are also counted in the cases below) ---------------------------------------------------------------------- Q: 8a) Do we need two different public key encryption authentication method. If not which one we should remove? A: 6 only one (3 dont care which one), 2 keep both ---------------------------------------------------------------------- Q: 8b) Do we need both aggressive and main mode? Which one? A: 1 remove aggressive, 3 replace aggr with base, 3 keep both ---------------------------------------------------------------------- Q: 8c) How about new group mode? A: 3 remove, 1 keep ---------------------------------------------------------------------- Q: 8d) How about private groups in the phase 1? A: 2 remove, 2 keep ---------------------------------------------------------------------- Q: 8e) Do we need both RSA and DSS signature authentication modes? Which one? A: 3 remove DSS, 2 keep both ---------------------------------------------------------------------- Q: 8g) Can we remove the whole DOI field? A: 2 remove, 4 keep it ---------------------------------------------------------------------- Q: 8h) Can we remove the situation stuff? A: 4 remove, 2 remove or just ignore it always ---------------------------------------------------------------------- Q: 8i) Negotiation multiple SAs over one Quick mode? A: 3 remove, 3 keep ---------------------------------------------------------------------- Q: 9) Do we want to fix the authentication hash at the same time (revised authentication hash)? A: 6 yes, 1 only minimal changes ---------------------------------------------------------------------- IPsec questions: ---------------------------------------------------------------------- Q: 12) Is there anything in the IPsec that you would like to be removed? A: - AH, DES, Manual keying to be optional and mostly for testing - AH, Transport mode, DES - AH, Manual Keying to be SHOULD - Transport mode, or tunnel mode and use GRE - AH - Remove ESP authentication, keep AH - AH (This is again their answers without showing the list below). ---------------------------------------------------------------------- Q: 12a) AH A: 7 remove AH, 2 keep it ---------------------------------------------------------------------- Q: 12b) Manual keying A: 6 Manual key to optional, 1 keep it ---------------------------------------------------------------------- Q: 13) Do you plan to implement IPv6 IPsec also? Do we need possibility to test that too? A: 13 plan to implement IPv6, 2 no, 1 do not know -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 26 20:46:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10493; Tue, 26 Sep 2000 20:46:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17382 Tue, 26 Sep 2000 22:31:27 -0400 (EDT) Date: Wed, 27 Sep 2000 05:42:39 +0300 (EET DST) Message-Id: <200009270242.FAA05721@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: "William Dixon" Cc: "Scott Fanning" , "IPsec List" Subject: RE: CERT_REQ_PAYLOAD usage In-Reply-To: <6A05D00595BE644E9F435BE5947423F2FFC60A@fifi.platinum.corp.microsoft.com> References: <6A05D00595BE644E9F435BE5947423F2FFC60A@fifi.platinum.corp.microsoft.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Dixon writes: > 4) When you receive certificate request you MUST send your own > certificate for that CA. > Your own IPSec policy typically includes what roots to use or what certs > to send - so you have to enforce that, regardless of what the peer sends > you. If the CRP's don't match the roots you are configured to use, then > you are saying here you MUST fail. No, I didn't say you MUST fail. I said you MUST send your own certificate for that CA. If you don't have certificate for that CA, then you just ignore the certificate request payload. If you ended up ignoring all certificate request payloads (you don't have certificate to any of them), then you can just send all certificates you have, in case that helps (most likely it does not, the authentication is going to fail anyways). > And that means that the peer MUST send a correct CRP for the > credential you have - which of course isn't always possible. The other end typically sends multiple certificate request payloads and you typically only answer to ONE. In most cases you cannot answer to all of them because your private key might be different for each CA, so you cannot mix those certificates. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 26 20:48:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10511; Tue, 26 Sep 2000 20:48:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17418 Tue, 26 Sep 2000 22:40:30 -0400 (EDT) Date: Wed, 27 Sep 2000 05:51:29 +0300 (EET DST) Message-Id: <200009270251.FAA09822@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: "Brian Swander" Cc: "William Dixon" , "kaijun gu" , "Scott Fanning" , "IPsec List" Subject: RE: CERT_REQ_PAYLOAD usage In-Reply-To: <5B90AD65A9E8934987DB0C8C076265740C5F09@DF-BOWWOW.platinum.corp.microsoft.com> References: <5B90AD65A9E8934987DB0C8C076265740C5F09@DF-BOWWOW.platinum.corp.microsoft.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian Swander writes: > Unless I'm missing something, it seems pretty hacky to send multiple end > entity cert chains. Say my peer sends me 3 CRPs for different roots, > root A,B,C. I have 3 cert chains that chain to these roots. Chain1: > A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0, and C0 are > the end entity certs. > > Say I send all of these certs in random order (A0,B1,A1,B0,C0 etc). > Now, the peer has to pick out the chains, and piece them back together. Yes. So what? If you are using real certificate manager that takes care of that that is not an issue. As the IKE is currently defined you have to do that anyways. > Worse yet, I also have to send 3 sig payloads since in general A0,B0 and > C0 will all have different private keys. There is no way in IKE to map No. If those certificates does not share the private key then you only send ONE chain. If they all share private key then you can send multiple chains. You SHOULD NOT send multiple certificates matching your ID payload that have different private key. You MAY send multiple certificates matching your ID payload if they have same private key. > the chain to the sig payload, so IKE has to guess what the chains are, > guess what the end entity certs are, and go with trial and error to find > the correct sig payloads. Or you could simple find out all certificates matching the ID payload and try to verify the signature with all of them. This might also be the case when you have overlapping validity periods while you get a new certificate to replace old one. The other end might already have your old certificate in its certificate cache, and you are using the new certificate when you create the SIG, thus the other end might end up checking the signature with wrong public key. > Thus, sending a single chain and a single sig payload seem to me to be > the only reasonable alternative. Of course, if we mandated that people > sent an individual chain as its own PKCS7 and that all end entity certs > MUST have the basic constraint saying that they are end entity, and > defined some way in IKE to map PKCS blobs to sig payloads (maybe with > mandatory payload ordering), then perhaps we could build an > interoperable way to send multiple chains. But as William points out, > we'd still have the problem of fragmented IKE payloads. What is the problem with fragmented IKE payloads? You have to be able to process them anyways, as there might be some ppp lines that has MTU of 128 bytes between you and the other end. If you don't know how to handle fragmented IKE payloads then your implementation is broken and it should be fixed. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Sep 27 00:14:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13744; Wed, 27 Sep 2000 00:14:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA18008 Wed, 27 Sep 2000 01:52:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: CERT_REQ_PAYLOAD usage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02848.85DD40C0" Date: Tue, 26 Sep 2000 23:02:31 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB80D@fifi.platinum.corp.microsoft.com> Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAoRaHJSz3v38woTBGcKryUstqkiQAAkxdQ From: "William Dixon" To: "Tero Kivinen" Cc: "Scott Fanning" , "IPsec List" X-OriginalArrivalTime: 27 Sep 2000 06:02:59.0415 (UTC) FILETIME=[9680BE70:01C02848] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C02848.85DD40C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So I have a cert that my local IPSec policy doesn't allow me to use - but since I receive a CRP that contains that cert's root, now I MUST send it ? -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Tuesday, September 26, 2000 7:43 PM To: William Dixon Cc: Scott Fanning; IPsec List Subject: RE: CERT_REQ_PAYLOAD usage William Dixon writes: > 4) When you receive certificate request you MUST send your own > certificate for that CA. > Your own IPSec policy typically includes what roots to use or what certs > to send - so you have to enforce that, regardless of what the peer sends > you. If the CRP's don't match the roots you are configured to use, then > you are saying here you MUST fail. No, I didn't say you MUST fail. I said you MUST send your own certificate for that CA. If you don't have certificate for that CA, then you just ignore the certificate request payload. If you ended up ignoring all certificate request payloads (you don't have certificate to any of them), then you can just send all certificates you have, in case that helps (most likely it does not, the authentication is going to fail anyways).=20 > And that means that the peer MUST send a correct CRP for the > credential you have - which of course isn't always possible. The other end typically sends multiple certificate request payloads and you typically only answer to ONE. In most cases you cannot answer to all of them because your private key might be different for each CA, so you cannot mix those certificates.=20 --=20 kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ------_=_NextPart_001_01C02848.85DD40C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CERT_REQ_PAYLOAD usage

So I have a cert that my local IPSec policy doesn't = allow me to use - but since I receive a CRP that contains that cert's = root, now I MUST send it ?

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@ssh.fi]
Sent: Tuesday, September 26, 2000 7:43 PM
To: William Dixon
Cc: Scott Fanning; IPsec List
Subject: RE: CERT_REQ_PAYLOAD usage


William Dixon writes:
>       4) When you = receive certificate request you MUST send your own
>       certificate for = that CA.
> Your own IPSec policy typically includes what = roots to use or what certs
> to send - so you have to enforce that, = regardless of what the peer sends
> you.  If the CRP's don't match the roots = you are configured to use, then
> you are saying here you MUST fail.

No, I didn't say you MUST fail. I said you MUST send = your own
certificate for that CA. If you don't have = certificate for that CA,
then you just ignore the certificate request payload. = If you ended up
ignoring all certificate request payloads (you don't = have certificate
to any of them), then you can just send all = certificates you have, in
case that helps (most likely it does not, the = authentication is going
to fail anyways).

> And that means that the peer MUST send a correct = CRP for the
> credential you have - which of course isn't = always possible.

The other end typically sends multiple certificate = request payloads
and you typically only answer to ONE. In most cases = you cannot answer
to all of them because your private key might be = different for each
CA, so you cannot mix those certificates.
--
kivinen@ssh.fi        &n= bsp;           &nb= sp;          Work : +358 = 303 9870
SSH Communications = Security           = ;       http://www.ssh.fi/
SSH IPSEC = Toolkit           =             &= nbsp;    http://www.ssh.fi/ipsec/

------_=_NextPart_001_01C02848.85DD40C0-- From owner-ipsec@lists.tislabs.com Wed Sep 27 00:14:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13759; Wed, 27 Sep 2000 00:14:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA18007 Wed, 27 Sep 2000 01:52:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: CERT_REQ_PAYLOAD usage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02847.8640E3C4" Date: Tue, 26 Sep 2000 22:55:22 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC60C@fifi.platinum.corp.microsoft.com> Thread-Topic: CERT_REQ_PAYLOAD usage Thread-Index: AcAoLej1MOJUMACPTCGvS3BjL2QS6QAFg5PQ From: "William Dixon" To: "Tero Kivinen" , "Brian Swander" Cc: "kaijun gu" , "Scott Fanning" , "IPsec List" X-OriginalArrivalTime: 27 Sep 2000 06:02:59.0024 (UTC) FILETIME=[96451500:01C02848] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C02847.8640E3C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tero, regarding "If you don't know how to handle fragmented IKE payloads then your implementation is broken and it should be fixed." The case isn't that we don't know how to handle them - its that fragmented packets are less reliable across the Internet, so we would really like to avoid them. It's such an issue that at least the Windows TCP stacks always enable the DF bit for PTMU detection. =20 The three problems I've seen in end-to-end IPSec are: 1. router/gw/fw filtering that don't handle fragments well (even core LAN routers due to bugs in OS version that took a long time track down) 2. flow-based QOS not having port info and 3. fragments can timeout in the reassembly queue when the receiver is really busy. In almost all IKE implementations there is no path MTU discovery, and no way to reduce the size of the UDP payload because you can't interoperable send payloads in different exchanges. So I would always expect fragmentation when you exchange certs, PKCS #7 chains, CRLs in-band & CRPs for real PKI systems. It does strike me that primarily UDP based services usually do define a TCP option to ensure traffic can get through reliably - e.g. DNS, Kerberos, LDAP. I wasn't around during the UDP or TCP debate, so I don't know why TCP 500 wasn't also an option to handle retransmissions, avoid fragmentation, do keep-alives, backoff, DOS prevention, etc. Do you remember ? I see it is already reserved... isakmp 500/tcp isakmp isakmp 500/udp isakmp -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Tuesday, September 26, 2000 7:51 PM To: Brian Swander Cc: William Dixon; kaijun gu; Scott Fanning; IPsec List Subject: RE: CERT_REQ_PAYLOAD usage Brian Swander writes: > Unless I'm missing something, it seems pretty hacky to send multiple end > entity cert chains. Say my peer sends me 3 CRPs for different roots, > root A,B,C. I have 3 cert chains that chain to these roots. Chain1: > A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0, and C0 are > the end entity certs. > =20 > Say I send all of these certs in random order (A0,B1,A1,B0,C0 etc). > Now, the peer has to pick out the chains, and piece them back together. Yes. So what? If you are using real certificate manager that takes care of that that is not an issue. As the IKE is currently defined you have to do that anyways.=20 > Worse yet, I also have to send 3 sig payloads since in general A0,B0 and > C0 will all have different private keys. There is no way in IKE to map No. If those certificates does not share the private key then you only send ONE chain. If they all share private key then you can send multiple chains. You SHOULD NOT send multiple certificates matching your ID payload that have different private key. You MAY send multiple certificates matching your ID payload if they have same private key. > the chain to the sig payload, so IKE has to guess what the chains are, > guess what the end entity certs are, and go with trial and error to find > the correct sig payloads. Or you could simple find out all certificates matching the ID payload and try to verify the signature with all of them. This might also be the case when you have overlapping validity periods while you get a new certificate to replace old one. The other end might already have your old certificate in its certificate cache, and you are using the new certificate when you create the SIG, thus the other end might end up checking the signature with wrong public key.=20 > Thus, sending a single chain and a single sig payload seem to me to be > the only reasonable alternative. Of course, if we mandated that people > sent an individual chain as its own PKCS7 and that all end entity certs > MUST have the basic constraint saying that they are end entity, and > defined some way in IKE to map PKCS blobs to sig payloads (maybe with > mandatory payload ordering), then perhaps we could build an > interoperable way to send multiple chains. But as William points out, > we'd still have the problem of fragmented IKE payloads. What is the problem with fragmented IKE payloads? You have to be able to process them anyways, as there might be some ppp lines that has MTU of 128 bytes between you and the other end. If you don't know how to handle fragmented IKE payloads then your implementation is broken and it should be fixed.=20 --=20 kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ------_=_NextPart_001_01C02847.8640E3C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CERT_REQ_PAYLOAD usage

Tero, regarding "If you don't know how to handle = fragmented IKE payloads then your implementation is broken and it should = be fixed."

The case isn't that we don't know how to handle them - = its that fragmented packets are less reliable across the Internet, so we = would really like to avoid them.  It's such an issue that at least = the Windows TCP stacks always enable the DF bit for PTMU = detection. 

The three problems I've seen in end-to-end IPSec = are:
1. router/gw/fw filtering that don't handle fragments = well (even core LAN routers due to bugs in OS version that took a long = time track down)

2. flow-based QOS not having port info and
3. fragments can timeout in the reassembly queue when = the receiver is really busy.

In almost all IKE implementations there is no path MTU = discovery, and no way to reduce the size of the UDP payload because you = can't interoperable send payloads in different exchanges.  So I = would always expect fragmentation when you exchange certs, PKCS #7 = chains, CRLs in-band & CRPs for real PKI systems.

It does strike me that primarily UDP based services = usually do define a TCP option to ensure traffic can get through = reliably - e.g. DNS, Kerberos, LDAP.  I wasn't around during the = UDP or TCP debate, so I don't know why TCP 500 wasn't also an option to = handle retransmissions, avoid fragmentation, do keep-alives, backoff, = DOS prevention, etc.  Do you remember ?

I see it is already reserved...
isakmp          = 500/tcp    isakmp
isakmp          = 500/udp    isakmp

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@ssh.fi]
Sent: Tuesday, September 26, 2000 7:51 PM
To: Brian Swander
Cc: William Dixon; kaijun gu; Scott Fanning; IPsec = List
Subject: RE: CERT_REQ_PAYLOAD usage


Brian Swander writes:
> Unless I'm missing something, it seems pretty = hacky to send multiple end
> entity cert chains.  Say my peer sends me 3 = CRPs for different roots,
> root A,B,C.  I have 3 cert chains that = chain to these roots.  Chain1:
> A0,A1,A  Chain2: B0,B1,B2,B  = Chain3:  C0,C1,C  where A0, B0, and C0 are
> the end entity certs.
> 
> Say I send all of these certs in random order = (A0,B1,A1,B0,C0 etc).
> Now, the peer has to pick out the chains, and = piece them back together.

Yes. So what? If you are using real certificate = manager that takes
care of that that is not an issue. As the IKE is = currently defined you
have to do that anyways.

> Worse yet, I also have to send 3 sig payloads = since in general A0,B0 and
> C0 will all have different private keys.  = There is no way in IKE to map

No. If those certificates does not share the private = key then you only
send ONE chain. If they all share private key then = you can send
multiple chains. You SHOULD NOT send multiple = certificates matching
your ID payload that have different private key. You = MAY send multiple
certificates matching your ID payload if they have = same private key.

> the chain to the sig payload, so IKE has to guess = what the chains are,
> guess what the end entity certs are, and go with = trial and error to find
> the correct sig payloads.

Or you could simple find out all certificates matching = the ID payload
and try to verify the signature with all of them. = This might also be
the case when you have overlapping validity periods = while you get a
new certificate to replace old one.

The other end might already have your old certificate = in its
certificate cache, and you are using the new = certificate when you
create the SIG, thus the other end might end up = checking the signature
with wrong public key.

> Thus, sending a single chain and a single sig = payload seem to me to be
> the only reasonable alternative.  Of = course, if we mandated that people
> sent an individual chain as its own PKCS7 and = that all end entity certs
> MUST have the basic constraint saying that they = are end entity, and
> defined some way in IKE to map PKCS blobs to sig = payloads (maybe with
> mandatory payload ordering), then perhaps we = could build an
> interoperable way to send multiple chains.  = But as William points out,
> we'd still have the problem of fragmented IKE = payloads.

What is the problem with fragmented IKE payloads? You = have to be able
to process them anyways, as there might be some ppp = lines that has MTU
of 128 bytes between you and the other end. If you = don't know how to
handle fragmented IKE payloads then your = implementation is broken and
it should be fixed.
--
kivinen@ssh.fi        &n= bsp;           &nb= sp;          Work : +358 = 303 9870
SSH Communications = Security           = ;       http://www.ssh.fi/
SSH IPSEC = Toolkit           =             &= nbsp;    http://www.ssh.fi/ipsec/

------_=_NextPart_001_01C02847.8640E3C4-- From owner-ipsec@lists.tislabs.com Wed Sep 27 00:52:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14594; Wed, 27 Sep 2000 00:52:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18329 Wed, 27 Sep 2000 02:49:02 -0400 (EDT) Date: Wed, 27 Sep 2000 08:59:20 +0200 From: Stefan Schlott To: ipsec@lists.tislabs.com Subject: ICMP "Destination unreachable" - should it be sent? Message-ID: <20000927085920.B11807@blackbird.extern.uni-ulm.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, some time ago, I read the ICMPv6 RFC (rfc2463) and found the following message: "Destination Unreachable Message Code 1 - communication with destination administratively prohibited" Should this message be sent when a packet does not conform to the local security policy database (spd), or should such packets be silently dis- carded? Stefan. -- *--- please cut here... -------------------------------------- thanks! ---* |-> E-Mail: stefan.schlott@student.uni-ulm.de DH-PGP-Key: 0x2F36F4FE <-| | Fixed sendmail on www.linux.org.uk - that is I installed exim on it. | | Sendmail kindly erased /etc/aliases when it was removed. That was nice | | of it. | | -- Alan Cox's diary (15.03.2000) | *-------------------------------------------------------------------------* From owner-ipsec@lists.tislabs.com Wed Sep 27 04:05:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19786; Wed, 27 Sep 2000 04:05:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18954 Wed, 27 Sep 2000 05:39:40 -0400 (EDT) Message-Id: <200009270949.LAA62994@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "William Dixon" cc: "Tero Kivinen" , "Brian Swander" , "kaijun gu" , "Scott Fanning" , "IPsec List" Subject: Re: CERT_REQ_PAYLOAD usage In-reply-to: Your message of Tue, 26 Sep 2000 22:55:22 PDT. <6A05D00595BE644E9F435BE5947423F2FFC60C@fifi.platinum.corp.microsoft.com> Date: Wed, 27 Sep 2000 11:49:52 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: In almost all IKE implementations there is no path MTU discovery, and no way to reduce the size of the UDP payload because you can't interoperable send payloads in different exchanges. => with IPv6 IKE *should* use the IPV6_USE_MIN_MTU socket option (IPv6 is a bit different: - there is no "en route" fragmentation, ie. fragmentation is end-to-end - path MTU discovery is mandatory (but doesn't work well with IKE) - there is some user control on path MTU (including this socket option) - minimal MTU is 1280 bytes (ie. far more than IPv4 68 bytes)) Regards Francis.Dupont@enst-bretagne.fr PS: I've sent this message in order to have this point in the archives. PPS: from draft-ietf-ipngwg-rfc2292bis-01.txt: 11.1. Sending with the Minimum MTU Some applications might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. This specification defines a mechanism to avoid fragmentation by sending at the minimum IPv6 MTU (1280 bytes). This can be enabled using the IPV6_USE_MIN_MTU socket option. int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); By default, this socket option is disabled. Setting the value to 0 also disables the option. This option can also be sent as ancillary data. From owner-ipsec@lists.tislabs.com Wed Sep 27 08:18:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27045; Wed, 27 Sep 2000 08:18:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19615 Wed, 27 Sep 2000 09:32:26 -0400 (EDT) Message-Id: <200009271343.e8RDh1l113252@thunk.east.sun.com> From: Bill Sommerfeld To: Stefan Schlott cc: ipsec@lists.tislabs.com Subject: Re: ICMP "Destination unreachable" - should it be sent? In-reply-to: Your message of "Wed, 27 Sep 2000 08:59:20 +0200." <20000927085920.B11807@blackbird.extern.uni-ulm.de> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 27 Sep 2000 09:43:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Should this message be sent when a packet does not conform to the local > security policy database (spd), or should such packets be silently dis- > carded? IMHO, it should be up to the system's policy as to whether or not ICMP unreachables (and, if so, *which* type of unreachable) should be sent. - Bill From owner-ipsec@lists.tislabs.com Wed Sep 27 08:55:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00524; Wed, 27 Sep 2000 08:55:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19926 Wed, 27 Sep 2000 10:33:43 -0400 (EDT) From: Dan McDonald Message-Id: <200009271424.HAA21557@kebe.Eng.Sun.COM> Subject: Connectathon and IKE/IPsec interop? To: ipsec@lists.tislabs.com Date: Wed, 27 Sep 2000 07:24:09 -0700 (PDT) CC: kivinen@ssh.fi, audrey@vanb.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We're planning on holding IKE/IPsec interoperability at Connectathon (www.connectathon.org) in March of 2001. This past C-thon's IPsec testing was added toward the last minute, and as a result didn't have as many people as normal IPsec events have. I'm mentioning this now because of Kivinen's note that said: > 100% of those I asked said they will come to the next meeting > WHEN there is going to be one. I don't know if someone wants one in between 3/2001 and now, but I do know that we're going to do it again at C-thon. Audrey Van Bellingham (audrey@vanb.com) runs C-thon. Dan p.s. The amount of participants in the IPsec bakeoffs might be a useful datapoint for Audrey, BTW. From owner-ipsec@lists.tislabs.com Wed Sep 27 11:06:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03066; Wed, 27 Sep 2000 11:06:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20679 Wed, 27 Sep 2000 12:58:04 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14802.10657.667759.99621@thomasm-u1.cisco.com> Date: Wed, 27 Sep 2000 10:08:49 -0700 (PDT) To: Henry Spencer Cc: IP Security List Subject: Re: TOS copying considered harmful In-Reply-To: References: <39C7895E.D04366DA@sxb.bsf.alcatel.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Tue, 19 Sep 2000, Olivier Kreet wrote: > > The best thing would probably be to have one tunnel per class of > > service, but it is not always possible to set up parallel tunnels on > > today's IPSec implementations (e.g. linux Freeswan). > > Also, whether this is "best" depends on your priorities. Making the TOS > field visible -- whether in one tunnel or parallel tunnels -- provides a > hint to traffic analysts and a covert channel for Trojan horses, so the > underlying assumption that this should be done is itself questionable. You really can't have it both ways though. In practice, I'm not sure what this will have really bought you from a traffic analysis standpoint: if I sniff packets in a tunnel, it's probably not going to take a lot of effort to notice that the packets popping out every 10ms are probably RTP packets. As to whether it should be done: if my choice is to mark the traffic and get acceptible QoS or not mark the traffic and get unacceptible QoS, any perceived security gain isn't buying you much if the base level communication is compromised beyond usability. It's not hard to imagine congested links and real time requirements where QoS is the critical problem. > I note, also, that TOS isn't in 2401's list of packet selectors, so there > is no requirement in the current IPsec architecture that such parallel > tunnels be supported. Arguably, IPsec is on the wrong side. The RSVP aggregation draft allows selectors based on TOS. There really should be flow selector police so that there is consistent flow selection requirements throughout IETF protocols. Mike From owner-ipsec@lists.tislabs.com Wed Sep 27 14:39:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08438; Wed, 27 Sep 2000 14:39:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21492 Wed, 27 Sep 2000 16:18:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: ipsec and win2k MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C028C1.A3C5A694" Date: Wed, 27 Sep 2000 13:29:30 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB814@fifi.platinum.corp.microsoft.com> Thread-Topic: ipsec and win2k Thread-Index: AcAkCJI5uvEJv1qLSRW5pfrOdtoSGwEuNJkw From: "William Dixon" To: "Michael Milbach" , X-OriginalArrivalTime: 27 Sep 2000 20:29:08.0391 (UTC) FILETIME=[966D2B70:01C028C1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C028C1.A3C5A694 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See http://support.microsoft.com KB article=20 -----Original Message----- From: Michael Milbach [mailto:mmilbach@mentortech.com] Sent: Thursday, September 21, 2000 12:55 PM To: ipsec@lists.tislabs.com Subject: ipsec and win2k Can anyone please point me to some documentation on IPsec Tunneling between=20 to win2k boxes. I already have been through M$'s support, and have some information, but the one Tunneling example given is for one unique=20 circumstance with little explanation. Any direction would be appreciated. TIA Michael ******************* Michael Milbach Mentor Technologies Group Cell: 240-460-0073 Office: 301-680-3562 ******************* Mentor Technologies Group: We're high tech, high touch, high performance; the total learning solutions company. ------_=_NextPart_001_01C028C1.A3C5A694 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ipsec and win2k

See http://support.microsoft.com = KB article


-----Original Message-----
From: Michael Milbach [mailto:mmilbach@mentortech.com]
Sent: Thursday, September 21, 2000 12:55 PM
To: ipsec@lists.tislabs.com
Subject: ipsec and win2k


Can anyone please point me to some documentation on = IPsec Tunneling between
to win2k boxes.  I already have been through = M$'s support, and have some
information, but the one Tunneling example given is = for one unique
circumstance with little explanation.  Any = direction would be appreciated.

TIA

Michael
*******************
Michael Milbach
Mentor Technologies Group

Cell:    240-460-0073
Office:  301-680-3562

*******************
Mentor Technologies Group:
We're high tech, high touch, high performance; the = total learning solutions
company.

------_=_NextPart_001_01C028C1.A3C5A694-- From owner-ipsec@lists.tislabs.com Wed Sep 27 15:33:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09393; Wed, 27 Sep 2000 15:33:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21572 Wed, 27 Sep 2000 17:09:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: who does ESP padding > 8 bytes ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C028C7.C569F092" Date: Wed, 27 Sep 2000 14:13:24 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB816@fifi.platinum.corp.microsoft.com> Thread-Topic: who does ESP padding > 8 bytes ? Thread-Index: AcAox6CkoMuPk1LlQP+HrpYDlJptBw== From: "William Dixon" To: X-OriginalArrivalTime: 27 Sep 2000 21:19:33.0750 (UTC) FILETIME=[A1AE5160:01C028C8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C028C7.C569F092 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Does anyone have an IPSec implementation w/IKE that inserts greater than 8 bytes of ESP padding. I'm aware of two that use up to 8, but none that use more than 8.=20 Thx, Wm ------_=_NextPart_001_01C028C7.C569F092 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable who does ESP padding > 8 bytes ?

Does anyone have an IPSec implementation w/IKE that = inserts greater than 8 bytes of ESP padding.  I'm aware of two that = use up to 8, but none that use more than 8.

Thx,
Wm

------_=_NextPart_001_01C028C7.C569F092-- From owner-ipsec@lists.tislabs.com Wed Sep 27 15:35:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09412; Wed, 27 Sep 2000 15:35:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21612 Wed, 27 Sep 2000 17:29:47 -0400 (EDT) Date: Wed, 27 Sep 2000 14:40:33 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: ike over sctp? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since IKE over TCP versus IKE over UDP was brought up recently (I think), I was wondering what people thought of IKE over SCTP (draft-ietf-sigtran-sctp-13.txt). A problem I would think in IKE over TCP is the head-end blocking, i.e. if one packet gets lost and needs retransmission, all others must wait before getting to the IKE process. In SCTP, this is not an issue (in fact one of the design goals was to eliminate this). SCTP (from what little I've read) sounds promising (better than everyone inventing their own reliability scheme on top of UDP). Just curious.. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Sep 27 15:41:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09493; Wed, 27 Sep 2000 15:41:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21571 Wed, 27 Sep 2000 17:09:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: ipsec and win2k MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C028C7.8CF763C0" Date: Wed, 27 Sep 2000 14:11:49 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB815@fifi.platinum.corp.microsoft.com> Thread-Topic: ipsec and win2k Thread-Index: AcAkCJI5uvEJv1qLSRW5pfrOdtoSGwEuNJkwAAAOihA= From: "William Dixon" To: "Michael Milbach" , X-OriginalArrivalTime: 27 Sep 2000 21:18:49.0530 (UTC) FILETIME=[8752E1A0:01C028C8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C028C7.8CF763C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hit reply too soon, I meant to add that tunnel configuration is detailed in KB article #Q252735. Since I'm posting, I'll add the following text that I keep mailing individually to people. I apologize to the rest of you who already know this. More detail on IPSec in Windows 2000 is available in: http://support.microsoft.com/support/kb/articles/Q265/1/12.ASP PLEASE NOTE: Windows 2000's VPN client ONLY supports PPTP and L2TP/IPSec for client VPN remote access. The L2TP/IPSec VPN client requires by default a machine certificate. While there is a registry key to disable the automatic IPSec policy that L2TP uses, we do not support this method of configuring a _client_ for VPN remote access. The KB article that provides documentation for this registry key explains this. There are many potential security risks & interoperability issues in operationally using static filters and a preshared authentication key to establish IPSec to the L2TP gateway - so we only support the integrated mode of operation. Likewise, using IPSec tunnels on Win2k laptops for remote access would not be supported (by the Win2k IPSec implementation) to other vendors. This is documented in the VPN whitepapers: http://www.microsoft.com/windows2000/library/howitworks/communications/r emoteaccess/default.asp You can save yourself a lot of trouble by using certificates for the L2TP/IPSec client. General IPSec transport and tunnel configurations (where you configure IPSec policy manually) can use any of 3 authentication methods. Most major CA vendors have web pages and other enrollment methods for you to get a certificate into the machine store on the win2k client. If you want to test win2k L2TP/IPSec with certificates, use the procedure in my walkthrough document below which provides links to the publicly available Microsoft test CAs. For gateways you can do cut & paste of PKCS#10 & #7, and they support SCEP, provided in the Windows 2000 Resource Kit. The IPSec tunnel mode in win2k is negotiated using IKE RFC 2409's tunneling capability - which does not provide address assignment necessary for remote access applications. As most IPSec vendors know, but most casual observers on the list don't, many vendors have made proprietary and/or non-RFC extensions to IKE to make it useful for IPSec tunneling in remote access scenarios. This involves support for the drafts commonly referred to as IKECFG (mode config) and XAUTH. Win2k's IKE does not support these extensions. =20 For those vendors which do not provide L2TP/IPSec gateway functionality, and thus do not work with the native Windows 2000 L2TP/IPSec client, they provide their own IPSec-based remote access client. In most cases you need to get a version of the client that works on Windows 2000.=20 However, when win2k end systems and Win2k gateways have static IP addresses - they could be configured (by network admins who understand IPSec, not end-users) to use IPSec tunneling to another IPSec gateway. This should interoperate in at least simple configurations with most other gateways. A number of demonstrations over the last year have shown this interoperability. Please send me private email if you need clarification. But please do not ask if win2k interoperates with vendor xxx doing yyy. There are over 200,000 combinations of IPSec/IKE configurations between two peers. We use KB articles to document known cases where special configuration is required to work with another vendor. The KB article Q265112 contains the news groups which provide user support for configuration if you are unable to reach a technical support engineer. If you have successfully configured two different products to work together, then I'd be happy to receive the configuration steps to assist our support engineers. =20 (and yes, I configured outlook to do plain text, but apparently some extra formatting is present. I apologize if this causes your reader problems.) Wm William Dixon Program Manager - Network Security Windows Operating Systems Division Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 Feb '00 Windows 2000 IPSec end-to-end walkthrough & mini-whitepaper (which covers IKE's use of certificates): http://www.microsoft.com/windows2000/library/technologies/security/defau lt.asp=20 -----Original Message----- From: William Dixon=20 Sent: Wednesday, September 27, 2000 1:30 PM To: 'Michael Milbach'; ipsec@lists.tislabs.com Subject: RE: ipsec and win2k See http://support.microsoft.com KB article=20 -----Original Message----- From: Michael Milbach [mailto:mmilbach@mentortech.com] Sent: Thursday, September 21, 2000 12:55 PM To: ipsec@lists.tislabs.com Subject: ipsec and win2k Can anyone please point me to some documentation on IPsec Tunneling between=20 to win2k boxes. I already have been through M$'s support, and have some information, but the one Tunneling example given is for one unique=20 circumstance with little explanation. Any direction would be appreciated. TIA Michael ******************* Michael Milbach Mentor Technologies Group Cell: 240-460-0073 Office: 301-680-3562 ******************* Mentor Technologies Group: We're high tech, high touch, high performance; the total learning solutions company. ------_=_NextPart_001_01C028C7.8CF763C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: ipsec and win2k

Hit reply too soon, I meant to add that tunnel = configuration is detailed in KB article #Q252735.  Since I'm = posting, I'll add the following text that I keep mailing individually to = people.  I apologize to the rest of you who already know = this.

More detail on IPSec in Windows 2000 is available = in:
h= ttp://support.microsoft.com/support/kb/articles/Q265/1/12.ASP

PLEASE NOTE: Windows 2000's VPN client ONLY supports = PPTP and L2TP/IPSec for client VPN remote access.  The L2TP/IPSec = VPN client requires by default a machine certificate.  While there = is a registry key to disable the automatic IPSec policy that L2TP uses, = we do not support this method of configuring a _client_ for VPN remote = access.  The KB article that provides documentation for this = registry key explains this.  There are many potential security = risks & interoperability issues in operationally using static = filters and a preshared authentication key to establish IPSec to the = L2TP gateway - so we only support the integrated mode of = operation.  Likewise, using IPSec tunnels on Win2k laptops for = remote access would not be supported (by the Win2k IPSec implementation) = to other vendors. This is documented in the VPN whitepapers:

http://www.microsoft.com/windows2000/libr= ary/howitworks/communications/remoteaccess/default.asp

You can save yourself a lot of trouble by using = certificates for the L2TP/IPSec client.  General IPSec transport = and tunnel configurations (where you configure IPSec policy manually) = can use any of 3 authentication methods.  Most major CA vendors = have web pages and other enrollment methods for you to get a certificate = into the machine store on the win2k client.  If you want to test = win2k L2TP/IPSec with certificates, use the procedure in my walkthrough = document below which provides links to the publicly available Microsoft = test CAs.  For gateways you can do cut & paste of PKCS#10 & = #7, and they support SCEP, provided in the Windows 2000 Resource = Kit.

The IPSec tunnel mode in win2k is negotiated using IKE = RFC 2409's tunneling capability - which does not provide address = assignment necessary for remote access applications.  As most IPSec = vendors know, but most casual observers on the list don't, many vendors = have made proprietary and/or non-RFC extensions to IKE to make it useful = for IPSec tunneling in remote access scenarios.  This involves = support for the drafts commonly referred to as IKECFG (mode config) and = XAUTH.  Win2k's IKE does not support these extensions.  =

For those vendors which do not provide L2TP/IPSec = gateway functionality, and thus do not work with the native Windows 2000 = L2TP/IPSec client, they provide their own IPSec-based remote access = client.  In most cases you need to get a version of the client that = works on Windows 2000.

However, when win2k end systems and Win2k gateways = have static IP addresses - they could be configured (by network admins = who understand IPSec, not end-users) to use IPSec tunneling to another = IPSec gateway.  This should interoperate in at least simple = configurations with most other gateways.  A number of = demonstrations over the last year have shown this = interoperability.

Please send me private email if you need = clarification.  But please do not ask if win2k interoperates with = vendor xxx doing yyy.  There are over 200,000 combinations of = IPSec/IKE configurations between two peers.  We use KB articles to = document known cases where special configuration is required to work = with another vendor.  The KB article Q265112 contains the news = groups which provide user support for configuration if you are unable to = reach a technical support engineer.  If you have successfully = configured two different products to work together, then I'd be happy to = receive the configuration steps to assist our support engineers.  =

(and yes, I configured outlook to do plain text, but = apparently some extra formatting is present.  I apologize if this = causes your reader problems.)

Wm
William Dixon
Program Manager - Network Security
Windows Operating Systems Division
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: WDixon@microsoft.com (preferred), Work: = 425-703-8729

Feb '00 Windows 2000 IPSec end-to-end walkthrough = & mini-whitepaper (which covers IKE's use of certificates): http://www.microsoft.com/windows2000/library/technologies/= security/default.asp


-----Original Message-----
From: William Dixon
Sent: Wednesday, September 27, 2000 1:30 PM
To: 'Michael Milbach'; ipsec@lists.tislabs.com
Subject: RE: ipsec and win2k


See http://support.microsoft.com = KB article


-----Original Message-----
From: Michael Milbach [mailto:mmilbach@mentortech.com]
Sent: Thursday, September 21, 2000 12:55 PM
To: ipsec@lists.tislabs.com
Subject: ipsec and win2k


Can anyone please point me to some documentation on = IPsec Tunneling between
to win2k boxes.  I already have been through = M$'s support, and have some
information, but the one Tunneling example given is = for one unique
circumstance with little explanation.  Any = direction would be appreciated.

TIA

Michael
*******************
Michael Milbach
Mentor Technologies Group

Cell:    240-460-0073
Office:  301-680-3562

*******************
Mentor Technologies Group:
We're high tech, high touch, high performance; the = total learning solutions
company.

------_=_NextPart_001_01C028C7.8CF763C0-- From owner-ipsec@lists.tislabs.com Wed Sep 27 20:59:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15170; Wed, 27 Sep 2000 20:59:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22346 Wed, 27 Sep 2000 22:35:31 -0400 (EDT) Message-ID: <39D2B082.ECE26BD2@storm.ca> Date: Wed, 27 Sep 2000 22:44:18 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: who does ESP padding > 8 bytes ? References: <6A05D00595BE644E9F435BE5947423F2038CB816@fifi.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > William Dixon wrote: > > Does anyone have an IPSec implementation w/IKE that inserts greater than 8 bytes of ESP padding. I'm aware of two that use up > to 8, but none that use more than 8. > A final choice on AES is due Real Soon Now: http://csrc.nist.gov/encryption/aes/ Once that happens, presumably several implementations will begin using AES with its 16-byte block size. At that point, the answer to your question will likely change. From owner-ipsec@lists.tislabs.com Thu Sep 28 08:44:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16970; Thu, 28 Sep 2000 08:44:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24389 Thu, 28 Sep 2000 10:11:20 -0400 (EDT) Date: Thu, 28 Sep 2000 10:22:30 -0400 From: Jerome Etienne To: ipsec@lists.tislabs.com Subject: Re: who does ESP padding > 8 bytes ? Message-ID: <20000928102230.A3236@host-36.dyn.cia.zks.net> References: <6A05D00595BE644E9F435BE5947423F2038CB816@fifi.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6A05D00595BE644E9F435BE5947423F2038CB816@fifi.platinum.corp.microsoft.com>; from wdixon@Exchange.Microsoft.com on Wed, Sep 27, 2000 at 02:13:24PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 27, 2000 at 02:13:24PM -0700, William Dixon wrote: > Does anyone have an IPSec implementation w/IKE that inserts greater than > 8 bytes of ESP padding. I'm aware of two that use up to 8, but none > that use more than 8. why this implementation limit of 8 when the protocol maximum is 255 ? From owner-ipsec@lists.tislabs.com Thu Sep 28 09:12:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18353; Thu, 28 Sep 2000 09:12:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24534 Thu, 28 Sep 2000 11:01:13 -0400 (EDT) Date: Wed, 27 Sep 2000 18:49:09 -0400 From: Richard Guy Briggs To: William Dixon Cc: Michael Milbach , ipsec@lists.tislabs.com Subject: Re: ipsec and win2k Message-ID: <20000927184909.J28566@grendel.conscoop.ottawa.on.ca> References: <6A05D00595BE644E9F435BE5947423F2038CB815@fifi.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6A05D00595BE644E9F435BE5947423F2038CB815@fifi.platinum.corp.microsoft.com>; from wdixon@Exchange.Microsoft.com on Wed, Sep 27, 2000 at 02:11:49PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, Sep 27, 2000 at 02:11:49PM -0700, William Dixon wrote: > Hit reply too soon, I meant to add that tunnel configuration is detailed > in KB article #Q252735. Since I'm posting, I'll add the following text > that I keep mailing individually to people. I apologize to the rest of > you who already know this. I don't already know this, but didn't subscribe to a general IPSEC list to get M$ support information. Is there not a M$ support network for this kind of thing? We don't do FreeS/WAN support on this list. > William Dixon slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOdJ5Yt+sBuIhFagtAQFaxAP/RVtQUqCKEJBAwrXfUmPbTkI4W73cWh8U vAgWOkkA88SZY2bIdrXDsuxcVjF3g5KKUYql+5SE/Qlpbzs5xbvF/FHlLX7eMDjA T486FlUd19HXy6yq/Gb9V7FEUPsEEGSqZdflnxXCgcNmdQFtLozXz29hH1wd7M9s 1MhOICHe66k= =tNd0 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Sep 28 09:24:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19418; Thu, 28 Sep 2000 09:24:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24516 Thu, 28 Sep 2000 10:55:54 -0400 (EDT) Message-ID: <39D35E7E.DFCE73EB@research.telcordia.com> Date: Thu, 28 Sep 2000 11:06:38 -0400 From: Sanjai Narain X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Replacing private lines with tunnels References: <200009271424.HAA21557@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suppose gateway routers at several corporate sites are linked by a network of private (dedicated) lines. OSPF is configured on these routers. Since each each private line is a single IP subnet, OSPF would -automatically- accomplish any-to-any connectivity between the gateway routers. Now suppose the private lines are replaced by IPSec tunnels. Then any-to-any connectivity will be lost. This is because router interfaces at tunnel endpoints will, in general, not belong to the same subnet, so OSPF won't work. So, what can be done to restore any-to-any connectivity between the gateway routers? In particular, do people implement a form of static routing over tunnels, i.e., direct the traffic coming out of one tunnel into another? -- Sanjai -- Sanjai Narain Senior Research Scientist Telcordia Technologies Tel: +1 973 829 4515 Fax: +1 973 829 5888 Email: narain@research.telcordia.com From owner-ipsec@lists.tislabs.com Thu Sep 28 09:36:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19804; Thu, 28 Sep 2000 09:36:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24637 Thu, 28 Sep 2000 11:21:08 -0400 (EDT) Date: Thu, 28 Sep 2000 11:30:08 -0400 From: Richard Guy Briggs To: Jerome Etienne Cc: ipsec@lists.tislabs.com Subject: Re: who does ESP padding > 8 bytes ? Message-ID: <20000928113008.A28566@grendel.conscoop.ottawa.on.ca> References: <6A05D00595BE644E9F435BE5947423F2038CB816@fifi.platinum.corp.microsoft.com> <20000928102230.A3236@host-36.dyn.cia.zks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000928102230.A3236@host-36.dyn.cia.zks.net>; from jerome@zeroknowledge.com on Thu, Sep 28, 2000 at 10:22:30AM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, Sep 28, 2000 at 10:22:30AM -0400, Jerome Etienne wrote: > On Wed, Sep 27, 2000 at 02:13:24PM -0700, William Dixon wrote: > > Does anyone have an IPSec implementation w/IKE that inserts greater than > > 8 bytes of ESP padding. I'm aware of two that use up to 8, but none > > that use more than 8. > > why this implementation limit of 8 when the protocol maximum is 255 ? For some time, I have been considering padding to a random 8-byte boundary between 0 and 255 to thwart traffic analysis... I'll take this to the FreeS/WAN list... William, please don't break things by assuming nobody uses more than 8. It is in the spec for a reason... slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOdNj/d+sBuIhFagtAQEM4AP+O45eIUsOinCocLZRlWT3uZ8Lc1tzUkiC MtjKVTH+6oK8m7cFHwTsSxllnqVw3/YTk78q0ye7M8EI5BUbM6mgGszhaeBP68n5 Qilk2skA8W46LgxXWIPnIK/ayCiqTdldo9rbGU9h7dF0xzfBcVfpujLe/hcAaDRo 1oFMJqSX1hY= =MThW -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Sep 28 11:57:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24421; Thu, 28 Sep 2000 11:57:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25021 Thu, 28 Sep 2000 13:42:00 -0400 (EDT) Message-Id: <200009281751.e8SHpsE21918@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Jerome Etienne Cc: ipsec@lists.tislabs.com Subject: Re: who does ESP padding > 8 bytes ? In-reply-to: Your message of "Thu, 28 Sep 2000 10:22:30 EDT." <20000928102230.A3236@host-36.dyn.cia.zks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 13:51:54 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000928102230.A3236@host-36.dyn.cia.zks.net>, Jerome Etienne write s: > >why this implementation limit of 8 when the protocol maximum is 255 ? I don't think it's an implementation limit (at least not in the receive side -- you have to be able to deal with more than 8 bytes of padding); the OpenBSD IPsec can generate and handle up to 254 (which is really the maximum) bytes of padding, it's just that I never felt the need to actually generate more than 6. -Angelos From owner-ipsec@lists.tislabs.com Thu Sep 28 18:02:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02767; Thu, 28 Sep 2000 18:02:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25977 Thu, 28 Sep 2000 19:38:27 -0400 (EDT) Date: Thu, 28 Sep 2000 16:49:07 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Sanjai Narain cc: ipsec@lists.tislabs.com Subject: Re: Replacing private lines with tunnels In-Reply-To: <39D35E7E.DFCE73EB@research.telcordia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess, you could use GRE tunnels, to simulate the private lines over the Internet, and then secure the GRE tunnels using IPSec (probably transport mode). OSPF can run as before, which each GRE tunnel as a point-to-point link. chinna On Thu, 28 Sep 2000, Sanjai Narain wrote: > Suppose gateway routers at several corporate sites are linked by a network of > private (dedicated) lines. OSPF is configured on these routers. Since each each > private line is a single IP subnet, OSPF would -automatically- accomplish > any-to-any connectivity between the gateway routers. Now suppose the private > lines are replaced by IPSec tunnels. Then any-to-any connectivity will be lost. > This is because router interfaces at tunnel endpoints will, in general, not > belong to the same subnet, so OSPF won't work. > > So, what can be done to restore any-to-any connectivity between the gateway > routers? In particular, do people implement a form of static routing over > tunnels, i.e., direct the traffic coming out of one tunnel into another? > > -- Sanjai > > -- > Sanjai Narain > Senior Research Scientist > Telcordia Technologies > Tel: +1 973 829 4515 Fax: +1 973 829 5888 > Email: narain@research.telcordia.com > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Sep 29 12:19:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05392; Fri, 29 Sep 2000 12:19:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00168 Fri, 29 Sep 2000 13:51:06 -0400 (EDT) Date: Fri, 29 Sep 2000 14:01:46 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: ICMP "Destination unreachable" - should it be sent? In-Reply-To: <20000927085920.B11807@blackbird.extern.uni-ulm.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 27 Sep 2000, Stefan Schlott wrote: > ..."Destination Unreachable Message > Code 1 - communication with destination administratively prohibited" > Should this message be sent when a packet does not conform to the local > security policy database (spd), or should such packets be silently dis- > carded? The central question is whether the ICMP message is believable. If it will flow via an authenticated path (e.g. an IPsec tunnel) or via a physically-secure path (e.g. on the "interior" side of a security gateway, where plaintext communication is normal), then sending it is probably wise... although administrators might want to be able to control that. If it will flow via an insecure path, then what good is it? The receiver can't trust it to tell the truth. At most, it might give the receiver a hint that communications difficulties are occurring, but the receiver cannot trust that report without confirming it by other means. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Sep 29 15:49:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13836; Fri, 29 Sep 2000 15:49:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00711 Fri, 29 Sep 2000 17:34:59 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14805.3467.20133.51811@thomasm-u1.cisco.com> Date: Fri, 29 Sep 2000 14:45:47 -0700 (PDT) To: Henry Spencer Cc: IP Security List Subject: Re: ICMP "Destination unreachable" - should it be sent? In-Reply-To: References: <20000927085920.B11807@blackbird.extern.uni-ulm.de> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Wed, 27 Sep 2000, Stefan Schlott wrote: > > ..."Destination Unreachable Message > > Code 1 - communication with destination administratively prohibited" > > Should this message be sent when a packet does not conform to the local > > security policy database (spd), or should such packets be silently dis- > > carded? > > The central question is whether the ICMP message is believable. > > If it will flow via an authenticated path (e.g. an IPsec tunnel) or via a > physically-secure path (e.g. on the "interior" side of a security gateway, > where plaintext communication is normal), then sending it is probably > wise... although administrators might want to be able to control that. > > If it will flow via an insecure path, then what good is it? The receiver > can't trust it to tell the truth. At most, it might give the receiver a > hint that communications difficulties are occurring, but the receiver > cannot trust that report without confirming it by other means. This strikes me as completely backward: the sender should *always* send it. It is the *receiver's* job to determine whether it is believable. Having the sender second guess what the receiver should and should not discard sounds like a great way to cause an interoperability deadlock. Mike