Subject: Re: Working Group Last Call for Hash Based Addresses (draft-ietf-shim6-hba-01.txt)
From: Francis Dupont <[email-masked]>
To: Geoff Huston <[email-masked]>
Cc: [email-masked], "marcelo bagnulo braun" <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 01 Dec 2005 00:22:20 +0100

In your previous mail you wrote:

   As there have been no objections, the document will now be forwarded to the 
   AD for publication as a  Proposed Standard
   
=> it should be fine to have an example (in the document or if it is
really too late in the list) like the Appendice A of RFC 3972.

Thanks

[email-masked]

PS: I'll provide an implementation in private as soon as I can get
an independent test (like an example...)

Delivery-date: Wed, 30 Nov 2005 18:29:20 +0000
Date: Thu, 01 Dec 2005 05:26:48 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Working Group Last Call for Hash Based Addresses (draft-ietf-shim6-hba-01.txt)
Cc: "marcelo bagnulo braun" <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>

At 07:20 AM 15/11/2005, Geoff Huston wrote:
>Hi,
>
>         This note starts the WG Last Call for comments on
>         draft-ietf-shim6-hba-01.txt "Hash Based Addresses".
>         It can be found at:
>         ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>
>         This document is intended to be published as an Internet
>         Standard, so the document will be passed to the IESG as
>         an intended Proposed Standard.
>
>         Please review the document carefully, and send your
>         feedback to the list.  Please also indicate whether or
>         not you believe that this document is ready to go to the
>         IESG.
>
>         This Last Call will end on 28 November 2005 at 0900 AEDT
>         (UTC + 11), two weeks form the time of this call.
>
>         Thanks,
>
>         Kurtis and Geoff

This working group last call period is now over.

As there have been no objections, the document will now be forwarded to the 
AD for publication as a  Proposed Standard

regards,

      Kurtis & Geoff

Delivery-date: Tue, 22 Nov 2005 18:14:41 +0000
Date: Tue, 22 Nov 2005 10:14:12 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: context confusion

marcelo bagnulo braun wrote:
>=20
> El 21/11/2005, a las 23:06, Erik Nordmark escribi=F3:
>=20
>> I don't think we need to tare down the old on reception of an I1. An I=
2
>=20
>=20
> ok with I2
>=20
>> or R1
>=20
>=20
> however, as currently defined, we cannot do it in R1 because it does no=
t=20
> contain the CT(peer) in it nor the locator set
> so either we include these info in R1 or we do it in R2,
>  i would go for doing it in R2, ok?

ok

   Erik

Delivery-date: Tue, 22 Nov 2005 09:43:44 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: context confusion
Date: Tue, 22 Nov 2005 10:42:59 +0100
To: Erik Nordmark <[email-masked]>

El 21/11/2005, a las 23:06, Erik Nordmark escribi=F3:
> I don't think we need to tare down the old on reception of an I1. An =
I2

ok with I2

> or R1

however, as currently defined, we cannot do it in R1 because it does=20
not contain the CT(peer) in it nor the locator set
so either we include these info in R1 or we do it in R2,
  i would go for doing it in R2, ok?

>  (don't have to wait for R2) would be better.
> Thus we'd do the implicit return routability check in addition to the=20=

> context tag having to match; the combination of those makes it very=20
> hard for off-path attackers to cause the taredown.
>

agree
regards, marcelo

>    Erik
>

Delivery-date: Mon, 21 Nov 2005 22:06:11 +0000
Date: Mon, 21 Nov 2005 14:06:00 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: context confusion

marcelo bagnulo braun wrote:

> The question is: what does A does when it detect this context confusion?
> 
> There seems to be reasonable to continue with the new context 
> establishment, using CT(B) for this new context, but what does A does 
> with the old context?
> There are two proposed approaches:
> - Discard the old context
> - try to reestablish the old context with a different context tag for B

I think the requirement on an implementation is that it must not send 
any shim6 packets using the old context.
I think there is an implementation choice whether it does this by just 
discarding the old context, or whether it discards it and immediately 
recreates it. (The recreated context would have different context tags, 
so there wouldn't be any confusion.)
One could even envision implementations that would use local information 
(such as whether there are open sockets) to choose whether it makes 
sense to recreate the old context or not.

> Now, the problem with discarding the old context is that this may open 
> the door to some form of attacks, when an attacker that discovers a 
> context tag and a valid locator of a given peer, can easily, by just 
> sending a I1 message make the victim to discard the state. In other 
> words, if we have the scenario above with A and B having an estasblished 
> context, an attacker can simply send an I1 message to A that includes 
> the CT(B) and an ULID option with B's address and this would cause A to 
> discard the context with B. Of course, it would require that the 
> attacker knows CT(B) and B's address, would this threat be acceptable? 
> An additional option would be to delay context teardown of the old 
> context until a I2 or an R2 packet is received, making sure that we can 
> track down an attacker....

I don't think we need to tare down the old on reception of an I1. An I2 
or R1 (don't have to wait for R2) would be better.
Thus we'd do the implicit return routability check in addition to the 
context tag having to match; the combination of those makes it very hard 
for off-path attackers to cause the taredown.

    Erik

Delivery-date: Mon, 21 Nov 2005 22:01:01 +0000
Date: Mon, 21 Nov 2005 14:00:01 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: forking

marcelo bagnulo braun wrote:

> The other option is that App2 also want that forking affects the reply 
> packets.

I don't think such a model makes any sense, because it creates a tension 
between:
  - A telling B which locator pair to use for return traffic, but the 
ULP on B might have a different idea on what locator pair to use for 
traffic sent to A. Would the shim layer have to resolve who should win?
  - A telling B which locator pair to use for return traffic, but the 
shim on B determines that this locator pair doesn't work (no 
reachability) in the B->A direction.
It also adds unneeded complexity in the shim AFAIK, because the shim 
would need to be able to handle packet filter expressions (sent from A?) 
so that it can determine which packets sent from B qualify as "return 
traffic".

> After some mail exchanges with Erik, a possible approach for this would 
> be the following:
> - App2a decides to do forking and through the shim API would detect the 
> shim and learn the locator sets (local and peer)
> - App2a decides to establishes a forked shim context i.e. a secondary 
> context within the initial context, which can use the selected locator 
> pair. For doing this, App2a need to signal the shim that new context 
> needs to be created using the shim API. Upon the reception of this 
> signal, the shim at host A would initiate a context establishment 
> exchange (I1,R1,I2,R2) for this new secondary context, that would 
> require the inclusion of some form of context instance identifier.

I'm a bit confused.

I think there is a need for a forked instance identifier due to the 
interaction of the context recovery and forking. I don't see this 
introducing a different model for forking though.

The issue is that with context recovery we have the case where B has 
lost the context for A1<->B1, and B tries to create a context A1<->B1.
Thus B sends an I1 packet to A.
A can easily see that this packet matches the existing context. Thus it 
can immediately reply with an R2 packet, which makes B re-establish the 
context. So far so good. An I1 packet where the ULID pair matches an 
existing context gets an R2 packet in response.

Enter forking. A and B have a context for A1<->B1. The ULP on B wants to 
fork to create a new context A1<->B1. So it sends an I1.
The problem is that A will follow the above context recovery rule, and 
will respond with a R2 for the existing context and no new, forked 
context will be created.

We can easily solve this if we include a context instance number in the 
I1, R1, I2, R2 packets, and make the check for "should I recover this 
context" match on the context instance number in addition to the ULID 
pair. Unless the ULPs do forking the context instance number would be zero.

    Erik

Delivery-date: Mon, 21 Nov 2005 12:08:49 +0000
Cc: Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: context confusion
Date: Mon, 21 Nov 2005 13:07:18 +0100
To: shim6-wg <[email-masked]>

Hi,

another issue that is still open is what the draft calls context 
confusion

The situation here is that we have hosts A and B that setup a shim 
context between them
the context has ULID(A) and ULID(B). For that context each  peer has 
assigned a context tag, CT(A) and CT(B)

suppose now that host B discards the state but A keeps it.

suppose that later on, a new context is established between A and B and 
that B reuses CT(B) for this new context.
In the case that the ULID or the locators used by B in this new context 
contain at least one of the addresses used by B in the previous 
context, A is able to detect the situation that we call context 
confusion. Such detection can occur whether when A receives a I1, an I2 
or an R2 message for this new context.

The question is: what does A does when it detect this context confusion?

There seems to be reasonable to continue with the new context 
establishment, using CT(B) for this new context, but what does A does 
with the old context?
There are two proposed approaches:
- Discard the old context
- try to reestablish the old context with a different context tag for B

Now, the problem with discarding the old context is that this may open 
the door to some form of attacks, when an attacker that discovers a 
context tag and a valid locator of a given peer, can easily, by just 
sending a I1 message make the victim to discard the state. In other 
words, if we have the scenario above with A and B having an 
estasblished context, an attacker can simply send an I1 message to A 
that includes the CT(B) and an ULID option with B's address and this 
would cause A to discard the context with B. Of course, it would 
require that the attacker knows CT(B) and B's address, would this 
threat be acceptable? An additional option would be to delay context 
teardown of the old context until a I2 or an R2 packet is received, 
making sure that we can track down an attacker....

The other option is that upon the reception of a shim control packet 
that causes context confusion detection, A tries to reestablish the 
context, that is, it sends a new I1 packet for the old context and see 
what happens. If the peer still has the old context (i.e. we are under 
attack) then the peer will respond with a R2 message and the attack is 
detected and no problem. If the peer actually has lost the context, it 
will reply with an R1 message and the situation is that the peer has 
discarded the context, and A can choose to restore it or not. In any 
case, there is still an open question is when does A sends the I1 
message: upon the reception of I1 or upon the reception of I2? I guess 
that we don't want to do anything when we receive a I1, and we better 
do it when we receive an I2 or an R2, when we have more confidence on 
what is going on...

So, what option do you prefer?

Regards, marcelo

Delivery-date: Sun, 20 Nov 2005 20:29:19 +0000
Cc: Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: forking
Date: Sun, 20 Nov 2005 12:47:57 +0100
To: shim6-wg <[email-masked]>

Hi,

I would like to understand a bit more in depth what is the expected 
behaviour of forking.

Suppose we have hosts A and B that establish a shim context.

Now suppose that we have a couple of apps running in A App1a and App2a, 
communicating with App1b and App2b respectively
suppose that App1 is the one that has established the initial 
communication for which the shim context was established
App2 was established later, but App2 wants to do forking. In order to 
do that App2 must detect that the shim is in use and then discover the 
available locator sets (local and peer) and then select the locator 
pair to use.
Now, detecting that the shim is in use and discovering the locator sets 
imply changes in the API (not in the protocol)
App2 can select the locator pair to use when sending packets through a 
new shim API and again for this we don't need changes in the shim 
protocol
In this case, the behaviour would be:
- App2a wants to do forking, so through the shim API detects the 
presence of the shim context and learns the locator sets (local and 
peer)
- App2a through the shim API selects the locator pair to use for the 
packets that App2a sends
- when packets reach App2b (App2 running in host B) they are delivered 
to the app and it wold be possible that the shim through the shim API 
informs App2b about the locator pair included in the packet. At this 
point, App2b can also do forking and select through the shim API the 
locator pair to be used for sending App2 packets from B to A.

The nice part of this is that we don't need to add complexity to the 
shim protocol. I would argue that it is reasonable that the app needs 
to be involved in forking since it is itself the one that is selecting 
the locator pair to be used

The other option is that App2 also want that forking affects the reply 
packets.
After some mail exchanges with Erik, a possible approach for this would 
be the following:
- App2a decides to do forking and through the shim API would detect the 
shim and learn the locator sets (local and peer)
- App2a decides to establishes a forked shim context i.e. a secondary 
context within the initial context, which can use the selected locator 
pair. For doing this, App2a need to signal the shim that new context 
needs to be created using the shim API. Upon the reception of this 
signal, the shim at host A would initiate a context establishment 
exchange (I1,R1,I2,R2) for this new secondary context, that would 
require the inclusion of some form of context instance identifier.
- After the new secondary context is established, App2a would start 
sending packets to App2b through this new secondary context. App2b 
would need to be informed, through the shim API that a secondary 
context is being used to exchange packets and App2b could use it to 
send reply packets

These are basically the two ways identified so far to do forking, do 
you have any other idea of how forking would be? do you have any 
preference for any of these two approaches?

The main difference afaict, is that the first approach does not 
requires protocol support while the second one does. Both of them 
require App involvement and API support

Regards, marcelo

Delivery-date: Mon, 14 Nov 2005 23:51:07 +0000
Date: Tue, 15 Nov 2005 10:49:51 +1100
To: marcelo bagnulo braun <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Material from the Friday SHIM6 WG Meeting
Cc: Kurt Erik Lindqvist <[email-masked]>, [email-masked]

I'll make this correction to the minutes - thanks!

    Geoff

At 10:02 PM 14/11/2005, marcelo bagnulo braun wrote:
>thanks for the minutes,
>Just a comment. the minutes state that:
>
>3. HBA update
>
>       [Marcelo Bagnulo, presented by Geoff Huston]
>
>           o The -01 version of the document references the 3484
>proposals and CGA extensions as normative, so they will be lock-stepped
>in the publication process.
>
>The hba document does not includes the update to RFC3484 as a normative
>reference.
>The hba document does includes two drafts as normative references:
>   [6]  Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses
>         (CGA) Extension Field Format", draft-bagnulo-shim6-cga-ext-02
>         (work in progress), October 2005.
>
>    [7]  Nordmark, E., "Level 3 multihoming shim protocol",
>         draft-ietf-shim6-proto-01 (work in progress), October 2005.
>
>The first one is needed in order to have a consistent format in the cga
>extensions
>The second one, i included mostly to be sure that everything runs
>smoothly between the shim protocol and the hba mechanisms, so that they
>move together
>
>regards, marcelo
>
>
>El 13/11/2005, a las 19:00, Geoff Huston escribi=F3:
>
>>With these fancy new tools at the IETF we can now post interim
>>material to the IETF and revise it in place.  So rather than circulate
>>the minutes, collect comments and then submit a final version to the
>>IETF Secretariat, this way we can post the initial draft of the
>>minutes and make revisions in situ if needed.
>>
>>The material for IETF64 is at
>>https://datatracker.ietf.org/public/meeting_materials.cgi? meeting_num=3D6=
4
>>
>>You'll find the reference SHIM6 in the Internet area of that web page
>>of course, and the minutes at
>>http://www3.ietf.org/proceedings/05nov/minutes/shim6.html
>>
>>If you have any comments on the minutes, please send them to this
>>mailing list please.
>>
>>thanks,
>>
>>     Geoff & Kurtis
>>
>>
>>
>>
>
>

Delivery-date: Mon, 14 Nov 2005 20:41:24 +0000
Date: Tue, 15 Nov 2005 07:40:15 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Working Group Last Call for Hash Based Addresses (draft-ietf-shim6-hba-01.txt)
Cc: "marcelo bagnulo braun" <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>

There was a ghost attachment to that Last Call message - please ignore the 
attachment - its from another working group in another time! :-)

  Geoff

At 07:20 AM 15/11/2005, Geoff Huston wrote:
>Hi,
>
>         This note starts the WG Last Call for comments on
>         draft-ietf-shim6-hba-01.txt "Hash Based Addresses".
>         It can be found at:
>         ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>
>         This document is intended to be published as an Internet
>         Standard, so the document will be passed to the IESG as
>         an intended Proposed Standard.
>
>         Please review the document carefully, and send your
>         feedback to the list.  Please also indicate whether or
>         not you believe that this document is ready to go to the
>         IESG.
>
>         This Last Call will end on 28 November 2005 at 0900 AEDT
>         (UTC + 11), two weeks form the time of this call.
>
>         Thanks,
>
>         Kurtis and Geoff
>
>
>
>
>
>
>
>
>
><file://C:\Documents%20and%20Settings\gih\Application%20Data\Qualcomm\Eudora\attachments\WGLC%20for%20BGP%20Wedgies%20(draft-iet>
>C:\Documents and Settings\gih\Application Data\Qualcomm\Eudora\
><file://C:\Documents%20and%20Settings\gih\Application%20Data\Qualcomm\Eudora\attachments\WGLC%20for%20BGP%20Wedgies%20(draft-iet> 
>WGLC for BGP Wedgies (draft-iet
>
>
>

Delivery-date: Mon, 14 Nov 2005 20:22:33 +0000
Date: Tue, 15 Nov 2005 07:20:36 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Working Group Last Call for Hash Based Addresses (draft-ietf-shim6-hba-01.txt)
Cc: "marcelo bagnulo braun" <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>

--=====================_49054437==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

         This note starts the WG Last Call for comments on
         draft-ietf-shim6-hba-01.txt "Hash Based Addresses".
         It can be found at:
         ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

         This document is intended to be published as an Internet
         Standard, so the document will be passed to the IESG as
         an intended Proposed Standard.

         Please review the document carefully, and send your
         feedback to the list.  Please also indicate whether or
         not you believe that this document is ready to go to the
         IESG.

         This Last Call will end on 28 November 2005 at 0900 AEDT
         (UTC + 11), two weeks form the time of this call.

         Thanks,

         Kurtis and Geoff

<file://C:\Documents%20and%20Settings\gih\Application%20Data\Qualcomm\Eudora\attachments\WGLC%20for%20BGP%20Wedgies%20(draft-iet>
C:\Documents and Settings\gih\Application Data\Qualcomm\Eudora\
<file://C:\Documents%20and%20Settings\gih\Application%20Data\Qualcomm\Eudora\attachments\WGLC%20for%20BGP%20Wedgies%20(draft-iet> 
WGLC for BGP Wedgies (draft-iet

--=====================_49054437==_
Content-Type: image/jpeg; name="2e675c3.jpg";
 x-mac-type="4A504547"; x-mac-creator="4A565752"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="2e675c3.jpg"

--=====================_49054437==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_49054437==_--

Delivery-date: Mon, 14 Nov 2005 11:02:47 +0000
Cc: Kurt Erik Lindqvist <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Material from the Friday SHIM6 WG Meeting
Date: Mon, 14 Nov 2005 12:02:55 +0100
To: Geoff Huston <[email-masked]>

thanks for the minutes,
Just a comment. the minutes state that:

3. HBA update

       [Marcelo Bagnulo, presented by Geoff Huston]

           o The -01 version of the document references the 3484 =20
proposals and CGA extensions as normative, so they will be lock-stepped =20=

in the publication process.

The hba document does not includes the update to RFC3484 as a normative =20=

reference.
The hba document does includes two drafts as normative references:
   [6]  Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses
         (CGA) Extension Field Format", draft-bagnulo-shim6-cga-ext-02
         (work in progress), October 2005.

    [7]  Nordmark, E., "Level 3 multihoming shim protocol",
         draft-ietf-shim6-proto-01 (work in progress), October 2005.

The first one is needed in order to have a consistent format in the cga =20=

extensions
The second one, i included mostly to be sure that everything runs =20
smoothly between the shim protocol and the hba mechanisms, so that they =20=

move together

regards, marcelo

El 13/11/2005, a las 19:00, Geoff Huston escribi=F3:

> With these fancy new tools at the IETF we can now post interim =20
> material to the IETF and revise it in place.  So rather than circulate =
=20
> the minutes, collect comments and then submit a final version to the =20=

> IETF Secretariat, this way we can post the initial draft of the =20
> minutes and make revisions in situ if needed.
>
> The material for IETF64 is at =20
> https://datatracker.ietf.org/public/meeting_materials.cgi?=20
> meeting_num=3D64
>
> You'll find the reference SHIM6 in the Internet area of that web page =20=

> of course, and the minutes at =20
> http://www3.ietf.org/proceedings/05nov/minutes/shim6.html
>
> If you have any comments on the minutes, please send them to this =20
> mailing list please.
>
> thanks,
>
>     Geoff & Kurtis
>
>
>
>
>

Delivery-date: Sun, 13 Nov 2005 18:02:29 +0000
Date: Mon, 14 Nov 2005 05:00:23 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Material from the Friday SHIM6 WG Meeting
Cc: Kurt Erik Lindqvist <[email-masked]>

With these fancy new tools at the IETF we can now post interim material to 
the IETF and revise it in place.  So rather than circulate the minutes, 
collect comments and then submit a final version to the IETF Secretariat, 
this way we can post the initial draft of the minutes and make revisions in 
situ if needed.

The material for IETF64 is at 
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64

You'll find the reference SHIM6 in the Internet area of that web page of 
course, and the minutes at 
http://www3.ietf.org/proceedings/05nov/minutes/shim6.html

If you have any comments on the minutes, please send them to this mailing 
list please.

thanks,

     Geoff & Kurtis

Delivery-date: Sun, 13 Nov 2005 14:50:54 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about R1bis
Date: Sun, 13 Nov 2005 11:40:07 +0100
To: Pierre Baume <[email-masked]>

Hi Pierre,

El 11/11/2005, a las 23:19, Pierre Baume escribi=F3:

> Marcelo,
>
> On 11/11/05, marcelo bagnulo braun <[email-masked]> wrote:
>>
>> El 11/11/2005, a las 17:16, Pierre Baume escribi=F3:
> [...]
>
>>>   Maybe it would help to have a message for servers to indicate that
>>> they wish to go quiet and drop the context. This could also =
interrupt
>>> probing.
>>>
>>
>> But in this case, the client wouldn't be able to use the probing for
>> detecting failures, right?
>> I guess that the optimal would be that the server reply to probes, =
but
>> that it does not verify that they belong to a given context. IMHO =
this
>> present no security issues, as long as these are probes to verify =
that
>> the current path is still working. It is completelly different story=20=

>> if
>> these are reachability tests perfromed before a rehoming
>>
>> regards, marcelo
>
>   Well, I'm not sure that I understand the scenarios.
>

i am not sure i understand the cases you are pointing out below... :-(
anyway, here is my interpretation

>   If a server drops the context when it has nothing to send to a
> client for a while, how can it resume communication, if needed?
>

i guess that the idea is that the server basically replies to queries=20
performed by the client, so it is never the case where the server wants=20=

to initiate a communication without a prior contact by the client

>   If the above isn't a problem, what is the benefit for a client to
> try and detect failures before it has something (else than a probe) to
> send to a server?
>

i see it as follows:

Client C and server S
C establishes a communication with S
A shim context is created between C and S
S drops the context (so it reduces the amount of memory consumed by the=20=

shim) (i.e. because of the many clients)
So far, there is no failures, so there is no translation being made,=20
so, the server does not need the state to process packets.
However, because S does not have any more shim state, it will not=20
perform any failure detection for this communication. Failure detection=20=

is completely in the hands of C. In particular S won't send periodic=20
probes to C to notify that the address pair is working ok
Since S won't be sending periodic probes, C will need to verify that=20
the address pair is working each time S is silent for while. This is=20
performed through a reachability test of the current address pair.
The problem is that as currently defined, a reachability test refers to=20=

a particular context, so this would trigger an R1bis, which would=20
result in reestablishing the context that S has dropped on purpose. The=20=

point is that at this point there is no need to reestablish the=20
context, since there is no failure yet. So the resulting behaviour is=20
that we would be creating and tearing down contexts periodically, which=20=

doesn't seem to be the desired result.

I can see two solutions for this problem:
- One would be that reachability test for current locator pair does not=20=

carry any context specific information. This afaict does not presents=20
any security issues
- the other is that the client should not try to reestablish the=20
context upon the reception of an R1bis as a reply to the reachability=20
test of the current locator pair. In this case, if the client knows=20
that the server drops context on purpose, the client only need to find=20=

out if the current locator pair is working. Receiving a R1bis packet=20
confirms that the current locator pair is working, so no need to=20
reestablish the context at this point. I wonder if this is one option=20
that needs to be negotiated or if this should be the default behaviour=20=

or we should leave this open to local policy?

>   Thanks for your patience. :-)
>

No, thank you for making interesting questions

Regards, marcelo

> Pierre.
>

Delivery-date: Fri, 11 Nov 2005 22:20:02 +0000
Date: Fri, 11 Nov 2005 23:19:53 +0100
From: Pierre Baume <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: about R1bis
Cc: shim6-wg <[email-masked]>

Marcelo,

On 11/11/05, marcelo bagnulo braun <[email-masked]> wrote:
>
> El 11/11/2005, a las 17:16, Pierre Baume escribi=F3:
[...]

> >   Maybe it would help to have a message for servers to indicate that
> > they wish to go quiet and drop the context. This could also interrupt
> > probing.
> >
>
> But in this case, the client wouldn't be able to use the probing for
> detecting failures, right?
> I guess that the optimal would be that the server reply to probes, but
> that it does not verify that they belong to a given context. IMHO this
> present no security issues, as long as these are probes to verify that
> the current path is still working. It is completelly different story if
> these are reachability tests perfromed before a rehoming
>
> regards, marcelo

  Well, I'm not sure that I understand the scenarios.

  If a server drops the context when it has nothing to send to a
client for a while, how can it resume communication, if needed?

  If the above isn't a problem, what is the benefit for a client to
try and detect failures before it has something (else than a probe) to
send to a server?

  Thanks for your patience. :-)

Pierre.

Delivery-date: Fri, 11 Nov 2005 22:09:53 +0000
Date: Fri, 11 Nov 2005 23:09:16 +0100
From: Pierre Baume <[email-masked]>
To: Jari Arkko <[email-masked]>
Subject: Re: slides for the failure detection discussion
Cc: shim6 <[email-masked]>

Hi Jari,

  Thanks for the slides.

  Am I the only one thinking that we're trying to reinvent ACKs? :-)

Pierre.

On 11/11/05, Jari Arkko <[email-masked]> wrote:
>
> http://www.arkko.com/publications/shim6/ietf64_shim_faildet.ppt

Delivery-date: Fri, 11 Nov 2005 18:29:33 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about R1bis
Date: Fri, 11 Nov 2005 19:28:01 +0100
To: Pierre Baume <[email-masked]>

El 11/11/2005, a las 17:16, Pierre Baume escribi=F3:

> Hi Marcelo,
>
> On 11/10/05, marcelo bagnulo braun <[email-masked]> wrote:
> [...]
>
>> 2 - Do we want that the failure detection probes trigger a context
>> recovery mechanisms i.e. R1bis?
>>
>> In the considered scenario, when the initial path between the ulids =
is
>> working fine, the transmission of probes to verify that the current
>> path is working may result in triggering the context recovery
>> mechanisms i.e. the transmission of a R1bis packet. Such behaviour =
may
>> not be the optimum for dealing with the case of the server that wants
>> to discard the clients contexts, in order to let the clients to =
handle
>> fault tolernace (the scenario suggested by Iljitsch in the ams
>> meeting). A possibility for dealing with this would be that probes=20
>> that
>> verify that the current path is working do not contain context=20
>> specific
>> information (as oposed to probes used for exploring the alternative
>> paths, that in order to be used for flooding prevention must carry
>> context specific information). I know that this would imply a change=20=

>> in
>> the failure detection protocol in Jari's draft, but maybe it would be
>> worth to consider this issue.
>>
>> Regards, marcelo
>>
>> PS: agree that interaction with context confusion mechanisms needs to
>> be be clearly understood in order to get the full picture about this
>> R1bis thing
> [...]
>
>   Maybe it would help to have a message for servers to indicate that
> they wish to go quiet and drop the context. This could also interrupt
> probing.
>

But in this case, the client wouldn't be able to use the probing for=20
detecting failures, right?
I guess that the optimal would be that the server reply to probes, but=20=

that it does not verify that they belong to a given context. IMHO this=20=

present no security issues, as long as these are probes to verify that=20=

the current path is still working. It is completelly different story if=20=

these are reachability tests perfromed before a rehoming

regards, marcelo

> Pierre.
>

Delivery-date: Fri, 11 Nov 2005 17:51:28 +0000
Date: Fri, 11 Nov 2005 18:48:05 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: slides for the failure detection discussion

http://www.arkko.com/publications/shim6/ietf64_shim_faildet.ppt

Delivery-date: Fri, 11 Nov 2005 16:58:28 +0000
Date: Fri, 11 Nov 2005 17:55:50 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: slides

The chairs can upload them in realtime to the proceedings page

    Brian

Iljitsch van Beijnum wrote:
> Hi,
> 
> If people who are about to present have their slides available  online, 
> that would significantly help those of us who are listening  in from afar.
> 
> If I receive URLs in private mail and I'll summerize to the list.
> 
> Iljitsch
> 

Delivery-date: Fri, 11 Nov 2005 16:50:54 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: slides
Date: Fri, 11 Nov 2005 17:48:15 +0100

Hi,

If people who are about to present have their slides available  
online, that would significantly help those of us who are listening  
in from afar.

If I receive URLs in private mail and I'll summerize to the list.

Iljitsch

Delivery-date: Fri, 11 Nov 2005 16:27:06 +0000
Date: Fri, 11 Nov 2005 17:16:03 +0100
From: Pierre Baume <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: about R1bis
Cc: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>

Hi Marcelo,

On 11/10/05, marcelo bagnulo braun <[email-masked]> wrote:
[...]

> 2 - Do we want that the failure detection probes trigger a context
> recovery mechanisms i.e. R1bis?
>
> In the considered scenario, when the initial path between the ulids is
> working fine, the transmission of probes to verify that the current
> path is working may result in triggering the context recovery
> mechanisms i.e. the transmission of a R1bis packet. Such behaviour may
> not be the optimum for dealing with the case of the server that wants
> to discard the clients contexts, in order to let the clients to handle
> fault tolernace (the scenario suggested by Iljitsch in the ams
> meeting). A possibility for dealing with this would be that probes that
> verify that the current path is working do not contain context specific
> information (as oposed to probes used for exploring the alternative
> paths, that in order to be used for flooding prevention must carry
> context specific information). I know that this would imply a change in
> the failure detection protocol in Jari's draft, but maybe it would be
> worth to consider this issue.
>
> Regards, marcelo
>
> PS: agree that interaction with context confusion mechanisms needs to
> be be clearly understood in order to get the full picture about this
> R1bis thing
[...]

  Maybe it would help to have a message for servers to indicate that
they wish to go quiet and drop the context. This could also interrupt
probing.

Pierre.

Delivery-date: Fri, 11 Nov 2005 01:31:10 +0000
Date: Thu, 10 Nov 2005 17:28:03 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about R1bis

marcelo bagnulo braun wrote:
> Two more issues related to R1bis that came to my mind:
> 
> 1 - Is it important to defend a peer from a fake R1bis?
> I mean, R1bis may enable some attacks similar to sending a fake TCP RST 
> packet.
> If a peer receives a R1bis packet refering to an established context, it 
> will try to restablish the context, sending an I2 packet. If we assume 
> that the R1bis packet is fake and that the validator is not correct, the 
> receiver will siliently discard the I2 packet. At this point the 
> receiver will try to resend the I2 packet or try to send an I1 packet 
> again. I2 will continue to be discarded, but I1 packet will get a R2 
> reply, which imho will be good enough in this case. I guess that this 
> covers this case pretty good, so i don't think that anything else is 
> needed.

ok

And faking an R1bis requires knowing the context tag.

> 2 - Do we want that the failure detection probes trigger a context 
> recovery mechanisms i.e. R1bis?

Yes.

> In the considered scenario, when the initial path between the ulids is 
> working fine, the transmission of probes to verify that the current path 
> is working may result in triggering the context recovery mechanisms i.e. 
> the transmission of a R1bis packet. Such behaviour may not be the 
> optimum for dealing with the case of the server that wants to discard 

But I don't think we need to have optimality; question is whether it 
works or not.

   Erik

> the clients contexts, in order to let the clients to handle fault 
> tolernace (the scenario suggested by Iljitsch in the ams meeting). A 
> possibility for dealing with this would be that probes that verify that 
> the current path is working do not contain context specific information 
> (as oposed to probes used for exploring the alternative paths, that in 
> order to be used for flooding prevention must carry context specific 
> information). I know that this would imply a change in the failure 
> detection protocol in Jari's draft, but maybe it would be worth to 
> consider this issue.
> 
> Regards, marcelo
> 
> PS: agree that interaction with context confusion mechanisms needs to be 
> be clearly understood in order to get the full picture about this R1bis 
> thing

Delivery-date: Thu, 10 Nov 2005 22:56:49 +0000
Date: Thu, 10 Nov 2005 14:55:54 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-02.txt

marcelo bagnulo braun wrote:

Thanks for the comments. I've applied all of them unless explicitly 
indicated below.

> 4.3  Overview of Shim Control Messages
> 
>    There is a No Context error message defined, when a control or
>    payload packet arrives and there is no matching context state at the
>    receiver.  When such a message is received, it will result in the
>    destruction of the shim context and a re-establishment.
> 
> 
> I guess that this is under discussion, but just as a remainder...
> I guess that the current idea would be not to discard but to try to 
> recover the lost context, right?
> ( i mean reestablishment without previous discard)

Yep; Context Error will go away and be replaced with R1bis.

> 6.1  Conceptual Data Structures
> 
> I don't know if timers involved should be included in here, but in case 
> they should, i guess that at least the time used to tear down the 
> context should be described here.
> An option for this would be the time elapsed since the last data or 
> control packet associated to the context was exchanged.
> The timers involved in context establishment may also need to be 
> included here.

I've added some vague words on this.

> In addition, i guess that the multiple timers involved in path 
> exploration and failure detection would be needed, but probably those 
> are better to be described in the failure detection protocol document.

Yes.

> 7.2  Concurrent context establishment
> 
>    If a host has received an I1 and sent an R1, then a ULP can trigger
>    it to send an I1 message itself, since it doesn't retain any state
>    when receiving the I1 message.  Thus while one end is sending an I1
>    the other is sending an I2.
> 
> I am not sure in this case why it is useful that the initiator replies 
> to the I1 sent by the responder with an R2... as i see it, the previous 
> I2 message should get to the responder, making him to issue a R2 back. 

Perhaps I'm misunderstanding, and "initiator" isn't well-defined when 
both ends are initiating at about the same time.

But AFAICT, if a host receives an I1 that matches an existing context, 
it needs to respond with an R2. This is needed e.g., when the first R2 
is dropped and the peer goes back to retransmitting the I1.

> The R2 sent by the initiator will have no effect in the responder as i 
> understand it... wouldn't make sense to remove this R2 then? Perhaps it 
> would be better to reply with an I2 instead of an R2?
> I mean, that the initiator replies to the I1 of the responder by 
> repeating the I2 instead of sending a new R2... this would keep the 
> roles simpler imho, since the initiator would always send I messages and 
> the responder R messages...

Does the above make things more clear? I've added similar text to the draft.

> 7.4  Context confusion
> 
> I think that the context confusion scenarios may be even more complex 
> than the cases described.

Yes, if the locator sets are not known as part of the context 
establishment, then things are harder.

But if sufficient things are exchanged during context establishment, 
then the host can tell whether the peer is the same at the latest when
receiving R2/I2.
The locators aren't needed AFAICT, the CGA PDS should be sufficient.

Does that work?

> 7.5  Sending I1 messages
> 
>    If, after several retransmissions, there is no response, then most
>    likely the peer does not implement the shim6 protocol, or there could
>    be a firewall that blocks the protocol.
> 
> Or that a failure has just affected the path between the ulids... right?
> would it make sense to try to recover here? i.e. using alternative 
> locator pairs for exchanging the initial exchange packets and carrying 
> different ULID pair as an option?

The shim would only know the ULID pair during the context establishment, 
so I don't think it can currently try anything different.
It is true that if/when we have the the "super-API" that allows 
applications to specify the two IPv6 address sets and ask the shim to 
setup a context, then things would be different.
But I think we can defer this until that point in time.

> Editorial
> 
> Abstract
> 
>    The hosts in a site which has multiple
>    provider allocated IPv6 address prefixes, will use the shim6 protocol
>    specified in this document to setup state with peer hosts, so that
>    the state can later be used to failover to a different locator pair,
>    should the original one stop working.
> 
> s/stop/stops

"should stop" isn't correct?

    Erik

Delivery-date: Thu, 10 Nov 2005 11:28:36 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about R1bis
Date: Thu, 10 Nov 2005 12:28:26 +0100
To: Erik Nordmark <[email-masked]>

Two more issues related to R1bis that came to my mind:

1 - Is it important to defend a peer from a fake R1bis?
I mean, R1bis may enable some attacks similar to sending a fake TCP RST=20=

packet.
If a peer receives a R1bis packet refering to an established context,=20
it will try to restablish the context, sending an I2 packet. If we=20
assume that the R1bis packet is fake and that the validator is not=20
correct, the receiver will siliently discard the I2 packet. At this=20
point the receiver will try to resend the I2 packet or try to send an=20
I1 packet again. I2 will continue to be discarded, but I1 packet will=20
get a R2 reply, which imho will be good enough in this case. I guess=20
that this covers this case pretty good, so i don't think that anything=20=

else is needed.

2 - Do we want that the failure detection probes trigger a context=20
recovery mechanisms i.e. R1bis?

In the considered scenario, when the initial path between the ulids is=20=

working fine, the transmission of probes to verify that the current=20
path is working may result in triggering the context recovery=20
mechanisms i.e. the transmission of a R1bis packet. Such behaviour may=20=

not be the optimum for dealing with the case of the server that wants=20
to discard the clients contexts, in order to let the clients to handle=20=

fault tolernace (the scenario suggested by Iljitsch in the ams=20
meeting). A possibility for dealing with this would be that probes that=20=

verify that the current path is working do not contain context specific=20=

information (as oposed to probes used for exploring the alternative=20
paths, that in order to be used for flooding prevention must carry=20
context specific information). I know that this would imply a change in=20=

the failure detection protocol in Jari's draft, but maybe it would be=20
worth to consider this issue.

Regards, marcelo

PS: agree that interaction with context confusion mechanisms needs to=20
be be clearly understood in order to get the full picture about this=20
R1bis thing

El 10/11/2005, a las 4:06, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> So, the proposal would be to:
>> Define a new type of messages: R1bis
>> Define types of validator mechanisms , which are identified by the 3=20=

>> most significant bits of the validator value
>
> So 3 bits instead of 1 bit is so that we can have some future=20
> extensibility?
>
>> Define an alternative validator mechanism for this message, that=20
>> includes as inputs the following values:
>> - the Secret S
>> - The responder (B) nonce
>> - the locator pair
>> - the context tag contained in the received packet (CTpac)
>> Define that the initiator nonce used for R1bis packets is the hash of=20=

>> the locator pair and CTpac
>
> Good suggestion.
>
>> Define generation and processing of the R1bis packet accordingly.
>
> I guess there is a detail which is whether R1bis is a different=20
> message type than R1, or whether use a bit in R1 to indicate bis vs.=20=

> normal.
> My suggestion is to use a different message type for R1bis.
>
>>      - Perhaps A is already using this context tag for another
>>        context. In this case, A simply starts a regular 4 way
>>        handshake to establish the context again
>>    I guess that the last option seems the preferred alternative...
>
> Hopefully the case when the context tag is use we have the option to=20=

> use the "context confusion" recovery mechanism, which handles other=20
> cases when a context tag has been reused...
>
> I have to think about this some more.
>
>    Erik
>

Delivery-date: Thu, 10 Nov 2005 03:07:55 +0000
Date: Wed, 09 Nov 2005 19:06:51 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about R1bis

marcelo bagnulo braun wrote:

> So, the proposal would be to:
> 
> Define a new type of messages: R1bis
> Define types of validator mechanisms , which are identified by the 3 
> most significant bits of the validator value

So 3 bits instead of 1 bit is so that we can have some future extensibility?

> Define an alternative validator mechanism for this message, that 
> includes as inputs the following values:
> - the Secret S
> - The responder (B) nonce
> - the locator pair
> - the context tag contained in the received packet (CTpac)
> Define that the initiator nonce used for R1bis packets is the hash of 
> the locator pair and CTpac

Good suggestion.

> Define generation and processing of the R1bis packet accordingly.

I guess there is a detail which is whether R1bis is a different message 
type than R1, or whether use a bit in R1 to indicate bis vs. normal.
My suggestion is to use a different message type for R1bis.

>      - Perhaps A is already using this context tag for another
>        context. In this case, A simply starts a regular 4 way
>        handshake to establish the context again
>    I guess that the last option seems the preferred alternative... 

Hopefully the case when the context tag is use we have the option to use 
the "context confusion" recovery mechanism, which handles other cases 
when a context tag has been reused...

I have to think about this some more.

    Erik

Delivery-date: Tue, 08 Nov 2005 18:20:31 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about R1bis
Date: Tue, 8 Nov 2005 19:20:35 +0100

Hi all,

Warning: this is quite long email. I didn't expected that this was a so 
complex issue, but this is the best i could came up with

One of the issues that are still open is how to detect context loss and 
recover it.

* Issue description: (background information, skip till next bullet * 
if you already know what R1bis is)

So far the approach selected is to detect context loss when a packet 
that refers to a non-existent context is received. In other words, A 
detects that it has lost a context when it receives a packet referring 
to a context that is not available.
However, in order to be able to tell that a given packet is referring 
to a non existent context, the packet must contain some information 
that indicate that a context associated to this packet is supposed to 
exist. This implies that data packets carrying the ULIDs in the address 
fields won't be useful to detect context loss, since they are regular 
ipv6 packets without any bits indicating that an associated context is 
supposed to be available at the receiver. OTOH, shim control packets 
and data packets carrying the shim payload header will be useful to 
detect context loss.

This means that the approach selected for context loss detection would 
work as follows:
A shim enabled node will detect that it has lost a context that is 
still being used by the peer when it receives a shim control packet or 
a data packet containing the shim payload header that refer to a non 
existent context.

A consequence of this approach, is that before a rehoming (i.e. when 
locators == ULIDs) only the shim control packets will be able to detect 
a context loss, and assuming that the shim control traffic will be 
limited, it is likely that frequently context loss will remain 
undetected until a failure occurs (this of course depends on the 
traffic pattern, since if periodic probes are required for failure 
detection, these will also be useful for detecting context loss)
However, once that the communication has been rehomed, all data packets 
will be useful for detecting context loss.

Now, without additional considerations, this behavior would be hardly 
acceptable, since context loss can only be (reasonably well) detected 
once that we really need it to be available.
The approach proposed to complement this failure detection mechanism is 
a context recovery mechanism that allows the peer to rebuild the lost 
context.

At this point, this would work as follows:
- Regular IPv6 communication is established between A and B
- Shim context is set up
- Peer A losses the context
- a failure occurs
- packets containing the shim payload header are sent
- Upon the reception of packets, A detects that it does not have a 
context for incoming packet
- A informs B about the missing context
- B reestablishes the context using the context information it has 
available.

The question at this points is how to perform the last two points:
one option would be to define a No context error message to let A 
inform B about the missing context and then let B use the 4 way 
exchange to establish the context again.
However, considering that we are in the situation that we need to use 
the context asap, because a failure has already occurred, it seems wise 
to explore the possibility of reducing the number of packets needed to 
reestablish the context. In particular, the possibility of using  a 
(possibly modified) R1 packet as indication from A to B that a context 
has been lost.

In other words, that upon the reception of a packet referring to a non 
existent context, the receiver return a R1 bis packet, so that the peer 
can continue with the rest of the context establishment exchange (i.e. 
I2 and eventually R2)
The result is a 3 packet exchange instead of a 5 packet exchange.

* About R1bis

The question now is whether R1 bis can be R1 as it is defined or some 
modifications to the R1 packet are needed.

The considered case, we have A and B shim peers that have established a 
context and suppose that B has lost the context.

At this point, A sends a packet referring to the missing context and B 
replies with a R1: the question is whether B can properly generate a R1 
packet or there is some information that B is lacking?

First of all, let's assume that any packet sent from A to B referring 
to the context contains information about the context tag assigned by B 
to identify the context.  This is so, because packets that refer to the 
context are shim control packet or data packets containing the shim 
payload header. The shim payload header carries the context tag, so no 
problem here. The question is if all shim control packet carry the 
context tag. While this is not clear yet, we will assume that for the 
time being:

   ##  Hypothesis 1: all shim control packets and all data packets
   ##  carrying the payload header carry the respective context tag

Now, upon the reception of this packet, B detects that no context 
associated to this packet exists. At this point, does B has the 
required information to build a R1 packet?

R1 packet contains the following information:

- Responder (B) nonce
- Initiator (A) nonce
- Responder (B) validator, which generation is suggested
   in the draft to require:
      - Secret S
      - Responder (B) nonce
      - Initiator (A) assigned context tag
      - ULID pair
      - Locator pair

According to the draft the goal of the validator is that:
    the responder can verify that the validator it receives back in the
    I2 message is indeed one that 1) it computed, 2) it computed for the
    particular context, and 3) that it isn't a replayed I2 message.

So which of this information is available in B?

Clearly all the information about B is likely to be available, in 
particular, B knows:
- The Responder nonce
- The Secret S

OTOH, the information about A is not available, in particular:
- The Initiator nonce
- the Initiator assigned context tag (note that the context tag 
contained in the received packet that referred to the lost context 
carried the context tag assigned by B to the context, not the one 
assigned by A)

Besides, the packet may or may not contain the ULIDs in the address 
fields: in particular, if it was a data packet with the payload 
extension, then the address fields did not contain the ulids. If it was 
a control packet, B has no way to tell if the addresses contained in 
the address fields were the ulids or not.
So, B knows the locator pair but it cannot be certain in general that 
it knows the ulid pair (it can only be certain in the case of the the 
payload header that it does not know the ulids)

Now, we know that B cannot produce a R1 packet since there is some 
information missing.
The next question is whether the information available at B is enough 
to build a R1bis packet that provides the required functionality with 
the required level of protection.

We will first consider the information required for generating a proper 
validator.
B could generate a validator as the hash of the following information:
- the Secret S
- The responder (B) nonce
- the locator pair
- the context tag contained in the received packet (CTpac)

Now is this validator good enough?

As mentioned above, a validator should fulfill the following conditions:

The responder can verify that the validator it receives back in the
I2 message is indeed one that:

1) it computed,
    No problem with this one, since the secret S
    ensures that only the responder is able to
    generate this validator

2) it computed for the particular context,
    This basically means that it must be possible to determine
    to which this validator is associated, so that it results
    impossible to an attacker to generate multiple contexts
    with a single validator.
    In other words, that one validator is used to create,
    at most a single context.
    A possible approach for this would be to remember
    which validators have been issued and which of those
    have been used. However, this is not the selected
    approach, because it would require keeping track of
    generated validators, which would require generating
    state for each I1 message received, and thus opening
    the door to DoS attacks.
    The selected approach is to include information that
    identifies a single context in the input of the hash
    function that generates the validator.
    These two considerations imply that enough information
    to uniquely identify a context after that it is created must
    be included in the validator, so that once that the context
    associated to a given validator is created, it is possible
    to identify future attempts of context generation using
    the same validator.
    The question at this point is which of the available
    information will be stored once the context is created and
    which information is enough to identify a single context.
    Clearly a locator pair and any of the two context tags fulfill
    those two conditions, since they will be stored as part of the
    context state once it is created and they are enough to
    identify a single context.
    In regular R1 validators, the initiators context tag is used.
    In this case, B (the responder) does not knows A (the
    initiator) context tag, but it does know the context tag CTpac
    that B used for the lost context.
    So the options at this point are:
    -  use CTpac as the context tag assigned by B to the new context
       The difficulties with this approach are:
       - Perhaps B is already using this context tag value for
         another context. The possibility here would be that
         B issues a No context error message and that
         the context is restablished using full 4 way handshake.
       - After B replies with R1bis, B will not keep any state
         about this reply, in particular about the context tag
         So, this implies that an I2bis packet would be
         required that it informs B about the context tag that it
         should use for this context that is being created.
         Potentially, this context tag value may have been used
         by B since it issued R1bis and received I2bis . Same as
         the previous case, fall back to full 4 way handshake
    - use CTpac as the context tag assigned by A to this context
      The difficulties with this approach are:
      - A should change the context tag used for this context.
        Not big deal here, i guess.
      - Perhaps A is already using this context tag for another
        context. In this case, A simply starts a regular 4 way
        handshake to establish the context again
    I guess that the last option seems the preferred alternative...

3) that it isn't a replayed I2 message.
Since we are including the responder nonce, we can protect against I2 
replayed attacks

So, a possible approach seems to use a different input for the 
validator of R1bis packets, which input would be:
- the Secret S
- The responder (B) nonce
- the locator pair
- the context tag contained in the received packet (CTpac)
In addition, upon the reception of this R1bis packet, node A needs to 
verify if the CTpac has been locally assigned for any context.
If CTpac is already in use, then initiate a regular context 
establishment exchange, sending a regular I1 packet.
If CTpac is not being used, then assign CTpac as the locally assigned 
context tag for this context that is being recovered, and delete it as 
the remotely assigned context tag, and continue sending an I2 packet.
(Note that CTpac does not need to be included in R1bis, since A already 
knows CTpac because it is contained in the existent context state.)
However, at least a flag or a new type is needed to differentiate R1 
packet from R1bis packet, in order to let a to perform the different 
packet processing

It should be noted that this change in the validator input only affects 
B.
This means, that only B have to know that different information was 
included in the validator input, so no need to inform A that a 
different input was used in the validator. In order to distinguish this 
validator type from the one used in regular R1 packets, it would be 
possible to include, let's say, 3 bits in the validator, to indicate 
the type of validator used. Node A does not need to understand the 
semantics of those 3 bits, but just need to be copied to the I2 packet. 
the responder will be able to read those 3 bits and find the proper 
mechanism to verify the validator.

We have now defined a new way to create a validator for a R1bis packet 
with the available information. In addition, regular R1 packets also 
carry the Initiators nonce, that it is not available when building a 
R1bis packet. We will next analyze alternative options to provide 
similar features than the ones achieved by including the initiator 
nonce.

In order to do that, we need first to understand what the initiator 
nonce is protecting from.
In the draft it is stated that nonces are used to prevent replay 
attacks.
So, what type of replay attacks can be made in the shim scenario?

Suppose that I1 packet does not includes a initiator nonce.
In this case, an attacker could send a replayed R1 packet and the 
initiator would take it for a true packet, since it has no way to 
verify that this is a replay.
The initiator could then continue sending the I2.
If the I2 makes it to the receiver, it will be silently discarded, 
because the responder nonce included in the message does not match with 
the one included in the validator, so the result is a DoS attack, where 
the initiator cannot establish a shim context.

Is there other attack that the initiator nonce is preventing?

In order to provide some kind of protection to this type of attacks, it 
would be possible to craft some kind of initiator nonce from the 
information contained in the received packet that was referring to the 
non existent context.
A possibility would be to use CTpac as initiators nonce. In this case, 
the attacks described above would be limited to attackers that were 
once on path, and that have discovered the context tag. Another option 
would be to use as an initiator nonce a hash of (the locator pair and  
CTpac). In this case, the attacker would need to find out the current 
locator pair, and the context tag. Probably this is good enough 
protection for this type of attacks.

So, the proposal would be to:

Define a new type of messages: R1bis
Define types of validator mechanisms , which are identified by the 3 
most significant bits of the validator value
Define an alternative validator mechanism for this message, that 
includes as inputs the following values:
- the Secret S
- The responder (B) nonce
- the locator pair
- the context tag contained in the received packet (CTpac)
Define that the initiator nonce used for R1bis packets is the hash of 
the locator pair and CTpac
Define generation and processing of the R1bis packet accordingly.

comments?

Delivery-date: Tue, 08 Nov 2005 08:56:07 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC 3484 update
Date: Tue, 8 Nov 2005 09:56:01 +0100
To: Pierre Baume <[email-masked]>

El 07/11/2005, a las 22:28, Pierre Baume escribi=F3:

> Marcelo,
>
> On 11/7/05, marcelo bagnulo braun <[email-masked]> wrote:
> [...]
>
>>>   Would it be a good idea to update section 8 (Implementation
>>> Considerations) of RFC 3484 as well?
>>>
>>
>> In general, I guess that retrying with different source addresses
>> (whether it is performed by the application or by the transport) does
>> indeed deserves some comments in the implementation considerations,=20=

>> but
>> i didn't had in mind some specific issue to include there. Do you =
have
>> anything particular in mind?
>
>   Sorry for being vague, I was thinking that paragraphs 2, 3 and 4 of
> section 3.1.3 of your draft could be used to update section 8 of RFC
> 3484. But this is just an editorial comment. :-)
>

ok

>>>   Here are some specific comments.
>>>
>>>> 3.1.2.  Retrying with different source addresses
>>> [...]
>>>
>>>>    Rule 0: Avoid unreachable source addresses.
>>>>
>>>>    If the address pair with source address SA and destination=20
>>>> address
>>>> D
>>>>    is known to be not working, then prefer SB
>>>
>>>   I think that we need a way to control this iteration.
>>
>> Do you mean a way to limit the number of source addresses that are
>> retried?
>> I asume that this will be up to the application in most of the=20
>> cases...
>> I mean in case that is the application the one making the retrial, =
the
>> clearly is up to the app the number of retrials.
>> In the case that is TCP the one retrying, i guess that the =
application
>> will decide when to give up and try with another destiantion address.
>> I mean, i am not sure whether the source address selection mechanisms
>> should define the maximum number of retrials, since i guess it =
depends
>> on the local policy, which i guess is aligned to your idea, of using
>> the policy table for this, right?
> [...]
>
>> Regards, marcelo
>
>   I was thinking about limiting the scope of the retries.
>
>   For instance, if a host has 3 addresses, 2 used to run a public
> service and 1 for remote administration.
>
>   If you have trouble with a public service address, you don't want to
> send any front-end traffic through your administrative interface, even
> if it would work. This way, you give yourself a chance to connect to
> the machine and troubleshoot. It can also be that the administrative
> address is on a slower interface and practically useless for the
> public service.
>
>   Hopefully, this clarifies some of my other comments as well.
>

right, i see what you mean

With current policy table, what you could do is to allow that for=20
certain destiantions, the source addresses for public service are tried=20=

first and for other destiantions the remote admin address is tried=20
first.

However, you cannot:
- do it per service/application using the policy table (since its=20
granularity is per address/prefix and does not takes into account the=20
service/application). In this case, i guess that the remote admin=20
application will select the proper source address, forcing the source=20
address selection mechanism
- prevent that the remote admin address is used by the public service=20
if the other two addresses are not working (i.e. the policy table=20
allows you to provide an ordering but not to prevent some of the=20
addresses to be tried)

I guess that this is probably not enough for supporting this case,=20
however, it should be noted that the proposed policy table is just a=20
minimum functionality that needs to be provided, and extended features=20=

can be supported

rfc 3484 states that:

    IPv6 implementations SHOULD support configurable address selection
    via a mechanism at least as powerful as the policy tables defined
    here.

So improved mechanisms can be provided... I am not sure if you consider=20=

that the default mechanisms should be able to deal with the scenario =20
that you describe?

I guess that in the case described, a possible approach would be to=20
cosnider that are two virtual hosts, one which is the server, with the=20=

2 public service addresses and other  that is the admin, which has a=20
single address, which is the remote admin address. In this case, there=20=

would be two address selection mechanisms running, one with the two=20
public service addresses and the other with a single address, the=20
remote admin address.

>   I see that you already updated the draft. That's quick. :-)
>

Yes, i was ashamed for the number of errors :-(

Regards, marcelo

> Pierre.
>

Delivery-date: Mon, 07 Nov 2005 23:13:33 +0000
Date: Mon, 7 Nov 2005 23:12:13 +0000 (GMT)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Mail-Copies-To: [email-masked]

(sorry for belated reply)

On Mon, 31 Oct 2005, marcelo bagnulo braun wrote:

> this, by itself would be enough to provide multihomed hosts some 
> mechanism to be able to establish new communications after an 
> outage in one of their ISPs i.e. rfc3484 bis, agree?

Yes, I agree.

> but in this would the app the one that triggers the shim? or would 
> be the shim that detects when there is a problem?... i don't see 
> how this works...

I'm not sure, but I was under the impression the plan was for shim6 
to be able to determine independently of the application whether 
failover was required, possibly using transport protocol hints.

> I am not sure if you are considering the case where the app selects 
> the source address (uses bind()) or not... i asume that the source 
> address is not set by the app.

Ah, well things get tricky if the application specifically selected 
an address. It might not even be wise to try shim such a socket, 
often applications which do this, do so because they expect that it 
will limit which interface(s) packets will arrive or exit from.

Breaking that might not be a good thing.

The vast majority of applications do not bind to a source address. 
Most which do are listening and do so at administrative behest. 
Senders which bind are rare, ones I can think of which sometimes do, 
do so to:

- have their address be independent of any physical interface
   (loopback attached address)
- control which interface(s) the packets will exit from (in
   conjunction with some other administrative action. E.g. routing or
   firewalling rules)
- sending to multicast address
   (kernel picks interface according to source, unless application
   uses some other mechanism to indicate output interface)

others?

> So, the app tries to establish a communication. suppose that there 
> is a failure in one of the isps. the app tries to establish a 
> communication without specifying a source address, and rfc3484 
> selects the address associated to the isp that is down.

> Now, the packet with that src address never make it, so who detects 
> that there is a problem?

The shim, that's its job surely. ;)

> The shim? how is this done? i mean, the shim cannot know if there 
> is an reply packet expected, since it is not aware of the app 
> protocol.

Well, the idea is to have it possibly hook-in to transport notions of 
progress, no? Or even have transports poke shim6.

In the worst case for datagramme protocols where connection state, if 
any, is wholly within the application, shim can do its own probing, 
for some unspecified time after the last packet is sent. There may be 
other sources of information. Seems to me a shim could draw from a 
variety of information sources:

- using Shim6 side-band probing, if other side can co-operate.
- fallback to "dumb" probes, e.g. ICMP based.
- unspecified local information (e.g. link-state)

> The other option would the app, to notify the shim that something 
> is wrong and to try fix it... This would require a modification to 
> the app and would only make sense of the other end supports the 
> shim. As i understand it, this is what we called "shim API on 
> steroids" which would allow an app to tell the shim "i want to 
> connect to hostX, you find a working pair for me"

Maybe. A libshim would be useful actually, possibly in conjunction 
with a shim daemon. For both prototyping and deployment on legacy 
hosts without a native shim.

> This is good, but it does not work with legacy hosts (that don't 
> support the shim), it imposes a shim negotiation upfront. I like 
> your point that this could be done only when the initial contact 
> fails though (but i am not sure how to detect this failure)

Well, shim will have its own control path no? So at least for 
communications between two shim aware hosts it will be possible to 
have an independent way to test viability. For paths to non-shim 
aware hosts you'll have to fall-back to monitoring TCP state (for 
TCP).

Transports where all the flow-state is in the application - no idea. 
Passive observation and maybe some dumb ICMP probes is best you'll 
likely do - hack, but something. But, really that's a *miniscule* 
fraction of inter-AS traffic.

Whatever else, the 99% case is that packets flow back and forth and 
shim literally would need to do nothing but observe. For the 1% of 
time where there is a failure, it doesn't matter if shim6 is not 
perfect and can not provide near-perfect detection for all protocols 
- because if it can cover even 80% of that 1%, then that's *way* 
better than what we have today.

(and I think it's a very safe bet that more than 80% of inter-site 
traffic is TCP, hence more state information available close to 
hand).

If Shim6 is good and useful, more and more hosts will implement it - 
even if it isn't perfect (and btw, lots and lots of complexity to try 
cover that last 10% or less of 'difficult' cases like opaque user 
protocols and make shim 'perfect' might be counter-productive if it 
makes Shim far more difficult to implement). The more hosts implement 
it, the more you'll have the more reliable 'shim6' methods available 
to monitor reachability, hence slowly providing coverage for that 
last 20% of that 1%.

> So, as i see it: - the API on steroids is a good feature that we 
> want to have

> - we need a rfc3484bis at least to support communications with non 
> shim hosts and maybe it would be good to deal with the problem for 
> communications between shim hosts, depending on the result

> please check draft-ietf-shim6-proto-02 there you will find that the 
> shim6 protocol rqeuires a 4 way exchange to establish the shim 
> context, that needs to be done before the shim translation between 
> locators and ulids can be done

Yes, but isn't there another discussion ongoing here to try optimise 
this?

There isn't a good reason to delay packets because of shim6, is 
there? You can send the first packet on without setting up two-way 
shim, just do an "opportunistic" mapping (the NULL mapping likely), 
let the packet go on its way and then also start Shim6 in parallel 
(be it by piggy-backing a shim6 setup message onto this first packet, 
or as a seperate packet). Typically there are no failures and all 
sources are valid, so typically any source will work.

I.e. at "initial contact", the shim can opportunistically startup and 
at least determine whether the other side is a shim6 capable host. If 
progress is obviously being made by ULP, shim6 can stay quiet.

I think in terms of the protocol, this means that shim6 could send 
the I1 message in parallel with the "initial contact" by ULP 
(possibly by piggy backing the I1 on the same packet as an optional 
header, Iljitsch, Pekka, etc. were discussing that I think).

This is the "deferred handshake" part of the Shim6 protocol, I think.

> right. 3 comments:
> - this is only for initial contact (so no problem with breaking tcp 
> connection because using a different address, since the communication is 
> being established at this very moment)
> - this assumes bidirectional working address pairs, (i.e. a single address 
> pair is used in both directions of the communication)
> - it does not require special support from the peer (it works with non-shim 
> nodes)
>

> In this other case, we are dealing with a different problem: how to 
> cope with failures during the initial contact?

Ah, got ya.

> however, it seems that there are apps that select the source 
> address they want to use using bind().

Right, see above.

> For this it makes sense to provide some guidance of how this needs 
> to be done

> I am not saying that this is the only mechanism that we need to 
> deal with this, but what i am saying is that IF apps are going to 
> select the source address, we need to provide guidance so that they 
> do it properly taking into account that different source addresses 
> need to be tried in case of a failure

Right, but the thing is, if an application is one of those rare apps 
which deliberately sets its source address - ask yourself "why is it 
doing that?", the reasons for doing so possibly are fundamentally 
incompatible with cycling through addresses for redundancy..

There's no point changing an RFC to add source address cycling, if 
the only apps picking source addresses are doing so because of 
multicast or explicit administrative action. ;)

That leaves the other set of apps, ones which do not bind() to any 
explicit address. I don't see then why apps then have to get into 
details of SAS - the whole point of shim6 is to handle that.

Needs consideration at least.

> well, rfc3484 state for instance that the app should iterate 
> through all the list of available destination addresses until one 
> that is working is found. This is why it seems that rfc3484bis 
> should be the place to state that in the case that multiple source 
> addresses are available, the app that decides to set the source 
> address using bind() should iterate through all available source 
> addresses until it finds one that is working

Maybe, but see above.

> do you have any idea you could share?

Write a connection setup / management library to handle 
multi-dest/source addresses nicely. This library could even take care 
of handling reconnects nicely. Further discussion is a bit out of 
scope (and I don't have any immediate interest in it ;) ).

> weel this is just another way to put it, right? whether you call it 
> shim without the shim protocol or rfc3484 bis, they would be local 
> mechanisms for identifying non working source addresses and 
> selecting those that are working, right?

Well, no. RFC3484 would affect *everything. Specifying as part of 
shim would only affect shim. As part of RFC3484, you'd be 
fundamentally changing how applications work today, e.g:

- SAS today assumes applications generally don't specify
   source-address, but if they do so it's for
   exceptional/administrative reasons - not overriden. You'd have to
   consider all those exceptional/administrative reasons..

- SAS today assumes routing policy has a strong influence (SAS is
   typically done after the output route is known). Applications
   however generally are not aware of routing. Seems a big change.

I think possibly it might be better to confine this to Shim6 
initially, where its application is more obvious.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Mathematics deals exclusively with the relations of concepts
to each other without consideration of their relation to experience.
 		-- Albert Einstein

Delivery-date: Mon, 07 Nov 2005 21:48:06 +0000
Date: Tue, 08 Nov 2005 08:47:38 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: AD Evaluation comments on : draft-ietf-grow-rfc1519bis-02.txt
Cc: David Meyer <[email-masked]>

uuuuusssshhhhhpppp!

(loud sucking noise of pulling this mail back - it was meant for the GROW 
mailing list - sorry for the noise - jet lag barin fade :-))

    Geoff

At 08:24 AM 8/11/2005, Geoff Huston wrote:
>Hi,
>
>In the WG meeting this morning there was a request to share the AD's 
>evaulation comments on draft-ietf-grow-rfc1519bis-02.txt with the Working 
>Group.
>
>We've checked with the AD on the procedure here, and we're happy to 
>forward these comments on to the mailing list. These comments have already 
>been passed to the document authors and the document is being worked on by 
>the authors to respond to these comments.
>
>Thanks,
>
>    Geoff & Dave
>
>-------------------------------------------------------------------------------------------------------------------------
>
>---
>
>   The IANA makes allocations from this pool to Regional Internet
>   Registries, as required. These allocations are made in contiguous
>   bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes).
>
>I don't believe it is a good idea to describe this at this level of
>detail, I believe it is intended for informational purposes but this
>draft is standards track and it is not intended to limit the
>flexibility of the IANA/registry interaction into only giving /8s.
>
>---
>
>  The RIRs, in turn, allocate or assign smaller address blocks to Local
>  Internet Registries (LIRs) or Internet Service Providers (ISPs).
>  These entities may make direct use of the assignment (as would
>  commonly be the case for an ISP) or may make further sub-allocations
>  of addresses to their customers.
>
>For most regional registries (geoff please correct me if I am wrong),
>they only deal with LIRs. They treat ISPs and all their other
>customers the same and call them LIRs. Basically, RIRs allocate or
>assign address space to LIRs, which in turn can be ISPs, large
>corporations or whatever other entitity that has the money and is
>willing to obey the rule of being an LIR.
>
>---
>
>  In practice, prefixes of length shorter than 8 are not allocated or
>  assigned though routes to such short prefixes may exist in routing
>  tables if or when aggressive aggregation is performed.
>
>Never say never, I would refrain from comments like this, we never know 
>whether a large
>DSL/cable or whatever provider might actually get a /7. I would simply
>drop this line and I admit that this one is a bit of a nitpick.
>
>---
>
>  To this end, it is recommended that mechanisms to facilitate such
>  migration, such as dynamic host address assignment using [RFC2131]) be
>  deployed wherever possible, and that additional protocol work be done
>  to develop improved technology for renumbering.
>
>Probably add a few more references to documents that can help here and
>expand the text a little bit.
>
>---
>I don't think the following sentence is constructed particularly well:
>
>  Also, since the routing cost associated with assigning a multi-homed
>  site out of a service provider's address space is no greater than the
>  old method of sequential number assignment by a central authority, it
>  makes sense to assign all end-site address space out of blocks
>  allocated to service providers.
>
>I know what you are trying to say but I was first reading it such that
>the registries have different blocks of address space for customers
>that are a service provider and other customers and that there is
>really no need to do this. It is meant that one can as well
>assign address space to an enduser who multihomes from it's provider
>instead of getting an assignment from the registry. However, I am not
>sure whether I agree as the provider of the enduser probably doesn't
>like this situation when the customer leaves as it can easily end up
>receiving traffic that was intended for the former customer due to
>filtering and failures somewhere in the Internet.
>
>---
>
>typo & perhaps some editorial work needed:
>
>  If, for some reason, the provider were to
>  use an obsolete IGP that doesn't support classless routing or
>  variable-length subnets, then then explicit routes all /24s will
>                          ^^^^^^^^^
>
>----
>
>Use example network range where possible
>
>
>----
>
>I would prefer to not give any examples on how to do classless
>in-addr for >/24 delegations and use the reference earlier in this
>section. I think showing the problem is fine, I would leave the
>solution completely to the referenced rfc to avoid duplication and
>people immitating the example without reading the reference.
>
>----
>
>While:
>
>  8.  Analysis of CIDR's effect on global routing state
>
>is an interesting chapter, I am not sure whether it is a good idea to
>refer to pictures that cannot be in the document. In addition, it
>is a bit more of an opinion piece than exact science . I would be inclined
>to drop it but understand that this is just one opinion.
>
>----
>
>Output from:
>
>idnits 1.72
>
>draft-ietf-grow-rfc1519bis-02.txt:
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html :
>
>     * The document seems to lack an Introduction section.
>      * The document seems to lack an IANA Considerations section.
>      Checking conformance with RFC 3978/3979 boilerplate...
>      the boilerplate looks good.
>
>   Checking nits according to
>http://www.ietf.org/ietf/1id-guidelines.txt :
>
>Nothing found here (but these checks does not cover all of
>1id-guidelines.txt yet).
>
>Miscellaneous warnings:
>
>   - Line 90 has weird spacing: '...classes  of ne...'
>
>   Run idnits with the --verbose option for more detailed
>   information.
>
>---

Delivery-date: Mon, 07 Nov 2005 21:29:51 +0000
Date: Tue, 08 Nov 2005 08:24:01 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: AD Evaluation comments on : draft-ietf-grow-rfc1519bis-02.txt
Cc: David Meyer <[email-masked]>

Hi,

In the WG meeting this morning there was a request to share the AD's 
evaulation comments on draft-ietf-grow-rfc1519bis-02.txt with the Working 
Group.

We've checked with the AD on the procedure here, and we're happy to forward 
these comments on to the mailing list. These comments have already been 
passed to the document authors and the document is being worked on by the 
authors to respond to these comments.

Thanks,

    Geoff & Dave

-------------------------------------------------------------------------------------------------------------------------

---

   The IANA makes allocations from this pool to Regional Internet
   Registries, as required. These allocations are made in contiguous
   bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes).

I don't believe it is a good idea to describe this at this level of
detail, I believe it is intended for informational purposes but this
draft is standards track and it is not intended to limit the
flexibility of the IANA/registry interaction into only giving /8s.

---

  The RIRs, in turn, allocate or assign smaller address blocks to Local
  Internet Registries (LIRs) or Internet Service Providers (ISPs).
  These entities may make direct use of the assignment (as would
  commonly be the case for an ISP) or may make further sub-allocations
  of addresses to their customers.

For most regional registries (geoff please correct me if I am wrong),
they only deal with LIRs. They treat ISPs and all their other
customers the same and call them LIRs. Basically, RIRs allocate or
assign address space to LIRs, which in turn can be ISPs, large
corporations or whatever other entitity that has the money and is
willing to obey the rule of being an LIR.

---

  In practice, prefixes of length shorter than 8 are not allocated or
  assigned though routes to such short prefixes may exist in routing
  tables if or when aggressive aggregation is performed.

Never say never, I would refrain from comments like this, we never know 
whether a large
DSL/cable or whatever provider might actually get a /7. I would simply
drop this line and I admit that this one is a bit of a nitpick.

---

  To this end, it is recommended that mechanisms to facilitate such
  migration, such as dynamic host address assignment using [RFC2131]) be
  deployed wherever possible, and that additional protocol work be done
  to develop improved technology for renumbering.

Probably add a few more references to documents that can help here and
expand the text a little bit.

---
I don't think the following sentence is constructed particularly well:

  Also, since the routing cost associated with assigning a multi-homed
  site out of a service provider's address space is no greater than the
  old method of sequential number assignment by a central authority, it
  makes sense to assign all end-site address space out of blocks
  allocated to service providers.

I know what you are trying to say but I was first reading it such that
the registries have different blocks of address space for customers
that are a service provider and other customers and that there is
really no need to do this. It is meant that one can as well
assign address space to an enduser who multihomes from it's provider
instead of getting an assignment from the registry. However, I am not
sure whether I agree as the provider of the enduser probably doesn't
like this situation when the customer leaves as it can easily end up
receiving traffic that was intended for the former customer due to
filtering and failures somewhere in the Internet.

---

typo & perhaps some editorial work needed:

  If, for some reason, the provider were to
  use an obsolete IGP that doesn't support classless routing or
  variable-length subnets, then then explicit routes all /24s will
                          ^^^^^^^^^

----

Use example network range where possible

----

I would prefer to not give any examples on how to do classless
in-addr for >/24 delegations and use the reference earlier in this
section. I think showing the problem is fine, I would leave the
solution completely to the referenced rfc to avoid duplication and
people immitating the example without reading the reference.

----

While:

  8.  Analysis of CIDR's effect on global routing state

is an interesting chapter, I am not sure whether it is a good idea to
refer to pictures that cannot be in the document. In addition, it
is a bit more of an opinion piece than exact science . I would be inclined
to drop it but understand that this is just one opinion.

----

Output from:

idnits 1.72

draft-ietf-grow-rfc1519bis-02.txt:

   Checking nits according to http://www.ietf.org/ID-Checklist.html :

     * The document seems to lack an Introduction section.
      * The document seems to lack an IANA Considerations section.
      Checking conformance with RFC 3978/3979 boilerplate...
      the boilerplate looks good.

   Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt :

Nothing found here (but these checks does not cover all of
1id-guidelines.txt yet).

Miscellaneous warnings:

   - Line 90 has weird spacing: '...classes  of ne...'

   Run idnits with the --verbose option for more detailed
   information.

---

Delivery-date: Mon, 07 Nov 2005 21:29:42 +0000
Date: Mon, 7 Nov 2005 22:28:56 +0100
From: Pierre Baume <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC 3484 update
Cc: shim6-wg <[email-masked]>

Marcelo,

On 11/7/05, marcelo bagnulo braun <[email-masked]> wrote:
[...]

> >   Would it be a good idea to update section 8 (Implementation
> > Considerations) of RFC 3484 as well?
> >
>
> In general, I guess that retrying with different source addresses
> (whether it is performed by the application or by the transport) does
> indeed deserves some comments in the implementation considerations, but
> i didn't had in mind some specific issue to include there. Do you have
> anything particular in mind?

  Sorry for being vague, I was thinking that paragraphs 2, 3 and 4 of
section 3.1.3 of your draft could be used to update section 8 of RFC
3484. But this is just an editorial comment. :-)

> >   Here are some specific comments.
> >
> >> 3.1.2.  Retrying with different source addresses
> > [...]
> >
> >>    Rule 0: Avoid unreachable source addresses.
> >>
> >>    If the address pair with source address SA and destination address
> >> D
> >>    is known to be not working, then prefer SB
> >
> >   I think that we need a way to control this iteration.
>
> Do you mean a way to limit the number of source addresses that are
> retried?
> I asume that this will be up to the application in most of the cases...
> I mean in case that is the application the one making the retrial, the
> clearly is up to the app the number of retrials.
> In the case that is TCP the one retrying, i guess that the application
> will decide when to give up and try with another destiantion address.
> I mean, i am not sure whether the source address selection mechanisms
> should define the maximum number of retrials, since i guess it depends
> on the local policy, which i guess is aligned to your idea, of using
> the policy table for this, right?
[...]

> Regards, marcelo

  I was thinking about limiting the scope of the retries.

  For instance, if a host has 3 addresses, 2 used to run a public
service and 1 for remote administration.

  If you have trouble with a public service address, you don't want to
send any front-end traffic through your administrative interface, even
if it would work. This way, you give yourself a chance to connect to
the machine and troubleshoot. It can also be that the administrative
address is on a slower interface and practically useless for the
public service.

  Hopefully, this clarifies some of my other comments as well.

  I see that you already updated the draft. That's quick. :-)

Pierre.

Delivery-date: Mon, 07 Nov 2005 11:24:34 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC 3484 update
Date: Mon, 7 Nov 2005 12:24:13 +0100
To: Pierre Baume <[email-masked]>

Hi Pierre,

thanks for the comments and the detailed review...
see inline for my  reply

El 06/11/2005, a las 16:10, Pierre Baume escribi=F3:

> Hi Marcelo,
>
>   Good stuff.
>
>   Would it be a good idea to update section 8 (Implementation
> Considerations) of RFC 3484 as well?
>

In general, I guess that retrying with different source addresses=20
(whether it is performed by the application or by the transport) does=20
indeed deserves some comments in the implementation considerations, but=20=

i didn't had in mind some specific issue to include there. Do you have=20=

anything particular in mind?

>   Here are some specific comments.
>
>> 3.1.2.  Retrying with different source addresses
> [...]
>
>>    Rule 0: Avoid unreachable source addresses.
>>
>>    If the address pair with source address SA and destination address=20=

>> D
>>    is known to be not working, then prefer SB
>
>   I think that we need a way to control this iteration.

Do you mean a way to limit the number of source addresses that are=20
retried?
I asume that this will be up to the application in most of the cases...
I mean in case that is the application the one making the retrial, the=20=

clearly is up to the app the number of retrials.
In the case that is TCP the one retrying, i guess that the application=20=

will decide when to give up and try with another destiantion address.
I mean, i am not sure whether the source address selection mechanisms=20
should define the maximum number of retrials, since i guess it depends=20=

on the local policy, which i guess is aligned to your idea, of using=20
the policy table for this, right?

> As a default, I
> suggest that we use the policy table and limit it to addresses with=20
> the same
> label.

I am not sure this would result in the expected behaviour...
As i understand it, labels are used to determine which source address=20
to prefer for a given destiantion address.
In order for this to work, you need to include the destiantion address=20=

(or a prefix containing it) in the policy table and assign a lable to=20
it.
I am not sure how to use this in order to limit the number of=20
retrials....
perhaps you could expand on what usage did you have in mind for doing=20
this...

>  That's provided that I understand what labels are for. ;-)
>
>> 3.1.3.  Providing an ordered list of source address
>>
>>    In addition to recommending that when the application selects the
>>    source address, it should try with all available address pairs to
>>    establish the communication, it would also make sense to provide=20=

>> some
>>    guidance about which addresses to try first.
> [...]
>
>   Same remark as above.

Well, the order of the list will be certainly influenced by the policy=20=

table and the labels assigned to the source addresses, but this would=20
not result in limiting the number of addresses included in the list=20
(unless we do some modification to the current behaviour of the policy=20=

table)
Again, do you have in mind some specific change here?

>
>>    However, such approach has the drawback that the resulting order =
of
>>    address pairs to try may not be the optimal, since for each
>>    destination address, all the available source address would be=20
>> tried
>>    before moving on to the next destination address.
> [...]
>
>   Restricting the iteration through possible source addresses will=20
> also help
> reduce the number of address pairs that are tried.
>

Right, i certainly agree that may make sense to reduce the amount of=20
source addresses but i am not sure if the policy table is the right=20
tool for doing it

>   Typos and nitpicks follow. :-)
>

Thanks, i will correct those asap.
(i am sorry for all the mistakes but i was in kind of a rush...)

Regards, marcelo

Delivery-date: Sun, 06 Nov 2005 21:15:49 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-ietf-shim6-proto-02.txt
Date: Sun, 6 Nov 2005 22:15:20 +0100

Hi,

i send a few comments on the v2 of the protocol draft.

regards, marcelo

1.2  Non-Goals

    This proposal also does not try to provide an IP identifier.

I would rephrase this to something like

    This proposal also does not try to provide a new network
    level identifier namespace separated from current IP address
    namespace.

I mean, we are using the concept of ULID and we are using a designated 
locator as the network level identifier.

1.3  Locators as Upper-layer Identifiers

    For example, the protocol already needs to handle ULIDs that are not
    initially reachable.  Thus the same mechanism can handle ULIDs that
    are permanently unreachable from outside their site.  The issue
    becomes how to make the protocol perform well when the ULID is not
    reachable, for instance, avoiding any timeout and retries in this
    case.

correct me if i am wrong, but i don't think that it is a goal to design 
a protocol that prevents retrials and timeouts when the ULID is a 
routable locator that is circumstantially  unreachable, right? I think 
that what is meant here, is that we want to prevent timeouts and 
retrials when we know a priori that the ulid is not a valid locator 
(like in the case of ulas) right?
If so, i would suggest the following rephrasing:

    The issue
    becomes how to make the protocol perform well when the ULID is known
    a priori to be not reachable (e.g. the ULID is a ULA), for instance,
    avoiding any timeout and retries in this case.

1.6  Placement of the shim

    The MOBIKE WG
    is looking at ways to have IPsec security associations survive even
    though the IP addresses changes, which is a different approach.

I guess that it would be good to add a reference to the actual mobike 
protocol (so that there is a reference when the mobike wg is done)

4.2  Securing shim6

I would add as an additional security technique:

    o  Every control message of the shim6 protocol must carry
       the valid context tag assigned to the particular context.
       This implies that an attacker needs to discover that
       context tag before being able to spoof any shim6 control
       message. Such discovery probably requires to be along the
       path in order to be sniff the context tag value. The result
       is that through this technique, the shim6 protocol is
       protected against off path attackers.

4.3  Overview of Shim Control Messages

    There is a No Context error message defined, when a control or
    payload packet arrives and there is no matching context state at the
    receiver.  When such a message is received, it will result in the
    destruction of the shim context and a re-establishment.

I guess that this is under discussion, but just as a remainder...
I guess that the current idea would be not to discard but to try to 
recover the lost context, right?
( i mean reestablishment without previous discard)

5.9  Update Request Message Format

    The following options are allowed in the message:
    Locator List:  The list of the senders (new) locators.  The locators
                   might be unchanged and only the preferences have
                   changed.
    Locator Preferences: Optionally sent when the locators don't all have
                   equal preference.
    CGA Signature: Included when the some of the locators in the list use
                   CGA (and not HBA) for validation.

In addition, i think we need to allow this message to carry the CGA 
Parameter Data structure Option, in order to support the case when the 
I2/R2 packets didn't carry the locator list, and didn't carry the CGA 
parameter data structure... (either this or we must mandate that the 
CGA parameter data structure is carried both in the I2 and R2 packets)

I think that the idea would be to allow the update request message to 
carry the CGA parameter data structure in it, so that this is aligned 
with the comment made in the R2 packet description saying "Locator 
List:  _Optionally_ sent when the responder immediately wants to tell 
the initiator its list of locators." (emphasis mine)

6.1  Conceptual Data Structures

I don't know if timers involved should be included in here, but in case 
they should, i guess that at least the time used to tear down the 
context should be described here.
An option for this would be the time elapsed since the last data or 
control packet associated to the context was exchanged.
The timers involved in context establishment may also need to be 
included here.
In addition, i guess that the multiple timers involved in path 
exploration and failure detection would be needed, but probably those 
are better to be described in the failure detection protocol document.

7.2  Concurrent context establishment

    If a host has received an I1 and sent an R1, then a ULP can trigger
    it to send an I1 message itself, since it doesn't retain any state
    when receiving the I1 message.  Thus while one end is sending an I1
    the other is sending an I2.

I am not sure in this case why it is useful that the initiator replies 
to the I1 sent by the responder with an R2... as i see it, the previous 
I2 message should get to the responder, making him to issue a R2 back. 
The R2 sent by the initiator will have no effect in the responder as i 
understand it... wouldn't make sense to remove this R2 then? Perhaps it 
would be better to reply with an I2 instead of an R2?
I mean, that the initiator replies to the I1 of the responder by 
repeating the I2 instead of sending a new R2... this would keep the 
roles simpler imho, since the initiator would always send I messages 
and the responder R messages...

7.4  Context confusion

I think that the context confusion scenarios may be even more complex 
than the cases described.

For instance consider the case where A and B were communicating and 
established a context with A1 and B1 as ulids. Locator pairs for this 
context are (A1,A2) and (B1,B2) respectivelly. B has allocated context 
C1 for this context.
Now B looses context state.
Later on, B sets up a new context with A but instead of using B1 as 
ulid, it uses B3 (which was not the previous ulid nor it was included 
in the locator set for the previous context)
So, far, A cannot detect that B is the same peer with A has another 
context established with.
Later on, B decides to add B2 as a valid locator for the new context. 
At this point, A realizes that B is the same host than earlier and it 
has a conflict since the tuple (local locator, remote locator, context 
tag) does not uniquely identifies a single context anymore.

I mean, there is an even delayed moment where A can detect the context 
confusion and that is when B decides to add a previous locator in the 
locator set of the new context.
I don't know if this brings additional difficulties... i guess that the 
possible solutions for this still apply, but the moment of discarding 
the old context may not only be at the establishment phase but also 
later on

7.5  Sending I1 messages

    If, after several retransmissions, there is no response, then most
    likely the peer does not implement the shim6 protocol, or there could
    be a firewall that blocks the protocol.

Or that a failure has just affected the path between the ulids... right?
would it make sense to try to recover here? i.e. using alternative 
locator pairs for exchanging the initial exchange packets and carrying 
different ULID pair as an option?

Editorial

Abstract

    The hosts in a site which has multiple
    provider allocated IPv6 address prefixes, will use the shim6 protocol
    specified in this document to setup state with peer hosts, so that
    the state can later be used to failover to a different locator pair,
    should the original one stop working.

s/stop/stops

(the same comment in the Introduction)

5.2  Payload Message Format

    The payload message is used to carry ULP packets where the receiver
    must replace the content of the source and or destination fields in

s/and or/and/or

5.9  Update Request Message Format

    Thus there is no
    mechanisms to just send deltas to the locator list.

s/mechanisms/mechanism

5.15.3  Locator Preferences Option Format

    When the Element length equals one, then the element consists of only
    a flags field.

the "1 octet" is missing
I think it should read:

    When the Element length equals one, then the element consists of only
    a 1 octet flags field.

5.15.5  CGA Signature Option Format

    When CGA is used for validation of one or more of the locators in the
    PDS,

The locators in the Locator List option rather than in the PDS

so it should read:

5.15.5  CGA Signature Option Format

    When CGA is used for validation of one or more of the locators in the
    Locator List option,

7.6  Receiving I1 messages

    If the host looks up a context for the ULID pair and the peer's (not
    its) context tag.

I guess that the initial if should be removed

10.  Teardown of the Host Pair Context

    However, there
    might be cases when the knowledge is not readily available to the
    shim layer, for instance for UDP applications which not not connect

rm not

Delivery-date: Sun, 06 Nov 2005 15:11:31 +0000
Date: Sun, 6 Nov 2005 16:10:24 +0100
From: Pierre Baume <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC 3484 update
Cc: shim6-wg <[email-masked]>

Hi Marcelo,

  Good stuff.

  Would it be a good idea to update section 8 (Implementation
Considerations) of RFC 3484 as well?

  Here are some specific comments.

> 3.1.2.  Retrying with different source addresses
[...]

>    Rule 0: Avoid unreachable source addresses.
>
>    If the address pair with source address SA and destination address D
>    is known to be not working, then prefer SB

  I think that we need a way to control this iteration. As a default, I
suggest that we use the policy table and limit it to addresses with the sam=
e
label. That's provided that I understand what labels are for. ;-)

> 3.1.3.  Providing an ordered list of source address
>
>    In addition to recommending that when the application selects the
>    source address, it should try with all available address pairs to
>    establish the communication, it would also make sense to provide some
>    guidance about which addresses to try first.
[...]

  Same remark as above.

>    However, such approach has the drawback that the resulting order of
>    address pairs to try may not be the optimal, since for each
>    destination address, all the available source address would be tried
>    before moving on to the next destination address.
[...]

  Restricting the iteration through possible source addresses will also hel=
p
reduce the number of address pairs that are tried.

  Typos and nitpicks follow. :-)

> 2.1.  Reference topology
[...]

>    Host X has to global IPv6

  s/to/two/

>    addresses, which we will note "A:X" and "B:X", formed by combined the

  s/combined/combining/

>    prefixes allocated by ISP A and B to "site X" with the host
>    identifier of X. Y has only one address "C:Y".
[...]

> 2.1.1.  RFC 3484 and the shim6 protocol
[...]

>    Essentially , the
>    proposed mechanisms are aimed to allow a node in a multihomed site
>    that implement them to be able to establish a new communication after

  s/implement/implements/

>    an outage with an external host that does not have any multihoming
>    specific support mechanism.
[...]

>    It is also possible to use the mechanisms described in this note to
>    establish communications between two shim enable peers.
[...]

  s/enable/enabled/

> 2.2.  The problem: address selection after failures
[...]

>    o  If X tries to communicate with Y using A:X as a source address,
>       packets will be routed through ISPA in order to comply with
>       ingress filters, and because ISPA has no link available wit the

  s/wit/with/

>       rest of the Internet, the packet will be discarded (it should be
>       noted that even if the packet could make it to Y, reply packets
>       from Y to X would contain A:X as a destination address, which is
>       unreachable from Y).
[...]

> 3.  Updates to RFC 3484
[...]

>    o  In case that the application does not selects a source address,

  s/selects/select/

>       the source address selection mechanism described how the IP layer

  s/described/describes/

>       selects the source address for a given destination address.
[...]

>    o  When the source address is specified by the application, the
>       source address selection mechanism does not provides any guidance

  s/provides/provide/

>       to the application about how to select the source address for
>       communicating with a destination address.  In particular, RFC 3484
>       does not recommends that the application should iterate through

  s/recommends/recommend/

>       all available source address until a working address pair is

  s/address/addresses/

>       found.
[...]

> 3.1.1.  Considered scenario
[...]

>    The stack and the source address selection mechanisms should honnour

  s/honnour/honour/

>    this choice.
[...]

> 3.1.3.  Providing an ordered list of source address
[...]

>    A possibility would be to let the source address
>    selection mechanism to order that list before it is returned to the

  s/to order/order/

>    application.
[...]

> 3.2.3.  UDP sockets
>
>    In this case, it is not possible to use a similar approach to the one
>    described for TCP, because there is no way to determine if a given
>    source address is working or not, because there are no connection

  s/are/is/

>    establishment packet exchange as in the case of TCP.
[...]

>    A detailed description of how this would is

  s/would/would work/

>    included in [3].  In any case, the goal here is to keep track of
>    source address tried for each destination address and whether these

  s/source addresses/the source addresses/

>    have worked or not (according to the previous definition of
>    "working").
[...]

  That's it. :-)

Pierre.

Delivery-date: Sat, 05 Nov 2005 05:54:14 +0000
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Fwd: RFC 4218 on Threats Relating to IPv6 Multihoming Solutions
Date: Sat, 5 Nov 2005 06:53:13 +0100
To: [email-masked]

Begin forwarded message:

> From: [email-masked]
> Date: tisdag 1 nov 2005 01.50.28 GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4218 on Threats Relating to IPv6 Multihoming Solutions
>
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4218
>
>         Title:      Threats Relating to IPv6 Multihoming Solutions
>         Author(s):  E. Nordmark, T. Li
>         Status:     Informational
>         Date:       October 2005
>         Mailbox:    [email-masked], [email-masked]
>         Pages:      31
>         Characters: 75969
>         Updates/Obsoletes/SeeAlso:    None
>
>         I-D Tag:    draft-ietf-multi6-multihoming-threats-03.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4218.txt
>
>
> This document lists security threats related to IPv6 multihoming.
> Multihoming can introduce new opportunities to redirect packets to
> different, unintended IP addresses.
>
> The intent is to look at how IPv6 multihoming solutions might make
> the Internet less secure; we examine threats that are inherent to
> all IPv6 multihoming solutions rather than study any specific
> proposed solution.  The threats in this document build
> upon the threats discovered and discussed as part of the Mobile IPv6
> work.
>
> This document is a product of the Site Multihoming in IPv6 Working
> Group of the IETF.
>
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].   
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions  
> to RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

Delivery-date: Sat, 05 Nov 2005 05:53:43 +0000
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Fwd: RFC 4219 on Things Multihoming in IPv6 (MULTI6) Developers Should Think About
Date: Sat, 5 Nov 2005 06:53:11 +0100
To: [email-masked]

Begin forwarded message:

> From: [email-masked]
> Date: tisdag 1 nov 2005 01.52.14 GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4219 on Things Multihoming in IPv6 (MULTI6) Developers  
> Should Think About
>
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4219
>
>         Title:      Things Multihoming in IPv6 (MULTI6) Developers
>                     Should Think About
>         Author(s):  E. Lear
>         Status:     Informational
>         Date:       October 2005
>         Mailbox:    [email-masked]
>         Pages:      12
>         Characters: 25141
>         Updates/Obsoletes/SeeAlso:    None
>
>         I-D Tag:    draft-ietf-multi6-things-to-think-about-01.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4219.txt
>
>
> This document specifies a set of questions that authors should be
> prepared to answer as part of a solution to multihoming with IPv6.
> The questions do not assume that multihoming is the only problem of
> interest, nor do they demand a more general solution.
>
> This document is a product of the Site Multihoming in IPv6 Working
> Group of the IETF.
>
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].   
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions  
> to RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

Delivery-date: Fri, 04 Nov 2005 18:06:57 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: RFC 3484 update
Date: Fri, 4 Nov 2005 19:06:35 +0100

Hi all,

as accorded in the meeting in amsterdam, i have produced a memo 
describing the limitations of RFC 3484 in multihomed environments and 
the proposed modifications that would be required to produce an 
rfc3484bis that supports multihoming.

You can find the document at:

http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-rfc3484-update-00.txt

Any comments are welcome.

I won't be able to be at vancouver, but Erik has kindly agreed to 
present it there.

Regards, marcelo

Delivery-date: Fri, 04 Nov 2005 06:47:27 +0000
Date: Fri, 04 Nov 2005 15:46:18 +0900
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Cc: [email-masked]

Hello Marcelo,

Sorry for the delay, but let me resume discussion on the email
thread which was suspended due to my absence about two weeks ago.
We were having discussions about need of interaction between ULP
(application) and shim6 in terms of activating shim6 feature for
particular flow.  I've snipped the points on which we already agreed.
Please find my responses inline.

On Mon, 17 Oct 2005 17:47:46 +0200
marcelo bagnulo braun <[email-masked]> wrote:

[snipped]

> 
> > Although ULID and locator are conceptually different thing, ULID is
> > at the same time one of locators.  This poses me following questions:
> >
> > Q1: Who decides which locator to be used as ULID ? (Shim6? ULP?)
> 
> ok, now i lost it
> for now, all locators are ULIDs and all ULIDs are valid locators (we 
> are exploring the possibility of using ulids that are not valid 
> locators, but not there yet)
> 
> So, when the ULP selects the ulid, it is actually selecting the locator 
> to be used initially as long as no failure occurs
> through forking the ulp can change to other locator
> After a failure, the shim selects the alternative locator to use, but 
> there are also forking here and also preferences
> 
> But i feel that this is not the point here. A i understood your point 
> above is that you think that it would be useful to allow a ULP to avoid 
> using the shim for its traffic.

Yes.  This may sound negative, but I think it is needed.

> As i see it, this is not performed by selecting a given ULID or locator 
> (as it would be in MIP, selecting the CoA)

Right.

> Here as i see it we would need something else, for instance:
> - an extended API (TBD) which allows ULP to indicate the shim that no 
> shim services are required for that flow

Yes, this is the one suggested by Erik (having socket option something
like IPV6_DONTSHIM).

> - configuration of the heuristics that trigger the shim establishment, 
> so that the shim context is not established for those flows that use 
> certain apps (this is somehow limited, because in case that we have two 
> apps, one that wants the shim and other that doesn't want it, then this 
> mechanism wouldn't work, and we would need to use the API above)
> 
> [Please note that shim protocol as currently defined supports this. I 
> mean, because we are using the shim payload header to indicate if a 
> packet needs to be rewritten, we can have two apps using the same 
> locators, one of which need to be rewritten by the shim and the other 
> that doesn't requires locators to be rewritten.

Yes, it's true that current shim6 design allows receiver to determine if
the packet requires demux or not by checking appearance of shim payload
header.

> for example, consider app1 uses A1 and B1 as ULIDs and locators.
> Now consider app2, that uses A2 and B2 as ulids and locators.
> Now suppose that app1 doesn't want to use the shim and that app2 does 
> want to use the shim.
> so a shim context with ulids A2 and B2 is created and suppose that A1 
> and B1 are alternative locators for those ulids (for app2)
> Now, for any reason, app2 traffic starts using A1 and B1 as locators
> At this point, both app1 and app2 traffic would be flowing using A1 and 
> B1 as addresses in the IPv6 packets. However, packets corresponding to 
> app1 wouldn't carry the shim header so no need to rewrite while packets 
> corresponding to app2 would carry the shim payload header, so they will 
> be rewritten, so no proble with supporting one app traffic that don't 
> requires the shim. The only problem here is how the app indicates the 
> shim that it doens't want shim services, agree?]

Yes, that's exactly the point that I was trying to make.  It's slightly
more than that, actually.  Please find my further comments below.

> 
> >   - IMHO, it would make sense to let ULP to decide.  According
> >     to the decision, shim6 takes care of context establishment.
> >
> > Q2: Who makes the ULID selection ?
> >   - I agree that one choice would be to let ULP make selection
> >     through source address selection. It would also possible of course
> >     that ULP has no specific preference on which ULID to use, which 
> > will
> >     result in kernel choosing the source address as defined in RFC 
> > 3484.
> >
> > To summarize, I think your comments are answers to Q2 above (actually
> > its more than answers to Q2 but IMHO it does not cover answers to Q1).
> > Taking look at Q1 from slightly different angle, I wonder how could
> > application decide whether to request shim6 support or not.  What do 
> > you
> > think?
> >
> 
> i think that this point is important, see above for the optins that i 
> can think of, do you have another idea of how this could be done?

As for negative indication, I think we need to define a new socket
option which indicates a request from application that it does not want
its flow get shimmed.  It seems to me that we may also need a mechanism
for "positive indication" which allows application to proactively
request particular flow get shimmed.  But I am not sure how this should
be realized.  One option would be to specify default behavior of source
of the shim node in terms of activating shim for particular flow.  Note
that this is different from the source address selection issue.  Another
option would be to define a new socket option (something like IPV6_SHIM)
which can be used for positive indication provided by the application
layer requesting for shim support for its flow.  Another approach would
be to let application make decision through proactive source address
selection.  If this is the case, system should specify which IPv6
address can be used for ULID.  This is rather similar to the case of
MIPv6 in which permanent identifier (=HoA) is given by the system.
Then the issue (how app can activate/deactivate shim6) can be simplified.
It's up to source address selection (RFC3484 + bis).

Well, my personal view on concept of ULID may be different from others,
I appreciate if you could hear your thoughts on this.

Regards,
Shinta

Delivery-date: Wed, 02 Nov 2005 07:45:22 +0000
Date: Wed, 2 Nov 2005 07:43:51 +0000 (GMT)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], shim6-wg <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Second shim
Mail-Copies-To: [email-masked]

On Mon, 31 Oct 2005, Erik Nordmark wrote:

> Thinking about a second shim to handle connection establishment, I've come up 
> with code (not running yet ;-) to do a

> 	int connect_by_name(char *hostname, int port);

> that can be implemented entirely as a library (using non-blocking 
> connect() calls). It returns a socket file descriptor.

Nice.

> For by connect_by_name() and the connect() hackery, this only 
> applies to TCP; can't make it apply to UDP since UDP doesn't have a 
> notion of "I succeeded using this IP address".

You could go the whole hog and provide "second shim" 
read/write/send{,to,msg} style calls too, and shim failures on the 
fly. Might also be a good way to protype any shim control protocol.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Before you ask more questions, think about whether you really want to
know the answers.
 		-- Gene Wolfe, "The Claw of the Conciliator"

Delivery-date: Tue, 01 Nov 2005 17:08:06 +0000
Date: Tue, 01 Nov 2005 19:05:24 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Spencer Dawkins <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection

Bernard Aboba wrote:

>The "green light" is carrier sense.  While loss of carrier 
>sense can be handled immediately on wired networks, it would not be wise 
>to treat it the same way on a wireless network.
>  
>
Yes, some damping process is needed.

(But I believe the action depends also a little bit on the kind
of network we are talking about, and what specific green
light we are referring to. E.g. you know that your access
auth state is not where what it should be, you can't get
a PDP context or the network told you to go away vs. just
not hearing the other end.)

>>But for the rest, we can only do operations that are relatively
>>slow. My view of what's achievable is somewhere between
>>RTO and the time TCP gives up. Interestingly, on this timescale
>>TCP has probably already slowed down.
>>    
>>
>
>Right.  In RFC 3539, this is characterized as somewhere between two 
>and four retransmissions.  Assuming RTO = RTOmin (1 second), this yields a 
>timer between 7 seconds (1 + 2 + 4) and 31 seconds (1 + 2 + 4 + 8 + 16).
>  
>
Right.

>However, this assumes that the protocol is not running over wireless WAN 
>links such as GPRS.  In such a situation, 7 seconds might only be time for 
>a single retransmission.  
>  
>
I'm getting sidetracked from the initial issue, but it may
be interesting to note that cellular network RTTs have
been decreasing and continue decrease substantially
from the initial GPRS deployments. If I remember correctly
modern network type and proper equipment gets you
in the 100ms range. YMMV though.

--Jari

Delivery-date: Tue, 01 Nov 2005 16:15:54 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "shim6" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection
Date: Tue, 1 Nov 2005 10:15:05 -0600

>>The application layer does have the ability to diagnose connectivity 
>>problems on the order of seconds, through keep-alives.   The IP layer 
>>generally does not have the ability to detect whether a connection is 
>>"satisfactory" since it does not have access to the TCB, only
>>knowledge of potential causes of connectivity problems (such as path 
>>changes or missing routes), which it can provide to the transport layer or 
>>to applications.
>>
> We do have direct information in some cases, see above.
> But in general... I think we should stay away from
> trying to defining "satisfactory", and simply work on
> a binary model where there's either connectivity or
> there isn't.

Ack. At the interim, Geoff spoke pretty eloquently about how 
multi-dimensional "satisfactory" can be in the general case, which includes 
usage-sensitive billing, satellite links, lossy cellular links, etc. If all 
your users are flat-rate customers on fixed broadband connections and only 
access other hosts on the same continent, it's easier, but that's not the 
general case...

Spencer 

Delivery-date: Tue, 01 Nov 2005 16:08:01 +0000
Date: Tue, 01 Nov 2005 18:05:05 +0200
From: Jari Arkko <[email-masked]>
To: Spencer Dawkins <[email-masked]>,  Bernard Aboba <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection

>I would therefore argue that the important issue is not action
>in multiple layers, but rather the avoidance of race conditions;  a 
>well-defined communication mechanism between the IP and 
>transport/application
>layer can help with this.
>  
>
Hmm. Yes. "Link Up" ... "Link Temporary Problem" (here shim
is exploring for other alternatives)... "Link Up"...

>   But it is less clear which protocol(s) should discover end-to-end
>   connectivity problems or recover from them.  One answer is that this
>   is clearly within the domain of multihoming protocol.  By performing
>   testing and failure detection of the used path and switching to a new
>   path if necessary, the transport and application protocols can work
>   unchanged.
>
>I am not clear that the "multi-homing protocol" necessarily has the right
>information to do testing and failure detection correctly. 
>
>For example, it does not make sense to diagnose a "connectivity problem" 
>on a time scale less than RTO.
>  
>
Yes, very small timescales would indeed be problematic.
Having said that a lot of the discussion around this is
centered around the path failures. I see path failure recovery
as a necessary component, but I would argue that local
failures (such as the little green light in the interface
card going blank) are likely to be more common. They are also
treated in a very different way. You KNOW you have a
problem and often have a good idea also about what other
things might be working (e.g., the interface whose green
light is still on). In local failures, even sub-second time
scale is achievable (depending on, of course, how fast
the green light reacts).

But for the rest, we can only do operations that are relatively
slow. My view of what's achievable is somewhere between
RTO and the time TCP gives up. Interestingly, on this timescale
TCP has probably already slowed down.

>   One can also envision that applications would be able to tell the IP
>   or transport layer that the current connection is unsatisfactory and
>   an exploration for a better one would be desirable.  This would
>   require an API to be developed, however.
>
>The application layer does have the ability to diagnose connectivity 
>problems on the order of seconds, through keep-alives.   The IP layer 
>generally does not have the ability to detect whether a connection is 
>"satisfactory" since it does not have access to the TCB, only
>knowledge of potential causes of connectivity problems (such as path 
>changes or missing routes), which it can provide to the transport layer 
>or to applications.
>
We do have direct information in some cases, see above.
But in general... I think we should stay away from
trying to defining "satisfactory", and simply work on
a binary model where there's either connectivity or
there isn't.

--Jari