Subject: Re: identity persistence and comparison issues

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 1 Jul 2004 10:10:58 +0200

On 2004-06-28, at 14.45, Erik Nordmark wrote:

>> What if we just always show the application a long-lived identifier,
>> even though when it sets up a session we use ephemeral identifiers?
>
> That's part of what Jukka and I were pondering a bit.
> I think it is very interesting; just need to make sure that
> the additional local mapping on the host from the long-lived to
> the ephemeral doesn't introduce attacks that we don't know how to
> handle.

Without having thought this through very much I have a few questions on 
this,

As you would need to keep state that would be very much like a cache. 
Would you not open your self up for "cache-poisoning" very much like 
todays DNS?

- - kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Jul 2004 02:37:06 -0700 (PDT)

> Would you not open your self up for "cache-poisoning" very much like 

In principle,yes.

But the WIMP+AID idea wouldn't AFAIK have more of a problem in this space
than NOID or cb64 type approaches. All can use the return routability
implicit in establishing the state to place some trust (no worse than today's
Internet) in the initial locators, and then verify additional locators
before they are marked as "usable" in the cache.
WIMP+AID should be able to take the same approach.

  Erik

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 1 Jul 2004 12:56:17 +0200

For the records I am for adopting this.

- - kurtis -

On 2004-06-30, at 14.25, Brian E Carpenter wrote:

> Geoff, thanks.
>
> Because of the way our charter is currently written, we have two 
> separate
> questions to the WG. Here is the first one:
>
> Do people agree to adopt this draft as a WG draft (which means
> that the next update will be draft-ietf-multi6-architectures-00.txt)?
>
> That doesn't mean you have to agree that it's perfect, just that it
> is a good basis for a WG deliverable.
>
> Please answer this question without worrying whether the Appendix
> is split off, and please respond by July 9th.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
>
>
>
>
> Geoff Huston wrote:
>> draft-huston-multi6-architectures-01.txt has been published by the 
>> drafts editor. This version integrates comments made by working group 
>> members on the -00 version and also includes material proposed in the 
>> interim multi6 working group meeting earlier this month.
>> I would like to propose to the chairs that the working group consider:
>> - that this document be adopted as a working group document, and
>> - that the appendix of this document be split off from the main text 
>> of the document and separately developed as a working group document.
>> thanks.
>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 02 Jul 2004 15:26:52 +1000

Marcelo, thanks for your careful review of this draft - its appreciated of 
course.

I have no issues with any of these suggestions and will integrate them into 
the next version of the draft if there are no objections from the working 
group, although my concerns about traffic engineering remain.

I recognise that its in the RFC3582 goal set, but I still have the concern 
that "The consideration here appears to be that hosts need much more 
information at hand if they are to make locator address selection decisions 
based on some form of metric of relative load currently being imposed on 
select components of a number of end-to end network paths, and it raises 
the entire issue of Traffic Engineering being a network function 
independent of host function or an outcome of host interaction with the 
network, and if the host is to interact with the network how is this 
interaction to be signalled?"

regards,

   Geoff

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Jul 2004 13:19:26 +0200

Hi Geoff,

El 02/07/2004, a las 7:26, Geoff Huston escribió:

> [...]

> although my concerns about traffic engineering remain.
>
> I recognise that its in the RFC3582 goal set, but I still have the 
> concern that "The consideration here appears to be that hosts need 
> much more information at hand if they are to make locator address 
> selection decisions based on some form of metric of relative load 
> currently being imposed on select components of a number of end-to end 
> network paths, and it raises the entire issue of Traffic Engineering 
> being a network function independent of host function or an outcome of 
> host interaction with the network, and if the host is to interact with 
> the network how is this interaction to be signalled?"

Ok, i agree with your point here.

perhaps we have a terminology problem here....

My intention about the TE capabilities of a mh are much more modest 
than selecting paths according to the current load. I think that a 
multihoming solution should allow the site to express some sort of 
preferences about which path to use, both for incoming and outgoing 
traffic . I think that this capability is present in current IPv4 
multihoming solution, and similar capabilities should be provided by 
the IPv6 multihomig solution.

I think that this is a reasonable goal, and that we should analyze 
different alternatives (if any) to provide it. Perhaps we end up 
concluding that the TE capabilities of the IPv6 multihoming solution 
are very limited (and that they will not match current IPv4 multihoming 
TE capabilities), but i think that this should be conclusion after 
analysing the possibilities and the tradeoffs, hence my opinion that 
this should be part of the analysis.

Regards, marcelo

---

From: Geoff Huston <[email-masked]>
Date: Sat, 03 Jul 2004 07:42:23 +1000

At 09:19 PM 2/07/2004, marcelo bagnulo braun wrote:
>>concern that "The consideration here appears to be that hosts need much 
>>more information at hand if they are to make locator address selection 
>>decisions based on some form of metric of relative load currently being 
>>imposed on select components of a number of end-to end network paths, and 
>>it raises the entire issue of Traffic Engineering being a network 
>>function independent of host function or an outcome of host interaction 
>>with the network, and if the host is to interact with the network how is 
>>this interaction to be signalled?"
>
>My intention about the TE capabilities of a mh are much more modest than 
>selecting paths according to the current load. I think that a multihoming 
>solution should allow the site to express some sort of preferences about 
>which path to use, both for incoming and outgoing traffic . I think that 
>this capability is present in current IPv4 multihoming solution, and 
>similar capabilities should be provided by the IPv6 multihomig solution.
>
>concluding that the TE capabilities of the IPv6 multihoming solution are 
>very limited (and that they will not match current IPv4 multihoming TE 
>capabilities), but i think that this should be conclusion after analysing 
>the possibilities and the tradeoffs, hence my opinion that this should be 
>part of the analysis.

I've no problem with the goal as a theoretical objective. My comment is in 
looking at the information available to a host that would be used as the 
basis of a preference decision. To be of any practical use this preference 
would be based on some level of information about the current state of the 
network paths (available capacity, latency, [QoS stuff]) and at this point 
we appear to be reentering the QoS routing realm with the added issue of 
host / network interaction.

However I suppose that the question here is that given that some 
considerations about TE should be included in the document, what text is 
appropriate here that notes the goal, but references the large body of work 
that has been undertaken already on QoS and TE?

Suggestions are, obviously, solicited!

thanks,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 03 Jul 2004 08:11:43 +1000

Hi Marcelo,

At 02:54 AM 1/07/2004, marcelo bagnulo braun wrote:
>- about section 4.5
>
>I am not sure about the following comment:
>
>   "Packet header rewriting by remote network elements has a large number
>    of associated considerations, and documentation relating to the
>    considerations of the use of Network Address Translators [4] contains
>    much of this material."
>
>I mean, if the multi6 layer within the host replaces the received locator 
>by the ULP identifier, then it doesn't really matter the locator than was 
>actually carried in the packet, right? I mean, in any case, the locator is 
>transparent to the ULP which only deals with the identifier.
>
>Moreover, perhaps replacing locators by identifiers introduce some of the 
>nat problems, but in any case, i don't see how this  related to the fact 
>that the locator is replaced by the host or by the edge router. So perhaps 
>some comment like this one is required but imho is not restricted to this 
>section but to all mechanisms that replace locators by identifiers.
>Perhaps you were considering other issues here?

What I was attempting to point out is that packet header rewriting by 
_remote_ network elements is effectively a description of a session 
hijacking technique. In order to allow locator rewriting in a manner that 
is resilient to hijacking there needs to be some element of 
visible  authorization of the locator substitution. A session hijack is an 
unauthorized and undetected rewriting of packet headers, while a path 
switch is in effect a authorized rewrite of the packet headers. If this is 
performed within the host then the authority issues are somewhat different 
than when such a header rewrite is performed at some point in the network path.

If this part of the document is unclear, then perhaps you could suggest a 
clearer rewording of this?

regards,

   Geoff

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 3 Jul 2004 16:04:43 +0200

> considerations about TE should be included in the document, what text 
> is appropriate here that notes the goal, but references the large body 
> of work that has been undertaken already on QoS and TE?
>

Well, after re-reading the document, it is my impression that the 
document actually already contains several references to this point.
First, the document includes it explicitely in the base scenario

Section 2:

  In addition there is the potential consideration of being able to
  distribute traffic load across a number of network paths according to
  some pre-determined objective, as a form of traffic engineering.

which is all that imho is needed in this part of the doc.

After, in section 4.2 the document describes the key point of how path 
selection is affected in this new multiaddress configuration

Section 4.2

  The further implication here is that path selection (ISP A vs ISP B
  transit for incoming packets) is an outcome of the process of
  selecting an address for the destination host.

Moreover, in the discussion of section 5.3.1 several considerations 
about locator selection are presented.
Perhaps an option would be to include a new subsection in section 5.3 
about policy based locator selection.
In this section, it could be possible to highlight that in this new 
multiaddress configuration, policy (and TE in general) is no longer 
solely achieved through manipulation of the routing system, but a 
relevant part of the path selection is performed through address 
selection and that it is possible to achieve policing and TE by 
influencing locator selection process. In particular a reference RFC 
3484 and its policy table could be useful.

Another interesting point that could be considered in the analysis is 
that the element that performs the locator selection (host or edge 
router) determines also policy, so the choice of using packet rewriting 
or host based locator selection shifts the policy capability from one 
element to the other.
this is relevant imho, because if hosts perform policing, then a more 
fine grained policy is simpler to achieve, because hosts can select 
locators depending for instance in the application that is sending 
traffic. However, policy configuration in every host may be a 
management problem. Finally, policy enforcement may be rather 
challenging when the host based approach is used, since it is up to the 
hosts themselves. In the edge router case, policy enforcement by router 
is more similar to what we have today imho.

well, this kind of stuff is what i think could be interesting to 
include in the analysis, since may be relevant for instance when 
selecting between the host based and the edge router based locator 
selection.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 3 Jul 2004 16:20:42 +0200

El 03/07/2004, a las 0:11, Geoff Huston escribió:

>> I mean, if the multi6 layer within the host replaces the received 
>> locator by the ULP identifier, then it doesn't really matter the 
>> locator than was actually carried in the packet, right? I mean, in 
>> any case, the locator is transparent to the ULP which only deals with 
>> the identifier.
>>
>> Moreover, perhaps replacing locators by identifiers introduce some of 
>> the nat problems, but in any case, i don't see how this  related to 
>> the fact that the locator is replaced by the host or by the edge 
>> router. So perhaps some comment like this one is required but imho is 
>> not restricted to this section but to all mechanisms that replace 
>> locators by identifiers.
> hijacking technique. In order to allow locator rewriting in a manner 
> that is resilient to hijacking there needs to be some element of 
> visible  authorization of the locator substitution. A session hijack 
> is an unauthorized and undetected rewriting of packet headers, while a 
> path switch is in effect a authorized rewrite of the packet headers. 
> If this is performed within the host then the authority issues are 
> somewhat different than when such a header rewrite is performed at 
> some point in the network path.
>
> If this part of the document is unclear, then perhaps you could 
> suggest a clearer rewording of this?
>

Ok, this is not what i thought you were considering at this point.
Since you are aiming to a security issue, i would suggest that you 
include a reference to the threats document here. I mean, i would say 
that :

Packet header rewriting by remote network elements has a large number 
of associated security considerations, and any packet rewriting 
mechanism has to provide proper protection against the attacks 
described in [threats], in particular against Redirection Attacks

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Jul 2004 10:27:59 +0200

marcelo bagnulo braun wrote:
> 
> El 29/06/2004, a las 13:30, Brian E Carpenter escribió:
> 
>> Iljitsch van Beijnum wrote:
>>
>>> On 28-jun-04, at 14:45, Erik Nordmark wrote:
>>>
>>>> And if the long-lived ID is one of the locators we can provide 
>>>> compatbility
>>>> for unmodified applications which do referrals and callbacks.
>>>
>>> We should really talk to some apps people to figure out how important 
>>> this is. It's entirely trivial to shoot yourself in the foot today 
>>> with NAT or multiple addresses anyway, and then there is dual stack. 
>>> How are referrals going to work when a future participant in the 
>>> communication may be limited to one IP version, which happens to be 
>>> the other one than the one used by current participants?
>>> It may very well be that apps and protocols need to be changed anyway 
>>> in order to work with IPv6, or IPv4+IPv6.
>>
>>
>> The point is that today, the underlying assumption of most applications
>> is that the IP address they get back from an A or AAAA query, or any
>> other source including manual config, is a permanent identifier with
>> the nice property that the routing system can use it as a locator.
>>
>> NAT breaks this assumption of course. But we are trying to repair the
>> damage done by NAT. So I suggest that a multi6 goal should be that the
>> thing an application gets back from an AAAA query, or any other source
>> including manual config,
> 
> 
> including a referral?

That is my meaning, yes.

    Brian

> 
> 
>>  must be a permanent identifier with the
>> nice property that something below the socket API can transform it
>> into a locator.
>>
> 
> i agree with this
> 
> regards, marcelo
> 
>> Which leads me to wonder whether session survival for sessions using
>> temporary things such as RFC 3041 addresses is a reasonable goal for
>> multi6.
>>
>>    Brian
>>
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 4 Jul 2004 12:10:37 +0200

>>> thing an application gets back from an AAAA query, or any other 

ok.

I wonder if this goal doesn't imposes ULP identifiers to be routable IP 
addresses

I mean, when we consider backward compatibility in a communication 
between to hosts, we can assume that if the two hosts are multi6 
capable they will recognize each other and they will start using the 
new identifier name space and that when a multi6 capable host 
communicates with a non multi6 capable host, the multi6 capable one 
will find out that the other host don't support the multi6 solution and 
will fall back to  legacy IPv6 and will use IPv6 addresses as 
identifiers. so far everything is ok

however, if you add referrals support, the problem is that the multi6 
capable host doesn't know in which host the identifier will end up, as 
Erik has mentioned. So even if the identifier has been initially used 
between two multi6 capable hosts, in a future communication, one of 
them can use this new identifier in a referral to a non multi6 capable 
host, which will fail, since it will unable to use it as a valid 
locator.

So, coming back to the goal as you stated it:

    a multi6 goal should be that the thing an application
    gets back from an AAAA query, or any other source
    including manual config, must be a permanent identifier with the
    nice property that something below the socket API can transform it
    into a locator.

So as we don't know if the host that receives the referral is multi6 
capable, we don't know if there will be something below the socket api 
to make the transformation.
So i guess that in order to fulfill this goal and to be fully backward 
compatible, the ULP identifier adopted by the multi6 solution has to be 
a routable IP address.
The other option would be decide not to support this kind of scenario.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Jul 2004 01:49:47 -0700 (PDT)

> than when such a header rewrite is performed at some point in the network

This is a discussion comment - I don't think it has any impact on the
text that Marcelo suggested for the architecture draft.

You don't necessarily need to authorize the locator rewriting itself.
The constraintis that you need to verify that the use of the new
locator is propertly authenticated and authorized.
One way to perform this without authorizing the routers is to
treat the locator rewritten by the router as a hint (due to reachability
or policy) to use a different locator and have the endpoints do their
e2e handshake before they take action on the hint.

  Erik

---

From: Geoff Huston <[email-masked]>
Date: Wed, 07 Jul 2004 08:20:37 +1000

(still working through your comments...)

- in section 5.3.3

>when considering opportunistic identifiers to initiate the communication.
>note that non of the proposals AFAIK, use opportunistic identifiers for 
>the server side. imho this is very difficult, because, the client side 
>needs to know the identifier in order to initiate the communication. It 
>would be possible that the client side would select the servers identity 
>beforehand, but this may imply collisions if the server is already using 
>it. imho opportunistic ids are only suitable for clients (if any), but not 
>for servers.

Hi Marcelo,

I'm unsure of what you are saying here. Could you describe in a bit more 
detail the point so that I can understand what changes may be necessary for 
the draft?

thanks,

   Geoff

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 7 Jul 2004 11:09:18 +0200

Hi Geoff,

sorry for being unclear,

El 07/07/2004, a las 0:20, Geoff Huston escribió:

>> note that non of the proposals AFAIK, use opportunistic identifiers 
>> for the server side. imho this is very difficult, because, the client 
>> side needs to know the identifier in order to initiate the 
>> communication. It would be possible that the client side would select 
>> the servers identity beforehand, but this may imply collisions if the 
>> server is already using it. imho opportunistic ids are only suitable 
>> for clients (if any), but not for servers.
>
> Hi Marcelo,
>
> I'm unsure of what you are saying here. Could you describe in a bit 
> more detail the point so that I can understand what changes may be 
> necessary for the draft?
>

In section 5.3.3. it is stated that

    "If opportunistic identities are used, where the identity is not a
    fixed discoverable value but one that is generated in the context of
    a session then additional actions must be performed at session
    startup.  In this case there is still the need for defined locators
    that are used to establish a session, but then an additional step is
    required to generate session keys and exchange these values in order
    to support the identity equivalence of multiple locators within the
    ensuing session.  This may take the form of a capability exchange and
    an additional handshake and associated token value exchange within
    the transport protocol if an in-band approach is being used, or it
    may take the form of a distinct protocol exchange at the level of the
    identity protocol element, performed out-of-band from the transport
    session."

Now, i wonder how such a solution would be, in the case that both 
initiator and responder use ephemeral ids.

The case where the initiator uses ephemeral ids is clear to me, and 
wimp_v1 is a example of how this would work.

However, if the receiver wants to use an ephemeral id, things get less 
clear (at least to me)

In this case, the app at the initiator's end needs to use a stable 
identifier to indicate the end that it wants to communicate with.

It could be possible to say that the apps will try to communicate with 
a fqdn.
If this is the case, i guess that the resolver at the initiators end 
will have to negotiate with the receiver the ephemeral id that the 
receiver will use, so that the initiator's resolver can return the 
ephemeral id back to the app, so that the app can use it to initiate 
the communication. However, if this is the case, i would say that the 
fqdn is the identifier really being used for initial contact, perhaps 
in this scenario we are using two identifiers, the fqdn and the 
ephemeral one?

bottom line is that the receiver always needs a stable identifier that 
the initiator can refer to, if not the initiator won't be able to 
indicate the target of the communication.

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jul 2004 07:40:41 +0200

Since there were no objections by close of business on July 9th
in the author's timezone, and the I-D deadline is almost here,
draft-ietf-multi6-architecture-00.txt has been submitted.

    Brian

Brian E Carpenter wrote:
> Geoff, thanks.
> 
> Because of the way our charter is currently written, we have two separate

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jul 2004 09:39:28 +0200

There's not been much response on this, so the Appendix is still
in the main draft for the moment. We will try to reach a consensus
on this point at the San Diego meeting.

     Brian

Brian E Carpenter wrote:
> And here is the second question:
> 
> Do people think the Appendix to this draft, which is a preliminary
> analysis of various proposed approaches, should become a separate
> document? If the answer is yes, we have to discuss with our Area
> Director how this would fit into the WG charter.
> 
>    Brian
> 
> Geoff Huston wrote:
>