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

[Mark Smith <[e-mail]>]

On Tue, 28 May 2019 at 06:29, Tom Herbert <[e-mail]> wrote:
>
> 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

ICMPv6 is already to be rate limited, per RFC 4443, 2.4, f.


> 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
> > > --------------------------------------------------------------------
> > >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------