[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Encapsulation vs options
Tom,
I don't see this as all that big a deal.
The security functionality you get with encapsulation and with an option are
virtually the same. That decision for IPv4 seems to me to mostly rest on how
compatible things will be with the installed base. I favor an option in IPv4
because I think it will work better particularly with the urgent problem of
authentication of "control" datagrams. You can even get multiple levels of
"encapsulation" easily with an option by just encapsulating IP in IP and
specifying the option at more than one level. The exact same fields as are
present in such an option could be present in an encapsulating proctol header
for SIP or other "IPv7".
Whether you use encapsulation or an option, you still have to decide about
providing (1) "unilateral" security, (2) negotiated security, or (3) both. (I
think both is the only way to go.) You still need to decide about
authentication/integrity, time stamps, confidentiality, and maybe even non-
denial stuff. You still need to figure out how to specify crypto algorithms
and keying techniques (whether unilateral or negotiated) and standardize a few
of them so people can interoperate while letting anyone who wants to use their
own private algorithms and keying techniques, etc.
Donald
--------------
From: US1RMC::"teb@saturn.sys.acc.com" "Tom Benkart" 4-DEC-1992 09:16
To: ipsec@ans.net
Subj: Encapsulation vs options
It seems like two different concepts for any "IP security" functionality
have been advanced. One involves encapsulation/sublayers, while the
other favors true IP options in the IP header itself. Is there real
consensus on which way to go? The schedule in the proposed charter
assumes SP3/NLSP as a starting point - if we don't agree on marching in
that direction, the schedule may not work.
Tom Benkart
ACC Systems