Re: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02

["Smith, Donald" <[e-mail]>]

(coffee != sleep) & (!coffee == sleep)
[e-mail] gcia

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Ron Bonica
> Sent: Friday, April 09, 2010 10:10 AM
> To: Danny McPherson
> Cc: opsec wg mailing list
> Subject: Re: [OPSEC] Comments on
> draft-dugal-opsec-protect-control-plane-02
>
> Hi Folks,
>
> <Speaking as individual contributor>
>
> Danny McPherson wrote:
> > I support this document becoming an OPSEC WG item.  A few
> > mostly trivial comments below.  I do believe the document
> > would benefit from an overwrite for readability, but it
> > seems to be in pretty good shape (and that's the purpose of
> > making it a WG item).
>
> +1
+1
>
> >
> > One substantive item is that I believe it needs to be a lot
> > more detailed on IPv6 examples, in particular as they relate
> > to ICMP.  This is where lots of operators really need extra
> > guidance today.
>
> I would like to suggest a sequel document specifically for
> operators who
> are deploying dual stack. There are enough sharp edges in dual stack
> deployment that it deserves some thought.
>
>
>
> >
> > Also, it should be clear about how transit traffic with TTL
> > expiry isn't necessarily addressed to the device, but might get
> > punted to the control plane.  There is some text that touches
> > on this, but this issue is not clear from the text.

"The treatment of exception traffic in the forwarding plane, and the
   generation of specific messages by the control plane also requires
   protection from a DoS attack.  Specifically, the generation of ICMP
   Unreachable messages by the control plane needs to be rate-limited,
   either implicitly within the router's architecture or explicitly
   through configuration.  See Section 4.3.2.8 of [RFC1812].
   For example, rate limiting the TTL / Hop Limit expired
   traffic before sending the packets to the control plane component
   that will send the ICMP error, and distributing the sending of ICMP
   errors in a Line Card CPU are protection mechanisms that deter
   attacks before a rate limited in the main control plane component."


When some vendors moved the TTL expired work to the line cards they created a really fast reflective attack surface which we have seen used in DDOS attacks:(

Also explicit ratelimits are always better then implicit:)


>
> +1
>
> >
> > Finally, after giving RFC 1812 another read (phew), my comments
> > at the microphone about references to that document aren't
> > really useful.  I had thought it had more detailed information
> > on what it terms "in-band" access, however, the guidance there
> > isn't particular useful in this context.
> >
> > -danny
> >
> >
> > ---
> > S 1.
> >
> > s/as as/as/
> >
> > s/traffic unwanted traffic/unwanted traffic/
> >
> > ---
> > S 2.
> >
> > I think the document would benefit from IPv6 examples as well, and
> > should reference that use case here and provide it further along in
> > parallel to IPv6 examples.
> >
> > ---
> > S 3.
> >
> > s/sample router introduced/sample router is introduced/
> >
> > ---
> > S 3.1.
> >
> > While I realize it's for example only, it might well be useful to
> > add some sort of authentication packets to that example, so that
> > folks can login if they have non-local auth models.
> >
> > Also, does anyone have recent rates of ICMP traffic destined to the
> > control plane of high-end routers?  2 Mbps of ICMP seems pretty
> > high to me..
> >
> > ---
> > S 3.2
> >
> > It might be useful for the document, or the appendices to recommend
> > allowing all traffic initially and auditing what hits the control
> > plane before applying explicit filters or rate limits.
> Additionally,
> > use of flow-based behavioral analysis or even CLI functions to
> > identify what client/server functions a given control plane handles
> > would be very useful during initial policy development phases (and
> > certainly for forensics afterwards).  Perhaps this belongs at the
> > end of S 3.3, in the last graf where you touch on some of this.
> >
> > ---
> > S 3.3
> >
> > I'm not sure what "sub-traffic" is..
> >
> > It might be worth expanding this a bit to say that an
> astute operator
> > would likely define varying rate limits for ICMP such than internal
> > traffic (i.e., from internal address blocks) obtains uninhibited
> > access to the control plane, while traffic from external blocks is
> > rate limited.  I think you meant to allude to this, but don't really
> > make it clear in the current text.
> >
> >
> > ---
> > S 4.
> >
> > I believe it'd be worthwhile to mention that while in the
> inter-domain
> > context express ingress anti-spoofing policies may be difficult,
> > operators should apply ingress infrastructure ACLs to limit
> access to
> > infrastructure from external source address spoofing of
> internal address
> > space.  I.e., allow no packet into the perimeter of the network that
> > has a source address of internal prefixes.  Of course,
> iACLs and GTSM
> > might well be a new section to this document, or a document entirely
> > themselves.
> >
> >
> > _______________________________________________
> > OPSEC mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsec
> > .
> >
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.