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

RE: Re: IPSEC & ROAD



I have a different view.  I think that a good part of any "IP Security 
Protocol" needs to be an IP Option.  This is particularly true of 
authentication.  Here are some reasons:

	(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.  After you have converted your local routers to produce 
authenticated redirects, you don't want to have to make all your hosts 
understand this or even have to keep a table of which do and don't.  (There was 
some joking at the IETF about using a forged redirect to 127.0.0.1 as a 
particularly effective form of source quench...)  Similarly, there is little 
reason to secure queries to the DNS, or any similar public database, but it 
would be nice to have authenticated responses always generated where the 
destination of the answer could be authentication aware or not.  An unknown 
option is supposed to be ignored so a security option, when used in 
authentication mode, should have the desired effects.  You could also protect 
against replay with a time field.

	(2) You would like to be able to send "secure" datagrams through 
various filters that look at the protocol field and perhaps port.  For 
authentication only, they can look as deep into other layers as they want.  If 
you want confidentiality and to still be able to get through such filters, you 
would need some kludge like a field that says where encryption starts in the 
"data", so you could leave the TCP header, say, clear if you wanted.  I'm not 
sure just how much this variable encryption start byte would be worth but it 
does not seem all that hard.

I think you would only want to use an encapsulating protocol in cases where you 
want confidentiality for the underlying protocol type or for one or more end-to-
end IP options.

Donald

PS:  To get stuff like that in item 1 above to work, you probably have to store 
public keys in the DNS and have the DNS servers be some of the first to be 
secured.

--------------
From:	US1RMC::"karn@qualcomm.com" "Phil Karn"    29-NOV-1992 05:12
To:	ipsec@ans.net, nmh@thumper.bellcore.com
Subj:	Re:  IPSEC & ROAD

I think IP version issues are probably orthogonal to the IP security
design I had in mind.

An "IP security protocol" should be just that - a modular "protocol"
that rides above IP. The Protocol field in the IP header would contain
a (newly assigned) value meaning "security protocol". The original
Protocol value (e.g., corresponding to TCP or UDP) would move into a
field inside the (encrypted) security protocol header. On the wire,
the packet might look something like this

Link header, type = IP|IP header, PID=security|security header, PID=6|TCP|data
|<-            clear                        ->|<- encrypted                ->|

This makes the security protocol a modular component that could ride
on top of any IP-like protocol, regardless of address size or format,
and under any transport protocol.  And when practicality (i.e., lack
of universal implementation) dictates that you use the IP security
protocol in a "security gateway" instead of in the hosts being
protected, you use a separate mechanism (e.g., protocol 94, IP-IP) to
carry the "inner" IP datagram on top of the security protocol:

Link |"outer" IP hdr|security hdr, PID=94 | "inner" IP hdr, PID=6 | TCP|data
|<-        clear  ->|<- encrypted                                         ->|

If the security protocol follows this general design, then it ought to
be independent of IP version, so long as protocol fields remain 8 bits
wide. And as long as IP remains connectionless (if it doesn't, I quit!
:-).

Phil