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

[Warren Kumari <[e-mail]>]

Is there an official "Last call" mail we should be replying to?


On Mar 30, 2010, at 8:18 AM, Danny McPherson wrote:

>
> I support this document becoming an OPSEC WG item.

+1

Already submitted comments off list.


>  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).
>
> 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.
>
> 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.
>
> 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

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they  
can talk but choose not to do so in case humans put them to work,  
possibly in the television industry. In fact they can talk. It's just  
that they talk in Orang-utan. Humans are only capable of listening in  
Bewilderment.
-- Terry Practhett