Hi, Eric, Thanks so much for the timely feedback! Please find some comments inline (more in a subsequent email)... On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote:
A couple of quick comments:
- this reminds me of taylor-v6ops-fragdrop (which you cite at the end), did you approach any of this old I-D authors?
Warren (co-author of this I-D) was a co-author of both draft-taylor-v6ops-fragdrop and draft-wkumari-long-headers -- but I did not approach all co-authors of the aforementioned I-Ds. FWIW, version -00 of our I-D is based in part on what was in version -00 of draft-gont-v6ops-ipv6-ehs-in-real-world (before we decided to have that one just focus on the measurements), and then discussions of this topic on the v6ops mailing-list (mostly the input from Nick and Gert, which was then augmented/elaborated for this I-D).
- not sure whether the security implications should be re-stated again in this document, let's rather split the security & operational issues into two documents
FWIW, the intent here with respect to the security implications was to provide a rather high-level discussion, and provide pointers for the interested reader. While in principle I don't object to splitting considerations in separate documents, I'm not sure it's possible to separate them, since the security aspect is probably one of the reasons for which some people filter them, though.
- in the introduction, 'widespread implementation limitations' is probably too strong (and I agree that my employer products could do better)
The intent here was to note that it's not a single product/vendor that has limitations in this respect, but rather rather a more widespread/general thing. Do you have any suggestions on how to tweak the text?
- in the introduction, "intentionally dropped" ? I am afraid that some drop are not intentional
Agreed. We noted that "...may be intentionally dropped on the public Internet in some network deployments". i.e., some operators do filter packets with EHs for a reason (rather than just e.g. wrong configuration defaults of buggy boxes).
- I would shorten a lot the section 3 (security implications) and simply put a lot of references to existing good documents of yours and others
This is indeed an open question. One one hand, the idea was to provide pointers (please let us know the ones we may have missed). On the other hand, we tried to provide some level discussion of each of the bullets such that folks could get some idea of "what this is all about" without digging into lots of documents.
- I like section 4 (operational implications) but it does not match the title, it is more about why transit operators have to look at layer-4
My mental model of this section is "We filter packets with EHs because they prevent us from doing our job, because we need the layer-4 info... And this is why we need that info".
- section 4 approaches the goal described in the abstract but actually only provide clues why operators intentionally (or non intentionally) drops packets with EH. For example, being unable to do ECMP is of course an operational impact but why would it be the cause of EH drop?
You mean other than you don't have many header fields on which to hash?
- section 4.1 (iACL), beyond the permit/deny, some operators also rate limit some traffic such pings
Yep. Will fix.
- section 4.2 (route processor protection) is a little unclear
- the processing of HbH would kill the Internet of course (at least with most routers), should HbH be separately called?
I think that'd be sensible. -- and seem to recall that there was some I-D (RFC?) focusing on HbH? (or was it on router alert option?)
- missing issue is lack of granular EH control by some routers, for example if an operator wants to block its subscribers RH-0 but can only drop RH (because RH type cannot be specified), then all RH are dropped including MIPv6
Good point. Will add this.
- section 5 (potential attack vector) appears to be focus on fragment drop by the public Internet.
Yes.
While it can probably work, the issues are twofold:
FWIW, kernel.org was vulnerable to this (before the Linux kernel was patched to prevent the generation of atomic fragments)
1) bad host implementations not doing enough tests before accepting a ICMP packet-too-big
Agreed. However: i) RFC4443 does not require such checks (unfortunately) ii) Because of EHs, at least in theory you might not even have such info available (a packet with EHs might mean that what you get in the ICMPv6 payload does not even have the layer-4 header)
2) public Internet dropping valid fragments in transit In both cases, we (the industry, vendors + operators) need to fix those two issues.
"Agreed" -- although some have argued against that (fwiw, I'm just the messenger :-) )
May I STRONGLY suggest to remove all security issues (other docs are describing this) and focus only on the operational issues (esp in V6OPS) ? And skip any discussion on the rationale why packets with EH are dropped?
Let's hear from other folks what they think. I think that without at least some "roadmap"/brief discussion, folks might need to dig deep into many documents in order to grasp "what this is ll about". FWIW, 8just me thinking out loud), I guess that one of the possible outcomes could be to have (some reduced version of) Section 3 be a subsection of Section 4? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492