[anonsec] comments on the BTNS core I-D
Nicolas.Williams at sun.com (Nicolas Williams) Mon, 30 July 2007 20:29 UTC
From: "Nicolas.Williams at sun.com"
Date: Mon, 30 Jul 2007 15:29:12 -0500
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <B0081A15-DB7E-4802-8AA1-4A0A94A9924E@electric-loft.org>
References: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> <20070730173138.GJ1199@Sun.COM> <B0081A15-DB7E-4802-8AA1-4A0A94A9924E@electric-loft.org>
Message-ID: <20070730202911.GP1199@Sun.COM>
On Mon, Jul 30, 2007 at 11:53:25AM -0700, Derrell Piper wrote: > On Jul 30, 2007, at 10:31 AM, Nicolas Williams wrote: > >On Mon, Jul 30, 2007 at 09:26:51AM -0700, Derrell Piper wrote: > >>Overall: > >> > >>'system' 'host' and 'node' are intermingled. 'node' in particular Actually, this is not the case. Looking at the usage in -04 I see - "system" is used as a synonym for "node" in one place; the other uses of it could be in reference to the implementation (as in "operating system") - "node" is mostly, but not always used when referring to a system operating with IPsec support - "host" is used only in reference to systems running behind a security gateway None of these uses seems to be inconsistent with the various glossaries of the IETF. For example, RFC1983 says this about "node": "An addressable device attached to a computer network. See also: host, router." And it says this about "host": "A computer that allows users to communicate with other host computers on a network. Individual users communicate by using application programs, such as electronic mail, Telnet and FTP. [Source: NNSC]." Whereas RFC2828 says this about "host": "(I) Specific Internet Protocol Suite usage: A networked computer that does not forward Internet Protocol packets that are not addressed to the computer itself. (See: router.)" Only RFC2828 defines "system": "(C) In this Glossary, the term is mainly used as an abbreviation for "automated information system"." From the usage of "system" elsewhere in RFC2828 I gather that "automated information system" means something like "computer." RFC4301 seems to use "system" to mean "networked computer" and includes, in some cases, intermediate systems ("A security gateway is an intermediate system..."). RFC4301 mostly does not refer to nodes, but it does not use "system" as having a single meaning ("system" usually appears in RFC4301 with or as a modifier). I see nothing about "node" denoting "possibly a cluster," only that it is a networked, addressable computer, including middle boxes (e.g., routers). OTOH, if a "node" can be replaced by a cluster of other nodes then presumably the cluster should behave as if it were a monolythic node to the best of the implementor's ability. And *this* leads me to conclude that "node" is a perfectly good word to be using in the BTNS core I-D, and in the way that we have used it. > >>implies > >>cluster to some of us and could easily be replaced with 'host' or > >>'system'. I simply fail to see where this implication comes from, although I do not reject the proposition that "every node could be a cluster [i.e., multiple systems behaving as though they were one]." And here I think "system" has a much broader meaning than "node," which leads me to conclude that... > >I'm not sure we want to do that. For one, nothing says that you can't > >cluster BTNS hosts. It is about as difficult to cluster BTNS hosts as > >it is to cluster hosts using IPsec in general (a little worse once you > >add connection latching if you use the dynamic IPsec policy editing > >implementation approach). > > If you just replace 'node' with either 'system' or 'host' throughout, > you'll address my point. ...to replace "node" with "system" would be inappropriate, and to replace "node" with "host" when some nodes in our examples are security gateways (and, therefore, a kind of router), is even more inappropriate still (since "host" is a "node" that does not forward packets, according to at least one glossary). I'd be happy to entertain an argument that "system" or some phrase including that word should replace "node" because RFC4301 does just that, but I've not seen such an argument. I'd also be happy to add a glossary, and to make sure that the I-D is consistent in its use of these three words, but this is a damned short I-D (particularly if you strip off the informative examples). Just how long must we make it?! And I'll note that RFC4301 does not define "system," nor "host," nor "node" in its glossary -- I think it doesn't even use "host" in the sense of "node that doesn't forward packets," which might make it a sloppily written RFC... But I think I'd rather conclude that English is not the formal language that ASN.1, XML, UML, etcetera are, and that this is actually a good thing. > >>You need to specify exactly what happens for every failure mode and > >>you ought to be sending IKE informational or Notify payloads for all > >>error cases. > > > >Failure is handled as specified in RFC4301 and RFC4306. There is a > >separate I-D adding an IKE notify payload to indicate to the peer that > >it has matched a BTNS PAD entry. > > Are there no new BNTS specific errors? Are they described somewhere > else? > > >>Your bracketed notation is confusing. The brackets aren't adding > >>anything. > > > >In the examples? > > Yes, but whatever. It's just notation. Agreed, it's just notation and we'll stick to it. > >>I generally don't like the idea of sending self-signed certificates > >>for ephemeral keys. If the point is solely to maintain IKEv2 > >>semantics, you should say that. Otherwise, there's little reason to > >>require the extra overhead of the certificate processing (and > >>parsing) when all you're really doing is extracting the public key > >>anyway. > > > >Sending such certs is an option, not a requirement. > > I dislike the reference to self-signed certificates here because I > believe the mere reference to them will encourage their use with BTNS > and I don't think that's goodness. It's adding complexity for no > additional value. Sorry, we're allowed to have MAYs, and we'll keep this one. Implementors are free to ignore this "MAY," as usual. > >>pg 6, Figure 1 > >> > >>"In this diagram, there are six end-nodes: A, B, C and D." > >> > >>That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? > > > >Yes. > > > >>"Node [D] has a non-fixed address." "non-fixed" meaning what > >>exactly? Why is that relevant? > > > >That it uses DHCP. Michael? > > I assumed as much but I don't see how that's relevant in your examples. It's relevant because dynamically addressed systems can take over each other's addresses with a modicum of active attack effort. Perhaps this needs to be explained in more detail. In -04 we removed text that referred to the problems that may arise from having PAD entries with large address constraints. We presented on these problems at earlier meetings; from Stephen's input we concluded that describing these problems was not important in this document, and that the consequent need to be rigorous in describing them would be a waste of our time. So perhaps it is, indeed, irrelevant now. But I'm not convinced that it's completely irrelevant: because such a system's address can be one of so many it becomes undesirable to write PAD entries for them that say to search the SPD by IP address; of course, we don't have example PAD/SPD entries for \[D\]. Perhaps the examples have served their purpose (help reviewers) and now it's time to remove them? Michael? > >I don't see the implication, particularly when the text is explicit > >about [C] not being protected from other BTNS nodes. > > We agree there's no protection. I still think the fact that you > mention 'rogue nodes' tends to make people question whether or not > BTNS is providing protection from this when in fact it does not (by > design). (FWIW, I do understand what you saying about C and the > PAD.) For now we'll leave this as is. > >>pg 9, "As [Q] has no formal relationship with [SG-B], rogues can > >>impersonate [B] (i.e., assert [B]'s addresses)." > >> > >>You need to specify what should happen if a second [B] or [SG-B] > >>comes along. > > > >I'm not sure what you mean here. > > Well, do you want to say anything about what you're going to do if > you encounter a second BTNS host that's asserting a conflict network > block (i.e., what are you going to do if you have a BTNS SA with SG-B > and then a second SG-B comes along)? The PAD says how to authenticate SG-B, and the text of the I-D tells you that a BTNS node cannot assert SG-B's addresses because child SA requests by BTNS peers MUST be rejected if they assert addresses that are referenced by other non-BTNS PAD entries. The next to last bullet in example #1 covers this too. Nico --
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Sam Hartman
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Nico
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Nicolas Williams