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: [email protected]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
