https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-snac-router-ra-flag-03
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>
Sent: 28 October 2024 21:11
To: Adrian Farrel <adrian@xxxxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-6man-snac-router-ra-flag.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
Subject: [Last-Call] Re: [IPv6]Opsdir last call review of draft-ietf-6man-snac-router-ra-flag-02
On Mon, Oct 28, 2024 at 9:33 PM Adrian Farrel via Datatracker <noreply@xxxxxxxx> wrote:
== Manageability issues ==
There is nothing substantive to say about manageability in this
document. That is, the manageability issues can largely be punted to
[I-D.ietf-snac-simple]. However, it is probably worth pointing that out
to readers of this document. For example,
- How does a router know that it should set the SNAC router flag?
Perhaps that is baked in. Perhaps it is configured.
--> Pointer to [I-D.ietf-snac-simple]
> We were trying really hard to leave the protocol work to the snac router document.
> There is in fact language in the flag bit draft that addresses this, though:>
> 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.
- How does a node (that does not support the new flag) decide to "log
and cache the value of the flag as part of normal router advertisement
processing, where applicable"?
> 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.
--> Pointer to some pre-existing document
> 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.
- How is an environment that implements RA guard in a way that filters
RAs sent by SNAC routers arranged?
--> Pointer to some pre-existing document
> 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.
== Minor ==
Section 3 attempts to use BCP 14 language to define the behaviour of
nodes that do not support the SNAC Router flag. But you can't do that!
(Because nodes that do not recognise the new flag, don't implement this
document.)
So you should achieve this by reference to RFC 5175 or RFC 4861. Thus...
OLD
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.
NEW
The SNAC router flag is to be used by SNAC routers. SNAC routers and
the use of this flag are documented in [I-D.ietf-snac-simple]. As
defined by [RFCxxxx] devices that do not operate as SNAC routers will
not set the SNAC router flag, and will silently ignore the SNAC
router flag.
END
> RFC4861 section 4.2.
Great. So you’ll just include that?
But!
The router that sends a SNAC Router flag in its RA is operating as a
SNAC router. Fine.
But the router that receives this RA is not a SNAC router, I think.
It is a regular router that supports being paired with a SNAC router.
So I think...
NEWER
The SNAC router flag is to be used by SNAC routers. SNAC routers and
the use of this flag are documented in [I-D.ietf-snac-simple]. As
defined by [RFCxxxx] devices that do not operate as SNAC routers will
not set the SNAC router flag, and routers that do not understand the
SNAC router flag will silently ignore it.
END
> 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.
---
I wonder whether the O bit (or, indeed, any other bit) is used when the
S bit is set. Are there any rules? Or this also punted to [I-D.ietf-
snac-simple]?
---
> 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.
Given the security discussion in 4861, I think the Security
Considerations section should indicate the risk associated with a router
or host falsely setting the S flag. Also, perhaps, what risk there is if
the presence of the S flag is observed by a third party.
> 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.
The security considerations delegate to 4861, which is fine. But since
4861 refers onwards to 3756 and 3971, it might be helpful to include
those pointers from this draft.
> 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
