[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: Address as IV [was] Size of IV field in DES-CBC mode
I'll point out that, in general, since user layer protocols make
frequent use of IP addresses (see, for instance, FTP), it is not
in general possible to operate conventional TCP/IP applications in
which addresses are not the same end to end. (Socks based firewalls
take enormous pains to allow users to hide this from the remote
applications, not always with success.)
Paul_Lambert-P15452@email.mot.com says:
> In the real world, IP addresses are not always end-to-end. Examples:
>
> - Tunneling of non-IP protocols
In this context, however, we would assume that the encrypting IPSP
tunnel would have to end at the end of the IP tunnel since IPSP is
only defined in an IP context. (other contexts might be defined but
this being the IETF we concern ourselves with IP.)
> - Mobile IP
Mobile IP addresses ARE end to end.
> - IP / IPSP1 / IPSP2 (double encryption with IPSP)
But in this instance, again, we would assume that the end of each
encrypting tunnel would necessarily have access to the IP address from
the beginning of the tunnel.
> 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.
Thats true, one might have a router protect things on behalf of other
hosts, but, but as SAIDs have been defined in our discussions as being
endpoint dependent rather than some sort of universal identifier, it
isn't the option of the transmitter to use a single SAID for all such
traffic.
In any case, in the context of using a hash of the source and/or
destination address with other material as an IV, it appears that
layering problems or the end-to-endness of IP addresses should NOT be
a reason not to do this. There may, of course, be other reasons not to.
Perry
References: