Hello, Michael,
Thanks a lot for your input! In-line...
On 20/1/21 22:31, Michael Dougherty wrote:
Greetings,
This was an interesting topic and write up. I have a few comments
related to writing structure and readability.
Original: While some operators "officially" drop packets that contain
IPv6 EHs, it is possible that some of the measured packet drops be
the result of improper configuration defaults, or inappropriate
advice in this area.
Suggestion: While some operators "officially" drop packets that
contain IPv6 EHs; it is possible that some of the measured packet
drops be the result of improper configuration defaults, or
inappropriate advice in this area.
Wouldn't the s/,/;/ make the two sentences more unrelated, when they are
actually meant to be closely-related?
Original: The advice in this document is aimed only at transit
routers that may need to enforce a filtering policy based on the EHs
and IPv6 options a packet may contain, following a "deny-list"
approach, and hence is likely to be much more permissive that a
filtering policy to be employed at e.g. the edge of an enterprise
network.
Suggestion: The advice in this document is aimed only at transit
routers that may need to enforce a filtering policy based on the EHs
and IPv6 options a packet may contain, following a "deny-list"
approach, and hence is likely to be much more permissive than a
filtering policy to be employed at, e.g., the edge of an enterprise
network.
Will do!
Original: Section 4.2, first paragraph, second sentence Essentially,
packets that contain IPv6 options might need to be processed by an
IPv6 router's general-purpose CPU,and hence could present a DDoS risk
to that router's general-purpose CPU (and thus to the router
itself).
Suggestion: Essentially, packets that contain IPv6 options that might
need to be processed by an IPv6 router's general-purpose CPU and
could present a DDoS risk to that router's general-purpose CPU.
Will do.
Comments: 1 - Within the last sentence of the third paragraph within
the "Introduction" sections. There is a comment about "inappropriate
and missing guidelines". Who dictates or decides what is
inappropriate?
Well, that's indeed subjective. One might say that, for example, "drop
all packets with EHs (regarding the EH-chain length) at transit routers"
is probably inappropriate.
That said, if you have any suggested tweaks, please do let us know (I'm
all for improving the document).
2 - First bullet point in Section 2.3, change
"recognise" to "recognize" 3
Will do.
- Within the last paragraph of section
2.3, part of the comment ".... it is generally desirable that the
sender be signaled of the packet drop...." While the idea is valid,
it might be a good idea to note that such a signal might attract
malicious attention or threat-actors.
You mean "expose the filtering policy"? If not, please elaborate. :-)
4 - Section 3.4.4.4. It might
be best to specify what type of IPSEC deployment is involved,
host-to-host, site-to-site, site-to-host?
Could you please elaborate a bit on this one?
5 - Section 3.4.5.5.
Advise, hasn't AH been depreciated as an insecure methodology versus
ESP?
That'd generally be my take. But AH has never been formally obsoleted.
While double-checking this, I ended up finding this thread
(http://www.sandelman.ottawa.on.ca/ipsec/2000/06/threads.html#00063 ) in
which some folks have actually suggested that, but it looks like the
idea didn't fly.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
