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

[Joel Jaeggli <[e-mail]>]

Thanks Danny,

test for inclusion will likely follow the publishing of the minutes.

joel

On 03/30/2010 05:18 AM, 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).
> 
> 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
>