Hello Fernando, Thanks for the reply, I wasn’t sure if you received my message, but I am glad that it has helped. I reviewed your comments and responded to them below. I am happy to help out.
-michael On 1/24/21, 12:45 AM, "Fernando Gont" <[email protected]> wrote: 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? //MD Reply - 24JAN2021 \\ The use of the semi-colon would be a good fit here, since the two sections are related but are separate sentence clauses - technically it would work. Take a look at my rewrite below, hopefully it still conveys the idea. Possible rewrite: While some operators "officially" drop packets containing IPv6 EHs, inappropriate defaults or incorrect advice in this area may result in the recording of elevated drops. > 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). MD: I reviewed the RFC7872 and you could maybe rephrase to include the call out of 7872, but also cover anything that might be considered. /// The advice conveyed in this document is to assist network operators with developing or refining packet dropping policies for IPv6 EH entering or leaving their operational responsibilities. Guidelines contained in RFC7872 may not have information for specific use cases or situations; this document may positively affect updated policies. \\\ > 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. :-) MD Response: Yes, that is exactly what I am referencing. Sending back an ICMP error message to the originating host may expose the "reporting devices" existence or operation. > 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? MD Response: It was more so a comment regarding how specific you want to be with the possibly breaking IPSec deployments. In general, yes, calling out as you have would cover various deployments or operational considerations. Being this document is aimed towards transit and possibly applicable to IXP's, they may not be mindful of how end-users might be operating. > 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. MD Response: It seems you are correct, at a standards level AH appears to be not be officially depreciated. While it sounds like there is discussion and need to do so, it has not been done. I will say some vendors do recommend ESP over AH, such as Juniper in their 2012 document, "Concepts & Examples ScreenOS Reference Guide Virtual Private Networks." Regardless, you can probably ignore my previous comment. 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
