Re: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.

[Ross Callon <rcallon@juniper.net>]

> bw> I was expecting some specific guidance
> here.  For example, support for
> bw> SNMPv3, SSH, etc. Instead, this section just talks about some
> ways
> bw> that things *might* be secured.  Based on this section, I
> guess one
> bw> could use SNMPv2 over TLS over TCP *or* SNMPv3 *or* SNMPv2 over
> IPsec
> bw> to secure management traffic and be compliant. If the goal is to
> use a
> bw> management station to securely manage devices, that level of
> guidance
> bw> is not helpful.
>
> What this is trying to say is that devices that use unencrypted
> telnet, http and SNMPv1 for management fail the requirements.
>
> Earlier (pre-IETF) versions said things like "use SSH", but I
> was
> advised that such sepcific requirements would cause the doc to
> become
> quickly dated and preclude advances (such as netconf) that met the
> spirit of the requirement.

Let's suppose that the document said "Use SNMPvX running over
IPSec with yyy encryption". Then lets suppose that six or eight
months from now someone finds a problem with yyy encryption, 
or comes out with a better form of encryption. Do we want the 
document to be outdated in six or eight months?

Similarly, what if we say the same thing, but an operator prefers
to manage their networks using XML over IPSec, and lets suppose
that the security aspects are equally good, but they have
implemented
applications which make mistakes significantly less likely. This 
may
be a net security win (due to the smaller number of mistakes). Even
if
it is neutral from a security point of view, it may have other
advantages. 
Do we want to preclude this?

Similarly, the security threat implicit in having hackers break into
network management will depend upon other details of how the 
network is set up. For example, there are some networks where 
there are a moderate number of very large routers, and where *all*
incoming interfaces (from customers) have packet filters set which
prevent the customers from sending packets to the routers (ie, 
they can't set the IP destination address to be the address of an 
internal router within the network). In this case hackers can't break
into a router because they can't send a packet to the router at
all
(they can send packets via the router, but only if the destination
is
not the router). In this case the urgency of encrypting network 
management might be lower than in other cases. 

We have a state today where many routers are protected only by
a simple password with is trivially easy to guess. We have a state
where many routers are managed using entirely "in the
clear"
unencrypted and unauthenticated network management. It seems
to me that making things *perfect* is not likely to happen in the 
next year or two. I am not sure that we could ever agree on
precisely
what constitutes perfect. Making network security substantially
better
needs to happen, and for some of the details there are several
options on how this can be accomplished.  

Ross