Subject: Re: Newbie Question about addressing impacts

From: [email-masked] (Noel Chiappa)
Date: Fri, 13 Aug 2004 11:19:58 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > I repeat my comment from when I first saw Mike O'Dell's original 8+8
    > proposal: "It's architected NAT." I think anything that massages
    > locators, whether it's in the host stack or in a proxy, comes down to
    > architected NAT. Which means there is going to be state, so that th
    > massage can be reversed, so that the ULP always sees the same e2e
    > identifier. 

Ah, no. If my recall of 8+8 is correct, *only* the lower 8 bytes was to be
used as the end-end identifier. The high-order part (massaged to contain the
appropriate topology location information) was to be ignored for end-end
identification purposes.

Obviously the binding between the two needed to be protected, to prevent e.g.
connection hijacking (unless end-end authentication were used at all times).
This was one of the big problems with 8+8, where the entity which handled the
"locator" part was *not* the end-end entity. Therefore, even had the binding
been secured, the end entity would have had to trust another entity to
securely manage the binding.

In fact, with all schemes which propose to move the management of the binding
to some entity other than the end-end entity (i.e. if you propose to *not*
have the end-end entity know its locators, and manage and secure the
bindings), you have the same problem.

Either i) you have to use end-end authentication at all times (i.e. the
identity-location binding doesn't need to be secured), or ii) the end-end
entity has to trust some other entity to manage and secure the binding.
Actually, though, now that I think about it, you always need a minimal amount
of security on the binding, other you can have a DoS attack - some third
party can change the binding, causing the connection to fail. So option i) is
not in fact really viable.

So that brings up back to the basic architectual point: if you separate
location and identity, either the end-end entity named by the identity has to
manage the binding (and know something of locators), or it has to trust some
other entity to secure its bindings.

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Aug 2004 09:39:08 +0200

I don't feel this thread is helping us... old arguments, which we
have set aside in order to make some progress.

Certainly, when we reach the end of our present exercise (i.e.
developing the wedge layer solution to the point where a real proof
of concept becomes possible, and we can suggest a concrete
re-chartering to the IESG) we will need to confront the proposed
solution with these issues. But that is some months away.

Can we let the design team proceed in peace?

    Brian
    WG co-chair