[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: IPSEC & ROAD
>From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 30-Nov-1992 1632" <dee@ranger.enet.dec.com>
>(1) You would like to authenicate ICMP messages (redirects, quenches,
>etc.), DNS responses (even if the query isn't authenticated), etc. This
>requires some way to sign the datagram, perhaps with an RSA signed digest like
>thing. However, you don't want to have to negotiate this with the destination
>and would like things to "work" even if the destination is ignorant of the
>security protocol.
Hmm. At first glance this does seem like a good argument for an IP
authentication option. But I see some significant practical obstacles.
Having routers and DNS servers sign responses to packets from J.
Random Host requires public key cryptography. And to do it on a
one-shot basis, a (slow) RSA secret key operation is probably required
for each one. It's not clear you'd want to spend all those cycles on
every single message, especially when you don't even know if the
recipient can make use of it. It could also open up a whole new class
of denial-of-service attacks based on overwhelming a node's signing
ability. And if you protect yourself by limiting the rate at which
signatures can be generated, then you will necessarily leave the
signatures off responses to legitimate messages.
This is not to say that it wouldn't be useful to sign standalone ICMP
and DNS messages, only that it might not be practical in the near
future.
In comparison, the kind of bidirectional communication that I envision
as the primary use of an IP security protocol would allow the host
pairs to sign their packets with a fast single-key algorithm like
keyed MD-5, using keys created and cached for some reasonable period
of time (e.g., at least 10 minutes). That means you'd only need to do
the slow RSA secret key operation once when the hosts first begin
talking and at most once every 10 minutes as long as the association
remains active. This is much more practical, especially since the
signing wouldn't take place unless both parties agree first to use it.
One could envision a negotiation that begins with the recipient of an
unsigned datagram sending a message that says "Sorry, unauthenticated
datagrams of this type are not accepted by this host. Please initiate
a key exchange." The negotiation could also determine whether
encryption is used. And once you have this whole mechanism in place
(which would fit nicely into a separate protocol, without requiring an
IP option), there's no reason why it couldn't also be used to sign
the occasional ICMP and DNS response.
Phil
Follow-Ups: