[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FWD: IPSP Alternatives
Russ,
I'm sorry to say that, for the reasons given below, I don't accept your
analysis into three alternatives.
>From: US1RMC::"Russ_Housley.McLean_CSD@xerox.com" 8-DEC-1992 16:29
>To: ipsec@ans.net
>Subj: IPSP Alternatives
>
>IPSECers:
>
>[repeat of stuff from draft charter]
>
>I see three likely alternatives for IPSP.
>
>Alternative 1: Network Layer Security Protocol (NLSP)
>
>This alternative adopts the connectionless form of ISO NLSP with minimal
>changes. This technique will probably be compatible with the current IP and
>the revised IP (IP version 7). Basically two changes are being considered.
>The first change is clearly mandatory for the Internet protocols to work; the
>second change is needed to support super-encryption in some network
>topologies.
>
>First, NLSP needs a protocol field to carry the next-protocol identifier. The
>next-protocol field in IP will indicate that NLSP is above IP, and the new
>field in NLSP will indicate which protocol is above NLSP. This is the
>traditional demultiplexing technique used in Internet protocols.
>
>Second, NLSP does not permit NLSP to run over itself in all possible network
>topologies. In particular, NLSP cannot be implemented at both hosts and
>routers, such that the routers super-encrypt the host encrypted traffic, unles
s
>some other network protocol runs between the two instantiations of NLSP.
>
>Alternative 2: A Convergence Protocol for NLSP
>
>This alternative leaves NLSP unchanged, but defines a convergence protocol to
>carry the next-protocol identifier. This technique will probably be compatibl
e
>with the current IP and the revised IP (IP version 7). One advantage with thi
s
>approach is that the same convergence protocol would work with the ISO
>Transport layer Security Protocol (TLSP). This approach does not address
>super-encryption in all network topologies, but assumes that ISO will make the
>necessary adjustments to NLSP to resolve this problem.
I'd like to know, from practical point of view, what the real
difference between the above alternatives is. I'm sure you will
correct me if I'm wrong, but I don't see any. In one case you add a
field to NLSP for the next protocol and declare that it can be nested.
In the second case, you add a field to NLSP, except that you give it a
much more complicated sounding label ("convergence protocol") and for
some reason that baffles me completely, you fail to declare that it
can be nested but instead claim some need to wait on the ISO process.
(And why do you belive that ISO will do it at all let alone within
the schedule this WG adopts?)
>Alternative 3: Customized IP Security Protocol
>
>This alternative does not use any ISO defined protocol. Instead, IPSP is
>designed specifically for IP. The lessons from SP3 and NLSP will be used to
>avoid some of the same pitfalls. With this approach, the resulting IPSP may
>not be compatible with the revised IP (IP version 7).
Both alternatives 1 and 2 above, if you want to consider them
different, took an ISO protocol and modified/augmented it. I can't
understand why some change makes them still be ISO protocols somehow
likely to work with IPv7 while being a little further from NLSP makes
something not an ISO protocol suddenly subject to the spectre of not
working with IPv7. Unless you could plug them into each other (in
some logical sense) and have them interoperate, they are not the same
protocol. Thus it seems clear that the output of this WG will not be
any ISO defined protocol, no matter what, although parts of it, such
as key certificate formats, could conform to an ISO standard.
Perhaps for Alternative 3 you meant "Customized *IPv4* Security
Protocol". If so, you need to either broaden the alternative or
add a 4th alternative.
It seems to me to be pretty pointless to try to evaluate this
alternative without a concrete proposal. Perhaps I will try to come
up with one.
>In order to speed IPSP developemnt, I would like to start a discussion of the
>pros and cons of each alternative.
>Russ
Donald