Re: An idea: GxSE

[Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>]

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

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.

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