Hi, Jen, Thanks so much for your feedback! Please find my comments in-line...
On 09/30/2014 01:24 AM, Jen Linkova wrote: > Hi Fernando, > > Some comments: > > 1) Section 2.2 > " - Permit this IPv6 Extension Header or IPv6 Option type; > - Ignore this IPv6 Extension Header or option type (forwarding > packets that contain them)" > > What the difference? With "permit", you honor the IP option (act on it) and forward the packet. With "ignore", you do not act on the option, but still forward the packet. Please let us know if you think this should be made more clear in the I-D. > 2) Section 3.4 discussed the unknown EHs and it says: > - impossible to determine specific security implications > - filtering might break new protocols and makes the deployment harder > > and then you make a conclusion 'it's recommended to filter' - does not > look too logical to me ;) The thing here is that a standardized IPv6 EH is not "unknown" anymore. [I've suppressed those comments that we will apply as suggested] > 7) Section 4 IPv6 Options > > As you already discussed HbH and Destination options - so why do you > have a separate section? Unless I'm really missing smth here, we have > only HbH and Destination ;) IMHO it would be more logical to have a > section about 'IPv6 Options Headers and two sub-sections for HbH and > Destination. The reason was to discuss filtering on both per-EH-type (Section 3) and per-option-type (Section 4) granularities. How renaming the section (somehow) make things more clear? > In general I'm a bit concern about the message of this document as it > is quite long and I'm afraid that people might read it as 'filter 'em > all, let God sort 'em out' which would make the current situation even > worse. Is it what you trying to say? Certainly not -- actually, kind of quite the opposite. :-) > If not - would it help to have a > short summary saying 'filter this, rate limit thas, permit everything > else' or 'permit this, rate-limit that, block everything else' and > then provide with all details you currently have in the document? Yes. This is what we did in RFC7126. We should definitely do it for this document, too. Thanks! Best 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
