Subject: I-D ACTION:draft-ietf-shim6-proto-05.txt
From: Geoff Huston <[email-masked]>
To: [email-masked]
Date: Fri, 26 May 2006 06:04:15 +1000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Level 3 multihoming shim protocol
         Author(s)       : M. Bagnulo, E. Nordmark
         Filename        : draft-ietf-shim6-proto-05.txt
         Pages           : 123
         Date            : 2006-5-25

The SHIM6 protocol is a layer 3 shim for providing locator agility
    below the transport protocols, so that multihoming can be provided
    for IPv6 with failover and load sharing properties, without assuming
    that a multihomed site will have a provider independent IPv6 address
    prefix which is announced in the global IPv6 routing table.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-proto-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Fri, 19 May 2006 13:28:12 +0000
Date: Fri, 19 May 2006 16:28:04 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC:  [email-masked]
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Hi John and many thanks for your review. I'm finally
getting to updating the failure detection document.

Please find below some further discussion
where it was warranted. For the rest I have simply
adopted your suggestions.

>2) Intro says:
>
>   This draft defines the mechanism and protocol to achieve both failure
>   detection and locator pair exploration.  This protocol is called
>   REAchability Protocol (REAP).  It designed to be carried within the
>   SHIM6 protocol, but may also be used in other contexts.
>
>I think we should drop the '... may be used in other contexts.' as this
>seems
>outside of the scope of SHIM6. I don't think that SHIM6 should work on a
>general
>purpose failure detection & path exploration protocol.  
>  
>
We have tried to scope the document to Shim6 and only
Shim6, although some earlier versions had more ambitious
goals. I'll remove the text that you quote above and see
if there are any other similar cases later in the next.

This narrow scope is necessary for us to complete the
work. (Neverthless, its been my hope that we can use
the same protocol later in, e.g., HIP, because the protocol
number and basic format between SHIM6 are already
very close to each other. However, there are non-trivial
issues in extending it. For instance, while its easy to
add IPv4 support, adding NAT support may not be all
that easy -- in MOBIKE for instance this was the hardest
part.)

>   ...  We assume that there are other, higher
>   level identifiers such as CGA public keys or HBA bindings that tie
>   the different locators used by a node together [17].
>
>Do we need to care about higher level identifiers for REAP?  My guess is
>that
>is something that should really matter for REAP, so that suggesting CGA
>or HBA
>would be something of relelvance for REAP is misleading.
>  
>
Specific techniques for identification should be removed from this
document.

>I also wonder if a blanket statement along the lines of "Many protocols,
>both
>standardized in the IETF and outside of the IETF make use of keep-alives
>to
>trVack the live-ness of a connection or session."  Also, you might want
>to consider
>RSVP also, as RSVP does track path conditions at the raw IP level.  I
>can supply
>text if needed.
>  
>
I like the blanket statement. Perhaps no need to say anything about
RSVP then.

>	
>5.3.  Exploration Order
>
>   The exploration process assumes an ability to pick current and
>   alternative address pairs.  
>
>The above sentence doesn't parse ... do you mean "... and use an 
>alternative address pair."?
>  
>
I see the problem. How about "... assumes an ability to pick a sequence
of alternative address pairs to try in order."?

>Section 5.3:
>
>   Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
>   what combinations of addresses are allowed from a local point of
>   view, as this reduces the search space. 
>
>RFC 3484 is "default address selection"; I would hesitate to make this
>a MUST.  I would say that 3484 is the default mechanism for REAP, but
>surely nodes can have an optimized algorithm?
>  
>
Yes they should be able to. A SHOULD seems more appropriate.

>Section 5.3:
>
>   One suggested good implementation strategy is to record the
>   reachability test result (an on/off value) and multiply this by the
>   age of the information.  This allows recently tested address pairs to
>   be chosen before old ones.
>
>This suggestion confuses me.  If reachable = 1 and unreachable = 0;
>multiplying
>it by the age of the information, I guess we'd like to choose the lowest
>non-zero
>value ... but I suggest deleting this text, unless you want to make a
>more formal
>algorithm for this action.
>  
>
I'd rather delete this text, and replace it with something that
suggests the age of previously acquired information should be
taken into account.

>Section 5.3:
>
>   Out of the set of possible candidate address pairs, nodes SHOULD
>   attempt a test through all of them until a working pair is found, and
>   retrying the process as is necessary.  However, all nodes MUST
>   perform this process sequentially and with exponential back-off.
>   This sequential process is necessary in order to avoid a "signaling
>   storm" when an outage occurs (particularly for a complete site).
>   However, it also limits the number of addresses that can in practice
>   be used for multihoming, considering that transport and application
>   layer protocols will fail if the switch to a new address pair takes
>   too long.
>
>I know you are describing a general procedure, but I think this protocol
>needs
>some suggest timer values, etc.  'as is ncessary' isn't sufficient.  If
>you 
>define timers elsewhere, then put a forward reference to the section,
>please.
>  
>
Yes -- the need for timers has been brough up by others as well.
They will be included.

>Section 5.4
>
>   REAP is designed as a modular part of SHIM6 in the hopes that it may
>   also be useful in other contexts. 
>
>This sentence doesn't make sense - you designed it to be a modular part
>of SHIM6
>so that it might be useful in other contexts?  I think you mean it is
>not included
>in the base shim6, but as a stand-alone, modular protocol as it may have
>potential
>uses for other protocols ....
>  
>
This will be removed.

>7. Security Considerations
>
>I think you should say that REAP SHOULD NOT rely on unverified "various
>indications from 
>lower layers" etc. to determine connectivity or failure, as they may be
>spoofed.
>  
>
Ok.

>General comment - lots of text in the document is somewhat speculative,
>esp. the use
>of REAP in other scenarios.  I'd probably tighten-up this language.
>Designing the
>protocol to a modular piece of SHIM6 is a good idea, but speculating
>that it could
>be used elsewhere seems inappropriate.
>
Right. This will be done in -04.

>4) Generally, I could quibble with some text in section 4 - if the
>authors feel
>quibbling is valuable, I could send text. 
>
I believe it would be valuable. Please send text.

--Jari

Delivery-date: Thu, 11 May 2006 17:00:32 +0000
Date: Thu, 11 May 2006 09:59:21 -0700
From: Erik Nordmark <[email-masked]>
To: Steven Blake <[email-masked]>
CC: [email-masked]
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01

Steven Blake wrote:
> On Tue, 2006-05-09 at 17:12 -0700, Erik Nordmark wrote:
> 
>> That type of leap-of-faith has a problem with address ownership (and
>> isn't very secure as you state). The ownership problem is as follows:
>>   - Alice arrives on the IETF terminal room. Is assigned IPv6 address
>> IP1. Alice communicates with www.example.com and conveys her secret.
>> www.example.com binds that secret to her current IP address. This means 
>> that Alice can move and signal www.example.com her new IP address using 
>> this secret.
>>
>>   - Alice leaves the IETF terminal room, her DHCP lease expires, but she 
>> continues to communicate with www.example.com (which maintains the 
>> secret they setup)
>>
>>   - Bob arrives in the IETF termincal room. The DHCP server gives him 
>> the IP address IP1. Bob tries to communicate with www.example.com. One 
> 
> With 62 bits of usable IID, this is a problem that is trivially easy to
> avoid.

I agree that HBA and CGA avoids it.

My comment was in response to the comment to "just use IPsec and it 
solves all your problems" that ekr made.

We do need CGA/HBA to solve address ownership issues.

    Erik

Delivery-date: Wed, 10 May 2006 06:51:46 +0000
Cc: [email-masked], Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01
Date: Wed, 10 May 2006 09:50:23 +0300
To: Steven Blake <[email-masked]>

Hi Steven,

El 10/05/2006, a las 4:44, Steven Blake escribi=F3:

> On Tue, 2006-05-09 at 17:12 -0700, Erik Nordmark wrote:
>
>> That type of leap-of-faith has a problem with address ownership (and
>> isn't very secure as you state). The ownership problem is as follows:
>>   - Alice arrives on the IETF terminal room. Is assigned IPv6 address
>> IP1. Alice communicates with www.example.com and conveys her secret.
>> www.example.com binds that secret to her current IP address. This=20
>> means
>> that Alice can move and signal www.example.com her new IP address=20
>> using
>> this secret.
>>
>>   - Alice leaves the IETF terminal room, her DHCP lease expires, but=20=

>> she
>> continues to communicate with www.example.com (which maintains the
>> secret they setup)
>>
>>   - Bob arrives in the IETF termincal room. The DHCP server gives him
>> the IP address IP1. Bob tries to communicate with www.example.com. =
One
>
> With 62 bits of usable IID, this is a problem that is trivially easy =
to
> avoid.
>

may agree with that, but Erik example was about a "casual" situation=20
where Bob is not actually trying to attack Alice, it just happens to=20
get the same address than her.

However, you may think of other situations where the attacker finds out=20=

the address of both communicating peers and activelly tries to interfer=20=

with the ongoing communication using such vulnerabilities....

regards, marcelo

>
> Regards,
>
> // Steve
>
>

Delivery-date: Wed, 10 May 2006 01:44:59 +0000
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01
From: Steven Blake <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: [email-masked]
Date: Tue, 09 May 2006 21:44:20 -0400

On Tue, 2006-05-09 at 17:12 -0700, Erik Nordmark wrote:

> That type of leap-of-faith has a problem with address ownership (and
> isn't very secure as you state). The ownership problem is as follows:
>   - Alice arrives on the IETF terminal room. Is assigned IPv6 address
> IP1. Alice communicates with www.example.com and conveys her secret.
> www.example.com binds that secret to her current IP address. This means 
> that Alice can move and signal www.example.com her new IP address using 
> this secret.
> 
>   - Alice leaves the IETF terminal room, her DHCP lease expires, but she 
> continues to communicate with www.example.com (which maintains the 
> secret they setup)
> 
>   - Bob arrives in the IETF termincal room. The DHCP server gives him 
> the IP address IP1. Bob tries to communicate with www.example.com. One 

With 62 bits of usable IID, this is a problem that is trivially easy to
avoid.

Regards,

// Steve

Delivery-date: Wed, 10 May 2006 01:11:44 +0000
Date: Wed, 10 May 2006 11:10:55 +1000
To: Erik Nordmark <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01
Cc: [email-masked], marcelo bagnulo braun <[email-masked]>, kurt Erik Lindqvist <[email-masked]>

While these comments were forwarded to me only recently by Jari (as AD), I 
believe that the secdir conversation quoted here dates back to late 
November 2005. [As WG chair I was not privy to that interchange, nor did I 
get a copy at the time]

   regards,

    Geoff

At 10:12 AM 10/05/2006, Erik Nordmark wrote:
>Geoff Huston wrote:
>
>>So are there any WG comments related to this security directorate review 
>>please?
>
>Sure.
>
>Will you feed these comments back?
>
>BTW: How old is the secdir review? I had some exchanges with some of the 
>folks around MOBIKE and address ownership fairly recently, and I don't 
>know if this review was done before or after that.
>
>>---------------------------------
>>
>>
>>
>>From: Eric Rescorla <[email-masked]>
>
>
>>It's also worth noting that if you're using IPsec, you have a lot of
>>other options that are even better.
>
>Such as? (I didn't think we used IPsec pixie dust arguments any more ;-)
>
>In order use IPsec to get any better security there would have to be a
>secure binding between a secret (e.g., a certificate) and the IPv6
>address; this is the "address ownership" problem. Only the owner of the
>IPv6 address should be authorized to determine to what locators packets
>destined to that address should be sent.
>
>The only way I know to securely solve this is to have a PKI where the
>subject names are IP addresses or IP address prefixes, and where the
>hierarchy in the PKI matches the address allocation hierarchy from the
>root down to every host. (Of course, when a host gets a new IP address
>it would need a new cert for this purpose.)
>
>MOBIKE didn't try to come up with a general solution to this. BTNS AFAIK
>is trying to avoid the problem using channel bindings, but that requires
>some care and timers to avoid a host previously using an IP address
>preventing the new "owner" of that IP address from using IPsec to
>communicate with a particular IP peer. That can certainly be done if you
>assume that the host be reachable at its IP address all the time.
>Unfortunately that assumption doesn't hold in the case of multihoming.
>
>So I honestly don't see a deployable solution that doesn't depend on
>placing a hash in part of the IPv6 address. [Today this means CGA/HBA for 
>shim6, since we use a routable IP address as the ULID. But in the future 
>we can have non-routable ULIDs so the hash can approach 128 bits. 
>Essentially the protection against redirection threats can be isomorphic 
>between SHIM6 and HIP. But going beyond 128 bits would require redefining 
>TCP, UDP etc to operate with larger connection identifiers and redefining 
>the socket API to do likewise.]
>
>
>>------------------------------------------------------------------------------ 
>>
>>From: Sam Hartman <[email-masked]>
>>
>>4) You don't want on-path attackers to be able to influence traffic
>>    such that it goes to them and not the original destination.
>>    I.E. if I'm on the path and also have some tunnel address you
>>    woludn't see I should not be able to redirect your traffic to my
>>    tunnel and thus capture it.
>
>RFC 4218 doesn't state that as a requirement.
>
>In general, on path attackers can use other means to funnel the packets
>somewhere else.
>
>>So, you don't start out with a secret.  You can trivially have a
>>secret from off-path attackers simply by sending the secret over the
>>connection.  (I hesitate to call that a secret, but it would at least
>>be a quantity unknown by people off-path).
>
>That type of leap-of-faith has a problem with address ownership (and
>isn't very secure as you state). The ownership problem is as follows:
>  - Alice arrives on the IETF terminal room. Is assigned IPv6 address
>IP1. Alice communicates with www.example.com and conveys her secret.
>www.example.com binds that secret to her current IP address. This means 
>that Alice can move and signal www.example.com her new IP address using 
>this secret.
>
>  - Alice leaves the IETF terminal room, her DHCP lease expires, but she 
> continues to communicate with www.example.com (which maintains the secret 
> they setup)
>
>  - Bob arrives in the IETF termincal room. The DHCP server gives him the 
> IP address IP1. Bob tries to communicate with www.example.com. One of 
> several things can happen depending on the details of a leap-of-faith 
> multihoming proposal, but all of them result in failure for Bob to communicate:
>         - www.example.com drops Bob's packets, since it knows that that 
> IP address has been relocated to Alice's new IP address.
>         - www.example.com sends the responses to Bob's packets (the 
> SYN|ACK) to Alice since it knows that's the new location
>         - Bob tries to use the leap-of-faith multihoming mechanism to 
> establish his secret with www.example.com, and the latter rejects this as 
> an attacker trying to steal the address associated with Alice's secret.
>
>>_______________________________________________
>>From: Jari Arkko <[email-masked]>
>
>>I guess the main question is "what association". In
>>situations where we have actual managed security
>>relationship, such as in VPNs, we already have IKEv2
>>and MOBIKE which do more or less the same function
>>as SHIM6 does, so there's really no need for additional
>>support in IPv6 for this purpose.
>
>But MOBIKE as specified has no solution to the general issue of address 
>ownership. Thus it only works for VPNs and where there is a separate 
>mechanism to authenticate the users before letting them join the VPN.
>
>>However, this is not
>>the only scenario people have. SHIM6 targets more
>>general Internet usage which does not assume managed
>>security between corresponding hosts. But I think
>>we agree on this, the question is on how to achieve
>>it. The possibilities that come to my mind are
>>  - HBAs
>>  - CGAs
>>  - BTNS
>
>FWIW I don't understand how the BTNS channel binding can avoid the 
>ownership problem. Unless I've very confused, all the channel bindings do 
>is transform the "IP address ownership" problem into the "IP,protocol,port 
>ownership" problem. At best this makes it 64,000 times harder for an 
>attacker to completely shut off an IP address for use by somebody else.
>
>>SHIM6 is taking the approach which uses HBAs or optionally
>>CGAs. Another possible option would have been to use only
>>CGAs. I believe the discussions that led to doing HBA related
>>to computational cost, and IPRs. However, I'm personally
>>not very convinced about the computational cost problem.
>
>I agree that computational cost and IPR where the issues that were brought 
>up and that are viewed as differences between HBA and CGA.
>
>>For one thing, I think you only need to do the computations
>>IF you actually end up having a connectivity problem and
>>have to switch the address.
>
>That isn't the only case (and for simplicity the shim6 specification says 
>to do it immediately when the locator set is received).
>If a locator set has been received during the context establishment, and 
>later a different locator set arrives in an Update message, then the host 
>presumably needs to defend itself against one or the other locator set 
>being spoofed. Perhaps this is something we can gain more experience with 
>over time.
>
>>BTNS would be the other option. However, while
>>I think BTNS does a good job in the channel binding
>>case I'm much less convinced that we know what it
>>should or could do in other cases. In fact, I do not
>>currently see how to make it work for something like
>>what SHIM6 wants to do. Maybe we can make it work,
>>but its really not there today. Getting it done would
>>be very useful, though, particularly if BTNS+MOBIKE would
>>give us SHIM6-like functionality but have it also work for v4
>>and over NATs...
>
>I don't see how this can solve the address ownership issue.
>
>
>
>>---------------------------------------------
>>From: Eric Rescorla <[email-masked]>
>
>>Well, I think I disagree here on philosophical grounds.
>>I prefer to avoid inventing new mechanisms--especially ones
>>of new styles--when that can be avoided. The standard primitives
>>we have for integrity are MACs with shared keys and digital
>>signatures with known public keys. Why invent something new.
>>-Ekr
>
>For public keys and a PKI to be useful to prevent IP address redirection 
>threats, the identities which the PKI uses MUST be IP addresses.
>Thus the current deployment for securing applications using identities 
>that make sense to applications (such as mbox:[email-masked]) do 
>not help for IP address redirection threats.
>
>    Erik
>
>

Delivery-date: Wed, 10 May 2006 00:37:58 +0000
Date: Tue, 09 May 2006 17:37:06 -0700
From: Erik Nordmark <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: two shim6-esd-00 comments

Pekka Savola wrote:
> Hi,
> 
> Two smaller comments, probably already made, on 
> draft-nordmark-shim6-esd-00.txt:

Thanks for the comments. I'll make sure to include some more text about 
this in 01.

> 1) this obviously requires control over the reverse tree, which is by no 
> means given for generic shim6 audience, though it might be more popular 
> with sites which want to employ rewriting.
> 
>       The shim performs the identifier to locator lookup very similarly
>       to normal IPv6 reverse lookups (form a query name based on the
>       nibbles in reverse order and append ip6.arpa), but it queries for
>       SRV records.

Yes, but an important point is that it requires control of the reverse 
tree for the identifier and not for the locators.
Thus the site can get there locators from ISPs without any control of 
the DNS for those, and get their identifier from a separate entity which 
delegates IP identities. The identity prefix wouldn't be useful without 
giving out the delegation for their part of the deal.

> 2) In the latter part of the example below, AFAICS, are you able to use 
> the Sent Locator immediately?  This could be part of a 3rd party 
> [bombing] attack?  Does it need to be probed first or is this 
> sufficiently secure as it is?
>
>       B processes the I1 message as specified in [7] to generate a R1
>       message.  In addition, it copies the content of the Sent Locator
>       Pair option into a Received Locator Pair option.  Host B must
>       decide whether it should send the R1 message to the IP source
>       address of the R1 message, or send it to the potentially different
>       Sender Locator in the Sent Locator Pair option in the I1 message.
>       Once B has made this decision, it puts the addresses, in this
>       example <B1, A2> in the IPv6 header as well as into a Sent Locator
>       Pair option.

Using the Sent Locator option for the R1 reply would open up a 
reflection attack as you point out. Assuming ingress filtering will 
continue to be used, it would be safer to send the R1 to the source of 
the I1.

    Erik

Delivery-date: Wed, 10 May 2006 00:14:46 +0000
Date: Tue, 09 May 2006 17:12:12 -0700
From: Erik Nordmark <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: [email-masked], marcelo bagnulo braun <[email-masked]>, kurt Erik Lindqvist <[email-masked]>
Subject: Re: [secdir]Comments on draft-ietf-shim6-hba-01

Geoff Huston wrote:

> So are there any WG comments related to this security directorate review 
> please?

Sure.

Will you feed these comments back?

BTW: How old is the secdir review? I had some exchanges with some of the 
folks around MOBIKE and address ownership fairly recently, and I don't 
know if this review was done before or after that.

> ---------------------------------
> 
> 
> 
> 
> 
> 
> From: Eric Rescorla <[email-masked]> 

> It's also worth noting that if you're using IPsec, you have a lot of
> other options that are even better.

Such as? (I didn't think we used IPsec pixie dust arguments any more ;-)

In order use IPsec to get any better security there would have to be a
secure binding between a secret (e.g., a certificate) and the IPv6
address; this is the "address ownership" problem. Only the owner of the
IPv6 address should be authorized to determine to what locators packets
destined to that address should be sent.

The only way I know to securely solve this is to have a PKI where the
subject names are IP addresses or IP address prefixes, and where the
hierarchy in the PKI matches the address allocation hierarchy from the
root down to every host. (Of course, when a host gets a new IP address
it would need a new cert for this purpose.)

MOBIKE didn't try to come up with a general solution to this. BTNS AFAIK
is trying to avoid the problem using channel bindings, but that requires
some care and timers to avoid a host previously using an IP address
preventing the new "owner" of that IP address from using IPsec to
communicate with a particular IP peer. That can certainly be done if you
assume that the host be reachable at its IP address all the time.
Unfortunately that assumption doesn't hold in the case of multihoming.

So I honestly don't see a deployable solution that doesn't depend on
placing a hash in part of the IPv6 address. [Today this means CGA/HBA 
for shim6, since we use a routable IP address as the ULID. But in the 
future we can have non-routable ULIDs so the hash can approach 128 bits. 
Essentially the protection against redirection threats can be isomorphic 
between SHIM6 and HIP. But going beyond 128 bits would require 
redefining TCP, UDP etc to operate with larger connection identifiers 
and redefining the socket API to do likewise.]

> ------------------------------------------------------------------------------ 
> 
> 
> From: Sam Hartman <[email-masked]>
>
> 4) You don't want on-path attackers to be able to influence traffic
>    such that it goes to them and not the original destination.
>    I.E. if I'm on the path and also have some tunnel address you
>    woludn't see I should not be able to redirect your traffic to my
>    tunnel and thus capture it.

RFC 4218 doesn't state that as a requirement.

In general, on path attackers can use other means to funnel the packets
somewhere else.

> So, you don't start out with a secret.  You can trivially have a
> secret from off-path attackers simply by sending the secret over the
> connection.  (I hesitate to call that a secret, but it would at least
> be a quantity unknown by people off-path).

That type of leap-of-faith has a problem with address ownership (and
isn't very secure as you state). The ownership problem is as follows:
  - Alice arrives on the IETF terminal room. Is assigned IPv6 address
IP1. Alice communicates with www.example.com and conveys her secret.
www.example.com binds that secret to her current IP address. This means 
that Alice can move and signal www.example.com her new IP address using 
this secret.

  - Alice leaves the IETF terminal room, her DHCP lease expires, but she 
continues to communicate with www.example.com (which maintains the 
secret they setup)

  - Bob arrives in the IETF termincal room. The DHCP server gives him 
the IP address IP1. Bob tries to communicate with www.example.com. One 
of several things can happen depending on the details of a leap-of-faith 
multihoming proposal, but all of them result in failure for Bob to 
communicate:
	- www.example.com drops Bob's packets, since it knows that that IP 
address has been relocated to Alice's new IP address.
	- www.example.com sends the responses to Bob's packets (the SYN|ACK) to 
Alice since it knows that's the new location
	- Bob tries to use the leap-of-faith multihoming mechanism to establish 
his secret with www.example.com, and the latter rejects this as an 
attacker trying to steal the address associated with Alice's secret.

> _______________________________________________
> 
> From: Jari Arkko <[email-masked]>

> I guess the main question is "what association". In
> situations where we have actual managed security
> relationship, such as in VPNs, we already have IKEv2
> and MOBIKE which do more or less the same function
> as SHIM6 does, so there's really no need for additional
> support in IPv6 for this purpose. 

But MOBIKE as specified has no solution to the general issue of address 
ownership. Thus it only works for VPNs and where there is a separate 
mechanism to authenticate the users before letting them join the VPN.

> However, this is not
> the only scenario people have. SHIM6 targets more
> general Internet usage which does not assume managed
> security between corresponding hosts. But I think
> we agree on this, the question is on how to achieve
> it. The possibilities that come to my mind are
> 
>  - HBAs
>  - CGAs
>  - BTNS

FWIW I don't understand how the BTNS channel binding can avoid the 
ownership problem. Unless I've very confused, all the channel bindings 
do is transform the "IP address ownership" problem into the 
"IP,protocol,port ownership" problem. At best this makes it 64,000 times 
harder for an attacker to completely shut off an IP address for use by 
somebody else.

> SHIM6 is taking the approach which uses HBAs or optionally
> CGAs. Another possible option would have been to use only
> CGAs. I believe the discussions that led to doing HBA related
> to computational cost, and IPRs. However, I'm personally
> not very convinced about the computational cost problem.

I agree that computational cost and IPR where the issues that were 
brought up and that are viewed as differences between HBA and CGA.

> For one thing, I think you only need to do the computations
> IF you actually end up having a connectivity problem and
> have to switch the address.

That isn't the only case (and for simplicity the shim6 specification 
says to do it immediately when the locator set is received).
If a locator set has been received during the context establishment, and 
later a different locator set arrives in an Update message, then the 
host presumably needs to defend itself against one or the other locator 
set being spoofed. Perhaps this is something we can gain more experience 
with over time.

> BTNS would be the other option. However, while
> I think BTNS does a good job in the channel binding
> case I'm much less convinced that we know what it
> should or could do in other cases. In fact, I do not
> currently see how to make it work for something like
> what SHIM6 wants to do. Maybe we can make it work,
> but its really not there today. Getting it done would
> be very useful, though, particularly if BTNS+MOBIKE would
> give us SHIM6-like functionality but have it also work for v4
> and over NATs...

I don't see how this can solve the address ownership issue.

> ---------------------------------------------
> 
> From: Eric Rescorla <[email-masked]>

> Well, I think I disagree here on philosophical grounds.
> I prefer to avoid inventing new mechanisms--especially ones
> of new styles--when that can be avoided. The standard primitives
> we have for integrity are MACs with shared keys and digital
> signatures with known public keys. Why invent something new.
> 
> -Ekr

For public keys and a PKI to be useful to prevent IP address redirection 
threats, the identities which the PKI uses MUST be IP addresses.
Thus the current deployment for securing applications using identities 
that make sense to applications (such as mbox:[email-masked]) do 
not help for IP address redirection threats.

    Erik

Delivery-date: Tue, 09 May 2006 07:22:34 +0000
Cc: Pekka Savola <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE
Date: Tue, 9 May 2006 10:22:41 +0300
To: Erik Nordmark <[email-masked]>

El 09/05/2006, a las 1:42, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> unless remote resolvers explicitly query for the SRV records, and=20
>> they use that information to order the list of addresses returned to=20=

>> the app, in which case this works and does not require upgrading the=20=

>> app to query for SRV records. In this case, there is no kludgery=20
>> AFAICT and it seems to work fine and be easier to deploy. imho this=20=

>> may be useful if we go to the path of using the DNS to express=20
>> preferences about locators for incoming communications
>
> *If* we go with SRV records at names like _shim6._ip.FQDN, then the=20
> applications don't have to be modified; the getaddrinfo()=20
> implementation (often implemented in a  resolver library) can handle=20=

> this transparent to the application.
>

agree
this is what i understand Pekka was arguing for...

regards, marcelo

>    Erik
>
>

Delivery-date: Tue, 09 May 2006 07:21:50 +0000
Cc: Marshall Eubanks <[email-masked]>, [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)
Date: Tue, 9 May 2006 10:20:43 +0300
To: Erik Nordmark <[email-masked]>

El 09/05/2006, a las 2:35, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> I can think of two possible approaches at this point:
>> 1) Whenever a host inside the soho network wants to establish a new=20=

>> communication with a given server S, it establishes a shim6 context=20=

>> with the proxy. For that shim6 context the ulid pair is:=20
>> PrefC:1:hostC and IPS and the locator set will be: for=20
>> Ls(PrefC:1:hostC) =3D (PrefA:hostC, PrefB:hostC) and Ls(IPS)=3D=20
>> (PrefC:proxy). the drawback of this approach is that we loose the=20
>> deferred setup capability, which imposes a penalty in terms of setup=20=

>> latency and by default shim6 would be used for all the communications=20=

>> (we could think of some heuristics about for which communication to=20=

>> use the shim6 and for which ones don't use it, but this would impact=20=

>> on which ulid use...)
>> 2) an alternative approach would be to create a shim6 protected=20
>> tunnel between the host in the soho network and the shim proxy. In=20
>> its simplest form, it would be a tunnel interface between the host in=20=

>> the soho network and the proxy and this interface would be used as a=20=

>> default route. The tunnel would then protected by the shim6 protocol=20=

>> and fault tolerance features would be available for that path. This=20=

>> does not impose additional latency because the tunnel/shim6 context=20=

>> would be established at bootstrap and only one tunnel/shim6 context=20=

>> is needed to support all the communications. The drawback is that we=20=

>> have the tunnel header overhead, but maybe it would be possible to=20
>> remove this using some sort of nested shim (not sure if this last=20
>> stuff would work...) The features provided by the shim in this case=20=

>> would be an secure automatic tunnel setup mechanism with fault=20
>> tolerance protection, which may be good enough justification.
>> I think this second approach is the one that is more attractive...
>
> Couldn't one do #2 today using IP-in-IP tunneling and some liveness=20
> test  protocol (ICMP echo?) for the tunnels, without any shim6?
>
> As I understand it in #2 the ULID is really an IP address assigned to=20=

> the host by the proxy provider, which gets tunneled to/from the IP=20
> addresses assigned to host by the "physical" providers.
>

right

as i see it, the shim6 protocol in this case would be used to:
- dynamicaly create the tunnels, so that the big ISP that is hosting=20
the proxy does not need to make manual configuration. note that even if=20=

a mechanism like a tunnel broker is used, you still need to make some=20
checks about the alternative addresses and so on that are configured.=20
This would be like a fully automatic secure mechanism to establish such=20=

tunnel
- failure detection and alternative path exploration. The mechanism for=20=

failure detection developed by shim have the possibility to eficiently=20=

explore alternative paths and deal with unidirectional connectivity.=20
BEsides, since the context establishment and the failure detection=20
paths use the same protocol number you are sure that if you can=20
establish the context, then your failure detection path exploration=20
packets won't get filtered (as oposed to the ICMP case)

BEsides, maybe it would be possible to define some form of nested shim,=20=

where we don't need to include both IP headers of the tunnel in this=20
case. I mean, after all a tunnel is an address mapping as performed by=20=

the shim, so it may be possible to optimize the shim for this case, so=20=

we can provide some additional eficiency for this case.

In any case, i agree that this case is much more simpler than the=20
general case for which the shim6 was designed for, and it wouldn't make=20=

sense to have the whole shim protocol just to provide this feature,=20
however i think this may be a good deployment tool, allowing small end=20=

sites to benefit from the shim while the servers don't have support for=20=

the shim protocol...

regards, marcelo

>    Erik
>

Delivery-date: Mon, 08 May 2006 23:47:33 +0000
Date: Mon, 08 May 2006 16:35:13 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Marshall Eubanks <[email-masked]>, [email-masked], Brian E Carpenter <[email-masked]>, Scott Leibrand <[email-masked]>
Subject: Re: What's our target audience? (Was: Re: Shim6 proxies)

marcelo bagnulo braun wrote:

> I can think of two possible approaches at this point:
> 
> 1) Whenever a host inside the soho network wants to establish a new 
> communication with a given server S, it establishes a shim6 context with 
> the proxy. For that shim6 context the ulid pair is: PrefC:1:hostC and 
> IPS and the locator set will be: for Ls(PrefC:1:hostC) = (PrefA:hostC, 
> PrefB:hostC) and Ls(IPS)= (PrefC:proxy). the drawback of this approach 
> is that we loose the deferred setup capability, which imposes a penalty 
> in terms of setup latency and by default shim6 would be used for all the 
> communications (we could think of some heuristics about for which 
> communication to use the shim6 and for which ones don't use it, but this 
> would impact on which ulid use...)
> 
> 2) an alternative approach would be to create a shim6 protected tunnel 
> between the host in the soho network and the shim proxy. In its simplest 
> form, it would be a tunnel interface between the host in the soho 
> network and the proxy and this interface would be used as a default 
> route. The tunnel would then protected by the shim6 protocol and fault 
> tolerance features would be available for that path. This does not 
> impose additional latency because the tunnel/shim6 context would be 
> established at bootstrap and only one tunnel/shim6 context is needed to 
> support all the communications. The drawback is that we have the tunnel 
> header overhead, but maybe it would be possible to remove this using 
> some sort of nested shim (not sure if this last stuff would work...) The 
> features provided by the shim in this case would be an secure automatic 
> tunnel setup mechanism with fault tolerance protection, which may be 
> good enough justification.
> 
> I think this second approach is the one that is more attractive...

Couldn't one do #2 today using IP-in-IP tunneling and some liveness test 
  protocol (ICMP echo?) for the tunnels, without any shim6?

As I understand it in #2 the ULID is really an IP address assigned to 
the host by the proxy provider, which gets tunneled to/from the IP 
addresses assigned to host by the "physical" providers.

    Erik

Delivery-date: Mon, 08 May 2006 22:42:32 +0000
Date: Mon, 08 May 2006 15:42:11 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Pekka Savola <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>
Subject: Re: transparent addrsel policy adjustment for outbound TE

marcelo bagnulo braun wrote:

> unless remote resolvers explicitly query for the SRV records, and they 
> use that information to order the list of addresses returned to the app, 
> in which case this works and does not require upgrading the app to query 
> for SRV records. In this case, there is no kludgery AFAICT and it seems 
> to work fine and be easier to deploy. imho this may be useful if we go 
> to the path of using the DNS to express preferences about locators for 
> incoming communications

*If* we go with SRV records at names like _shim6._ip.FQDN, then the 
applications don't have to be modified; the getaddrinfo() implementation 
(often implemented in a  resolver library) can handle this transparent 
to the application.

    Erik

Delivery-date: Mon, 08 May 2006 22:38:59 +0000
Date: Mon, 08 May 2006 15:35:40 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt

marcelo bagnulo braun wrote:

>>    Next the host verifies that the Responder Nonce is a recent one, and
>>    that the Responder Validator option matches the validator the host
>>    would have computed for the ULID, locators, responder nonce, and FII.
>>
>> ==> how do you define 'a recent one' ?
>>
> 
> this is also up to the implementations, but are you suggesting we 
> provide some guidance about the lifetime of a responder nonce? like a 
> maximum nonce lifetime or similar?

I think "recent" should capture the VALIDATOR_MIN_LIFETIME.
Thus if the nonce is less than that constant (30 seconds), then it is 
recent. If we don't require that behavior then a retransmitted I2 might 
be silently ignored, which adds delay to the establishment.

>> ==> you should probably apply the same policy for certain other ICMP 
>> errors,
>> at least type 1 code 1 "Communication with destination administratively
>> prohibited", implying the protocol may be filtered at the firewall.
>>
> 
> ok for that error code, do you have another one in mind?

Part of the issue with ICMP errrors generated by routers is that they 
only speak for one path between the hosts. In the case of a 
misconfigured site one path could result in type 1/code 1 but some other 
path does not.
That's the motivation for only having host generated ICMPs to derive 
what the host actually supports.

>> ==> but this is not an exhaustive list.  Do you already specify 
>> somehow how
>> you will treat yet-to-be-specified options?  How do you parse the options
>> that are not on the lists?
>>
> 
> well, all the options have to have the format defined in section 5.14 
> whcih is basically a TLV format. In addition, it contains the C flag, 
> that defines whether the option is criticial or not and if it must be 
> recognized.
> what do you think that something is missing?

How about adding some text to the format section after the listed 
options for each message type that says:
	Future protocol extensions might define additional options for this 
message. The C-bit in the option format defines how such a new option 
will be handled by an implementation.

But I just realized that we don't seem to specify how an unknown option 
with C=1 should be handled (silently drop the message? Send some error 
such as an ICMP parameter problem??)

I'd suggest an ICMP parameter problem. Question is where we place this 
text. Does it make sense in secion 5.14?

    If a host receives an option that it does not understand (an option 
that was defined in some future extension to this protocol) or is not 
listed as a valid option for the different message types above, then the 
Critical bit in the option determines the outcome. If C=0 then the 
option is silently ignored, and the rest of the message is processed. If 
C=1 then the host SHOULD send back an ICMP parameter problem (type 4, 
code ), with the Pointer referencing the first octet in the option Type 
field. When C=1 the message MUST NOT be processed.

>> ==> at this point, I wondered, "how can the responder stay idle?  it 
>> needs
>> to remember _something_", so maybe a forward pointer to the security
>> discussion (i.e., a global secret value) could be useful.
>>
> 
> ok

The point is that the host doesn't create or update any state per peer 
when receiving I1.

    Erik

Delivery-date: Tue, 02 May 2006 01:59:24 +0000
Date: Tue, 02 May 2006 11:57:41 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt
Cc: kurt Erik Lindqvist <[email-masked]>, marcelo bagnulo braun <[email-masked]>, <[email-masked]>, Pekka Savola <[email-masked]>

Hi,

The Working Group Last Call for draft-ietf-shim6-proto-04.txt has concluded.

There has been one review report posted during this last call period 
(thanks Pekka) and one response (thanks Marcelo)

I'd like to ensure that we have clear consensus from the Working Group on 
the outcomes of this Last Call.

The points raised in the review are attached to this posting in summary form.

There are a number of points where the reviewer is invited to send text - a 
two week period  (ending 14 May) is proposed for this.

On the basis of this WG Last Call a new draft of the document, addressing 
those points as noted below, is requested

regards,

   Geoff

----------- WG Last Call Review Comments 
----------------------------------------

1) On IP multicast: it's not clear whether the text only applies to 
Any-Source-Multicast, rather than also to SSM.

    Comment:
     Section 1.4 includes the text::  "In summary, IP multicast will not 
need the shim to remap the IP addresses"

     Conclusion:
     It appears that the text in the draft, saying that the shim should not 
be applied to multicast addresses, applies to ASN as well as SSM.

     Recommendation:
     No further revisions to the document are required for this.

2) carrying the context tag opens the avenue for time-shifting attacks 
(e.g., data insertion into a session) after an attacker has moved from 
on-path to off-path ?

    Comment:
    Marcelo has responded: "I would argue that it is probably easier to try 
to send packets with the spoofed source address than trying to intercept 
one of the shim6 establishment packets and then move away and inject 
packets in an ongoing communication. Especially, considering that those 
packets are likely to be discarded by higher layers, since they do not 
belong to any established communication. My perception of this is that the 
threat is similar to the current situation, if not less. Note that this 
could be easily solved by checking that the source locator is included in 
Ls(peer) but this has several difficulties in its own in the protocol 
functioning, and it doesn't seem to be worthy imho"

     Conclusion:
     No further WG comment has been noted on this topic. Marcelo's comment 
indicates that no change to the draft is proposed

     Recommendation:
     No further revisions to the document are required for this.

3) The spec IMHO needs to say more about application framing impacts, as a 
result of adding the shim to some packets (well, we have been rather vague 
about this in the past, RFC4038 sec 5.4.2).  TCP-like protocols are not a 
big problem because the stack can just adjust to whatever value is 
appropriate, but protocol such as UDP where the user needs to specify this 
are trickier.  You should probably describe the required modifications to 
the implementations fragmentation handling code.

   Comment:
   There has been no further comment on this

   Conclusion
   The reviewer is proposing a new section (11.2) to address fragmentation 
handling code

   Recommendation
   The reviewer is requested to send proposed text of a section 11.2 of the 
draft to the Working Group for consideration. The document will be held for 
a further two (2) week awaiting this text.

4) There seem to be a number of minor attacks, and/or non-issues or 
residual threats which might be good to spell out better in the security 
considerations sections.

  4.1) The only hash input that an attacker could not affect is the secret 
value, and even that is static.  As the responder nonce is basically 
incremented based on the shim exchanges of the responder, the attacker can 
predict that as well. [...] That said, both of these issues may be no-op's 
because the value of the information protected is not very high.  But these 
considerations should be spelled out.

   Comment:
   Marcelo has responded: "rather than the information protected is not 
very high, i would say that it would be easier for the attacker to actually 
send the I1 messages and get new validators from the peer, rather than 
doing all this work [...] Agree, i guess we could also mention that the 
secret value could also be changed from once in a while making this 
attractive this attack, since the secret obtained would only be valid for a 
limited lifetime". There has been no further WG comment on this.

   Conclusion
   The reviewer is proposing additional material to be included in the 
Security Considerations Section . The document will be held for a further 
two (2) week awaiting this text.

   Recommendation
   The reviewer and document authors are requested to send proposed text of 
a section 11.2 of the draft to the Working Group for consideration. The 
document will be held for a further two (2) week awaiting this text.

  4.2) what about the scenario where the initiator wishes to establish 
shim6 sessions when the other party isn't (yet) willing to do so? (Think 
about large content providers.)  What are the graceful mechanisms to 
achieve this?

   Comment:
   Marcelo has responded that this is not felt to be a security concern and 
that the I1 messages will be dropped by the other party. There has been no 
further WG comment on this.

     Recommendation:
     No further revisions to the document are required for this.

4.3) you really don't need the 4-way handshake under normal circumstances

     Comment:
     Marcelo has noted that at the Interim SHIM6 meeting (October 2005), 
the proposal was to leave the 4 way handshake in the base spec and allow 
future extensions of the shim6 protocol for supporting this.

     Recommendation:
     No further revisions to the document are required for this. The 
reviewer may propose to the Working Group via a draft submission an 
extension to the SHIM6 protocol for supporting a simpler I2 - R2 message 
exchange.

4.4) 47-bit context tags are the most troublesome issue to me.  You should 
be more explicit what the effects of guessing (or knowing, from being on 
the path) the tag are, 'cause disruption' is a bit vague.

   Comment:
   Marcelo has proposed text along the lines of
   "In particular, it would be possible for an attacker that once was on 
the path to send a payload message that is protected by the context tag. 
This means that the attacker can insert data packet inside an established 
communication. This has the same effect of sending packets with spoofed 
source address, right? Currently the only defense against this is ingress 
filtering, which may or may not be deployed. With the shim solution, the 
attacker needs to be on path and catch at least one of the packets that 
carry to context tag. Then it can leave the path and he will be able to 
inject packets that the shim layer will translate into the proper source 
address. I would argue that it is probably easier to try to send packets 
with the spoofed source address than trying to intercept one of the shim6 
establishment packets and then move away and inject packets in an ongoing 
communication. Especially, considering that those packets are likely to be 
discarded by higher layers, since they do not belong to any established 
communication. My perception of this is that the threat is similar to the 
current situation, if not less. Note that this could be easily solved by 
checking that the source locator is included in Ls(peer) but this has 
several difficulties in its own in the protocol functioning, and it doesn't 
seem to be worthy imho"

   Recommendation:
   The draft be revised to include this text in the Security Considerations 
Section

5) isn't there any timeout for contexts in ESTABLISHED state..?  Does it 
stay there forever?"

     Comment:
     Marcelo pointed out that this was covered in Section 9. No further WG 
comment has been made

     Recommendation:
     No further revisions to the document are required for this.

6) How do you define a recent Responder Nonce

     Comment:
     Marcelo has responded: "this is also up to the implementations, but 
are you suggesting we provide  some guidance about the lifetime of a 
responder nonce? like a maximum nonce  lifetime or similar?" There has been 
no further WG comment.

     Recommendation:
     No further revisions to the document are required for this.

7) you should probably apply the same policy for certain other ICMP errors, 
at least type 1 code 1 "Communication with destination administratively 
prohibited", implying the protocol may be filtered at the firewall.

   Comment:
   Marcelo has agreed with this suggestion for adding type 1 code 1 in 
addition to type 4, code 1

      Recommendation:
      Marcelo to edit the draft to reflect this change

8)  Next Header:   NO_NXT_HDR (59). "I'd make this 'Normally...' [when 
referring to options defined for this message] or the like, so that it 
would be clearer that it might be OK for future extensions (if any) to also 
put in some other value if they wanted to.

     Comment:
     Allowing for unspecified 'other values'  appears to be unwise in a 
standards specification

     Recommendation:
     No further revisions to the document are required for this.

9)  Do you already specify somehow how you will treat yet-to-be-specified 
options?  How do you parse the options that are not on the lists?

     Comment:
     Marcelo wrote in response: "well, all the options have to have the 
format defined in section 5.14 whcih is basically a TLV format. In 
addition, it contains the C flag, that defines whether the option is 
criticial or not and if it must be recognized. what do you think that 
something is missing?" There has been no further WG comment on this

     Recommendation:
     No further revisions to the document are required for this.

10) I think this specification of padding adding is sub-optimal:

    Comment:
     There has been no WG comment on this observation

     Recommendation:
     No further revisions to the document are required for this.

11) in  Normal context establishment, the responder is noted to stay IDLE 
folloing receipt of an R1 message. The question has been raised: how can 
the responder stay idle?  it needs
to remember _something_", so maybe a forward pointer to the security 
discussion (i.e., a global secret value) could be useful.

     Comment:
     Marcelo has agreed to this suggestion of a forward pointer in the text 
to the security discussion

      Recommendation:
      Marcelo to edit the draft to reflect this change

12) The text notes that it is assumed that all the incoming packets that 
trigger the generation of an R1bis message contain a locator pair (in the 
address fields of the IPv6 header) and a Context Tag.. The reviewer suggest 
a rewording to the effect of "The locator pair is extracted from the source 
and destination IP addresses"

     Comment:
     Marcelo has noted that: "well, this is in the case that new message 
formats are defined. We are assuming that they will contain the context 
tag. In this case, if they don't contain the context tag, it won't be 
possible to properly generate the R1bis packet."

     Recommendation:
     No further revisions to the document are required for this.

13) The CGA signature options is only applicable w/ new locators when you 
use non-HBA CGA addresses, right?

    Comment:
     Marcel has noted: "yes, but it would be somehow strange to add new 
locators if you use HBAs, right? i mean, if you use HBAs the locator set is 
static. You could just include a subset on the HBA set in the locator set 
option initially exchanged and later on add new locators of the set, i 
guess, but i am not sure if this makes much sense, but we could add a 
clarification about this point if you think it would be useful". There has 
been no further WG comment on this suggestion

     Recommendation:
     No further revisions to the document are required for this.

14) the specification should suggest values for  retransmission timeout and 
a value for I1_RETRIES_MAX

     Comment:
     Marcelo has aghreed with this comment

      Recommendation:
      Marcelo to edit the draft to reflect this change

15) Editoral suggestions

     Recommendation
      Marcelo to edit the draft to reflect changes as appropriate