[Last-Call] Re: Secdir last call review of draft-ietf-6man-eh-limits-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

 

On 26/11/2024, 23:59, "Tom Herbert" <tom@xxxxxxxxxxxxxxx> wrote:


> Thanks for the review!

 

Of course. Sorry for the mangled formatting of the bullets.


> This draft states "Per [RFC8200], a destination host that
> receives a packet with extension headers must process all the
> extension headers in the packet before accepting the packet and
> processing the payload.", but RFC9673 states "Hosts SHOULD process the
> Hop-by-Hop Options header in received packets.". The intent of the
> eh-limits wording is that all EH and all EH options, including HBH
> options, must be properly processed by a host or the packet is dropped
> because of the security concern you mentioned. This is how it works
> already in Linux so the vast majority of destination hosts are already
> covered.

 

Ah, this is indeed a considerable improvement in the direction I was

hoping for, thanks for the extra background.

 

> This draft gives a non-normative requirement, but maybe a
> normative update to RFC9673 or RFC8200 should be considered?

That’s what feels right to me, taking the perspective of a non-expert outsider

having to follow specs and implement them that seems the more robust

approach. But there’s legacy at play here. I will leave such things to

the WG and Area Directors.


[SNIP]

>> * It’s interesting to me that this
>> document is almost 3 years old by this point, had WGLC issues from at least 1
>> year ago, and has not been discussed officially at (at least) the past 3 IETF
>> meetings. There has been modest discussion on the list and I am satisfied with
>> the shepherd’s review but I think that emphasises the ‘Informational’ decision.

>> Is there adoption/implementer support? *
>
> There were a couple of detailed reviews by the chairs, I'm not sure
> all of that discussion was on the list.

 

Fine. I just did a simple list search, could have missed something..

 

> Also, for "running code",
> several of the limits are already in use in Linux for a while. For
> instance, the limit in Linux for the maximum number of HBH or DestOpts
> is eight by default (as stated in the draft).

 

Very good, thanks. That’s decent evidence 😊


>> *Nits:*
>> * Grammar/typo in Introduction: "[...] including a myriad of use cases those
>> are obviously outside the realm of ever being realistic or useful [...]" should
>> be "[...] including myriad use cases that are obviously outside the realm of
>> ever being realistic or useful [...]" * typo top of page 5: “limited is
>> exceeded” should be “limit is exceeded” * grammar/typo: “The potential for this
>> DOS attack exists routers, hosts, and intermediate nodes.”. Missing “in”?
>
>Will fix.

Thanks very much. Nothing further.

 

Jon

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux