Subject: Re: [rrg] Next topic: properties of identifiers

From: Patrick Frejborg <[email-masked]>
Date: Wed, 1 Jul 2009 23:47:07 +0300

Hi Christian,

I think host identity together with a generic session identification
mechanism would make it easier to promote the decoupling, there would
be more good reasons to upgrade the stack - e.g. server load balancing
and troubleshooting in the "middleboxed" Internet would be a lot more
easier to carry out.

HTTP deploys cookies to identify sessions and a Server Load Balancer
uses the cookies to do load balancing, especially if the clients are
behind a NAT device. Using cookies as the session identifier is the
only mechanism to ensure that the client is communicating to the
correct real server, also to achieve good load balancing if there are
many clients behind one NAT device.

Also SIP people are building their own mechanism to identify sessions
http://tools.ietf.org/html/draft-kaplan-sip-session-id-02

1.2. The use-case for Session-ID

   The need for a unique identifier is driven by the need to
   troubleshoot SIP sessions as they cross SIP nodes.  Troubleshooting
   is more complicated if multiple legs of the session are on different
   sides of B2BUA's, due to the lack of a common identifier to tie the
   legs together.  Currently proprietary mechanisms are used to achieve
   this.

It seems that application people are already developing their own
specific solutions to have an end-to-end session identifier mechanism.
HTTP uses cookies, SIP is developing their own mechanism and perhaps
there are more applications having similar solutions developed or
under construction - could this get out of control, if every
application develops their own method to identify an end-to-end
host/session???

It would be great if the transport layer (or something between the
transport and network layer) have a standardized host identifier (not
relying on the network locators) with a session identifier that all
applications could access - if the application developers find it
useful. And the middleboxes should not be allowed to touch the
host/session identifier - the main purpose of the identifier is to
provide a troubleshooting tool that provides visibility behind
NAT/middleboxes, a mobility enabler (with a session identifier you
might restart a TCP connection, security issues arises and now I'm on
thin ice) and a new routing architecture enabler.
A host/session identifier could be e.g. the following: the host part
derived from the MAC address from one attached NIC and the session
identifier could be just a random counter that changes every time the
application layer initiates a new session. So one part is globally
unique and the other part is session unique - just as an example.
Ports are used to identify services and I don't see a reason to change
that mechanism.....or??

-- patte

On Tue, Jun 30, 2009 at 11:14 PM, Christian
Vogt<[email-masked]> wrote:
> Hi Patte -
>
> You are absolutely right that decoupling services and sessions from
> their location would be highly useful.  The current conflation of
> identification and location certainly has serious disadvantages.  For
> example, decoupling would mitigate the routing scalability problem.
>
> But are you saying that using a host identity as part of service or
> session identification is necessary to achieve this decoupling?
>
> - Christian
>
>
>
> On Jun 30, 2009, at Patrick Frejborg wrote:
>
>> Hi Christian,
>>
>> I think service identification and session identification is belonging
>> to the transport layer in the IP reference model  - in the OS model
>> they are on separate layers. So in the IP model I would collapse them
>> under one identifier, I think that is what we have today. E.g a TCP
>> connection is identified by the five tuples; source and destination
>> addresses, source and destination ports and protocol. But here the
>> problems starts, a connection/session/association is identified by
>> elements from the network layer (source and destination addresses) -
>> thus the border between the network and transport layer gets very
>> blurred. I believe that this is the reason why we today need to have
>> global unique IP addresses, with global addresses we can identify
>> connections on hosts, security and NAT nodes - it is the only method
>> at the moment, right?
>>
>> Adding a host identifier to the IP reference model wouldn't add much
>> value - unless it can decouple the dependency between network and
>> transport layer. If the host identifier could give an identity for a
>> connection without deep dependency to the network layer an new world
>> opens. I.e. a connection could be identified by some other mechanisms
>> than the network tuples. Then we could migrate from a single-level
>> address scheme to a multilevel address scheme and create a better
>> routing architecture without the need to have global unique addresses.
>> And mobility would be much easier to achieve, i.e. if connections are
>> identified by something else it doesn't matter when the underlying
>> network changes - the application will not be aware and doesn't care
>> about the network parameters.
>>
>> SCTP goes in this direction but the current mainstream transport
>> protocol is TCP. Guess people will not move their applications to use
>> SCTP instead of TCP in order to improve the routing architecture of
>> Internet, right?
>> I think the only way is to fool TCP that underlying network is still
>> the same though it isn't - something is needed between the network and
>> transport layer that the applications aren't aware of. By having a new
>> layer we could change the underlying addressing scheme with backwards
>> compatibly to the current addressing scheme - not all stacks needs to
>> be upgraded since it is backwards compatible. This will not improve
>> mobility but mobility will be improved once people are starting to
>> move their applications to use the host identifier to identify
>> connections on the transport layer. Would people move their
>> applications to support mobility? I think it is matter of time, there
>> are so much mobile devices connected to Internet that enterprises will
>> see business opportunities to move applications to an infrastructure
>> that better supports mobility, this is long term vision but guess it
>> will happen.
>>
>> So I think the identifier(s) should be designed to decouple the
>> transport layer from the network layer. Opponents will say that all
>> hosts must be upgraded, this is not true if the the new stack is made
>> backwards compatible with fallback mechanisms to the current
>> architecture.
>>
>>
>> -- patte
>
>
>
>

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 2 Jul 2009 10:41:22 +0300

Hi Christian,

trying to come up with more arguments and here is an early simple
idea, more or less a brain dump that you (all of you) should try to
shoot down.

NAPT devices have to keep track of both IP addresses and ports, the
binding can become quite complex. But if the connection also have host
identifiers in the header of the datagrams the NAPT box doesn't need
to keep track of the ports - the connection can be tracked with the
help of the host identifier.

Not so interesting but it gets better if the host identifier is added
to the DNS record. By adding a host identifier to the DNS record the
NAPT box could accept traffic from the Internet and redirect it to the
correct host in the private network. This can be achieved by having
the DNS entry as the IP address with the public IP address of the NAPT
box and the host identifier with the global unique identifier of the
internal server. Then you create a static binding at the middlebox - a
host identifier is binded to the internal IP address of the server.
Now the middlebox can handle both inbound and outbound connections,
with one public PA IP address, and still provide end-to-end visibility
in case you need to troubleshoot sessions. Also the meaning of DNS
changes slightly, a DNS look up tells us today "what is the local IP
address of the server". With the host identifier added the DNS look up
would tell us "via this attachment point at the border of Internet the
internal host can be reached".

How then to achieve multi-homing? Well, add a second middlebox to the
organization's network - the second middlebox should have a PA-address
from another service provider and then two DNS records are needed,
same host identifier record with two different A-records, each with
weights so one of them is the preferred path (just as an example). If
the primary path goes down the clients should after a while try to use
the secondary path. And here is the session identifier needed - since
the network path changes TCP connections needs to be restarted, this
can be achieved if there is a session identifier coupled to the host
identifier. But this will also open up for man-in-the-middle attacks -
should we try to solve this on the network or transport layer?  I
don't think so, instead the transport layer should inform the
application layer that the network parameters has changed (could be an
attack) and then it is up to the application layer - should the
credentials for this session be re-verified or not - it depends on the
content of the application (the lower layers should not get involved
with the content).

If this is really doable the outcome is that PI-addresses are no
longer attractive, you can publish services towards Internet with your
internal addressing scheme - the routing architecture of an
organization is an internal affair and Internet doesn't need to know
about how it is constructed. But still external customers, partners
etc. can reach your published services with the help of the host
identifier.

It seems that adding a host identifier to the Internet architecture
will provide better visibility of end-to-end connectivity and at the
same time hide more the routing architecture, interesting...

Or do I miss something, this is an early idea and there might be some
severe flaw in my thinking.

-- patte

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 2 Jul 2009 12:25:44 +0300

Sorry for sounding like a broken record player, but I have a strong  
deja vu.

> Not so interesting but it gets better if the host identifier is  
> added to the DNS record.

RFC5205

> By adding a host identifier to the DNS record the NAPT box could  
> accept traffic from the Internet and redirect it to the correct host  
> in the private network.

See draft-ietf-hip-nat-traversal-08.txt and draft-melen-spinat-01.txt  
for two different ways.

> How then to achieve multi-homing?

RFC5206

> etc. can reach your published services with the help of the host

I completely agree. Those were some of our goals.

> same time hide more the routing architecture, interesting...

I think we wrote something about those already in RFC4423.  (And  
others before that, see e.g. NIMROD...)

-------

[Then I hear all the usual objections on HIP from the list.  To them:   
Yes, you can use HIP without ESP (but we still need someone to define  
exact how).  Yes, we can use HIP without public key crypto, see draft- 
heer-hip-lhip-00.txt.  No, architecturally HIP does not necessarily  
add packet size as it can use any flow identifier as a proxy for host  
identifier.  No, HIP does not necessarily add delay when opening TCP  
with legacy hosts, draft-lindqvist-hip-tcp-piggybacking-00.txt.

Ducking back wondering why people want to invent the same again and  
again...]

--Pekka Nikander

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 16:05:03 -0700

On Jul 1, 2009, Patrick Frejborg wrote:

> mechanism would make it easier to promote the decoupling, there  
> would be
> more good reasons to upgrade the stack - e.g. server load balancing  
> and
> troubleshooting in the "middleboxed" Internet would be a lot more  
> easier
> to carry out.

Patte -

So you are saying that it would be useful if (part of) a session
identifier identified the host that is keeping the session state.
Perhaps.  Or, more specifically, session identifiers should also
identify the /stack/ that is keeping the session state.

But I am still unconvinced that session identifiers really should
identify anything else but a session.  There are two reasons:  First, if
they did, session mobility would be constrained, because a session would
by definition be bound to something else, such as a host or a stack.
Second, given a pure session identifier and the session's address, I
don't yet see a general benefit of having a host (or stack) identifier
in addition.

The emphasis here is on "general", since there will certainly be
applications that need host or stack identifiers.  But again, those host
and stack identifiers will be application-level components, and don't
have to be defined as part of Internet architecture in my personal
opinion.

- Christian

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 7 Jul 2009 19:13:18 +0300

Pekka,

thanks for playing that record again, I got familiar with LHIP - which
is a very interesting draft, indeed.

-- patte

On Thu, Jul 2, 2009 at 12:25 PM, Pekka
Nikander<[email-masked]> wrote:
> Sorry for sounding like a broken record player, but I have a strong deja vu.
>
>> Not so interesting but it gets better if the host identifier is added to
>> the DNS record.
>
> RFC5205
>
>> By adding a host identifier to the DNS record the NAPT box could accept
>> traffic from the Internet and redirect it to the correct host in the private
>> network.
>
> See draft-ietf-hip-nat-traversal-08.txt and draft-melen-spinat-01.txt for
> two different ways.
>
> I think we wrote something about those already in RFC4423.  (And others
> before that, see e.g. NIMROD...)
>
> -------
>
> [Then I hear all the usual objections on HIP from the list.  To them:  Yes,
> you can use HIP without ESP (but we still need someone to define exact how).
>  Yes, we can use HIP without public key crypto, see
> draft-heer-hip-lhip-00.txt.  No, architecturally HIP does not necessarily
> identifier.  No, HIP does not necessarily add delay when opening TCP with
> legacy hosts, draft-lindqvist-hip-tcp-piggybacking-00.txt.
>

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 7 Jul 2009 13:00:27 -0700

On Jun 26, 2009, at 10:24 AM, Christian Vogt wrote:

> Dear all -
>
> I am catching up on folks' previous discussion on identifier  
> properties.

I'm doing the same, albert 10 days after Christian, in preparation for  
next IETF. Just finished all the msgs on this thread.

> This discussion is really useful; I wish I had participated earlier.

same here!!!

I'll save the detailed comments for a face-face chat as next IETF is  
really coming soon.
For a quick comment here: I'd just say that I would like to second the  
view some other people have expressed earlier, that is whether a good  
architecture should have nothing more than necessary --- this is  
quoted from one of Joel's msgs but I removed the adjective "absolutely".
I view a good architecture as a good engineering design, the necessity  
should be measured by whether it is the best engineering tradeoff;  
pushing a design to the extreme point may or may not represent the  
best tradeoff.

Lixia

> One thought that has been brought up is the inevitable coexistence of
> multiple types of identifiers.  This makes sense given the variety of
> things to be identified.  In fact, the multitudinousness of  
> identifiers
> is not new:  Many applications have their own identifiers already  
> today.
>
> But are all these identifier types essential elements of an Internet
> architecture?  I would argue most of them are not -- they are useful
> within the scope of a particular Internet application, but they are  
> not
> essential for the Internet per se to function.  In fact, I see only  
> two
> purposes for which the Internet architecture must have identifiers:
>
> (1) service identification, identifying a piece of communication
>    software that responds to incoming contact establishment attempts
>
> (2) session identification, identifying the protocol state  
> corresponding
>    to a particular session after contact establishment
>
> Individual Internet architecture solutions may use combinations of  
> more
> than one identifier for either of these two purposes.  For example,
> service identification in the existing Internet is achieved by  
> combining
> a host identifier (DNS name, or IP address in its role as a host
> identifier) and a host-local service identifier (well-known port
> number).  So an Internet architecture may have more than two types of
> identifiers.  But again, it seems that all of those identifiers would
> serve only the above two purposes, after all.
>
> Given the distinct identifier purposes, the properties of identifiers
> may naturally be specific to a particular purpose.  For example, the
> property of enabling session referrals clearly applies to only session
> identification, but not to service identification.  On the other hand,
> stability is a property that is more important for service
> identification than for session identification, since two hosts  
> engaged
> in a session may be able to handle changes of session identifiers.
>
> Thoughts?
>
> - Christian
>
>
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 7 Jul 2009 13:45:02 -0700

On Jun 30, 2009, at 6:13 AM, Patrick Frejborg wrote:

> ......

I think so.

> that better supports mobility, this is long term vision but guess it

Patte, the above are all great comments.
To my view, the work by multipath-TCP people seems to match what you  
described above: don't try to change TCP, but make use of it by adding  
some sort of sub-layer, in their case it is a sub-layer that makes use  
of multiple simultaneous TCP connections, and backward compatible (and  
might  handling mobility as well).
In case not everyone has heard: a MPTCP BOF has been scheduled on Wed  
morning of IETF week.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 8 Jul 2009 15:58:35 -0700

top posting:
- it is a generally accepted notion that some sort of identifier(s)  
needs to be added to the existing architecture (I'm writing up a short  
notes on my own understanding of why now, and why *not* day one)

- since god did not write us a bible on how to design networks, we  
have to learn as we go.  And one of the things I have learned from  
last 30 years: never be too sure about the future's need.  A winning  
strategy seems including the following ingredients:
   + start simple, and
   + stay flexible, keep the mind open.

Along that line of thought: we need to understand the interplay  
between address (used for routing) and this forthcoming identifier  
thing, but I would keep the focus on address/routing, not nailing down  
the exactly numbers and definitions of identifiers.

Lixia

---

From: Christian Vogt <[email-masked]>
Date: Wed, 8 Jul 2009 19:53:13 -0700

Hi Lixia -

I certainly agree with your winning strategy.  And if you prefer not to
discuss identifiers on this mailing list, so be it.

I still would like to observe, though, that a good understanding of what
needs to be identified may prove helpful in devising the locators that
must lead to the things being identified.

This said, I do understand your impatience to bring the discussion to
the core topic of this research group.  This, in fact, reminds me of a
result from the Dagstuhl workshop in March, which the research group
didn't yet evaluate -- namely, the following set of locator properties:

- topologically sensitive

- multihoming‐capable

- local and constant cost for topological changes

Would a discussion of these locator properties be in scope?

- Christian

On Jul 8, 2009, Lixia Zhang wrote:

>   needs to be added to the existing architecture (I'm writing up a
>   short notes on my own understanding of why now, and why *not* day
>   one)
>
> have
>   to learn as we go.  And one of the things I have learned from last
>   30 years: never be too sure about the future's need.  A winning
>   strategy seems including the following ingredients: + start simple,
>   and + stay flexible, keep the mind open.
>
> between
> address (used for routing) and this forthcoming identifier thing,  
> but I
> would keep the focus on address/routing, not nailing down the exactly
> numbers and definitions of identifiers.
>
> Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 9 Jul 2009 05:56:55 -0700

> discuss identifiers on this mailing list, so be it.

it is not an issue of any individual's preference.
Rather,
- this list got its own mission to accomplish;
and perhaps more importantly,
- it is unclear whether people who know more about the higher level  
requirements on identifiers are watching this list.

agree?

> must lead to the things being identified.

agree on the good understanding part.
I avoid the word "locator", as what we have in hand is simply IP  
addresses, whose basic function is to identify the attachment point of  
destinations to which IP packets are delivered, independent from which  
identifier resolved to that delivery address.

make sense?

> the core topic of this research group.

impatience?  not sure what led to that...  maybe my poor English  
expressions. but honest, I have all the patience:-)

my goal is trying to focus the attention on our own mission (I assume  
everyone still remembers that we have this March deadline for a  
routing scalability recommendation:)

>  This, in fact, reminds me of a

of course.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 9 Jul 2009 09:27:52 -0700

> internal host can be reached".

Patte,

Just FYI: your above description actually matches to an existing  
implementation pretty closely: Apple's Mobile.Me/BTMM (Back To My Mac).

I gave a short talk on this implementation back in February at the  
Dagstuhl Seminar on naming and addressing:
  "What to Use as Host Identifier: there is theory, and there is  
practice"
  http://www.dagstuhl.de/Materials/Files/09/09102/09102.ZhangLixia1.Slides1.pdf

- This is really Apple/Stuart Cheshire's work; I failed to get Stuart to
   attend the seminar, so I gave the talk.
- I wanted to make this work known to the community because it  
represents a
   *very* pragmatic way of adding the identifier into the pictur--it is
   running today (the claim is that BTMM got millions of users)

It may be far from perfect (I've been collecting a list of things that  
need to be improved), but seems to me a good/pragmatic starting point.

> How then to achieve multi-homing?

I'd like to clarify a bit here: there are multiple levels of  
multihoming, for example,
- site multihoming: UCLA is multihomed to multiple providers
- host multihoming: an iphone has multiple interfaces that even
   goes to different providers.
(of course there is also subnet multihoming, handled by IGP routing).

this naturally leads to the question of whether one would attempt one  
solution for all levels of multihoming, or have a separate solution  
for host multihoming, and handle site multihoming in a different way.

> etc. can reach your published services with the help of the host

this can be one possibility, but not the only one.
There are people out that who want PI blocks, or want to hold on their  
PI blocks.
It is because PI blocks make some part of their jobs easier.
It is not because there is something that can be theoretically proven  
impossible without PI blocks (even the need for identifier can't be  
proven this way). As I mentioned in an earlier reply, networking (both  
designs and operations) is about making a best engineering tradeoffs  
(and the criteria for "best" vary for different parties).
Isn't networking fun? :-)

Lixia

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Jul 2009 13:30:45 -0400

It's my turn to catch up :-)

Christian Vogt allegedly wrote on 06/26/2009 1:24 PM:
> within the scope of a particular Internet application, but they are not
> essential for the Internet per se to function.  In fact, I see only two
> (2) session identification, identifying the protocol state corresponding

First, let's avoid thinking of the Internet in client/server concepts.
"Service" has connotations of a destination that is frequently accessed,
well-known, and perhaps globally addressed.  We need to leave room for
simple personal communications.  Let's just talk about destinations.

I repeat the litany of five identifier functions :-) ...

  * for access, to use a visited network at all.

  * for initially finding something you want to talk to.  Examples would
    be domain names and SIP URIs.  These might correspond to your
    "service identification".

  * for initial contact, in order to establish sessions.  These include
    authentication and authorization identifiers.

  * for session control: initial authentication and association of
    locators with sessions, as well as re-authentication when locators
    change.

  * for referrals, whereby one endpoint tells another about yet a third.

Which of these are "essential for the Internet to function"?  I don't
see how we could get rid of any of access, search, authentication,
session control and referral.  However,

  * You might be able to use the same identifiers for different
    functions.  That is, you may be able to use the same identifier as
    input to multiple identification functions.

  * Also, a single identification function can take multiple
    identifiers.

  * Finally, different layers will repeat the same functions.  For
    example, you may have multiple authentication functions, or
    "session" control at multiple layers.

We haven't resolved the practical aspects of what might be the most
convenient way to reduce identifier count because we don't have enough
experience, so we're projecting and speculating.

Toni Stoev allegedly wrote on 06/26/2009 8:29 PM:
> Node identification provides for efficient handling of node
> multihoming, possibly dynamic, and for stable mapping of human
> readable names.

If I move a session from one device to another, or from one interface to
another, a node identifier is not enough to support session continuity.
 If I have a way to identify sessions that does support session
continuity, then a node identifier is not necessary in addition for that
purpose.  As others have said, one might want a node identifier for
management, but what we really want is a way to talk to a management
entity that claims to be responsible for the node.

Joel M. Halpern allegedly wrote on 07/03/2009 10:36 PM:
> The reason this (naming the set of locators that lead to the same 
> entity) leads to a stack ID (or node, host, something) is that I want
> that collective property available before I start communicating. 
> Referrals are the easy case. I am trying to refer someone to a
> specific entity. They do not have a session with that entity. So a
> session ID is clearly totally useless for a referral.

http://tools.ietf.org/html/draft-carpenter-behave-referral-object-00
(which we should get back to, Joel).

> I believe that similar constraints apply at the time of initial 
> communication establishment, in that there is a semantic difference 
> between using multiple locators for a target to establish
> communication and trying to establish communicaiton with multiple
> "equivalent but distinct" targets. I consider it helpful to
> udnerstand that distinction.

Of course there is but I don't see the point you're trying to make.  If
you address a letter to {my country, my town, my street, my house, me},
you are using multiple locators for a target, but are you trying to
establish communication with "equivalent but distinct" targets?
Identifiers do not all have to name the endpoints of communication; they
can also name the scope in which other (associated) identifiers are to
be interpreted.

I'm not going to say much more about whether we want a "stack ID" or
whether doing the same thing with a set of identifiers with multiple
purposes is better.  We can leave that to the market.

Stopping here for now.

... Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Jul 2009 13:37:18 -0400

> help of the host identifier.

There are privacy concerns with host identifiers.  If an identifier
associated with an endpoint is persistent over a long time, regardless
of where the node might be, its behavior is easier to track and analyze.
  Session identifiers of various sorts are transient.  Even security
associations are rekeyed periodically.

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Jul 2009 13:38:28 -0400

> In case not everyone has heard: a MPTCP BOF has been scheduled on Wed

It has almost certainly moved to Thursday to avoid conflict with ICCRG.

Scott

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 9 Jul 2009 13:50:16 -0400

> It has almost certainly moved to Thursday to avoid conflict with  

Thursday morning, according to the "Final" schedule
THURSDAY, July 30,
0900-1130 Morning Session I
Congresshall B INT l2vpn Layer 2 Virtual Private Networks WG
Cabaret INT savi Source Address Validation Improvements WG
Room 300 OPS capwap Control And Provisioning of Wireless Access Points  
WG
Room 307 RAI mediactrl Media Server Control WG
Congresshall C RAI mmusic Multiparty Multimedia Session Control WG
Small Stage RTG sidr Secure Inter-Domain Routing WG
Large Stage SEC keyprov Provisioning of Symmetric Keys WG
Congresshall A TSV mptcp Multipath TCP BOF

Marshall

> Scott

Regards
Marshall Eubanks
email   : [email-masked]
twitter : @TMEubanks
Cut the Cord with AmericaFree.TV

---

From: Christian Vogt <[email-masked]>
Date: Fri, 10 Jul 2009 11:12:15 -0700

Lixia -

> it is not an issue of any individual's preference. Rather,

Of course.  But keep in mind that there is a group of people in RRG who
believe that identifier-locator separation can accomplish our mission.
Devising a suitable identifier-locator separation solution, in turn,
requires some discussion of the type we were having.

> requirements on identifiers are watching this list.

This may indeed be an issue, I agree.  But the conclusion from this
should be different, in my opinion.  We should motivate more good people
to participate in this discussion, not give up the discussion.

> agree on the good understanding part. I avoid the word "locator", as
> what we have in hand is simply IP addresses, whose basic function is  
> to
> identify the attachment point of destinations to which IP packets are
> delivered, independent from which identifier resolved to that delivery
> address.

This makes sense.  Any viable solution to the routing scalability
problem will have to use IP addresses as locators, since this is a
prerequisite for incremental deployability.

- Christian

---

From: Toni Stoev <[email-masked]>
Date: Sat, 11 Jul 2009 09:16:27 +0300

Scott Brim wrote:
> another,

Scott, a session is established with a node. You can move communication among interfaces but you keep talking to the same node.

> a node identifier is not enough to support session continuity.

A node locator, a node identifier and a node-local session instance number would do the job.

> purpose.

A node locator and a node-local session instance number are sufficient to have a session.
A node identifier is needed to move the session from one node to another.

Caught up.
Toni

---

From: Christian Vogt <[email-masked]>
Date: Sat, 11 Jul 2009 16:41:19 -0700

Hi Scott -

>> In fact, I see only two purposes for which the Internet architecture
>> must have identifiers:
>>

Yes, thinking in client-server concepts would be too limiting.  And we
are not.  "Service" here is defined as a piece of communication software
that responds to incoming contact establishment attempts.  This includes
both peer-to-peer and client-server applications.  (FWIW, it also  
includes
"applications" further down the stack, such as the ICMP Echo service.)

> I repeat the litany of five identifier functions :-) ...

Many things certainly need to be identified.  But again, most identifier
types are not core elements of Internet architecture because they are
specific to certain services.  An example is host identifiers, which per
se are of use only in management applications.

Further, I would exclude authentication and authorization credentials
from the definition of identifier.  Credentials are useful to prove
ownership of an identifier, but they are not identifiers themselves.

> * for access, to use a visited network at all.

Network access identifiers are certainly needed.  But they are specific
to the access authorization service, and exchanged only within this
service.  Also, network access identifiers are likely to be specific to
certain networks.  Hence I would not consider them core elements of
Internet architecture.

In my personal view, the core elements of Internet architecture are
those which enable you to establish communications in general, such as
with said access authorization service.  And those are service
identifiers for initial contact, and session identifiers afterwards.

>   "service identification".

Agree, these are service identifiers.

>   authentication and authorization identifiers.

These are service identifiers as well, plus credentials.

>   locators with sessions, as well as re-authentication when locators

These are session identifiers.  Supplementary credentials may be needed
for security reasons.

> * for referrals, whereby one endpoint tells another about yet a third.

Referrals are important.  But you don't need an extra identifier for it.
Service identifiers serve this purpose already.

Reading your email further:

> However,

Absolutely.  The actual identifiers used may end up being more than just
two.  E.g., we may find that the use of host identifiers as a component
in service identification has advantages engineering-wise.  This is why
we are only talking about "identification purposes" at this stage, and
not yet about actual sets of identifier types.

- Christian