Hi Ted, Thanks for the speedy reply. Grumpy is allowed – you should hear me whine about reviews of my documents 😊 The purpose of the review is, of course, to help make the document better and more valuable when it is an RFC. So ignoring minor comments is reasonable. Please see in line for discussion, and me digging my heals in a little. Cheers, Adrian From: Ted Lemon <mellon@xxxxxxxxx> On Mon, Oct 28, 2024 at 9:33 PM Adrian Farrel via Datatracker <noreply@xxxxxxxx> wrote:
> We were trying really hard to leave the protocol work to the snac router document. > > The SNAC router flag is to be used by SNAC routers. The use of this flag is documented > in [I-D.ietf-snac-simple]. Devices that do not operate as SNAC routers [I-D.ietf-snac-simple] > MUST NOT set the SNAC router flag, and MUST silently ignore the SNAC router flag. > > So if you aren't a SNAC router, you aren't allowed to set the bit. If you are a SNAC router, > by definition, you implement the SNAC router specification, so you will know whether or > not to set the bit by reading the specification. I don't think we need additional text about this. Possibly I’m being dumb, but I wonder how a SNAC router knows it is a SNAC router. This could easily be fixed as… The SNAC router flag is to be used by SNAC routers. The configuration of SNAC routers and the use of this flag are documented in [I-D.ietf-snac-simple]. > You propose that this normative language isn't required here, because this is just what > RFC4861 already says. However, the motivation for putting normative language here is > to emphasize to the reader, who is not implementing the SNAC router spec, that they > aren't allowed to do anything at all with this bit. So I'm sympathetic to your complaing > about this, but I don't think punting to RFC4861 gets the point across. We really do want > readers who are not implementing SNAC to feel that there is a requirement that they not > use this bit for anything at all. No, I don’t propose that it isn’t required. I state that you must not use it! You should not use BCP14 for emphasis. That is not its purpose. And you cannot define the behavior, in this document, of an implementation that does not support this document. Hence my suggested replacement language (below). By all means paint this red, but you can only describe behavior of non-SNAC by reference to other RFCs that define their behavior.
> The point of this text, which is common to many specifications, is to avoid requiring > non-implementors to log the RA flags in such a way that the presence or absence of > this bit is not seen in the log. We have no interest in specifying how such implementations > log this bit: the point is precisely that we are not trying to tell them they can't log it.
> I don't think there is such a document. I find this a bit fragile. If it is “normal RA processing” then I would expect it to be defined elsewhere. But if it isn’t, well, I guess it has been poorly documented for a while.
> Why do we need to say this? This document is specifying a flag. We are not interested > in telling you how to set up RA guard: if you want to do that, presumably you know > how or can go look it up. Our goal here is simply to say that if you do set up RA guard, > devices on the network where it is active will not see these RAs because they will be > blocked. This text was added in response a review comment—my preference would > be to remove this text entirely. I don't think it serves any purpose. Certainly, removing the text would address my comment. But you have to keep all of the people happy all of the time. If RA guards are not described in any existing RFC, then including a mention here seems wrong. If they are described elsewhere, then a pointer should be easy.
> RFC4861 section 4.2. Great. So you’ll just include that?
> Non-SNAC routers aren't supposed to even listen to RAs. We really tried > not to specify protocol in this document based on both the 6man WG > consensus and the SNAC WG consensus. We're just trying to write the > document in such a way that someone who is not implementing a SNAC > router is clear that they should not set the bit, nor should they pay > attention to it. If you want to know more you should read the SNAC > document. A bit of repetition from the discussion above. I’m really not asking you to define protocol. In fact, I’m asking you to not define protocol! This is where my heals dig in – you cannot specify the behavior of a node that does not implement this document.
> Given that this document does not update RFC4861, I think you could reasonably (and > correctly) conclude that the treatment of these bits is as specificed in RFC4861. I think > it would be harmful to specify anything about such behavior here. I noted that even in 4861 there is a comment that one bit has no meaning when the other bit is set. So I wondered whether the S-bit always has meaning regardless of the setting of the other bits, and whether the other bits always have meaning if the S-bit is set. If you are saying that the S-bit has no interaction with any of the other bits defined so far (not just in 4861), then nothing more to say.
> There is no such risk. If you set the bit, your RA will be ignored in some situations where > it otherwise wouldn't be. Which is specified in the SNAC router document. Which we've > referenced. Well, the security considerations here do not reference draft-ietf-snac-simple. And given that the security considerations of draft-ietf-snac-simple don’t do more than reference 4861, that is probably just as well. So, there is an attack. If I set the S-bit in an RA it will cause the whole RA to be ignored in some circumstances. Presumably, also, if I set the S-bit in other circumstances, it will cause a non-SNAC router to be treated as a SNAC router. I agree there is nothing new here. I just believe that security risks should be called out, partial or complete solutions pointed to, and implementers/deployers left to make up their own minds.
> We don't reference those documents otherwise, so this seems like it would make things more, > not less, confusing. Our point in referencing RFC4861 is that that is the document in which the > RA flags are documented, so whatever security considerations it specifies are not changed by > this document. Yeah, OK. Just personal style. > Thanks for the review. Sorry if this sounds grumpy—I feel like I'm not taking any of your advice, > but I do appreciate the time you took to offer it. I think the source of disagreement is sort of a > usual one in the IETF: the "one document or two" question. We chose two because it felt like it > was out of scope to define this flag in the SNAC working group, since 6man has change control > over the Neighbor DIscovery spec, but that leaves us with a document that says nothing other > than what the bit is called and where to look if you're curious about what it does. :] Yeah, I know how that ends up happening. Let’s not try to fix it here! I’m not really a fan of breaking documents – I’d prefer to do cross-WG review. Best, Adrian |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
