[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS Security

Don,

You raise a number of interesting issues.  I wholeheartedly agree with the 
notion of defining one protocol to provide security transparently for many 
client protocols, rather than have each application protocol provide his own 
security mechanisms, excluding, of course, E-mail.  But I disagree with your
assertion that the IPSEC WG is "concentrating mainly on proposals patterned 
after 'connection oriented' ISO protocols."  

Actually, I disagree with your assertion that the ISO security protocols that
have been discussed in the IPSEC WG "...always require set-up, critical state
at both ends, and tear down, even if all you are trying to do is push through 
one secure datagram."  In fact, the security protocols as such are simply
encapsulation protocols, and any mechanism may be utilized to establish the
shared keying material at both ends, which may include sending it in the clear
header as the value (or a permutation of the value - there was a gentleman
from DEC at the last meeting who used just such a method) of the Security 
Association Identifier (conceptually, this field contains an identifier that 
identifies the particular "Security Association" (Key and Attributes) that needs
to be referenced to understand this PDU), or using a previously established 
Security Association of long standing (yes, a separate set-up step in thus 
required, but comparing this, as you did, with the overhead of a communications
association establishment is misleading, since the set-up exchange required
for establishing a communications association is required each time
communications is initiated, whereas the security association may be left in
place for a long, long time....thus "tear-down" may also not be necessary...)

In conclusion, I think the requirements that you have brought up will have to
be considered. But I don't think they impact the Security Protocol that much
(perhaps they require a different interpretation of he SAID field), rather I
think they have to be kept in mind as we try to settle upon a key management and
authentication scheme.  (Perhaps we should insure that we can prepare long
lived keying material?)  I would firmly hope they don't entail developing
another, separate security  protocol.  

Anyway, you brought up some good issues to keep in mind. I think we should add 
these to the list of requirements* from the last meeting that we are supposed 
to be coming to closure on.  


Jim Zmuda

* Has anyone got the complete list from the last meeting? I got the following 
down:

* Clear Header
  - Security Association Identifier
  - PID  (Issue for debate!)
* basing formats on NLSP (a rancorous issue for debate!)
* Sequence integrity (swIPe has, NLSP-CL doesn't.
  Almost agreed to drop.  Still an "issue" for E-mail debate.)
* Fragmentation.  (We all agree to not handle within the security
  protocol. Not needed for ES implementation.)
* "peak through" (filtering routers problem)
* Word alignment (needed for efficient implementation of some upper layer
  protocols, like NFS.)
* Padding
* ICV
* works with CLNP, as well as IP
* Overhead
* efficiency
* Encipherment
* key Managment
* Negotiation of services

and Don's requirement
* support infrequent, isolated  "connectionless application" traffic
efficiently

etc.....
Follow-Ups: