From Nicolas.Williams at sun.com Tue Sep 13 22:59:52 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 14 Sep 2005 00:59:52 -0500 Subject: [anonsec] draft-williams-btns-00.txt Message-ID: <20050914055952.GF26789@binky.Central.Sun.COM> A new I-D, draft-williams-btns-00.txt, based on feedback at Paris and on the list is now available. Nico -- From jari.arkko at piuha.net Wed Sep 14 03:03:22 2005 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 14 Sep 2005 13:03:22 +0300 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <20050914055952.GF26789@binky.Central.Sun.COM> References: <20050914055952.GF26789@binky.Central.Sun.COM> Message-ID: <4327F56A.6040102@piuha.net> This draft is major improvement from the previous one. Overall, I like the approach. Its simple. It seems to satisfy both goals that I think are important, i.e., "anonymous encryption" (= unauthenticated SA) and "leap of faith" styles. I like the way that this is integrated to the rest of the policy processing. Some comments below, however: Technical: >4. Security Considerations > Is there an issue with the use of tunnel mode without proper settings? E.g., A establishes a tunnel mode SA with the a gateway that uses A's addresses on the outside but B's addresses on the inside, grabbing B's traffic. (But I may be missing something here.) Another potential issue is establishing a btns-willing node as a gateway to tunnel illegal traffic through this unsuspecting victim. >Another possible > mitigation would be to prompt a user about each leap-of-faith BTNS > policy entry instantiation. > > The text should probably say something about this being hard. For instance, a router sitting in a cabinet may not have means to ask its "user" about whether the new entry is appropriate. >3. Leap-of-Faith BTNS > > Implementors may provide a PAD entry attribute used to indicate that > the given PAD entry is a template that should, when matched, cause > new PAD and SPD entries to be created binding the matching peer's IP > address and BTNS ID (i.e., public key) by using the PUBLICKEY ID > selector to match on the peer's public key. Entries created this way > have to be persistent, for some value of "persistent," though we > RECOMMEND that "persistent" mean "until manually removed. > > The interesting question is what IP address you are talking about above. I think you mean the peer's address that is visible in the IKE packets. But I wonder if that's the best approach. You could also imagine binding between the ID and the inner address. In transport mode there's no difference, but in tunnel mode the relevant address is really the inner one. What about IKEv2's configuration mechanisms, would that be tied to this binding? E.g., when you connect for the first time, you will be allocated an IP address and then on subsequent connections, you will get/ must use that same IP address. > Use with applications that bind authentication at higher network > layers to secure channels at lower layers may provide one secure way > to use unauthenticated IPsec, but this is not specified herein and. > > Question: In IKEv2 EAP mode the gateway end needs to be authenticated by a cert, even if there might be mutual authentication in the underlying EAP scheme that is being used. Does this draft allow the usage of unauthenticated mode in this scenario? Editorial: > The conditions under which a BTNS-capable IKE/IKEv2 implementation > MUST accept an IKE_SA that it would otherwise reject are such where > the reasons for rejection relate only to the peer's CERT payload, > namely: > > Is MUST really appropriate here, or this rather a SHOULD? > Implementors may provide a PAD entry attribute used to indicate that > s/may/MAY/ ? > o For BTNS IKE and IKEv2 MUST coerce the IDs of peers whose CERT > payloads could not be validated (in certain conditions, see below) > to PUBLICKEY IDs whose values correspond to the public key used by > the peer (if the peer used a certificate, then the certificate's > subjectPublicKey) that can only be matched by either the 'UNKNOWN' > ID selector wildcard value or a PUBLICKEY ID selector with that > same key as its value; of course, HASH/AUTH payloads must be > validated. > > This paragraph was hard to parse. --Jari From Nicolas.Williams at sun.com Wed Sep 14 07:46:43 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 14 Sep 2005 09:46:43 -0500 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <4327F56A.6040102@piuha.net> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> Message-ID: <20050914144643.GB29692@binky.Central.Sun.COM> On Wed, Sep 14, 2005 at 01:03:22PM +0300, Jari Arkko wrote: > This draft is major improvement from the previous one. > Overall, I like the approach. Its simple. It seems to satisfy both > goals that I think are important, i.e., "anonymous > encryption" (= unauthenticated SA) and "leap of faith" styles. > I like the way that this is integrated to the rest of the policy > processing. Glad you like it; much credit goes to Charlie and all who commented on the previous I-D. > Some comments below, however: > > Technical: > > >4. Security Considerations > > > Is there an issue with the use of tunnel mode without > proper settings? E.g., A establishes a tunnel mode SA > with the a gateway that uses A's addresses on the > outside but B's addresses on the inside, grabbing > B's traffic. (But I may be missing something here.) > > Another potential issue is establishing a btns-willing > node as a gateway to tunnel illegal traffic through this > unsuspecting victim. There's two issues with tunnelling: - applications can't do channel bindings to tunnels (one end-point may see the tunnel, but the other won't, unless the other is at the SG); - a tunnel can carry traffic for many nodes which might consider BTNS inappropriate but have no choice as they have no knowledge of what the SG is doing, whereas end-to-end BTNS can only carry traffic for two nodes that have all the information they need to decide whether to engage in conversation. Now, you could start a BTNS tunnel, then run an application at the client and SG to do authentication and channel binding, then start actual packet forwarding at the SG; that would be fine. But I think that would: a) be out of scope for this I-D, b) replicate functionality that's already in IKEv2. So I'd rather limit this I-D to end-to-end IPsec and leave tunnels out of scope. > >Another possible > > mitigation would be to prompt a user about each leap-of-faith BTNS > > policy entry instantiation. > > > > > The text should probably say something about this being > hard. For instance, a router sitting in a cabinet may not > have means to ask its "user" about whether the new entry > is appropriate. Sure. > >3. Leap-of-Faith BTNS > > > > Implementors may provide a PAD entry attribute used to indicate that > > the given PAD entry is a template that should, when matched, cause > > new PAD and SPD entries to be created binding the matching peer's IP > > address and BTNS ID (i.e., public key) by using the PUBLICKEY ID > > selector to match on the peer's public key. Entries created this way > > have to be persistent, for some value of "persistent," though we > > RECOMMEND that "persistent" mean "until manually removed. > > > > > The interesting question is what IP address you are talking > about above. I think you mean the peer's address that is > visible in the IKE packets. But I wonder if that's the best > approach. You could also imagine binding between the ID > and the inner address. In transport mode there's no > difference, but in tunnel mode the relevant address is > really the inner one. Since we're talking end-to-end, not tunnels, there should be no ambiguity as to which IP address to use, no? > What about IKEv2's configuration mechanisms, would > that be tied to this binding? E.g., when you connect > for the first time, you will be allocated an IP address > and then on subsequent connections, you will get/ > must use that same IP address. Would this be used in non-tunnel situations? > > Use with applications that bind authentication at higher network > > layers to secure channels at lower layers may provide one secure way > > to use unauthenticated IPsec, but this is not specified herein and. > > > > > Question: In IKEv2 EAP mode the gateway end needs to > be authenticated by a cert, even if there might be > mutual authentication in the underlying EAP scheme > that is being used. Does this draft allow the usage > of unauthenticated mode in this scenario? I'd rather not address tunnels here, but, I could see this being allowed provided that the selected EAP method provides EAP cryptographic and channel bindings and is acceptable to the client for use w/o SG certs. > Editorial: > > > The conditions under which a BTNS-capable IKE/IKEv2 implementation > > MUST accept an IKE_SA that it would otherwise reject are such where > > the reasons for rejection relate only to the peer's CERT payload, > > namely: > > > > > Is MUST really appropriate here, or this rather a SHOULD? I think MUST as this is necessary for BTNS to work, but don't yet feel strongly about it. > > Implementors may provide a PAD entry attribute used to indicate that > > > s/may/MAY/ ? I'd be happy either way. > > o For BTNS IKE and IKEv2 MUST coerce the IDs of peers whose CERT > > payloads could not be validated (in certain conditions, see below) > > to PUBLICKEY IDs whose values correspond to the public key used by > > the peer (if the peer used a certificate, then the certificate's > > subjectPublicKey) that can only be matched by either the 'UNKNOWN' > > ID selector wildcard value or a PUBLICKEY ID selector with that > > same key as its value; of course, HASH/AUTH payloads must be > > validated. > > > > > This paragraph was hard to parse. Would removing the parentheticals and splitting the sentence at "that" and at the semi-colon help? The text in the second paren could be made a separate sentence too. I'll smith it. Nico -- From sommerfeld at sun.com Wed Sep 14 09:16:52 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Wed, 14 Sep 2005 12:16:52 -0400 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <20050914144643.GB29692@binky.Central.Sun.COM> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> Message-ID: <1126714611.10426.49.camel@thunk> On Wed, 2005-09-14 at 10:46, Nicolas Williams wrote: > So I'd rather limit this I-D to end-to-end IPsec and leave tunnels out > of scope. Agreed. My preference would be for transport mode only, but I can live with using a "self-tunnel" mode where the respective inner and outer addresses are required to match. - Bill From lha at it.su.se Wed Sep 14 09:35:46 2005 From: lha at it.su.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 14 Sep 2005 18:35:46 +0200 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <20050914055952.GF26789@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 14 Sep 2005 00:59:52 -0500") References: <20050914055952.GF26789@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050914/732788ca/attachment.bin From jari.arkko at piuha.net Wed Sep 14 16:10:12 2005 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu, 15 Sep 2005 02:10:12 +0300 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <1126714611.10426.49.camel@thunk> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> Message-ID: <4328ADD4.4070600@piuha.net> Bill Sommerfeld wrote: >Agreed. > >My preference would be for transport mode only, but I can live with >using a "self-tunnel" mode where the respective inner and outer >addresses are required to match. > > I think we need to do one of three things - document that the configuration of btns with tunnel mode is a bad idea, require implementations to prevent this, or to develop some specific rules when tunnel mode usage is safe (and useful - this may be the harder exercise). I also think that the default assumption is transport mode only, but I'm not sure I personally understand all aspects of this decision yet. Specifically, it might be interesting to think some more about the potential implications wrt usage scenarios. Is there some potential usage that we are preventing if we don't allow tunnel mode? I don't see any right now, but it doesn't mean that they don't exist... --Jari From Nicolas.Williams at sun.com Wed Sep 14 19:43:37 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 14 Sep 2005 21:43:37 -0500 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <4328ADD4.4070600@piuha.net> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> Message-ID: <20050915024337.GM29692@binky.Central.Sun.COM> On Thu, Sep 15, 2005 at 02:10:12AM +0300, Jari Arkko wrote: > I think we need to do one of three things - document that > the configuration of btns with tunnel mode is a bad idea, > require implementations to prevent this, or to develop > some specific rules when tunnel mode usage is safe (and > useful - this may be the harder exercise). > > I also think that the default assumption is transport mode > only, but I'm not sure I personally understand all aspects > of this decision yet. Specifically, it might be interesting > to think some more about the potential implications wrt > usage scenarios. Is there some potential usage that we > are preventing if we don't allow tunnel mode? I don't > see any right now, but it doesn't mean that they don't > exist... None that couldn't be enabled through a separate I-D. We should explicitly leave tunnel mode BTNS out of scope; I see explaining why as gravy, though I certainly don't mind. I did describe a reasonable use for tunnel mode BTNS earlier, but it's nothing that couldn't be done with IKEv2 w/ EAP... Cheers, Nico -- From pekka.nikander at nomadiclab.com Thu Sep 15 00:19:06 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 15 Sep 2005 09:19:06 +0200 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <4328ADD4.4070600@piuha.net> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> Message-ID: <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> > usage scenarios. Is there some potential usage that we > are preventing if we don't allow tunnel mode? IIRC, someone (David Black?) mentioned at the Paris meeting that some IP storage solutions currently require tunnel mode. Therefore our f2f decision was to include tunnel mode where the inner and outer addresses are equal. From the minutes: (http://www.ietf.org/proceedings/05aug/minutes/ btns.html) 1. Need to support tunnel mode where inner address is the same as outer address. This is because of requirements of other protocols, such as iSCSI that have tunnel mode as MUST. --Pekka From kivinen at iki.fi Thu Sep 15 04:26:16 2005 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 15 Sep 2005 14:26:16 +0300 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> Message-ID: <17193.23128.486931.373479@fireball.kivinen.iki.fi> Pekka Nikander writes: > > usage scenarios. Is there some potential usage that we > > are preventing if we don't allow tunnel mode? > > IIRC, someone (David Black?) mentioned at the Paris meeting that some > IP storage solutions currently require tunnel mode. Therefore our > f2f decision was to include tunnel mode where the inner and outer > addresses are equal. Also NAT-T is simplier if done on tunnel mode, no need to mess around with original IP-addresses and updating checksums. In NAT-T case the inner and outer addresses are not equal, as outer address is the NAT-boxeses address, and inner address is the endpoints address. I do not think if the NAT-T is relevant to the btns... -- kivinen at safenet-inc.com From jari.arkko at piuha.net Thu Sep 15 05:13:34 2005 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu, 15 Sep 2005 15:13:34 +0300 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <17193.23128.486931.373479@fireball.kivinen.iki.fi> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> <17193.23128.486931.373479@fireball.kivinen.iki.fi> Message-ID: <4329656E.5000009@piuha.net> Tero Kivinen wrote: >Also NAT-T is simplier if done on tunnel mode, no need to mess around >with original IP-addresses and updating checksums. In NAT-T case the >inner and outer addresses are not equal, as outer address is the >NAT-boxeses address, and inner address is the endpoints address. I do >not think if the NAT-T is relevant to the btns... > > NAT-T is probably relevant to anything that deals with end-user devices. Anyway, the same problem with addresses not being equal appears also in MOBIKE, should that be used together with BTNS (and it too only works for tunnel mode, at least for now). --Jari From Nicolas.Williams at sun.com Thu Sep 15 09:12:29 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 15 Sep 2005 11:12:29 -0500 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> <4A3E6212-A258-4826-A1BF-A6B6D350AC3E@nomadiclab.com> Message-ID: <20050915161229.GB1191@binky.Central.Sun.COM> On Thu, Sep 15, 2005 at 09:19:06AM +0200, Pekka Nikander wrote: > >usage scenarios. Is there some potential usage that we > >are preventing if we don't allow tunnel mode? > > IIRC, someone (David Black?) mentioned at the Paris meeting that some > IP storage solutions currently require tunnel mode. Therefore our > f2f decision was to include tunnel mode where the inner and outer > addresses are equal. > > From the minutes: (http://www.ietf.org/proceedings/05aug/minutes/ > btns.html) > > 1. Need to support tunnel mode where inner address is the same as > outer address. > > This is because of requirements of other protocols, such as iSCSI > that have tunnel mode as MUST. Tunnelling, as opposed to "tunnel mode" SAs, is what would be out of scope in the I-D. To me that's the real distinction between "tunnel" and "transport" -- not labelling on the wire in IKE, or in an SADB, but how the things are used. Tunnels are, well tunnels, and you can make tunnels out of transport mode IPsec by doing IP-IP tunnelling. Similarly there's no requirement that tunnel mode SAs be used for anything other than end-to-end purposes. Nico -- From mohanp at sbcglobal.net Thu Sep 15 13:11:06 2005 From: mohanp at sbcglobal.net (Mohan Parthasarathy) Date: Thu, 15 Sep 2005 13:11:06 -0700 Subject: [anonsec] draft-williams-btns-00.txt References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net><20050914144643.GB29692@binky.Central.Sun.COM><1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> Message-ID: <00ee01c5ba31$9b64b740$6701a8c0@adithya> > > > >My preference would be for transport mode only, but I can live with > >using a "self-tunnel" mode where the respective inner and outer > >addresses are required to match. > > > > > I think we need to do one of three things - document that > the configuration of btns with tunnel mode is a bad idea, > require implementations to prevent this, or to develop > some specific rules when tunnel mode usage is safe (and > useful - this may be the harder exercise). > Perhaps, i missed the discussion earlier. What is the problem with supporting it for tunnel mode ? thanks mohan > I also think that the default assumption is transport mode > only, but I'm not sure I personally understand all aspects > of this decision yet. Specifically, it might be interesting > to think some more about the potential implications wrt > usage scenarios. Is there some potential usage that we > are preventing if we don't allow tunnel mode? I don't > see any right now, but it doesn't mean that they don't > exist... > > --Jari > > _______________________________________________ From Nicolas.Williams at sun.com Thu Sep 15 13:47:22 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 15 Sep 2005 15:47:22 -0500 Subject: [anonsec] draft-williams-btns-00.txt In-Reply-To: <00ee01c5ba31$9b64b740$6701a8c0@adithya> References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> <00ee01c5ba31$9b64b740$6701a8c0@adithya> Message-ID: <20050915204722.GK1191@binky.Central.Sun.COM> On Thu, Sep 15, 2005 at 01:11:06PM -0700, Mohan Parthasarathy wrote: > > > > > >My preference would be for transport mode only, but I can live with > > >using a "self-tunnel" mode where the respective inner and outer > > >addresses are required to match. > > > > > > > > I think we need to do one of three things - document that > > the configuration of btns with tunnel mode is a bad idea, > > require implementations to prevent this, or to develop > > some specific rules when tunnel mode usage is safe (and > > useful - this may be the harder exercise). > > > Perhaps, i missed the discussion earlier. What is the problem with supporting > it for tunnel mode ? http://www.postel.org/pipermail/anonsec/2005-September/date.html From hartmans-ietf at mit.edu Tue Sep 20 12:13:24 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 20 Sep 2005 15:13:24 -0400 Subject: [anonsec] [IESG Secretary] Evaluation: draft-bellovin-useipsec-04.txt to BCP Message-ID: An embedded message was scrubbed... From: IESG Secretary Subject: Evaluation: draft-bellovin-useipsec-04.txt to BCP Date: Tue, 20 Sep 2005 11:45:56 -0400 Size: 5398 Url: http://www.postel.org/pipermail/anonsec/attachments/20050920/970e0efd/attachment.mht From pekka.nikander at nomadiclab.com Thu Sep 22 01:36:40 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 22 Sep 2005 10:36:40 +0200 Subject: [anonsec] [IESG Secretary] Evaluation: draft-bellovin-useipsec-04.txt to BCP In-Reply-To: References: Message-ID: <62B73FB6-AD72-4102-86C6-24C412434955@nomadiclab.com> Sam, below, On Sep 20, 2005, at 21:13, Sam Hartman wrote: > I don't know whether the following document was ever last called. > however people in the BTNS working group may want to review it and see > whether its advice is in alignment with the direction we are going. > > Please let me know by the end of the week this week if there are any > significant blocking issues. > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt I briefly re-reviewed the document (I had read an earlier version of it), and I didn't see substantial issues. AFAICT, BTNS work is not likely to change the situation as described in Sections 3.4, 5, or 6 any soon, even though I of course hope that we will eventually be able to change it. Hence, my only comment is that the document is very much looking at the currently deployed situation, and at protocols that must work with what is out there now and can't require anything more. For protocols that would require changes to the kernel anyway, there might be a slightly wider set of options available, since it might be reasonable to expect small changes (such as better API) to the local IPsec implementation, too. So, maybe a note stating that the document describes the situation as out there now, and that while there are likely to be other options in the future, people are not recommended to keep their breath unless they plan to do substantial changes to the IP, or transport, or API part of the stack? Leaving BTNS behind, I didn't see the document to discuss mobility at difficulties related to that at all. But maybe you have already brought this to the attention of the MOBIKE WG? (I am currently not following that WG.) --Pekka Nikander From touch at ISI.EDU Fri Sep 23 11:02:02 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 23 Sep 2005 11:02:02 -0700 Subject: [anonsec] [IESG Secretary] Evaluation: draft-bellovin-useipsec-04.txt to BCP In-Reply-To: <62B73FB6-AD72-4102-86C6-24C412434955@nomadiclab.com> References: <62B73FB6-AD72-4102-86C6-24C412434955@nomadiclab.com> Message-ID: <4334431A.9020502@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I posted my comments off-line, but some of them are germane to this reply... Pekka Nikander wrote: > Sam, below, > > On Sep 20, 2005, at 21:13, Sam Hartman wrote: > >>I don't know whether the following document was ever last called. >>however people in the BTNS working group may want to review it and see >>whether its advice is in alignment with the direction we are going. >> >>Please let me know by the end of the week this week if there are any >>significant blocking issues. > > >>http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt > > I briefly re-reviewed the document (I had read an earlier version of > it), > and I didn't see substantial issues. AFAICT, BTNS work is not likely > to change the situation as described in Sections 3.4, 5, or 6 any > soon, even > though I of course hope that we will eventually be able to change it. Agreed - there's the question of whether to foreshadow or not. The doc already refers to a number of I-Ds in other places, so it'd still be useful and appropriate to add something. To that end, I noted 4 groups of mods that might be useful: BTNS-related: 1. to add a statement about BTNS at end sec 3.3 on key management and sec 4 on IPsec availability (where keying affects availability) i.e., the document doesn't note that key systems themselves cause IPsec to be hard to configure, and that's a significant impediment. Tunnel vs. transport related: 2. to add a statement about sec 3.2's tunnel vs. transport (vs. transport on IP tunnel, as you might expect I'd notice) The following two are just general input: 3. to clarify some statements, e.g., that "IP header" in some places is vague (original, vs encapsulation) 4. to explain when inadequacies in IPsec implementations are due to non-compliance vs. permitted implementation trade-offs (e.g., lack of port selectors vs. small key tables) Some of the personal positions made sweeping assertions about the future, or value judgements about current systems ('mistake', 'wrong') could also be stated more objectively and would result in a more useful document. > Leaving BTNS behind, I didn't see the document to discuss mobility at > difficulties related to that at all. But maybe you have already brought > this to the attention of the MOBIKE WG? (I am currently not following > that WG.) I also wonder why it didn't appear to have been posted to the ipsec mailing list for feedback (unless it was and I missed it - I checked the archives and found no related post for the past year ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNEMaE5f5cImnZrsRAifdAJ9zF73hG+Fp4zBbZEs3YlxD/yrGMQCfSSZ6 9WEQcDMhfLGoDLENGY1P39Y= =m+tV -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Sep 23 17:27:25 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 23 Sep 2005 17:27:25 -0700 Subject: [anonsec] new problem and applicabilty statement available Message-ID: <43349D6D.5010102@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, A revised version of the P&AS I-D has been submitted which incorporates feedback from Sam and Steve. See http://www.postel.org/anonsec which includes a link to a copy (and other docs - let me know if I'm missing others), until it is available in the usual places. Feedback appreciated - and apologies in advance if I forgot to incorporate anything. Joe (for all authors of the doc) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNJ1tE5f5cImnZrsRArBvAJ9NnYkGDYQy/v94yjahwHlYgkyDLwCgzHEG 97XFyJuq6JJ4hGlPCJlgFK8= =8OOP -----END PGP SIGNATURE----- From Internet-Drafts at ietf.org Mon Sep 26 07:50:02 2005 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 26 Sep 2005 10:50:02 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-prob-and-applic-01.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-prob-and-applic-01.txt -------------- next part --------------