[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[4]: IPSEC at Dec IETF
Perry,
This all sounds good. Mainly because I though this is close to where we left
off at the last meeting.
The bundling provided by the transforms allows a simple representation of
multiple algorithms and format considerations. IPv6 forces the transformations
to be 64 bit aligned. This would means that one network layer security protocol
can protect both IPv4 and IPv6. Different transformations would be supported
for different security services, export considerations, and IPv6 alignment. The
IPv6 aligned transformations are only necessary between in IPv6-to-IPv6
security encapsulations.
IPv6 also has identified a requirement for a transparent authentication only
encapsulation mode. This requirement was not met by IPSP and was our basis for
consolidating the IPv4 versus IPv6 issues from the last meeting. IPv6 does need
it's own authentication protocol to meet this requirement.
I am reiterating these points because we seem to be saying the same thing now
but your draft specification did not seem to reflect these ideas. Are we on the
same wavelength now?
Paul
_______________________________________________________________________________
Subject: Re: Re[2]: IPSEC at Dec IETF
Author: perry@imsi.com@INTERNET
Date: 12/1/94 5:16 PM
X-Reposting-Policy: redistribute only with permission
Paul_Lambert-P15452@email.mot.com says:
> I have a one comment on this ... if you change the header format it is no
> longer IPv6 pure.
That is not really true. The AP header is identical to what we already
agreed on and the ESP is identical other than the contents of the
opaque portion of the packet. The opaque portion is, well, opaque, and
I'm merely suggesting that it be made even more opaque by making it
security transform dependant. Under that circumstance, Ran's drafts
and what we were proposing as IPSP become completely identical -- so
there is very little point in having two specs.
> At the last meeting, we were moving towards replacing the IPv6 encapsulation
> with IPSP.
It would be better to say that after a couple of days we re-derived
the v6 encapsulation and decided to try to have one encapsulation and
call it IPSP, but it was basically just Ran's encapsulation.
> It looks the group has reached a branch point in the IPSP. We need
> to decide if IPv6 purity is more important than efficiency.
I am not certain that this is an issue. The only way this comes up is
in the question of how many bytes are used inside the opaque portion
of the opaque encapsulation to define "next header" or the
equivalent. If Ran is willing to let this be transform dependant the
specs suddenly become absolutely identical and ther is no longer a
reason to declare them to be two different protocols.
Perry
Follow-Ups: