On Sun, Nov 25, 2018 at 11:55 PM Fernando Gont wrote:
> On 24/11/18 17:37, C. M. Heard wrote:
> > On Sat, Nov 24, 2018 at 12:30 PM Nick Hilliard <[email protected]> wrote:
> >> Brian E Carpenter wrote on 24/11/2018 20:17:
> >>> Operators make their own
> >>> decisions, so I think that is what the draft should say. Something like:
> >>>
> >>> 3.5.5. Advice
> >>>
> >>> Operators should determine according to their own circumstances
> >>> whether to discard packets containing unknown IPv6 EHs.
> >>>
> >>> And at the same time, delete the 2nd and 3rd sentences of this:
> >>>
> >>> 3.5.3. Specific Security Implications
> >>>
> >>> For obvious reasons, it is impossible to determine specific security
> >>> implications of unknown IPv6 EHs. However, from security standpoint,
> >>> a device should discard IPv6 extension headers for which the security
> >>> implications cannot be determined. We note that this policy is
> >>> allowed by [RFC7045].
> >>
> >> This looks like a sensible approach.
> >
> > I could live with that.
>
> FWIW, I can live with that, too. UNless somebody screams against it, I
> will apply the proposed change to the next rev. Thanks!
>
> > Similar changes might be considered for Sec. 4.4.5.
>
> Will do.
Thank you. There is also related advice in the note to Section 3.1 that
needs similar changes and the matter of experimental EHs and experimental
options that I raised in my original comments. These are all cases where
the security implications cannot be determined. Proposed text for Sections
3.1, 3.4.10.5, 3.5.3 et. seq., 4.3.18.5, and 4.4.5 follows below.
---
OLD:
NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
IPv6 First-Fragments MUST contain the entire IPv6 header chain
[RFC7112]. Therefore, intermediate systems can enforce the
filtering policies discussed in this document, or resort to simply
discarding the offending packets when they fail to comply with the
requirements in [RFC7112]. We note that, in order to implement
filtering rules on the fast path, it may be necessary for the
filtering device to limit the depth into the packet that can be
inspected before giving up. In circumstances where there is such
a limitation, it is recommended that implementations discard
packets if, when trying to determine whether to discard or permit
a packet, the aforementioned limit is encountered.
NEW:
NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
IPv6 First-Fragments MUST contain the entire IPv6 header chain
[RFC7112]. Therefore, intermediate systems can enforce the
filtering policies discussed in this document, or resort to simply
discarding the offending packets when they fail to comply with the
requirements in [RFC7112]. We note that, in order to implement
filtering rules on the fast path, it may be necessary for the
filtering device to limit the depth into the packet that can be
inspected before giving up. In circumstances where there is such
a limitation, it is recommended that implementations provide a
configuration option that specifies whether to discard packets if
the aforementioned limit is encountered. Operators may then
determine according to their own circumstances how such packets
will be handled.
---
OLD:
3.4.10.5. Advice
Intermediate systems should discard packets containing these EHs.
Only in specific scenarios in which RFC3692-Style experiments are to
be performed should these EHs be permitted.
NEW:
3.4.10.5. Advice
Operators should determine according to their own circumstances
whether to discard packets containing experimental IPv6 EHs.
---
OLD:
3.5.3. Specific Security Implications
For obvious reasons, it is impossible to determine specific security
implications of unknown IPv6 EHs. However, from security standpoint,
a device should discard IPv6 extension headers for which the security
implications cannot be determined. We note that this policy is
allowed by [RFC7045].
3.5.4. Operational and Interoperability Impact if Blocked
As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
deployment of new IPv6 EHs and transport protocols. The
corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
such that filtering rules are updated as new IPv6 EHs are
standardized.
We note that since IPv6 EHs and upper-layer protocols share the same
numbering space, discarding unknown IPv6 EHs may result in packets
encapsulating unknown upper-layer protocols being discarded.
3.5.5. Advice
Intermediate systems should discard packets containing unknown IPv6
EHs.
NEW:
3.5.3. Specific Security Implications
For obvious reasons, it is impossible to determine specific security
implications of unknown IPv6 EHs.
3.5.4. Operational and Interoperability Impact if Blocked
As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
deployment of new IPv6 EHs and transport protocols. The
corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
such that filtering rules are updated as new IPv6 EHs are
standardized.
We note that since IPv6 EHs and upper-layer protocols share the same
numbering space, discarding unknown IPv6 EHs may result in packets
encapsulating unknown upper-layer protocols being discarded.
3.5.5. Advice
Operators should determine according to their own circumstances
whether to discard packets containing unknown IPv6 EHs.
---
OLD:
4.3.18.5. Advice
Intermediate systems should discard packets that contain these
options. Only in specific environments where RFC3692-style
experiments are meant to be performed should these options be
permitted.
NEW:
4.3.18.5. Advice
Operators should determine according to their own circumstances
whether to discard packets containing experimental IPv6 options.
---
OLD:
4.4.5. Advice
Enterprise intermediate systems that process the contents of IPv6 EHs
should discard packets that contain unknown options. Other
intermediate systems that process the contents of IPv6 EHs should
permit packets that contain unknown options.
NEW:
4.4.5. Advice
Operators should determine according to their own circumstances
whether to discard packets containing unknown IPv6 options.
EDITORIAL: I believe that the following is simply mis-worded:
---
OLD:
4.3.10.5. Advice
Intermediate system should discard packets that contain this option.
NEW:
4.3.10.5. Advice
Intermediate systems that are not within a MANET domain should
discard packets that contain this option.
NITS: These should be fixed prior to publication.
---
OLD:
4.3.1.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 EHs.
NEW:
4.3.1.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 options.
---
OLD:
4.3.2.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 EHs.
NEW:
4.3.2.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 options.
In some places the abbreviations RHT0 and RHT1 are used, while in other
places RTH0 and RTH1 are used. The usage should be consistent; IMHO the
former abbreviations seem to be more correct.
Mike Heard
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
