Re: GxSE & ESP/AH

[RJ Atkinson <rja@inet.org>]

Earlier, Mohan said:
>> There was another suggestion that we can rewrite the destination
>> address by DSBR, that will also break IPsec because you can't
>> locate the SA (SAs are looked up using dst_addr, SPI). I agree
>> that it might be too early to discuss about IPsec issues.

At 13:58 22/06/01, Paul Francis wrote:
>Clearly IPsec would have to change to accomodate this.  I assume 
>something like use the ID part of the source address and the 
>whole destination address as part of the encrypted body, 
>and use the SPI and any of the list of addresses to identify 
>the incoming packet.

<CAUTION>
        I'll use precise terms (ESP/AH) rather than imprecise
terms (IPsec) in this note.   I've never quite puzzled out what
"IPsec" precisely means, so try not to use it when precision counts...
</CAUTION>

        ESP/AH use the Destination IP Address & SPI for locating the
Security Association applicable to an incoming packet.  The SPI
is not affected by GSE or GxSE, so won't be discussed further.
The Destination IP Address was chosen instead of the Source IP Address
because of the need to fully support IP multicasting.  The use
of any *IP address* for this purpose has always been known to be
undesirable and a by-product of an insufficiently rich naming
architecture for The Internet.  The right answer has always been
to use a topologically-independent namespace for ESP/AH purposes,
but no such namespace exists and is widely deployed today.  Note
well that DNS does NOT work for this because a FQDN does NOT uniquely 
name a single TCP/IP stack -- instead an FQDN quite often names a 
service or content (e.g. www.cnn.com is NOT a system, but rather a 
cluster of servers with a middle box in front).

        Now, the original GSE proposal was sunk in its original form
as soon as the "Privacy (sic) Address Autoconfiguration Extension"
appeared, because the low order bits could no longer (probabilistically)
identify a single TCP/IP stack.

        Some work is going on in the IRTF Namespace Research Group 
(NSRG) on whether one or more new namespaces would be appropriate
to add to the Internet Architecture.  IMHO, the NSRG is unlikely
to achieve unanimity on this question, though some form of very
rough consensus seems possible.  HIP is an example of an item that 
has come out of the NSRG.  THere is one more proposal (at least)
still cooking in the NSRG.

        My own view, which dates back at least to the early 90s,
is that we need to have a topologically independent namespace
for individual systems.  If such existed, it would be worthwhile,
IMHO, to spin ESP/AH to take advantage of this capability.

        Bottom line is that ESP/AH is NOT a reason to stop work
that is otherwise useful.  It is helpful, however, to consider
how ESP/AH will need to be tweaked depending on what happens
with a given proposal for multihoming.

Ran
rja@inet.org