Subject: Re: domain names as end-point identifiers?

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 10:04:05 -0700

Folks,

Thanks for the responses.  I decided to send one, aggregate response, rather
than a flood of smaller ones:

Dredging up some graduate school discussions, I suspect that this topic is
differentiated between the classic "network" model of host to host
communication, versus the "distributed processing" model of process to process
communication.

In the early 70's, for example, the Irvine Ring project (and, by the way,
Netbios, later) use the process-oriented model. For wide-area networking, this
has not gained much traction, at the lower packet-handling levels. (It was
even interesting to watch MIT take over the Irvine work and eliminate the
process addressing function.)

My point is that I'm suspecting some folks are trying to lay a very different
reference model onto the Internet than we have been using for the last 30
years.  Hence, the discussion about multihoming and mobility gets changed into
what is really an effort to change the Internet's communication reference
paradigm.

BEC> If you are looking for stable identifiers for "stacks" (in the
BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely
BEC> that an FQDN is a safe answer.

It is probably worth noting that the NSRG report uses domain names to label
the different stacks, in its own examples and in discussion.  Whatever the
reasons for that choice, I obviously find it interesting that they were used
for that purpose.

BEC> FQDNs are (mis)used in many ways;
BEC> a name like www.example.com certainly doesn't identify a given IP stack
BEC> on a given interface on a given host

1. When someone starts talking about identifying _interfaces_ I suspect they
mean address, rather than 'end point identifier'. On the assumption that that
is not what Brian meant, it's worth having this clarified. I'm confused by
Bill's comment on this: " if there is an entity at a point in the topology,
then the name maps nicely into the DNS". Domain names are not tied to network
topology. They are tied to an administrative "topology", which is an entirely
different thing.

2. If I understand the concern, here, it is that not _all_ domain names are
endpoint identifiers. Erik also raised the point that domain names are used
for different (and inconsistent?) purposes. One might be a host, another a
service.  When there are multiple records returned, they might refer to
alternative systems or they might be alternate paths to the same service.

My question is: so why does that mean that the ones that _are_ EIDs are
not acceptable?  What problems are caused by having multiple uses?

BEC> I don't see that this has any functional advantage over an IPv6 address
BEC> for that stack, and it introduces a DNS dependency for the transport layer.

1. I thought an IPv6 address was an address, not an end-point identifier.  No?

2. The concern about introducing a DNS dependency into a lower layer, like
transport, strikes me as pretty important, too. However, if we invent a new
construct for an EID, we are a) introducing a new global administration
requirement, and b) creating a dependency on it in that lower layer. So the
concern with this new dependency is on the need for an EID, rather than the
fact that it might be a domain name. No?

MT> In the case of mobility and multihoming, you might want a stable
MT> identifier on a per-packet basis which is independent of the routing
MT> layer.

A number of folks clearly have in mind using the identifier in every packet.
My question is:  Why is this needed?  What requires putting the identifier in
every packet, rather than using it a occasional, special points of an
interaction, such as initial rendezvous?

Erik's comments are particularly helpful for considering the requirements that
folks are trying to satisfy:

EN> It might be useful to split your question apart into two questions:
EN> 1. Using current domain names and their mapping to AAAA records

(or A records or even MX records or SRV records?)  At any rate, this is the
rendezvous function.

EN> 2. Using variable length identifiers

Or, to turn this one around, explaining when and why fixed-length IDs might be
needed.

EN> For #1 folks have pointed out that a currently domain names are often used
EN> as service names and not host names, and one can't tell...

my question is what problems are caused by multiple uses for domain names?
how does it break the usage as endpoint ids?

EN> I've also seen statements in the past that current domain name usage isn't
EN> one that guarantees uniqness.

I guess this underscores the need to be clear about the set of problems being
tackled. Let's remember that IP datagrams are pretty basic. There are lots of
very clever, useful things they do _not_ do.

Are we, perhaps, trying to add other functionality to the IP service, beyond
simply providing the current IP service, enhanced to support multihoming and
mobility? For example, are we trying to add extra levels of security to the
basic service, beyond simply making the use of multiple addresses carry the
same, minimal security functions present for current, single-address IP?

The "security" associated with a current, bare-bones mono-address host-to-host
IP exchange is pretty darn small. I'd summarize it as simply being the
assertion that a datagram probably did come from the IP address in the
relevant field of the datagram. That's why MAST only tries to ensure an
equivalent degree of assurance that latter datagrams with different IP
addresses came from the same "system" that sent the first one.  If you really
need stronger security, use IPSEC, TLS, or whatever.

Why do we need more, at the IP level for multihoming or mobility?

EN> One example of this are cases when
EN> www.example.com brings you to different http content from the inside of the
EN> company than from the outside of the company.

Clearly this is an important behavior.  But should it be discerned at the IP
level, or is this better suited to something above, say, transport?

EN> I think all these can be addressed and still use FQDNs as identifiers.
EN> (For instance by having some different RRtype which allows telling "service"
EN> apart from "host".)

Not surprisingly, I agree.

EN> The issues around #2 has to do with how the protocols above IP operate.
EN> If the identifier is only used to establish some state which is only used
EN> when the locators change, then it is possible to have the upper layer protocols
EN> operate on the locators when sending and receiving packets. Thus you'd have
EN> multi-locator ULPs.
...
EN> An alternate approach, which requires fixed length identifiers which can fit
EN> into existing 128 bit fields, is to have a shim layer above IP which handles
EN> id<->locator mappings and have the ULPs operate on the identifiers.

Given the MAST proposal, obviously I favor the latter.  However it's also
clear that I do not believe the EID needs to be in every packet.

I think it is a question of where some state information goes.  One is to have
the ID in every packet, making the IP address irrelevant.  (The packet carries
its own 'state' about the EID.)  The alternative is to have a table of IP
addresses that the EID maps to, and maintain the table in the participating
hosts.  Hence the IP address in the packet indexes to the EID when it is
received.)

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 12 Sep 2003 15:23:37 -0400

> Dredging up some graduate school discussions, I suspect that this
> topic is differentiated between the classic "network" model of host to
> host communication, versus the "distributed processing" model of
> process to process communication.

I think this is an exaggeration.  But as long as primary memory is
private to hosts and processes (i.e. not accessible by other hosts or
processes running the same applications or services), there will be a
need to rendezvous with, and refer to, specific hosts running specific
processes that have sole access to state that is critical for continued
operation of an instance of an application.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 16:43:04 -0700

Folks,

Thanks for the responses.  I decided to send one, aggregate response, rather
than a flood of smaller ones.:

In the early 70's, for example, the Irvine Ring project (and, by the way,
Netbios, later) use this process model. For wide-area networking, this has not
gained much traction, at the lower packet-handling levels. (It was even
interesting to watch MIT take over the Irvine work and eliminate the process
addressing function.)

years.

d/

---

From: Bhaskar S <[email-masked]>
Date: Mon, 15 Sep 2003 09:42:34 +0530

Hi,

Please could someone explain how IPv4 compatible IPv6 address is
used?

-- 
Regards,

Bhaskar S.

---

From: Tim Chown <[email-masked]>
Date: Mon, 15 Sep 2003 07:43:09 +0100

See http://www.ist-long.com/long/045Guidelines/LONG_Trans_app_IPv6.pdf
for examples of IPv4-IPv6 interactions, and where IPv4-mapped addresses
are used.

Tim

---

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 15 Sep 2003 12:36:43 +0530

RFC 2893.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Sep 2003 11:03:19 +0200

Dave Crocker wrote:
...
> reasons for that choice, I obviously find it interesting that they were used

As I recall that was a pragmatic choice...

> is not what Brian meant, it's worth having this clarified. 

I meant an interface. That could mean a physical interface, or it could mean a
virtual interface such as a tunnel termination or a 6to4 interface. BTW, these
concepts are all made a bit fuzzy by virtualization at level 2. A given Ethernet
address may well refer to different connectors simultaeously, if some level 2
box is doing fancy footwork to distribute transport connections around a server
cluster.

As far a I'm concerned, an address is just a string of bits. Whether it's a
locator or an identifier depends on context. What it locates or identifies
depends on context.

> I'm confused by

Possibly none, but exactly the same argument applies to the bit strings
formerly known as address. As Lewis Carroll would perhaps have said, they
mean what we want them to mean.
> 1. I thought an IPv6 address was an address, not an end-point identifier.  No?

No. "Address" is an overloaded concept in IPvN {N=1,4}. They will do just fine
as identifiers if we want.
> fact that it might be a domain name. No?

If we use "address" bit strings as identifiers, we are *not* adding either
a new administration or a dependency. We are just being a bit clearer about
the double semantics of "addresses" (id and locator).

   Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 15 Sep 2003 21:22:59 +0900 (JST)

> Please could someone explain how IPv4 compatible IPv6 address is

	its use is deprecated.

itojun

---

From: Tim Chown <[email-masked]>
Date: Mon, 15 Sep 2003 14:05:14 +0100

> > Please could someone explain how IPv4 compatible IPv6 address is

Ah, misread compatible for mapped.  Don't see compatible mentioned very often
now as Itojun says :)

Tim

---

From: "Robson Oliveira" <[email-masked]>
Date: Mon, 15 Sep 2003 13:59:48 -0300

Hi Itojun,

Could you let us know where is documented the IPv4 compatible deprecation?

I believe that some future confusions could be prevented regarding which
address continue to be used if a new documentation has been published.

robson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jun-ichiro itojun Hagino
Sent: Monday, September 15, 2003 9:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Example for IPv4 compatible IPv6 address?

	its use is deprecated.

itojun

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Sep 2003 15:17:54 -0700

Dave,

I've been trying to stay out of this discussion, but there's one point in
your email that I think needs comment, and since I haven't seen anybody else
make it, I guess it's up to me.

> relevant field of the datagram.

Well, I think an argument could be made that even this isn't guaranteed.
Given the lax security on address translation for the link between the last
hop router and the host, various kinds of attacks could be mounted that
would allow an attacker to send a packet that looked as if it originated
from a particular IP address claimed by a victim on the subnet. In addition,
from what I've heard, some ISPs don't have any ingress filters in place, so
such an attack could even originate from another subnet. With wired
networks, this isn't so much of a problem because the physical access to the
last hop can be restricted, or (in the case of serial access) restricted
using PPP or other means. With wireless networks and broadband networks that
use shared access media, there may be an issue, however.

> That's why MAST only tries to ensure an

For mobile networks, there's a need if the mobile host is allowed to send a
routing update to the correspondent host. The correspondent host needs some
assurance that the routing update came from a node that is authorized to
issue such an update. This is only a problem because, unlike the presumed
security of the routing infrastructure itself, end hosts presumably cannot
be trusted to issue routing updates only on their own behalf.

I don't know enough about the specific problems of multihoming to make a
comment on that.

            jak

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Sep 2003 15:38:56 -0700

James,

>> The "security" associated with a current, bare-bones mono-address
>> host-to-host IP exchange is pretty darn small. I'd summarize it as simply
>> being the assertion that a datagram probably did come from the IP address
>> in the relevant field of the datagram.

JK> Well, I think an argument could be made that even this isn't guaranteed.

That's why I said "probably".  But my real point is that relying on that
"probably" is at the core of most TCP and UDP use today.

By suggesting that additional security issues go beyond the specific needs of
multiaddressing, I am certainly not suggesting that those issues are minor.

However I find that clarity about the goals being served helps design
processes quite a bit.  At the least it can help avoid feature creep, and
thereby facilitate simpler design and easier adoption.

JK> For mobile networks, there's a need if the mobile host is allowed to send a
JK> routing update to the correspondent host.

I cannot imagine anyone seriously disagreeing with you.

d/

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 15 Sep 2003 17:03:12 -0700 (PDT)

> interaction, such as initial rendezvous?

I don't think an identifier is necessary in every packet.
But I do think it makes sense to have a shim layer above IP which
uses locators in the packets below (for IP's routing) and presents
fixed length identifiers in the pseudo-headers passed to/from the upper layer
protocols.
The reason having identifiers in every packet isn't useful is that if
you want to avoid facilitating redirection attacks of packet flows,
then the receiver needs to verify at some level the relationship between
locators and identifiers. The state (which can be soft-state created
dynamically using a protocol similar to MAST) needed for this verification
allows the receiver to recreate a packet with the same identifiers as what was 
sent by the peer ULP. Thus between the ULPs the shim provides a service which 
passes what looks like packets containing 128 bit identifiers, even though on 
the wire the packets have 128 bit locators.

> same, minimal security functions present for current, single-address IP?

I think the goal should be to not be any worse than
the current IPv4 internet.
In that Internet it is relatively easy for an attacker on the path
between the two endpoints to redirect the packet flow - for instance
it can use ARP spoofing like attacks to siphon off packets.
But attackers that are not on this path can at most inject
packets - with bogus source addresses in many cases.

> being the assertion that a datagram probably did come from the IP address in
> the relevant field of the datagram. That's why MAST only tries to ensure an

To analyze the security you have to look a more than just the IP layer.
With TCP the initial sequence number makes it a tad bit harder (especially
with non-guessable ISNs) for an off-path attacker to spoof a connection.
While other protocols, such as DNS over UDP, require just guessing a 16 bit
number in order to spoof a DNS response.

   Erik

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 14:07:02 -0700

Erik,

EN> I don't think an identifier is necessary in every packet.
EN> But I do think it makes sense to have a shim layer above IP which
EN> uses locators in the packets below (for IP's routing) and presents
EN> fixed length identifiers in the pseudo-headers passed to/from the upper layer
EN> protocols.

I believe you have described the common characteristic to the set of solutions
I classed as "IP Endpoint" in the -analysis- paper I issued last night. It
distinguishes a "shim" approach from an "ip-es" approach with a shim being
more backward compatible for the upper layers, but that is a nicety, rather
than a key point, I believe.

EN> The reason having identifiers in every packet isn't useful is that if
EN> you want to avoid facilitating redirection attacks of packet flows,
EN> then the receiver needs to verify at some level the relationship between
EN> locators and identifiers.

yes!

EN>  Thus between the ULPs the shim provides a service which
EN> passes what looks like packets containing 128 bit identifiers, even though on 
EN> the wire the packets have 128 bit locators.

Yes. I've come to the view that that is really what MAST (and I believe LIN6
and HIP) are trying to do, though I originally described it in NAT terms.

128bits vs. 32 is a v4/v6 distinction, not an architectural distinction. The
point is that transport sees something that is like what it is used to, but it
no longer is really a locator. Instead it is an identifer that the new layer
(shim, ip-es, or whatever) maps to the locator.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2003 23:09:58 -0700

Folks,

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2003 22:53:39 -0700

Folks,

d/