Re: [OPSEC] Lars Eggert's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

[Fernando Gont <[e-mail]>]

Hi, Lars,

My apologies for the delay in my response. (Things have been a bit messy 
over here -- changed jobs, had covid, etc. .. but now getting back to 
"normal")

In-line....

On 13/7/21 09:46, Lars Eggert via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This is mostly a personal style issue, but I find large parts of the document
> hard to read, because of a myriad of very short (1-2 line) subsections, each
> with their own repetitive section heading.

FWIW, part of that is that the groups wanted that this document be 
useful as a reference for looking-up options, rather than something 
you´d read entirely.



> Section 2.3. , paragraph 7, comment:
>>     We recommend that configuration options are made available to govern
>>     the processing of each IPv6 EH type and each IPv6 option type.  Such
>>     configuration options should include the following possible settings:
> 
> Out of curiosity, is there a reason a "strip option and forward packet" isn't
> one of the options below?

Yes: unless according to the traditional interpretation of RFC8200, 
that's forbidden.



> Section 3.2. , paragraph 2, comment:
>>     In some device architectures, IPv6 packets that contain IPv6 EHs can
>>     cause the corresponding packets to be processed on the slow path, and
>>     hence may be leveraged for the purpose of Denial of Service (DoS)
>>     attacks [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH]
>>     [FW-Benchmark].
> 
> Do such device architectures really still exist in 2021? 

Yes.


> The [Cisco-EH]
> reference is from 2006, and the URL in [FW-Benchmark] does not seem to return
> content.

Fixed!



> Section 3.4.1.2. , paragraph 2, comment:
>>     This EH is specified in [RFC8200].  At the time of this writing, the
>>     following options have been specified for the Hop-by-Hop Options EH:
> 
> Wouldn't a pointer to the respective IANA registry suffice here, rather than a
> list that is going to be inaccurate with time?

At the end of the day, it would seem to me it would be the same: we list 
the options to subsequently analyze/discuss them.

I guess we could remove "at the time of this writing", since thatś kind 
of implicit?



> 
> Document has Informational status, but uses RFC2119 keywords.

FWIW, it only quotes text with RFC2119 keywords, but doesn't really use 
RFC2119 keywords to introduce requirements or the like. -- anything to 
fix here?



> 
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
> 
>   * Term "his"; alternatives might be "they", "them", "their".

Are these the instances in the Acks?



>   * Term "traditional"; alternatives might be "classic", "classical",
>     "common", "conventional", "customary", "fixed", "habitual", "historic",
>     "long-established", "popular", "prescribed", "regular", "rooted",
>     "time-honored", "universal", "widely used", "widespread".

Fixed.



> These URLs in the document did not return content:
>   *
>   http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf

Fixed!


> 
> These URLs in the document can probably be converted to HTTPS:
>   *
>   http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf
>   * http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml *
>   http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

Fixed!

Thanks!

Regards,
-- 
-- 
Fernando Gont
e-mail: [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1