> 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.
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.)
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
>
>
>>
>> SUGGESTED ADDITIONAL TEXT for 4.3.9.1:
>>
>> "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."
>
> We will incorporate this. Thanks for suggesting text!
Thanks.
>> 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).
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.
Also, “SHOULD” is different from “MUST”. To my mind, the word “require”
is different from “recommend” and “require” would map to “MUST” rather
than to “SHOULD”.
In practice, most (all ?) of us realize that any guidance that is neither
“MUST”
nor “MUST NOT” might or might be followed by a conforming implementation
of an IETF standards-track RFC. My goal is simply to offer the best advice
to a (possibly naive) implementer who is not active in IETF, is not reading
IETF mailing list archives for context, and simply has been told to
“implement
RFC-wxyz in our intermediate system because customer A asked for it”.
There are HUGE numbers of implementers of mainstream commercial
products who aren’t active in IETF and simply write code from the RFC.
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. Does that answer the question ?
Yours,
Ran
<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>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
