[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: Networking Model for Crypto-services [was] Re[2]: Ad
Carl,
>This is true, the IP addresses are not true end-to-end, but they are
>end-to-end between the cooperating IPSP entities.
What if an IPSP encapsulated packet is originated from a system that is not
running IP? This is not in the scope of our IETF specification, but has been
proposed in other forums (ISO 11577 over IEEE 802.3). In the IETF environment
we have a cleaner networking model, but once again we should not limit the
application of IPSP by the selection of a an IV mechanism that requires a
specific layering of protocols.
>>
>> Also, consider router-like scenarios where a device decrypts traffic for
>> multiple addresses. Traffic between pairs of router-like devices could be
>> protected with a single SAID, even though there might be several visible
>> "black" addresses.
>
>This may be the crux of my problem. Do you envision router-based encryptors
>putting the addresses of the true recipients on the "black" side
>(unencrypted), or do the "black" addresses simply indicate the source and
>destination encryptors? I expect that when doing encapsulation at a router
>the true addresses are carried as part of the encapsulated data, and that the
>addresses used to transport IP datagrams through the unprotected network
>indicate the encryptor and the decryptor (which may be the true recipient
>or the router serving the recipient).
>
>If the router attempts to simply encrypt the data on the way out, without
>changing the addresses to map to the encryption service providers, several
>potential problems arise. First, how is fragementation dealt with, for a
>destination on a richly connected network, fragments may arrive through
>different (encrypting) routers. For decryption to be correctly performed the
>entire datagram must be reassembled, where is this done? Since the only
>destination address provided is the host, he will get all of the fragments
>and reassemble them, but how does he decrypt it? Second, Lets assume that the
>routers do MTU discovery, fragment before encryption, and encrypt as
>mentioned above (only addresses visible are true source and destination). How
>are the keys and SAIDs shared between all routers serving the destination?
The mapping of "Red" to "Black" addresses is an interesting issue. There are
many mapping combinations, and most can and have been made to work. In the
IPSP specification we should provide a recommendation on this topic. The
simplest approach is to set the Black addresses equal to the decrypting peer
entity address and the source Black address to the source encrypting entities
address. This is the best approach for preliminary releases of IPSP. All of
the issues that you raise above on "transparent" address mapping are
legitimate, but have been solved before. I only wanted to illustrate examples
of many-to-one mappings of IP addresses to SAID. I am not advocating this
approach for our baseline IPSP.
>>
>> We should not limit the usage of IPSP by using specific IP fields outside of
>> the IPSP encapsulation. For our specific discussion on IVs, there are
several
>> other viable options.
>
>My immediate reason for pursuing the IP address usage is to support the
>multicast work we are doing. With multicast users sharing a key, IV
>clashes may pose a problem, IP source addresses provide a clean way to
>divide up the IV space uniquely. Also, stealing the IP address should be less
>computationally intensive than CRCs or MD5 (though not padding or repeating
>the pattern).
Please provide a better explanation of IV clash. This sounds like an algorithm
specific issue. We have been discussing the DES-CBC-MD5 usage of a shortened
IV. Does DES-CBC-MD5 have a IV clash problem with multicast traffic?
>I agree that several different options exist, but this seemed to be as good a
>point as any to begin this discussion of network models. I've been a little
>troubled by the lack of coverage of the potential addressing issues. In the
>BLACKER, CANEWARE, and SDNS work a great deal of thought went into defining a
>model of encryptor addressing (single catenent vs dual catenet) which would
>actually work in the networks envisioned.
Single versus dual catenet is early eighties terminology that does not
adequately capture all of the possible addressing approaches. Currently, the
IPSP work is tending towards a "dual IP" model with peer encryptor addressing
(IP / IPSP / IP). Note that the IPSP model is cleaner than the SDNS model
(IP/SP3-D) which had SP3-D define a field that contained a complete IP header.
The most significant change from SP3 to IPSP is the addition of a next protocol
field in IPSP!
SP3 required a interoperability mode that only carried "red" addresses (SP3-I)
and a no address mode (SP3-N). IPSP uses the next protocol field to
encapsulate or tunnel a "red" IP packet (like SP3-D) or directly carry
transport data (like SP3-N).
Back to addressing, I propose that we decouple the lower layer IP address from
the processing of the IPSP encapsulation. If we do this, any of the addressing
models can be made to work.
Paul
Follow-Ups: