Having exchanged a few mails in the secure-BGP, SNMPv3 and syslog mailing
lists recently, I would be interested in seeing a 'common' approach where
possible.
Two main security requirements seem to shine through:
1) the ability to authenticate the level-4 information. BGP needs to know it
can trust the subnets being advertised, SNMPv3 wants to know that a user is
allowed access to a particular attribute, and syslog servers want to be able
to back-check the validity of incoming syslogs.
2) the data needs to be 'secure' over the network.
For 1), S-BGP uses PKI with certificates allocated per Autonomous system and
per address range. SNMP uses an authentication key (which may be derived
from a password). Syslog is yet to be determined.
For 2), S-BGP uses IPSEC/IKE/PKI (optionally), SNMPv3 uses the
nothing/auth-key/encryption-key/both-keys, syslog is to be determined.
Now for wire-protection, there is nothing better than IPSEC - in my view -
given the level of protection given to the entire packet, the dynamic key
management, and the availability of IPSEC on typical syslog/SNMP/BGP capable
devices, and now available with operating systems.
For Level-4 authentication, PKI is the best, but should probably be
partnered with a 'easy-start' method.
An SNMPv3 variance to this worth mentioning is that SNMPv3 supports
selecting protection per set of management objects, for example, a policy of
'passwords-sets must be authenticated and encrypted, interface-counter-gets
can be in the clear' can be specified.
This all comes down to a matter of policy. In the end, IPSEC will always
offer more for wire protection than a higher-level scheme (because of the
position in the stack), and today has the most complete
key/crypto-management scheme, and supports the most robust authentication
method (PKI). In some installation, a 'light-weight' application level
scheme may be sufficient - a matter of policy.
In the case of remote management/monitoring, an IPSEC tunnel to the target
device is possible allowing Telnet, tftp, SNMP, syslog... to be performed
securely over the Internet - probably the best reason for running
router/switch/firewall management over IPSEC.
Steve.
-----Original Message-----
From: Jon Callas [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 12:32 AM
To: Waters, Stephen; Chris Calabrese
Cc: [EMAIL PROTECTED]
Subject: RE: IPSEC usage to protect syslog
There are a couple of things I'd like to add to this discussion.
As I read our proposed charter, what we're trying to do in it is to scope
the working group -- that is to say, describe the problem we're trying to
solve rather than come up with a solution. It may very well end up that
IPsec is the solution, but we should talk about the problem before we come
up with a solution.
The obvious exception would be if the problem is so simple that simply
doing syslog over IPsec would solve the problem. Then we wouldn't need a
working group at all. I think we do need a working group, because there are
many problems we're trying to solve, few of which IPsec solve. Furthermore,
with some of those, there may be a better solution, like TLS. But again,
we're trying to describe the problem, not come up with the solution at this
stage of the game.
Nonetheless, here is my quick description of things we're considering here:
(1) Syslog is unreliable. If you send a message, you don't know that it
will get there. Furthermore, you don't know when it doesn't get there. You
don't know that the server you're talking to is the right one.
(2) Syslog is not secure. Anyone can sniff messages that go by, trivially.
Anyone can trivially conjure up bogus data. Data can be damaged in transit
(by accident or malice) without detection.
(3) Syslog data is not secure. There are no integrity checks in the data
that improve its usefulness as an audit log or evidence.
There are a number of these issues that can be solved by not using UDP.
There are a number of them that can be solved by using IPsec. There are a
number of them that can be solved by using TLS. There are still others that
none of these address, even if you mandate that you use TLS on IPsec on TCP
(yes, yes, I know that TLS implies TCP). Ironically, the ones that matter
most to me are the ones that IPsec has the least to do with. TCP and
checksums would make me much happier than lots of crypto. And I'm a crypto
guy! In fact, I'll say it now that my worries are more that we do overkill
on the crypto. This is why we're forming a working group. We want to
discuss these issues.
Now on the other hand, I'd love to hear what the BGP people decided, and if
their solutions apply to us, then I'm sure we'll be happy to use them too.
On the other hand, I suspect the problems we're trying to solve are
different problems (otherwise we could just drop syslog and use BGP
instead, eh?).
Jon
-----
Jon Callas [EMAIL PROTECTED]
Director of Engineering +1 (408) 556-2445 (voice)
Counterpane Internet Security +1 (408) 556-0889 (fax)
3031 Tisch Way, Suite 100 PGP: 42C6 AD1A 98B7 84B4 349E
San Jose CA 95128, USA 1528 EC0C ED80 D65E 3DFD
