Subject: RE: Enforcing unreachability of site local addresses

From: Dan Lanciani <[email-masked]>
Date: Mon, 3 Feb 2003 17:57:38 -0500 (EST)

"Tony Hain" <[email-masked]> wrote:

|Dan Lanciani wrote:
|> "Tony Hain" <[email-masked]> wrote:
|> 
|> |Suspend disbelief for a moment, and consider a name 
|> resolution service 
|> |where the consumer edge widget was responsible for both tracking 
|> |topology changes, and updating a branch of the name tree to keep it 
|> |aligned. Said widget would need a secure mechanism to graft 
|> itself to 
|> |the name tree after an address change, but otherwise might 
|> look like a 
|> |typical DNS server. [...]
|> 
|> It's not much of a suspension.  I've been saying for years 
|> that exactly such a mechanism is necessary to push the 
|> routing task out to the end nodes where ample resources will 
|> be available.  If it isn't done at some other level it will 
|> have to happen in the DNS.  However, I believe that the DNS 
|> is the wrong place for it.
|
|There is an important difference between pushing all the way to the end
|system, vs. the edge router. While architecturally there is little
|difference, when the mapping function is in the end system the level of
|churn on the registration infrastructure is substantially higher.

Why?  The level of churn is determined by how often you renumber, not
by where you translate the identifier to the locator.

|Moving
|that to the consumer edge/set top provides both a platform that is
|generally more stable in its availablity, as well as an aggregation
|point for the bulk of the device churn.

My proposal works equally well in end nodes or in edge routers.  Obviously
you get somewhat more benefit from a shared cache on the edge router, but
you seem to be saying something more significant is going on.

|> |Given that as a
|> |starting point, there is no obvious reason that using name 
|> strings as 
|> |the identifier is more difficult than any other approach.
|> 
|> Using name strings may be no more difficult with respect to 
|> the implementation of the name service, but it leverages far 
|> less existing code than would a fixed- length binary 
|> identifier.
|
|Existing code is not a reasonable argument to justify the architectural
|change of inserting an additional name service into the system. 

Is existing code a reasonable argument for sticking with the current system?
Inertia seems to be the justification for much of what we have.  Any new system
that required wholesale changes in higher layers would be shot down for just
that reason.  You can't have it both ways.

|> Consider the advantages of using an identifier 
|> that has exactly the same format as what we currently call an 
|> address, i.e., 128 bits.  With translation happening near the 
|> bottom of the IP layer, no changes would be necessary in tcp 
|> or in applications.  
|
|Unless the application was trying to associate the source address of the
|packet with something it knows about.

This doesn't make any sense.  The applications never see anything but the
portable identifiers.

|If there is a 'transparent'
|mapping function in the system, apps that expect that service will
|break.

Applications won't "expect" anything.  If this system were implemented
it would simply replace what we currently call addresses with portable
identifiers.

|If such a mapping service is to work with said apps, there needs
|to be a mechanism to distribute the mapping table with some level of
|authenticity.

Not the table, just the entries that are of interest to particular consumers.
Why do you believe that this is any more difficult than what DNS is currently
expected to do?

|If you are talking about essentially in-line encaps like
|8+8, every routing edge would need to map the source locator as well as
|destination. 

Yes, of course the source has to be mapped as well.  There are different
ways to handle this, perhaps avoiding the overhead of explicitly carrying
around both values.  See my original notes in the Sep. 99 archives for some
possibilities.

|> The problem of tcp connections
|> (not) surviving renumbering would disappear.  The DNS would 
|> work just the way it is, so no duplicate effort would be 
|> required.  
|
|Wait, a string to string translation happens in the DNS, then you claim
|another string to string translation is not a duplicate effort !?!?! 

No, you are completely missing the point.  If the fast-changing mappings
are handled in a separate 128b->128b transformation (one perhaps optimized
just for this purpose) then there is no need to fix the existing DNS to deal
with fast-changing mappings.  The DNS would continue to hold long-term mappings
(from name to portable identifier) which could continue to be updated with
the existing semi-manual process.  The duplicate effort that is avoided is
that of enhancing the DNS to deal with fast-changing dymanic mappings.

|The request/response is not the problem. Explain how it handles a
|scalable, secure update as nodes move between 802.11 hotspots of
|different providers.

You are introducing a different problem.  I proposed only to fix the
aggregation/allocation/renumbering mess.  I said it would likely make
mobile IP easier; I didn't say it would make it free.  How exactly do you
think the use of arbitrary strings will solve the new problem that you
have introduced?

|If that problem is solved, there is no reason for
|such a mapping system be limited to 16B fixed length strings.

There is no correlation between solving that problem and selecting a 128->128
mapping.  The latter is purely a matter of convenience for existing code.
If you want to scrap the entire existing v6 suite and start over then I'd
be happy to help, but I don't think that is going to happen.  If we did do
this then we could just start with an explicit source-route model and avoid
the trap from the beginning.

|>  The latter final response is assumed to come from a server 
|> under the control of the owner of the identifier.  
|
|Basically what I was suggesting by pushing the service to the customer
|edge.

We seem to be confusing two different things.  The actual transformation
of addresses in packets can happen at end nodes or in edge routers.  The
servers that provide the information necessary to perform those mappings
can exist anywhere, much as DNS servers do today.  I would not be inclined
to make the latter servers resident within the edge routers, but it is not
out of the question.

|> Obviously, 
|> responses would also include the usual TTL values and such 
|> much as a DNS response does.  The mapping service actually 
|> scales a lot better than the DNS because it can increase the 
|> depth of the tree as necessary by splitting on arbitrary bit 
|> fields in the identifier.  This should be transparent (think 
|> unix DBM).
|
|The only thing that limits DNS is the assumption that the branching is
|limited. If name strings were device.customer.aol.cc... there is no real
|difference to parsing on a bit boundary.

Are you kidding?  Yes, sure, if you made domain allocation hierarchical and
forced people to change their names when they changed providers then there
would be more opportunity for deepening the tree.  This would make names almost
as useless as addresses.  Talk about a step in the wrong direction...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Mon, 3 Feb 2003 16:02:58 -0800

Dan Lanciani wrote:
> | ...
> Why?  The level of churn is determined by how often you 
> renumber, not by where you translate the identifier to the locator.

Ok, that was not well worded. Any node that renumers will have to update
some mapping server in the network. That function will require some
authenticity, therefore a scalable trust model. If we put the
identified/locator mapping function on the consumer side of the existing
routing trust boundary, the authentication tools we have today will
scale (ie: ISP cert in edge router, shared secret for consumer devices).
If my devices show up at different networks and registers their new
addresses with my edge router at home, the scaling impact is
substantially lower than if they all try to update some central store in
the ISP.

> My proposal works equally well in end nodes or in edge 
> routers.  Obviously you get somewhat more benefit from a 
> shared cache on the edge router, but you seem to be saying 
> something more significant is going on.

I am sure we can make mechanisms work either way, but there is a trust
boundary here and the more often we cross it the more complex the tools
become. 

> 
> Is existing code a reasonable argument for sticking with the 
> current system? Inertia seems to be the justification for 
> much of what we have.  Any new system that required wholesale 
> changes in higher layers would be shot down for just that 
> reason.  You can't have it both ways.

I am not arguing that we can't change the higher layers. All I was
pointing out was that using something that exists to justify defining
something completely new is broken. If we are really talking about a
completely new architecture we should not assume that any existing code
will meet the yet to be defined requirements. It might work out that
way, but we can't base the decision on it.

> ...
> |Unless the application was trying to associate the source address of 
> |the packet with something it knows about.
> 
> This doesn't make any sense.  The applications never see 
> anything but the portable identifiers.

Consider the SMTP server that wants to reject connections from a group
of servers. If there is no indication of topological grouping, that
server would have to look up all the portable identifiers to find out
what to filter.

> Applications won't "expect" anything.  If this system were 
> implemented it would simply replace what we currently call 
> addresses with portable identifiers.

No, it is very different. Current portable identifiers include some
degree of topology information. 

> 
> |If such a mapping service is to work with said apps, there 
> needs to be 
> |a mechanism to distribute the mapping table with some level of 
> |authenticity.
> 
> Not the table, just the entries that are of interest to 
> particular consumers. Why do you believe that this is any 
> more difficult than what DNS is currently expected to do?

Scale. If every device on the net today were registered in DNS & could
change that registration at will for topology changes, they I would
agree. Reality is that the current DNS handles a very small subset of
nodes, and the vast majority of those are static entries. The reasons
for this are lack of a trust infrastructure to allow arbitrary updates,
coupled with the lack of distribution appropriate to accommodate the
scale. We can't give DNS servers to the consumer because the existing
system is too arcane, and we can't support DDNS for every network
enabled device in the ISP servers because we don't have a trust model
that scales.

> Yes, of course the source has to be mapped as well.  There 
> are different ways to handle this, perhaps avoiding the 
> overhead of explicitly carrying around both values.  See my 
> original notes in the Sep. 99 archives for some possibilities.

Optimizing in one place just moves the problem somewhere else.

> No, you are completely missing the point.  If the 
> fast-changing mappings are handled in a separate 128b->128b 
> transformation (one perhaps optimized just for this purpose) 
> then there is no need to fix the existing DNS to deal with 
> fast-changing mappings.  The DNS would continue to hold 
> long-term mappings (from name to portable identifier) which 
> could continue to be updated with the existing semi-manual 
> process.  The duplicate effort that is avoided is that of 
> enhancing the DNS to deal with fast-changing dymanic mappings.

At the expense of having to do two mappings for every connection. The
proposal is to make the whole system slower rather than fix the problem
at the source. 

> You are introducing a different problem.  

No, that is the core of the DNS problem. DNS can already handle the
request/response load. What it doesn't do is provide a scalable way to
update the changes.

> I proposed only to 
> fix the aggregation/allocation/renumbering mess.  I said it 
> would likely make mobile IP easier; I didn't say it would 
> make it free.  How exactly do you think the use of arbitrary 
> strings will solve the new problem that you have introduced?

It is not a new problem, and I am just pointing out that inserting a new
name system doesn't do any good unless it solves the authentication
issues. If it does that, there is no reason to limit it to fixed length
strings.

> There is no correlation between solving that problem and 
> selecting a 128->128 mapping.  The latter is purely a matter 
> of convenience for existing code. If you want to scrap the 
> entire existing v6 suite and start over then I'd be happy to 
> help, but I don't think that is going to happen.  If we did 
> do this then we could just start with an explicit 
> source-route model and avoid the trap from the beginning.

If one only looks at the resolution part of the problem, then existing
code and fixed lengths are a natural draw. The reason this exercise is
even being undertaken is that we don't have the authentication
infrastructure to update mappings to begin with. If we create that
infrastructure it would apply just as well to DNS, so why would we need
multiple layers of name to address translation.

> We seem to be confusing two different things.  The actual 
> transformation of addresses in packets can happen at end 
> nodes or in edge routers.  The servers that provide the 
> information necessary to perform those mappings can exist 
> anywhere, much as DNS servers do today.  I would not be 
> inclined to make the latter servers resident within the edge 
> routers, but it is not out of the question.

It is a convinent aggregation point that aligns with the routing trust
boundary.

> |limited. If name strings were device.customer.aol.cc... there is no 
> |real difference to parsing on a bit boundary.
> 
> Are you kidding?  Yes, sure, if you made domain allocation 
> hierarchical and forced people to change their names when 
> they changed providers then there would be more opportunity 
> for deepening the tree.  This would make names almost as 
> useless as addresses.  Talk about a step in the wrong direction...

We are only moving the problems around here. People already deal with
updating email addresses when they change providers, or employers, so it
is within some degree of reason. For those that multi-home or want to
mask their provider from the name, they can always register for a name
in cc, then work out the authentication process with the providers.

Tony