Subject: RE: GUSL proposal (very crude)

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Nov 2002 20:59:56 -0800

Mark,

> Mark Smith wrote:
> I've always thought we were trying to solve this same
> single problem, and GUPIs and GUSLs were basically the
> same thing.

GUSL solves the merger thing, but not the VPN.

It was my original intent that GUSL could solve the VPN and inter-site
connect as well, but Keith convinced me that it would be an
architectural change and overall not a good idea to do.

I see GUSL as a relatively low-ambition proposal that would solve some
of the problems associated with site locals (but not all) and could
reach consensus quickly.

> Or is it that the wording below stating that GUSL
> addresses SHOULD NOT be used between sites if traffic
> will transit links _that are part of the public
> Internet_ (excluding a private VPN tunnel over the
> public Internet) ? If so, I agree with the text,
> though it probably needs to be a bit more explicit
> about what it is SHOULD NOTting.

Site-local addresses MUST NOT be routed outside the site. GUSL *are*
site-locals, and therefore must not be used for site-to-site
communication.
This part in the GUSL proposal is un-necessary as it basically is what
is in the DS today; I included it to remove the potential
misunderstanding that I intended to use GUSL to solve the inter-site
connect as well.

I'm happy to include "site-to-site communications MUST use GUPI
addresses" as soon as there is a GUPI draft available.

GUPI is the next step to GUSL. They could be merged, but I think GUPI is
not ready for consensus, so there is some value in separating them.

In other words: I think that GUSL is a no-brainer. It's not a miracle,
but it does address two issues that I hear were a pain associated with
site-locals: ambiguity and multi-site.

The point I am trying to make is: let's nail GUSL if we can, and get
something done that everyone could agree on. _Then_, let's work on
inter-site communication, which is what GUPI is about, and which
requires a lot more work.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: 28 Nov 2002 16:39:42 +1100

> GUSL solves the merger thing, but not the VPN.

I'm not sure I see the difference.

Presuming running IPsec in tunnel mode, the outer addressing (ie your
tunnel end points) is using global addresses, but the inner addressing
is what ever you like it to be (and is hidden from the Internet anyway
as the IPsec ESP encrypted payload).

What addressing would nodes use when they decide to talk to each other
over the IPsec tunnel ?

If the nodes use their global addresses, then the IPsec tunnel becomes a
single-hop short circuit of the Internet routing infrastructure between
the sites. The advantage it adds is the encryption and authentication of
the traffic between sites. But if nodes want to that level of security,
an alternative is to do end-to-end opportunistic IPsec between the nodes
themselves.

I'm not sure if there is a problem with using global addresses inside a
site-to-site IPsec tunnel, I'll need to think about it some more.

I do need to put together a follow up email on a related IPsec /
site-local topic though.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2002 09:56:01 +0100

> I'm not sure I see the difference.

I agree. As longs as GUSL prefixes are unique, you can flat route
them in a "foreign" enterprise network. Maybe some ad hoc static routes
are needed, but that's common in inter-enterprise VPN setups.

  Brian