[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNS Security
Hilarie,
You are correct in that one argument I can see for doing security
services in a protoocol above the IP layer is that you can make use of
them without requiring an update of or more interfaces with the IP
layer. However, this still requires that the other party you are
talking protocol x with (say ftp for an example) updates. If you want
secure ftp between machine h1 and h2, is it more likely that you have
an updated ftp server and client for those machines with a special ftp
security protocol or is it more likely that they both have an updated
IP? It's hard to say in general but sooner or later I think the
proliferation of higher level security protocols will slow down and
more and more dependence will be put on al IP level protocol.
Note that, when this happens, (1) further implementations of the
higher level protocol security (ie, ftp security) will slow down or
cease and (2) you will then be faced with adding links to the IP level
security to ftp implementations resulting in two distinct sets of
secruity services in your ftp. This sort of duplication and confusion
points to dropping additional higher level services and concentrating
on IP security unless there is a very good reason to add the
particular higher level security service.
The IP security protocol (IPSP) will no doubt be used in many ways.
On would be to secure all or almost all of the packets coming in or
out of a host (or subnet, etc.). This could have the effect of
carving out a private net where users could not communicate outside a
limited circle. But I think more commonly the facilties will be
available and the security services needed (authentication and/or
encryption and/or time stamps and/or etc.) will be requested as needed
by applications and the services used by a remote sender will be
flagged and provided to higher level protocols on unsolicited incoming
packets.
Certainly some services, like DNS, are mostly happy to respond to
anyone's UDP request packet coming in. But I think that many users of
DNS services would like authenticated responses so they can't be
spoofed. There are also places that prohibits zone transfers to
"outsiders" for security reasons who would like authentication and
maybe even encryption of such transfers. And if you permited update
transactions to change the DNS database, you would certainly want
authentication. So yes, there are many cases where you would want to
act differently depending on the security services that were provided
with an incoming datagram. But that is no reason to duplicate those
services in every protocol above raw IP. Communication between the
higher levels and IP, which exists now, will just have to be slightly
expaned.
Donald
From: "Hilarie Orman" <ho@cs.arizona.edu>
In-Reply-To: Your message <9304081856.AA28311@skidrow.ljo.dec.com>
>While applauding the call for consolidation of security services into
>appropriate layers, I think I see a counter-argument to the need to
>feed datagram security requirements into the IP layer. The services
>themselves can easily be configured to use host-to-host signed,
>private datagrams that provide the authentication required for
>securing their services. Perhaps they would share some sort of
>certificate or key information with the IP layer, but there is no need
>to be dependent on the IP layer itself for security. In fact, it is
>somewhat awkward to do this, because some services will accept
>requests (reads) from any host, but accept changes (writes) only from
>a trusted subset. Upon receiving a datagram, they might have to query
>the IP layer as to its provenance --- was this an authenticated
>datagram or not?
> Hilarie Orman
References: