[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FWD: 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 authenticate 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 lik
e
>>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
I don't want you to think that I see this sort of unilateral security
as the only way to good. Negotiated security which can use more
efficient symetric security will be very important as well.
However, I do think that unilateral security is required in some cases
to practically maintain the integrity of network operations. Note
that the material being authenticated need not include the destination
or even the source address, TTL, etc. (However, the source address
must be used in determining the authenticity of the message.) If
messages are not time stamped, signatures could be precalculated and
stored until the data changed or cached when first calculated on
demand. Even with time stamps, given the general IPv4 timeout of 4
minutes, you could probably cache them for 2 minutes. It would be
intersting to see what fraction of queries received by the top level
DNS servers are repeats of other queries within the past few minutes.
If a machine has multiple interfaces (ie, IPv4 addresses), the same
public key could be associated with them all. Cycles are getting
cheap and I think they will be much cheaper by the time any IP
security protocol is widely deployed.
>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.
Well, there would be nothing wrong with only signing responses to
requests with the security option specified. In the case of DNS
queries, you could only sign request that claim to be authenticated
but not actually bother at the DNS server to check the authentication,
avoiding that effort. Of course, if someone is out to mount a denial
of service attack by over whelming you with requests, they would catch
on to this right away, but none of this IP security protocol
discussion so far has talked about denial of service and I'm not
convinced this would make matters that much worse than they are now.
There is no way to resist such denial of service attacks in the
current Internet. Sure, you can look at the source addresses of
requests and ignore those from hosts/networks/whatever that are
sending "too many" but then they can forge random source addresses.
Presumably that is one of the reasons we want authentication. In
fact, the more I think about it, the more it seems like, if this is a
problem, you should carefully handle and be sure to respond to
authenticated requests that are not an excessive request stream from
one source and give unauthenticated requests lower priority. (Might
be an interesting strategy to encourage people to implement the
security protocol :-) ! ) People can still probably deny service by
just fire-hosing packets at you...
I realize that what I have said above may make my previous arguments
for an option somewhat weaker. However, it still might be useful to
have only one cached version with authentication that you send
outregardless of the security status of the request. Also, IP was
originally designed with options and the software interfaces on many
systems are designed for ease in receiving and specifying options.
Encapsulation may be "better" in many ways (for example, I think SIP
as IPv7 has a lot going for it) but it is frankly installed base
hostile.
>This is not to say that it wouldn't be useful to sign stand alone 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.
I think the type of key exchange you suggest is an excellent idea.
The only thing I would suggest is that the key exchange should be
considered to be "out of band" and asynchronous with respect to the
data transfers which should be tagged with a small "key number" field
or something. Thus you could do key rollover without disruption
(would be particularly important for attempts at secure isochronous
traffic like voice). If you kept the previous key N around for up to
4 minutes after getting a valid datagram using key N+1 (mod field
size), you would also have no trouble with re-ordered datagrams. In
fact, I think the "exchange" should include agreement on the
algorithm(s) to be used, the key management to be used, and the key
exchange itself if appropriate (would not, for example, if the agreed
upon key management was manual distribution in which case the exchange
would just be agreement to use key number N out of the set S of keys
that had been manually distributed). With this you could, if you
want, have algorithm rollover as well as key rollover.
(In case you haven't figured it out, I think sequence numbers are, as
they say "Right out!" (ie, a bad idea) for an IP security protocol.
Ordering isn't part of the IP level which is what this is suppoed to
protect.)
>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.
I am not sure this is practical. Assume a large net of some sort.
Assume a couple of routers. Assume the pipe(s) to the outside world
from one of them go down. It has to redirect everything it gets to
the other router. If you have an option, the router can calculate
authenticated redirects and just send them out. If bilateral security
is required, a blizzard of key negotiation and secure connection set
up would have to occur, probably enough to drown a lot of real
traffic.
Of course, I am assuming these hosts have cached the public key for
the router or else you get a significant amount of DNS traffic to get
it (although the DNS servers involved would all cache the relavent
responses)... I am also assuming that the hosts don't already have a
bilateral agreement with that router for secure communications...
Maybe the real advantage of being able to do things in the manner I
have suggest is that there is less state information. With bilateral
security, this poor router would have to set up keys with everyone of
a possibly huge number of hosts... I certainly think less state
information is a good thing and goes with being connectionless..
If a reasonable encapsulating protocol is defined with half an eye to
the size limits of options, it does not seem that hard to define an
option version of the host-to-host protocol for use where you have not
already determined that the other end understands the encapsulating
security protocol and its not worth the effort to test this and then
maybe negotiate a more efficient algorithm&key because the traffic
you want to send is of the nature of an isolated datagram.
>Phil
This has already run on too long,
Thanks if you have read this far,
Donald