Subject: Re: An idea: GxSE

From: "Paul Francis" <[email-masked]>
Date: Fri, 22 Jun 2001 10:58:11 -0700

>
> 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.
>

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.

PF

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 22 Jun 2001 10:45:41 -0700 (PDT)

> 
> > > Every host knows at least one (and typically only one) address for
> itself,
> > > called the self-known address (SK address).  The SK address may or may
> not
> > > be globally routable, but must be globally unique.
> >
> > I think that today there are distributed (multi-party) applications
> > that depend on an application being able to extract a globally routable
> > IP address of the box (so that it can be passed to peers etc).
> > It would be good to run the idea of apps not knowing their GR addresses
> > passed folks with better application knowledge.
> >
> > It the applications need to know the GR addresses but the host itself
> > doesn't know them then it seems like you need a way to map from SK
> > to GR addresses.
> 
> I think you are mis-understanding the model a little here (cause I wasn't
> clear about this aspect in the original message).  Applications should
> operate in terms of passing the entire list of addresses around.  SK
> addresses should not be thought of as some magic token that can be used by
> applications to learn GR addresses.  Applications should know the GR
> addresses from the start.  So here is the basic model:
> 
> 1.  A DNS lookup on the FQDN will return you the GR addresses (if you are
> outside the target's site), suggesting that at least for the initial
> contact, the application should be aware of the FQDN not the addresses.
> 2.  Applications should be aware of the complete list of addresses, not just
> the SK address.  Obviously this is tricky if a host doesn't know its own
> complete list of addresses.  But what I have in mind is this:
> 
> The socket API has a set of calls like this:
> 
>     getcurrentaddresslist1(sock_id)
>     or
>     getcurrentaddresslist2(sk_address)
>     or
>     getcurrentaddresslist3(fqdn)
> 
> When host A talks to host B, host B learns the list of addresses by making
> one of the above calls.  Ideally host A never "identifies" itself to host B
> in the application, host B simply does the first call while the socket is
> still up, learns the whole list, and uses the whole list whenever it
> identifies A, either internally or when talking to a third application at
> host C.  If for some reason it is necessary for host A to send its identity
> to host B in the application layer, host A should preferably use its FQDN,
> but could also use its SK address.
> 
As part of IPsec processing, when an inbound packet is decrypted/
authenticated (section 5.2.1 bullet 2 of RFC 2401) there is
selector verification i.e it verifies whether the source address
of the packet is the same as the one that was used in SA negotiation.
Host A would use an SK address while setting up the SA but it
is never sent end to end, so there would be a problem.

-mohan

> The second or thir call could be then used by host B if the socket has
> closed.  If host B's "network layer" (kernel or whatever) has forgotten the
> list, then both the FQDN or the SK address could be used by DNS to obtain
> the list, but the third one is more likely to succeed (and requiring that
> reverse lookups on SK addresses work even if they are not globally routable
> is possible but puts more constraints on SK addresses).
> 
> Ideally the first call would be used wherever possible.
> 
> Anyway, once host B's application gets the whole list, which it can do
> without host A knowing what the list is, it can send the whole list to host
> C so that subsequently host C can access host A without resorting to DNS.
> 
> 
> I don't think the above is real pretty---it is the cost one pays for
> isolating site addressing from global addressing and getting rid of the
> renumbering burden.
> 
> 
> >
> > > The list of addresses (GR and SK) is conveyed to partner hosts by an
> IPv6
> > > extension header---the address-list extension.  This header is typically
> > > added by the site border router as the packet exits the site.  (It could
> >
> > Having intermediate nodes change the length of the packet does cause some
> > issues with path MTU discovery. That's why encapsulation is normally used
> > (e.g. in mobile IP) to deal with this.
> 
> An alternative approach would be to have the host attach a syntactically
> correct address-list extension, but with empty place-holders for the GR
> prefix list (instead of the "address-list trigger" extension I suggested
> before).  There would be a learning mechanism, whereby address-list
> extensions would have a field indicating the number of GR prefixes, and this
> field would be set on incoming packets.  So if the host doesn't know the
> number of prefixes, it would use a default, say 4.  If it chooses too small
> of a number, then it would learn that in a subsequent return packet.  Of
> course now the partner host would not have the complete list, but this would
> not be a disaster.  (Alternatively the sending host could always add one
> more GR prefix placeholder than it thinks it needs, to catch the case where
> a new prefix has recently been added.)
> 
> Of course one could take this one step further, and simply have the
> destination host return the source host's list of GR prefixes in the return
> packet, so that the source host knows it too (on a connection by connection
> basis---this would not be something the source host could generalize about
> once the connection was closed).  This could be an option selectable by the
> application...(ah, the complexity creeps in!!!!)
> 
> >
> > > Pseudo-header checksums and IPsec would I suppose be based on the SK
> address
> > > only (not the GR addresses).
> >
> > It would be good to look at the effects of bit errors in the source GR
> address.
> > With no IPv6 header checksum and the GR address not being part of the
> > pseudo-header checksum means that it is unprotected. (Perhaps having a
> > checksum on the address-list extension can catch this.)
> >
> 
> Thinking about it a bit more, pseudo-header checksumming the SK address,
> when in fact it isn't even sent end-to-end, sounds kind of stupid...maybe
> better to cover just the ID part of the source address (and the full
> destination address, which doesn't get translated), and let it go at that.
> 
> PF
> 
> 
>

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 23 Jun 2001 21:08:14 -0400

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
[email-masked]

---

From: "Paul Francis" <[email-masked]>
Date: Fri, 29 Jun 2001 12:15:00 -0700

> cluster of servers with a middle box in front).

The fact that DNS does not *always* uniquely name a single TCP/IP stack does
not mean that it never does, and that when it does it couldn't be used to
uniquely identify the host.

Thinking off the top of my head, what you would need is for www.cnn.com type
hosts to have multiple FQDNs, at least one of them unique, and it would have
to know it was unique so that it could use it for identification.

Now I'm sure y'all have thought of this, so there must be some gotcha's in
there.  Perhaps Ran we could find some nice pub in London where you could
explain it all to me...

PF