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

[Danny McPherson <[e-mail]>]

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.