Great. Thanks for the explanation! Looks good to me. --- Mike Ounsworth From: Acee Lindem <acee.ietf@xxxxxxxxx> Hi Mike, Speaking as document shepherd and LSR Co-Chair. > On Mar 4, 2025, at 4: 23 PM, Mike Ounsworth via Datatracker <noreply@ ietf. org> wrote: > > Reviewer: Mike Ounsworth > Review result: Ready > > Draft-ietf-lsr-ospf-prefix-extended-flags-06 Hi Mike,Speaking as document shepherd and LSR Co-Chair. > On Mar 4, 2025, at 4:23 PM, Mike Ounsworth via Datatracker <noreply@xxxxxxxx> wrote:> > Reviewer: Mike Ounsworth> Review result: Ready> > Draft-ietf-lsr-ospf-prefix-extended-flags-06> > I have reviewed this document as part of the security directorate's> ongoing effort to review all IETF documents being processed by the> IESG. These comments were written primarily for the benefit of the> security area directors. Document editors and WG chairs should treat> these comments just like any other last call comments.> > The summary of the review is Ready; I see no security implications to this> draft although I have one substantial non-security comment related to handling> unassigned bits.> > Introduction> “ Unassigned bits MUST be set to zero on transmission and MUST be> ignored on receipt.> “This is a common statement to allow backward compatible flag bits in routing protocols. You'll find this in RFCs specifying extendable bit fields. > What happens if the sender and receiver have different views of which bits are> “unassigned”?If the sender supports new bits but the receiver does not, the bits will be ignored by the receiver. If incremental deployment is supported, then the backward compatibility mechanisms must be specified. If the receiver support new bits but the sender does not, the sender won't will send these bits as 0 since it doesn't support the feature associated with the bits. Look at it this way, unsupported bits are handled similar to unsupported TLV or Sub-TLVs. I don't believe any additional action is required or even desired here. Thanks,Acee> Maybe because the sender and receiver’s software were written 5> years apart and the IANA registry changed in the mean time? I guess the two> options are: 1: the receiver MUST ignore unassigned bits by treating unassigned> bits as if they are 0. … this would generally allow for cases where the sender> is at a higher protocol level than the receiver without blowing up here …> although things could still blow up later if the ignored 1 bit ends up causing> the sender and receiver to behave differently in an important way. 2. the> receiver MUST ignore unassigned zero bits and fail with an error on unassigned> 1 bits. This is probably “safer” but basically means that you can’t really add> anything new to the registry.> > If you go with #1, then you could combat “rusting shut” by borrowing the GREASE> idea from TLS [RFC 8701] and saying: “Following the GREASE paradigm [RFC8701],> senders SHOULD occasionally set randomly-chosen unassigned bits to 1 in order> to force receivers to be tolerant of additional flags being added to the> registry after the receiver’s code was written”. One way or another, I found> this sentence to be under-specified, so it should be made more explicitly clear.> > |
<<attachment: smime.p7s>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
