Subject: Re: error messages and silently discarding packets
From: marcelo bagnulo braun <[email-masked]>
To: Brian E Carpenter <[email-masked]>, Erik Nordmark <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Fri, 30 Mar 2007 17:43:53 +0200

Hi all,

El 16/03/2007, a las 15:38, Brian E Carpenter escribió:

> ...
>> The question is whether we should use ICMP error message or if we 
>> should define a shim6 error message within the shim6 protocol
>> Iljitsch suggested we do define such an error message, while the 
>> current spec uses ICMP error messages, what should we do?
>
> In my opinion it depends whether the error messages are *necessary*
> or whether they are only advisory.
>
> If they are *necessary* for shim6 to function, that means they need
> to arrive whatever ICMP filters are in place. So they would need to
> be shim6 messages. If they aren't functionally necessary, ICMP
> seems OK.
>

i have analyzed the different situations based on the criteria 
suggested by Brian

below i attach the criteria suggested by Brian and the analysis for the 
different cases.

my conclusion is that most of them are critical, so we should use a new 
shim6 error message for this, following Brian's criteria. What do 
others think?

>> Second, about silently discarding packets:
>> there are quite a few situations that the shim6 protocol silently 
>> discard packets that it considers an error or are not supported.
>
> If the error messages are not functionally necessary, I suggest silent
> discard as a SHOULD in all cases, with implementers allowed to 
> implement
> error messages as a configurable debug option.
>

they are not functionally necesary, since the protocol should be 
working fine wihtout them

do you think we should add some recomendation for the implementers that 
the can add error messages for debugging purposes?
Should we define a generic error message for debugging purposes?

analysis of the different cases below...

First, shim6 protocol sends a error message in the following situations:
- when a node receives a critical option that is not recognized. In 
order to do that, it sends an an ICMP parameter problem (type 4, code 
1), with the Pointer referencing the first octet in the option Type 
field.

This one seems critical for shim6 to work properly, since the option is 
critical

- when the verification method in the locator list option is not 
supported, then the host MUST ignore the Locator List and the message 
in which it is contained, and the host SHOULD generates an ICMP 
parameter problem (type 4, code 0), with the Pointer referencing the 
octet in the Verification method that was found inconsistent.

This one seems critical for shim6 to work properly, since if the peer 
does nto support the verification method, the whole shim6 context is 
useless

- when a node receives a I1 packet and it doesn't support the shim6 
protocol, it sends a  ICMP error with "Unrecognized Next Header" type 
(type 4, code 1)

This one doesn't seem too critical for shim6 to work properly, since it 
will give up eventually

-  If the Update message contains a Locator Preference option, then the 
Generation number in the preference option is compared with the peer 
generation number in the context.  If they do not match, then the host 
generates an ICMP parameter problem (type 4, code 0) with the Pointer 
field referring to the first octet in the Generation number in the 
Locator Preference option.  In addition, if the number of elements in 
the Locator Preference option does not match the number of locators in 
Ls(peer), then an ICMP parameter problem is sent with the Pointer 
referring to the first octet of the Length field in the Locator 
Preference option.  In both cases of failures, no further processing is 
performed for the Locator Update message.

This one seems critical for shim6 to work properly, becuase, the 
locator lists may go out of sync

- If a node receives a packet that contains a shim message type which 
is unknown to the receiver, then an ICMPv6 Parameter Problem error is 
generated and sent back.  The pointer field in the Parameter Problem is 
set to point at the first octet of the shim message type. The error is 
rate limited just like other ICMP errors [5].

This one may be critical for shim6 to work properly, depending on the 
message

So accroding to Brian's criteria, we shoudl define a shim6 error 
message.. what do others think?

Delivery-date: Thu, 22 Mar 2007 13:27:49 +0000
Date: Thu, 22 Mar 2007 14:25:16 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: shim6 interoperability / traffic analyzer - update

Already an update for the shim6 enabled wireshark, which allows you to
apply filters on many shim6 elements. Useful if you want to view only
probe messages or what so ever...

The new patch and source can also be found at
http://www.pletterpet.nl/shim6/

Regards,

Matthijs Mekking

Matthijs Mekking wrote:
> Hello,
> 
> I have been working on a SHIM6 enabled version of Wireshark. More
> information (including the patch and source files) can be found
> temporary on:
> 
> http://www.pletterpet.nl/shim6/
> 
> It will be here for at least two months. Before that, I will update you
> of the permanent link.
> 
> If you like, you can use it to test your SHIM6 implementation. I have
> tested it on my own created dummy messages and the SHIM6 0.4
> implementation of Sébastien. For suggestions, questions, criticism or
> any other form of feedback, you can reach me at [email-masked].
> 
> Regards,
> 
> Matthijs Mekking

Delivery-date: Wed, 21 Mar 2007 10:15:41 +0000
Cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
Date: Wed, 21 Mar 2007 11:16:57 +0100
To: Erik Nordmark <[email-masked]>

El 21/03/2007, a las 10:50, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>> In this case, it seems that the host will send a packet with 
>> destination address the cmula and the P-shim won't have the locator 
>> information associated to the CMULa. In this case, the P-shim6 will 
>> perform a reverse lookup for the CMULA and retrieve the locator 
>> information from the DNS. (This can be handled in the same way the 
>> case where there is a failure in the primary P-shim6 and the backup 
>> P-him6 is used)
>
> I agree with everything but the parenthesis.
>
> Even if you have a primary and backup pshim which share state, then 
> wold be likely to time out the state, for instance based on the DNS 
> ttl.
> But there are applications that remember the IP address independent of 
> the DNS TTL.
> Thus to the extent that the document says that the reverse DNS tree is 
> optional there is a problem; the reverse tree information must be 
> present for it to be robust.
>
>

i see

in other words, if you want to handle the call-back or referral 
situation when you are using non routable identifiers, you need a 
stable repository from where to obtain the ULID to locator mapping, 
since hosts (or thier upper layers) can have sotred the ULID for longer 
than the shim6 context in the proxy

The DNS is an option (you could have a local repository with a really 
long expiration information that stores the ULID to locator mapping 
that have been used (as opposed to store the whole shim6 context)

>> the order of preference would be
>> 1- an locator ID mapping verified using HBA/CGA
>> 2- a locator ID mapping verified through reverse DNS
>> 3- a locator ID mapping obtained through direct DNS (ULID RR and AAAA 
>> RR for the same FQDN)
>> In case of conflict, the one with higher preference wins
>> If two with the lower preference are obtained, then the P-shim must 
>> use a higher preference method to determine which one is the correct 
>> one
>> makes sense?
>
> OK.
>
> But does or does this not mean that an implementation has to track 
> multiple mappings for the same ID while it is trying to verify them?
>
> An example is that suppose the pshim has a preference 3 mapping for ID 
> A and it starts doing verification for ID A for a higher preference, 
> does it need to keep the preference 3 mapping around until the other 
> verification has completed (or failed) and only then replace the 
> existing mapping.
>

i think so...

is this a problem?

regards, marcelo

>    Erik
>

Delivery-date: Wed, 21 Mar 2007 09:52:21 +0000
Date: Wed, 21 Mar 2007 02:50:11 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt

marcelo bagnulo braun wrote:

> In this case, it seems that the host will send a packet with destination 
> address the cmula and the P-shim won't have the locator information 
> associated to the CMULa. In this case, the P-shim6 will perform a 
> reverse lookup for the CMULA and retrieve the locator information from 
> the DNS. (This can be handled in the same way the case where there is a 
> failure in the primary P-shim6 and the backup P-him6 is used)

I agree with everything but the parenthesis.

Even if you have a primary and backup pshim which share state, then wold 
be likely to time out the state, for instance based on the DNS ttl.
But there are applications that remember the IP address independent of 
the DNS TTL.
Thus to the extent that the document says that the reverse DNS tree is 
optional there is a problem; the reverse tree information must be 
present for it to be robust.

> the order of preference would be
> 1- an locator ID mapping verified using HBA/CGA
> 2- a locator ID mapping verified through reverse DNS
> 3- a locator ID mapping obtained through direct DNS (ULID RR and AAAA RR 
> for the same FQDN)
> 
> In case of conflict, the one with higher preference wins
> If two with the lower preference are obtained, then the P-shim must use 
> a higher preference method to determine which one is the correct one
> 
> makes sense?

OK.

But does or does this not mean that an implementation has to track 
multiple mappings for the same ID while it is trying to verify them?

An example is that suppose the pshim has a preference 3 mapping for ID A 
and it starts doing verification for ID A for a higher preference, does 
it need to keep the preference 3 mapping around until the other 
verification has completed (or failed) and only then replace the 
existing mapping.

    Erik

Delivery-date: Tue, 20 Mar 2007 14:26:12 +0000
Date: Tue, 20 Mar 2007 15:24:40 +0100
From: Matthijs Mekking <[email-masked]>
To: Matthijs Mekking <[email-masked]>
Subject: Re: shim6 interoperability / traffic analyzer

Hello,

I have been working on a SHIM6 enabled version of Wireshark. More
information (including the patch and source files) can be found
temporary on:

http://www.pletterpet.nl/shim6/

It will be here for at least two months. Before that, I will update you
of the permanent link.

If you like, you can use it to test your SHIM6 implementation. I have
tested it on my own created dummy messages and the SHIM6 0.4
implementation of Sébastien. For suggestions, questions, criticism or
any other form of feedback, you can reach me at [email-masked].

Regards,

Matthijs Mekking

Delivery-date: Tue, 20 Mar 2007 09:26:33 +0000
Date: Tue, 20 Mar 2007 10:24:38 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
Subject: About draft-ietf-shim6-failure-detection-07

Hello,

When I was reading the draft-ietf-shim6-failure-detection-07 again, I
got a little confused about the probe messages. The confusion is mainly
a result of the example scenario described in appendix A.

Luckily the confusion is almost completely solved :-). However I found
two small type mismatches (and I think were not reported yet).

1) Section 5.1 Keepalive Message (Page 15)

Type
      This field identifies the Probe message and MUST be set to 66
      (Keepalive).

This should the "This field identifies the Keepalive message".

2) Appendix A Example 5 (Page 37)

The Probe id=q should report that it received probe p, not q.
Why is in the example shown that it received payload? Should a probe
message be able to include this information? If so, the message format
should be changed to handle this (or can the probe data field be used
for this?). If not, 'received payload' should be removed from the example.

Regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Sat, 17 Mar 2007 00:33:12 +0000
Cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
Date: Sat, 17 Mar 2007 01:32:36 +0100
To: Erik Nordmark <[email-masked]>

El 16/03/2007, a las 22:24, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>>> It sounds brittle to rely on one of the P-shims to always have the 
>>> cached locators in the cases that a host might have retained the 
>>> CMULA.
>>>
>>> For instance, there is plenty of host software (even though it is 
>>> broken) which retains DNS answers past the expiry of the DNS TTL.
>>> Thus some host software might retain the CMULA long after the 
>>> P-shim's have timed out the DNS information.
>
> FWIW I didn't see a response to the above robustness issue.
>

right

In this case, it seems that the host will send a packet with 
destination address the cmula and the P-shim won't have the locator 
information associated to the CMULa. In this case, the P-shim6 will 
perform a reverse lookup for the CMULA and retrieve the locator 
information from the DNS. (This can be handled in the same way the case 
where there is a failure in the primary P-shim6 and the backup P-him6 
is used)

This would of course result in additional latency for the time required 
to retrieve the locator information

>> but in any case the P-shim will perform the shim6 context 
>> establishment and will use the HBA/CGA technique to verify that the 
>> ULID to locator binding is ok, so, even if some attacker manages to 
>> install the false id to loc mapping in the P-shim, it would still 
>> have to be able to crack the HBAA/CGA protection, right?
>
> I forgot about that because the draft didn't explicitly say that it is 
> done and when it is done.
>

yes, need to add that part then

>
> If the HBA/CGA check isn't done until the P-shims do the exchange 
> there is still a source of confusion (hence possible redirect attacks) 
> before then if the P-shim caches things based on the DNS response.

> A way to avoid this is to invalidate the locator cache in the p-shim 
> entry when there is a conflict, but even that seems shaky to me.
> Suppose the lookup for H2.foo.com comes back the shim returns the ULID 
> 1::1 to the host. The shim caches the mapping from 1::1 -> {x, y, z}.
> If/when a shim6 exchange with 1::1 has verified that using HBA/CGA 
> that mapping can be marked as 'verified'.
> But if there is some other DNS lookup (for H3.bar.com) via the same 
> shim resulting in the same ULID but different locator set being 
> returned by the DNS, then an unverified mapping should be discarded 
> and a new mapping should not be setup (pointing at a different locator 
> set). In this case the shim MUST do a ULID->locator set lookup (using 
> the DNS as the example mechanism) to avoid a redirection DoS for one 
> of the communications.
>

i agree

the order of preference would be
1- an locator ID mapping verified using HBA/CGA
2- a locator ID mapping verified through reverse DNS
3- a locator ID mapping obtained through direct DNS (ULID RR and AAAA 
RR for the same FQDN)

In case of conflict, the one with higher preference wins
If two with the lower preference are obtained, then the P-shim must use 
a higher preference method to determine which one is the correct one

makes sense?

i will add this to security considerations section of the draft

thanks

> > the result would be some form of DoS attack, but i guess that this 
> has
> > similar impact (and should be protected with the same tools than) a 
> DNS
> > cache poisoning...
>
> This has nothing to do with DNS cache poisoning.
> The issue is that if you ask for a RRset for H3.bar.com the DNS server 
> which is authoritative for that zone can return whatever it pleases - 
> and it could be signed by DNSsec - because it is authoritative.
>
> Thus using the fact that H3.bar.com says ULID=1::1 and AAAA set = {a, 
> c}  is completely unrelated to which DNS server is authoritative for 
> the lookup of the ULID (in the reverse tree). It is the delegation of 
> the reverse tree that provides the authorization.
>

yes you are right

this is not similar to DNS cache poisining since there is no trust 
chain for publishing ULID RR in the direct tree

regards, marcelo

>    Erik
>

Delivery-date: Fri, 16 Mar 2007 21:26:16 +0000
Date: Fri, 16 Mar 2007 14:24:21 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt

marcelo bagnulo braun wrote:

>> It sounds brittle to rely on one of the P-shims to always have the 
>> cached locators in the cases that a host might have retained the CMULA.
>>
>> For instance, there is plenty of host software (even though it is 
>> broken) which retains DNS answers past the expiry of the DNS TTL.
>> Thus some host software might retain the CMULA long after the P-shim's 
>> have timed out the DNS information.

FWIW I didn't see a response to the above robustness issue.

> but in any case the P-shim will perform the shim6 context establishment 
> and will use the HBA/CGA technique to verify that the ULID to locator 
> binding is ok, so, even if some attacker manages to install the false id 
> to loc mapping in the P-shim, it would still have to be able to crack 
> the HBAA/CGA protection, right?

I forgot about that because the draft didn't explicitly say that it is 
done and when it is done.

If the HBA/CGA check isn't done until the P-shims do the exchange there 
is still a source of confusion (hence possible redirect attacks) before 
then if the P-shim caches things based on the DNS response.

A way to avoid this is to invalidate the locator cache in the p-shim 
entry when there is a conflict, but even that seems shaky to me.
Suppose the lookup for H2.foo.com comes back the shim returns the ULID 
1::1 to the host. The shim caches the mapping from 1::1 -> {x, y, z}.
If/when a shim6 exchange with 1::1 has verified that using HBA/CGA that 
mapping can be marked as 'verified'.
But if there is some other DNS lookup (for H3.bar.com) via the same shim 
resulting in the same ULID but different locator set being returned by 
the DNS, then an unverified mapping should be discarded and a new 
mapping should not be setup (pointing at a different locator set). In 
this case the shim MUST do a ULID->locator set lookup (using the DNS as 
the example mechanism) to avoid a redirection DoS for one of the 
communications.

 > the result would be some form of DoS attack, but i guess that this has
 > similar impact (and should be protected with the same tools than) a DNS
 > cache poisoning...

This has nothing to do with DNS cache poisoning.
The issue is that if you ask for a RRset for H3.bar.com the DNS server 
which is authoritative for that zone can return whatever it pleases - 
and it could be signed by DNSsec - because it is authoritative.

Thus using the fact that H3.bar.com says ULID=1::1 and AAAA set = {a, c} 
  is completely unrelated to which DNS server is authoritative for the 
lookup of the ULID (in the reverse tree). It is the delegation of the 
reverse tree that provides the authorization.

    Erik

Delivery-date: Fri, 16 Mar 2007 14:43:12 +0000
Date: Fri, 16 Mar 2007 15:42:38 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: =?UTF-8?B?U8OpYmFzdGllbiBCYXJyw6k=?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07 {2}

I'm curious - was this ever resolved?

     Brian

-------- Original Message --------
Subject: About draft-ietf-shim6-failure-detection-07 {2}
Date: Fri, 26 Jan 2007 13:53:10 +0100
From: SÃ©bastien BarrÃ© <[email-masked]>
To: [email-masked], [email-masked]
CC: [email-masked]

Hi,

I have another question regarding the failure detection draft. This is
about the end of an exploration. I think it is useful to have a notion of
- when an exploration process begins.
- when an exploration process terminates.

* Motivation :
    - An implementation might want to have a specific thread/process for
each exploration. It is useful to know when the exploration thread may
be terminated.
    - We need to store information about each probe sent/received
(because reports are included in the probes). It is useful to know when
the memory used by this information can be released. This would ensure
that only information relative to the current exploration is stored in
memory. Also, a context in operational state would need less space than
a context in course of exploration, which is more scalable if lots of
contexts are present.

* The problem :

While it is rather evident when we must trigger an exploration (send
timer expiry or incoming probe exploring), we are not so certain about
the end of an exploration. More precisely *one of the peers* is not
certain, while the other is. Here is an example situation with the
currently defined scheme for the end of an exploration :

Peer A                                        Peer B
      |                                             |
    State:                                        State:
  Inbound_OK                                    Exploring
      |                                             |
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                           State:
      |                                         Operational
      |           Probe Operational                 |
      |    	  /---------------------------------| path working, but probe lost (because of
      |                                             | congestion for example)
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                             |
      |           Probe Operational                 |
      |<--------------------------------------------|
      |                                             | Now B can forget its received/sent probe reports,
   State : 					    | because A is in state operational, but B has no way to know it.
Operational

As illustrated in this scenario, when A receives a probe Operational, it
knows for sure that B is operational, and so that the exploration
process is terminated. But B won't receive such a probe. B enters into
the Operational state when he receives a Probe Inbound OK. This means
that he knows the conversation will work from now, but this doesn't
mean, however, that A won't ever ask B to send its list of sent/recvd
probe reports, as is the case in the above scenario (because of the
first probe operational being lost).

* One possible (and simple :-) ) solution :

Because the only problem is for B to know for sure that A is
operational. Just let it know this fact by sending another Probe
Operational. Of course, with such a rule, we could end up with A and B
infinitely sending Probes Operational. This can be simply solved by
having something different in the last Probe Operational, such as a
flag. This can also be solved by sending no probe report (psent=0 and
precevd=0). This may seem contradictory with my previous mail, but it
isn't : we are here in the special case where A *knows* that B is in
operational state, so he doesn't need anymore to have any probe
information, his only need is now to be sure that A is also in
operational state. In fact, the only thing that B will do when receiving
the last probe is check whether this is an operational probe or an
Inbound OK probe :
    - in the first case : stop the exploration process gracefully
    - in the last case : The last probe operational from B has been
lost, send another one.
This results in the following (very similar, but much simpler/efficient
from an implementation point of view, IMHO) scenario :

Peer A                                        Peer B
      |                                             |
    State:                                        State:
  Inbound_OK                                    Exploring
      |                                             |
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                           State:
      |                                         Operational
      |           Probe Operational                 |
      |    	  /---------------------------------| path working, but probe lost (because of
      |                                             | congestion for example)
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                             |
      |           Probe Operational                 |
      |<--------------------------------------------|
      |	                                            |
   State : 					    |
Operational					    |
      |						    |
      |           Probe Operational|final           |
      |-------------------------------------------->|
      |                                             | Now B can forget its received/sent probe reports,

In fact, the final flag is not necessary, because there is no ambiguity,
here would be the difference in the state machine :
event : Reception of the probe message State Operational
if in state Operational : just update timers (see draft) -> *end of
exploration*
if in state Inbound_OK : goto Operational, update timers AND send a
probe operational
if in state Exploring : goto Operational, update timers AND send a probe
operational (mmm, in fact i guess this case should not occur, unless one
of the peers is buggy, but this answer to this little probable event
seems OK).

What is your opinion ?
Thanks for any comments,

SÃ©bastien.

-- 
SÃ©bastien BarrÃ©
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Fri, 16 Mar 2007 14:40:13 +0000
Date: Fri, 16 Mar 2007 15:38:55 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: error messages and silently discarding packets

...
> The question is whether we should use ICMP error message or if we should 
> define a shim6 error message within the shim6 protocol
> 
> Iljitsch suggested we do define such an error message, while the current 
> spec uses ICMP error messages, what should we do?

In my opinion it depends whether the error messages are *necessary*
or whether they are only advisory.

If they are *necessary* for shim6 to function, that means they need
to arrive whatever ICMP filters are in place. So they would need to
be shim6 messages. If they aren't functionally necessary, ICMP
seems OK.

> 
> Second, about silently discarding packets:
> 
> there are quite a few situations that the shim6 protocol silently 
> discard packets that it considers an error or are not supported.

If the error messages are not functionally necessary, I suggest silent
discard as a SHOULD in all cases, with implementers allowed to implement
error messages as a configurable debug option.

     Brian

Delivery-date: Fri, 16 Mar 2007 08:15:43 +0000
Date: Fri, 16 Mar 2007 17:14:48 +0900
From: Shinta Sugimoto <[email-masked]>
To: Erik Nordmark <[email-masked]>
Subject: Re: State of play with Shim6 documents
Cc: "Henderson, Thomas R" <[email-masked]>, Geoff Huston <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]

Hi,

Please find my comments inline.

On Mon, 12 Mar 2007 14:26:07 -0700
Erik Nordmark <[email-masked]> wrote:

> Henderson, Thomas R wrote:
> 
> > Besides the fragmentation issue, the way it is defined now, it seems
> > burdensome to implementations that want to implement the shim6 control
> > plane as a user-space daemon (as opposed to defining a separate protocol
> > number for shim6 control messages).  My reading of IPv6 raw sockets
> > semantics suggests that they cannot be used.
> > 
> > from RFC 3542:
> > "With IPv6 raw sockets will be
> >    used for ICMPv6 and to read and write IPv6 datagrams containing a
> >    Next Header field that the kernel does not process."
> > 
> > This is not the case for shim6 since the kernel does process the payload
> > extension header in the data plane.
> > 
> > Under current definition, how should a user-space shim6 implementation
> > use IPv6 sockets API to get only the control messages?  If there isn't
> > an easy way, should we consider to separate the protocol numbers?  
> 
> Thomas,
> 
> Are you saying that the *only* thing that prevents a complete shim6 
> user-space implementation using standard APIs is the fact that shim6 
> uses a single protocol number? I find that very hard to believe since I 
> don't know of any standard APIs that allow me to insert the transmit 
> side data plane of shim6 in the transmit path. The API RFCs clearly 
> don't have such a mechanism, nor does the socket standard from the open 
> group. Thus a user space shim6 implementation would require some 
> non-standard extensions and/or modifications to the stack. Given that, I 
> suspect one can figure out how to handle the above issue as well.
> 
> The reason for using a single protocol number for shim6 is to increase 
> the probability of uniform handling by existing firewalls. With a single 
> protocol number existing firewalls would probably either let all such 
> packets through, or block all of them. If we chose to instead use 
> multiple protocol numbers there is the danger that some packets (such as 
> the context establishment packets) make it through the firewall while 
> others (such as the payload packets) are blocked. That possibility adds 
> a new failure mode which is hard to deal with, especially if the probe 
> messages get the same firewall treatment as the context establishment 
> packets.

The above argument sounds reasonable to me. So I support having a single
protocol number for SHIM6.

In our implementation, in an inbound packet processing of an IP packet
whose next protocol field is IPPROTO_SHIM6, the kernel (Linux) verifies
the bit right after the SHIM6 common header and takes necessary action
as follows:

1) if the bit indicates the packet is data, do locator switching
2) else, do nothing and deliver the packet to RAW socket (if any)

Regards,
Shinta

Delivery-date: Fri, 16 Mar 2007 07:48:34 +0000
Cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
Date: Fri, 16 Mar 2007 08:48:21 +0100
To: Erik Nordmark <[email-masked]>

El 16/03/2007, a las 1:15, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>> This is described in the draft in this way.
>>    The DNS reverse tree is used to retireve locator information
>>    associated with an unroutable ULID.  In concrete, it is used in the
>>    following situation: A shim6 context has been established between a
>>    P-shim and a remote shim6 peer (either P-shim6 or a shim6 host).  
>> The
>>    P-shim6 that has the shim6 context information fails and the backup
>>    shim6 is used to continue with the communication.  In order to do
>>    that, the context information must be restored.  In this case, the
>>    backup P-shim6 needs to retrieve the locator information associated
>>    to the ULID of the remote peer.  It does so, by performing a DNS
>>    reverse lookup for the CMULA used a ULID.
>>    However, it should be noted that the locator information was 
>> already
>>    available in the site, in particular, it was available in the 
>> primary
>>    P-shim6.  So it would be perfectly possible to create an inter-P-
>>    shim6 protocol to exchange locator-ULID binding information between
>>    the primary and the backup P-shim6 as soon as the the context is
>>    created.  This would distribute the locator to ULID binding
>>    information and there would be no need to retrieve it from the DNS
>>    reverse tree (and there would be no need to require the population 
>> of
>>    the reverse DNS tree if such inter-P-shim6 protocol was available.
>>    It must be noted that the reverse tree is never used to retrieve 
>> ULID
>>    locator binding information for initial contact, but is only used 
>> to
>>    restore information that was once available locally. this is why, 
>> it
>>    is perfectly possible to design local mechanisms to substitute the
>>    usage of the reverse DNS in the P-shim6 approach.
>> So i am perfectly open to define a new protocol for this and forget 
>> the reverse DNS completely if people prefer this. This is not central 
>> to the P-shim6 approach
>
> It sounds brittle to rely on one of the P-shims to always have the 
> cached locators in the cases that a host might have retained the 
> CMULA.
>
> For instance, there is plenty of host software (even though it is 
> broken) which retains DNS answers past the expiry of the DNS TTL.
> Thus some host software might retain the CMULA long after the P-shim's 
> have timed out the DNS information.
>
> But I think there is also a potential security issue the way you 
> describe the DNS lookups and caching.
>
> This is how I understand it.
> An unmodified host looks up H2.foo.com. The P-shim caches
> 	ULID = 1::1
> 	AAAA = x, y, z
> and returns the ULID to the host. As a result of this the P-shim 
> established a local mapping from 1::1 -> {x, y, z}.
>
> Later a possibly different host in the same site looks for H3.bar.com. 
> For some reason the ULID returned from the DNS is also 1::1. But the 
> AAAA set is {a, b}.
> Which mapping will be P-shim use for ULID 1::1?
> The P-shim can't tell the packets received from its hosts apart since 
> both the ones destined to H2.foo.com and H3.bar.com have the same ULID 
> in the IPv6 header.
> Should it let H3.bar.com lauch a succesful redirection attack for the 
> packets that were really destined to H2.foo.com?

but in any case the P-shim will perform the shim6 context establishment 
and will use the HBA/CGA technique to verify that the ULID to locator 
binding is ok, so, even if some attacker manages to install the false 
id to loc mapping in the P-shim, it would still have to be able to 
crack the HBAA/CGA protection, right?

the result would be some form of DoS attack, but i guess that this has 
similar impact (and should be protected with the same tools than) a DNS 
cache poisoning...

makes sense?

regards, marcelo

> The only way I know of addressing this is to check who is authorized 
> to specify the locators for ULID=1::1. If we are using the DNS that 
> can be done using doing a ULID->locator lookup when caching the 
> mapping in the P-shim. And AFAICT the same type of lookup would be 
> needed if a protocol different than DNS was used for the lookup.
>
> Thus I think a ULID->locator lookup mechanism is mandatory to avoid 
> redirection attacks.
>
> Or am I missing something?
>

>   Erik
>

Delivery-date: Fri, 16 Mar 2007 00:16:24 +0000
Date: Thu, 15 Mar 2007 17:15:02 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt

marcelo bagnulo braun wrote:

> This is described in the draft in this way.
> 
>    The DNS reverse tree is used to retireve locator information
>    associated with an unroutable ULID.  In concrete, it is used in the
>    following situation: A shim6 context has been established between a
>    P-shim and a remote shim6 peer (either P-shim6 or a shim6 host).  The
>    P-shim6 that has the shim6 context information fails and the backup
>    shim6 is used to continue with the communication.  In order to do
>    that, the context information must be restored.  In this case, the
>    backup P-shim6 needs to retrieve the locator information associated
>    to the ULID of the remote peer.  It does so, by performing a DNS
>    reverse lookup for the CMULA used a ULID.
> 
>    However, it should be noted that the locator information was already
>    available in the site, in particular, it was available in the primary
>    P-shim6.  So it would be perfectly possible to create an inter-P-
>    shim6 protocol to exchange locator-ULID binding information between
>    the primary and the backup P-shim6 as soon as the the context is
>    created.  This would distribute the locator to ULID binding
>    information and there would be no need to retrieve it from the DNS
>    reverse tree (and there would be no need to require the population of
>    the reverse DNS tree if such inter-P-shim6 protocol was available.
>    It must be noted that the reverse tree is never used to retrieve ULID
>    locator binding information for initial contact, but is only used to
>    restore information that was once available locally. this is why, it
>    is perfectly possible to design local mechanisms to substitute the
>    usage of the reverse DNS in the P-shim6 approach.
> 
> So i am perfectly open to define a new protocol for this and forget the 
> reverse DNS completely if people prefer this. This is not central to the 
> P-shim6 approach

It sounds brittle to rely on one of the P-shims to always have the 
cached locators in the cases that a host might have retained the CMULA.

For instance, there is plenty of host software (even though it is 
broken) which retains DNS answers past the expiry of the DNS TTL.
Thus some host software might retain the CMULA long after the P-shim's 
have timed out the DNS information.

But I think there is also a potential security issue the way you 
describe the DNS lookups and caching.

This is how I understand it.
An unmodified host looks up H2.foo.com. The P-shim caches
	ULID = 1::1
	AAAA = x, y, z
and returns the ULID to the host. As a result of this the P-shim 
established a local mapping from 1::1 -> {x, y, z}.

Later a possibly different host in the same site looks for H3.bar.com. 
For some reason the ULID returned from the DNS is also 1::1. But the 
AAAA set is {a, b}.
Which mapping will be P-shim use for ULID 1::1?
The P-shim can't tell the packets received from its hosts apart since 
both the ones destined to H2.foo.com and H3.bar.com have the same ULID 
in the IPv6 header.
Should it let H3.bar.com lauch a succesful redirection attack for the 
packets that were really destined to H2.foo.com?

The only way I know of addressing this is to check who is authorized to 
specify the locators for ULID=1::1. If we are using the DNS that can be 
done using doing a ULID->locator lookup when caching the mapping in the 
P-shim. And AFAICT the same type of lookup would be needed if a protocol 
different than DNS was used for the lookup.

Thus I think a ULID->locator lookup mechanism is mandatory to avoid 
redirection attacks.

Or am I missing something?

   Erik

Delivery-date: Thu, 15 Mar 2007 23:43:56 +0000
Date: Thu, 15 Mar 2007 16:42:34 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Geoff Huston <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation

marcelo bagnulo braun wrote:

> Section X.X Middle-boxes considerations
> 
> Data packets belonging to a Shim6 context carrying the Shim6 Payload 
> Header contain alternative locators other than the ULIDs in the source 
> and destination address fields of the IPv6 header. On the other hand, 
> the upper layers of the peers involved in the communication operate on 
> the ULID pair presented by the Shim6 layer to them, rather on the 
> locator pair contained in the IPv6 header of the actual packets. It 
> should be noted that the Shim6 layer does not modify the data packets, 
> but because a constant ULID pair is presented to upper layers 
> irrespective of the locator pair changes, the relation between the upper 
> layer header (such as TCP, UDP, ICMP, ESP, etc) and the IPv6 header is 
> modified. In particular, if those data packets are TCP, UDP or ICMP 
> packets, the presudoheader used for the checksum calculation will 
> contain the ULID pair, rather than the locator pair contained in the 
> data packet.

Change last setence to start with
In particular, when the shim6 extension header is present in the packet, 
  ...

> It is possible that some firewalls or other middle boxes try to verify 
> the validity of upper layer sanity checks of the packet on the fly. If 
> they do that based on the actual source and destination addresses 
> contained in the IPv6 header without considering the Shim6 context 
> information (in particular without replacing the locator pair by the 
> ULID pair used by the Shim6 context) such verifications may fail. Those 
> middle-boxes need to be updated in order to be able to parse the Shim6 
> payload header and find the next header header after that.  It is 
> recommended that firewalls and other middle-boxes do not drop packets 
> that carry the Shim6 Payload header with apparently incorrect upper 
> layer validity checks that involve the addresses in the IPv6 header for 
> their computation, unless they are able to determine the ULID pair of 
> the Shim6 context associated to the data packet and use the ULID pair 
> for the verification of the validity check.
> 
> In the particular case of TCP, UDP and ICMP checksums, it is recommended 
> that firewalls and other middle-boxes do not drop TCP, UDP and ICMP 
> packets that carry the Shim6 Payload header with apparently incorrect 
> checksums when using the addresses in the IPv6 header for the 
> pseudoheader computation, unless they implement are able to determine 
> the ULID pair of the Shim6 context associated to the data packet and use 
> the ULID pair to determine the checksum that must be present in a packet 
> with addresses rewritten by shim6.
> 
> would that be better?

The last paragraph seems redundant with the 2nd paragraph. But it looks ok.

    Erik

Delivery-date: Thu, 15 Mar 2007 10:14:08 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Geoff Huston <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation
Date: Thu, 15 Mar 2007 10:24:57 +0100
To: Erik Nordmark <[email-masked]>

El 15/03/2007, a las 7:24, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>> Add a new section titled "Middle-boxes considerations" with the 
>> following text.
>> Data packets belonging to a Shim6 context carrying the Shim6 Payload 
>> Header contain alternative locators other than the ULIDs in the 
>> source and destination address fields of the IPv6 header. However, if 
>> those data packets are TCP or UDP packets, the presudoheader used for 
>> the checksum calculation will contain the ULID pair, rather than the 
>> locator pair contained in the data packet.
>
> Same is true for the ICMPv6 pseudo-header. And I think the statement 
> is a lot more general than an enumeration of protocols. All protocols 
> sitting above the SHIM6 sub-layer would operate based on the ULIDs. 
> Thus if you had a hypothetical middle-box that cracked open IKE and 
> verified that the ESP/AH packets IP addresses + SPI that matched the 
> IKE exchange, they could also potentially be confused by shim much the 
> same way the TCP checksum verifying middlebox would be.
>
>> It is possible that some firewalls or other middle boxes verify the 
>> TCP/UDP checksum. Those middleboxes need to be updated in order to be 
>> able to parse the Shim6 payload header and find the TCP/UDP header 
>> after that. It is recommended that firewalls and other middleboxes do 
>> not drop TCP, UDP and ICMP packets that carry the Shim6 Payload 
>> header with apparently incorrect checksums when using the addresses 
>> in the IPv6 header for the pseudoheader computation, unless they 
>> implement (monitoring of) the full shim6 protocol and are able to 
>> determine the checksum that must be present in a packet with 
>> addresses rewritten by shim6.
>> would this be ok/enough?
>
> I have a hard time understanding the issue from the text. Could we 
> make it a bit more explicit that the TCP and UDP packets aren't 
> modified, but what is modified is relationship between the 
> TCP/UDP/ICMP/ESP/etc header that follows the shim6 header, and the 
> IPv6 header?
>
>    Erik
>
>

Section X.X Middle-boxes considerations

Data packets belonging to a Shim6 context carrying the Shim6 Payload 
Header contain alternative locators other than the ULIDs in the source 
and destination address fields of the IPv6 header. On the other hand, 
the upper layers of the peers involved in the communication operate on 
the ULID pair presented by the Shim6 layer to them, rather on the 
locator pair contained in the IPv6 header of the actual packets. It 
should be noted that the Shim6 layer does not modify the data packets, 
but because a constant ULID pair is presented to upper layers 
irrespective of the locator pair changes, the relation between the 
upper layer header (such as TCP, UDP, ICMP, ESP, etc) and the IPv6 
header is modified. In particular, if those data packets are TCP, UDP 
or ICMP packets, the presudoheader used for the checksum calculation 
will contain the ULID pair, rather than the locator pair contained in 
the data packet.

It is possible that some firewalls or other middle boxes try to verify 
the validity of upper layer sanity checks of the packet on the fly. If 
they do that based on the actual source and destination addresses 
contained in the IPv6 header without considering the Shim6 context 
information (in particular without replacing the locator pair by the 
ULID pair used by the Shim6 context) such verifications may fail. Those 
middle-boxes need to be updated in order to be able to parse the Shim6 
payload header and find the next header header after that.  It is 
recommended that firewalls and other middle-boxes do not drop packets 
that carry the Shim6 Payload header with apparently incorrect upper 
layer validity checks that involve the addresses in the IPv6 header for 
their computation, unless they are able to determine the ULID pair of 
the Shim6 context associated to the data packet and use the ULID pair 
for the verification of the validity check.

In the particular case of TCP, UDP and ICMP checksums, it is 
recommended that firewalls and other middle-boxes do not drop TCP, UDP 
and ICMP packets that carry the Shim6 Payload header with apparently 
incorrect checksums when using the addresses in the IPv6 header for the 
pseudoheader computation, unless they implement are able to determine 
the ULID pair of the Shim6 context associated to the data packet and 
use the ULID pair to determine the checksum that must be present in a 
packet with addresses rewritten by shim6.

would that be better?

Regards, marcelo

Delivery-date: Thu, 15 Mar 2007 06:27:14 +0000
Date: Wed, 14 Mar 2007 23:24:39 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Geoff Huston <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation

marcelo bagnulo braun wrote:

> Add a new section titled "Middle-boxes considerations" with the 
> following text.
> 
> Data packets belonging to a Shim6 context carrying the Shim6 Payload 
> Header contain alternative locators other than the ULIDs in the source 
> and destination address fields of the IPv6 header. However, if those 
> data packets are TCP or UDP packets, the presudoheader used for the 
> checksum calculation will contain the ULID pair, rather than the locator 
> pair contained in the data packet.

Same is true for the ICMPv6 pseudo-header. And I think the statement is 
a lot more general than an enumeration of protocols. All protocols 
sitting above the SHIM6 sub-layer would operate based on the ULIDs. Thus 
if you had a hypothetical middle-box that cracked open IKE and verified 
that the ESP/AH packets IP addresses + SPI that matched the IKE 
exchange, they could also potentially be confused by shim much the same 
way the TCP checksum verifying middlebox would be.

> It is possible that some firewalls or other middle boxes verify the 
> TCP/UDP checksum. Those middleboxes need to be updated in order to be 
> able to parse the Shim6 payload header and find the TCP/UDP header after 
> that. It is recommended that firewalls and other middleboxes do not drop 
> TCP, UDP and ICMP packets that carry the Shim6 Payload header with 
> apparently incorrect checksums when using the addresses in the IPv6 
> header for the pseudoheader computation, unless they implement 
> (monitoring of) the full shim6 protocol and are able to determine the 
> checksum that must be present in a packet with addresses rewritten by 
> shim6.
> 
> would this be ok/enough?

I have a hard time understanding the issue from the text. Could we make 
it a bit more explicit that the TCP and UDP packets aren't modified, but 
what is modified is relationship between the TCP/UDP/ICMP/ESP/etc header 
that follows the shim6 header, and the IPv6 header?

    Erik

Delivery-date: Wed, 14 Mar 2007 18:12:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Wrap-up: TCP checksum calculation
Date: Wed, 14 Mar 2007 11:08:42 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>, "Brian E Carpenter" <[email-masked]>, "Geoff Huston" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 2:31 PM
> To: marcelo bagnulo braun
> Cc: shim6-wg; Henderson, Thomas R; Brian E Carpenter; Geoff 
> Huston; Iljitsch van Beijnum
> Subject: Re: Wrap-up: TCP checksum calculation
> 
> marcelo bagnulo braun wrote:
> 
> > The problem is that shim6 payload packets that carry 
> locators different 
> > than ULIDs, will have the checksum calculated based on the 
> ULIDs and not 
> > on the actual addresses carried in the ipv6 header. This 
> would imply 
> > that any device in the middle (from NIC to middle boxes 
> (firewalls and 
> > TCP relays)) will fail the checksum verification (and drop 
> the packet). 
> > It is possible that TCP checksum verification is more common, since 
> > there is no IP checksum in IPv6.
> 
> I don't understand what the issue is.
> 
> The shim6 packets have a protocol/nexthdr field which is 
> shim6 and not 
> TCP, UDP, etc.
> 
> Thus an unmodified middlebox doesn't see a TCP packet - it 
> seems a to it 
> unknown IP protocol.
> 
> Only if the middlebox is modified to know about shim6 would 
> it be able 
> to skip the shim6 header to find the TCP, UDP, etc header.

My assumption was that there might be middleboxes capable of skipping
unknown extension headers to find the TCP.  The shim6 header has
NxtHdr/Length just like other extension headers.  Maybe this assumption
is unrealistic for IPv6-- I don't know.

> And a middlebox which is modified to know about shim6 could be aware 
> that the TCP/UDP etc checksums are different when there is a shim6 
> payload message before the TCP/UDP header.
> 

Yes, I support Marcelo's most recent text proposal.

Tom

Delivery-date: Wed, 14 Mar 2007 12:45:09 +0000
Date: Wed, 14 Mar 2007 13:44:18 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Erik Nordmark <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Geoff Huston <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation

On 2007-03-14 11:53, marcelo bagnulo braun wrote:
> 
> El 13/03/2007, a las 22:30, Erik Nordmark escribiÃ³:
> 
>> marcelo bagnulo braun wrote:
>>
>>> The problem is that shim6 payload packets that carry locators 
>>> different than ULIDs, will have the checksum calculated based on the 
>>> ULIDs and not on the actual addresses carried in the ipv6 header. 
>>> This would imply that any device in the middle (from NIC to middle 
>>> boxes (firewalls and TCP relays)) will fail the checksum verification 
>>> (and drop the packet). It is possible that TCP checksum verification 
>>> is more common, since there is no IP checksum in IPv6.
>>
>> I don't understand what the issue is.
>>
>> The shim6 packets have a protocol/nexthdr field which is shim6 and not 
>> TCP, UDP, etc.
> 
>> Thus an unmodified middlebox doesn't see a TCP packet - it seems a to 
>> it unknown IP protocol.
>>
>> Only if the middlebox is modified to know about shim6 would it be able 
>> to skip the shim6 header to find the TCP, UDP, etc header.
>> And a middlebox which is modified to know about shim6 could be aware 
>> that the TCP/UDP etc checksums are different when there is a shim6 
>> payload message before the TCP/UDP header.
>>
>>
>>> Proposed approach:
>>> First: Add a new section titled "Middle-boxes considerations" with 
>>> the following text.
>>> It is recommended that firewalls and other middleboxes do not drop 
>>> TCP, UDP and ICMP packets with apparently incorrect checksums based 
>>> on that fact alone unless they implement (monitoring of) the full 
>>> shim6 protocol and are able to determine the checksum that must be 
>>> present in a packet with addresses rewritten by shim6."
>>
>> If the above sentence was expanded to say that these TCP etc headers 
>> are the ones that follow a shim6 header, then it would be a useful 
>> addition.
>>
> 
> Add a new section titled "Middle-boxes considerations" with the 
> following text.
> 
> Data packets belonging to a Shim6 context carrying the Shim6 Payload 
> Header contain alternative locators other than the ULIDs in the source 
> and destination address fields of the IPv6 header. However, if those 
> data packets are TCP or UDP packets, the presudoheader used for the 
> checksum calculation will contain the ULID pair, rather than the locator 
> pair contained in the data packet.
> It is possible that some firewalls or other middle boxes verify the 
> TCP/UDP checksum. Those middleboxes need to be updated in order to be 
> able to parse the Shim6 payload header and find the TCP/UDP header after 
> that. It is recommended that firewalls and other middleboxes do not drop 
> TCP, UDP and ICMP packets that carry the Shim6 Payload header with 
> apparently incorrect checksums when using the addresses in the IPv6 
> header for the pseudoheader computation, unless they implement 
> (monitoring of) the full shim6 protocol and are able to determine the 
> checksum that must be present in a packet with addresses rewritten by 
> shim6.
> 
> would this be ok/enough?

I don't know how TCP relays work. If (as seems logical) they correctly
terminate the first hop of TCP, they could be shim6-capable (in which
case they will do the right thing). If they are not shim6-capable,
then shim6 will never be used by the originating host and we have
no problem.

On the other hand, if TCP relays mess with addresses and checksums
like a NAT does, the above text should apply.

So I think we are OK.

     Brian

Delivery-date: Wed, 14 Mar 2007 10:53:29 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Geoff Huston <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation
Date: Wed, 14 Mar 2007 11:53:17 +0100
To: Erik Nordmark <[email-masked]>

El 13/03/2007, a las 22:30, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>> The problem is that shim6 payload packets that carry locators 
>> different than ULIDs, will have the checksum calculated based on the 
>> ULIDs and not on the actual addresses carried in the ipv6 header. 
>> This would imply that any device in the middle (from NIC to middle 
>> boxes (firewalls and TCP relays)) will fail the checksum verification 
>> (and drop the packet). It is possible that TCP checksum verification 
>> is more common, since there is no IP checksum in IPv6.
>
> I don't understand what the issue is.
>
> The shim6 packets have a protocol/nexthdr field which is shim6 and not 
> TCP, UDP, etc.

> Thus an unmodified middlebox doesn't see a TCP packet - it seems a to 
> it unknown IP protocol.
>
> Only if the middlebox is modified to know about shim6 would it be able 
> to skip the shim6 header to find the TCP, UDP, etc header.
> And a middlebox which is modified to know about shim6 could be aware 
> that the TCP/UDP etc checksums are different when there is a shim6 
> payload message before the TCP/UDP header.
>
>
>> Proposed approach:
>> First: Add a new section titled "Middle-boxes considerations" with 
>> the following text.
>> It is recommended that firewalls and other middleboxes do not drop 
>> TCP, UDP and ICMP packets with apparently incorrect checksums based 
>> on that fact alone unless they implement (monitoring of) the full 
>> shim6 protocol and are able to determine the checksum that must be 
>> present in a packet with addresses rewritten by shim6."
>
> If the above sentence was expanded to say that these TCP etc headers 
> are the ones that follow a shim6 header, then it would be a useful 
> addition.
>

Add a new section titled "Middle-boxes considerations" with the 
following text.

Data packets belonging to a Shim6 context carrying the Shim6 Payload 
Header contain alternative locators other than the ULIDs in the source 
and destination address fields of the IPv6 header. However, if those 
data packets are TCP or UDP packets, the presudoheader used for the 
checksum calculation will contain the ULID pair, rather than the 
locator pair contained in the data packet.
It is possible that some firewalls or other middle boxes verify the 
TCP/UDP checksum. Those middleboxes need to be updated in order to be 
able to parse the Shim6 payload header and find the TCP/UDP header 
after that. It is recommended that firewalls and other middleboxes do 
not drop TCP, UDP and ICMP packets that carry the Shim6 Payload header 
with apparently incorrect checksums when using the addresses in the 
IPv6 header for the pseudoheader computation, unless they implement 
(monitoring of) the full shim6 protocol and are able to determine the 
checksum that must be present in a packet with addresses rewritten by 
shim6.

would this be ok/enough?

Regards, marcelo

>    Erik
>

Delivery-date: Tue, 13 Mar 2007 21:31:28 +0000
Date: Tue, 13 Mar 2007 14:30:52 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>, Thomas R Henderson <[email-masked]>, Brian E Carpenter <[email-masked]>, Geoff Huston <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: Wrap-up: TCP checksum calculation

marcelo bagnulo braun wrote:

> The problem is that shim6 payload packets that carry locators different 
> than ULIDs, will have the checksum calculated based on the ULIDs and not 
> on the actual addresses carried in the ipv6 header. This would imply 
> that any device in the middle (from NIC to middle boxes (firewalls and 
> TCP relays)) will fail the checksum verification (and drop the packet). 
> It is possible that TCP checksum verification is more common, since 
> there is no IP checksum in IPv6.

I don't understand what the issue is.

The shim6 packets have a protocol/nexthdr field which is shim6 and not 
TCP, UDP, etc.

Thus an unmodified middlebox doesn't see a TCP packet - it seems a to it 
unknown IP protocol.

Only if the middlebox is modified to know about shim6 would it be able 
to skip the shim6 header to find the TCP, UDP, etc header.
And a middlebox which is modified to know about shim6 could be aware 
that the TCP/UDP etc checksums are different when there is a shim6 
payload message before the TCP/UDP header.

> Proposed approach:
> 
> First: Add a new section titled "Middle-boxes considerations" with the 
> following text.
> 
> It is recommended that firewalls and other middleboxes do not drop TCP, 
> UDP and ICMP packets with apparently incorrect checksums based on that 
> fact alone unless they implement (monitoring of) the full shim6 protocol 
> and are able to determine the checksum that must be present in a packet 
> with addresses rewritten by shim6."

If the above sentence was expanded to say that these TCP etc headers are 
the ones that follow a shim6 header, then it would be a useful addition.

    Erik

Delivery-date: Tue, 13 Mar 2007 21:22:42 +0000
Date: Tue, 13 Mar 2007 14:20:55 -0700
From: Erik Nordmark <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: Geoff Huston <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
Subject: Re: State of play with Shim6 documents

Henderson, Thomas R wrote:

> For the data plane, I understand your point that it may be moot if the
> control plane were to be supported without modifications, if the data
> plane could not be.  However, I was thinking that judicious use of Linux
> netfilter could be used to insert the data plane shim.  In particular,
> the IP6 local in and local out hooks seem well positioned in the stack
> to support a shim6 shimming module.

If you do that, then you could use the same hook for all the shim6 
messages, right?

> My basic concern is that it would be nice to support shim6 without
> patching the Linux kernel, for deployment/experimental purposes.  It may
> be possible to make this work as defined now without a patched kernel.
> I think it may require some more complicated matching rules to divert
> shim6 control packets to user space while diverting shim6 data packets
> to a deshimming module, and making sure there is some way to inject the
> control plane packets from user space.  I suspect it will be harder to
> do the way it is defined, including for non-Linux systems, but perhaps
> not impossible.

There is a single bit in the shim6 header which says whether it is a 
payload message or something else. So it shouldn't be hard to have 
different rules.

> Since I understand the motivation you have here, I think it would be
> best to avoid speculating and experiment with the above to see if it can
> work.  I'll try to get some results in the next week or two and report
> back.

OK
    Erik

Delivery-date: Tue, 13 Mar 2007 15:32:44 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: error messages and silently discarding packets
Date: Tue, 13 Mar 2007 16:34:04 +0100

Hi,

one issue that was brought by Iljitsch  in his review is about error 
messages in shim6 and silently discarding packets

The issue is two folded:

First, shim6 protocol sends a error message in the following situations:
- when a node receives a critical option that is not recognized. In 
order to do that, it sends an an ICMP parameter problem (type 4, code 
1), with the Pointer referencing the first octet in the option Type 
field.
- when the verification method in the locator list option is not 
supported, then the host MUST ignore the Locator List and the message 
in which it is contained, and the host SHOULD generates an ICMP 
parameter problem (type 4, code 0), with the Pointer referencing the 
octet in the Verification method that was found inconsistent.
- when a node receives a I1 packet and it doesn't support the shim6 
protocol, it sends a  ICMP error with "Unrecognized Next Header" type 
(type 4, code 1)
-  If the Update message contains a Locator Preference option, then the 
Generation number in the preference option is compared with the peer 
generation number in the context.  If they do not match, then the host 
generates an ICMP parameter problem (type 4, code 0) with the Pointer 
field referring to the first octet in the Generation number in the 
Locator Preference option.  In addition, if the number of elements in 
the Locator Preference option does not match the number of locators in 
Ls(peer), then an ICMP parameter problem is sent with the Pointer 
referring to the first octet of the Length field in the Locator 
Preference option.  In both cases of failures, no further processing is 
performed for the Locator Update message.
- If a node receives a packet that contains a shim message type which 
is unknown to the receiver, then an ICMPv6 Parameter Problem error is 
generated and sent back.  The pointer field in the Parameter Problem is 
set to point at the first octet of the shim message type. The error is 
rate limited just like other ICMP errors [5].

The question is whether we should use ICMP error message or if we 
should define a shim6 error message within the shim6 protocol

Iljitsch suggested we do define such an error message, while the 
current spec uses ICMP error messages, what should we do?

Second, about silently discarding packets:

there are quite a few situations that the shim6 protocol silently 
discard packets that it considers an error or are not supported.

Those include:

- receiving I1, R1, I2, R2, R1bis, I2bis, Update request, Update ack, 
packets with less than 16 bytes or that do not comply with validity 
checks specified in section 12.2 (included below for your convenience 
:-)

- receiving a R1 packet that does not match to any context in I1-SENT 
state (not matching any requested context)

- receiving an I2 packet and that at least one of the following 
verifications fail
    Next the host verifies that the Responder Nonce is a recent one
    (Nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be
    considered recent), and that the Responder Validator option matches
    the validator the host would have computed for the ULID, locators,
    responder nonce, and FII.

    If a CGA Parameter Data Structure (PDS) is included in the message,
    then the host MUST verify if the actual PDS contained in the message
    corresponds to the ULID(peer).

- receiving an I2 message and the folloiwng situations occur
   situation 1
       If the state is I1-SENT, then the host verifies if the source
       locator is included in Ls(peer) or, it is included in the Locator
       List contained in the the I2 message and the HBA/CGA verification
       for this specific locator is successful

       *  If this is not the case, then the message is silently discarded
          and the context state remains unchanged.
   situation 2
       If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
       verifies if the source locator is included in Ls(peer) or, it is
       included in the Locator List contained in the the I2 message and
       the HBA/CGA verification for this specific locator is successful

       *  If this is not the case, then the message is silently discarded
          and the context state remains unchanged.

- receiving an R2 message and one of the following situations occur
    Upon the reception of an R2 message, the host extracts the Initiator
    Nonce and the Locator Pair from the message (the latter from the
    source and destination fields in the IPv6 header).  Next the host
    looks for an existing context which matches the Initiator Nonce and
    where the locators are Lp(peer) and Lp(local), respectively.  Based
    on the state:

    o  If no such context is found, i.e., the state is IDLE, then the
       message is silently dropped.

    o  If state is I1-SENT, I2-SENT, or I2BIS-SENT then the host performs
       the following actions: If a CGA Parameter Data Structure (PDS) is
       included in the message, then the host MUST verify that the actual
       PDS contained in the message corresponds to the ULID(peer) as
       specified in Section 7.2.  If the verification fails, then the
       message is silently dropped.

    o  If the state is ESTABLISHED, the R2 message is silently ignored,
       (since this is likely to be a reply to a retransmitted I2
       message).

- receiving an R1 bis in the following situations

    Upon the reception of an R1bis message, the host extracts the Packet
    Context Tag and the Locator Pair from the message (the latter from
    the source and destination fields in the IPv6 header).  Next the host
    looks for an existing context where the Packet Context Tag matches
    CT(peer) and where the locators match Lp(peer) and Lp(local),
    respectively.

    o  If no such context is not found, i.e., the state is IDLE, then the
       R1bis message is silently discarded.

    o  If the state is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis
       message is silently discarded.

- receiving an I2 bis message and the following situation occurs

   situation 1: one of the following verifications fail
    Next the host verifies that the Responder Nonce is a recent one
    (Nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be
    considered recent), and that the Responder Validator option matches
    the validator the host would have computed for the ULID, locators,
    responder nonce, and FII as part of sending an R1bis message.

    If a CGA Parameter Data Structure (PDS) is included in the message,
    then the host MUST verify if the actual PDS contained in the message
    corresponds to the ULID(peer).

    situation 2
    o  If the state is I1-SENT, then the host verifies if the source
       locator is included in Ls(peer) or, it is included in the Locator
       List contained in the the I2 message and the HBA/CGA verification
       for this specific locator is successful

       *  If this is not the case, then the message is silently
          discarded.  The the context state remains unchanged.

    situation 3
    If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
       verifies if the source locator is included in Ls(peer) or, it is
       included in the Locator List contained in the the I2 message and
       the HBA/CGA verification for this specific locator is successful

       *  If this is not the case, then the message is silently
          discarded.  The the context state remains unchanged.

- when receiving an Update ACK
   Any Update Acknowledgement which doesn't match the current request
    nonce, for instance an acknowledgement for the abandoned Update
    Request, will be silently ignored.

- when receiving an UPDATE request message and
    If a CGA Parameter Data Structure (PDS) is included in the message,
    then the host MUST verify if the actual PDS contained in the packet
    corresponds to the ULID(peer).  If this verification fails, the
    message is silently discarded.

So the question is whether people think that it is ok to silently 
discard in the above situations or we should send some erro message 
back. If the second option, please let me know in which situations you 
think we should sent an error message and which one

Thanks, marcelo

PS: Section 12.2 is included next

12.2.  Receiving Shim Control messages

    A shim control message has the checksum field verified.  The Shim
    header length field is also verified against the length of the IPv6
    packet to make sure that the shim message doesn't claim to end past
    the end of the IPv6 packet.  Finally, it checks that the neither the
    IPv6 destination field nor the IPv6 source field is a multicast
    address.  If any of those checks fail, the packet is silently
    dropped.

    The message is then dispatched based on the shim message type.  Each
    message type is then processed as described elsewhere in this
    document.  If the packet contains a shim message type which is
    unknown to the receiver, then an ICMPv6 Parameter Problem error is
    generated and sent back.  The pointer field in the Parameter Problem
    is set to point at the first octet of the shim message type.  The
    error is rate limited just like other ICMP errors [5].

    All the control messages can contain any options with C=0.  If there
    is any option in the message with C=1 that isn't known to the host,
    then the host MUST send an ICMPv6 Parameter Problem, with the Pointer
    field referencing the first octet of the Option Type.

Delivery-date: Tue, 13 Mar 2007 14:51:09 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Open issues in Re: shim6-proto-07 review
Date: Tue, 13 Mar 2007 15:52:22 +0100
To: Iljitsch van Beijnum <[email-masked]>

there are some open issues from Iljitsch review...

El 03/01/2007, a las 12:38, Iljitsch van Beijnum escribió:
>
>>>    the original locators become invalid at the same time and 
>>> depending
>>>    on the time that is required to update the DNS and for those 
>>> updates
>>>    to propagate.
>
>>> Why is the DNS relevant here?
>
>> because at least one valid locator must be published in the DNS in 
>> order for a shim host to be reachable, since the DNS is used as a 
>> rendez vous mechanism. OTOH, this is no specific of the shim6 
>> protocol, but generic for any host... do you prefer we remove the DNS 
>> consideration from here?
>
> I don't understand what you mean here... The way I see it, the stuff 
> that's in the DNS doesn't change when there are outages, only when 
> links are added to or removed from the site. As such, the DNS timing 
> is irrelevant except in the corner case where all existing links are 
> replaced by all new ones or all the links that don't change go down.
>

The text on the current draft states:

    When a host is renumbered, the effect is that one or more locators
    become invalid, and zero or more locators are added to the host's
    network interface.  This means that the set of locators that is used
    in the shim will change, which the shim can handle as long as not all
    the original locators become invalid at the same time and depending
    on the time that is required to update the DNS and for those updates
    to propagate.

i think this is accurate and the time required for changes in the DNS 
to propagate is a relevant factor when all addresses in a site are 
renumbered and i don't think there is problem leaving this here.

OTOH, i don't have a strong preference to keep this here.

Please suggest text if you think otherwise

>>> This makes me uncomfortable. How do you know that an address has 
>>> become terminally invalid, rather than accidentally unusable?
>
>> this was discussed during the last meeting in san diego and there was 
>> consensus that if a prefix is removed from the site, existing shim 
>> contexts that are using a ulid containing the prefix must be 
>> terminated when the prefix is removed.
>> however, i read from your comment is that you don't have a problem 
>> with this idea but your problem is with how to implement this, right?
>
> Indeed. The autoconfig protocols don't have a mechanism to see the 
> difference between a router going down accidentally and administrative 
> removal of prefixes, unless you want to add significant amounts of 
> guesswork to the mix. And that's something I don't think is a good 
> idea, especially considering that in SITE multihoming the chances of 
> clashing ULIDs after renumbering are near-zero.

i may agree with you here but there was a strong concensous in the San 
Diego meeting to prevent the usage of prefixes that are no longer 
available at the multihomed site, even as ULIDs.

So as long as i don't see strong concensous in the other sense, i will 
have to keep this as it is.

again, if you can suggest text for addressing this issue...

>
>> what about when the address becomes invalid?
>
> In many Unix stacks you can keep using an address even if it's removed 
> from all interfaces. This is a good thing, because it allows sessions 
> to survive short transitions such as moving out of radio range for a 
> few moments. With shim6 there is the potential that the address is 
> gone for a long time but it remains in use because the failure is 
> repaired using the shim.
>
> I think the best thing to do here is keep using the address for a 
> limited amount of time, like 1 - 24 hours.
>

same as before

many people argued that they do not want to use a ULID that is no 
longer assigned to the site

i think that this concensous still holds,

if you want, i can change the wording, so that the ULID is no longer 
used when the prefix is invalid, but when the prefix is no longer 
assigned to the site, would that be better?

>
>
>>>    Bidirectional Communication (FBD).  FBD uses a Keepalive message
>>>    which is sent when a host has received packets from its peer but 
>>> has
>>>    not yet sent any packets from its ULP to the peer.
>
>>> No, this works per address (per locator even, not per ULID, IIRC), 
>>> not per ULP.
>
>> the meaning here is that FBD generates packets when the ULPs are 
>> silent. It doesn't mean that it generates packets per ULP, just that 
>> when all ULPs are silent, FBD generates packets. It may be rephrased 
>> as follows:
>
>>    FBD uses a Keepalive message
>>    which is sent when a host has received packets from its peer but 
>> has
>>    not yet sent any packets from any of its ULPs to the peer.
>
>> would this be better?
>
> No, because I don't see what the ULP has to do with anything. FBD is 
> between address pairs.
>

could you suggest text to describe more precisely what FBD does?

>>> So what happens when some other header follows the shim header? 
>>> Could this be used for attacks?
>
>> this is for shim6 control messages and so far we haven't defined 
>> means to perform piggybacking of other protocols in shim6 control 
>> messages, so it is not possible for other protocols to follow the 
>> shim header. If this is defined in future extensions, they will need 
>> to update this part of the spec
>
> Well, wouldn't it be better then to forbid having additional headers 
> after the shim header?

i don't think we need to take such a measure unless we identify what 
would be the attack that this could open

I mean, piggybacking seems a nice to have feature in the future, so 
imho we need a strong reason to close that door, don't you agree?

>
>>> About the different messages: they are very similar. If I were to 
>>> implement all of this, I would rather work with one basic structure 
>>> for all of the messages, even if the _meaning_ of some fields is 
>>> different as long as their structure is always the same. I think 
>>> this can easily be done here, by including fields that nearly all 
>>> messages need (simply leave it zero when a particular message 
>>> doesn't need a field) and use options for things that a particular 
>>> message needs that aren't accommodated in the unified structure.
>
>> i can clearly see the cost of this approach, additional overhead for 
>> unused fields and potential source of confusion when fields change 
>> their name... what is the advantage of such approach?
>
> When you write an implementation, you need to extract all the values 
> from a header. Since these are all different sizes without natural 
> alignment this involves some complexity. When there are different 
> message headers, you need to do this multiple times. If there is only 
> one message header, you only have to implement the value extraction 
> code once.
>
> The field names aren't an issue at all. In code it works something 
> like this:
>
> void getheaders(int *field1, char *field2, unsigned int *field3);
>
> void lookatmessage1()
> {
>   int contexttag;
>   char evilbit;
>   unsigned int remotecookie;
>
>   getheaders(&contexttag, &evilbit, &remotecookie);
>   if (evilbit)
>     printf("You are breaking Evil Corp.'s patent, prepare to be 
> sued!\n");
> }
>
> void lookatmessage2()
> {
>   int contexttag;
>   char ossbit;
>   unsigned int localcookie;
>
>   getheaders(&contexttag, &ossbit, &localcookie);
>   if (!ossbit)
>     printf("You are breaking the GPL, prepare to be sued!\n");
> }
>
> Since the formats are so similar already there are only 1 or 2 cases 
> where an unused field would be included so I don't think the overhead 
> is a concern.
>

I am not sure what to do with this.... maybe we can have some feedback 
from the people working on implementations...

>>> update request: why is this a request?
>
>> because this is a two way protocol, update and request... (i do agree 
>> that it is not the best name in this case... suggestion?)
>
> Just "update"?
>
>>> Hm, is it smart to defer verification here?
>
>> depending what verification we are talking about....
>
>> this is explained in detail in section 7.2.  Locator Verification
>
>> there are two type of verification HBA/CGA verification is one type 
>> and the other type is the one against flooding attakcs that is 
>> achived using a probe packets (of the path exploration protocol)
>
>> The spec in section 7.2 states that:
>
>>    Thus the HBA/CGA
>>    verification SHOULD be performed by the host before the host
>>    acknowledges the new locator, by sending an Update Acknowledgement
>>    message, or an R2 message.
>
>>    Before a host can use a locator (different than the ULID) as the
>>    destination locator it MUST perform the HBA/CGA verification if 
>> this
>>    was not performed before upon the reception of the locator set.  In
>>    addition, it MUST verify that the ULID is indeed present at that
>>    locator.  This verification is performed by doing a return-
>>    routability test as part of the Probe sub-protocol [9].
>
>> makes sense?
>
> Is it useful to be able to defer locator verification? Simply doing it 
> immediately and either acknowledging that everything is ok or sending 
> back an error is much more robust than saying nothing and failing 
> later.

In its current form the spec allows for deferred until it is really 
necesary, but it doesn't require to deffer it. Besides it reccomends 
that the verification that does not requires additional packet exchange 
is prefroemd before sending the ACK.

I think this is enough, since we allow implementations to decide 
whether to wait until is needed to perform the reachability 
verification that will be needed in any case before using the locator 
pair, in order verify that is actually reachable.

So i suggest keeping it in its current form

>
>> When the traffic generated by the ULPs results in a bidirectional 
>> flow of packet between the peers, no extra packets need to be 
>> inserted.
>
>> is this ok?
>
> No, it's still confusing. Why not leave this up to the reachability 
> draft?

I think it would be useful to have a hint of how this works in this 
document... could you suggest some text that you don't find confusing?

>
>>> Ugh, this is certainly enough to make a grown man cry... Why all of 
>>> this alignment silliness? BGP works pretty well without it.
>
>> i think this is general in IPv6 protocols which are optimized for 
>> handling 64 bits units.... but maybe someone with more expertise can 
>> answer this one...
>
> Believe me, implementations aren't going to be any simpler because of 
> all the padding and length calculations, and the amounts of data 
> involved are so small that having faster copying because of the 
> alignment isn't an issue.
>

i would like some feedback from other in this one...

I would preffer not changing  all the packet format at this stage... 
really

> [...]
>
>>> More in general, most error conditions are handled by silently 
>>> dropping packets, however, which is a very bad idea because that 
>>> way, there is no difference between an error and lost messages.
>
> [...]
>
>> sent this issue in a separate email
>
> IIRC this mail doesn't go into the issue of silently dropping 
> messages, so I'll restate my objection to that here.
>

ok, will try to address this issue along with the error message issue

>>> About the locator option: how many locators are allowed?
>
>> there is no upper limit other than the ones that fit inside a packet 
>> with the other required options... As i mentioned above, roughly this 
>> seemed enough not to become a limitation
>
> Some limit might be helpful, though.
>

why?
>
>>> Regarding section 7.9: shouldn't there be checks to make sure that 
>>> seemingly duplicate packets contain the same information as the 
>>> earlier packets they are supposedly the duplicate of?
>
>> I am not following you here...
>
>> are we talking about an initiator that receives a duplicate R1 back 
>> or a receiver that receives a duplicate I1?
>
>> If a receiver receives a duplicate I1 it doesn't do anything special, 
>> just replies with a R1. don't see any problem here
>
> So the issue whether it's a duplicate is irrelevant because the reply 
> is the same either way?
>

yes

>> If an initiator receives a duplicated R1 (this may be due that the 
>> initiator have retried with multiple I1), it will process the first 
>> one received, and send a I2. The second one received, there will be 
>> no shim6 context in I1-SENT state, so it will be discarded. I do not 
>> see the point in verifying that the other information in the packet 
>> is ok or not... what would be the point in doing this verification?
>
> If you have special case handling for duplicates it's important to be 
> sure that you're actually dealing with duplicates. For instance, an 
> attack could be sending out fake shim6 packets so that when the real 
> ones come in later, those are rejected because they are presumed 
> duplicates.
>

agree but in this case, the R1 contains the INIT nonce that prevents 
such attack. So while it is not verified that the second R1 is a replay 
of the first one, but that any R1 received is a proper reply of the 
initial I1 sent. I think this provides the required protection

>>> What if validators don't match? Eventually this shouldn't be a 
>>> problem but I expect some initial trouble here because you're doing 
>>> hashes over a fairly large number of values, a small mistake 
>>> somewhere means the hash doesn't work, some feedback in the form of 
>>> an error message would be good.
>
>> you mean for the first packet or for the following (duplicated)  
>> packets? for the first packet, this is a specific case of the general 
>> problem about whether it is ok to silently discard wrong packets 
>> (that i have initiated a new thread for this)
>> For the second case, i don't see any point on doing this...
>
> Initial = when implementations first appear.
>
> It's important that people know what's going on in order to debug 
> problems, not only when doing interoperability testing, but also "in 
> the wild" later on.
>

ok, this is part of the silently discarding packets when there is an 
error issue, that is discussed in other thread.

>
>>> Adn why verify whether the source address is in Ls(peer)? The 
>>> security mechanisms do all the checking we need.
>
>> could you point me where is the text you are referring to? i mean 
>> there is no such verification in section 7.15 which was the section 
>> the previous comment was referring to...
>
> Page 59:
>
>    If such a context exists in ESTABLISHED state, the host verifies 
> that
>    the locator of the Initiator is included in Ls(peer) (This check is
>    unnecessary if there is no ULID-pair option in the I1 message).
>
> Page 63:
>
>    o  If the state is I1-SENT, then the host verifies if the source
>       locator is included in Ls(peer) or, it is included in the Locator
>       List contained in the the I2 message and the HBA/CGA verification
>       for this specific locator is successful
>

> Page 69:
>
>    o  If the state is I1-SENT, then the host verifies if the source
>       locator is included in Ls(peer) or, it is included in the Locator
>       List contained in the the I2 message and the HBA/CGA verification
>       for this specific locator is successful
>
>
>    o  If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the 
> host
>       verifies if the source locator is included in Ls(peer) or, it is
>       included in the Locator List contained in the the I2 message and
>       the HBA/CGA verification for this specific locator is successful
>
> Page 74:
>
>    Since context tags can be reused, the host MUST verify that the IPv6
>    source address field is part of Ls(peer) and that the IPv6
>
> Page 76:
>
>    Since context tags can be reused, the host MUST verify that the IPv6
>    source address field is part of Ls(peer) and that the IPv6
>    destination address field is part of Ls(local).
>
> Page 81:
>
>    o  Other control messages (Update, Keepalive, Probe): Deliver to the
>       context with CT(local) equal to the Receiver Context Tag included
>       in the packet.  Verify that the IPv6 source address field is part
>       of Ls(peer) and that the IPv6 destination address field is part 
> of
>       Ls(local).  If not, send a R1bis message.
>

The security checks that you mention, verify that the locators 
contained in the locator set are bound to the ULID.

These checks that you point out below, check if the particular locator 
that is being used for sending the packets belongs to the locator set 
that has previously been bound to the ULID.

So, this is needed in order to avoid accepting packets coming from any 
source address that is not included in the verified locator set.

>>>    NO_R1_HOLDDOWN_TIME = 1 min
>
>>>    ICMP_HOLDDOWN_TIME = 10 min
>
>>> This seems rather short, basically a shim host talking to a non-shim 
>>> host would retry setting up the shim every minute or every 10 
>>> minutes even though there is good reason to assume this won't be 
>>> successful. Something like several hours seems more appropriate. 
>>> (And only when packets are actively exchanged.)
>
>> well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we 
>> retry when no R1 have been received. Note that this may be due to 
>> network outages that can be solved in a short time. So, we have a 
>> good reason to assume this will be successful, someone fixed the 
>> network path :-)
>
>> in the other case, i agree, what about:
>
>>    NO_R1_HOLDDOWN_TIME = 5 min
>
>>    ICMP_HOLDDOWN_TIME = 60 min
>
> The case where a firewall silently filters the packets is much more 
> likely. I still find what you list above rather short.
>

can you suggest values for the above parameters?

>>> The Locator List Option Format only specifies two verification 
>>> methods at this time: CGA or HBA. What about the case where a 
>>> locator can be verified using either CGA or HBA? Maybe it makes more 
>>> sense to have each method be a bit so they can be present or absent 
>>> independently.
>
>> if this turns to be useful we could define a verification code that 
>> would be CGA or HBA but i don't see why this would be useful... do 
>> you?
>
> I guess you can argue that if HBA verification is possible, there is 
> never a need to do CGA verification.
>
> Still, I think having bits for this rather than a single code is good 
> for two reasons:
>
> 1. In case someone wants to implement either HBA or CGA but not both 
> for IPR reasons, then it becomes useful to announce both HBA and CGA 
> capability
>
> 2. So that when in the future a new verification method is introduced 
> that obviously isn't universally implemented but is better than 
> CGA/HBA in some way, so that people may want to take advantage of the 
> new method when supported but fall back on HBA/CGA if not
>

so the open issue here would be to define a code 3 of verification that 
would be HBA or CGA?

is that the proposal?

Delivery-date: Tue, 13 Mar 2007 14:45:31 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8 resulting from: Re: shim6-proto-07 review
Date: Tue, 13 Mar 2007 15:46:19 +0100
To: Iljitsch van Beijnum <[email-masked]>

Hi,

these are the changes that i am including in version 8 of the draft 
based on the comments made in this review.
(besides thos that i have addressed in separate emails)

El 11/12/2006, a las 19:54, Iljitsch van Beijnum escribió:
>
>
>
>    o  Have minimal impact on upper layer protocols in general and on
>       transport protocols in particular.
>
> And applications.
>

done

>
> Early in the text, the phrase "site multihoming" is used. There has 
> been some discussion on this list as to whether shim6 actually is site 
> multihoming, and readers of the draft may not know that all of this is 
> the result of wgs chartered to work on "site" multihoming. So I 
> suggest adding text to clear up any potential confusion, for example:
>
> "The shim protocol is a site multihoming solution in the sense that it 
> allows existing communication to continue when a site that has 
> multiple connections to the internet experiences an outage on a subset 
> of these connections or further upstream. However, shim processing is 
> performed in individual hosts rather than through site-wide 
> mechanisms."
>
>

added in the introduction

>    Finally, this proposal also does not try to provide a new network
>    level or transport level identifier name space distinct from the
>    current IP address name space.
>
> The terms "identifier" and "locator" are used extensively even though 
> the shim is NOT an actual identifier/locator separation solution... 
> Suggested text (immediately following the sentence above):
>
> "The shim proposal doesn't fully separate the identifier and locator 
> functions that have traditionally been overloaded in the IP address. 
> However, throughout this document the term "identifier", or more 
> specifically, Upper Layer Identifier (ULID) refers to the identifying 
> function of an IPv6 address, and "locator" to the network layer 
> routing and forwarding properties of an IPv6 address."
>

added the paragraph in the suggested place

>
>    solution.  While this document doesn't specify all aspects of this,
>    it is believed that the approach can be extended to handle the non-
>    routable address case..
>
> Extra period. (Note that the quaint custom of inserting an extra space 
> after a sentence is generally "discouraged" in style manuals.)
>

removed extra period

>
>
>    But IP addresses are also used as ULID,
>
> Addresses is plural, ULID singular... Probably make this "ULIDs".
>

done
>
>
>    layer map to/from different locators.  The shim6 layer maintains
>    state, called ULID-pair context, per ULID pairs
>
> "Pairs" should probably be singular.
>

done

>
>    fields, and even though those locators may be changed by the
>    transmitting shim6 layer. .
>
> Extra  .
>

done

>
>    Inherent in a scalable multihoming mechanism that separates locators
>    from identifiers is that each host ends up with multiple locators.
>
> This says explicitly that we do id/loc...
>

rephrased as

Inherent in a scalable multihoming mechanism that separates the locator
function of the IP address from
identifying function of the IP address is that each host ends up with 
multiple locators.
This means that at least for initial contact, it is the remote peer that
needs to select which peer locator to try first. In the case of Shim6 
this
is performed by applying RFC 3484 address selection

>
>    This means that at least for initial contact, it is the remote peer
>    that needs to select which peer locator to try first.  In the case 
> of
>    shim6 this is performed by applying RFC 3484 address selection.
>
> This is incorrect: the application (or layer working on its behalf) 
> needs to select an initial ULID, which automatically becomes the 
> initial locator.
>
>

rephrased as

This means that at least for initial contact, it is the remote peer 
application
(or layer working on its behalf) needs to select an initial ULID,
which automatically becomes the initial locator. In the case of Shim6 
this
is performed by applying RFC 3484 address selection.

>
>    document), such as having the ISPs relax there ingress filters, or
>    selecting the egress such that it matches the IP source address
>    prefix.
>
> There -> their
>

done

>
>    o  Some heuristic on A or B (or both) determine that it is
>       appropriate to pay the shim6 overhead to make this host-to-host
>       communication robust against locator failures.  For instance, 
> this
>       heuristic might be that more than 50 packets have been sent or
>       received, or a timer expiration while active packet exchange is 
> in
>       place.  This makes the shim initiate the 4-way context
>       establishment exchange.
>
> Maybe say something like:
>
> "The purpose of this heuristic is to avoid setting up a shim context 
> when only a small number of packets is exchanged between two hosts."
>
>

added the above sentence in the suggested place

>       If the context establishment exchange fails, the initiator will
>       then know that the other end does not support shim6, and will
>       continue with standard unicast behavior for the session.
>
> Unicast? Shouldn't this be "single homed"?

changed to standard (non-shim6) behaviour

>
>
>    context tag is a 47-bit number (the largest which can fit in an
>    8-octet extension header).
>
> "while preserving one bit to differentiate the shim signalling 
> messages from the shim header included in data packets, allowing both 
> to use the same protocol number."
>
>

added

>
>       Such discovery probably requires to be along the path in order to
>       be sniff the context tag value.
>
> Grammar: clause without subject. Who is required to be along the path?
>
>

rephrased as

  Such discovery probably requires any potential attacker 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.

>    dynamic.  For this reason there is a Update Request and Update
>    Acknowledgement messages, and a Locator List option.
>
> Grammar. "is a" -> "are" would be better.
>

done

>
>
> 5.13.  Probe Message Format
>
>    This message and its semantics are defined in [9].
>
>    The idea behind that mechanism is to be able to handle the case when
>    one locator pair works in from A to B, and another locator pair 
> works
>    from B to A, but there is no locator pair which works in both
>    directions.  The protocol mechanism is that as A is sending probe
>    messages to B, B will observe which locator pairs it has received
>    from and report that back in probe messages it is sending to A.
>
> No, this is to test whether locator pairs work or not in the general 
> case.
>

rephrased as

The goal of this mechanism is to test whether locator pairs work or
    not in the general case. In particular, this mechanism
is to be able to handle the case when one locator pair works in from A 
to B,
and another locator pair works from B to A, but there is no locator pair
which works in both directions. The protocol mechanism is that as A is 
sending
probe messages to B, B will observe which locator pairs it has received
from and report that back in probe messages it is sending to A.

>
>
>    Consequently, the Length field indicates the length of the Contents
>    field (in bytes).  The total length of the TLV parameter (including
>    Type, Length, Contents, and Padding) is related to the Length field
>    according to the following formula:
>
>    Total Length = 11 + Length - (Length + 3) % 8;
>
> This is almost impossible to understand.
>
> First of all, this assumes familiarity with C or a similar language 
> from the reader to note that % is the modulo operation and that it 
> binds stronger than subtraction. As such, this would be an 
> improvement:
>
> Total Length = 11 + Length - ((Length + 3) mod 8)
>
> However, the logic that underpins this is never spelled out, apart 
> from the requirement that all options be a multiple of 8 bytes long. 
> (Yes, _bytes_, not octets.)
>
> Text:
>
> "The Total Length of the option is the smallest multiple of 8 bytes 
> that allows for the 4 bytes of option header and the option itself. 
> The amount of padding required can be calculated as follows:
>
> padding = 7 - ((Length + 3) mod 8)
>
> And:
>
> Total Length = 4 + Length + padding"
>

added the suggest text and modifications

>
>    The responder can choose exactly what input is used to compute the
>    validator, and what one-way function (MD5, SHA1)
>
> Or something else, I presume? So "(such as MD5 or SHA-1)"
>

done

>
> About the locator option: how many locators are allowed?
>
>
>       TEMPORARY: 0x02
>
>    The intent of the BROKEN flag is to inform the peer that a given
>    locator is known to be not working.  The intent of TEMPORARY is to
>    allow the distinction between more stable addresses and less stable
>    addresses when shim6 is combined with IP mobility, when we might 
> have
>    more stable home locators, and less stable care-of-locators.
>
> So this has nothing to do with RFC 3041 temporary addresses? In that 
> case, a different name is probably better.
>

changed the name of TEMPORATY flag to TRANSIENT flag

>
>    o  For each peer locator, a bit whether it has been verified using
>       HBA or CGA, and a bit whether the locator has been probed to
>       verify that the ULID is present at that location.
>
> "Flag" rather than "bit"?
>

changed to flag

>
>    In all the cases the result is that the peer without state receives 
> a
>    shim message for which it has to context for the context tag.
>
> To -> no?
>

changed

>
>    case we can not use the recovery mechanisms since there needs to be
>    separate context tags for the two ULID pairs.
>
> Needs -> need
>

done

>
> About the randomness of the context tag: I don't think we have to 
> require that the entire context tag random in a cryptographically 
> strong sense. If this makes implementation easier, why not allow an 
> implementation to use part of the CT to be used as a lookup key (which 
> is relatively easy to predict) as long as enough bits are really 
> random? In my opinion, 20 good random bits is enough here. Suggested 
> text (but no suggested place to put it):
>
> "It is important that context tags are hard to guess for off-path 
> attackers. Therefore, if an implementation uses structure in the 
> context tag to facilitate efficient lookups, at least 20 bits of the 
> context tag must be unstructured and populated by completely random 
> bits. For this purpose, bits derived from one of the generally used 
> one-way hash functions such as SHA-1 may be considered random.
>
>

added the text in section Uniqueness of Context Tags, resulting in:

<section title="Uniqueness of Context Tags" anchor="context-tag">

<t>As part of establishing a new context, each host has to assign a 
unique
context tag. Since the Payload Extension headers are demultiplexed based
solely on the context tag value (without using the locators), the 
context
tag MUST be unique for each context.
</t>

<t>It is important that context tags are hard to guess for off-path 
attackers.
Therefore, if an implementation uses structure in the context tag to
facilitate efficient lookups, at least 30 bits of the context tag MUST 
be
unstructured and populated by completely random bits.</t>

<t>In addition, in order to minimize the reuse of context tags, the host
SHOULD
randomly cycle through the unstrucutred tag name space reserved
for randomly assigned context tag values,(e.g. following the
guidelines described in <xref target='RFC4086'/>).</t>

>
>
>    network transit path.  Second, in case that IPSec is implemented as
>    Bump-In-The-Wire (BITW) [7] it is expected that the shim6 sub-layer
>    is also implemnted in the same fashion.
>
> Not strong enough:
>
> "in case that IPSec is implemented as Bump-In-The-Wire (BITW) [7], 
> either the shim MUST be disabled, or the shim MUST also be implemented 
> as Bump-In-The-Wire, in order to satisfy the requirement that IPsec is 
> layered above the shim."
>

done

>
>       could require a 2-way handshake "did you really loose the state?"
>       in response to the error message.
>
> lose
>
>

done

>    o  The validator included in the R1 and R1bis packets are generated
>       as a hash of several input parameters.  However, most of the
>       inputs are actually determined by the sender, and only the secret
>       value S is unknown to the sender.  However, the resulting
>       protection is deemed to be enough since it would be easier for 
> the
>       attacker to just obtain a new validator sending a I1 packet than
>       performing all the computations required to determine the secret
>       S. However, it is recommended that the host changes the secret S
>       periodically.
>
> Too many howevers...
>

agree

rephrased as

    <t> The validator included in the R1 and R1bis packets are generated
    as a hash of several input parameters. While most of the inputs are
    actually determined by the sender, and only the secret value S is 
unknown
    to the sender, the resulting protection is deemed to be enough
    since it would be easier for the attacker to just obtain a new
    validator sending a I1 packet than performing all the computations
    required to determine the secret S. Nevertheless, it is recommended 
that the host
    changes the secret S periodically.
    </t>

>
>    o  Study whether a host explicitly fail communication when a ULID
>       becomes invalid (based on RFC 2462 lifetimes or DHCPv6), or 
> should
>       we let the communication continue using the invalidated ULID (it
>       can certainly work since other locators will be used).
>
> Some kind of grammar problem, not obvious to me what is meant here.
>

removed the paragraph

>
>
>    that the Flow Label carries context information as proposed in the
>    now expired NOID draft. .
>
> Extra  .
>
removed

>
>    It may happen, that later on, one of the hosts, e.g.  Host A looses
>    the shim context.
>
> loses
>

done

>
>    Mechanisms for detecting context. loss
>
> Extra word?
>
>

done

>
>    approach eliminates the possibility of a context confusion situation
>    because premature garbage collection, but it does not prevents
>
> prevent
>

done

>
>    [9]  Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
>         Exploration Protocol for IPv6  Multihoming",
>
> Please make this "I. van Beijnum"
>

will try, but note that the reference in the xml directory is imported 
this way

Let me know about any issue about the comments addressed in this email

I will send a separate email with open issues from this review

thanks again for the review

Regards, marcelo

Delivery-date: Tue, 13 Mar 2007 05:44:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Wrap-up: TCP checksum calculation
Date: Mon, 12 Mar 2007 22:43:14 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, "shim6-wg" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>, "Geoff Huston" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Marcelo,
Your proposal seems to be a reasonable way to provide a possible future
remedy if the problem arises.

Tom 

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Saturday, March 10, 2007 11:12 AM
> To: shim6-wg
> Cc: Henderson, Thomas R; Brian E Carpenter; Geoff Huston; 
> Iljitsch van Beijnum
> Subject: Wrap-up: TCP checksum calculation
> 
> Hi,
> 
> this has been an interesting discussion
> 
> Let me see if i can propose a way forward.
> 
...

Delivery-date: Tue, 13 Mar 2007 05:41:55 +0000
Content-class: urn:content-classes:message
Subject: RE: State of play with Shim6 documents
Date: Mon, 12 Mar 2007 22:39:14 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Geoff Huston" <[email-masked]>, "shim6-wg" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 2:26 PM
> To: Henderson, Thomas R
> Cc: Geoff Huston; shim6-wg; [email-masked]
> Subject: Re: State of play with Shim6 documents
> 
> Henderson, Thomas R wrote:
> 
> > Besides the fragmentation issue, the way it is defined now, it seems
> > burdensome to implementations that want to implement the 
> shim6 control
> > plane as a user-space daemon (as opposed to defining a 
> separate protocol
> > number for shim6 control messages).  My reading of IPv6 raw sockets
> > semantics suggests that they cannot be used.
> > 
> > from RFC 3542:
> > "With IPv6 raw sockets will be
> >    used for ICMPv6 and to read and write IPv6 datagrams containing a
> >    Next Header field that the kernel does not process."
> > 
> > This is not the case for shim6 since the kernel does 
> process the payload
> > extension header in the data plane.
> > 
> > Under current definition, how should a user-space shim6 
> implementation
> > use IPv6 sockets API to get only the control messages?  If 
> there isn't
> > an easy way, should we consider to separate the protocol numbers?  
> 
> Thomas,
> 
> Are you saying that the *only* thing that prevents a complete shim6 
> user-space implementation using standard APIs is the fact that shim6 
> uses a single protocol number? I find that very hard to 
> believe since I 
> don't know of any standard APIs that allow me to insert the transmit 
> side data plane of shim6 in the transmit path. The API RFCs clearly 
> don't have such a mechanism, nor does the socket standard 
> from the open 
> group. Thus a user space shim6 implementation would require some 
> non-standard extensions and/or modifications to the stack. 
> Given that, I 
> suspect one can figure out how to handle the above issue as well.

No, I was talking about the control plane only, that it would be
convenient to define a protocol number so that raw sockets could be used
to generate and consume those messages.

For the data plane, I understand your point that it may be moot if the
control plane were to be supported without modifications, if the data
plane could not be.  However, I was thinking that judicious use of Linux
netfilter could be used to insert the data plane shim.  In particular,
the IP6 local in and local out hooks seem well positioned in the stack
to support a shim6 shimming module.

My basic concern is that it would be nice to support shim6 without
patching the Linux kernel, for deployment/experimental purposes.  It may
be possible to make this work as defined now without a patched kernel.
I think it may require some more complicated matching rules to divert
shim6 control packets to user space while diverting shim6 data packets
to a deshimming module, and making sure there is some way to inject the
control plane packets from user space.  I suspect it will be harder to
do the way it is defined, including for non-Linux systems, but perhaps
not impossible.

> 
> The reason for using a single protocol number for shim6 is to 
> increase 
> the probability of uniform handling by existing firewalls. 
> With a single 
> protocol number existing firewalls would probably either let all such 
> packets through, or block all of them. If we chose to instead use 
> multiple protocol numbers there is the danger that some 
> packets (such as 
> the context establishment packets) make it through the firewall while 
> others (such as the payload packets) are blocked. That 
> possibility adds 
> a new failure mode which is hard to deal with, especially if 
> the probe 
> messages get the same firewall treatment as the context establishment 
> packets.
> 

Since I understand the motivation you have here, I think it would be
best to avoid speculating and experiment with the above to see if it can
work.  I'll try to get some results in the next week or two and report
back.

Tom

Delivery-date: Mon, 12 Mar 2007 21:27:45 +0000
Date: Mon, 12 Mar 2007 14:26:07 -0700
From: Erik Nordmark <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: Geoff Huston <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
Subject: Re: State of play with Shim6 documents

Henderson, Thomas R wrote:

> Besides the fragmentation issue, the way it is defined now, it seems
> burdensome to implementations that want to implement the shim6 control
> plane as a user-space daemon (as opposed to defining a separate protocol
> number for shim6 control messages).  My reading of IPv6 raw sockets
> semantics suggests that they cannot be used.
> 
> from RFC 3542:
> "With IPv6 raw sockets will be
>    used for ICMPv6 and to read and write IPv6 datagrams containing a
>    Next Header field that the kernel does not process."
> 
> This is not the case for shim6 since the kernel does process the payload
> extension header in the data plane.
> 
> Under current definition, how should a user-space shim6 implementation
> use IPv6 sockets API to get only the control messages?  If there isn't
> an easy way, should we consider to separate the protocol numbers?  

Thomas,

Are you saying that the *only* thing that prevents a complete shim6 
user-space implementation using standard APIs is the fact that shim6 
uses a single protocol number? I find that very hard to believe since I 
don't know of any standard APIs that allow me to insert the transmit 
side data plane of shim6 in the transmit path. The API RFCs clearly 
don't have such a mechanism, nor does the socket standard from the open 
group. Thus a user space shim6 implementation would require some 
non-standard extensions and/or modifications to the stack. Given that, I 
suspect one can figure out how to handle the above issue as well.

The reason for using a single protocol number for shim6 is to increase 
the probability of uniform handling by existing firewalls. With a single 
protocol number existing firewalls would probably either let all such 
packets through, or block all of them. If we chose to instead use 
multiple protocol numbers there is the danger that some packets (such as 
the context establishment packets) make it through the firewall while 
others (such as the payload packets) are blocked. That possibility adds 
a new failure mode which is hard to deal with, especially if the probe 
messages get the same firewall treatment as the context establishment 
packets.

    Erik

Delivery-date: Mon, 12 Mar 2007 11:02:41 +0000
Date: Mon, 12 Mar 2007 12:01:33 +0100
From: Thierry Ernst <[email-masked]>
To: ml-ietf-shim6 <[email-masked]>
Cc: tj <[email-masked]>
Subject: Cross-Reviews of draft-ietf-nemo-multihoming-issues
Organization: INRIA

Dear Shim6 members,

We submitted an updated version of draft-ietf-nemo-multihoming-issues
which already passed WGLC a while ago. We now need this draft to be
cross-reviewed before it could hopefully be sent to the IESG.

A review from someone in the Shim6 WGs would be particularly useful.
Would one of you be able to review it by the IETF meeting in Prague ?
If so, please let us know.

Thanks in advance,
NEMO Chairs.

On Wed, 07 Feb 2007 15:50:02 -0500
[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Network Mobility Working Group of the IETF.
>
>	Title		: Analysis of Multihoming in Network Mobility Support
>	Author(s)	: C. Ng, et al.
>	Filename	: draft-ietf-nemo-multihoming-issues-07.txt
>	Pages		: 48
>	Date		: 2007-2-7
>	
>This document is an analysis of multihoming in the context of network
>   mobility (NEMO) in IPv6.  As there are many situations in which
>   mobile networks may be multihomed, a taxonomy is proposed to classify
>   the possible configurations.  The possible deployment scenarios of
>   multihomed mobile networks are described together with the associated
>   issues when network mobility is supported by RFC 3963 (NEMO Basic
>   Support).  Recommendations are offered on how to address these
>   issues.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt

The HTML version is available at:
http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/draft-ietf-nemo-multihoming-issues-07.html

Delivery-date: Mon, 12 Mar 2007 08:39:00 +0000
From: "Alvaro Vives" <[email-masked]>
To: "'shim6-wg'" <[email-masked]>
Subject: RE: Wrap-up: TCP checksum calculation
Date: Mon, 12 Mar 2007 09:35:54 +0100
Reply-To: [email-masked]

Hi Marcelo,

> 
> this has been an interesting discussion
> 
> Let me see if i can propose a way forward.
> 
> The problem is that shim6 payload packets that carry locators different
> than ULIDs, will have the checksum calculated based on the ULIDs and
> not on the actual addresses carried in the ipv6 header. This would
> imply that any device in the middle (from NIC to middle boxes
> (firewalls and TCP relays)) will fail the checksum verification (and
> drop the packet). It is possible that TCP checksum verification is more
> common, since there is no IP checksum in IPv6.
> 
> Proposed approach:
> 
> First: Add a new section titled "Middle-boxes considerations" with the
> following text.
> 
> It is recommended that firewalls and other middleboxes do not drop TCP,
> UDP and ICMP packets with apparently incorrect checksums based on that
> fact alone unless they implement (monitoring of) the full shim6
> protocol and are able to determine the checksum that must be present in
> a packet with addresses rewritten by shim6."

Wouldn't it be useful to also recommend to the middleboxes sending a packet
back, for example a (new?) ICMP one, to allow the sending host to be aware
of what is happening?

Something like what is done with PMTU discovery. In our case we could have
more than one middlebox. It will also facilitate the network operator work.

> Second: allow the possibility that shim6 nodes can use the locators for
> calculating the TCP/UDP checksum, in case they detect that there is a
> middle box that does not support the shim6 protocol and drops the
> packets that contain the checksum calculated using the ULIDs (which are
> not used a addresses in the IPv6 header). In order to do that, we need
> to use a bit in the shim6 payload header to signal whether the ULIDs or
> the locators are used for the pseudoheader. The bad news is that there
> are no more spare bits in the shim6 payload header. I think this was
> not the best choice, since we haven't finished the spec and we already
> are out of bits.
> My suggestion is that we reduce the context tag to 40 bits and the we
> reserve 8 bits for flags and other information. In the current spec we
> would define two bits. The P flag that is already defined and the L
> flag, which would be set if the Locators are used to calculate the
> tcp/UDP checksum.
> 
> Third: Define a mechanism for detecting the presence of these middle
> boxes. I think that this could be achieved by adding a TCP or UDP
> header in the  I1/R1 exchange, but making sure that the tcp/udp
> checksum is calculated with other than the addresses contained in the
> ipv6 header. One simple option would be to use TCP header and leave the
> checksum filed to 0. If packets are dropped, then the peer should retry
> using a checksum calculated based on the addresses carried in the ipv6
> header. If this works, then it should use the locators for the
> peusoheader and set the L bit in the shim6 payload header.
> 
> Makes sense?

IMHO as we are using SHIM6, in some cases this middlebox behaviour would be
no problem because the SHIM6 REAP will detect that the locator pair have to
change, or am I missing something?

Regards,
Alvaro

> 
> Regards, marcelo
> 
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Sun, 11 Mar 2007 12:22:18 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Wrap-up discussion about: Re: about the protection against on path attackers
Date: Sun, 11 Mar 2007 13:22:18 +0100
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

I am trying to close the issues that were discussed previously and i am 
not sure how to deal with this one...

El 02/01/2007, a las 15:04, Iljitsch van Beijnum escribió:

> On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:
>
>>> Also, for CGA verification, don't we need to send the other side a 
>>> challenge to avoid replays?
>
>> I don't know if this is necessary...
>
> Ah, ok, so the updates are their own challenge.
>
> What I was thinking about was that the correspondent claims to have 
> the secret key belonging to the public key, but you don't know that 
> unless you see some data signed with the secret key that is particular 
> to the session at hand.
>
>>>       context.  In this case, we are in the Context confusion 
>>> situation,
>>>       and the host MUST NOT use the old context to send any packets. 
>>>  It
>>>       MAY just discard the old context (after all, the peer has
>>>       discarded it), or it MAY attempt to re-establish the old 
>>> context
>>>       by sending a new I1 message and moving its state to I1-SENT.  
>>> In
>>>       any case, once that this situation is detected, the host MUST 
>>> NOT
>>>       keep two contexts with overlapping Ls(peer) locator sets and 
>>> the
>>>       same context tag in ESTABLISHED state, since this would result 
>>> in
>>>       demultiplexing problems on the peer.
>
>>> What if an attacker is trying to interfere with legitimate 
>>> communication? We must be VERY sure that the new shim messages come 
>>> from the same host as the one that created the existing state if 
>>> we're going to mess with that existing state.
>
>> THe current security level is that we don't provide protection 
>> against on path attackers. If an attacker learns the context tag, 
>> then it can do some nasty stuff, including destroying the established 
>> context. this is the level of security that we have defined for the 
>> protocol. We can discuss whether this security level is approapriate, 
>> but i would like to have a high level discussion on the issue.
>
> I guess you're right. But as an added measure, I'd like to see that 
> the old context isn't torn down until the new one is set up 
> completely. This way, an attacker that somehow finds out a context tag 
> needs to have return routability and do the full 4-way handshake to 
> destroy a context, which is almost certainly not worth that much 
> trouble.
>
>

This seems reasonable, but the problem with this is that in order to do 
that, you need to actually have two contexts for the same ULID pair and 
the same FII simoultaneously (even if they are in different states) I 
am not sure how would this work, and if this would work properly. I 
think it is much clear the case that there is only one context for a 
given ULID pair and FII which seems a basic assumption on the spec.
so, again, current mechanism only provides protection to contexts from 
off path attackers and it is based on learning the context tag. If this 
is discovered by an attacker, it can tear down the context. OTOH, the 
spec just states a may tear down the context. If the node thinks he is 
under attack, it can keep the context (as long as it doesn't create a 
new one)

my proposal is to leave it as it is since introducing the possibility 
to have two context with the same ULID pair and FII may introduce some 
incosistencies in the spec, since the uniqueness of a context with a 
given ULID pair and FII was a basic assumption on the spec

Regards, marcelo

Delivery-date: Sun, 11 Mar 2007 11:49:34 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, Geoff Huston <[email-masked]>, Wesley Eddy <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8: Congestion notification
Date: Sun, 11 Mar 2007 12:50:58 +0100
To: shim6-wg <[email-masked]>

Hi,

Following the discussion on this topic, i am including a new section in 
the introduction that states:

<section title="Congestion Control Considerations">
<t>When the locator pair currently used for exchanging packets in a 
Shim6 context
becomes unreachable, the Shim6 layer will divert the communication 
through
an alternative locator pair, which in most cases will result in 
redirecting the
packet flow through an alternative network path. In this case, it 
reccomended that
the Shim6 follows the reccomendation defined in <xref 
target="I-D.schuetz-tcpm-tcp-rlci"> and it
informs the upper layers about the path change, in order to allow
the congestion control mechanisms of the upper layers can react 
accordingly.
</t>
</section>

Let me know if this addresses the received comments and clears this 
issue

Thanks, marcelo

Delivery-date: Sun, 11 Mar 2007 11:21:37 +0000
Cc: Geoff Huston <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8 w.r.t. Shim6 messages length
Date: Sun, 11 Mar 2007 12:05:23 +0100
To: shim6-wg <[email-masked]>

Hi,

in response to Iljitsch comment, I have added the following text in the 
Common Shim6 message format section, based on Iljitsch suggestion:

Shim6 signalling packets may not be larger than 1280 bytes, including
the IPv6 header and any intermediate headers between the IPv6 header and
the Shim6 header. One way to meet this requirement is to omit part of 
the
locator address information if with this information included,
the packet would become larger than 1280 bytes.Another option is to 
perform
option engineering, dividing into different Shim6 messages the 
information to
be transmitted. An implementation may
impose administrative restrictions to avoid excessively large Shim6
packets, such as a limitation on the number of locators to be used.

Let me know if you want additional changes w.r.t. this issue

Thanks, marcelo

Delivery-date: Sat, 10 Mar 2007 19:12:29 +0000
Cc: Thomas R Henderson <[email-masked]>, Brian E Carpenter <[email-masked]>, Geoff Huston <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Wrap-up: TCP checksum calculation
Date: Sat, 10 Mar 2007 20:12:08 +0100
To: shim6-wg <[email-masked]>

Hi,

this has been an interesting discussion

Let me see if i can propose a way forward.

The problem is that shim6 payload packets that carry locators different 
than ULIDs, will have the checksum calculated based on the ULIDs and 
not on the actual addresses carried in the ipv6 header. This would 
imply that any device in the middle (from NIC to middle boxes 
(firewalls and TCP relays)) will fail the checksum verification (and 
drop the packet). It is possible that TCP checksum verification is more 
common, since there is no IP checksum in IPv6.

Proposed approach:

First: Add a new section titled "Middle-boxes considerations" with the 
following text.

It is recommended that firewalls and other middleboxes do not drop TCP, 
UDP and ICMP packets with apparently incorrect checksums based on that 
fact alone unless they implement (monitoring of) the full shim6 
protocol and are able to determine the checksum that must be present in 
a packet with addresses rewritten by shim6."

Second: allow the possibility that shim6 nodes can use the locators for 
calculating the TCP/UDP checksum, in case they detect that there is a 
middle box that does not support the shim6 protocol and drops the 
packets that contain the checksum calculated using the ULIDs (which are 
not used a addresses in the IPv6 header). In order to do that, we need 
to use a bit in the shim6 payload header to signal whether the ULIDs or 
the locators are used for the pseudoheader. The bad news is that there 
are no more spare bits in the shim6 payload header. I think this was 
not the best choice, since we haven't finished the spec and we already 
are out of bits.
My suggestion is that we reduce the context tag to 40 bits and the we 
reserve 8 bits for flags and other information. In the current spec we 
would define two bits. The P flag that is already defined and the L 
flag, which would be set if the Locators are used to calculate the 
tcp/UDP checksum.

Third: Define a mechanism for detecting the presence of these middle 
boxes. I think that this could be achieved by adding a TCP or UDP 
header in the  I1/R1 exchange, but making sure that the tcp/udp 
checksum is calculated with other than the addresses contained in the 
ipv6 header. One simple option would be to use TCP header and leave the 
checksum filed to 0. If packets are dropped, then the peer should retry 
using a checksum calculated based on the addresses carried in the ipv6 
header. If this works, then it should use the locators for the 
peusoheader and set the L bit in the shim6 payload header.

Makes sense?

Regards, marcelo

Delivery-date: Thu, 08 Mar 2007 10:15:44 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Changes in version 8 resulting from comments in: Re: Retransmission of I2 messages
Date: Thu, 8 Mar 2007 11:16:35 +0100
To: Matthijs Mekking <[email-masked]>

El 08/03/2007, a las 10:44, Matthijs Mekking escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> marcelo bagnulo braun wrote:
>>
>> El 11/12/2006, a las 10:02, Matthijs Mekking escribió:
>>
>>> Hi,
>>>
>>> I have a question about the proto draft. In section 7.12, the draft 
>>> says
>>>  "If the initiator does not receive an R2 message after I2_TIMEOUT 
>>> time
>>> after sending an I2 message it MAY retransmit the I2 message" and 
>>> "Thus
>>> the initiator SHOULD fall back to retransmitting the I1 message when
>>> there is no R2 received after retransmitting the I2 message
>>> I2_RETRIES_MAX times."
>>>
>>> I am concerned about keywords MAY and SHOULD in section 7.12. If an
>>> implementation decides not to implement these retransmissions, then
>>> according to the protocol specification, the fall back to 
>>> retransmitting
>>> I1 messages would never occur (because this SHOULD happen after
>>> I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by 
>>> the
>>> responder, and no retransmissions are sent, than the context would 
>>> stay
>>> in I2-SENT, and is never able to reach ESTABLISHED.
>>>
>>> I think the host MAY retransmit I2 messages, but MUST fall back 
>>> after a
>>> certain amount of time, to avoid this deadlock situation. The same
>>> applies for retransmitting I2bis messages.
>>>
>>
>> I have rephrased this section  in order to clarify this.
>>
>> the section is now:
>>
>> If the initiator does not receive an R2 message after I2_TIMEOUT
>> time after sending an I2 message it MAY retransmit the I2 message, 
>> using
>> binary exponential backoff and randomized timers.
>> The Responder Validator option might have
>> a limited lifetime, that is, the peer might reject Responder Validator
>> options
>> that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In
>> the case that
>> the initiator decides not to retransmit I2 messages or in the case 
>> that the
>> initiator still does not recieve an R2 message after
>> retransmitting I2 messages I2_RETRIES_MAX times,
>> the initiator SHOULD retransmit the I1 message.
>>
>> Hope this clarifies this issue
>
> This is ok, although I think the last sentence must be "the initiator
> MUST fallback to retransmitting the I1 message":
>

> 1. "the initiator SHOULD retransmit the I1 message" can be read as:
> "retransmit one I1 message, stay in I2-SENT". However, I think the
> context must also fallback to the state I1-SENT, because R1 messages 
> (in
> reply to I1) are discarded when in I2-SENT.
>

ok

> 2. The keyword SHOULD implies that there might be a valid reason not to
> fallback to retransmitting the I1 message. However, I think there is no
> valid reason to do so, and doubting if this keyword should be MUST.
>

i see your point.
OTOH this is retrial in case something has failed. So, if the host is 
quite certain that the packet didn't got lost in the way (for example, 
the peer is located in the same LAN) and it is not getting any reply, 
then probably is the peer that doesn't want to run the shim6 protocol 
and it shouldn't retry.
I mean, i think that a must could be an overkill here and should is ok

Regards, marcelo

> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF79sYNiaStnTWEtYRAjiPAJ4+0YDsm24v35kgMDcSms9AOUBVygCdEDIa
> wIHVlYrHUV1EeNWMTELnKVw=
> =/zI4
> -----END PGP SIGNATURE-----
>

Delivery-date: Thu, 08 Mar 2007 09:52:26 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Changes in version 8 resulting from comments in:  Re: questions about draft-ietf-shim6-proto-06.txt
Date: Thu, 8 Mar 2007 10:53:44 +0100
To: Matthijs Mekking <[email-masked]>

El 08/03/2007, a las 10:30, Matthijs Mekking escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> First of all, thanks for processing these comments.
>
>> 1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
>> draft, "the peer might reject Responder Validator options that are 
>> older
>> than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
>> are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
>> Does this value apply to both nonces and responder validator options?
>>
>> Is this value solely used by a host acting as responder?
>>
>> If so, do you agree that this value should be used outside SHIM6?
>> Because a responder may not store state (yet) and thus can not verify 
>> if
>> a nonce in an I2 or I2bis message may be considered recent. If you
>> agree, can't this value be omitted from the document (since it is
>> independent of the correct working of SHIM6, but merely a security
>> consideration of the host)?
>>
>>> The version 7 of the document seemed unclear of how the Responder 
>>> Nonce
>>> lifetime was determined since no per context state was sotred. I have
>>> updated the draft, to make clear that the Responder nonce is obtained
>>> from a counter that is increased in fixed periods (indepedently of 
>>> any
>>> shim6 proto event) which allows to determine the age of a Responder
>>> Nonce just by comparing it with the current value of the counter.
>
> This clarifies how the responder nonce is obtained. However, it raises
> some questions about the predictability of the nonce. If the nonce is
> related to the time (the system's clock), the responder nonce might be
> easy to guess.
>

agree, but there is also the secret S, which would prevent guessing the 
validator even if the responder nonce can be guessed, would that be 
enough?

Regards, marcelo

>>
>>> Thanks again for this review, hope you find these changes ok
>>
>>> Let me know of further comments
>
> The other changes are ok. Thanks!
>
> regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF79fCNiaStnTWEtYRAviCAJ90i3T59hNOq04nlHnjrmPsRuu0eQCePD77
> BS6zaJQG2CoHLaLm2ztK8b8=
> =xRpk
> -----END PGP SIGNATURE-----
>

Delivery-date: Thu, 08 Mar 2007 09:45:36 +0000
Date: Thu, 08 Mar 2007 10:44:57 +0100
From: Matthijs Mekking <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: Changes in version 8 resulting from comments in: Re: Retransmission of I2 messages

marcelo bagnulo braun wrote:
> 
> El 11/12/2006, a las 10:02, Matthijs Mekking escribió:
> 
>> Hi,
>>
>> I have a question about the proto draft. In section 7.12, the draft says
>>  "If the initiator does not receive an R2 message after I2_TIMEOUT time
>> after sending an I2 message it MAY retransmit the I2 message" and "Thus
>> the initiator SHOULD fall back to retransmitting the I1 message when
>> there is no R2 received after retransmitting the I2 message
>> I2_RETRIES_MAX times."
>>
>> I am concerned about keywords MAY and SHOULD in section 7.12. If an
>> implementation decides not to implement these retransmissions, then
>> according to the protocol specification, the fall back to retransmitting
>> I1 messages would never occur (because this SHOULD happen after
>> I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by the
>> responder, and no retransmissions are sent, than the context would stay
>> in I2-SENT, and is never able to reach ESTABLISHED.
>>
>> I think the host MAY retransmit I2 messages, but MUST fall back after a
>> certain amount of time, to avoid this deadlock situation. The same
>> applies for retransmitting I2bis messages.
>>
> 
> I have rephrased this section  in order to clarify this.
> 
> the section is now:
> 
> If the initiator does not receive an R2 message after I2_TIMEOUT
> time after sending an I2 message it MAY retransmit the I2 message, using
> binary exponential backoff and randomized timers.
> The Responder Validator option might have
> a limited lifetime, that is, the peer might reject Responder Validator
> options
> that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In
> the case that
> the initiator decides not to retransmit I2 messages or in the case that the
> initiator still does not recieve an R2 message after
> retransmitting I2 messages I2_RETRIES_MAX times,
> the initiator SHOULD retransmit the I1 message.
> 
> Hope this clarifies this issue

This is ok, although I think the last sentence must be "the initiator
MUST fallback to retransmitting the I1 message":

1. "the initiator SHOULD retransmit the I1 message" can be read as:
"retransmit one I1 message, stay in I2-SENT". However, I think the
context must also fallback to the state I1-SENT, because R1 messages (in
reply to I1) are discarded when in I2-SENT.

2. The keyword SHOULD implies that there might be a valid reason not to
fallback to retransmitting the I1 message. However, I think there is no
valid reason to do so, and doubting if this keyword should be MUST.

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Thu, 08 Mar 2007 09:32:42 +0000
Date: Thu, 08 Mar 2007 10:30:42 +0100
From: Matthijs Mekking <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: Changes in version 8 resulting from comments in:  Re: questions about draft-ietf-shim6-proto-06.txt

First of all, thanks for processing these comments.

> 1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
> draft, "the peer might reject Responder Validator options that are older
> than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
> are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
> Does this value apply to both nonces and responder validator options?
> 
> Is this value solely used by a host acting as responder?
> 
> If so, do you agree that this value should be used outside SHIM6?
> Because a responder may not store state (yet) and thus can not verify if
> a nonce in an I2 or I2bis message may be considered recent. If you
> agree, can't this value be omitted from the document (since it is
> independent of the correct working of SHIM6, but merely a security
> consideration of the host)?
> 
>> The version 7 of the document seemed unclear of how the Responder Nonce
>> lifetime was determined since no per context state was sotred. I have
>> updated the draft, to make clear that the Responder nonce is obtained
>> from a counter that is increased in fixed periods (indepedently of any
>> shim6 proto event) which allows to determine the age of a Responder
>> Nonce just by comparing it with the current value of the counter.

This clarifies how the responder nonce is obtained. However, it raises
some questions about the predictability of the nonce. If the nonce is
related to the time (the system's clock), the responder nonce might be
easy to guess.

> 
>> Thanks again for this review, hope you find these changes ok
> 
>> Let me know of further comments

The other changes are ok. Thanks!

regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Wed, 07 Mar 2007 19:27:43 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8 resulting from comments in: Re: teardown of the ULID-pair context
Date: Wed, 7 Mar 2007 20:28:13 +0100
To: Matthijs Mekking <[email-masked]>

El 12/12/2006, a las 14:47, Matthijs Mekking escribió:

> Hi,
>
> I have a question about the teardown of the ULID-pair context. In
> chapter 9, the proto6 draft says "A reasonable approach would be not to
> tear down a context until at least 5 minutes have passed since the last
> message was sent or received using the context." Does this include
> messages that do not contain a shim6 extension header? My opinion is 
> yes:
>
> If there is a context on host A for host B, this means that both are
> multihomed. They should enjoy the goals of multihoming, such as
> failover. However, the communication between A and B initially uses the
> ULID address pair. Therefore, the IPv6 address fields do not need to be
> replaced by a different locator pair, and the message is not tagged 
> with
> a shim6 extension header. In other words, the context is not being used
> at the moment. This means that if after 5 minutes there was no context
> switch, the context states may be teared down again. If shortly after
> this the link corresponding to the ULID pair fails, the hosts are not
> able to do failover anymore.
>
> So, shim unaware payloads (traffic not using the context) should also 
> be
> observed. I suggest that the text 'using the context' in chapter 9 will
> be removed.

I have added the  following note on this section:

  (Note that
packets that use the ULID pair as locator pair and that do not require
address rewriting by the Shim6 layer are also considered as packets
using the associated Shim6 context)

>
> In order to observer shim unaware payloads, the shim6 layer should look
> up a context for these kind of messages. Chapter 11 already defines how
> this should be done for sending ULP payloads. For receiving packets
> (chapter 12), this information is missing. I suggest there should be a
> section before 12.1 receiving payload extension headers:
>
> 12.x Receiving payload without extension headers
>
> The receiver extracts the IPv6 source and destination fields, and uses
> this to find a ULID-pair context, such that the IPv6 address fields
> match the ULID(local) and ULID(peer). If such a context is found, the
> context appears not to be quiescent and this should be remembered. The
> host continues with proceeding the message.
>

I have added this section with some few changes

the final text is the following

<section title="Receiving payload without extension headers">

<t>The receiver extracts the IPv6 source and destination fields, and 
uses
this to find a ULID-pair context, such that the IPv6 address fields
match the ULID(local) and ULID(peer). If such a context is found, the
context appears not to be quiescent and this should be remembered in 
order to
avoid tearing down the context and for reachability detection porpuses 
as described in
<xref target="I-D.ietf-shim6-failure-detection"/>.
The host continues with the normal processing of the IP packet.
</t>
</section>

thanks for the comments
regards, marcelo

>
>
> With regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
>

Delivery-date: Wed, 07 Mar 2007 18:34:24 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8 resulting from comments in: Re: Retransmission of I2 messages
Date: Wed, 7 Mar 2007 19:35:39 +0100
To: Matthijs Mekking <[email-masked]>

El 11/12/2006, a las 10:02, Matthijs Mekking escribió:

> Hi,
>
> I have a question about the proto draft. In section 7.12, the draft 
> says
>  "If the initiator does not receive an R2 message after I2_TIMEOUT time
> after sending an I2 message it MAY retransmit the I2 message" and "Thus
> the initiator SHOULD fall back to retransmitting the I1 message when
> there is no R2 received after retransmitting the I2 message
> I2_RETRIES_MAX times."
>
> I am concerned about keywords MAY and SHOULD in section 7.12. If an
> implementation decides not to implement these retransmissions, then
> according to the protocol specification, the fall back to 
> retransmitting
> I1 messages would never occur (because this SHOULD happen after
> I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by the
> responder, and no retransmissions are sent, than the context would stay
> in I2-SENT, and is never able to reach ESTABLISHED.
>
> I think the host MAY retransmit I2 messages, but MUST fall back after a
> certain amount of time, to avoid this deadlock situation. The same
> applies for retransmitting I2bis messages.
>

I have rephrased this section  in order to clarify this.

the section is now:

If the initiator does not receive an R2 message after I2_TIMEOUT
time after sending an I2 message it MAY retransmit the I2 message, using
binary exponential backoff and randomized timers.
The Responder Validator option might have
a limited lifetime, that is, the peer might reject Responder Validator 
options
that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In 
the case that
the initiator decides not to retransmit I2 messages or in the case that 
the
initiator still does not recieve an R2 message after
retransmitting I2 messages I2_RETRIES_MAX times,
the initiator SHOULD retransmit the I1 message.

Hope this clarifies this issue

Thanks for the review,

regards, marcelo

> Furthermore, last week I have sent an e-mail with questions about the
> proto6 draft (http://ops.ietf.org/lists/shim6/msg01738.html). I would 
> be
> very grateful if someone could answer them.
>
> With kind regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
>

Delivery-date: Wed, 07 Mar 2007 18:19:11 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Changes in version 8 resulting from comments in:  Re: questions about draft-ietf-shim6-proto-06.txt
Date: Wed, 7 Mar 2007 19:18:48 +0100
To: Matthijs Mekking <[email-masked]>

These are the changes that i have made in the version 8 of the proto 
document based on these comments:

El 05/12/2006, a las 14:54, Matthijs Mekking escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> My name is Matthijs, and I am doing research on shim6 for Radboud
> University Nijmegen/NLnetLabs Amsterdam (Netherlands). I have a couple
> of questions about draft-ietf-shim6-proto-06.txt that seem a bit 
> unclear
> to me. Some of them are maybe obvious comments, but I shall make them,
> because I think it is good for a protocol description to allow only one
> clear interpretation.
>
> 1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
> draft, "the peer might reject Responder Validator options that are 
> older
> than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
> are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
> Does this value apply to both nonces and responder validator options?
>
> Is this value solely used by a host acting as responder?
>
> If so, do you agree that this value should be used outside SHIM6?
> Because a responder may not store state (yet) and thus can not verify 
> if
> a nonce in an I2 or I2bis message may be considered recent. If you
> agree, can't this value be omitted from the document (since it is
> independent of the correct working of SHIM6, but merely a security
> consideration of the host)?
>

The version 7 of the document seemed unclear of how the Responder Nonce 
lifetime was determined since no per context state was sotred. I have 
updated the draft, to make clear that the Responder nonce is obtained 
from a counter that is increased in fixed periods (indepedently of any 
shim6 proto event) which allows to determine the age of a Responder 
Nonce just by comparing it with the current value of the counter.

....
> 5. In chapter 6, a conceptual model of the host is given. However, the
> second table in section 6.2 introduces some new elements that are not
> described in section 6.1: INIT nonce, RESP nonce and CT(R1bis). I
> suggest that they (including a short description) are added to section 
> 6.1.
>

I have added Init nonce, Responder nonce and responder validator as 
additional information available in the conceptual model during the 
establishment phase

>
>
>
> 6. Am I right that the RESP nonce in I2-SENT is stored so that the host
> is able to create the correct I2 retransmission? If so, than the
> responder validator should also be stored (because this is also copied
> from the R1 message, just like RESP nonce).

added responder validator as information available in I2-SENT state

>  If this is the reason, than
> I think RESP nonce, INIT nonce and the responder validator should also
> be stored in state I2BIS-SENT.
>

Added RESP nonce Init nonce and Responder validator in I2BIS-SENT

>
>
>
> 7. In the text, computing a responder validator looks inconsistent with
> generating the validator:
>
> For R1 the secret S, the Initiator Context Tag and the locators are
> omitted when computing the validator:
>
> "use the following information concatenated as input to the one-way
> function:
> o  The the secret S
> o  That Responder Nonce
> o  The Initiator Context Tag from the I1 message
> o  The ULIDs from the I1 message
> o  The locators from the I1 message (strictly only needed if they are
> different from the ULIDs)
> o  The forked instance identifier if such option was included in the
> I1 message"
> (section 7.10.1, page 62)
>
> and
>
> "that the Responder Validator option matches the validator the host
> would have computed for the ULID, locators, responder nonce, and FII."
> (section 7.13, page 63).
>

added the init nonce in the description here

> For R1bis the secret S and Receiver Context tag are omitted when
> computing the validator, but the ULID and FII are added:
>
> "use the following information concatenated as input to the one-way
> function:
> o  The the secret S
> o  That Responder Nonce
> o  The Receiver Context tag included in the received packet
> o  The locators from the received packet"
> (section 7.17.1, page 68)
>
> and
>
> "the Responder Validator option matches the validator the host would
> have computed for the ULID, locators, responder nonce, and FII as part
> of sending an R1bis message."
> (section 7.20, page 69)
>

removed the ULID and FII from the description above

added the receiver context tag

Thanks again for this review, hope you find these changes ok

Let me know of further comments

Regards, marcelo

>
> With kind regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFdXocNiaStnTWEtYRAo3nAKC+sB2E/8YxJQ6PR7AzORZ6gEKyOgCeJccj
> UQAPF0SpqzlfSZT7smcf++k=
> =P4tt
> -----END PGP SIGNATURE-----
>

Delivery-date: Fri, 02 Mar 2007 07:38:45 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: cost of provider independence in p-shim6
Date: Fri, 2 Mar 2007 08:40:03 +0100

Motivated by the different questions i have wrote the following text 
that i will include in the next version, since i think it would clarify 
some aspects of the p-shim6

    The presented approach provides a set of features and relies on a set
    of components.  However, it should be noted that it is possible to
    provide a subset of the features using a subset of the components and
    that some of the components can be sustituted by alternative ones.
    In this section we describe which components are needed for which
    features and we also describe which other options could be used to
    replace some of the selected componenets.
    We will start by identifying which components are required for which
    feature.

    Centrally Managed Unique Local Addresses

    Centrally Managed Unique Local Addresses are used to provide provider
    independence i.e. avoid provider lock-in.  Using CMULAs allows the
    multihomed site to have provider independent identifiers and in the
    presented approach, the hosts within the multihomed site are only
    configured with CMULAs, greatly reducing the cost of a renumbering
    event.  PA addresses are only configured in the P-Shim6 boxes, so in
    case of a change in one of the ISPs, only the P-Shim6 boxes need to
    be reconfigured.  It should be noted that it is perfectly possible to
    use the P-Shim6 approach presented in this document with regular PA
    addresses as identifiers.  In this case, the hosts would be
    configured with PA addresses and the cost of a renumbering event
    would increase increasing also the provider lock-in.  In addition it
    should be noted that alternative provider independent identifiers
    could be used, such a regular PI address space.

    DNS Reverse tree

    The DNS reverse tree is used in this approach to restore ULID to
    locator mapping information in backup P-Shim6 boxes for ongoing
    communications in case that the primary shim6 fails.  In case that a
    single P-Shim6 box is used in a site, there is no need to populate
    the reverse DNS tree.  In case that alternative fault tolerance
    measures are in place (like mirrored P-Shim boxes) there reverse DNS
    population is not required.  In addition, alternative mechanisms to
    distribute ULID to locator mapping information among P-Shim6 boxes
    can be used instead of the reverse DNS (more in this below)

    ULID RR

    ULID RR is used to store information about addresses that are not
    globally routable and that are only meant to be used as ULID for
    shim6 context and not as locators.  Again, this is only needed to
    support non routable ULIDs, which are required to provide provider
    independence.  In the case that routable addresses (PA addresses for
    isntance) are used as ULIDs, this new ULID RR would be no longer
    needed.

    DNS Aplication level Gateway

    DNS Application Gateway is used to translate information ontained in
    the newly defined ULID RR and presented to legacy hosts in a AAAA
    record.  This is needed to support unmodified legacy hosts and
    provider independence through PI identifiers.  In the case that no
    provider independence is needed, and routable addresses are used as
    ULIDs, the DNS ALG would be no longer needed.  Similarly, if it can
    be asumed that the hosts in the multihomed site can understand the
    new ULID RR the DNS ALG would be no longer needed.

    Dual faced DNS

    The current proposal asumes that the DNS server in the multihomed
    site will return ULIDs in AAAA RR to internal queries and ULIDs in
    ULID RRs to external queries.  Again this is needed when non routable
    provider independent ULIDs are used.  If routable addresses are used
    as ULIDs (and no provider independence is required, there would be no
    need to dual faced DNS.

    Direct DNS population

    Direct DNS is used in the same way that it is currently used in non
    shim6 setups.  It is used in order to allow eternal hosts to initiate
    communications with a FQDN.  So DNS population is only required for
    hosts behaving as servers (i.e. they receive externally initiated
    communications).  Clients do no need DNS entries.

    NATv6

    NATv6 is required as a mechanism to comunicate with legacy hosts
    outside the multihomed site in the case that non routable ULIDs are
    being used i.e. in case provider independence is required.  If
    provider independence is not required, then is is posible to use the
    alternative choice described in the document, which relies in
    configurating multiple PA addresses per host, increasing provider
    lock in.

    Firewall component

    Having a firewall component in the P-Shim6 boxes is also required to
    provide provider independence.  This is so, because in order to
    facilitate renumbering we require that firewall rules will be
    configured using PI ULIDs rather than PA addresses.  If provider
    independence is no required and routable addresses can be used as
    ULIDs, the regular firewalls can be used unmodified.

    CGAs and HBAs

    ULIDs must be either CGAs or part of an HBA set.  In casethat
    provider independence is required, CGA are the only option, since a
    modification in one of the acialble prefixes in the site would result
    in a change in the ULIDs.  So, again, the usage of only CGAs is
    required by the provider independence requirement.

    Summarizing

    Tools imposed by the Provider Independence requirement

    CMULAs or similar

    DNS ALG

    New ULID RR

    NATv6

    Firewall component

    CGAs and not HBAs

    It would be perfectly possible to use the proposed approach wihtout
    the aforementioned components if provider independence is not
    required

Delivery-date: Fri, 02 Mar 2007 07:37:52 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: slight comments on shim6 proxies (1)
Date: Fri, 2 Mar 2007 08:37:17 +0100
To: Deguang Le <[email-masked]>

El 01/03/2007, a las 22:25, Deguang Le escribió:

> Hi Marcelo,
> Thanks you very much for your detailed explaination. :-)
> Please see my responses inline, which still have some questions.
>
>
>
>  bagnulo braun schrieb:
>
>> Hi Deguang,
>> thanks for the comments
>> see below..
>> El 01/03/2007, a las 12:14, Deguang Le escribió:
>>> Hi Marcelo, all,
>>> I read through the insightful draft and I have some questions and 
>>> comments on Section 3 as follows:
>>>
>>> To my understanding, the proposed approach employs two kinds of IP 
>>> addressing: the PI addressing and CMULA addressing, then the PI is 
>>> used as the locator and CMULA is used as the ULID separately. Right?
>> P-shim uses two types of addresses:
>> First type: CMULAs which are provider independent as ULIDs
>> Second type: PA addresses that are used as locators.
>> So, PA addresses are used as locators, no globally routable PI 
>> addresses are used in P-shim in any case
>>> If it is right, I wonder why we need to use a special IP addressing 
>>> (i.e. the CMULA) as the ULID.
>> see above
>
> However, I don't understand why the proposed approach has to employ 
> the CMULA as the ULID rather than use one of the locators as the ULID 
> as specified in the base shim6 protocol 
> (draft-ietf-shim6-proto-07.txt)?
>

you could use a locator of course, but this depends on what features 
you want to obtain
i am assuming that locators will be PA in order to make the routing 
system scale and there we don't want to use routable PI addresses
So if you use a PA addresss as ULID, then you need to renumber when you 
change ISPs and this may lead to provider lock in

So if the site has no problem with that, no problem it can use PA 
addesses as locators as it is in the basic shim6 approach and p-shim 
works

however, if the site wants to achieve provider independence through 
p-shim then it shouldn't configure any provider dependent addressses in 
the host, in order to reduce the renumbering costs in a changing 
provider event

this includes the ULIDs

that is why CMULAs that are provider independetn but that do not 
contaminate the global bgp routing table are used as ULIDs

this has a cost, since in order to support this, additional efferts are 
needed.
I will send an email summarizing all the costs involved in supporting 
this provider independence in p-shim

as i mention above, if the site is not interested in provider 
independence, and only wants p.shim for facilitating deployment or to 
obtain centrally enforced TE, then it can use  p-shim wihtout requiring 
some of the mechanisms

>
>>> Doesn't the base shim6 protocol (draft-ietf-shim6-proto-07.txt) 
>>> specifies to use the locator as the Upper Layer Identifier (ULID)?
>>>
>>> I am confused by the following sentence:
>>> *Hosts within the multihomed site are IPv6 hosts without any shim6 
>>> support and they are configured only with a single address 
>>> containing the CMULA prefix.*
>>> Since the non-shim6 capable hosts are only assigned with a single 
>>> address containing the CMULA prefix, is it feasible to put these 
>>> non-shim6 capable hosts in any place of the Internet and not 
>>> necessary to put them in a multihomed site?
>> this refers to the non shim6 capable hosts inside a multihomed site 
>> (or that are served by a P-shim box)
>> Hosts that are not served by a P-shim6 box cannot be configured with 
>> a CMULA because it is not routable
>
> Consider the situation where the non-shim6 capable host accesses to 
> the Internet through a single provider and is configured only with a 
> single globally routable IP address. Then, is the P-SHIM6 box in the 
> proposed approach still able to serve this kind of host?
>

yes,
the site will need a p-shim box in the site (or the isp)

even in this case, p-shim can provide a couple of benefits:
- support for multihoming fault tolerance capabilities when 
communicating with a multihomed site that has shim6
- provider independence, since it could use CMULAs in the hosts and the 
renumbering costs would be reduced

>>>  We only need to put the P-SHIM6 in a multihomed site. Right?
>>>
>>> It is not clear for me how the new *ULID RR* is specified in the 
>>> existing DNS.
>>>
>> becasue we cannot place CMULAs in AAAA records because if we did so, 
>> CMULAs would be returned to hosts and hosts (that are not aware of 
>> CMULAs and that are not served by a P-shim6) may try to send packets 
>> to this CMULA which is non globally routable
>
>>> I am not sure whether the CMULA is stored in the "ULID RR" or "AAAA 
>>> RR" on earth, because the following contexts presented in section 3 
>>> seem not consistent:
>>> PA addresses are published in AAAA RR while *CMULAs are published in 
>>> a new ULID RR*.
>>> The reply is processed by the DNS ALG of the multihomed site and 
>>> only *the CMULA is returned to H1 in a AAAA RR*.
>>>
>> Yes, because a host behind a P-shim, it can use a CMULA as a 
>> destiantion address becuase such packet will be intercepted by the 
>> P.shim box and the CMULA will be replaced by a gloablly routable PA 
>> address
>> So, the host behind a P-shim box makes a DNS query
>> The DNS server returns the CMULA in the ULID RR and the routable 
>> address in the AAAA RR (this is so becuase the DNS server doesn't 
>> know if the host that is asking is behind a P-shim6 or not)
>> The DNS component of the P-shim box processes the DNS reply and 
>> presentes the CMULA in a AAAA RR to the host behind the P-shim.
>> the host behind the p-shim sends a packet with the CMULA as dest 
>> address, which in turn is intercepted by the P-shim box, which 
>> establishes the shim context with the peer and replaces the CMULA 
>> address by a valid routable locator
>
> If the destination host (i.e. the peer) does not have the CMULA (e.g. 
> If H2 is a multihomed host as well as is shim6 capable, and all the 
> assigned IP addresses of H2 are PA addresses from its providers), then 
> what does it happen? How does the P-SHIM6 box works or how is the 
> procedure of DNS query peroformed?

in this case there is no need for the DNS ALG and the reply from the 
DNS is returned untouched to the source host behind the p-shim
one of the PA addresses returned in the DNS query will be used as ULID 
for that context

regards, marcelo

> Thanks!
>
>>> The following statement is not clear to me:
>>> *When H1 sends the first packet addressed to the CMULA of H2, the 
>>> packet is intercepted and processed by the P- Shim6 box of the 
>>> multihomed site.  *
>>> How could the P-SHIM6 intercept the first packet addressed to the 
>>> CMULA of H2?
>> because the P-shim must be located in the path between the host that 
>> it is serving and the internet
>>> Does the H1 send the first packet to the CMULA of H2 directly using 
>>> the common IP routing or does the H1 need to send the first packet 
>>> to the P-SHIM6 at first?
>> it uses the common ip routing, but the p-shim must be placed on the 
>> path between the host it serves and the internet, this can be 
>> achieved by  configuring the p-shim box to inject a route to the 
>> CMULA prefix, so it sinks all the packets with a CMULA as a 
>> destiantion address
> Because the CMULA of H2, which should belong to the H2's site, is not 
> globally routable, I don't think the first packet with the CMULA of H2 
> in the destination address field can be routed from the H1 to the 
> S-SHIM6 box in H1's site. :-)
> What do you think?
>
>>>
>>> Section 3 provides an example to explain how the proposed approach 
>>> would work. However, it is not clear for me how a ULP connection 
>>> (e.g. a TCP connection) could be established between the H1 and H2 
>>> through a P-SHIM6. I think it is important to describe how ULP 
>>> connection is established and preserved through the P-SHIM6. :-)
>> i cannot but agree with this comment, but i am not sure what is that 
>> you would like me to detail more...
>> perhaps with the above clarifications, it is clearer how this works, 
>> but let me know if it is not and i can try to make an example...
>>
> Does the establishment of SHIM6 context is prior to the establishment 
> of TCP connection?
> Thanks!
>
> Cheers,
> Deguang
>
>
>
>> thanks, marcelo
>>>
>>> Cheers,
>>> Deguang
>>>
>>>
>>>
>>>
>>> marcelo bagnulo braun schrieb:
>>>
>>>> Hi,
>>>> i have included in this draft some level of detail on how to do 
>>>> proxies in shim6, in order to support unmodified hosts, allow some 
>>>> middle boxes to perform egress path selection and provide PI 
>>>> identifiers, so that we can have an idea of how this would look 
>>>> like in the shim approach
>>>> Comments are welcome
>>>> Regards, marcelo
>>>> Inicio mensaje reenviado:
>>>>
>>>>> De: [email-masked]
>>>>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>>>>> Para: [email-masked]
>>>>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>>>>> Responder a: [email-masked]
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>
>>>>>
>>>>>     Title        : Proxy Shim6 (P-Shim6)
>>>>>     Author(s)    : M. Bagnulo
>>>>>     Filename    : draft-bagnulo-pshim6-00.txt
>>>>>     Pages        : 22
>>>>>     Date        : 2007-2-27
>>>>>        This draft discusses extensions to the shim6 architecture 
>>>>> to support
>>>>>    shim6 proxies that would allow the provision of the following
>>>>>    capabilities:
>>>>>    o  Provide Upper Layer Identifier portability.
>>>>>    o  Provide Traffic Engineering policy enforcement.
>>>>>    o  Off-load of the shim6 context management from the actual 
>>>>> peers of
>>>>>       the communication.
>>>>>
>>>>>
>>>>> A URL for this Internet-Draft is:
>>>>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
>>>>>
>>>>> Internet-Drafts can also be obtained by e-mail.
>>>>>
>>>>> Send a message to:
>>>>>     [email-masked].
>>>>> In the body type:
>>>>>     "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>>>>     NOTE:    The mail server at ietf.org can return the document in
>>>>>     MIME-encoded form by using the "mpack" utility.  To use this
>>>>>     feature, insert the command "ENCODING mime" before the "FILE"
>>>>>     command.  To decode the response(s), you will need "munpack" or
>>>>>     a MIME-compliant mail reader.  Different MIME-compliant mail 
>>>>> readers
>>>>>     exhibit different behavior, especially when dealing with
>>>>>     "multipart" MIME messages (i.e. documents which have been split
>>>>>     up into multiple messages), so check your local documentation 
>>>>> on
>>>>>     how to manipulate these messages.
>>>>>
>>>>> Below is the data which will enable a MIME compliant mail reader
>>>>> implementation to automatically retrieve the ASCII version of the
>>>>> Internet-Draft.
>>>>> Content-Type: text/plain
>>>>> Content-ID: <[email-masked]>
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>>
>>>
>
>

Delivery-date: Thu, 01 Mar 2007 21:27:26 +0000
Date: Thu, 01 Mar 2007 22:25:33 +0100
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: slight comments on shim6 proxies (1)

Hi Marcelo,
Thanks you very much for your detailed explaination. :-)
Please see my responses inline, which still have some questions.

  bagnulo braun schrieb:

> Hi Deguang,
> 
> thanks for the comments
> 
> see below..
> 
> El 01/03/2007, a las 12:14, Deguang Le escribió:
> 
>> Hi Marcelo, all,
>> I read through the insightful draft and I have some questions and 
>> comments on Section 3 as follows:
>>
>> To my understanding, the proposed approach employs two kinds of IP 
>> addressing: the PI addressing and CMULA addressing, then the PI is 
>> used as the locator and CMULA is used as the ULID separately. Right?
> 
> 
> P-shim uses two types of addresses:
> First type: CMULAs which are provider independent as ULIDs
> Second type: PA addresses that are used as locators.
> 
> So, PA addresses are used as locators, no globally routable PI addresses 
> are used in P-shim in any case
> 
>> If it is right, I wonder why we need to use a special IP addressing 
>> (i.e. the CMULA) as the ULID.
> 
> 
> see above

However, I don't understand why the proposed approach has to employ the 
CMULA as the ULID rather than use one of the locators as the ULID as 
specified in the base shim6 protocol (draft-ietf-shim6-proto-07.txt)?

> 
>> Doesn't the base shim6 protocol (draft-ietf-shim6-proto-07.txt) 
>> specifies to use the locator as the Upper Layer Identifier (ULID)?
>>
>> I am confused by the following sentence:
>> *Hosts within the multihomed site are IPv6 hosts without any shim6 
>> support and they are configured only with a single address containing 
>> the CMULA prefix.*
>> Since the non-shim6 capable hosts are only assigned with a single 
>> address containing the CMULA prefix, is it feasible to put these 
>> non-shim6 capable hosts in any place of the Internet and not necessary 
>> to put them in a multihomed site?
> 
> 
> this refers to the non shim6 capable hosts inside a multihomed site (or 
> that are served by a P-shim box)
> 
> Hosts that are not served by a P-shim6 box cannot be configured with a 
> CMULA because it is not routable

Consider the situation where the non-shim6 capable host accesses to the 
Internet through a single provider and is configured only with a single 
globally routable IP address. Then, is the P-SHIM6 box in the proposed 
approach still able to serve this kind of host?

> 
>>  We only need to put the P-SHIM6 in a multihomed site. Right?
>>
>> It is not clear for me how the new *ULID RR* is specified in the 
>> existing DNS.
>>
> 
> becasue we cannot place CMULAs in AAAA records because if we did so, 
> CMULAs would be returned to hosts and hosts (that are not aware of 
> CMULAs and that are not served by a P-shim6) may try to send packets to 
> this CMULA which is non globally routable

> 
>> I am not sure whether the CMULA is stored in the "ULID RR" or "AAAA 
>> RR" on earth, because the following contexts presented in section 3 
>> seem not consistent:
>> PA addresses are published in AAAA RR while *CMULAs are published in a 
>> new ULID RR*.
>> The reply is processed by the DNS ALG of the multihomed site and only 
>> *the CMULA is returned to H1 in a AAAA RR*.
>>
> 
> Yes, because a host behind a P-shim, it can use a CMULA as a destiantion 
> address becuase such packet will be intercepted by the P.shim box and 
> the CMULA will be replaced by a gloablly routable PA address
> 
> So, the host behind a P-shim box makes a DNS query
> The DNS server returns the CMULA in the ULID RR and the routable address 
> in the AAAA RR (this is so becuase the DNS server doesn't know if the 
> host that is asking is behind a P-shim6 or not)
> The DNS component of the P-shim box processes the DNS reply and 
> presentes the CMULA in a AAAA RR to the host behind the P-shim.
> the host behind the p-shim sends a packet with the CMULA as dest 
> address, which in turn is intercepted by the P-shim box, which 
> establishes the shim context with the peer and replaces the CMULA 
> address by a valid routable locator

If the destination host (i.e. the peer) does not have the CMULA (e.g. If 
H2 is a multihomed host as well as is shim6 capable, and all the 
assigned IP addresses of H2 are PA addresses from its providers), then 
what does it happen? How does the P-SHIM6 box works or how is the 
procedure of DNS query peroformed?
Thanks!

> 
>> The following statement is not clear to me:
>> *When H1 sends the first packet addressed to the CMULA of H2, the 
>> packet is intercepted and processed by the P- Shim6 box of the 
>> multihomed site.  *
>> How could the P-SHIM6 intercept the first packet addressed to the 
>> CMULA of H2?
> 
> 
> because the P-shim must be located in the path between the host that it 
> is serving and the internet
> 
>> Does the H1 send the first packet to the CMULA of H2 directly using 
>> the common IP routing or does the H1 need to send the first packet to 
>> the P-SHIM6 at first?
> 
> 
> it uses the common ip routing, but the p-shim must be placed on the path 
> between the host it serves and the internet, this can be achieved by  
> configuring the p-shim box to inject a route to the CMULA prefix, so it 
> sinks all the packets with a CMULA as a destiantion address
Because the CMULA of H2, which should belong to the H2's site, is not 
globally routable, I don't think the first packet with the CMULA of H2 
in the destination address field can be routed from the H1 to the 
S-SHIM6 box in H1's site. :-)
What do you think?

> 
>>
>> Section 3 provides an example to explain how the proposed approach 
>> would work. However, it is not clear for me how a ULP connection (e.g. 
>> a TCP connection) could be established between the H1 and H2 through a 
>> P-SHIM6. I think it is important to describe how ULP connection is 
>> established and preserved through the P-SHIM6. :-)
> 
> 
> i cannot but agree with this comment, but i am not sure what is that you 
> would like me to detail more...
> 
> perhaps with the above clarifications, it is clearer how this works, but 
> let me know if it is not and i can try to make an example...
>
Does the establishment of SHIM6 context is prior to the establishment of 
TCP connection?
Thanks!

Cheers,
Deguang

> thanks, marcelo
> 
> 
>>
>> Cheers,
>> Deguang
>>
>>
>>
>>
>> marcelo bagnulo braun schrieb:
>>
>>> Hi,
>>> i have included in this draft some level of detail on how to do 
>>> proxies in shim6, in order to support unmodified hosts, allow some 
>>> middle boxes to perform egress path selection and provide PI 
>>> identifiers, so that we can have an idea of how this would look like 
>>> in the shim approach
>>> Comments are welcome
>>> Regards, marcelo
>>> Inicio mensaje reenviado:
>>>
>>>> De: [email-masked]
>>>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>>>> Para: [email-masked]
>>>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>>>> Responder a: [email-masked]
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>>
>>>>     Title        : Proxy Shim6 (P-Shim6)
>>>>     Author(s)    : M. Bagnulo
>>>>     Filename    : draft-bagnulo-pshim6-00.txt
>>>>     Pages        : 22
>>>>     Date        : 2007-2-27
>>>>        This draft discusses extensions to the shim6 architecture to 
>>>> support
>>>>    shim6 proxies that would allow the provision of the following
>>>>    capabilities:
>>>>    o  Provide Upper Layer Identifier portability.
>>>>    o  Provide Traffic Engineering policy enforcement.
>>>>    o  Off-load of the shim6 context management from the actual peers of
>>>>       the communication.
>>>>
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
>>>>
>>>> Internet-Drafts can also be obtained by e-mail.
>>>>
>>>> Send a message to:
>>>>     [email-masked].
>>>> In the body type:
>>>>     "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>>>     NOTE:    The mail server at ietf.org can return the document in
>>>>     MIME-encoded form by using the "mpack" utility.  To use this
>>>>     feature, insert the command "ENCODING mime" before the "FILE"
>>>>     command.  To decode the response(s), you will need "munpack" or
>>>>     a MIME-compliant mail reader.  Different MIME-compliant mail 
>>>> readers
>>>>     exhibit different behavior, especially when dealing with
>>>>     "multipart" MIME messages (i.e. documents which have been split
>>>>     up into multiple messages), so check your local documentation on
>>>>     how to manipulate these messages.
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>> Content-Type: text/plain
>>>> Content-ID: <[email-masked]>
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
> 

Delivery-date: Thu, 01 Mar 2007 16:52:09 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: slight comments on shim6 proxies (1)
Date: Thu, 1 Mar 2007 17:52:16 +0100
To: Deguang Le <[email-masked]>

Hi Deguang,

thanks for the comments

see below..

El 01/03/2007, a las 12:14, Deguang Le escribió:

> Hi Marcelo, all,
> I read through the insightful draft and I have some questions and 
> comments on Section 3 as follows:
>
> To my understanding, the proposed approach employs two kinds of IP 
> addressing: the PI addressing and CMULA addressing, then the PI is 
> used as the locator and CMULA is used as the ULID separately. Right?

P-shim uses two types of addresses:
First type: CMULAs which are provider independent as ULIDs
Second type: PA addresses that are used as locators.

So, PA addresses are used as locators, no globally routable PI 
addresses are used in P-shim in any case

> If it is right, I wonder why we need to use a special IP addressing 
> (i.e. the CMULA) as the ULID.

see above

> Doesn't the base shim6 protocol (draft-ietf-shim6-proto-07.txt) 
> specifies to use the locator as the Upper Layer Identifier (ULID)?
>
> I am confused by the following sentence:
> *Hosts within the multihomed site are IPv6 hosts without any shim6 
> support and they are configured only with a single address containing 
> the CMULA prefix.*
> Since the non-shim6 capable hosts are only assigned with a single 
> address containing the CMULA prefix, is it feasible to put these 
> non-shim6 capable hosts in any place of the Internet and not necessary 
> to put them in a multihomed site?

this refers to the non shim6 capable hosts inside a multihomed site (or 
that are served by a P-shim box)

Hosts that are not served by a P-shim6 box cannot be configured with a 
CMULA because it is not routable

>  We only need to put the P-SHIM6 in a multihomed site. Right?
>
> It is not clear for me how the new *ULID RR* is specified in the 
> existing DNS.
>

becasue we cannot place CMULAs in AAAA records because if we did so, 
CMULAs would be returned to hosts and hosts (that are not aware of 
CMULAs and that are not served by a P-shim6) may try to send packets to 
this CMULA which is non globally routable

> I am not sure whether the CMULA is stored in the "ULID RR" or "AAAA 
> RR" on earth, because the following contexts presented in section 3 
> seem not consistent:
> PA addresses are published in AAAA RR while *CMULAs are published in a 
> new ULID RR*.
> The reply is processed by the DNS ALG of the multihomed site and only 
> *the CMULA is returned to H1 in a AAAA RR*.
>

Yes, because a host behind a P-shim, it can use a CMULA as a 
destiantion address becuase such packet will be intercepted by the 
P.shim box and the CMULA will be replaced by a gloablly routable PA 
address

So, the host behind a P-shim box makes a DNS query
The DNS server returns the CMULA in the ULID RR and the routable 
address in the AAAA RR (this is so becuase the DNS server doesn't know 
if the host that is asking is behind a P-shim6 or not)
The DNS component of the P-shim box processes the DNS reply and 
presentes the CMULA in a AAAA RR to the host behind the P-shim.
the host behind the p-shim sends a packet with the CMULA as dest 
address, which in turn is intercepted by the P-shim box, which 
establishes the shim context with the peer and replaces the CMULA 
address by a valid routable locator

> The following statement is not clear to me:
> *When H1 sends the first packet addressed to the CMULA of H2, the 
> packet is intercepted and processed by the P- Shim6 box of the 
> multihomed site.  *
> How could the P-SHIM6 intercept the first packet addressed to the 
> CMULA of H2?

because the P-shim must be located in the path between the host that it 
is serving and the internet

> Does the H1 send the first packet to the CMULA of H2 directly using 
> the common IP routing or does the H1 need to send the first packet to 
> the P-SHIM6 at first?

it uses the common ip routing, but the p-shim must be placed on the 
path between the host it serves and the internet, this can be achieved 
by  configuring the p-shim box to inject a route to the CMULA prefix, 
so it sinks all the packets with a CMULA as a destiantion address

>
> Section 3 provides an example to explain how the proposed approach 
> would work. However, it is not clear for me how a ULP connection (e.g. 
> a TCP connection) could be established between the H1 and H2 through a 
> P-SHIM6. I think it is important to describe how ULP connection is 
> established and preserved through the P-SHIM6. :-)

i cannot but agree with this comment, but i am not sure what is that 
you would like me to detail more...

perhaps with the above clarifications, it is clearer how this works, 
but let me know if it is not and i can try to make an example...

thanks, marcelo

>
> Cheers,
> Deguang
>
>
>
>
> marcelo bagnulo braun schrieb:
>
>> Hi,
>> i have included in this draft some level of detail on how to do 
>> proxies in shim6, in order to support unmodified hosts, allow some 
>> middle boxes to perform egress path selection and provide PI 
>> identifiers, so that we can have an idea of how this would look like 
>> in the shim approach
>> Comments are welcome
>> Regards, marcelo
>> Inicio mensaje reenviado:
>>> De: [email-masked]
>>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>>> Para: [email-masked]
>>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>>> Responder a: [email-masked]
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>>     Title        : Proxy Shim6 (P-Shim6)
>>>     Author(s)    : M. Bagnulo
>>>     Filename    : draft-bagnulo-pshim6-00.txt
>>>     Pages        : 22
>>>     Date        : 2007-2-27
>>>        This draft discusses extensions to the shim6 architecture to 
>>> support
>>>    shim6 proxies that would allow the provision of the following
>>>    capabilities:
>>>    o  Provide Upper Layer Identifier portability.
>>>    o  Provide Traffic Engineering policy enforcement.
>>>    o  Off-load of the shim6 context management from the actual peers 
>>> of
>>>       the communication.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>>     [email-masked].
>>> In the body type:
>>>     "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>>     NOTE:    The mail server at ietf.org can return the document in
>>>     MIME-encoded form by using the "mpack" utility.  To use this
>>>     feature, insert the command "ENCODING mime" before the "FILE"
>>>     command.  To decode the response(s), you will need "munpack" or
>>>     a MIME-compliant mail reader.  Different MIME-compliant mail 
>>> readers
>>>     exhibit different behavior, especially when dealing with
>>>     "multipart" MIME messages (i.e. documents which have been split
>>>     up into multiple messages), so check your local documentation on
>>>     how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID: <[email-masked]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

Delivery-date: Thu, 01 Mar 2007 16:35:24 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 proxies
Date: Thu, 1 Mar 2007 17:35:05 +0100
To: Shinta Sugimoto <[email-masked]>

Hi Shinta,

Thanks for reading and commenting the document...

see below...

El 01/03/2007, a las 4:57, Shinta Sugimoto escribió:

> Hi Marcelo,
>
> I read your draft and found it insightful. I had a couple of
> questions as below:
>
> - I am not sure if I understand the definition of CMULA and its
>   expected role in P-shim6, so please help me clarify. According to
>   draft-ietf-ipv6-ula-contral-01.txt, CMULAs are not expected to be
>   routable globally.  However, reading the P-shim6 draft, I assume
>   that CMULA need to be globally routable addresses.

CMULAs in the P-shim6 draft are not routed gloablly

CMULAs are only used a ULIDs and are never used a locators for shim6 
contexts
current shim6 uses one of the PA addresses as the ULIDs, so the ulids 
depend on the provider.

The goal in P-shim is to only configure provider independent addresses 
(which are not globally routable) in the nodes within the multihomed 
site, so that renumbering is trivial
The problem is that since they are not routable, you need to establish 
the shim6 context before exchanging packets using alternative locators. 
(this is basically what was proposed by Erik in 
http://tools.ietf.org/wg/shim6/draft-nordmark-shim6-esd-00.txt)

makes sense?

>   And if there is any problem with assigning more than one CMULA
>   blocks to a multihomed site?

no but this is not needed AFAICT
I mean, CMULAs are the ULIDs, and are provider independent, so i am not 
sure why would you need more than one block...

> - In Section 5, it is mentioned that P-shim6 box virtually assigns
>   PA address for each host and uses it as locator for each
>   multiplexing/demultiplexing for the proxy-shimmed flow.
>   But wouldn't it be possible for the P-shim6 box to use a PA
>   address as a common locator for multiple clients?

yes, this would be possible

This  does present some problems AFAICT especially when you want to 
fall back from the primary P-shim to the secondary P-shim, since the 
packets are addressed to the p-shim itself
In addition, if you want to provide communication with legacy nodes 
outside the multihomed site that are not served by any P.shim, you 
still need to assign PA addresses to each node in the multihomed site

>  I would
>   think that proxy-shimmed payload traffic can be normally
>   demultiplexed to CMULA on the receiver.  Sharing common locator
>   may help to reduce costs of REAP failure detection.

yes this could be an optimization, i agree

I am not sure if no changes are needed for this, in the reap logic, but 
i think this could be done

in order to do this, you would need that the backup p-shim would take 
over the address of the primary p-shim when this one fails. I am not 
sure what could be the complexity added by this.

>   I missing something?

i don't think so, this is another possibility and i worth to explore 
its benefits deeper

> - The draft says that P-shim6 box should be the DNS server for
>   the hosts, providing DNS relay in a specific manner; inducing
>   the host to access to its peer with ULID.  But I am wondering
>   if such role can be played by other DNS server (!= P-shim box)
>   as well.  Is there any reason why P-shim6 box should be involved
>   in address resolution requested by host?
>

Yes, because the DNS reply returns the ULID and the locators. the 
P-shim stores the locators and includes the ULID in the DNS reply to 
the host. when the host sends the first packet to the peer, it includes 
the ULID in the dest address field. when the packet reaches the P-Shim, 
the P-shim box has the locator information associated to this ULID 
because it was returned in the original DNS reply
makes sense?

regards, marcelo

>
> Regards,
> Shinta
>
> On Wed, 28 Feb 2007 12:46:36 +0100
> marcelo bagnulo braun <[email-masked]> wrote:
>
>>
>> Hi,
>>
>> i have included in this draft some level of detail on how to do 
>> proxies
>> in shim6, in order to support unmodified hosts, allow some middle 
>> boxes
>> to perform egress path selection and provide PI identifiers, so that 
>> we
>> can have an idea of how this would look like in the shim approach
>>
>> Comments are welcome
>>
>> Regards, marcelo
>>
>> Inicio mensaje reenviado:
>>
>>> De: [email-masked]
>>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>>> Para: [email-masked]
>>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>>> Responder a: [email-masked]
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> 	Title		: Proxy Shim6 (P-Shim6)
>>> 	Author(s)	: M. Bagnulo
>>> 	Filename	: draft-bagnulo-pshim6-00.txt
>>> 	Pages		: 22
>>> 	Date		: 2007-2-27
>>> 	
>>>    This draft discusses extensions to the shim6 architecture to 
>>> support
>>>    shim6 proxies that would allow the provision of the following
>>>    capabilities:
>>>    o  Provide Upper Layer Identifier portability.
>>>    o  Provide Traffic Engineering policy enforcement.
>>>    o  Off-load of the shim6 context management from the actual peers 
>>> of
>>>       the communication.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> 	[email-masked].
>>> In the body type:
>>> 	"FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>> 	
>>> NOTE:	The mail server at ietf.org can return the document in
>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>> 	command.  To decode the response(s), you will need "munpack" or
>>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>> 	exhibit different behavior, especially when dealing with
>>> 	"multipart" MIME messages (i.e. documents which have been split
>>> 	up into multiple messages), so check your local documentation on
>>> 	how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID: <[email-masked]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
>

Delivery-date: Thu, 01 Mar 2007 13:03:19 +0000
Date: Thu, 01 Mar 2007 14:01:35 +0100
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: slight comments on shim6 proxies (1)

Hi Marcelo, all,
I read through the insightful draft and I have some questions and 
comments on Section 3 as follows:

To my understanding, the proposed approach employs two kinds of IP 
addressing: the PI addressing and CMULA addressing, then the PI is used 
as the locator and CMULA is used as the ULID separately. Right?
If it is right, I wonder why we need to use a special IP addressing 
(i.e. the CMULA) as the ULID.
Doesn't the base shim6 protocol (draft-ietf-shim6-proto-07.txt) 
specifies to use the locator as the Upper Layer Identifier (ULID)?

I am confused by the following sentence:
*Hosts within the multihomed site are IPv6 hosts without any shim6 
support and they are configured only with a single address containing 
the CMULA prefix.*
Since the non-shim6 capable hosts are only assigned with a single 
address containing the CMULA prefix, is it feasible to put these 
non-shim6 capable hosts in any place of the Internet and not necessary 
to put them in a multihomed site? We only need to put the P-SHIM6 in a 
multihomed site. Right?

It is not clear for me how the new *ULID RR* is specified in the 
existing DNS.

I am not sure whether the CMULA is stored in the "ULID RR" or "AAAA RR" 
on earth, because the following contexts presented in section 3 seem not 
consistent:
PA addresses are published in AAAA RR while *CMULAs are published in a 
new ULID RR*.
The reply is processed by the DNS ALG of the multihomed site and only 
*the CMULA is returned to H1 in a AAAA RR*.

The following statement is not clear to me:
*When H1 sends the first packet addressed to the CMULA of H2, the packet 
is intercepted and processed by the P- Shim6 box of the multihomed site.  *
How could the P-SHIM6 intercept the first packet addressed to the CMULA 
of H2?
Does the H1 send the first packet to the CMULA of H2 directly using the 
common IP routing or does the H1 need to send the first packet to the 
P-SHIM6 at first?

Section 3 provides an example to explain how the proposed approach would 
work. However, it is not clear for me how a ULP connection (e.g. a TCP 
connection) could be established between the H1 and H2 through a 
P-SHIM6. I think it is important to describe how ULP connection is 
established and preserved through the P-SHIM6. :-)

Cheers,
Deguang

marcelo bagnulo braun schrieb:

> 
> Hi,
> 
> i have included in this draft some level of detail on how to do proxies 
> in shim6, in order to support unmodified hosts, allow some middle boxes 
> to perform egress path selection and provide PI identifiers, so that we 
> can have an idea of how this would look like in the shim approach
> 
> Comments are welcome
> 
> Regards, marcelo
> 
> Inicio mensaje reenviado:
> 
>> De: [email-masked]
>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>> Para: [email-masked]
>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>> Responder a: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : Proxy Shim6 (P-Shim6)
>>     Author(s)    : M. Bagnulo
>>     Filename    : draft-bagnulo-pshim6-00.txt
>>     Pages        : 22
>>     Date        : 2007-2-27
>>     
>>    This draft discusses extensions to the shim6 architecture to support
>>    shim6 proxies that would allow the provision of the following
>>    capabilities:
>>    o  Provide Upper Layer Identifier portability.
>>    o  Provide Traffic Engineering policy enforcement.
>>    o  Off-load of the shim6 context management from the actual peers of
>>       the communication.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     [email-masked].
>> In the body type:
>>     "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> 

Delivery-date: Thu, 01 Mar 2007 09:07:42 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
Date: Thu, 1 Mar 2007 10:07:38 +0100
To: Brian E Carpenter <[email-masked]>

Hi Brian,

El 28/02/2007, a las 15:14, Brian E Carpenter escribió:

> I'm glad to see this written up, and I like
> many aspects of it. I do have a couple of remarks
>
> 1. Exactly as with draft-farinacci-lisp, there is
> a clear question whether it's wise to depend so
> heavily on DNS for locator mapping. Or should we
> invent a separate map distribution mechanism?
>

Let me see if i can detail exactly what the DNS is used for.

It really depends what features you want to achieve with the P-shim6

If you want to achieve Provider independence (i.e. have only PI 
identifiers configured in the hosts and avoid renumbering costs) then 
you need the new ULID RR and you will use the DNS to retrieve both ULID 
and locator (exactly like HIP)
DNS is not used as a generic ULID to lookup mechanism (it could be used 
but it is not really used AFICT)

If you don't want provider independence, the you don't need the new 
ULID RR and regular PA addresses are stored in DNS just as regular 
shim6

The reverse DNS is used to restore the ULID to locator mapping 
information to the backup P-shim in case that the primary P-shim fails.
Please note that only the information that was originally in the 
primary P-shim needs to be restored in the backup

The reverse DNs was used because is one mechanism that is already there 
and it can be perfectly replaced with another mechanism. In particular 
a primary Pshim - backup p-shim protocol could be used.

This is described in the draft in this way.

    The DNS reverse tree is used to retireve locator information
    associated with an unroutable ULID.  In concrete, it is used in the
    following situation: A shim6 context has been established between a
    P-shim and a remote shim6 peer (either P-shim6 or a shim6 host).  The
    P-shim6 that has the shim6 context information fails and the backup
    shim6 is used to continue with the communication.  In order to do
    that, the context information must be restored.  In this case, the
    backup P-shim6 needs to retrieve the locator information associated
    to the ULID of the remote peer.  It does so, by performing a DNS
    reverse lookup for the CMULA used a ULID.

    However, it should be noted that the locator information was already
    available in the site, in particular, it was available in the primary
    P-shim6.  So it would be perfectly possible to create an inter-P-
    shim6 protocol to exchange locator-ULID binding information between
    the primary and the backup P-shim6 as soon as the the context is
    created.  This would distribute the locator to ULID binding
    information and there would be no need to retrieve it from the DNS
    reverse tree (and there would be no need to require the population of
    the reverse DNS tree if such inter-P-shim6 protocol was available.
    It must be noted that the reverse tree is never used to retrieve ULID
    locator binding information for initial contact, but is only used to
    restore information that was once available locally. this is why, it
    is perfectly possible to design local mechanisms to substitute the
    usage of the reverse DNS in the P-shim6 approach.

So i am perfectly open to define a new protocol for this and forget the 
reverse DNS completely if people prefer this. This is not central to 
the P-shim6 approach

> 2. I think we could probably use unregistered
> ULAs and some fairly simple clash-detection mechanism.
> Otherwise, we will be creating registration expense
> for no very good reason.

This is perfectly possible.
as ULIDs, you can use PA addresses if you don't need provider 
independence
If you need provider independence, then some form of PI ULID is needed. 
You can use CMULAs as described in the draft
You could use statiscally unique ULAs. One point here, is how to 
publish them in the reverse DNS. In this case you would need as you 
said a clash detection mechanism, like for instance trying to register 
them in the reverse DNS tree. But i guess this would be possible also.

the other option is to simply use PI addresses as ULIDs get them 
directly from the RIRs and not announced them in the BGP routing table

Regards, marcelo

>
>     Brian
>

Delivery-date: Thu, 01 Mar 2007 03:59:56 +0000
Date: Thu, 01 Mar 2007 12:57:50 +0900
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 proxies
Cc: shim6-wg <[email-masked]>

Hi Marcelo,

I read your draft and found it insightful. I had a couple of
questions as below:

- I am not sure if I understand the definition of CMULA and its
  expected role in P-shim6, so please help me clarify. According to
  draft-ietf-ipv6-ula-contral-01.txt, CMULAs are not expected to be
  routable globally.  However, reading the P-shim6 draft, I assume
  that CMULA need to be globally routable addresses.
  And if there is any problem with assigning more than one CMULA
  blocks to a multihomed site?
- In Section 5, it is mentioned that P-shim6 box virtually assigns
  PA address for each host and uses it as locator for each
  multiplexing/demultiplexing for the proxy-shimmed flow.
  But wouldn't it be possible for the P-shim6 box to use a PA
  address as a common locator for multiple clients?  I would
  think that proxy-shimmed payload traffic can be normally
  demultiplexed to CMULA on the receiver.  Sharing common locator
  may help to reduce costs of REAP failure detection.
  I missing something?
- The draft says that P-shim6 box should be the DNS server for
  the hosts, providing DNS relay in a specific manner; inducing
  the host to access to its peer with ULID.  But I am wondering
  if such role can be played by other DNS server (!= P-shim box)
  as well.  Is there any reason why P-shim6 box should be involved
  in address resolution requested by host?

Regards,
Shinta

On Wed, 28 Feb 2007 12:46:36 +0100
marcelo bagnulo braun <[email-masked]> wrote:

> 
> Hi,
> 
> i have included in this draft some level of detail on how to do proxies 
> in shim6, in order to support unmodified hosts, allow some middle boxes 
> to perform egress path selection and provide PI identifiers, so that we 
> can have an idea of how this would look like in the shim approach
> 
> Comments are welcome
> 
> Regards, marcelo
> 
> Inicio mensaje reenviado:
> 
> > De: [email-masked]
> > Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
> > Para: [email-masked]
> > Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
> > Responder a: [email-masked]
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > 	Title		: Proxy Shim6 (P-Shim6)
> > 	Author(s)	: M. Bagnulo
> > 	Filename	: draft-bagnulo-pshim6-00.txt
> > 	Pages		: 22
> > 	Date		: 2007-2-27
> > 	
> >    This draft discusses extensions to the shim6 architecture to support
> >    shim6 proxies that would allow the provision of the following
> >    capabilities:
> >    o  Provide Upper Layer Identifier portability.
> >    o  Provide Traffic Engineering policy enforcement.
> >    o  Off-load of the shim6 context management from the actual peers of
> >       the communication.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.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-bagnulo-pshim6-00.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
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > Content-Type: text/plain
> > Content-ID: <[email-masked]>
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce