Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure"

From: Ross Callon <[email-masked]>
Date: Thu, 05 Feb 2004 11:50:27 -0500

I think that this is a very useful document, and is quite well done. The 
topic is also quite urgent. I therefore encourage publication. 

My comments are very minor editorial comments, and are intended
only to be helpful (if any of these are controversial then "never mind").  

Regarding the title: it is very clearly stated in the scope section that this 
document covers routers and switches. My general interpretation of the 
phrase "IP Network Infrastructure" tends to include servers as well. It
therefore seems reasonable to change the title to "Operational Security
Requirements for IP Routers and Switches". (although I wouldn't change
the title if this requires any major trouble -- the stated scope is very clear, 
and some of these requirements might carry over to other devices). 

Section 1.4, second bullet item: In principle a packet could be delivered
to more than one place. Thus I would be inclined to reword this bullet as:

         o traffic goes where its supposed to go, and only where its supposed
            to go (availability, confidentiality)

Section 1.5, In interpret the phrase "end user" to be a person sitting at
home on the other end of a dial-up or DSL connection, or perhaps a 
company. Thus I think that "end user" could be changed to "network 
operator" so that this section reads: 

         There are two intended audiences: the network operator who selects, 
         purchases, and operates IP network equipment, and the vendors who 
         create them.

Page 10, definition of "Single-Homed Network". Does this include a network
which has two physical links to the same service provider? Does this depend
upon whether this results in the network having a single address prefix that
needs to be advertised? It seems to me that the issue is primarily related to 
addressing and routing, and the related checking of source addresses. Thus
the definition looks good, but a little clarification might not hurt. This is a 
difficult area to get precisely the right wording, but how about a comment 
along the line of:

         Note: A single homed network may have more than one physical links 
         to the same service provider, so long as the connection can be treated
         as one logical connection for the purpose of inter-domain routing and
         addressing.

Page 27/28, section 2.5.6, discussion of anti-spoofing filters. Current text
for the example says: 

         Examples.
         This requirement could be satisfied in several ways. It could be 
         satisfied by the provision of a single command that automatically 
         generates and applies filters to an interface that implements 
         anti-spoofing. It could be satisfied by the provision of a 
         command that causes the return path for packets received to be
         checked against the current routing tables and dropped if they 
         would not be forwarded back through the interface on which they 
         were received.

This is perhaps a nit. In the single-homed case, the text is correct as
it currently stands. If we wanted this to extend to spoof checking in
other cases, then you want a slightly less rigid check, in that there 
might be multiple paths, and you want to accept the packet if any
path exists back to the source over the interface, not just the paths
that you happen to have chosen. Thus we could generalize this as
follows:

         Examples.
         This requirement could be satisfied in several ways. It could be 
         satisfied by the provision of a single command that automatically 
         generates and applies filters to an interface that implements 
         anti-spoofing. It could be satisfied by the provision of a 
         command that causes the return path for packets received to be
         checked against the current routing tables and dropped if they 
         could not be forwarded back through the interface on which they 
         were received (ie, if no path to the source exists over the interface). 
         
thanks, Ross

At 02:24 PM 1/22/2004 -0800, Alex Zinin wrote:

>Folks-
>
>  The IESG received a request to publish draft-jones-opsec as a BCP
>  RFC. To ensure wide community review, we are soliciting comments on
>  this document from the routing community. Please send your comments
>  by February 5th, 2004.
>
>  From the abstract:
>
>    This document defines a list of operational security requirements for
>    the infrastructure of large IP networks (routers and switches) which
>    are considered to be best current practice (BCP). A framework is
>    defined for specifying "profiles", which are collections of
>    requirements applicable to certain network topology contexts (all,
>    core-only, edge-only...). The goal is to provide network operators a
>    clear, concise way of communicating their security requirements to
>    vendors. Comments to: "[email-masked]".
>
>  When commenting, please use the Routing Area mailing list
>  ([email-masked]).
>
>Alex Zinin
>IETF Routing Area Co-Director
>
>
>_______________________________________________
>routing-discussion mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Ross Callon <[email-masked]>
Date: Thu, 05 Feb 2004 11:50:27 -0500

Examples.

         Examples.
         
thanks, Ross