Hi, Mike,
Thanks so much for your feedback! Please find my comments in-line....
On 08/20/2014 04:20 PM, C. M. Heard wrote:
>
> Last paragraph of the introduction:
>
> Section 3 of this document discusses IPv6 extension headers and IPv6
> options, and provides advice in the area of filtering IPv6 packets
> that contain such IPv6 Extension Headers and/or options.
>
> This needs a small editorial fix since Section 3 discusses extension
> headers and Section 4 discusses specific options.
Yep. Fixed.
> Section 2.2:
>
> The advice provided in this document is only meant to guide an
> operator in configuring forwarding devices, and is *not* to be
> interpreted as advice regarding default configuration settings for
> network devices. That is, this document provides advice with respect
> to operational configurations, but does not change the implementation
> defaults required by [RFC7045].
>
> The second half of the first sentence is not quite tre, since the
> draft does provide advice on default processing of the CALIPSO
> option.
We will remove this "default configuration" thing for this option, such
that there is coherence throughout the document in this respect
(recommending defaults for options but not for EHs would likely lead to
confusion).
Thoughts?
> My inclination is to suggest that Section 2.2 be beefed up to point
> this out, e.g., by saying
>
> The advice provided in this document is only meant to guide an
> operator in configuring forwarding devices, and is *not* to be
> interpreted as advice regarding default configuration settings for
> network devices. That is, this document provides advice with respect
> to operational configurations, but does not change the implementation
> defaults required by [RFC7045] and [RFC2460].
>
> and to suggest that all advice for option implementation defaults be
> left out of this document -- at most, it should be pointed out what
> the default configuration default _is_.
Agreed.
> Section 3.3.1.1, uses of Hop-by-Hop option header, fails to mention
> the following hop-by-hop options:
>
> o Quick-Start [RFC4782]
> o CALIPSO [RFC5570]
>
> I missed this the first time around, sorry about that. Also, as an
> editorial nit, I would suggest either including the type in this
> list, as was done in Section 3.3.6.2, or leaving it out in both
> places (and while I am at it, I would also suggest listing the
> options in the same subsection in both places, either Uses or
> Specification -- I also missed that in my previous comments).
All of these are good points. We will fix all of them in the next
revision. Thanks!
> Section 3.10.5, advice regarding experimental use headers (253/254):
>
> Advice from -00:
> Routers, security gateways, and firewalls SHOULD have configuration
> knobs for IP packets that contain this extension header to select
> between "ignore & forward" and "drop & log". Otherwise, no
> legitimate experiment using these options will be able to traverse
> any IP router.
>
> The aforementioned configuration knob SHOULD default to "drop & log".
>
> Special care needs to be taken in the case of "drop & log". Devices
> SHOULD count the number of packets dropped, but the logging of drop
> events SHOULD be limited so as to not overburden device resources.
>
> Advice from -01:
> Intermediate systems should discard packets containing these
> extension headers.
>
> Presumably the reason for this change to avoid giving advice to
> implementors regarding the default configuration and to focus on
> advice to operators on what configuration to set.
Exactly. This was the motivation for removing such text.
> If so, maybe
> something along the following lines would have less dissonance with
> the preceding paragraphs (c.f. jumbogram option advice):
>
> Alternative advice:
> Intermediate systems should discard packets containing these
> extension headers. This policy could be overridden in specific
> environments where the experimental headers are used.
The thing is that "this policy could be overriden.." sounds a bit like
defining configuration defaults. mm.. how about:
Intermediate systems should discard packets containing these
extension headers. Only in in specific scenarios in which
experiments are to be performed, an operator may want to permit
these extension headers.
?
> General comment on Section 4, advice about options: should the
> advice be nuanced to distinguish between cases where an option
> appears in a Hop-by-Hop option header vs a Destination Options
> header?
Yes. Even if te advice ends up being the same. I will check if there are
any options (other than the padding ones) that cane be included in
different EH types (of the top of my head, most of the options are meant
for specific EH types).
> For instance, should the advice be to discard all options
> that are supposed to appear only in a Destination Options header if
> they appear in a Hop-by-Hop options header? This is done for Tunnel
> Encapsulation Limit but not for other destination options (other
> than Line-Identification, for which the advice is unconditional
> discard).
Yes. I will make sure we do this for all options.
> Also, should it be recommended that implemention allow separate polcies for
> these cases?
I would think so.
>
>
> Section 4.3.6.5, advice on Router Alert option:
>
> Current text:
> Intermediate systems should discard packets that contain this option.
>
> Recommended text:
> Intermediate systems should discard packets that contain this option.
> This policy could be overridden in specific environments where
> support for RSVP or similar protocols is desired.
I agree with the recommended text, but as with the experimental options
above, I'd edit it as:
Intermediate systems should discard packets that contain this option.
Only in specific environments where support for RSVP or similar
protocols is desired should this option be permitted.
Thoughts?
> Section 4.3.8.5, advice on processing CALIPSO option: eliminate the
> text that provides advice about implentation defaults.
Will do.
> Section 4.3.17.1, Uses if RFC3692-style experimental options: I
> would recommend s/MUST NOT/must not/ since this document does not
> levy that requirement -- RFC 4727 does.
Correct. Will do.
> Section 4.3.17.5, advice regarding RFC3692-style experimental options:
>
> Current text:
> Intermediate systems should discard packets that contain these
> options.
>
> Recommended text:
> Intermediate systems should discard packets that contain these
> options. This policy could be overridden in specific environments
> where support for one or more of these options is desired.
How about tweaking this text as I did above?
> Unknown options: there is no section covering these. I am not
> concerned if the RFC 2460 implementation defaults (i.e., obey the
> instructions in the top two bits of the option type) is
> operationally acceptable.
mm.. let me think about this one -- I'll come back to you.
Thanks so much!
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
