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. “ What happens if the sender and receiver have different views of which bits are “unassigned”? 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
