On 07/06/2018 05:49 PM, R. Atkinson wrote: > >> On Jul 6, 2018, at 10:41, Fernando Gont <[email protected]> wrote: >> >> Hello, Ran, >> >> I realize that you had sent feedback on this topic before, but for sme >> reason I had missed it -- my apologies for that! >> >> Please find my comments in-line.... >> >> On 07/06/2018 03:43 PM, R. Atkinson wrote: >>> Fernando, >>> >>> Regarding this draft, I have some feedback with respect to CALIPSO >>> (in part because I am one of the co-authors of RFC-5570, which specifies >>> CALIPSO). >>> >>> 1. Section 4.3.9 makes an incorrect assumption. >>> >>> Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no method >>> to learn or know whether or not it is deployed in an MLS-enabled >>> environment. >>> >>> An MLS-enabled IPv6 environment might well be using globally routable >>> addresses, so the routing prefixes in use are not informative about the >>> deployment type. >>> >>> Further, the majority of routers in an MLS-enabled environment are ordinary >>> commercial off-the-shelf IP routers from the usual IP router vendors. Some >>> routers and firewalls in such environments might have MLS-enhancements, >>> but many more will NOT have MLS-enhancements. This is partly because >>> the MLS-enabled label enforcement only is needed at enclave boundaries. >>> >>> Explicit configuration is the only method via which a particular deployed >>> intermediate system can learn whether or not it is in an MLS-enabled >>> network environment. This is sad, but also is reality. >> >> Question: would you argue that this would warrant forwarding them at >> transit routers? >> >> (I ask because while the answer to this question would most likely be >> "yes" if within a domain, I bet at a transit router it would be better >> to drop the MLS traffic to avoid leaks?) -- please see the applicability >> statement in Section 2.2. > > Hmm. Good question. > > At least in principle, there might be MLS-enabled network environments > with more than one AS in use. I do not have data on whether those actually > exist today or not.
I guess that in those cases the operator could decide to "pass" those packets? > Separately, how does a given deployed IP router learn/know that it is > a transit router ? > > Merely running BGP does not imply that it is a transit router. > > Merely not running BGP does not imply that it is not a transit router. > (It could be a transit router in an MPLS-centric BGP-free-core backbone.) Agreed. I'm not saying the router would detect the scenario and filter accordingly, but rather that the advice applies in such cases. i.e., the folk reading this doc know that this advice is meant only for such scenarios. > For clarity, might the Title of the I-D be changed to something like this: > > Recommendations on the Filtering of IPv6 Packets > Containing IPv6 Extension Headers at Transit Routers I have no issues myself. Will ask the chairs about it. >>> 2. As a result, the advice in 4.3.9.5 is not good or correct. Incorrect >>> assumption >>> above leads to an incorrect conclusion about advice on option handling. >>> >>> My suggestion is to revise the advice in 4.3.9.5. >>> >>> PROPOSED REPLACEMENT TEXT for 4.3.9.5: >>> >>> “Intermediate systems that do not implement RFC-5570 SHOULD have >>> a configuration option to EITHER (a) drop packets containing the >>> CALIPSO option OR (b) to ignore the presence of the CALIPSO option >>> and forward the packets normally.” >> >> A couple of questions here: >> * What would you argue that de default value of this knob should be? > > I do not really care either way about the default value, provided that there > is a knob. > >> * In any case, I'd somehow rephrase the advice, since it implies a >> requirement for a CALIPSO-specific knob --while we don't require any >> option-specific knob for any other option. > > > A. Well, this partly goes back to my question towards the top: > How does a particular router figure out whether it is a transit router ? > > I’ve built IP routers at more than one company, and did Cisco’s initial IPv6 > router implementation. If there are no knobs in the router/IS > configuration, > then how does the router know whether to apply the advice here (because > it IS a transit router) or NOT to apply the advice here (because it is NOT a > transit router). The goal is that the operator will apply the advice depending on where the router is being deployed. > > B. For the other part, please let me observe that at the top of Page 5, the > current draft’s text reads in part: > > "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 may include the following possible settings: […] " > > The text I proposed for 4.3.9.5 to me seems __very consistent__ with the > __existing__ text at the top of page 5 — since that text says that > configuration > knobs are recommended and outlines 2 of the 3 configuration choices > that I propose to document. My proposed text used “SHOULD” which is > consistent with the word “recommend” at the top of page 5. > Yes, my bad. [....] > > I do fully understand that (at least for some common implementations) the > presence of a Hop-by-Hop Header can create a (D)DOS attack vector on > the control plane (for some common router implementations). Having the > configuration knob (which again, is consistent with existing text at the > top > of page 5), allows for the desire/need to drop packets with Hop-by-Hop > headers while also allows for the desire/need to ignore those packets > (or to process them following the RFC-5570 specification). > > My apologies for the lengthy answers. Quite the contrary! -- Thans so much for your elaborate anwers! > Does that answer the question ? It does. :-) (agreed on making the knob available) Regarding the advice, I'm wondering what would be the recommended advice for transit routers. I guess it would be "drop, unless it's a MLS network", with the operator applying this configuration (and hence knowing what's the context in which this device s operating) Thoughts? > <off-topic rant> :-) > PS: At a former employer, we had packet forwarding silicon that could > be configured either to ignore xor to honor any Hop-by-Hop options that > appeared in an IPv6 packets. The Verilog to do this was pretty simple. > Adding that Verilog did not increase the die size or adversely impact our > layout/place time & costs. As a customer, I’d much rather buy a router > with packet forwarding silicon that had such a knob. Other than on > very low speed links (e.g., VSAT SATCOM often are Kbps), I want > to buy routers that use silicon to forward packets, not a CPU, and > with silicon robust against various kinds of (now all too predictable) > (D)DOS attacks. :-) > </off-topic rant> Agreed :-) Thanks a lot! Cheers, -- Fernando Gont e-mail: [email protected] || [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
