Re: I-D Action: draft-ietf-6man-icmp-limits-02.txt

[Tom Herbert <[e-mail]>]

On Mon, May 27, 2019 at 12:58 PM Nick Hilliard <[e-mail]> wrote:
>
> Tom,
>
> Overall this looks useful.
>
> Minor nits:
>
> >  options in Type-length-value (TLV) format. Each option includes a
> >  length of the data field in octets, and the minimum size of an option
> >  (non-pad type) is two bytes and the maximum length is 257 bytes.
>
> rephrase as:
>
> >  options in Type-length-value (TLV) format. Each option includes a
> >  length of the data field in octets:  the minimum size of an option
> >  (non-pad type) is two octets and the maximum length is 257 octets.
>
> s/extensions headers/extension headers/
>
> s/attack of extension headers-- many/attack of extension headers, many/
>
> s/may be applied on the number/may be applied to the number/
>
> s/hosts may institute limits on/hosts may implement limits for/
>
> s/of a fixed sized/of a fixed size/
>
> s/for Parameter Problem type/for Parameter Problem types/
>
> s/chain exceeds it processing/chain exceeds its processing/
>
> Can I suggest the following for the security consideration section?
>
> --
> 5  Security Considerations
>
>     The security considerations for ICMPv6 described in [RFC4443] apply
>     to this document.
>
>     A malicious actor could use crafted packets to trigger ICMPv6 error
>     replies described in this document, thereby allowing them to
>     discover configuration or hardware characteristics of an
>     intermediate node.  If the intermediate node processes packets which
>     trigger extension header limit ICMPv6 error replies by processing
>     them in a slow path, then an attacker may be able to selectively
>     flood the slow-path packet processor or the specific slow-path
>     processing ingress queue, thereby affecting the packet processor's
>     ability to handle legitimate ICMPv6 error replies.
>
Hi Nick,

Thanks for the comments. For your proposed security considerations
text, is the problem of exposing hardware configuration specific to
only these type of ICMP errors? Do we need to provide so much detail
about the possible attack? Also I suspect that ICMP error processing
is in slow path processing anyway and there are other ways to generate
an ICMP flood, the bigger issue might be in divulging details about
hardware capabilities of intermediate nodes to third parties in the
ICMP error.

How about text like this:

"In some circumstances, the sending of ICMP errors could be exploited
for denial of service attack or as a means to covertly deduce
processing capabilities of nodes as a precursor to denial of service
attack. As such, an implementation MAY allow configurable policy to
rate limit or withhold sending of ICMP in environments where security
of ICMP errors is an issue."

Thanks,
Tom

> --
>
> Nick
>
> Tom Herbert wrote on 24/05/2019 18:57:
> > Hello,
> >
> > This is an update to ICMPv6 errors for processing limits. The material
> > change is to add an "Option too big" Parameter Problem code. This is
> > used used if a HBH or DO option length exceeds a limit, or the length
> > consecutive padding in HBH or DO options list exceeds a limit. The
> > recommended priority for reporting errors was also update accordingly.
> >
> > Thanks,
> > Tom
> >
> > On Thu, May 23, 2019 at 1:42 PM <[e-mail]> wrote:
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This draft is a work item of the IPv6 Maintenance WG of the IETF.
> >>
> >>          Title           : ICMPv6 errors for discarding packets due to processing limits
> >>          Author          : Tom Herbert
> >>          Filename        : draft-ietf-6man-icmp-limits-02.txt
> >>          Pages           : 12
> >>          Date            : 2019-05-23
> >>
> >> Abstract:
> >>     Network nodes may discard packets if they are unable to process
> >>     protocol headers of packets due to processing constraints or limits.
> >>     When such packets are dropped, the sender receives no indication so
> >>     it cannot take action to address the cause of discarded packets. This
> >>     document defines ICMPv6 errors that can be sent by a node that
> >>     discards packets because it is unable to process the protocol
> >>     headers. A node that receives such an ICMPv6 error may be able to
> >>     modify what it sends in future packets to avoid subsequent packet
> >>     discards.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-02
> >> https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmp-limits-02
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-icmp-limits-02
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >