Subject: Re: address pair exploration, flooding and state loss
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6 <[email-masked]>
Date: Tue, 31 May 2005 14:03:03 -0700

Iljitsch van Beijnum wrote:
> On 31-mei-2005, at 19:21, Erik Nordmark wrote:
> 
>>> - after a rehoming event, context loss is detected upon the  
>>> reception of any packet associated with the shim session, whether  
>>> signalling packet or data packet. for that, data packets need to  
>>> carry at least one bit that identifies them as belonging to a shim  
>>> session.
> 
> 
>> Makes sense to me.
> 
> 
> It is indeed necessary to determine that a higher layer session or  
> association belongs to a shim session. However:
> 
> - That doesn't necessarily mean that this can be determined for an  
> individual packet. Another way to do this would be the "ICMP bad  
> checksum" message that I suggested a few days ago.

But as I responded, such an approach only makes sense if we are going to 
modify all the protocols which run over IP to generate such errors. And 
assuming that an implementation can do this is problematic due to "raw 
socket" APIs which allow there to be any number of IP protocols 
implemented unbeknown to the provider of the IP and shim6 layers.

> - Even if we want to determine the shim status of individual packets,  
> we don't necessarily need a bit for this. For instance, when locator- 
> only addresses and ULID addresses are disjunct this can be determined  
> from the destination address.

Correct. The above "bit" is really a conceptual piece of information 
that needs to be sent from A to B; could be in the form of
  - using a separate extension header
  - some bit stealing in the nxthdr field
  - using locators which are not allowed as ULIDs as you point out
  - or anything else which conveys the meaning

    Erik

Delivery-date: Tue, 31 May 2005 20:56:32 +0000
Date: Tue, 31 May 2005 13:56:16 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote:

>> This is the debate about positive vs. negative advise from the ULPs.
> 
> 
> Hm, in a binary world saying no or not saying yes are the same  thing... 
> Not sure if there is a big difference here.

Ah - but this is not binary.
A ULP can do three things at any given time:
  - provide no advise
  - provide positive advise (things are making progress)
  - provide negative advise (I see some problems/retransmissions)

Thus the lack of positive advise is not the same as negative advise.

>> You are advocating that the ULPs provide negative advise.
> 
> 
> Actually I want the shim to monitor ULP progress rather than depend  on 
> the actual ULP to provide feedback. The problem with that would be  that 
> in many cases (= 99% of the time when UDP is the payload), the  "real" 
> ULP is implemented in the application.

Adding code in the shim that parses ULP headers to determine "progress" 
doesn't make an implementation perform better, and requiring that the 
shim understands this for all possible ULPs (think raw sockets) doesn't 
make it easier to deploy the shim.

A technique based on positive advise from the ULP is robust against the 
case when the ULP doesn't provide any advise, since this would trigger 
the shim to do it's own data driven probes.
So we can handle the UDP case just fine in this approach. The positive 
advise from the ULP is a performance optimization; when the advise 
arrives in the shim it removes the need for the shim to probe.

>> But things are problematic on B, because there isn't an (efficient)  
>> strategy for the TCP on B to generate negative advise - it doesn't  
>> run a retransmit timer.
> 
> 
> Ah, but if A can detect the failure in this case, then that would be  
> good enough if A can tell B about it at some point.

Yes, but this assumes that packets from A to B in fact get delivered.
Since the failure could be for the A->B direction, the B->A direction, 
or both, there are cases when B would not be informed that A is seeing 
problems,

> A long time ago in a galaxy far away, I thought it would be important  
> to handle the case where only one end has the knowledge to repair the  
> failure. However, I don't think this applies to the shim as all  
> addresses for both sides are communicated during the shim negotiation  
> so the possibility of a successful repair shouldn't depend on which  end 
> detects the failure.

I agree that we can have either or both ends try all the N*M locator 
pairs, i.e. that the technique works. But the issue is how efficient it 
would be and whether positive vs. negative advise makes a difference 
here on what we can do in the shim.

> So IMO, it is good enough when just one side is able to detect the  
> failure.
> 
>> Thus when something fails it will always be up to A to initiate the  
>> exploration of alternate locator pairs. Also, the time at which the  
>> exploration of alternates start is a function of the retransmit  
>> behavior of the ULP, which makes it harder to tightly control the  
>> failover time.
> 
> 
> No, in my plan the shim wouldn't know about retransmissions, it only  
> looks for return traffic. So either the timeout is relatively long to  
> accommodate ULPs that don't send traffic in the low-traffic direction  
> very often (I think streaming A/V protocols send an ack every 10  
> seconds or so) or relatively short but then there would be almost  
> continuous reachability probes in at least one direction.

But then the best you can do is determined by the ULPs (re)transmission 
behavior, which is why I say that you can't control the failover time in 
the shim.
If the ULP retransmits 10 times with binary exponential backoff starting 
with a timeout of 4 seconds, and it has been told to send negative 
advise after consuming half the retransmits, then the shim will see 
negative advise after 4+8+16+32+64 seconds.
But once the ULP has a better RTT estimate it might retransmit with a 
timeout starting at 500 ms or less. In that case the negative advise 
will arrive to the shim a lot sooner.

With positive advise the shim can always operate with "if I send a 
packet and >10 seconds have passed since I have positive advise or a 
successful probe, then send a probe" logic.
In this case the shim will always start looking for alternatives after 
10 seconds.

> What kind of failover time do you imagine, BTW?

10 seconds for sending a probe might not be a bad default. If we think 
we can send a small number of probes in parallel (3 or so) with binary 
exponential backoff for the probes, we might be able to recover from the 
failure in one RTT after those 10 seconds, but if there are lots of 
address pairs to try and more than one has failed, it can take a lot 
longer. If the shim itself is conservative and has a 4 second probe 
timeout with exponential backoff, then it would
  - send 3 probes at time 10 seconds
  - send 3 other probes at time 14 seconds
  - send 3 more at time 22 seconds
But the shim can probably use an initial timeout based on the RTT 
measured when then shim state was setup, so that things can be sped up.

>> With such a strategy the shim implementation can do a check after  
>> sending a ULP packet: "how long time ago since some positive advise?"
> 
> 
> AFter every packet...?

Yes, but a node which implements the mandatory NUD in RFC 2461 already 
has that test in the code path, so it might very well be possible to 
implement the shim6 liveness check without adding an extra test to the 
code path.

    Erik

Delivery-date: Tue, 31 May 2005 20:06:43 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Tue, 31 May 2005 22:06:27 +0200
To: Erik Nordmark <[email-masked]>

On 31-mei-2005, at 19:36, Erik Nordmark wrote:

>> What I'm getting at is that one end says "hey, can you still hear   
>> me?" and then the other end says "sure, and can you still hear  
>> me?".  The first party then replies with "yes" and we know that  
>> there is  reachability in both directions.

> Yes, one can verify that bidirectional reachability exists (when it  
> does exist) by using 3 packets instead of the naive approach which  
> would result in 4 packets.
> But that doesn't necessarily help when reachability does not exist  
> for some subset of the address pairs.

While I think that we want to save this fourth packet, my real point  
was that when one end suspects there is a reachability problem, this  
in itself should be enough for the other side to become suspicious as  
well. I.e., the situation where one end detects a failure but the  
other keeps sending packets into the void in blissful ignorance would  
be suboptimal if the first end's suspicions were correct and there  
was a failure, and (as would be common) a bidirectional one.

>>> Thus I think we'd want a packet driven trigger of reachability   
>>> testing (much like NUD). When A sends a ULP packet to B, it  
>>> checks  whether it has current reachability information for B,  
>>> and if not  it triggers reachability testing.

>> Disagree. I think we should assume reachability until we get a  
>> hint  that there is none. So if A sends a packet to B, B does  
>> nothing and  will 99% likely in due course send a packet back  
>> because transports  tend to work in both directions. However, if A  
>> doesn't get a reply  and the packet it sent earlier isn't one that  
>> is known to go  replyless (i.e., TCP ack-only or fin packets, A  
>> triggers reachability  testing.

> This is the debate about positive vs. negative advise from the ULPs.

Hm, in a binary world saying no or not saying yes are the same  
thing... Not sure if there is a big difference here.

> You are advocating that the ULPs provide negative advise.

Actually I want the shim to monitor ULP progress rather than depend  
on the actual ULP to provide feedback. The problem with that would be  
that in many cases (= 99% of the time when UDP is the payload), the  
"real" ULP is implemented in the application.

> But that isn't sufficient to trigger in all cases of failures.

> Take the case when the TCP on A is sending data to B, hence B is  
> only sending ACK packets back to A.
> The TCP on A can easily generate negative advise when it has  
> retransmitted a few times and doesn't receive a response.

So far so good.

> But things are problematic on B, because there isn't an (efficient)  
> strategy for the TCP on B to generate negative advise - it doesn't  
> run a retransmit timer.

Ah, but if A can detect the failure in this case, then that would be  
good enough if A can tell B about it at some point.

A long time ago in a galaxy far away, I thought it would be important  
to handle the case where only one end has the knowledge to repair the  
failure. However, I don't think this applies to the shim as all  
addresses for both sides are communicated during the shim negotiation  
so the possibility of a successful repair shouldn't depend on which  
end detects the failure.

So IMO, it is good enough when just one side is able to detect the  
failure.

> Thus when something fails it will always be up to A to initiate the  
> exploration of alternate locator pairs. Also, the time at which the  
> exploration of alternates start is a function of the retransmit  
> behavior of the ULP, which makes it harder to tightly control the  
> failover time.

No, in my plan the shim wouldn't know about retransmissions, it only  
looks for return traffic. So either the timeout is relatively long to  
accommodate ULPs that don't send traffic in the low-traffic direction  
very often (I think streaming A/V protocols send an ack every 10  
seconds or so) or relatively short but then there would be almost  
continuous reachability probes in at least one direction.

What kind of failover time do you imagine, BTW?

Current BGP is around the 2 minute mark for severe failures.

> It is easier to have the ULPs generate positive advise ("the  
> traffic to this destination is making forward progress") at both  
> ends. The fact that an ACK for new data has been recently received,  
> or that a data packet which advances the sequence number has been  
> recently received, are both easy indications of forward progress.

Doesn't this require changes to all transports?

> With such a strategy the shim implementation can do a check after  
> sending a ULP packet: "how long time ago since some positive advise?"

AFter every packet...?

> The positive advise approach has the benefit that it works even if  
> the ULPs don't generate any advise; in this case the shim would,  
> when ULP packets are being sent, revert to periodically sending a  
> test packet.

We can tolerate this in less common cases (depending on the amount of  
test traffic), but not for the more common upper layer protocols.

Delivery-date: Tue, 31 May 2005 19:45:19 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Tue, 31 May 2005 21:44:47 +0200
To: Erik Nordmark <[email-masked]>

On 31-mei-2005, at 19:21, Erik Nordmark wrote:

>> - after a rehoming event, context loss is detected upon the  
>> reception of any packet associated with the shim session, whether  
>> signalling packet or data packet. for that, data packets need to  
>> carry at least one bit that identifies them as belonging to a shim  
>> session.

> Makes sense to me.

It is indeed necessary to determine that a higher layer session or  
association belongs to a shim session. However:

- That doesn't necessarily mean that this can be determined for an  
individual packet. Another way to do this would be the "ICMP bad  
checksum" message that I suggested a few days ago.

- Even if we want to determine the shim status of individual packets,  
we don't necessarily need a bit for this. For instance, when locator- 
only addresses and ULID addresses are disjunct this can be determined  
from the destination address.

Delivery-date: Tue, 31 May 2005 17:36:37 +0000
Date: Tue, 31 May 2005 10:36:41 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote:
> On 27-mei-2005, at 23:37, Erik Nordmark wrote:
> 
>>> I would think that if one side triggers reachability testing, the   
>>> other side would also do it. The probes in one direction can also   
>>> function as replies in the other direction, cutting down on the   
>>> number of packets exchanged.
> 
> 
>> I'm not sure we'd end up with both ends triggering reachability  
>> testing at about the same time, because that would seem to assume  
>> some form of periodic reachability testing even when there is no  ULP 
>> traffic. Such background chatter seems undesirable.
> 
> 
> I'm not sure what you mean here...

I think it was the use of "trigger" in your earlier email that triggered 
me to go off in what is perhaps tangential to your point.

> What I'm getting at is that one end says "hey, can you still hear  me?" 
> and then the other end says "sure, and can you still hear me?".  The 
> first party then replies with "yes" and we know that there is  
> reachability in both directions.

Yes, one can verify that bidirectional reachability exists (when it does 
exist) by using 3 packets instead of the naive approach which would 
result in 4 packets.
But that doesn't necessarily help when reachability does not exist for 
some subset of the address pairs.

>> Thus I think we'd want a packet driven trigger of reachability  
>> testing (much like NUD). When A sends a ULP packet to B, it checks  
>> whether it has current reachability information for B, and if not  it 
>> triggers reachability testing.
> 
> 
> Disagree. I think we should assume reachability until we get a hint  
> that there is none. So if A sends a packet to B, B does nothing and  
> will 99% likely in due course send a packet back because transports  
> tend to work in both directions. However, if A doesn't get a reply  and 
> the packet it sent earlier isn't one that is known to go  replyless 
> (i.e., TCP ack-only or fin packets, A triggers reachability  testing.

This is the debate about positive vs. negative advise from the ULPs. You 
are advocating that the ULPs provide negative advise. But that isn't 
sufficient to trigger in all cases of failures.

Take the case when the TCP on A is sending data to B, hence B is only 
sending ACK packets back to A.
The TCP on A can easily generate negative advise when it has 
retransmitted a few times and doesn't receive a response.
But things are problematic on B, because there isn't an (efficient) 
strategy for the TCP on B to generate negative advise - it doesn't run a 
retransmit timer.

Thus when something fails it will always be up to A to initiate the 
exploration of alternate locator pairs. Also, the time at which the 
exploration of alternates start is a function of the retransmit behavior 
of the ULP, which makes it harder to tightly control the failover time.

It is easier to have the ULPs generate positive advise ("the traffic to 
this destination is making forward progress") at both ends. The fact 
that an ACK for new data has been recently received, or that a data 
packet which advances the sequence number has been recently received, 
are both easy indications of forward progress.
With such a strategy the shim implementation can do a check after 
sending a ULP packet: "how long time ago since some positive advise?"
If this exceeds some limit, then the shim can trigger a test of the 
current locator pair, and if that fails, start testing alternative 
locator pairs.

The positive advise approach has the benefit that it works even if the 
ULPs don't generate any advise; in this case the shim would, when ULP 
packets are being sent, revert to periodically sending a test packet.

> As per my suggestion, there would normally not be any reachability  
> testing as long as packets flow in both directions. When there is a  
> bidirectional failure AND both ends were sending data at the same  time 
> (= not when data is flowing in one direction and just acks in  the 
> other), there would probably be reachability testing triggered in  both 
> directions at the same time.
> 
> Do you consider this problematic?

Yes, because the ULP on both ends will not be able to detect that there 
is a problem. The canonical example where this isn't easy is a TCP which 
is receiving data packets and only sending ACKs; in that case there is 
no retransmit timer running on which you can hang a "send negative 
advise to the IP layer" event.

    Erik

Delivery-date: Tue, 31 May 2005 17:21:38 +0000
Date: Tue, 31 May 2005 10:21:30 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

marcelo bagnulo braun wrote:

> so the conclusion is that reboots and lost state have to be detected at 
> least as fast as what is available today

yep

> may be but it does constraint the possible heuristics used for 
> establishing shim sessions.
> Maybe it would be enough to mention that the heuristics for establishing 
> shim sessions also are used for recover from those situations where the 
> context has been lost. However, i guess that need to take into account 
> where the heuristics for establsihing shim sessions are not useful for 
> recovering from lost state and provide a worst case recovery for this case.

Yes, it makes sense to describe this part of state recovery, and any 
implications it has on the recommendations for the heuristics used to 
determine when to establish shim state.

> so, so far what we have is:
> 
> - before a rehoming event, packets may not be identified as belonging to 
> a shim session. If this is the case, the data packets associated to this 
> sessions are not useful to detect context loss, so alternative 
> mechanims, like using the heuristics for establishing shim sessions are 
> used for recover from this situations
> - after a rehoming event, context loss is detected upon the reception of 
> any packet associated with the shim session, whether signalling packet 
> or data packet. for that, data packets need to carry at least one bit 
> that identifies them as belonging to a shim session.

Makes sense to me.

    Erik

Delivery-date: Tue, 31 May 2005 13:47:35 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Tue, 31 May 2005 15:47:04 +0200
To: Erik Nordmark <[email-masked]>

El 27/05/2005, a las 22:57, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>>> In #1 it is key that we can get A to realize that the context has=20
>>> been lost on B, so that we can get to the point where the shim on B=20=

>>> can pass up the packets to the ULPs. This will cause the ULPs to=20
>>> generate errors (e.g. TCP RST) and we are back to what we have today=20=

>>> without a shim.
>>>
>> besides at this point, there is no possible recovery, since ULP state=20=

>> also has been lost
>
> Yes, but "do no harm" presumably includes "don't slow down current=20
> failure detection".
>
> The recovery, once the RST comes back, could be to open a new=20
> connection, or something else in the application layer. (Think of an=20=

> application with the same behavior as wget -c)
>
> I think there is a significant quality difference between
> 1. The box reboots in 30 seconds. The first TCP retransmission after=20=

> 30 seconds results in a RST coming back. This triggers application=20
> recovery.
> 2. The box reboots in 30 seconds. TCP retransmissions for the next 10=20=

> minutes are silently dropped because the retransmissions arrive at the=20=

> peer's TCP with a bad checksum (due to "missing" shim6 rewrite).
> Thus any RST doesn't arrive until 10 minutes or so later!
>
agree
so the conclusion is that reboots and lost state have to be detected at=20=

least as fast as what is available today

>>
>> right, the only point that i wonder w.r.t. this is if it is wise to=20=

>> base the context loss detection procedure on the heuristics to=20
>> establish shim context... i mean, the heuristics for establishing=20
>> shim context may greatly vary, i guess. For instance, i think it may=20=

>> be a possibility that some heavy loaded servers use the policy to=20
>> never initiate shim session establishment procedure, but they only=20
>> accept establishment request from clients. In such a case, they=20
>> wouldn't detect context loss.
>
> So we can point out in our RFCs why such a behavior would be=20
> suboptimal.
> Ensuring that one end can quickly detect when the peer has lost the=20
> context state, even when the state isn't used (when the ULIDs are used=20=

> as locators), is far from inexpensive.

may be but it does constraint the possible heuristics used for=20
establishing shim sessions.
Maybe it would be enough to mention that the heuristics for=20
establishing shim sessions also are used for recover from those=20
situations where the context has been lost. However, i guess that need=20=

to take into account where the heuristics for establsihing shim=20
sessions are not useful for recovering from lost state and provide a=20
worst case recovery for this case.

>
>> In any case, if the procedure you described in the previous mail for=20=

>> including both the context identifier and the nonce in a compact way=20=

>> in 20 bits, we could stuff all we need in all data packets, i guess,=20=

>> so if the flow label approach is used, all data packets of=20
>> established shim sessions can be identified as such
>
> No, that isn't sufficient, because there is nothing in a received=20
> packet which identifies it to the receiver (which has lost context) as=20=

> a shim6 packet. Any packet can have a non-zero flow label, so that=20
> isn't a useful indication.
>
> So you'd need to add at least one bit to every data packet to be able=20=

> to do this.

>> ok, now i am confused
>> AFAIU until now, if we want to detect context loss based on the=20
>> reception of data packets, we need to have some falg in the data=20
>> packet that this packet belongs to a existent shim session. If we=20
>> eliminate this bit, then we cannot detect loss context from data=20
>> packets, right? or have i lost track of our reasoning?
>
> If B receives a packet from A1 to B1 with flow label 12345 and a=20
> nexthdr of UDP, then if B has no context for <A1, B1, 12345>, how can=20=

> B tell whether this is due to
>  - there never having been a shim6 context - A might not be shim6=20
> capable for instance
>  - B having had such a context but has garbage collected too early
>

right, this is what i have in mind.

so, so far what we have is:

- before a rehoming event, packets may not be identified as belonging=20
to a shim session. If this is the case, the data packets associated to=20=

this sessions are not useful to detect context loss, so alternative=20
mechanims, like using the heuristics for establishing shim sessions are=20=

used for recover from this situations
- after a rehoming event, context loss is detected upon the reception=20
of any packet associated with the shim session, whether signalling=20
packet or data packet. for that, data packets need to carry at least=20
one bit that identifies them as belonging to a shim session.

right?

regards, marcelo

>  Erik
>

Delivery-date: Mon, 30 May 2005 00:51:16 +0000
Date: Mon, 30 May 2005 10:50:04 +1000
From: Greg Daley <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Iljistch,

Iljitsch van Beijnum wrote:
> Signature checks are relatively expensive: these are exactly the  
> operations you want to avoid for suspect packets.
> 
> However, this could easily be done by having A give B a nonce that is  
> (for instance) a timestamp and a hash over B's IP address, the  
> timestamp and some secret data. If A then loses its state for B, B  can 
> prove to A it talked to A at the indicated time, and A can check  this 
> as long as it still has its piece of secret data. Since this  doesn't 
> have to change often, that will be likely.
> 

In that case, the state required for generating the cookie would have
to be simple (small?) enough to store in a non-volatile way, so that
it too doesn't get lost easily.  It could possibly be system wide,
so long as there's no easy way to determine the secret, or generate
fake cookies.

It may also to be useful to consider if the cookie contains
information about the original context state (which would have to
be sent from B->A in the query). This context state in the query
could help prove that the cookie was given for a particular SHIM6
context, and ensures that if there's a flow still in existence
the flow state can't be restored (if that's an aim) by someone
other than the original context owner.

While cookie generation wouldn't need to be standardized, it
would be useful to have an example incarnation which people could
point to (and implement).

Greg

Delivery-date: Sat, 28 May 2005 11:32:58 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sat, 28 May 2005 13:32:30 +0200
To: Erik Nordmark <[email-masked]>

On 27-mei-2005, at 23:37, Erik Nordmark wrote:

>> I would think that if one side triggers reachability testing, the   
>> other side would also do it. The probes in one direction can also   
>> function as replies in the other direction, cutting down on the   
>> number of packets exchanged.

> I'm not sure we'd end up with both ends triggering reachability  
> testing at about the same time, because that would seem to assume  
> some form of periodic reachability testing even when there is no  
> ULP traffic. Such background chatter seems undesirable.

I'm not sure what you mean here...

What I'm getting at is that one end says "hey, can you still hear  
me?" and then the other end says "sure, and can you still hear me?".  
The first party then replies with "yes" and we know that there is  
reachability in both directions.

Obviously it would be possible for one end to test reachability and  
for the other end to do nothing, but that means more packets and  
longer delays until certain failures are detected.

There is of course a corner case where both ends trigger reachability  
testing independently at the same time, but I think if we design the  
protocol carefully, this shouldn't be problematic.

> Thus I think we'd want a packet driven trigger of reachability  
> testing (much like NUD). When A sends a ULP packet to B, it checks  
> whether it has current reachability information for B, and if not  
> it triggers reachability testing.

Disagree. I think we should assume reachability until we get a hint  
that there is none. So if A sends a packet to B, B does nothing and  
will 99% likely in due course send a packet back because transports  
tend to work in both directions. However, if A doesn't get a reply  
and the packet it sent earlier isn't one that is known to go  
replyless (i.e., TCP ack-only or fin packets, A triggers reachability  
testing.

> With such an approach, only in the case that B receives the ULP  
> packet and this makes it send a ULP packet back (e.g., a TCP ACK),  
> might B trigger reachability testing.
> But when B doesn't receive the packet it would not trigger  
> reachability testing at the same time as A does.

As per my suggestion, there would normally not be any reachability  
testing as long as packets flow in both directions. When there is a  
bidirectional failure AND both ends were sending data at the same  
time (= not when data is flowing in one direction and just acks in  
the other), there would probably be reachability testing triggered in  
both directions at the same time.

Do you consider this problematic?

Delivery-date: Fri, 27 May 2005 21:53:27 +0000
Date: Fri, 27 May 2005 14:53:09 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

Iljitsch van Beijnum wrote:
> On 27-mei-2005, at 22:57, Erik Nordmark wrote:
> 
>> 2. The box reboots in 30 seconds. TCP retransmissions for the next  10 
>> minutes are silently dropped because the retransmissions arrive  at 
>> the peer's TCP with a bad checksum (due to "missing" shim6  rewrite).
>> Thus any RST doesn't arrive until 10 minutes or so later!
> 
> 
> Can we create a new ICMP message that says "I got a packet that may  or 
> may not have come from you and it had a wrong layer 4 checksum"?

And modify every transport protocol implementation? I'd prefer if we 
don't have to rely on such modifications.

> On a slightly related note: it would be good if we can rebuild shim  
> state after it has been lost on one side when at the same time, there  
> is a failure. This would allow new sessions to be created and  
> immediately rehomed that would otherwise have failed.

Presumably when A discovers that B has lost the shim state and it had 
failed over to an alternate locator pair, it will immediately try to 
rebuilt it, before sending any more ULP packets.
In this case it makes sense for A to use the locator pair that was 
working before the state loss for the shim6 signaling (and if possible, 
tell B which locator pair was used in the reverse direction).

I don't know how important it would be to optimize this case though.

   Erik

Delivery-date: Fri, 27 May 2005 21:37:06 +0000
Date: Fri, 27 May 2005 14:37:11 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote:

> I would think that if one side triggers reachability testing, the  other 
> side would also do it. The probes in one direction can also  function as 
> replies in the other direction, cutting down on the  number of packets 
> exchanged.

I'm not sure we'd end up with both ends triggering reachability testing 
at about the same time, because that would seem to assume some form of 
periodic reachability testing even when there is no ULP traffic. Such 
background chatter seems undesirable.

Thus I think we'd want a packet driven trigger of reachability testing 
(much like NUD). When A sends a ULP packet to B, it checks whether it 
has current reachability information for B, and if not it triggers 
reachability testing.

With such an approach, only in the case that B receives the ULP packet 
and this makes it send a ULP packet back (e.g., a TCP ACK), might B 
trigger reachability testing.
But when B doesn't receive the packet it would not trigger reachability 
testing at the same time as A does.

    Erik

Delivery-date: Fri, 27 May 2005 21:12:59 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 23:12:46 +0200
To: Erik Nordmark <[email-masked]>

On 27-mei-2005, at 22:57, Erik Nordmark wrote:

> 2. The box reboots in 30 seconds. TCP retransmissions for the next  
> 10 minutes are silently dropped because the retransmissions arrive  
> at the peer's TCP with a bad checksum (due to "missing" shim6  
> rewrite).
> Thus any RST doesn't arrive until 10 minutes or so later!

Can we create a new ICMP message that says "I got a packet that may  
or may not have come from you and it had a wrong layer 4 checksum"?

Since the faulty checksum may be the result of a bit error, we  
probably don't want to copy back any data to the sender as it may not  
be the actual sender. But if the sender is shim capabable and has  
state towards the receiver, it can then send a shim-level state  
inquiry and the truth will come out.

On a slightly related note: it would be good if we can rebuild shim  
state after it has been lost on one side when at the same time, there  
is a failure. This would allow new sessions to be created and  
immediately rehomed that would otherwise have failed.

Delivery-date: Fri, 27 May 2005 20:57:29 +0000
Date: Fri, 27 May 2005 13:57:09 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

marcelo bagnulo braun wrote:

>> In #1 it is key that we can get A to realize that the context has been 
>> lost on B, so that we can get to the point where the shim on B can 
>> pass up the packets to the ULPs. This will cause the ULPs to generate 
>> errors (e.g. TCP RST) and we are back to what we have today without a 
>> shim.
>>
> 
> besides at this point, there is no possible recovery, since ULP state 
> also has been lost

Yes, but "do no harm" presumably includes "don't slow down current 
failure detection".

The recovery, once the RST comes back, could be to open a new 
connection, or something else in the application layer. (Think of an 
application with the same behavior as wget -c)

I think there is a significant quality difference between
1. The box reboots in 30 seconds. The first TCP retransmission after 30 
seconds results in a RST coming back. This triggers application recovery.
2. The box reboots in 30 seconds. TCP retransmissions for the next 10 
minutes are silently dropped because the retransmissions arrive at the 
peer's TCP with a bad checksum (due to "missing" shim6 rewrite).
Thus any RST doesn't arrive until 10 minutes or so later!

>
> right, the only point that i wonder w.r.t. this is if it is wise to base 
> the context loss detection procedure on the heuristics to establish shim 
> context... i mean, the heuristics for establishing shim context may 
> greatly vary, i guess. For instance, i think it may be a possibility 
> that some heavy loaded servers use the policy to never initiate shim 
> session establishment procedure, but they only accept establishment 
> request from clients. In such a case, they wouldn't detect context loss.

So we can point out in our RFCs why such a behavior would be suboptimal.
Ensuring that one end can quickly detect when the peer has lost the 
context state, even when the state isn't used (when the ULIDs are used 
as locators), is far from inexpensive.

> In any case, if the procedure you described in the previous mail for 
> including both the context identifier and the nonce in a compact way in 
> 20 bits, we could stuff all we need in all data packets, i guess, so if 
> the flow label approach is used, all data packets of established shim 
> sessions can be identified as such

No, that isn't sufficient, because there is nothing in a received packet 
which identifies it to the receiver (which has lost context) as a shim6 
packet. Any packet can have a non-zero flow label, so that isn't a 
useful indication.

So you'd need to add at least one bit to every data packet to be able to 
do this.

> ok, now i am confused
> AFAIU until now, if we want to detect context loss based on the 
> reception of data packets, we need to have some falg in the data packet 
> that this packet belongs to a existent shim session. If we eliminate 
> this bit, then we cannot detect loss context from data packets, right? 
> or have i lost track of our reasoning?

If B receives a packet from A1 to B1 with flow label 12345 and a nexthdr 
of UDP, then if B has no context for <A1, B1, 12345>, how can B tell 
whether this is due to
  - there never having been a shim6 context - A might not be shim6 
capable for instance
  - B having had such a context but has garbage collected too early

  Erik

Delivery-date: Fri, 27 May 2005 16:22:28 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 18:21:59 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-mei-2005, at 17:28, marcelo bagnulo braun wrote:

>> However, if we assume that bidirectional connectivity is the most  
>> common, the fact that A sent something and B didn't get it is a  
>> good hint for B that this address probably won't work in the  
>> opposite direction either.

>> Since we want to arrive at one or two "good enough" pairs as  
>> quickly as possible, such hints could be valuable.

> ok, this is a choice that we need to make: do we think that the  
> bidirectional connectivity case will be common, so it makes sense  
> to provide an optimized support for it?

Most failures break connectivity in both directions. Only when the  
unreachability is because of ingress filtering (or maybe some other  
filtering), unidirectional reachability is much more likely.

> (because, this could also apply to the other threat that we are  
> having, about detecting outages, right?

How is this "other"??

> well, i guess i would always reply quite fast, but i would always  
> include info about past probes... but i guess i will be able to see  
> this point clearer once we have sketched a protocol

We have to be careful with this stuff: suppose a link for a site with  
many hosts goes down, then all those hosts are going to do  
reachability testing for all their sessions at the same time.

 From your other message:

>> I would think that if one side triggers reachability testing, the  
>> other side would also do it.

> wouldn't this mean assuming bidirectional connectivity?

> I mean, would also do this is the locators used in one direction  
> differ from the ones used in the other direction?

I don't understand...

If the upper layers are communicating, there is some kind of  
reachability. Could be that it's 2 x unidirectional hidden by shim  
magic, but still.

If packets aren't flowing at it looks like this isn't because  
applications are idle, we need to test reachability. At this point we  
don't assume bidirectional reachability: it's highly likely that the  
current testing was triggered by an outage, so it's even possible  
that there is _no_ reachability.

The thing is that we need to decide which paths are most likely to be  
viable, and test them quickly. If that doesn't work, we have to start  
checking less and less likely paths until we've tested everything in  
every direction at least two or three times.

Delivery-date: Fri, 27 May 2005 15:29:49 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 17:29:42 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/05/2005, a las 17:26, Iljitsch van Beijnum escribi=F3:

> On 27-mei-2005, at 17:10, marcelo bagnulo braun wrote:
>
>>>> well, this wouldn't really tell you that the path is working for=20
>>>> sure, right?
>
>>> Node A could be sending and receiving while there is a failure, but=20=

>>> in that case, B wouldn't be receiving data. So if both sides do=20
>>> this, it works well.
>
>> ok, but the one that needs to react is node A in this case, right? so=20=

>> how does node A finds out the problem?
>
> I would think that if one side triggers reachability testing, the=20
> other side would also do it.

wouldn't this mean assuming bidirectional connectivity?

I mean, would also do this is the locators used in one direction differ=20=

from the ones used in the other direction?

Regards, marcelo

>  The probes in one direction can also function as replies in the other=20=

> direction, cutting down on the number of packets exchanged.
>

Delivery-date: Fri, 27 May 2005 15:28:36 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 17:28:25 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/05/2005, a las 17:22, Iljitsch van Beijnum escribi=F3:

> On 27-mei-2005, at 16:35, marcelo bagnulo braun wrote:
>
>>> However, it gets even better if we also include ids and address pair=20=

>>> info for probes we recently sent or maybe even are about to send.
>
>> i don't see how this is useful... see below
>
>>> So if A sends out 6 probes using 6 address pairs and puts a=20
>>> "manifest" for the whole batch of probes into each of them, then B=20=

>>> can, after waiting a bit, determine that there is reachability from=20=

>>> A to B for 3 pairs and, presumably, unreachability for the other 3=20=

>>> pairs. B then includes this information in its replies to A and A=20
>>> then knows exact reachability information for all address pairs in=20=

>>> the A -> B direction. (Well, probably want to send more than one=20
>>> probe per pair when you need to be absolutely sure.)
>
>> the relevant information here is that B send A what probes B has=20
>> received. A informing B about whta probes A sent does not provide any=20=

>> help, AFAICT.
>
> You're mostly right: it doesn't provide the benefits I thought it=20
> would: B doesn't really need to know about reachability from A to B,=20=

> and A can already determine from what it knows it sent and what it=20
> gets back from B what doesn't work in the A -> B direction.
>
> However, if we assume that bidirectional connectivity is the most=20
> common, the fact that A sent something and B didn't get it is a good=20=

> hint for B that this address probably won't work in the opposite=20
> direction either.
>
> Since we want to arrive at one or two "good enough" pairs as quickly=20=

> as possible, such hints could be valuable.
>

ok, this is a choice that we need to make: do we think that the=20
bidirectional connectivity case will be common, so it makes sense to=20
provide an optimized support for it?

(because, this could also apply to the other threat that we are having,=20=

about detecting outages, right?

> Something else:
>
> Sometimes, the sender may want to receive a positive reply=20
> immediately, while in other cases it may prefer that the other side=20
> wait for a while and send a report that covers a number of probes.=20
> Most likely: A sends some probes to B, and it wants an immediate reply=20=

> from B when B receives the first probe, and then a second reply for=20
> all the other probes after sufficient time has passed for B to have=20
> received them all.
>
> It's probably useful to include a field that governs the reply=20
> immediacy.
>

well, i guess i would always reply quite fast, but i would always=20
include info about past probes... but i guess i will be able to see=20
this point clearer once we have sketched a protocol

regards, marcelo

Delivery-date: Fri, 27 May 2005 15:26:23 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 17:26:13 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-mei-2005, at 17:10, marcelo bagnulo braun wrote:

>>> well, this wouldn't really tell you that the path is working for  
>>> sure, right?

>> Node A could be sending and receiving while there is a failure,  
>> but in that case, B wouldn't be receiving data. So if both sides  
>> do this, it works well.

> ok, but the one that needs to react is node A in this case, right?  
> so how does node A finds out the problem?

I would think that if one side triggers reachability testing, the  
other side would also do it. The probes in one direction can also  
function as replies in the other direction, cutting down on the  
number of packets exchanged.

Delivery-date: Fri, 27 May 2005 15:23:01 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 17:22:48 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-mei-2005, at 16:35, marcelo bagnulo braun wrote:

>> However, it gets even better if we also include ids and address  
>> pair info for probes we recently sent or maybe even are about to  
>> send.

> i don't see how this is useful... see below

>> So if A sends out 6 probes using 6 address pairs and puts a  
>> "manifest" for the whole batch of probes into each of them, then B  
>> can, after waiting a bit, determine that there is reachability  
>> from A to B for 3 pairs and, presumably, unreachability for the  
>> other 3 pairs. B then includes this information in its replies to  
>> A and A then knows exact reachability information for all address  
>> pairs in the A -> B direction. (Well, probably want to send more  
>> than one probe per pair when you need to be absolutely sure.)

> the relevant information here is that B send A what probes B has  
> received. A informing B about whta probes A sent does not provide  
> any help, AFAICT.

You're mostly right: it doesn't provide the benefits I thought it  
would: B doesn't really need to know about reachability from A to B,  
and A can already determine from what it knows it sent and what it  
gets back from B what doesn't work in the A -> B direction.

However, if we assume that bidirectional connectivity is the most  
common, the fact that A sent something and B didn't get it is a good  
hint for B that this address probably won't work in the opposite  
direction either.

Since we want to arrive at one or two "good enough" pairs as quickly  
as possible, such hints could be valuable.

Something else:

Sometimes, the sender may want to receive a positive reply  
immediately, while in other cases it may prefer that the other side  
wait for a while and send a report that covers a number of probes.  
Most likely: A sends some probes to B, and it wants an immediate  
reply from B when B receives the first probe, and then a second reply  
for all the other probes after sufficient time has passed for B to  
have received them all.

It's probably useful to include a field that governs the reply  
immediacy.

Delivery-date: Fri, 27 May 2005 15:10:24 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 17:10:14 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/05/2005, a las 17:05, Iljitsch van Beijnum escribi=F3:

> On 27-mei-2005, at 16:17, marcelo bagnulo braun wrote:
>
>>> Also note that the feedback doesn't always have to be from the=20
>>> actual transport protocol: just observing packets flowing in both=20
>>> directions will tell you that all is well.
>
>> well, this wouldn't really tell you that the path is working for=20
>> sure, right?
>
> Node A could be sending and receiving while there is a failure, but in=20=

> that case, B wouldn't be receiving data. So if both sides do this, it=20=

> works well.
>

ok, but the one that needs to react is node A in this case, right? so=20
how does node A finds out the problem?

regards, marcelo

> (Ok, this has the potential to be a big problem: what happens if there=20=

> is significant packet loss, but enough packets make it so the shim=20
> doesn't see the problem?)
>

Delivery-date: Fri, 27 May 2005 15:05:49 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 17:05:31 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-mei-2005, at 16:17, marcelo bagnulo braun wrote:

>> Also note that the feedback doesn't always have to be from the  
>> actual transport protocol: just observing packets flowing in both  
>> directions will tell you that all is well.

> well, this wouldn't really tell you that the path is working for  
> sure, right?

Node A could be sending and receiving while there is a failure, but  
in that case, B wouldn't be receiving data. So if both sides do this,  
it works well.

(Ok, this has the potential to be a big problem: what happens if  
there is significant packet loss, but enough packets make it so the  
shim doesn't see the problem?)

Delivery-date: Fri, 27 May 2005 14:36:07 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 16:35:45 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/05/2005, a las 16:00, Iljitsch van Beijnum escribi=F3:

> On 17-mei-2005, at 20:15, marcelo bagnulo braun wrote:
>
>> The next question is what is the form of the packet exchange required=20=

>> for Address pair Exploration and what information need to be included=20=

>> in those packets. The faildet draft defines a mechanisms where nodes=20=

>> send multiple poll messages using different address pairs. In each of=20=

>> those poll packets, the node includes reachability information=20
>> obtained from previously received poll packets.
>> So, what is the information that needs to be included in these poll=20=

>> packets?
>> It seems that the minimum required is to include enough information=20=

>> to allow the node to identify which packet was received by the peer.
>
> [...]
>
>> So, each poll packet needs to contain the following information:
>> - its own poll packet identifier
>> - the poll packet identifiers of previously received poll packets, in=20=

>> the case that this poll packet is issued as a reply to a poll packet.
>
>> Anything else? security stuff?
>
> Security stuff? Just make room for TLV options.  :-)
>
> I think including probe identifiers and address information for=20
> recently received packets from the other side is good. This way, out=20=

> of (say) 6 probes sent, 3 received and 1 reply received back at the=20
> original sender, we get to know reachability information for 1 address=20=

> pair and unreachability for 2 address pairs.
>
> However, it gets even better if we also include ids and address pair=20=

> info for probes we recently sent or maybe even are about to send.
>

i don't see how this is useful... see below

> So if A sends out 6 probes using 6 address pairs and puts a "manifest"=20=

> for the whole batch of probes into each of them, then B can, after=20
> waiting a bit, determine that there is reachability from A to B for 3=20=

> pairs and, presumably, unreachability for the other 3 pairs. B then=20
> includes this information in its replies to A and A then knows exact=20=

> reachability information for all address pairs in the A -> B=20
> direction. (Well, probably want to send more than one probe per pair=20=

> when you need to be absolutely sure.)
>

the relevant information here is that B send A what probes B has=20
received. A informing B about whta probes A sent does not provide any=20
help, AFAICT.

I mean, B will inform A that B has received 3 probes. A already knows=20
that a has sent 6 probes, so A knows which path are not working. What=20
is the pointing in allowing A to inform B about the probes that A has=20
sent?

regards, marcelo

> Additionally, there should be timestamps everywhere. This means that=20=

> after receiving a second probe, it becomes possible to determine the=20=

> relative unidirectional delay for each reachable address pair.

>
> An important objective of this sub-protocol is to know when to stop=20
> probing, as the number of possible address pairs goes through the roof=20=

> when both ends have more than a couple of addresses.
>
>

Delivery-date: Fri, 27 May 2005 14:17:28 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 16:17:13 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/05/2005, a las 15:30, Iljitsch van Beijnum escribi=F3:

> On 17-mei-2005, at 20:15, marcelo bagnulo braun wrote:
>
>>> I think we can use the same host mechanism which avoids NUD probes=20=

>>> to avoid reachability tests (this mechanism is a positive advise=20
>>> "everything is fine" from the transport layer to the IP layer).
>>> For transports like TCP that is sufficient.
>
>> well, i guess that my perception is that ULP feedback is not so=20
>> common, and that it will be common to fall back in reachability test=20=

>> to verify that the path is working...
>> Does current TCP usually implement this positive feedback for=20
>> avoiding NUD?
>
> I can't be sure but I don't think host operating systems such as the=20=

> KAME/BSD family and Linux currently implement NUD.
>
> Also note that the feedback doesn't always have to be from the actual=20=

> transport protocol: just observing packets flowing in both directions=20=

> will tell you that all is well.

well, this wouldn't really tell you that the path is working for sure,=20=

right?

I mean a host can be sending and receiving packets but the packets it=20
is sending may not be reaching the other end, right?
moreover, how do you apply this to the unidrectional connectivty case?

regards, marcelo

>  This should be easy to implement in the shim.
>

Delivery-date: Fri, 27 May 2005 14:00:20 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 16:00:05 +0200
To: marcelo bagnulo braun <[email-masked]>

On 17-mei-2005, at 20:15, marcelo bagnulo braun wrote:

> The next question is what is the form of the packet exchange  
> required for Address pair Exploration and what information need to  
> be included in those packets. The faildet draft defines a  
> mechanisms where nodes send multiple poll messages using different  
> address pairs. In each of those poll packets, the node includes  
> reachability information obtained from previously received poll  
> packets.
> So, what is the information that needs to be included in these poll  
> packets?
> It seems that the minimum required is to include enough information  
> to allow the node to identify which packet was received by the peer.

[...]

> So, each poll packet needs to contain the following information:
> - its own poll packet identifier
> - the poll packet identifiers of previously received poll packets,  
> in the case that this poll packet is issued as a reply to a poll  
> packet.

> Anything else? security stuff?

Security stuff? Just make room for TLV options.  :-)

I think including probe identifiers and address information for  
recently received packets from the other side is good. This way, out  
of (say) 6 probes sent, 3 received and 1 reply received back at the  
original sender, we get to know reachability information for 1  
address pair and unreachability for 2 address pairs.

However, it gets even better if we also include ids and address pair  
info for probes we recently sent or maybe even are about to send.

So if A sends out 6 probes using 6 address pairs and puts a  
"manifest" for the whole batch of probes into each of them, then B  
can, after waiting a bit, determine that there is reachability from A  
to B for 3 pairs and, presumably, unreachability for the other 3  
pairs. B then includes this information in its replies to A and A  
then knows exact reachability information for all address pairs in  
the A -> B direction. (Well, probably want to send more than one  
probe per pair when you need to be absolutely sure.)

Additionally, there should be timestamps everywhere. This means that  
after receiving a second probe, it becomes possible to determine the  
relative unidirectional delay for each reachable address pair.

An important objective of this sub-protocol is to know when to stop  
probing, as the number of possible address pairs goes through the  
roof when both ends have more than a couple of addresses.

Delivery-date: Fri, 27 May 2005 13:40:09 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 15:39:54 +0200
To: [email-masked]

On 26-mei-2005, at 5:39, Greg Daley wrote:

> For self-authentication, you'd basically require the original
> data sender to have enough context left to authenticate the peer,
> based on their IP address information (For example if CGA
> addresses were locators, and the public key was known).
> Timestamp information gathered previously for the CGA address
> may be able to be used to ensure freshness.

> Some of these mechanisms were used in SEND, but become suspect
> for devices which have lost context state on the other side of the
> Internet.  It's possible to say though, that if the error message
> contains a valid signature and timestamp, it's immediately verified.

Signature checks are relatively expensive: these are exactly the  
operations you want to avoid for suspect packets.

However, this could easily be done by having A give B a nonce that is  
(for instance) a timestamp and a hash over B's IP address, the  
timestamp and some secret data. If A then loses its state for B, B  
can prove to A it talked to A at the indicated time, and A can check  
this as long as it still has its piece of secret data. Since this  
doesn't have to change often, that will be likely.

Delivery-date: Fri, 27 May 2005 13:35:11 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Fri, 27 May 2005 15:35:03 +0200
To: Margaret Wasserman <[email-masked]>

On 19-mei-2005, at 23:29, Margaret Wasserman wrote:

> I agree with Geoff -- SHIM6 will represent a major change to IPv6,  
> anyway, so adding an extension header is not unreasonable.

However, the sender putting in a header when the receiver doesn't  
need it would be unreasonable.

> My concern (once upon a time) with extension headers is that the  
> use of extension headers on some packets and not others effectively  
> presents a variable MTU to upper layers.  We need to make sure that  
> this is properly handled to avoid bad interactions with PMTU  
> discovery code.

This has nothing to do with PMTUD as MTU is the size of the packet  
including all headers. What you mean is the MSS, the maximum segment  
size. In all implementations I've seen TCP is smart enough to adapt  
its MSS to the MTU and additional headers statically. So presumably,  
it could do the same thing dymanically by just invoking the same  
mechanism for every packet. So worst case, all that's needed are  
performance optimizations.

Delivery-date: Fri, 27 May 2005 13:30:49 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 27 May 2005 15:30:07 +0200
To: marcelo bagnulo braun <[email-masked]>

On 17-mei-2005, at 20:15, marcelo bagnulo braun wrote:

>> I think we can use the same host mechanism which avoids NUD probes  
>> to avoid reachability tests (this mechanism is a positive advise  
>> "everything is fine" from the transport layer to the IP layer).
>> For transports like TCP that is sufficient.

> well, i guess that my perception is that ULP feedback is not so  
> common, and that it will be common to fall back in reachability  
> test to verify that the path is working...
> Does current TCP usually implement this positive feedback for  
> avoiding NUD?

I can't be sure but I don't think host operating systems such as the  
KAME/BSD family and Linux currently implement NUD.

Also note that the feedback doesn't always have to be from the actual  
transport protocol: just observing packets flowing in both directions  
will tell you that all is well. This should be easy to implement in  
the shim.

Delivery-date: Fri, 27 May 2005 08:27:11 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 10:27:07 +0200
To: Erik Nordmark <[email-masked]>

El 26/05/2005, a las 23:02, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> but this would require to include in all data packets of a context=20
>> session the following information:
>> - some indication that this is a shim data packets (note that until=20=

>> now, data packets exchanged within a shim session that used ULIDs as=20=

>> locators were not necesarily tagged as shim packets i.e. there were=20=

>> simple IP packets. this would need to change if these data packets=20
>> are to be used to detect context loss)
>> - some context identifier in order to properly id to involved context
>> - some random nonce in order to limit TCP rst type of attacks to mitm
>> Note that the flow label option for carrying context id can carry a=20=

>> context id, perhaps a shim flag bit but i guess it cannot carry the=20=

>> random nonce.
>> The extension header can carry the three of them, but it may be=20
>> required to carry it in all shim data packets
>
> I'm not sure what type of state loss you are trying to guard against,=20=

> because there are at least two.
>
> 1. B crashes and reboots hence it looses all shim6 as well as=20
> transport and application state.
> 2. The shim6 layer on B garbage collects some context too early - when=20=

> there is still some use of it.
>
> In #1 it is key that we can get A to realize that the context has been=20=

> lost on B, so that we can get to the point where the shim on B can=20
> pass up the packets to the ULPs. This will cause the ULPs to generate=20=

> errors (e.g. TCP RST) and we are back to what we have today without a=20=

> shim.
>

besides at this point, there is no possible recovery, since ULP state=20
also has been lost

> For #2 I think we should figure out how an implementation can minimize=20=

> the occurrence. But in many implementations I suspect we can't=20
> completely get rid of them when there are long lived UDP "sessions" in=20=

> the applications; the kernel TCP/UDP/IP stack wouldn't be aware of=20
> such "sessions".
>

this is the case that i am more concerned, since this would be the case=20=

where the shim mechanism behaviour results in communication=20
interruption.

> Above you seem to be concerned about case #2, with the added twist=20
> that the context state has been established but the original ULIDs=20
> still work as locators.
> I think I commented before that the heuristics on B for deferred=20
> context establishment might recover from this. If the heuristic is to=20=

> try to set up a shim6 context after N packets, then after N packets=20
> have passed, B would try to set up a context with A, at which point A=20=

> would see that it already has a context with B.
>

right, the only point that i wonder w.r.t. this is if it is wise to=20
base the context loss detection procedure on the heuristics to=20
establish shim context... i mean, the heuristics for establishing shim=20=

context may greatly vary, i guess. For instance, i think it may be a=20
possibility that some heavy loaded servers use the policy to never=20
initiate shim session establishment procedure, but they only accept=20
establishment request from clients. In such a case, they wouldn't=20
detect context loss.

In any case, if the procedure you described in the previous mail for=20
including both the context identifier and the nonce in a compact way in=20=

20 bits, we could stuff all we need in all data packets, i guess, so if=20=

the flow label approach is used, all data packets of established shim=20
sessions can be identified as such

> Should the <A1, B1> locator pair fail before those N packets, then if=20=

> A detects the failure it will start probing additional locator pairs.=20=

> As you've pointed out earlier, it makes sense for this probing to also=20=

> be able to detect when the context is unknown to B.
>
> So I think the only case which might be problematic is when
>  - B garbage collects the context state while it is still used
>  - <A1, B1> stops working before N packets have been exchanged after=20=

> the
>    garbage collection
>  - A doesn't detect that there was a failure (because A isn't trying =
to
>    send something)
>
> In this case B wouldn't be able to recover, because it doesn't have=20
> any context state hence doesn't know the alternate locator pairs.
>
> I don't think this case is common enough to warrant sticking a lot of=20=

> extra bits in each data packet.

agree, the question is what happens if the session context=20
establishment heuristics are different.

> I wonder if it is even worth while to include one extra bit in the=20
> data packets (this would be a bit which asserts that the sender has=20
> shim6 state for the context).

ok, now i am confused
AFAIU until now, if we want to detect context loss based on the=20
reception of data packets, we need to have some falg in the data packet=20=

that this packet belongs to a existent shim session. If we eliminate=20
this bit, then we cannot detect loss context from data packets, right?=20=

or have i lost track of our reasoning?

regards, marcelo

> It's hard to find a free bit, and the "usual" :-) place to steal one=20=

> is the nexthdr field, which would raise a bunch of issues about=20
> firewall uniformity. (If a TCP packet is 6 before the context state is=20=

> setup, and e.g. 250 after it has been setup, then firewalls might drop=20=

> the packets after the setup even though the initial TCP packets made=20=

> it through.)
>
> So I'd punt on this rare case. If B drops context state too early then=20=

> it shouldn't be surprised if failover to a different locator pair=20
> doesn't work.
>

>    Erik
>

Delivery-date: Fri, 27 May 2005 08:12:39 +0000
Cc: [email-masked], shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Fri, 27 May 2005 10:12:28 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

I think this mechanism you outline can do thee trick.
thanks, marcelo

El 26/05/2005, a las 22:42, Erik Nordmark escribi=F3:

>
>> As i think we concluded a while ago, the key point is that these=20
>> particular error messages cannot be sent spontaneously, but must be=20=

>> sent as a reply to a packet of the context (which must carry this=20
>> random nonce)
>
> Yes, only as a reply.
>
>> this, i guess imposes that data packets of the context, that need to=20=

>> be demuxed, need not only to carry the context tag, but also this=20
>> security nonce.
>
> If the context tag is big enough and randomly allocated (at least hard=20=

> to guess), then it would be sufficient. Question is how big would be=20=

> sufficient? 20 bits?
>
> We can do a two step scheme where the hosts allocate large context=20
> tags, but the data packets only contain the last N bits of the tag.
> This would allow e.g. the shim6 signaling to use the tags with all the=20=

> bits (which makes it harder for off-path attackers to inject bogus=20
> shim6 signaling messages).
> But one can also then use this for the lost context case as in:
> 1. A sends data packet to B. Contains a small number of bits of the=20
> context tag.
> 2. B doesn't have any state. Responds with an error which includes the=20=

> above bits.
> 3. A sends a "have you really lost the context" message, which=20
> includes the full context tag.
> 4. B responds and echoes the full context tag.
>
> I guess a variant of this is that the context tag remains short and in=20=

> #3 there is a random nonce plus the shortish context tag.
>
>    Erik
>
>

Delivery-date: Fri, 27 May 2005 07:46:57 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: are there any news about the creation of the shim wg?
Date: Fri, 27 May 2005 09:46:22 +0200
To: Geoff Huston <[email-masked]>

Hi Geoff,

El 27/05/2005, a las 4:54, Geoff Huston escribi=F3:

> At 10:08 PM 26/05/2005, marcelo bagnulo braun wrote:
>> Can we expect to have a shim wg for Paris?
>
>
> Yes, I have been assured by our assumed-to-be-AD, Margaret, that this=20=

> will be the case. The shim6 proposed charter was submitted to the IESG=20=

> some weeks back and we are now awaiting the outcomes of the IESG's=20
> considerations of this proposed charter.
>

ok thanks,

> Kurtis and I were thinking of a 2 hour slot for this initial wg=20
> meeting. We could make some starting movement now by thinking about=20
> what we'd like to achieve in terms of preparation for the Paris=20
> meeting and what we'd like to consider at the face-to-face meeting.
>

Well, i guess that there a couple of issues that we have been=20
discussing that are relevant imho:
- context tags: where to carry them?
- shim state management: in particular, how to finnish shim sessions=20
(how to discard shim state, garbage collection) how to detect state=20
loss, and its relation with other signaling.

i guess we still have a long way to get consensus, but it may be worth=20=

discussing about this...

regards, marcelo

> regards,
>
>     Geoff
>
>
>
>
>

Delivery-date: Fri, 27 May 2005 02:54:36 +0000
Date: Fri, 27 May 2005 12:54:10 +1000
To: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: are there any news about the creation of the shim wg?

At 10:08 PM 26/05/2005, marcelo bagnulo braun wrote:
>Can we expect to have a shim wg for Paris?

Yes, I have been assured by our assumed-to-be-AD, Margaret, that this will 
be the case. The shim6 proposed charter was submitted to the IESG some 
weeks back and we are now awaiting the outcomes of the IESG's 
considerations of this proposed charter.

Kurtis and I were thinking of a 2 hour slot for this initial wg meeting. We 
could make some starting movement now by thinking about what we'd like to 
achieve in terms of preparation for the Paris meeting and what we'd like to 
consider at the face-to-face meeting.

regards,

     Geoff

Delivery-date: Fri, 27 May 2005 00:21:27 +0000
Date: Fri, 27 May 2005 10:15:58 +1000
From: Greg Daley <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
To: marcelo bagnulo braun <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Marcelo.

marcelo bagnulo braun wrote:
[cut]
>> In order to ensure that context error messages aren't ignored like
>> destination unreachables, it may be valuable to work out a way
>> of verifying the messages.
>>
>> So either the error message needs to self-authenticate (potentially
>> difficult considering context has been lost), or be used as a hint
>> to the peer to check the path with further signalling.
>>
>> This works so long as in a resultant state checking exchange, there's
>> a liveness mechanism at least (nonce?) which can be known to be fresh.
>>
> 
> I think that the security achieved by including some random nonce 
> present in the original packet in the error packet would be good enough. 
> such approach would imply that only on path attackers can generate fake 
> error messages.
> Probably this can be complemented by a context reestablishment strategy, 
> in order to re create the lost context. In case that the context has not 
> been lost, peers should be able to detect it.
> 
> As i think we concluded a while ago, the key point is that these 
> particular error messages cannot be sent spontaneously, but must be sent 
> as a reply to a packet of the context (which must carry this random nonce)
> 
> this, i guess imposes that data packets of the context, that need to be 
> demuxed, need not only to carry the context tag, but also this security 
> nonce.

I really don't like where that's going.  In order to get any sort of
reasonable sized nonce, there will have to be nonces or sequence numbers
big enough to handle at least an RTT worth of data.

That's because we're not necessarily able to rely on the data contents
of the packet itself being dissimilar enough to allow matching.

This means that for the advantage of a rare occurrence of context loss,
we'd have overhead of 2, 4, 6 or 8 bytes (not looked into the details,
but even two bytes may be unpleasant if it doesn't already fit into a
proposed extension header) in every data packet.

I'd really dislike such a mechanism if it wasn't able to be carried
within the existing overheads from the context tag.

It's actually more likely that the sender will get a
"Destination Unreachable" message than a context lost message, and less
is done for that.

I like the idea of Erik's that the context is included in the error,
and subsequent queries may be used to determine a live end-point has
actually lost the context.

Greg

Delivery-date: Thu, 26 May 2005 21:02:00 +0000
Date: Thu, 26 May 2005 14:02:06 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

marcelo bagnulo braun wrote:

> but this would require to include in all data packets of a context 
> session the following information:
> - some indication that this is a shim data packets (note that until now, 
> data packets exchanged within a shim session that used ULIDs as locators 
> were not necesarily tagged as shim packets i.e. there were simple IP 
> packets. this would need to change if these data packets are to be used 
> to detect context loss)
> - some context identifier in order to properly id to involved context
> - some random nonce in order to limit TCP rst type of attacks to mitm
> 
> Note that the flow label option for carrying context id can carry a 
> context id, perhaps a shim flag bit but i guess it cannot carry the 
> random nonce.
> The extension header can carry the three of them, but it may be required 
> to carry it in all shim data packets

I'm not sure what type of state loss you are trying to guard against, 
because there are at least two.

1. B crashes and reboots hence it looses all shim6 as well as transport 
and application state.
2. The shim6 layer on B garbage collects some context too early - when 
there is still some use of it.

In #1 it is key that we can get A to realize that the context has been 
lost on B, so that we can get to the point where the shim on B can pass 
up the packets to the ULPs. This will cause the ULPs to generate errors 
(e.g. TCP RST) and we are back to what we have today without a shim.

For #2 I think we should figure out how an implementation can minimize 
the occurrence. But in many implementations I suspect we can't 
completely get rid of them when there are long lived UDP "sessions" in 
the applications; the kernel TCP/UDP/IP stack wouldn't be aware of such 
"sessions".

Above you seem to be concerned about case #2, with the added twist that 
the context state has been established but the original ULIDs still work 
as locators.
I think I commented before that the heuristics on B for deferred context 
establishment might recover from this. If the heuristic is to try to set 
up a shim6 context after N packets, then after N packets have passed, B 
would try to set up a context with A, at which point A would see that it 
already has a context with B.

Should the <A1, B1> locator pair fail before those N packets, then if A 
detects the failure it will start probing additional locator pairs. As 
you've pointed out earlier, it makes sense for this probing to also be 
able to detect when the context is unknown to B.

So I think the only case which might be problematic is when
  - B garbage collects the context state while it is still used
  - <A1, B1> stops working before N packets have been exchanged after the
    garbage collection
  - A doesn't detect that there was a failure (because A isn't trying to
    send something)

In this case B wouldn't be able to recover, because it doesn't have any 
context state hence doesn't know the alternate locator pairs.

I don't think this case is common enough to warrant sticking a lot of 
extra bits in each data packet.
I wonder if it is even worth while to include one extra bit in the data 
packets (this would be a bit which asserts that the sender has shim6 
state for the context).
It's hard to find a free bit, and the "usual" :-) place to steal one is 
the nexthdr field, which would raise a bunch of issues about firewall 
uniformity. (If a TCP packet is 6 before the context state is setup, and 
e.g. 250 after it has been setup, then firewalls might drop the packets 
after the setup even though the initial TCP packets made it through.)

So I'd punt on this rare case. If B drops context state too early then 
it shouldn't be surprised if failover to a different locator pair 
doesn't work.

    Erik

Delivery-date: Thu, 26 May 2005 20:43:10 +0000
Date: Thu, 26 May 2005 13:42:57 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

> As i think we concluded a while ago, the key point is that these 
> particular error messages cannot be sent spontaneously, but must be sent 
> as a reply to a packet of the context (which must carry this random nonce)

Yes, only as a reply.

> this, i guess imposes that data packets of the context, that need to be 
> demuxed, need not only to carry the context tag, but also this security 
> nonce.

If the context tag is big enough and randomly allocated (at least hard 
to guess), then it would be sufficient. Question is how big would be 
sufficient? 20 bits?

We can do a two step scheme where the hosts allocate large context tags, 
but the data packets only contain the last N bits of the tag.
This would allow e.g. the shim6 signaling to use the tags with all the 
bits (which makes it harder for off-path attackers to inject bogus shim6 
signaling messages).
But one can also then use this for the lost context case as in:
1. A sends data packet to B. Contains a small number of bits of the 
context tag.
2. B doesn't have any state. Responds with an error which includes the 
above bits.
3. A sends a "have you really lost the context" message, which includes 
the full context tag.
4. B responds and echoes the full context tag.

I guess a variant of this is that the context tag remains short and in 
#3 there is a random nonce plus the shortish context tag.

    Erik

Delivery-date: Thu, 26 May 2005 12:16:53 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Thu, 26 May 2005 14:16:45 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

After Greg's message, i have been rethinking your comments here, and i=20=

would like to express further comments...

El 17/05/2005, a las 23:14, Erik Nordmark escribi=F3:

>> State Loss:
>> -----------
>> The goal here is to detect if the context state has been lost. The=20
>> reasons for this lost may be related with failures, or with early=20
>> garbage collection.
>> The packet exchange would require the following information:
>> - a packet that refers to an existent context. This packet need to be=20=

>> identified as a shim packet and must contain context identification=20=

>> (i.e. context tag). In addition, the packet needs to include a packet=20=

>> identifier, so that it is possible to bound the reply to this initial=20=

>> packet (this is so in order to prevent some forms of attacks similar=20=

>> to TCP reset attacks, where an attacker can force a node to act as if=20=

>> the peer has lost its state)
>
> This makes me realize that the approach to use a separate packet to=20
> detect state loss is a bit less effective than defining a "missing=20
> context" error message which is sent in response to data packets.
>

but this would require to include in all data packets of a context=20
session the following information:
- some indication that this is a shim data packets (note that until=20
now, data packets exchanged within a shim session that used ULIDs as=20
locators were not necesarily tagged as shim packets i.e. there were=20
simple IP packets. this would need to change if these data packets are=20=

to be used to detect context loss)
- some context identifier in order to properly id to involved context
- some random nonce in order to limit TCP rst type of attacks to mitm

Note that the flow label option for carrying context id can carry a=20
context id, perhaps a shim flag bit but i guess it cannot carry the=20
random nonce.
The extension header can carry the three of them, but it may be=20
required to carry it in all shim data packets

> Here is an example with an error message.
> Assume A is communicating with B using <A1, B1> as the locator pair.
> A is seeing upper layer advise indicating that things are ok.
> At time t0 A receives the last positive upper layer advise.
>
> At some time later (t1), A should send some "test" to B.
> But there could be two possible failures to handle:
> 1. B lost (or garbage collected) the context state.
> 2. <A1, B1> stopped working.
>
> In #1 the best thing for A would be to test <A1, B1>.
> In #2 the best thing for A would be to try a different locator pair.
>
> If we had a "missing context" error message, then in case #1 A would=20=

> have received such an error with high probability. Hence when it sees=20=

> nothing coming back it can assume #2 and explore a different locator=20=

> pair.
>

well, i think we still need to explore the potential triggers for a=20
rehoming event, but my feeling is that some of those will be hints,=20
rather than triggers, and that in many situations the currently used=20
locator pair will have to be explictly verified through a reachability=20=

test.

regards, marcelo

> Without such an error message in the protocol it isn't clear to me=20
> what A's strategy should be.
>
>    Erik
>
>
>

Delivery-date: Thu, 26 May 2005 12:08:47 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: are there any news about the creation of the shim wg?
Date: Thu, 26 May 2005 14:08:13 +0200

Can we expect to have a shim wg for Paris?

thanks, marcelo

Delivery-date: Thu, 26 May 2005 10:21:25 +0000
Cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
Date: Thu, 26 May 2005 12:21:00 +0200
To: [email-masked]

Hi Greg,

El 26/05/2005, a las 5:39, Greg Daley escribi=F3:

> Hi,
>
> Sorry about the delay in responding, I've been catching up.
>
> Erik Nordmark wrote:
> [cut]
>>>
>>> - a packet that refers to an existent context. This packet need to=20=

>>> be identified as a shim packet and must contain context=20
>>> identification (i.e. context tag). In addition, the packet needs to=20=

>>> include a packet identifier, so that it is possible to bound the=20
>>> reply to this initial packet (this is so in order to prevent some=20
>>> forms of attacks similar to TCP reset attacks, where an attacker can=20=

>>> force a node to act as if the peer has lost its state)
>> This makes me realize that the approach to use a separate packet to=20=

>> detect state loss is a bit less effective than defining a "missing=20
>> context" error message which is sent in response to data packets.
>> Here is an example with an error message.
>> Assume A is communicating with B using <A1, B1> as the locator pair.
>> A is seeing upper layer advise indicating that things are ok.
>> At time t0 A receives the last positive upper layer advise.
>> At some time later (t1), A should send some "test" to B.
>> But there could be two possible failures to handle:
>> 1. B lost (or garbage collected) the context state.
>> 2. <A1, B1> stopped working.
>> In #1 the best thing for A would be to test <A1, B1>.
>> In #2 the best thing for A would be to try a different locator pair.
>> If we had a "missing context" error message, then in case #1 A would=20=

>> have received such an error with high probability. Hence when it sees=20=

>> nothing coming back it can assume #2 and explore a different locator=20=

>> pair.
>> Without such an error message in the protocol it isn't clear to me=20
>> what A's strategy should be.
>
> In order to ensure that context error messages aren't ignored like
> destination unreachables, it may be valuable to work out a way
> of verifying the messages.
>
> So either the error message needs to self-authenticate (potentially
> difficult considering context has been lost), or be used as a hint
> to the peer to check the path with further signalling.
>
> This works so long as in a resultant state checking exchange, there's
> a liveness mechanism at least (nonce?) which can be known to be fresh.
>

I think that the security achieved by including some random nonce=20
present in the original packet in the error packet would be good=20
enough. such approach would imply that only on path attackers can=20
generate fake error messages.
Probably this can be complemented by a context reestablishment=20
strategy, in order to re create the lost context. In case that the=20
context has not been lost, peers should be able to detect it.

As i think we concluded a while ago, the key point is that these=20
particular error messages cannot be sent spontaneously, but must be=20
sent as a reply to a packet of the context (which must carry this=20
random nonce)

this, i guess imposes that data packets of the context, that need to be=20=

demuxed, need not only to carry the context tag, but also this security=20=

nonce.

Regards, marcelo

> For self-authentication, you'd basically require the original
> data sender to have enough context left to authenticate the peer,
> based on their IP address information (For example if CGA
> addresses were locators, and the public key was known).
> Timestamp information gathered previously for the CGA address
> may be able to be used to ensure freshness.
>
> Some of these mechanisms were used in SEND, but become suspect
> for devices which have lost context state on the other side of the
> Internet.  It's possible to say though, that if the error message
> contains a valid signature and timestamp, it's immediately verified.
>
> I guess the "hint+check" mechanism is a fair one in general though.
> The hint could be afforded more or less weight if it was impossible
> to verify a CGA signature or the timestamp was out of bounds.
>
> Greg
>

Delivery-date: Thu, 26 May 2005 03:45:11 +0000
Date: Thu, 26 May 2005 13:44:52 +1000
From: Greg Daley <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
To: Erik Nordmark <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi,

Erik Nordmark wrote:
> marcelo bagnulo braun wrote:
> 
>> right, good point.
>> but in the three way reachability test that is outlined in the faildet 
>> draft, this exchange could be good for both purposes, right?
> 
> 
> What's outlined in the draft isn't a 3-way exchange but more like two 
> 2-way exchanges. It could probably be extended to "bind" things 
> together, but the details need to be worked out.
> 
>> well, i guess that my perception is that ULP feedback is not so 
>> common, and that it will be common to fall back in reachability test 
>> to verify that the path is working...
>> Does current TCP usually implement this positive feedback for avoiding 
>> NUD?
> 
> 
> I know Solaris has done this since Solaris 8, but I don't know the 
> status of other implementations.

Linux does positive feedback using TCP, but the last-hop router isn't an
endpoint for the TCP connection, so it keeps doing NUD to the
host, even though the host doesn't send NS's to it....

Greg

Delivery-date: Thu, 26 May 2005 03:41:10 +0000
Date: Thu, 26 May 2005 13:39:40 +1000
From: Greg Daley <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss
To: Erik Nordmark <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi,

Sorry about the delay in responding, I've been catching up.

Erik Nordmark wrote:
[cut]
>>
>> - a packet that refers to an existent context. This packet need to be 
>> identified as a shim packet and must contain context identification 
>> (i.e. context tag). In addition, the packet needs to include a packet 
>> identifier, so that it is possible to bound the reply to this initial 
>> packet (this is so in order to prevent some forms of attacks similar 
>> to TCP reset attacks, where an attacker can force a node to act as if 
>> the peer has lost its state)
> 
> 
> This makes me realize that the approach to use a separate packet to 
> detect state loss is a bit less effective than defining a "missing 
> context" error message which is sent in response to data packets.
> 
> Here is an example with an error message.
> Assume A is communicating with B using <A1, B1> as the locator pair.
> A is seeing upper layer advise indicating that things are ok.
> At time t0 A receives the last positive upper layer advise.
> 
> At some time later (t1), A should send some "test" to B.
> But there could be two possible failures to handle:
> 1. B lost (or garbage collected) the context state.
> 2. <A1, B1> stopped working.
> 
> In #1 the best thing for A would be to test <A1, B1>.
> In #2 the best thing for A would be to try a different locator pair.
> 
> If we had a "missing context" error message, then in case #1 A would 
> have received such an error with high probability. Hence when it sees 
> nothing coming back it can assume #2 and explore a different locator pair.
> 
> Without such an error message in the protocol it isn't clear to me what 
> A's strategy should be.

In order to ensure that context error messages aren't ignored like
destination unreachables, it may be valuable to work out a way
of verifying the messages.

So either the error message needs to self-authenticate (potentially
difficult considering context has been lost), or be used as a hint
to the peer to check the path with further signalling.

This works so long as in a resultant state checking exchange, there's
a liveness mechanism at least (nonce?) which can be known to be fresh.

For self-authentication, you'd basically require the original
data sender to have enough context left to authenticate the peer,
based on their IP address information (For example if CGA
addresses were locators, and the public key was known).
Timestamp information gathered previously for the CGA address
may be able to be used to ensure freshness.

Some of these mechanisms were used in SEND, but become suspect
for devices which have lost context state on the other side of the
Internet.  It's possible to say though, that if the error message
contains a valid signature and timestamp, it's immediately verified.

I guess the "hint+check" mechanism is a fair one in general though.
The hint could be afforded more or less weight if it was impossible
to verify a CGA signature or the timestamp was out of bounds.

Greg

Delivery-date: Fri, 20 May 2005 11:09:32 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Fri, 20 May 2005 13:08:43 +0200
To: Margaret Wasserman <[email-masked]>

Hi Margaret,

El 19/05/2005, a las 23:29, Margaret Wasserman escribi=F3:
...
> My concern (once upon a time) with extension headers is that the use=20=

> of extension headers on some packets and not others effectively=20
> presents a variable MTU to upper layers.  We need to make sure that=20
> this is properly handled to avoid bad interactions with PMTU discovery=20=

> code.
>

Right, but note that the extension header is included after a new path=20=

is used. I mean, as long as the communication flows through the initial=20=

paths (i.e. the ULIDs are used as locators) there is no need of the=20
extension header.
Once there is a failure, we need to change the path, which means=20
changing locators and then we need to include the header in data=20
packet.

so considering that the extension header is included as a result of=20
changing paths, it may be reasonable to expect a change in the MTU=20
anyway (because of the path change)

Regards, marcelo

> Margaret
>

Delivery-date: Thu, 19 May 2005 21:31:44 +0000
Date: Thu, 19 May 2005 17:29:30 -0400
To: Geoff Huston <[email-masked]>, Francis Dupont <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Cc: shim6 <[email-masked]>

Hi All,

At 12:14 PM +1000 5/18/05, Geoff Huston wrote:
>>=> I am sorry but I believe to propose major changes in IPv6 is no more
>>a good idea today. Perhaps you have a little deployment where you are
>>but don't expect it is the case everywhere...
>
>I suspect that Shim6 is more of the nature of a "major change" than
>an "insignificant tweak", and the concept of explicit use of extension
>headers  for signalling appeals to me much more than hacking away at
>header bits in the flow label. I would suggest that we should indeed
>attempt to engineer this using extension headers where extension
>headers are logically required.

I agree with Geoff -- SHIM6 will represent a major change to IPv6, 
anyway, so adding an extension header is not unreasonable.

My concern (once upon a time) with extension headers is that the use 
of extension headers on some packets and not others effectively 
presents a variable MTU to upper layers.  We need to make sure that 
this is properly handled to avoid bad interactions with PMTU 
discovery code.

Margaret

Delivery-date: Wed, 18 May 2005 02:15:38 +0000
Date: Wed, 18 May 2005 12:14:52 +1000
To: Francis Dupont <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Cc: shim6 <[email-masked]>

At 07:53 PM 2/05/2005, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    > => basically as there is no way to deal with a new extension header
>    > without
>    > modifying code or more, this will kill all the boxes which are looking
>    > inside packets for good or less good reasons.
>
>    I don't think that in this stadium of IPv6 deployment this is that
>    huge a deal.
>
>=> I am sorry but I believe to propose major changes in IPv6 is no more
>a good idea today. Perhaps you have a little deployment where you are
>but don't expect it is the case everywhere...

I suspect that Shim6 is more of the nature of a "major change" than
an "insignificant tweak", and the concept of explicit use of extension
headers  for signalling appeals to me much more than hacking away at
header bits in the flow label. I would suggest that we should indeed
attempt to engineer this using extension headers where extension
headers are logically required.

regards,

   Geoff

  Geoff

Delivery-date: Tue, 17 May 2005 21:14:14 +0000
Date: Tue, 17 May 2005 14:14:15 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: address pair exploration, flooding and state loss

marcelo bagnulo braun wrote:

> So, each poll packet needs to contain the following information:
> - its own poll packet identifier
> - the poll packet identifiers of previously received poll packets, in 
> the case that this poll packet is issued as a reply to a poll packet.
> 
> Anything else? security stuff?

You might want to include an echo of a nonce (echoed from the previously 
received poll packets) to prevent off-path attackers from being able to 
confuse the protocol.

> State Loss:
> -----------
> 
> The goal here is to detect if the context state has been lost. The 
> reasons for this lost may be related with failures, or with early 
> garbage collection.
> 
> The packet exchange would require the following information:
> 
> - a packet that refers to an existent context. This packet need to be 
> identified as a shim packet and must contain context identification 
> (i.e. context tag). In addition, the packet needs to include a packet 
> identifier, so that it is possible to bound the reply to this initial 
> packet (this is so in order to prevent some forms of attacks similar to 
> TCP reset attacks, where an attacker can force a node to act as if the 
> peer has lost its state)

This makes me realize that the approach to use a separate packet to 
detect state loss is a bit less effective than defining a "missing 
context" error message which is sent in response to data packets.

Here is an example with an error message.
Assume A is communicating with B using <A1, B1> as the locator pair.
A is seeing upper layer advise indicating that things are ok.
At time t0 A receives the last positive upper layer advise.

At some time later (t1), A should send some "test" to B.
But there could be two possible failures to handle:
1. B lost (or garbage collected) the context state.
2. <A1, B1> stopped working.

In #1 the best thing for A would be to test <A1, B1>.
In #2 the best thing for A would be to try a different locator pair.

If we had a "missing context" error message, then in case #1 A would 
have received such an error with high probability. Hence when it sees 
nothing coming back it can assume #2 and explore a different locator pair.

Without such an error message in the protocol it isn't clear to me what 
A's strategy should be.

    Erik

Delivery-date: Tue, 17 May 2005 21:01:41 +0000
Date: Tue, 17 May 2005 14:01:29 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

> right, good point.
> but in the three way reachability test that is outlined in the faildet 
> draft, this exchange could be good for both purposes, right?

What's outlined in the draft isn't a 3-way exchange but more like two 
2-way exchanges. It could probably be extended to "bind" things 
together, but the details need to be worked out.

> well, i guess that my perception is that ULP feedback is not so common, 
> and that it will be common to fall back in reachability test to verify 
> that the path is working...
> Does current TCP usually implement this positive feedback for avoiding NUD?

I know Solaris has done this since Solaris 8, but I don't know the 
status of other implementations.

    Erik

Delivery-date: Tue, 17 May 2005 18:17:03 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: address pair exploration, flooding and state loss
Date: Tue, 17 May 2005 20:15:49 +0200
To: Erik Nordmark <[email-masked]>

Following with the approach suggested in the previous mail, there are 
three functions required that are conceptually different. The 
mechanisms for their provision are likely to require some form of 
packet exchange. the roadmap then is to define what is required for 
each of them and then see potential optimizations that could result 
from the merging of some of the packets involved.
So the three functions are the following:

Address pair Exploration:
------------------------
The goal here is to determine if a given address pair is working i.e. 
that a packet carrying one of the addresses as source address and the 
other one as destination address can actually reach the destination 
from the source.
Note that reachability can be unidirectional, and it is an explicit 
goal to be able to discover unidirectional paths.

The next question is what is the form of the packet exchange required 
for Address pair Exploration and what information need to be included 
in those packets. The faildet draft defines a mechanisms where nodes 
send multiple poll messages using different address pairs. In each of 
those poll packets, the node includes reachability information obtained 
from previously received poll packets.
So, what is the information that needs to be included in these poll 
packets?
It seems that the minimum required is to include enough information to 
allow the node to identify which packet was received by the peer.
Consider the following situation:
node A with address A1 and A2, node B with address B1 and B2

- node A starts address pair exploration sending a poll packet 1 using 
A1 and B1.
- node B replies sending a poll packet 2 using B1 and A1.

The packet needs to carry enough information to allow node A to 
understand that the poll packet 2 is a reply to poll packet 1 i.e. that 
the path from A1 to B1 is working.
Such information could be simply the address pair or a identification 
number of poll packets.

Now, consider a situation where the reverse path is not working (as 
depicted in the faidet draft)

- node A starts address pair exploration sending a poll packet 1 using 
A1 and B1.
- node B replies sending a poll packet 2 using B1 and A1 but this 
packet is lost.
- node B send another poll packet 3, now using A1 and B2, and this 
packet reaches node A

Packet poll 3 should carry information about the fact that poll packet 
1 was properly received by node B (A1 to B1 path is working). This 
again can be achieved carrying the poll packet 1 identifier in poll 
packet 3.

Note that poll packet identifier are assigned by the issuer of the poll 
packets, since it will be used by itself to bind received poll packets 
with issued poll packets. I am assuming here that one poll packet will 
result in many replies and all of the replies will carry the initial 
poll packet identifier.

So, each poll packet needs to contain the following information:
- its own poll packet identifier
- the poll packet identifiers of previously received poll packets, in 
the case that this poll packet is issued as a reply to a poll packet.

Anything else? security stuff?

Flooding protection:
-------------------
The goal here is to determine if the receiver is willing to accept the 
packets belonging to a communication established with a given ULID 
through an  alternative locator.

In this case, it is required to include information about the ULID 
involved in the communication. Note that unidirectional connectivity is 
also a possibility here.

So, this exchange essentially consists in two packets:
- one query packet, that asks if a node is willing to receive packets 
associated with communication involving ULID U though locator Y
- one reply packet that informs that the node is willing to receive 
packets associated with a communication involving ULID U though locator 
Y

Now, note that because of unidirectional connectivity, reply packets 
may have the same addresses than query packet. However, the reply 
packet must contain some information carried in the query packet so 
that the receiver can proof that he is able to receive packets through 
the alternative locator.

So, the information to be carried in the Query packet is:
- the ULID
- the alternative locator (included in the destination address)
- a query identifier
(this packet must include the alternative locator in the dst address 
field)

The reply packet will include:
- the ULID
- THe alternative locator
- the query identifier
(the addresses included in the packet can be any address, no need to be 
the alternative locator or the ULID. The query identifier needs to be 
randomly generated, i.e. its value must not be predictable)

State Loss:
-----------

The goal here is to detect if the context state has been lost. The 
reasons for this lost may be related with failures, or with early 
garbage collection.

The packet exchange would require the following information:

- a packet that refers to an existent context. This packet need to be 
identified as a shim packet and must contain context identification 
(i.e. context tag). In addition, the packet needs to include a packet 
identifier, so that it is possible to bound the reply to this initial 
packet (this is so in order to prevent some forms of attacks similar to 
TCP reset attacks, where an attacker can force a node to act as if the 
peer has lost its state)

In case that the context exists, a affirmative reply packet could be 
defined

In case that the context does not exists, then the reply packet should 
contain:
- inform that the refered context does not exist
- information about the context i.e. context identifier
- initial packet identifier, so that it is possible to proof that this 
packet is a reply to recently sent packet.

Including the context identifier does provide some protection to the 
TCP reset type of attacks, since the attacker need to discover the 
context identifier.
The additional protection provided by including a packet identifier, 
comes form the fact that the attacker needs to have intercepted a 
packet recently (and it is not enough to intercept one packet at any 
time since the session was established) Not sure if the achieved 
protection is worthy though...

Well, once we came up with the set of required information for each 
exchange, then we could move to optimizations, merging these packet 
exchanges...

Regards, marcelo

  

Delivery-date: Tue, 17 May 2005 18:16:33 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Tue, 17 May 2005 20:15:46 +0200
To: Erik Nordmark <[email-masked]>

El 16/05/2005, a las 19:18, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> agree with the point that conceptually these are different things.
>> However, i think that both verifications require a packet exchange,=20=

>> that needs to be performed before sending packets using the involved=20=

>> addresses.
>> I mean, for path exploration we need to verify that packets sent=20
>> using the address pair get to the destiantion
>> For flooding attack prevention, we need to verify that the node that=20=

>> is located in the proposed target address is willing to receive the=20=

>> packets of the existing communication. The only way to do this=20
>> AFAICS, is to send a packet to the new locator and see if the node=20
>> receiving packets sent to that address is willing to receive packets=20=

>> of the communication. Can you think of alternative mechanisms to=20
>> perform flooding prevention that does not involve a packet exchange=20=

>> to the new address?
>
> Presumably they both need to exchange packets.
> But that doesn't mean they flow in the same "directions" for the=20
> locator pair testing and for the flooding attack prevention.
>
> For instance, A might send packets to B (with B responding) to=20
> discover that the A2<->B2 locator pair is working (in both=20
> directions), followed by A telling B "please use locator pair <B2,=20
> A2>".
> At that point in time B hasn't actually verified that A is present at=20=

> locator A2, since B hasn't done a packet exchange that verifies this.
> B needs to send a packet to A2, and expect A to send back the response=20=

> in order to prevent the 3rd party flooding.
>

right, good point.
but in the three way reachability test that is outlined in the faildet=20=

draft, this exchange could be good for both purposes, right?
i mean, to verify reachability in both directions and flood prevention=20=

in both sentences... i guess that for determining what is achieved in=20
the case of failure would require additional analysis

>> I mean, if we need to perform a packet exchange to explore=20
>> alternative paths and we also need a packet exchange in order to=20
>> prevent flooding, i guess it would be reasonable to do it in the same=20=

>> packet exchange, in order to reduce the number of packets, agree?
>
> If the packets are exchanged in the "right" direction, one can=20
> presumably optimize this. But I'd prefer waiting with optimizations=20
> until we have the pieces worked out.
>

Ok, i can live with that.
So conceptually we need three different mechanisms:
- reachability test for (unidirectional) path exploration
- flood prevention mechanism
- context loss detection mechanism

We can now try to understand what it takes for each one of them, and=20
eventually try to mingle them together later on.

>> So, the alternative would be to include the ULID in the reachability=20=

>> test request instead of the context identifier?
>
> Yes.
>
>> I think this could be an option to prevent flooding attacks, but i am=20=

>> not sure what are the benefits of such approach.
>
> The benefits is that you don't need to also worry all the different=20
> combinations of reachability test outcome and context state present.
> My head starts hurting if I try to do all of that at the same time.
>

:-)

ok, i guess that if we follow the dissection approach, we can first=20
identify which information is required for each of the three exchanges=20=

above, and then, when trying to optimize by combining them, we can=20
determine which info needs to be kept in the packets.

> However, it *might be* that a test mechanism which includes both the=20=

> ULID and the context tag(s) would be part of an optimization that can=20=

> minimize the number of messages. That allows the receiver to=20
> distinguish between a test packet delivered to the wrong ULID (perhaps=20=

> a 3rd party DoS attempt, or a bit error in transit) and one delivered=20=

> to the correct ULID, but no context state which matches the context=20
> tag.
>

right

>> Let me write down how this would look like in order to make sure that=20=

>> we are on the same page:
>> node A with IPA1 and IPA2, node B with IPB1 and IPB2
>> node A is communicating with node B and a shim context is established=20=

>> with ULIDs IPA1 and IPB1.
>> Node B includes IPB2 in the locator set available for that=20
>> communication.
>> Now, node A detects a failure and performs a reachability test to=20
>> explore alternative paths and perform flooding prevention.
>> The packet sent from A to B is a reachability test request that=20
>> contains the following information:
>> IP src: IPA1
>> IP dst: IPB2
>> Packet type: reachability test request
>> Additional info: IPB1 as ULID associated with IPB2
>> Now, when node B receives such packet, it can reply because it has=20
>> received it (the path is working) and both IPB1 and IPB2 belong to=20
>> him (no flooding threat)
>> Is something like this what you had in mind?
>
> Yep
>
>
>> Agree that this is not clear, but from 30.000 meters it seems that:
>> - reachability tests may be performed quite often
>
> Why so?
> I think we can use the same host mechanism which avoids NUD probes to=20=

> avoid reachability tests (this mechanism is a positive advise=20
> "everything is fine" from the transport layer to the IP layer).
> For transports like TCP that is sufficient.
>

well, i guess that my perception is that ULP feedback is not so common,=20=

and that it will be common to fall back in reachability test to verify=20=

that the path is working...
Does current TCP usually implement this positive feedback for avoiding=20=

NUD?

Regards, marcelo

Delivery-date: Mon, 16 May 2005 17:19:08 +0000
Date: Mon, 16 May 2005 10:18:43 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

> agree with the point that conceptually these are different things.
> However, i think that both verifications require a packet exchange, that 
> needs to be performed before sending packets using the involved addresses.
> I mean, for path exploration we need to verify that packets sent using 
> the address pair get to the destiantion
> For flooding attack prevention, we need to verify that the node that is 
> located in the proposed target address is willing to receive the packets 
> of the existing communication. The only way to do this AFAICS, is to 
> send a packet to the new locator and see if the node receiving packets 
> sent to that address is willing to receive packets of the communication. 
> Can you think of alternative mechanisms to perform flooding prevention 
> that does not involve a packet exchange to the new address?

Presumably they both need to exchange packets.
But that doesn't mean they flow in the same "directions" for the locator 
pair testing and for the flooding attack prevention.

For instance, A might send packets to B (with B responding) to discover 
that the A2<->B2 locator pair is working (in both directions), followed 
by A telling B "please use locator pair <B2, A2>".
At that point in time B hasn't actually verified that A is present at 
locator A2, since B hasn't done a packet exchange that verifies this.
B needs to send a packet to A2, and expect A to send back the response 
in order to prevent the 3rd party flooding.

> I mean, if we need to perform a packet exchange to explore alternative 
> paths and we also need a packet exchange in order to prevent flooding, i 
> guess it would be reasonable to do it in the same packet exchange, in 
> order to reduce the number of packets, agree?

If the packets are exchanged in the "right" direction, one can 
presumably optimize this. But I'd prefer waiting with optimizations 
until we have the pieces worked out.

> So, the alternative would be to include the ULID in the reachability 
> test request instead of the context identifier?

Yes.

> I think this could be an option to prevent flooding attacks, but i am 
> not sure what are the benefits of such approach.

The benefits is that you don't need to also worry all the different 
combinations of reachability test outcome and context state present.
My head starts hurting if I try to do all of that at the same time.

However, it *might be* that a test mechanism which includes both the 
ULID and the context tag(s) would be part of an optimization that can 
minimize the number of messages. That allows the receiver to distinguish 
between a test packet delivered to the wrong ULID (perhaps a 3rd party 
DoS attempt, or a bit error in transit) and one delivered to the correct 
ULID, but no context state which matches the context tag.

> Let me write down how this would look like in order to make sure that we 
> are on the same page:
> 
> node A with IPA1 and IPA2, node B with IPB1 and IPB2
> 
> node A is communicating with node B and a shim context is established 
> with ULIDs IPA1 and IPB1.
> 
> Node B includes IPB2 in the locator set available for that communication.
> 
> Now, node A detects a failure and performs a reachability test to 
> explore alternative paths and perform flooding prevention.
> 
> The packet sent from A to B is a reachability test request that contains 
> the following information:
> 
> IP src: IPA1
> IP dst: IPB2
> Packet type: reachability test request
> Additional info: IPB1 as ULID associated with IPB2
> 
> Now, when node B receives such packet, it can reply because it has 
> received it (the path is working) and both IPB1 and IPB2 belong to him 
> (no flooding threat)
> 
> Is something like this what you had in mind?

Yep

> Agree that this is not clear, but from 30.000 meters it seems that:
> - reachability tests may be performed quite often

Why so?
I think we can use the same host mechanism which avoids NUD probes to 
avoid reachability tests (this mechanism is a positive advise 
"everything is fine" from the transport layer to the IP layer).
For transports like TCP that is sufficient.

> - if those carry context information, then they can provide a hint of a 
> context loss event, since a node that receives such a packet and does 
> not has the associated context can reply saying the no context is 
> available, allowing the other end (which does have context information) 
> to detect the problem. BTW i guess that the error message could inform 
> if the problem is that the ULID does not belong to the node (potential 
> flooding) or the context tag is non associated to any context (potential 
> context loss)

Yes, you'd want both the ULIDs and the context tag to be able to make 
this distinction.

> well, as i see it, the different packets will be addressed to different 
> addresses, right? so i am not sure that congestion control would limit 
> the rate of packets, since they will be routed through different paths 
> (i am assuming that congestion control is performed per path basis, 
> which i am not sure would be the case though...)

You hope the packets will follow as disjoint paths as possible, but that 
doesn't mean that you can assume that there will be no common point of
congestion between the paths (which really aren't "paths" but merely 
different locator pairs).

    Erik

Delivery-date: Sun, 15 May 2005 07:42:34 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sun, 15 May 2005 09:41:35 +0200
To: marcelo bagnulo braun <[email-masked]>

On 14-mei-2005, at 16:58, marcelo bagnulo braun wrote:

>> The thing is, that you need some kind of semi-reliable  
>> communication to accomplish all of this, and to do the negotiation  
>> too. (In the case of the reasability testing, it would be useful  
>> if the receiver of a probe would have a semi-reliable way of  
>> telling the sender that the probe was received.) There is also  
>> some circularity: you need connectivity to negotiate locators, but  
>> you need to know the locators already to discover connectivity.

> Well, i was thinking in retrying a couple of times, just to keep it  
> simple. I don't know yet if this would provide all that we need though

Even with the minimum number of locators (2 on one side, 1 on the  
other), there are two paths in each direction, making for four  
possibilities for two-way communication. We really need to be smart  
here rather than simple in order to get results fast...

>> I'm thinking we could come up with a kind of "UDP on steroids"  
>> that similarly to SCTP works over multiple addresses. Such a semi- 
>> reliable multi-address datagram protocol would be very useful for  
>> the negotiations and similar exchanges, and it would supply  
>> reachability information as sort of a by-product.

> this sounds quite more complex that what i was thinking about...  
> (maybe it only sounds complex though :-)

You haven't even heard about all the heuristics and optimizations I  
want to implement.  :-)  But apart from that, the way I see it, we  
need this functionality one way or another. Splitting it off and  
making a separate protocol for it will actually make things less  
complex.

>>> :-)
>>> Context state AND path failure AND unidirectional  
>>> connectivity.... this seems amusing enough

>> Since the situations where context state doesn't exist (= before  
>> the start of a session) and unidirectional reachability (caused by  
>> ingress filtering) will be very common, we really need to cover  
>> this case.

> I guess this depends on what solution for ingress filtering  
> compatibility is available i guess

I'm not very hopeful in this area: I think we'll have to make do with  
source address based routing for smaller networks and ingress  
filtering exceptions for larger networks, and possibly make only one  
set of addresses available for non-shim hosts.

Alternatively, we could look into creating a protocol that allows  
users to signal their address blocks to an ISP so the ISP can  
automatically open up ingress filtering. But I'm sure many ISPs won't  
do this for home user-grade service as a means to push multihomers  
towards more expensive services.

Delivery-date: Sat, 14 May 2005 19:56:07 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sat, 14 May 2005 16:58:14 +0200
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

El 14/05/2005, a las 14:46, Iljitsch van Beijnum escribi=F3:
>> The above assumption is based in that i think this is needed to=20
>> properly protect from flooding attacks.
>> I mean, the goal of reachability tests in a shim protocol can be=20
>> two-folded:
>> - to explore if a given address pair is working
>> - to determine if a given host is willing to receive packets at a=20
>> given address (i.e. to prevent flooding attacks)
>
>> the first goal can be achieved with a kind of ping (enhanced ping in=20=

>> order to determine unidirectional reachability) but it may not=20
>> require that the reachability test is associated with a given=20
>> context. I mean, the goal here is just to obtain reachability=20
>> information
>
>> The second goal is somehow different, and since what is being queried=20=

>> is the willingness of the node to receive traffic through a certain=20=

>> address, it is needed to inform the node which traffic are we talking=20=

>> about.
>
> The thing is, that you need some kind of semi-reliable communication=20=

> to accomplish all of this, and to do the negotiation too. (In the case=20=

> of the reasability testing, it would be useful if the receiver of a=20
> probe would have a semi-reliable way of telling the sender that the=20
> probe was received.) There is also some circularity: you need=20
> connectivity to negotiate locators, but you need to know the locators=20=

> already to discover connectivity.
>

Well, i was thinking in retrying a couple of times, just to keep it=20
simple. I don't know yet if this would provide all that we need though

> I'm thinking we could come up with a kind of "UDP on steroids" that=20
> similarly to SCTP works over multiple addresses. Such a semi-reliable=20=

> multi-address datagram protocol would be very useful for the=20
> negotiations and similar exchanges, and it would supply reachability=20=

> information as sort of a by-product.
>

this sounds quite more complex that what i was thinking about... (maybe=20=

it only sounds complex though :-)

> Separating this layer also has the advantage that a simple unprotected=20=

> multi-address datagram protocol can be used for other purposes as=20
> well, and it allows us to layer the solution so that we can work on=20
> different aspects independently.
>
>> :-)
>> Context state AND path failure AND unidirectional connectivity....=20
>> this seems amusing enough
>
> Since the situations where context state doesn't exist (=3D before the=20=

> start of a session) and unidirectional reachability (caused by ingress=20=

> filtering) will be very common, we really need to cover this case.
>

I guess this depends on what solution for ingress filtering=20
compatibility is available i guess

Regards, marcelo

Delivery-date: Sat, 14 May 2005 12:46:38 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sat, 14 May 2005 14:46:18 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-mei-2005, at 15:30, marcelo bagnulo braun wrote:

> I mean, is it possible to create two contexts between the same two  
> nodes with the same two ULIDs (and perhaps a different context  
> tag)? would this make any sense?

Having two contexts between the same hosts can lead to trouble. On  
the other hand, making sure this can't happen is also hard. But we  
should definately not make this something that happens routinely, IMO.

> The above assumption is based in that i think this is needed to  
> properly protect from flooding attacks.
> I mean, the goal of reachability tests in a shim protocol can be  
> two-folded:
> - to explore if a given address pair is working
> - to determine if a given host is willing to receive packets at a  
> given address (i.e. to prevent flooding attacks)

> the first goal can be achieved with a kind of ping (enhanced ping  
> in order to determine unidirectional reachability) but it may not  
> require that the reachability test is associated with a given  
> context. I mean, the goal here is just to obtain reachability  
> information

> The second goal is somehow different, and since what is being  
> queried is the willingness of the node to receive traffic through a  
> certain address, it is needed to inform the node which traffic are  
> we talking about.

The thing is, that you need some kind of semi-reliable communication  
to accomplish all of this, and to do the negotiation too. (In the  
case of the reasability testing, it would be useful if the receiver  
of a probe would have a semi-reliable way of telling the sender that  
the probe was received.) There is also some circularity: you need  
connectivity to negotiate locators, but you need to know the locators  
already to discover connectivity.

I'm thinking we could come up with a kind of "UDP on steroids" that  
similarly to SCTP works over multiple addresses. Such a semi-reliable  
multi-address datagram protocol would be very useful for the  
negotiations and similar exchanges, and it would supply reachability  
information as sort of a by-product.

Separating this layer also has the advantage that a simple  
unprotected multi-address datagram protocol can be used for other  
purposes as well, and it allows us to layer the solution so that we  
can work on different aspects independently.

> :-)
> Context state AND path failure AND unidirectional connectivity....  
> this seems amusing enough

Since the situations where context state doesn't exist (= before the  
start of a session) and unidirectional reachability (caused by  
ingress filtering) will be very common, we really need to cover this  
case.

Delivery-date: Sat, 14 May 2005 12:30:21 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sat, 14 May 2005 14:19:45 +0200
To: Erik Nordmark <[email-masked]>

El 14/05/2005, a las 1:56, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> - Flooding attacks once the shim context is established: in this=20
>> case, an attacker creates a context with a server and starts=20
>> downloading a heavy flow (i know you know this story, but just to=20
>> make sure we are sync), then the attackers rehomes the flow towards=20=

>> an alternative address that belongs to the victim, so the victim is=20=

>> flooded. In this case, the server has context state and the packets=20=

>> involved in the flooding are the data flow (not only reachability=20
>> test packets) Imho, if we are going to use a reachability test=20
>> exchange to prevent this attack, then the reachability test exchange=20=

>> requires additional information than the one is included in the=20
>> reachability test exchange that you describe below.
>
> FWIW I've been assuming that the purpose of the locator pair test=20
> protocol is merely to test which locator pairs are working.
> Shim6 does need a way to prevent this kind of 3rd party flooding=20
> attacks, by verifying that A is indeed present at locator A2, but I=20
> don't see why this needs to be done at the same time as searching for=20=

> a working locator pair.
> Conceptually there is a big difference between searching for a working=20=

> locator pair and verifying whether one of the locators that A says it=20=

> has, does indeed reach ULID A.
>

agree with the point that conceptually these are different things.
However, i think that both verifications require a packet exchange,=20
that needs to be performed before sending packets using the involved=20
addresses.
I mean, for path exploration we need to verify that packets sent using=20=

the address pair get to the destiantion
For flooding attack prevention, we need to verify that the node that is=20=

located in the proposed target address is willing to receive the=20
packets of the existing communication. The only way to do this AFAICS,=20=

is to send a packet to the new locator and see if the node receiving=20
packets sent to that address is willing to receive packets of the=20
communication. Can you think of alternative mechanisms to perform=20
flooding prevention that does not involve a packet exchange to the new=20=

address?

I mean, if we need to perform a packet exchange to explore alternative=20=

paths and we also need a packet exchange in order to prevent flooding,=20=

i guess it would be reasonable to do it in the same packet exchange, in=20=

order to reduce the number of packets, agree?

>> This is because for preventing this attack, the victim needs to know=20=

>> what is the context that is associated with the reachability test=20
>> that it is replying to, in order to verify that the future incoming=20=

>> flow corresponds to an existent context.
>
> You still don't need to check the context tag. It is sufficient to=20
> verify that the ULID A1 is acceptable by whoever responds at locator=20=

> A2.
>

So, the alternative would be to include the ULID in the reachability=20
test request instead of the context identifier?

I think this could be an option to prevent flooding attacks, but i am=20
not sure what are the benefits of such approach.

Let me write down how this would look like in order to make sure that=20
we are on the same page:

node A with IPA1 and IPA2, node B with IPB1 and IPB2

node A is communicating with node B and a shim context is established=20
with ULIDs IPA1 and IPB1.

Node B includes IPB2 in the locator set available for that=20
communication.

Now, node A detects a failure and performs a reachability test to=20
explore alternative paths and perform flooding prevention.

The packet sent from A to B is a reachability test request that=20
contains the following information:

IP src: IPA1
IP dst: IPB2
Packet type: reachability test request
Additional info: IPB1 as ULID associated with IPB2

Now, when node B receives such packet, it can reply because it has=20
received it (the path is working) and both IPB1 and IPB2 belong to him=20=

(no flooding threat)

Is something like this what you had in mind?

I think such scheme would work, but i am not sure about the benefits of=20=

such approach w.r.t. to the case where the full context information is=20=

carried in the reachability test request.

If full context information is included, i guess it would be easier to=20=

detect the cases where there is a context loss

>
>> - reachability test request for exploring alternative address pairs=20=

>> for rehoming an established communication require context information=20=

>> in order to prevent flooding attacks
>
> To prevent the 3rd party flooding attack this verification just needs=20=

> the ULID.
>
>> OTOH, i think that both reachability test exchange will be similar in=20=

>> all the other aspects ( i mean, i don't think that two different=20
>> reachability tests are required for this two situations, only that in=20=

>> one case it will be required to carry context information and in the=20=

>> other one it won't. However, such context information can be useful=20=

>> to detect loss of context, i think
>
> I still have to work out some details to figure out if this really=20
> helps in detecting a lost context.
>

Agree that this is not clear, but from 30.000 meters it seems that:
- reachability tests may be performed quite often
- if those carry context information, then they can provide a hint of a=20=

context loss event, since a node that receives such a packet and does=20
not has the associated context can reply saying the no context is=20
available, allowing the other end (which does have context information)=20=

to detect the problem. BTW i guess that the error message could inform=20=

if the problem is that the ULID does not belong to the node (potential=20=

flooding) or the context tag is non associated to any context=20
(potential context loss)

>
>
>>> and perhaps also trigger its own exploration of the B->A direction=20=

>>> (since it knows that Ai,Bj works for the A->B direction).
>>>
>> at this point i wonder if this exploration may not result in=20
>> amplification attacks?
>
> Perhaps. But any damage can be limited by this being (in addition to=20=

> applying to existing contexts) limited to a few and rate limited=20
> tests.
>
>
>> here is the part that i am concerned, since B would generate 6=20
>> packets as reply to one packet, right?
>
> Yep, but they need to be spaced out according to whatever congestion=20=

> control constraints we have in any case.
>

well, as i see it, the different packets will be addressed to different=20=

addresses, right? so i am not sure that congestion control would limit=20=

the rate of packets, since they will be routed through different paths=20=

(i am assuming that congestion control is performed per path basis,=20
which i am not sure would be the case though...)

>
>> I think this test protocol is ok for initial contact, but that we=20
>> need additional protectio from flooding attacks in the case of a=20
>> rehoming of an existing context, as i described above. for this,=20
>> context information is to be included in the exchange
>
> Yes. But to me that is a conceptually different protocol mechanism.
>

as i said above, conceptually they are different, but in practice, i=20
would guess that they would be the same packet exchange for performance=20=

reasons.

regards, marcelo

>   Erik
>

Delivery-date: Fri, 13 May 2005 23:57:01 +0000
Date: Fri, 13 May 2005 16:56:26 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

> - Flooding attacks once the shim context is established: in this case, 
> an attacker creates a context with a server and starts downloading a 
> heavy flow (i know you know this story, but just to make sure we are 
> sync), then the attackers rehomes the flow towards an alternative 
> address that belongs to the victim, so the victim is flooded. In this 
> case, the server has context state and the packets involved in the 
> flooding are the data flow (not only reachability test packets) Imho, if 
> we are going to use a reachability test exchange to prevent this attack, 
> then the reachability test exchange requires additional information than 
> the one is included in the reachability test exchange that you describe 
> below.

FWIW I've been assuming that the purpose of the locator pair test 
protocol is merely to test which locator pairs are working.
Shim6 does need a way to prevent this kind of 3rd party flooding 
attacks, by verifying that A is indeed present at locator A2, but I 
don't see why this needs to be done at the same time as searching for a 
working locator pair.
Conceptually there is a big difference between searching for a working 
locator pair and verifying whether one of the locators that A says it 
has, does indeed reach ULID A.

> This is because for preventing this attack, the victim needs to 
> know what is the context that is associated with the reachability test 
> that it is replying to, in order to verify that the future incoming flow 
> corresponds to an existent context.

You still don't need to check the context tag. It is sufficient to 
verify that the ULID A1 is acceptable by whoever responds at locator A2.

> - reachability test request for exploring alternative address pairs for 
> rehoming an established communication require context information in 
> order to prevent flooding attacks

To prevent the 3rd party flooding attack this verification just needs 
the ULID.

> OTOH, i think that both reachability test exchange will be similar in 
> all the other aspects ( i mean, i don't think that two different 
> reachability tests are required for this two situations, only that in 
> one case it will be required to carry context information and in the 
> other one it won't. However, such context information can be useful to 
> detect loss of context, i think

I still have to work out some details to figure out if this really helps 
in detecting a lost context.

>> and perhaps also trigger its own exploration of the B->A direction 
>> (since it knows that Ai,Bj works for the A->B direction).
>>
> 
> at this point i wonder if this exploration may not result in 
> amplification attacks?

Perhaps. But any damage can be limited by this being (in addition to 
applying to existing contexts) limited to a few and rate limited tests.

> here is the part that i am concerned, since B would generate 6 packets 
> as reply to one packet, right?

Yep, but they need to be spaced out according to whatever congestion 
control constraints we have in any case.

> I think this test protocol is ok for initial contact, but that we need 
> additional protectio from flooding attacks in the case of a rehoming of 
> an existing context, as i described above. for this, context information 
> is to be included in the exchange

Yes. But to me that is a conceptually different protocol mechanism.

   Erik

Delivery-date: Fri, 13 May 2005 19:28:22 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Fri, 13 May 2005 21:05:25 +0200
To: Erik Nordmark <[email-masked]>

El 13/05/2005, a las 2:24, Erik Nordmark escribi=F3:
>
...
>> Well, i guess that what i am assuming is that a shim enable context=20=

>> will verify that received reachability test packets corresponds to an=20=

>> existent context, i.e. that upon the reception of a reahcability=20
>> test, the node will verify that this corresponds to an exsitent=20
>> context. If it does, it will reply, if not it won't
>> I don't know if you consider that i am assuming something else...=20
>> (please let me know)
>
> The above assumption is what I find problematic.
>> The above assumption is based in that i think this is needed to=20
>> properly protect from flooding attacks.
>
> I'm far from convinced. See below.
>

Ok, i think we are considering different types of attacks:

 =46rom what i understand there are three types of attacks involved =
here:

- DoS attack when establishing a new shim context: this is the case=20
where the attacker plays the role of an initiator and tries to DoS a=20
receiver, through resource consumption, in particular, memory of CPU=20
exhaustion. (this type of attacks is taken into account in reachability=20=

exchange you describe below)

- Flooding attacks (with or without amplification) when  establishing a=20=

new shim context: In this case, the attacker also plays the role of an=20=

initiator and uses the initial reachability test defined for=20
identifying working address pairs for initial contact for flooding a=20
third party. In this case, the situation is that the receiver has no=20
context (or very limited) and the packets involved are only the packets=20=

associated with the reachability test exchange (this type of attack is=20=

also taken into account in the reachability test exchange that you=20
describe below)

- Flooding attacks once the shim context is established: in this case,=20=

an attacker creates a context with a server and starts downloading a=20
heavy flow (i know you know this story, but just to make sure we are=20
sync), then the attackers rehomes the flow towards an alternative=20
address that belongs to the victim, so the victim is flooded. In this=20
case, the server has context state and the packets involved in the=20
flooding are the data flow (not only reachability test packets) Imho,=20
if we are going to use a reachability test exchange to prevent this=20
attack, then the reachability test exchange requires additional=20
information than the one is included in the reachability test exchange=20=

that you describe below. This is because for preventing this attack,=20
the victim needs to know what is the context that is associated with=20
the reachability test that it is replying to, in order to verify that=20
the future incoming flow corresponds to an existent context.

Let me put an example:

Attacker X address IPX
Server S address IPS
Victim V address IPV

Attacker X initiates a communication with Server S and creates a shim=20
context with ULIDs IPX and IPS, and X include IPV as an alternative=20
locator for IPX.

Next, X starts downloading a heavy flow from S
Next, X rehomes to communication to IPV, flooding V

One mechanism to prevent this attack is to use a reachability test,=20
right?

I mean, if we include a reachability test it would look like this, i=20
guess:

Attacker X initiates a communication with Server S and creates a shim=20
context with ULIDs IPX and IPS, and X include IPV as an alternative=20
locator for IPX.

Next, X starts downloading a heavy flow from S
Next, X rehomes to communication to IPV,
However, S before sending packets to IPV performs a reachability test=20
to IPV, in order to verify the the node sitting at IPV is willing to=20
receive packets.
Now the question is which information needs to be included in this=20
reachability test in order to make it useful to prevent the considered=20=

flooding attack?
If no context information is included in the reachability test request=20=

sent by S to IPV, then V is not able if this reachability test request=20=

is associated to one of its own contexts, or a reachability test=20
performed for initial contact or if this is an atempt of flooding=20
attack as described.
This is important, because V should react differently in the different=20=

cases (V should reply to the reachability test request in the first two=20=

cases and not reply in the third case, in order to prevent the attack)

So, i think that we have different situations here:

- reachability test request for exploring address pairs for initial=20
contact do not carry context information (since ther is no context=20
created yet)

- reachability test request for exploring alternative address pairs for=20=

rehoming an established communication require context information in=20
order to prevent flooding attacks

In the second case, i still think that it is reasonable to assume that=20=

a shim enable context will verify that received reachability test=20
packets corresponds to an existent context, i.e. that upon the=20
reception of a reahcability test, the node will verify that this=20
corresponds to an exsitent context. If it does, it will reply, if not=20
it won't

BEsides, i think this is the case to consider when we are dealing with=20=

lost state, since one of the nodes still has the state, so when it=20
sends a reachability test request it will include the context=20
information in the packet.

OTOH, i think that both reachability test exchange will be similar in=20
all the other aspects ( i mean, i don't think that two different=20
reachability tests are required for this two situations, only that in=20
one case it will be required to carry context information and in the=20
other one it won't. However, such context information can be useful to=20=

detect loss of context, i think

>
...
>
>> Ok, but let's first discuss how do we deal with this situation when=20=

>> establishing the initial context, so we can then move to this=20
>> scenario after a context loss event, agree?
>
> I think it is actually more fruitful to try to design a test protocol=20=

> which doesn't assume context state on the peer and that can cope with=20=

> a DoS.

As i mention above, i think we are considering different DOS attacks...

>  I see two avenues to pursue here:
> 1. Limiting the amount of state on the peer (some finite size) but=20
> allow
>    it to be non-zero, since this can be an important performance
>    optimization.
> 2. A test protocol with no state created on the peer.
>
> Here is a rough sketch of such a test protocol.
> Assume that A has n IP addresses (A1,,An) and B has m IP addresses=20
> (B1,,Bm).
>
> To find a working bidirectional locator pair we need to try m*n=20
> combinations. But when the locator pairs can be unidirectional, then=20=

> we need to be able to test the m*n combinations in each direction, for=20=

> a total of (m*n)^2 combinations.
>
> A can do this by explicitly instructing B which source and destination=20=

> locator to use in its response.
> Thus A would send from Ai to Bj asking B to respond from Bk to Al=20
> (letter L).
> This doesn't require any state being created on B, but the search=20
> space is huge (36 combinations if n=3D2, m=3D3 for example).
>
> We can optimize this case when it is ok for B to create state.
> This can always be ok when B knows that the locators are part of some=20=

> existing context.
> But it can also be ok for a small number of tests (basically, B having=20=

> a fixed amount of memory dedicated to this).
> In such a case, B can indicate to A "I have heard you using Ai,Bj"

so far, i agree

> and perhaps also trigger its own exploration of the B->A direction=20
> (since it knows that Ai,Bj works for the A->B direction).
>

at this point i wonder if this exploration may not result in=20
amplification attacks?

> Such an optimization is important. If you take the (unlikely case)=20
> with m=3D3,n=3D2 when only one locator pair works in each direction =
and it=20
> is a different pair for each direction, then with no state on B, A has=20=

> to scan 36 combinations thus on average it is likely to find the only=20=

> working combination after 18 tries.
> But if B can retain state, then A can try all the different=20
> combinations for the forward path. There are only 6. So on average B=20=

> will receive a packet from A after 3.5 tries.

right

> This can then trigger B to try the 6 combinations for the reverse=20
> path, resulting in an average of about 7 tries to find the combination=20=

> of pairs that work.
>

here is the part that i am concerned, since B would generate 6 packets=20=

as reply to one packet, right?

> There is a potential for reflection attacks when A asks B to respond=20=

> to a different locator, but there is no amplification involved here.

no? i mean, B is doing its own exploration to all available locators,=20
right?

>  Also, we can design the protocol so that B's response always includes=20=

> the locators from the request. This means that if X is sending a=20
> packet to B, telling B to respond to IP address A, then A can at least=20=

> tell that it was X that triggered the response.
>
>> i deduce from your statement that you are considering the possibility=20=

>> to perform reachability tests that are not bound to any context, so=20=

>> it can be used for initial contact, right?
>
> Correct.
>

I think this test protocol is ok for initial contact, but that we need=20=

additional protectio from flooding attacks in the case of a rehoming of=20=

an existing context, as i described above. for this, context=20
information is to be included in the exchange

Regards, marcelo

Delivery-date: Fri, 13 May 2005 00:24:43 +0000
Date: Thu, 12 May 2005 17:24:17 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

> I mean, is it possible to create two contexts between the same two nodes 
> with the same two ULIDs (and perhaps a different context tag)? would 
> this make any sense?

It doesn't seem useful to me.

> Well, i guess that what i am assuming is that a shim enable context will 
> verify that received reachability test packets corresponds to an 
> existent context, i.e. that upon the reception of a reahcability test, 
> the node will verify that this corresponds to an exsitent context. If it 
> does, it will reply, if not it won't
> 
> I don't know if you consider that i am assuming something else... 
> (please let me know)

The above assumption is what I find problematic.

> The above assumption is based in that i think this is needed to properly 
> protect from flooding attacks.

I'm far from convinced. See below.

> :-)
> Context state AND path failure AND unidirectional connectivity.... this 
> seems amusing enough

Yep. It's like a car where one can turn left, hit the breaks, while the 
CD player is searching for track 3. All at the same time! Wow! :-)

The easiest way to deal with such complexity is to make sure the 
mechanisms are independent (the CD player doesn't connect to the break 
system etc).

> Ok, but let's first discuss how do we deal with this situation when 
> establishing the initial context, so we can then move to this scenario 
> after a context loss event, agree?

I think it is actually more fruitful to try to design a test protocol 
which doesn't assume context state on the peer and that can cope with a 
DoS. I see two avenues to pursue here:
1. Limiting the amount of state on the peer (some finite size) but allow
    it to be non-zero, since this can be an important performance
    optimization.
2. A test protocol with no state created on the peer.

Here is a rough sketch of such a test protocol.
Assume that A has n IP addresses (A1,,An) and B has m IP addresses (B1,,Bm).

To find a working bidirectional locator pair we need to try m*n 
combinations. But when the locator pairs can be unidirectional, then we 
need to be able to test the m*n combinations in each direction, for a 
total of (m*n)^2 combinations.

A can do this by explicitly instructing B which source and destination 
locator to use in its response.
Thus A would send from Ai to Bj asking B to respond from Bk to Al 
(letter L).
This doesn't require any state being created on B, but the search space 
is huge (36 combinations if n=2, m=3 for example).

We can optimize this case when it is ok for B to create state.
This can always be ok when B knows that the locators are part of some 
existing context.
But it can also be ok for a small number of tests (basically, B having a 
fixed amount of memory dedicated to this).
In such a case, B can indicate to A "I have heard you using Ai,Bj" and 
perhaps also trigger its own exploration of the B->A direction (since it 
knows that Ai,Bj works for the A->B direction).

Such an optimization is important. If you take the (unlikely case) with 
m=3,n=2 when only one locator pair works in each direction and it is a 
different pair for each direction, then with no state on B, A has to 
scan 36 combinations thus on average it is likely to find the only 
working combination after 18 tries.
But if B can retain state, then A can try all the different combinations 
for the forward path. There are only 6. So on average B will receive a 
packet from A after 3.5 tries. This can then trigger B to try the 6 
combinations for the reverse path, resulting in an average of about 7 
tries to find the combination of pairs that work.

There is a potential for reflection attacks when A asks B to respond to 
a different locator, but there is no amplification involved here. Also, 
we can design the protocol so that B's response always includes the 
locators from the request. This means that if X is sending a packet to 
B, telling B to respond to IP address A, then A can at least tell that 
it was X that triggered the response.

> i deduce from your statement that you are considering the possibility to 
> perform reachability tests that are not bound to any context, so it can 
> be used for initial contact, right?

Correct.

> in the flow label case, this is not enough, as you point out below, you 
> also need a shim bit to indicate that this is shim data packet, right?

Yes, you need to know it is a shim packet (just like TCP only operates 
on TCP packets, the shim should only operate on shim packets).

    Erik

Delivery-date: Thu, 12 May 2005 13:31:37 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Thu, 12 May 2005 15:30:56 +0200
To: Erik Nordmark <[email-masked]>

El 11/05/2005, a las 20:15, Erik Nordmark escribi=F3:
>

...

>> I think that the protocol behaviour would be something like this.
>> A communication is established between node A and node B
>> Later on, a shim context is created between those two nodes.
>> The parameters for that context are:
>>   ULIDs: IPA1 and IPB1
>>   Locators: for IPA1 (IPA1,...,IPAn)
>>             for IPB1 (IPB1,...,IPBm)
>
> And a context tag presumably.
>

right

>> Suppose that for some reason node B losses the shim context (and only=20=

>> the shim context, i.e. the application and transport state about=20
>> ongoing communications is preserved)
>> I guess that at this point we have several scenarios to consider:
>> Scenario a): the communication between A and B is still using IPA1=20
>> and IPB1 as locators.
>> This scenario has two subcases:
>> Scenario a.1) The communication is bidirectional and e.g.
>>               TCP is providing ack of the progress of the=20
>> communication
>>               this means that no periodic reachability test
>>               nor any other shim signaling is being exchanged.
>>               In this scenario, a lost of SHIM context would remain
>>               undetected until there is a failure and node A detects=20=

>> it
>>               and tries to explore alternative paths. This is so=20
>> because
>>               data packets will carry ULIDs and will be passed=20
>> successfully
>>               to the upper layers.
>
> If we assume that B (as well as A) will have a heuristic to create=20
> shim6 contexts (e.g. based on having received 50 packets for a locator=20=

> pair), then this heuristic might be trigger and cause B to try to=20
> establish a context with A, at which point in time A will see that it=20=

> already has a context with B.
>

good point, this means that there is a possibility that the lost of=20
context is detected also by receiving a context establishment request=20
packet for an already available context....
i wonder how the receiver of that packets who already has a context=20
associated with the communication would react...

I mean, is it possible to create two contexts between the same two=20
nodes with the same two ULIDs (and perhaps a different context tag)?=20
would this make any sense?

If the answer is no, then i guess that the receiver can detect the=20
situation because it already has a context with the same two ULIDs. At=20=

this point, the receiver can go along with the context establishment=20
exchange in order to help the peer to re-create the lost context.=20
Perhaps there may be some issues with how to assign the context tags,=20
though...

>> Once that there is a failure, then
>>               reachability test packets won't be recognized as=20
>> belonging
>>               to any existent shim context and the problem can be=20
>> detected.
>
> Here you are already assuming that reachability test packets will not=20=

> be recognized, i.e. presupposing a particular interaction between the=20=

> state management and the test protocol.

Well, i guess that what i am assuming is that a shim enable context=20
will verify that received reachability test packets corresponds to an=20
existent context, i.e. that upon the reception of a reahcability test,=20=

the node will verify that this corresponds to an exsitent context. If=20
it does, it will reply, if not it won't

I don't know if you consider that i am assuming something else...=20
(please let me know)

The above assumption is based in that i think this is needed to=20
properly protect from flooding attacks.
I mean, the goal of reachability tests in a shim protocol can be=20
two-folded:
- to explore if a given address pair is working
- to determine if a given host is willing to receive packets at a given=20=

address (i.e. to prevent flooding attacks)

the first goal can be achieved with a kind of ping (enhanced ping in=20
order to determine unidirectional reachability) but it may not require=20=

that the reachability test is associated with a given context. I mean,=20=

the goal here is just to obtain reachability information

The second goal is somehow different, and since what is being queried=20
is the willingness of the node to receive traffic through a certain=20
address, it is needed to inform the node which traffic are we talking=20
about. If the reachability test request packet does not contain any=20
information about the context that is associated, then i thin that it=20
would not fulfill the second goal.
This is so because an attacker could then flood any shim capable node,=20=

since any shim capable node would be able to reply reachability tests=20
packets, no matter if they refer to existent contexts or not. Make=20
sense?

So, this is why i think it makes sense to assume that a reachability=20
test packet needs to contain information about the context that it=20
refers, and that a node that has lost its context state won't recognize=20=

a reachability test packet of the lost context.

>
>> Scenario a.2) The communication is unidirectional
>>               In this case, periodic reachability test need to be
>>               performed in order to verify that the path is still=20
>> working
>>               If the node B losses its shim state, it won't =
recongnize
>>               the reachability test packets, and the lost of context=20=

>> can
>>               be detected
>
> Again, here you are presupposing a particular interaction.

right, same than above

>
>> Scenario b) the communication between A and B is using alternative=20
>> locators.
>> In this case, when node B losses the context, data packets won't be=20=

>> properly delivered in node B, because it won't be properly demuxed.
>> At this point, the reachability test will be performed to verify the=20=

>> locator pair being used
>
> If you are using alternate locators and the working locator pair is=20
> unidirectional, then it seems like you'd need to be able to=20
> re-discover that working unidirectional locator pair, before you can=20=

> re-establish the context state on B.
> Thus if A is sending using IPA1->IPB2 and B was replying using=20
> IPB1->IPA2, and B looses the context state, what do you do?
> Seems like solving this case requires that the test protocol is not=20
> tied in with the state management.
>

:-)
Context state AND path failure AND unidirectional connectivity.... this=20=

seems amusing enough

Ok, but let's first discuss how do we deal with this situation when=20
establishing the initial context, so we can then move to this scenario=20=

after a context loss event, agree?

So, suppose that we have node A with (IPA1,IPA2) and node B with (IPB1=20=

and IPB2)

suppose that only one unidirectional path is available in each=20
direction, let's say for example that

IPA1->IPB1 is working
IPB2->IPA2 is working
and all the rest of paths are not working
(in particular IPB1->IPA1 is not working and IPA2->IPB2 is not working)

So, the question is how the can establish a communication?

Clearly retrying with different address pairs won't work, since they=20
need to use alternative address pairs

The other option would be to try to establish the shim context=20
simultaneously with the beginning of the communication, so that the=20
shim can be used since the beginning. This would allow to use different=20=

address pairs in each direction since the beginning.

The problem here is how we can design a context establishment exchange=20=

that can support this scenario. I mean, in the functional decomposition=20=

draft, the context establishment exchange is a 4 way handshake designed=20=

to avoid DoS attack, in which the receiver does not create any state=20
upon the reception of the first packet. So far this design does not=20
seems to support the considered scenario where there is unidirectional=20=

connectivity.
I guess that it would be possible to include in the first packet, an=20
alternative locator to be used when sending packets back to the=20
initiator.
I mean, consider the scenario described above.
Node A is initiating using IPA1 and IPB1 as locators for the context=20
establishment request packet.
In this packet, i guess it could include an alternative locator for=20
node A, IPA2, so that node B sends the reply to IPA2 (another issue=20
that needs to be considered would be security checks that are needed=20
for this and how much more expensive is the context establishment=20
because of this verification).
The question now is how do we manage that the reply also uses an=20
alternative locator for node B? I mean, if we still want that node B=20
does not stores any state about this context upon the reception of this=20=

first packet, this may be difficult

My point is that i am not sure we can support this type of scenarios=20
for the establishment of the context, so i would propose to analyze=20
this case first and then move on to see if we can deal with the case of=20=

lost state and unidirectional connectivity.

>> I don't know if i am missing something, but AFAICS, all the=20
>> situations when the shim context is lost result in a reachability=20
>> test exchange, and that is why i was wondering if it wouldn't make=20
>> sense to define a "no-context" error message as a rply to a=20
>> reachability test request packet.
>
> That is one particular solution with strong coupling between the test=20=

> protocol and the state management.
>
> But don't we want to retain the possibility to test locator pairs for=20=

> initial contact, i.e. before a context is established between the=20
> peers? And handle the above case of unidirectional locator pairs?

right, i guess we should explore how this would work and see how hard=20
this is...

i deduce from your statement that you are considering the possibility=20
to perform reachability tests that are not bound to any context, so it=20=

can be used for initial contact, right?

I guess that we would need to design two different reachability tests,=20=

one for reachability and one for flood prevention, right?

>
>
>> But i fail to understand how the node that has lost the state can=20
>> identify that a data packet belongs to a non existent shim state....
>
> By seeing that the <source locator, destination locator, context tag>=20=

> doesn't match any existing context?

in the flow label case, this is not enough, as you point out below, you=20=

also need a shim bit to indicate that this is shim data packet, right?

> I suspect we want that capability for robustness in any case.
>
>> I mean, i guess that a first element that is relevant here is where=20=

>> are we going to carry the context tag.
>> If the context tag is carried in a extension header or dest option,=20=

>> then i can see that if a node receives an packet with one of those,=20=

>> can easily detect that there is no context associated. (note that in=20=

>> this case, the context loss is only detected in the case where the=20
>> locators used for the communication differ from the ULIDs, i.e. the=20=

>> extension header dst option is included in the packet)
>> If the context tag is included in the flow label, then i don't see=20
>> how a node that receives the data packet can determine that the=20
>> packet is associated to a shim context that is no longer there. At=20
>> this point, i gues that as you mentioned in a previous mail, the data=20=

>> packet would be silently discarded, right?
>
> If the context tag is carried as a flow label, I still think we need a=20=

> way to tell the receiver "this is a shim6 packet". For robustness=20
> reasons I think the fact that the packet needs shim6 processing should=20=

> be explicit.
> There has been proposals in multi6 which suggested doing this without=20=

> making the packets larger by defining a set of new nexthdr values with=20=

> meaning like
> 	shim6+tcp
> 	shim6+udp
> 	...
> 	shim6+esp
>
> Not having that "shim6" bit when the flow label is used as a context=20=

> tag can easily result in hard to diagnose errors. We might have errors=20=

> due to some middlebox messing with the data packets (a TCP relay for=20=

> instance), but that leaves the shim6 test packets alone. If the TCP=20
> relay doesn't preserve the flow label, then the packets would be=20
> dropped due to TCP checksum errors (since the ULID rewrite didn't=20
> happen), but the test protocol would say that everything is fine.
>

well, i may agree here, but this should be considered when choosing=20
where to carry the context tag. So far, in the discussion, and in the=20
arch draft, there where no shim bit in data packets, and this point was=20=

not considered in the discussion of the trade offs.

In any case, i agree that it seems that the loss of the shim context=20
can be detected when receiving packets other than reachability tests, i=20=

guess that it may also be detected when receiving any shim signaling=20
i.e. data packets with context tag (that are explicitly signaled as=20
context tags) context establishment request packets and reachability=20
test packets.

Regards, marcelo

>> I think that at this point is clear to me that if we define a=20
>> no-context error message, this message should be defined as a reply=20=

>> to a packet that refers to that context and it should include enough=20=

>> information about this initial packet to verify that is a reply to=20
>> that packet.
>> The no-context error message cannot be issued spontaneously by a =
node.
>
> Agreed.
>
>   Erik
>

Delivery-date: Wed, 11 May 2005 18:40:44 +0000
Date: Wed, 11 May 2005 11:40:42 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote:

> The reachability testing protocol needs to have access to the shim  
> state because it may need to discover unidirectional reachability. If  
> we assume A1, A2 and B1, B2 where A1 -> B1 and B2 -> A2 are the only  
> working paths, doing a simple ping or something like it won't find  
> these paths.

We can do that without involving the context as outlined in Jari's 
draft. And we need to do it without the context to handle cases when we 
need to do locator pair testing and the peer doesn't yet have context 
state. (See my response to Marcelo.)

> People may also want to limit reachability testing to known  
> correspondents for security reasons.

We definitely need to be concerned about both state creation DoS, as 
well as using the testing protocol as a reflector.

    Erik

Delivery-date: Wed, 11 May 2005 18:16:00 +0000
Date: Wed, 11 May 2005 11:15:44 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

>> Why would we want to couple the state management aspects of shim6 but 
>> the shim6 test protocol? To me any such coupling seems undesirable, 
>> especially since the parameters for the test protocol (how quickly to 
>> detect failures) might be a function of upper layer advise, as well as 
>> upper layer hints of "working" or "not working".
>>
> 
> Well, i guess that the situation when one of the nodes has lost the shim 
> state can be seen as a form of failure and my assumption is that failure 
> detection mechanisms will likely detect it first

But that's a circular argument for including the context state in the 
failure detection mechanism. You are in effect saying that the test 
protocol should test whether the context has been lost on the peer since 
it can be made to test for a lost context on the peer.

FWIW the outline of a test protocol in section 5.4 of 
draft-arkko-multi6dt-failure-detection-00.txt doesn't assume such a 
thing. (But it does assume that B remember something about previously 
received probes, so there are some issues about DoS opportunities.)

> I think that the protocol behaviour would be something like this.
> 
> A communication is established between node A and node B
> Later on, a shim context is created between those two nodes.
> The parameters for that context are:
>   ULIDs: IPA1 and IPB1
>   Locators: for IPA1 (IPA1,...,IPAn)
>             for IPB1 (IPB1,...,IPBm)

And a context tag presumably.

> Suppose that for some reason node B losses the shim context (and only 
> the shim context, i.e. the application and transport state about ongoing 
> communications is preserved)
> 
> I guess that at this point we have several scenarios to consider:
> 
> Scenario a): the communication between A and B is still using IPA1 and 
> IPB1 as locators.
> This scenario has two subcases:
> Scenario a.1) The communication is bidirectional and e.g.
>               TCP is providing ack of the progress of the communication
>               this means that no periodic reachability test
>               nor any other shim signaling is being exchanged.
>               In this scenario, a lost of SHIM context would remain
>               undetected until there is a failure and node A detects it
>               and tries to explore alternative paths. This is so because
>               data packets will carry ULIDs and will be passed successfully
>               to the upper layers. 

If we assume that B (as well as A) will have a heuristic to create shim6 
contexts (e.g. based on having received 50 packets for a locator pair), 
then this heuristic might be trigger and cause B to try to establish a 
context with A, at which point in time A will see that it already has a 
context with B.

> Once that there is a failure, then
>               reachability test packets won't be recognized as belonging
>               to any existent shim context and the problem can be detected.

Here you are already assuming that reachability test packets will not be 
recognized, i.e. presupposing a particular interaction between the state 
management and the test protocol.

> Scenario a.2) The communication is unidirectional
>               In this case, periodic reachability test need to be
>               performed in order to verify that the path is still working
>               If the node B losses its shim state, it won't recongnize
>               the reachability test packets, and the lost of context can
>               be detected

Again, here you are presupposing a particular interaction.

> Scenario b) the communication between A and B is using alternative 
> locators.
> In this case, when node B losses the context, data packets won't be 
> properly delivered in node B, because it won't be properly demuxed.
> At this point, the reachability test will be performed to verify the 
> locator pair being used

If you are using alternate locators and the working locator pair is 
unidirectional, then it seems like you'd need to be able to re-discover 
that working unidirectional locator pair, before you can re-establish 
the context state on B.
Thus if A is sending using IPA1->IPB2 and B was replying using 
IPB1->IPA2, and B looses the context state, what do you do?
Seems like solving this case requires that the test protocol is not tied 
in with the state management.

> I don't know if i am missing something, but AFAICS, all the situations 
> when the shim context is lost result in a reachability test exchange, 
> and that is why i was wondering if it wouldn't make sense to define a 
> "no-context" error message as a rply to a reachability test request packet.

That is one particular solution with strong coupling between the test 
protocol and the state management.

But don't we want to retain the possibility to test locator pairs for 
initial contact, i.e. before a context is established between the peers? 
And handle the above case of unidirectional locator pairs?

> But i fail to understand how the node that has lost the state can 
> identify that a data packet belongs to a non existent shim state....

By seeing that the <source locator, destination locator, context tag> 
doesn't match any existing context?
I suspect we want that capability for robustness in any case.

> I mean, i guess that a first element that is relevant here is where are 
> we going to carry the context tag.
> If the context tag is carried in a extension header or dest option, then 
> i can see that if a node receives an packet with one of those, can 
> easily detect that there is no context associated. (note that in this 
> case, the context loss is only detected in the case where the locators 
> used for the communication differ from the ULIDs, i.e. the extension 
> header dst option is included in the packet)
> 
> If the context tag is included in the flow label, then i don't see how a 
> node that receives the data packet can determine that the packet is 
> associated to a shim context that is no longer there. At this point, i 
> gues that as you mentioned in a previous mail, the data packet would be 
> silently discarded, right?

If the context tag is carried as a flow label, I still think we need a 
way to tell the receiver "this is a shim6 packet". For robustness 
reasons I think the fact that the packet needs shim6 processing should 
be explicit.
There has been proposals in multi6 which suggested doing this without 
making the packets larger by defining a set of new nexthdr values with 
meaning like
	shim6+tcp
	shim6+udp
	...
	shim6+esp

Not having that "shim6" bit when the flow label is used as a context tag 
can easily result in hard to diagnose errors. We might have errors due 
to some middlebox messing with the data packets (a TCP relay for 
instance), but that leaves the shim6 test packets alone. If the TCP 
relay doesn't preserve the flow label, then the packets would be dropped 
due to TCP checksum errors (since the ULID rewrite didn't happen), but 
the test protocol would say that everything is fine.

> I think that at this point is clear to me that if we define a no-context 
> error message, this message should be defined as a reply to a packet 
> that refers to that context and it should include enough information 
> about this initial packet to verify that is a reply to that packet.
> 
> The no-context error message cannot be issued spontaneously by a node.

Agreed.

   Erik

Delivery-date: Wed, 11 May 2005 13:57:34 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Wed, 11 May 2005 15:57:10 +0200
To: Erik Nordmark <[email-masked]>

El 10/05/2005, a las 23:38, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>>> But you need to given all the addresses to the host so that there=20
>>> are redundant addresses available for it during initial=20
>>> communication, don't you?
> >
>> yes, unless you are sure that you are communicating with a shim=20
>> enabled peer (the peer or a middlebox in front of it) in which case=20=

>> you could use shim capabilities even for dealing with outages in the=20=

>> locator used for initial contact
>
> How would the DHCP server, when handing out address, know whether or=20=

> not the local host will communicate with a shim capable peer?
> The local host might communicate both with shim incapable peers and=20
> with shim capable peers. In the first case it makes sense for the host=20=

> to know all its addresses with the hope that default address selection=20=

> and application retries finds a working address pair.

so far, so good

> In the second case the middlebox can help so it makes more sense (does=20=

> it?) to only give the host one address, which is part of a HBA/CGA set=20=

> maintained by the middlebox.
>

sorry, i have lost a bit of track here....

what was the problem with handing back to the non-shim capable host all=20=

the addresses of the HBA set?

I mean, the dhcp server gives all the addresses of the HBA set to the=20
host, and the host can use any of them to establish a communication.=20
The middle box will establish shim context for each different=20
communication that uses different src dst iids

regards, marcelo

Delivery-date: Wed, 11 May 2005 11:04:11 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Wed, 11 May 2005 13:03:27 +0200
To: Erik Nordmark <[email-masked]>

On 10-mei-2005, at 23:28, Erik Nordmark wrote:

> Why would we want to couple the state management aspects of shim6  
> but the shim6 test protocol? To me any such coupling seems  
> undesirable, especially since the parameters for the test protocol  
> (how quickly to detect failures) might be a function of upper layer  
> advise, as well as upper layer hints of "working" or "not working".

The reachability testing protocol needs to have access to the shim  
state because it may need to discover unidirectional reachability. If  
we assume A1, A2 and B1, B2 where A1 -> B1 and B2 -> A2 are the only  
working paths, doing a simple ping or something like it won't find  
these paths.

People may also want to limit reachability testing to known  
correspondents for security reasons.

Delivery-date: Wed, 11 May 2005 10:03:49 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Wed, 11 May 2005 12:03:17 +0200
To: Erik Nordmark <[email-masked]>

El 10/05/2005, a las 23:28, Erik Nordmark escribi=F3:

>> I mean, in this case, probably the reachability test will be=20
>> performed, because an outage will be detected, and if no reply is=20
>> received, the the path exploration process will begin, sending=20
>> packets with alternative locators, right?
>> I mean, failure detection timers should be much shorter than session=20=

>> lifetime timers, right?
>
> Why would we want to couple the state management aspects of shim6 but=20=

> the shim6 test protocol? To me any such coupling seems undesirable,=20
> especially since the parameters for the test protocol (how quickly to=20=

> detect failures) might be a function of upper layer advise, as well as=20=

> upper layer hints of "working" or "not working".
>

Well, i guess that the situation when one of the nodes has lost the=20
shim state can be seen as a form of failure and my assumption is that=20
failure detection mechanisms will likely detect it first

I think that the protocol behaviour would be something like this.

A communication is established between node A and node B
Later on, a shim context is created between those two nodes.
The parameters for that context are:
   ULIDs: IPA1 and IPB1
   Locators: for IPA1 (IPA1,...,IPAn)
             for IPB1 (IPB1,...,IPBm)

Suppose that for some reason node B losses the shim context (and only=20
the shim context, i.e. the application and transport state about=20
ongoing communications is preserved)

I guess that at this point we have several scenarios to consider:

Scenario a): the communication between A and B is still using IPA1 and=20=

IPB1 as locators.
This scenario has two subcases:
Scenario a.1) The communication is bidirectional and e.g.
               TCP is providing ack of the progress of the communication
               this means that no periodic reachability test
               nor any other shim signaling is being exchanged.
               In this scenario, a lost of SHIM context would remain
               undetected until there is a failure and node A detects it
               and tries to explore alternative paths. This is so =
because
               data packets will carry ULIDs and will be passed=20
successfully
               to the upper layers. Once that there is a failure, then
               reachability test packets won't be recognized as =
belonging
               to any existent shim context and the problem can be=20
detected.

Scenario a.2) The communication is unidirectional
               In this case, periodic reachability test need to be
               performed in order to verify that the path is still=20
working
               If the node B losses its shim state, it won't recongnize
               the reachability test packets, and the lost of context =
can
               be detected

Scenario b) the communication between A and B is using alternative=20
locators.
In this case, when node B losses the context, data packets won't be=20
properly delivered in node B, because it won't be properly demuxed.
At this point, the reachability test will be performed to verify the=20
locator pair being used

I don't know if i am missing something, but AFAICS, all the situations=20=

when the shim context is lost result in a reachability test exchange,=20
and that is why i was wondering if it wouldn't make sense to define a=20
"no-context" error message as a rply to a reachability test request=20
packet.

>
>> again i think that this is very much related with the failure=20
>> detection mechanism... i mean, in this case, the node that still has=20=

>> the state (both for the shim and for TCP) will detect an outage and=20=

>> perform the reachability test process and eventually the path=20
>> exploration process...
> >
>> I am wondering if all these issues could be addressed by defining an=20=

>> error message as a possible response for the reachability test=20
>> request message, if you see what i mean.
>
> Even if we decide to couple the state management with the test=20
> protocol there would still be an issue. The test protocol is there to=20=

> discover a working locator pair. Just because a locator pair is=20
> working doesn't mean that the peer has any context state for any=20
> particular shim6 context.
>

agree, but as i describe above, i think that the situation where=20
context is lost will result in a reachability test.

imho, this is so, because the failure detection mechanisms will react=20
fast.

> Thus you'd need a "context alive" probe in addition to the locator=20
> pair test message.
>

I don't think so... imho, if when a node receives a reachability test=20
request packets for a context that it does not have any state, the node=20=

can reply with a no-context error, would be enough. imho i cannot see=20
the need for a periodic context alive probe protocol (yet)

> I think we can come of with way to do state management which doesn't=20=

> require such added complexity.
>
>> I think that the problems with potential attacks using an error=20
>> message to cause nodes involved in a shim communication to discard=20
>> their state could be avoided by defining an error message that cannot=20=

>> be sent spontaneously by one of the hosts (or an attacker) but that=20=

>> need to be sent as a reply of a reachability test request message=20
>> (including some random seq number or similar)
>
> Or sent in response to a data packet, but including enough of the data=20=

> packet (the locator pair and context tag) that are hard for an=20
> off-path attacker to guess.
>

But i fail to understand how the node that has lost the state can=20
identify that a data packet belongs to a non existent shim state....

I mean, i guess that a first element that is relevant here is where are=20=

we going to carry the context tag.
If the context tag is carried in a extension header or dest option,=20
then i can see that if a node receives an packet with one of those, can=20=

easily detect that there is no context associated. (note that in this=20
case, the context loss is only detected in the case where the locators=20=

used for the communication differ from the ULIDs, i.e. the extension=20
header dst option is included in the packet)

If the context tag is included in the flow label, then i don't see how=20=

a node that receives the data packet can determine that the packet is=20
associated to a shim context that is no longer there. At this point, i=20=

gues that as you mentioned in a previous mail, the data packet would be=20=

silently discarded, right?

>
>> i am not sure what do you have in mind when stating that the error=20
>> message could only be generated by a mitm (considering that one of=20
>> the nodes has lost its state, so no previous cookie is available) but=20=

>> i think that the defining an error message that can only be issued as=20=

>> a reply of a previous packet could do the trick
>
> I meant sent in response to a packet, so that only an attacker on the=20=

> path can construct a forged error message, as above.
>

I think that at this point is clear to me that if we define a=20
no-context error message, this message should be defined as a reply to=20=

a packet that refers to that context and it should include enough=20
information about this initial packet to verify that is a reply to that=20=

packet.

The no-context error message cannot be issued spontaneously by a node.

Regards, marcelo

>    Erik
>

Delivery-date: Tue, 10 May 2005 21:38:30 +0000
Date: Tue, 10 May 2005 14:38:25 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]

marcelo bagnulo braun wrote:

>> But you need to given all the addresses to the host so that there are 
>> redundant addresses available for it during initial communication, 
>> don't you?
 >
> yes, unless you are sure that you are communicating with a shim enabled 
> peer (the peer or a middlebox in front of it) in which case you could 
> use shim capabilities even for dealing with outages in the locator used 
> for initial contact

How would the DHCP server, when handing out address, know whether or not 
the local host will communicate with a shim capable peer?
The local host might communicate both with shim incapable peers and with 
shim capable peers. In the first case it makes sense for the host to 
know all its addresses with the hope that default address selection and 
application retries finds a working address pair. In the second case the 
middlebox can help so it makes more sense (does it?) to only give the 
host one address, which is part of a HBA/CGA set maintained by the 
middlebox.

>> If the DHCP server only hands back one address to the host, what would 
>> happen when a shim6 capable host is used? It would want all the 
>> addresses/prefixes so it could do shim6 on its own.
> 
> 
> i guess that the DHCP server should know if the requesting host is shim 
> capable or not

This is at least solvable, with a new DHCPv6 option saying "I'm shim6 
capable - disable any shim6 middlebox stuff".

> imho middleboxes don't really fit nicely in the shim arch. I mean shim 
> arch is e2e by design, not suited for middle boxes i guess.

Well, TCP is e2e yet there are plenty of transparent TCP proxies which 
work most of the time. (They are a single point of failure for a 
connection etc, but they don't seem to run into the same type of issues 
we see for a shim6 middlebox.) Perhaps the added complexity of both 
overloading the IP addresses to function as ULIDs and locators, combined 
with handling failures during initial communication in the 
application/ULP, and failure of existing communication in the shim, is 
what makes this so hard.

> any middlebox support will be some form of hack imho

Agreed. Question is it would be a useful hack, or just asking for trouble.

    Erik

Delivery-date: Tue, 10 May 2005 21:28:27 +0000
Date: Tue, 10 May 2005 14:28:15 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

> FWIW i am not proposing not even defending this approach, just trying to 
> explore how this would look like...

ok
Makes sense trying to understand the issues and tradeoffs.

>> Such an approach isn't robust in the presence of packet loss.
>> A could be sending a few packets, but B might never receive them due 
>> to random packet loss. So you end up with B discarding the state while 
>> A thinks B should still have the state, since A sent packets to B.
> 
> 
> I am not sure about that...
> 
> I mean, in this case, probably the reachability test will be performed, 
> because an outage will be detected, and if no reply is received, the the 
> path exploration process will begin, sending packets with alternative 
> locators, right?
> 
> I mean, failure detection timers should be much shorter than session 
> lifetime timers, right?

Why would we want to couple the state management aspects of shim6 but 
the shim6 test protocol? To me any such coupling seems undesirable, 
especially since the parameters for the test protocol (how quickly to 
detect failures) might be a function of upper layer advise, as well as 
upper layer hints of "working" or "not working".

> again i think that this is very much related with the failure detection 
> mechanism... i mean, in this case, the node that still has the state 
> (both for the shim and for TCP) will detect an outage and perform the 
> reachability test process and eventually the path exploration process...
 >
> I am wondering if all these issues could be addressed by defining an 
> error message as a possible response for the reachability test request 
> message, if you see what i mean.

Even if we decide to couple the state management with the test protocol 
there would still be an issue. The test protocol is there to discover a 
working locator pair. Just because a locator pair is working doesn't 
mean that the peer has any context state for any particular shim6 context.

Thus you'd need a "context alive" probe in addition to the locator pair 
test message.

I think we can come of with way to do state management which doesn't 
require such added complexity.

> I think that the problems with potential attacks using an error message 
> to cause nodes involved in a shim communication to discard their state 
> could be avoided by defining an error message that cannot be sent 
> spontaneously by one of the hosts (or an attacker) but that need to be 
> sent as a reply of a reachability test request message (including some 
> random seq number or similar)

Or sent in response to a data packet, but including enough of the data 
packet (the locator pair and context tag) that are hard for an off-path 
attacker to guess.

> i am not sure what do you have in mind when stating that the error 
> message could only be generated by a mitm (considering that one of the 
> nodes has lost its state, so no previous cookie is available) but i 
> think that the defining an error message that can only be issued as a 
> reply of a previous packet could do the trick

I meant sent in response to a packet, so that only an attacker on the 
path can construct a forged error message, as above.

    Erik

Delivery-date: Tue, 10 May 2005 15:36:05 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Tue, 10 May 2005 17:35:55 +0200
To: [email-masked]

...
>> fully agree, so this is not a problem, right?
>> i mean, before accepting packets from a given locator, this locator 
>> has to be be contained in the locator set and properly verified. 
>> through this verification process, it is possible to guarantee that 
>> the context tag associated to this locator is good for uniquely 
>> identify the associated shim context...
>> I mean, i don't see a problem which is specific to the context tag 
>> assignment mechanism....
>
> I agree.
>
> So sender or receiver allocation becomes purely a choice about
> whether to match on <source,tag> (receiver) or <source,dest,tag>
> (sender).

> Does the signalling have to say which destination locators a
> host will communicate to in the receiver case?
>

I guess that when a new ddestiantion locator is added in the context, 
if we are using sender based allocation, the sender may need to use a 
different tag for that destination, right?
in this case, when a dst locator is added, the sender may inform the 
receiver that a different tag will be used for that dst and the 
avaialbel source addresses.

> [chop]
>>>
>>>
>>> Well, perhaps it doesn't matter in the general "I haven't seen the
>>> address
>>> but I know the label", but for a previously known valid 
>>> <src,dest,label>
>>> mapping, you shouldn't need to signal that the packets are about to
>>> arrive like MIPv6 does now.
>>>
>> agree.
>> What is needed is a signalling mechanism to add locators to the 
>> locator set and properly verify it (at this point a valid context tag 
>> can be assoicated by the receiver, as you suggested)
>> Once that the locator is included in the locator set and verified, it 
>> can be used without prior signalling to announce its usage in the 
>> data packets
>
> Subsequent signaling (not on the critical path) may be able to be used
> to verify path reachability, in an analogous manner to STALE neighbour
> cache entries, if no upper layer confirmation is available.
>

right, but this is for fault tolerance rather than security right? so i 
guess that these checks will depend on local policy (i mean there may 
be a lot of potential src dst pairs to keep track of all of them)

regards, marcelo

> There should be some experiences available from IKE DPD which apply
> (if there is no use of IKE itself).
>
> Greg
>

Delivery-date: Tue, 10 May 2005 14:34:52 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Tue, 10 May 2005 16:34:44 +0200
To: Erik Nordmark <[email-masked]>

El 09/05/2005, a las 19:54, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> well, i guess that addresses could be delivered through dhcp also.
>> I mean, the middle box delivers the HBA/CGA through dhcp to the hosts=20=

>> and performs proxy funtions for this hosts, since it knows the=20
>> associated paramenters
>
> So the DHCP server would need to be part of the middlebox, and hand=20
> back the ULID to the host, while maintaining the complete HBA/CGA set.
>
> But you need to given all the addresses to the host so that there are=20=

> redundant addresses available for it during initial communication,=20
> don't you?
>

yes, unless you are sure that you are communicating with a shim enabled=20=

peer (the peer or a middlebox in front of it) in which case you could=20
use shim capabilities even for dealing with outages in the locator used=20=

for initial contact

> If the DHCP server only hands back one address to the host, what would=20=

> happen when a shim6 capable host is used? It would want all the=20
> addresses/prefixes so it could do shim6 on its own.

i guess that the DHCP server should know if the requesting host is shim=20=

capable or not

>
> Seems tricky to do this.
>

yes

imho middleboxes don't really fit nicely in the shim arch. I mean shim=20=

arch is e2e by design, not suited for middle boxes i guess.

any middlebox support will be some form of hack imho

I mean, if the middle box is the one that establishes the shim context,=20=

then i guess we can only have one middle box, right? what happens if an=20=

alternative path is used and another middle box routes the packets? i=20
guess that there will be issues because the middle box don't have a=20
state created for the context. So, or we associate one and only one=20
middle box for node (in which case there is faye sharing between the=20
host and middle box, i.e. reduced fault tolerance) or we create a inter=20=

middle box synchronization protocol (which seems at least complex)

So, i guess that we could support middle boxes, but with limited=20
capabilites and some additional effort

Regards, marcelo

>    Erik
>

Delivery-date: Tue, 10 May 2005 14:22:28 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers
Date: Tue, 10 May 2005 16:22:08 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

FWIW i am not proposing not even defending this approach, just trying=20
to explore how this would look like...

El 09/05/2005, a las 19:37, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>
>> But, the state can be rebuild using the initial exchange again, =
right?
>
> How will A know in a timely manner that B has lost state, if B never=20=

> responds?
>
>> I mean, i am thinking in the following scenario (that i think Brian=20=

>> suggested some time ago)
>> Node A and Node B start a communication using IPA1 and IPA2=20
>> respectively,
>> A while after, they decide to create a SHIM context, for this=20
>> communication. For that, the perform the initial exchange and the=20
>> continue the communication for a while.
>> At this points i can think about 3 scenarios:
>> 1- the "normal" situation i.e. there no abrupt lost of context for=20
>> external reasons. In this case, each packet received corresponding to=20=

>> that context would extend the lifetime of the context information. If=20=

>> no packets are exchanged for a given period T, then both ends discard=20=

>> the state. I guess T should defined in a conservative way, i.e. long=20=

>> enough.
>
> Such an approach isn't robust in the presence of packet loss.
> A could be sending a few packets, but B might never receive them due=20=

> to random packet loss. So you end up with B discarding the state while=20=

> A thinks B should still have the state, since A sent packets to B.

I am not sure about that...

I mean, in this case, probably the reachability test will be performed,=20=

because an outage will be detected, and if no reply is received, the=20
the path exploration process will begin, sending packets with=20
alternative locators, right?

I mean, failure detection timers should be much shorter than session=20
lifetime timers, right?

My concern now, as i think you suggest below, is that before trying to=20=

reestablish the context (if no no-context-available error message is=20
defined), all alternative paths need to be explored, which is at least=20=

a time consuming task, which will delay the reestablsihemnt process for=20=

a probably unacceptable period.

>
> FWIW the CLOSE exchange in draft-ietf-hip-base-02.txt avoids this=20
> problem by basing the "should I time this out" on the receipt of=20
> packets, and not due to packets being sent.

I guess this heavily depends on the failure detection mechanism... =46rom=20=

previous discussions on this, i think that the one that would detect=20
the outage and perform a reachability test will be the node that has=20
packets to send...

> I think you'd need a similar approach in a semi-hard-state approach to=20=

> shim6.
>
>> 2- One of the nodes reboots and all state is lost. In this case, it=20=

>> doesn't make much sense to rebuild the context, i think, because the=20=

>> upper layer state has also been lost, so i guess it doesn't make much=20=

>> sense to try to resume the SHIM context when there is no upper layer=20=

>> that wants to preserve a communication
>
> The problem if you do nothing, is that the upper layer would not find=20=

> out in a timely manner. For instance, TCP would not receive a reset=20
> packet when the peer has rebooted, because the shim layer would pass=20=

> up a TCP packet with a bad checksum (due to not having replaced the=20
> locators with the ULIDs).
>
> So if you do nothing you are most likely making the notification of a=20=

> upper layer state loss a lot worse than it is without shim6.
>

right

again i think that this is very much related with the failure detection=20=

mechanism... i mean, in this case, the node that still has the state=20
(both for the shim and for TCP) will detect an outage and perform the=20
reachability test process and eventually the path exploration=20
process...

I am wondering if all these issues could be addressed by defining an=20
error message as a possible response for the reachability test request=20=

message, if you see what i mean.

I think that the problems with potential attacks using an error message=20=

to cause nodes involved in a shim communication to discard their state=20=

could be avoided by defining an error message that cannot be sent=20
spontaneously by one of the hosts (or an attacker) but that need to be=20=

sent as a reply of a reachability test request message (including some=20=

random seq number or similar)

>> 3- There is some abrupt lost of context state in one of the nodes=20
>> (and only the context state. (i am not sure how likely this is, i=20
>> mean i guess it could happen when because of the soft state, one of=20=

>> the nodes discards the state before its peer, and after that the peer=20=

>> wants to resume the communication associated with this context. I=20
>> guess the occurrence of such situation becomes less likely, as the=20
>> inactive time required to discard the context grows). In any case,=20
>> suppose that suddenly node A losses its state about the SHIM context.=20=

>> At this point, node B would detect that the context has been lost.=20
>> How this is detected, is to be analyzed in depth.
>>    - If the communication was still using the ULIDs as locators,
>>      then data packets will flow without problems and no problem
>>      is detected. I guess that for this case, a SHIM keepalive
>>      may be needed to detect this case
>>    - If the communication is using locators that differ from ULIDs
>>      then, i guess that upper layers will send an error message
>>      back, like port unreachable or similar, so that the context
>>      loss can be detected
>
> NO, NO, NO.
> The upper layer packets will be silently discarded with a checksum=20
> error.

right

>
>>    - If SHIM signaling packets are sent by node B, the absence
>>      of replies would indicate that an the context has been lost
>> At this point, when node B detects that the context state has been=20
>> lost, node B can try to perform the initial exchange again, using the=20=

>> same information that was used during the initial exchange the first=20=

>> time. I think this would permit node A to rebuild the lost state
>> I think this soft state could work without requiring the error=20
>> message.
>
> And I think it is at least very hard. The protocol would be more=20
> robust with an error message.
>
> And since we are not trying to build a security protocol - we just=20
> don't want to make things less secure than they are today - an error=20=

> message which will only be believed when generated by an on-path node,=20=

> should be ok even if it makes the peers re-establish the shim6 state.
>

i am not sure what do you have in mind when stating that the error=20
message could only be generated by a mitm (considering that one of the=20=

nodes has lost its state, so no previous cookie is available) but i=20
think that the defining an error message that can only be issued as a=20
reply of a previous packet could do the trick

Regards, marcelo

>> But in any case, note that through error message spoofing the=20
>> attacker may manage to impose that the context is re initiated while=20=

>> the communication still flows (in the case that the ULIDs are still=20=

>> being used as locators) That would allow an attacker that has a=20
>> compatible CGA parameter data structure for instance to place himself=20=

>> in the middle of an ongoing communication.
>
> But getting a compatible CGA structure is hard.
>
>    Erik
>

Delivery-date: Tue, 10 May 2005 00:24:23 +0000
Date: Tue, 10 May 2005 10:22:43 +1000
From: Greg Daley <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers
To: Erik Nordmark <[email-masked]>
Cc: shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> In some circumstances, there may be a port unreachable response before
>> the checksum is even consulted (UDP-Lite).
> 
> 
> If that's the case it sounds like a bug in UDP-Lite. UDP-lite can verify 
> the checksum (which only covers part of the payload unlike UDP), before 
> it generates the ICMP error.
> 

Sorry about that: rfc3828:

"The UDP-Lite header MUST always be covered by the checksum."

I was importing bad IPv4 knowledge without checking carefully.

>> I believe that there's a chance of additional responding port
>> unreachables or resets for flows which match but do not have upper layer
>> sessions for the flow (since it is tied to different IP addresses).
> 
> 
> There is a small probability, but not qualitatively different than for 
> IPv6 itself. For this to happen the bit error would have to be such that 
> the resulting packet is ok according to the TCP/UDP/ICMP checksum.
> 
> When this low probability even happens in IPv4 or IPv6 today, the result 
> is quite unpredictable. Could cause undetected data corruption in the 
> application payload.
 >
> I don't think the indirection via the shim (which would change the 
> locators to ULIDs for the incorrectly matched context) changes much in 
> terms of the probability.

Agreed.

[cut]
> 
> 
> But we also get loss of state when B has rebooted, and lost all state.
> In this case B would be unable to deliver any higher-level error (TCP 
> reset, UDP port unreachable) until it either has reacquired the shim 
> state, or convinced A to send using the ULIDs as locators (so no receive 
> side address field replacement is necessary).

This is likely to be one of the big issues.

There may be varying degrees of state loss.  One of the hosts
may lose one of its ULIDs, which could make session reestablishment
tricky (trying to bind to an identity which doesn't exist).

This is clearly an error condition, but sending responses from an
address in the destination locator should be able to show that this
is a legitimate response.

For example, if a CGA or HBA locator exists while an identity has been
lost, then packet reception can be validated using the already known
parameters for this HBA on the notified receiver, so that it can
distinguish errors from DoS.

Otherwise, more expensive timeout operations may need to occur,
before other state is removed, or procedures retried.
This is what would happen if the host lost its CGA/HBA locators too
(and didn't receive the packet).

Greg

Delivery-date: Tue, 10 May 2005 00:20:30 +0000
Date: Tue, 10 May 2005 10:13:21 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: marcelo bagnulo braun <[email-masked]>
Cc: shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Marcelo,

marcelo bagnulo braun wrote:
[cut]
>> If the upper layer on the data plane is only AH or authenticated ESP,
>> there's no need to be particularly careful about the matching and
>> whether
>> the source and destination addresses are in the locator set, since
>> the authentication mechanism will take care of it.
>>
> 
> ok, so you are considering a scenario that depending on what the next 
> header, the demux operation is performed based on different context 
> tags, i.e. if there IPSec is done based on the SPI, if no IPSec use the 
> flow label, for example?
>
> My only concern about this multi-context tag situation is the added 
> complexity, especially considering that we need a general purpose 
> mechanism to deal with the general case, where the next header is no 
> useful for us

Yes, I guess there should only be one specification (and simple).
As mentioned, pre-signalling works OK no matter what the allocation
scheme is used.

[cut]
>>
>> As a slightly comical solution: we could use AH (or a trusty
>> authenticated ESP)
>> as our already defined extension header.  SPI's are already sender
>> assigned,
>> and are even bigger than flow labels.
>>
> 
> in the data packets, you mean?
> 
> but wouldn't this imply that all data packets need to be protected with 
> ESP or AH, imposing crypto for all data packets?

Oh yes.  I said it may be comical.

It's not really crypto anyway, it's an HMAC.
I don't think we need to worry too much about
the burdens of using HMACs.

It lies within the realm of possibile, although not
necessarily desirable, solutions.

[cut]
> 
>> So it may be possible for someone to quickly shift to a valid source
>> and destination pair without explicitly signalling at that instant.
>>
>> essentially, the signalling could say: all these are valid locators,
>> please be ready for these packets.
>>
> 
> fully agree, so this is not a problem, right?
> 
> i mean, before accepting packets from a given locator, this locator has 
> to be be contained in the locator set and properly verified. through 
> this verification process, it is possible to guarantee that the context 
> tag associated to this locator is good for uniquely identify the 
> associated shim context...
> 
> I mean, i don't see a problem which is specific to the context tag 
> assignment mechanism....

I agree.

So sender or receiver allocation becomes purely a choice about
whether to match on <source,tag> (receiver) or <source,dest,tag>
(sender).

Does the signalling have to say which destination locators a
host will communicate to in the receiver case?

[chop]
>>
>>
>> Well, perhaps it doesn't matter in the general "I haven't seen the
>> address
>> but I know the label", but for a previously known valid <src,dest,label>
>> mapping, you shouldn't need to signal that the packets are about to
>> arrive like MIPv6 does now.
>>
> 
> agree.
> 
> What is needed is a signalling mechanism to add locators to the locator 
> set and properly verify it (at this point a valid context tag can be 
> assoicated by the receiver, as you suggested)
> Once that the locator is included in the locator set and verified, it 
> can be used without prior signalling to announce its usage in the data 
> packets

Subsequent signaling (not on the critical path) may be able to be used
to verify path reachability, in an analogous manner to STALE neighbour
cache entries, if no upper layer confirmation is available.

There should be some experiences available from IKE DPD which apply
(if there is no use of IKE itself).

Greg

Delivery-date: Mon, 09 May 2005 20:39:40 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Mon, 9 May 2005 22:39:32 +0200
To: Erik Nordmark <[email-masked]>

On 9-mei-2005, at 19:56, Erik Nordmark wrote:

> Unless Marcelo's DHCP suggestion works, I don't see how a middlebox  
> could ensure that the address fields get restored.

> To restore the fields the unmodified host needs to use a ULID which  
> is part of the HBA/CGA set that the middlebox is holding on behalf  
> of the host.

 From a protocol standpoint this may be a problem, but don't forget  
that for the other 99.99% of the world there is a BIG difference  
between the things you can do in a simple perl script and the things  
you can only do when you have the kernel source.

In other words: if people want this bad enough, they'll configure  
hosts manually if need be, or use a non-standard mechanism such as a  
script for this. This isn't a show stopper.

Delivery-date: Mon, 09 May 2005 20:36:02 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Mon, 9 May 2005 22:35:52 +0200
To: Erik Nordmark <[email-masked]>

On 9-mei-2005, at 19:45, Erik Nordmark wrote:

>> Simply going for the option means adding bytes to all packets   
>> forever.

> Nobody has argued that there would be extra bytes in very packet.

> We only need to carry the demux information to the peer when the  
> locator pair is different than the ULID pair.

I know, and I didn't mean "all" packets, but rather all packets that  
are actively shimmed. Currently that may not look likethat would be  
too many, but if we want to rehome using the shim for traffic  
engineering purposes, or use unreachable ULIDs, this could be a lot.

So a moderate investment in future optimization is prudent, IMO.

Delivery-date: Mon, 09 May 2005 20:33:26 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Mon, 9 May 2005 22:33:08 +0200
To: Christian Huitema <[email-masked]>

On 9-mei-2005, at 18:51, Christian Huitema wrote:

>> Wouldn't IPsec be just another higher layer protocol to the shim?

> Actually, I would like an option to run the shim inside IPSEC. It
> prevents meddling by intermediate boxes.

Well, wouldn't the shim seem like just another higher layer protocol  
to IPsec?

There shouldn't be any problems with either running IPsec on top of  
the shim or the shim on top of IPsec (IPsec on top of the shim on top  
of IPsec), as long as both ends agree on the layering. One type of  
layering should probably be the default and the other can then only  
be negotiated if both IPsecs are shim-aware.

Delivery-date: Mon, 09 May 2005 18:02:46 +0000
Date: Mon, 09 May 2005 11:02:42 -0700
From: Erik Nordmark <[email-masked]>
To: Christian Huitema <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter <[email-masked]>, shim6 <[email-masked]>
Subject: shim and IPsec placement [Was: Middleboxes]

Christian Huitema wrote:

> Actually, I would like an option to run the shim inside IPSEC. It
> prevents meddling by intermediate boxes. It also mitigates the privacy
> risks associated with shim6. 

Isn't that what the MOBIKE WG is effectively trying to do?
An implication of layering multihoming support above IPsec is that 
IKE/IPsec needs to get involved to either create new SAs when locators 
change, or have a way to "rehome" existing SAs to use different locators.

FWIW The approach put forth by the multi6 DT was to run the shim below 
IPsec. The shim6 WG could of course decide to do something different, 
but there is no outline on the table for a scheme which runs above 
IPsec. Is anybody working on such a scheme? (other than mobike?)

    Erik

Delivery-date: Mon, 09 May 2005 17:56:40 +0000
Date: Mon, 09 May 2005 10:56:40 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]

Iljitsch van Beijnum wrote:
> On 9-mei-2005, at 14:44, Brian E Carpenter wrote:
> 
>>> So unless having potential middlebox implementation compatibility  
>>> is  a great hardship we shouldn't break it.
> 
> 
>> But I think it will be a great hardship, simply because of IPSEC.
> 
> 
> Wouldn't IPsec be just another higher layer protocol to the shim?
> 
> Since the address fields are restored to their original state, even  AH 
> should work.

Unless Marcelo's DHCP suggestion works, I don't see how a middlebox 
could ensure that the address fields get restored.

To restore the fields the unmodified host needs to use a ULID which is 
part of the HBA/CGA set that the middlebox is holding on behalf of the host.

So unless we come up with how a middlebox and DHCP can conspire to make 
the ULID be restored for the important cases, then the best thing a 
middlebox shim6 implementation can do is 1-1 IPv6 NAT. No need to touch 
the transport protocols/port numbers, but the IP address rewrite would 
mess up at least AH and ESP transport mode, and have other NAT implications.

    Erik

Delivery-date: Mon, 09 May 2005 17:54:19 +0000
Date: Mon, 09 May 2005 10:54:12 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]

marcelo bagnulo braun wrote:

> well, i guess that addresses could be delivered through dhcp also.
> I mean, the middle box delivers the HBA/CGA through dhcp to the hosts 
> and performs proxy funtions for this hosts, since it knows the 
> associated paramenters

So the DHCP server would need to be part of the middlebox, and hand back 
the ULID to the host, while maintaining the complete HBA/CGA set.

But you need to given all the addresses to the host so that there are 
redundant addresses available for it during initial communication, don't 
you?

If the DHCP server only hands back one address to the host, what would 
happen when a shim6 capable host is used? It would want all the 
addresses/prefixes so it could do shim6 on its own.

Seems tricky to do this.

    Erik

Delivery-date: Mon, 09 May 2005 17:45:14 +0000
Date: Mon, 09 May 2005 10:45:12 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Iljitsch van Beijnum wrote:

> Simply going for the option means adding bytes to all packets  forever. 

Nobody has argued that there would be extra bytes in very packet.

We only need to carry the demux information to the peer when the locator 
pair is different than the ULID pair.

    Erik

Delivery-date: Mon, 09 May 2005 17:37:14 +0000
Date: Mon, 09 May 2005 10:37:04 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: soft state (was Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:
> 

> But, the state can be rebuild using the initial exchange again, right?

How will A know in a timely manner that B has lost state, if B never 
responds?

> I mean, i am thinking in the following scenario (that i think Brian 
> suggested some time ago)
> 
> Node A and Node B start a communication using IPA1 and IPA2 respectively,
> 
> A while after, they decide to create a SHIM context, for this 
> communication. For that, the perform the initial exchange and the 
> continue the communication for a while.
> 
> At this points i can think about 3 scenarios:
> 
> 1- the "normal" situation i.e. there no abrupt lost of context for 
> external reasons. In this case, each packet received corresponding to 
> that context would extend the lifetime of the context information. If no 
> packets are exchanged for a given period T, then both ends discard the 
> state. I guess T should defined in a conservative way, i.e. long enough.

Such an approach isn't robust in the presence of packet loss.
A could be sending a few packets, but B might never receive them due to 
random packet loss. So you end up with B discarding the state while A 
thinks B should still have the state, since A sent packets to B.

FWIW the CLOSE exchange in draft-ietf-hip-base-02.txt avoids this 
problem by basing the "should I time this out" on the receipt of 
packets, and not due to packets being sent.
I think you'd need a similar approach in a semi-hard-state approach to 
shim6.

> 2- One of the nodes reboots and all state is lost. In this case, it 
> doesn't make much sense to rebuild the context, i think, because the 
> upper layer state has also been lost, so i guess it doesn't make much 
> sense to try to resume the SHIM context when there is no upper layer 
> that wants to preserve a communication

The problem if you do nothing, is that the upper layer would not find 
out in a timely manner. For instance, TCP would not receive a reset 
packet when the peer has rebooted, because the shim layer would pass up 
a TCP packet with a bad checksum (due to not having replaced the 
locators with the ULIDs).

So if you do nothing you are most likely making the notification of a 
upper layer state loss a lot worse than it is without shim6.

> 3- There is some abrupt lost of context state in one of the nodes (and 
> only the context state. (i am not sure how likely this is, i mean i 
> guess it could happen when because of the soft state, one of the nodes 
> discards the state before its peer, and after that the peer wants to 
> resume the communication associated with this context. I guess the 
> occurrence of such situation becomes less likely, as the inactive time 
> required to discard the context grows). In any case, suppose that 
> suddenly node A losses its state about the SHIM context. At this point, 
> node B would detect that the context has been lost. How this is 
> detected, is to be analyzed in depth.
>    - If the communication was still using the ULIDs as locators,
>      then data packets will flow without problems and no problem
>      is detected. I guess that for this case, a SHIM keepalive
>      may be needed to detect this case
>    - If the communication is using locators that differ from ULIDs
>      then, i guess that upper layers will send an error message
>      back, like port unreachable or similar, so that the context
>      loss can be detected

NO, NO, NO.
The upper layer packets will be silently discarded with a checksum error.

>    - If SHIM signaling packets are sent by node B, the absence
>      of replies would indicate that an the context has been lost
> 
> At this point, when node B detects that the context state has been lost, 
> node B can try to perform the initial exchange again, using the same 
> information that was used during the initial exchange the first time. I 
> think this would permit node A to rebuild the lost state
> 
> I think this soft state could work without requiring the error message.

And I think it is at least very hard. The protocol would be more robust 
with an error message.

And since we are not trying to build a security protocol - we just don't 
want to make things less secure than they are today - an error message 
which will only be believed when generated by an on-path node, should be 
ok even if it makes the peers re-establish the shim6 state.

> But in any case, note that through error message spoofing the attacker 
> may manage to impose that the context is re initiated while the 
> communication still flows (in the case that the ULIDs are still being 
> used as locators) That would allow an attacker that has a compatible CGA 
> parameter data structure for instance to place himself in the middle of 
> an ongoing communication.

But getting a compatible CGA structure is hard.

    Erik

Delivery-date: Mon, 09 May 2005 16:52:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Mon, 9 May 2005 09:51:56 -0700
From: "Christian Huitema" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Brian E Carpenter" <[email-masked]>
Cc: "shim6" <[email-masked]>

> >> So unless having potential middlebox implementation compatibility
> >> is  a great hardship we shouldn't break it.
>=20
> > But I think it will be a great hardship, simply because of IPSEC.
>=20
> Wouldn't IPsec be just another higher layer protocol to the shim?

Actually, I would like an option to run the shim inside IPSEC. It
prevents meddling by intermediate boxes. It also mitigates the privacy
risks associated with shim6.=20

-- Christian Huitema

Delivery-date: Mon, 09 May 2005 13:27:24 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Mon, 9 May 2005 15:27:04 +0200
To: Brian E Carpenter <[email-masked]>

On 9-mei-2005, at 14:44, Brian E Carpenter wrote:

>> So unless having potential middlebox implementation compatibility  
>> is  a great hardship we shouldn't break it.

> But I think it will be a great hardship, simply because of IPSEC.

Wouldn't IPsec be just another higher layer protocol to the shim?

Since the address fields are restored to their original state, even  
AH should work.

Delivery-date: Mon, 09 May 2005 12:44:42 +0000
Date: Mon, 09 May 2005 14:44:08 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Christian Huitema <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]

Iljitsch van Beijnum wrote:
> On 8-mei-2005, at 18:35, Christian Huitema wrote:
> 
>> Besides, the assumption that a middlebox sees all of the host
>> communications is often wrong today, and will likely become wrong even
>> more often in the future.
> 
> 
> That's true, and in most cases a host implementation would be better  
> than a middlebox implementation. Still, we shouldn't ignore the input  
> from the enterprise guys who really don't want to do traffic  
> engineering on a host-by-host basis, to name just one downside of  every 
> host doing multihoming autonomously.
> 
> So unless having potential middlebox implementation compatibility is  a 
> great hardship we shouldn't break it.

But I think it will be a great hardship, simply because of IPSEC.

    Brian

Delivery-date: Sun, 08 May 2005 17:24:21 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Sun, 8 May 2005 19:24:04 +0200
To: Christian Huitema <[email-masked]>

On 8-mei-2005, at 18:35, Christian Huitema wrote:

> Besides, the assumption that a middlebox sees all of the host
> communications is often wrong today, and will likely become wrong even
> more often in the future.

That's true, and in most cases a host implementation would be better  
than a middlebox implementation. Still, we shouldn't ignore the input  
from the enterprise guys who really don't want to do traffic  
engineering on a host-by-host basis, to name just one downside of  
every host doing multihoming autonomously.

So unless having potential middlebox implementation compatibility is  
a great hardship we shouldn't break it.

Delivery-date: Sun, 08 May 2005 16:35:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Sun, 8 May 2005 09:35:06 -0700
From: "Christian Huitema" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: "Jeroen Massar" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>, <[email-masked]>, "shim6" <[email-masked]>

> >> IMHO shim6 being able to be done in middleboxes is actually a=20
> >> requirement if you really think this will every be deployed at all.
>=20
> I don't agree. I think the best hope of deployment of=20
> anything these days is stealth, and that means (in this case)=20
> new versions of host TCP/IP stacks, without the people=20
> operating the network having to change anything.

I am with Brian on that one. This sort of changes is typically done in
service packs, which would enable wide scale deployment of shim6 in a
couple of years after the standardisation.

Besides, the assumption that a middlebox sees all of the host
communications is often wrong today, and will likely become wrong even
more often in the future. For example, the middlebox does not see the
content of a VPN connection, and does not control the allocation of
addresses by the VPN server. The middlebox does not see the content of a
GPRS or UMTS connection. Even on a home network, you may well end up
with several middleboxes, e.g. one for the DSL network and one for the
cable network.

-- Christian Huitema

Delivery-date: Sat, 07 May 2005 14:31:24 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Sat, 7 May 2005 16:31:14 +0200
To: Erik Nordmark <[email-masked]>

On 7-mei-2005, at 1:31, Erik Nordmark wrote:

>> Anyway, in a post I don't think anybody read I suggested that we   
>> should use a sort of demux negotation. Since demux can happen on:
>> - unique locator sets
>> - transport protocol information (port numbers)
>> - flow label
>> - demux option in the packet

> I did read that message.
> My concerns with this suggestion are:
> 1. Having multiple mechanisms plus some fallback rules seems very  
> complex. We should figure out how to make a single mechanism work.

Well, obviously a single mechanism is always gong to be less complex,  
but what I'm proposing here really isn't all that bad. In its  
simplest form, the receiver only has to transmit a fixed capabilities  
message and demux based on a shim header. The sender needs to parse a  
capabilities message and perform the following check:

if (demuxPossibleOnLocators() == true)
   sendPacket();
else if (demuxPossibleOnPort() == true && (proto == TCP || proto ==  
UDP))
   sendPacket();
else
   sendPacketWithShim6Option();

However, the possible gains are substantial: implementers now get to  
add unique locator / transport / flow label (de)multiplexing to their  
stuff if and when it makes sense for them, and this capability will  
be used whenever it's available at both ends.

Simply going for the option means adding bytes to all packets  
forever. This is especially harmful when future developments such as  
unreachable ULIDs or rehoming for traffic engineering purposes happen.

> 2. Peeking at the transport information is a no-no in my mind. We  
> want this to be transport independent.

There is a difference in using information when it's available and  
depending on the information to be there.

Delivery-date: Sat, 07 May 2005 14:19:29 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers
Date: Sat, 7 May 2005 16:19:06 +0200
To: Erik Nordmark <[email-masked]>

On 7-mei-2005, at 1:29, Erik Nordmark wrote:

> But there is one style of recovery where the checksum might help.
> When B receives a packet and doesn't have matching context state,  
> instead of sending an error to A, B could initiate creating a new  
> context with A.
> This approach needs to be done with care to cope with DoS attacks  
> (don't create any state on B etc). But it is an example of  
> something which can benefit from the checksum.
> However, if the mechanism can deal with a DoS attack, presumably it  
> can deal with occasional extra work due to bit errors.

Right. There is a problem, though: presumably there is already a  
failure, or there wouldn't be any "shim6ed" packets coming in. This  
means that the receiver that is without state can't contact the  
remote ULID directly for a return routability check.

We can make this work by adding some extra stuff to the initial  
exchange between the ULIDs: each host would have to generate a hash  
over a timestamp, the remote ULID and a secret and then transmit this  
hash directly to the ULID address. When there is a state loss the  
correspondent is then able to prove that it held the ULID as a  
reachable address at a known point in time. However, this mechanism  
may be too open to sniffing attacks.

>> BTW if we're just worried about single bit errors you don't need a  
>> 16  bit checksum for this. Even a parity bit will find single  
>> flipped  bits without fail. A very short CRC may be a good  
>> alternative.

> I don't think I said "single" anywhere.

Ok.

> I think we need to be concerned about all in-transit errors that  
> are not detected by the L2 mechanisms (CRC, etc).

Hm, AFAIK _all_ layer 2 checksums are MUCH stronger than the TCP/UDP/ 
ICMP checksum. And as long as all that the shim does is transform  
information that is already covered by a checksum later (= addresses,  
which are in the pseudo header) then there is no need to have a  
separate checksum here.

Delivery-date: Sat, 07 May 2005 13:37:05 +0000
Date: Sat, 07 May 2005 15:36:49 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Erik Nordmark <[email-masked]>
CC: Jeroen Massar <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, [email-masked], shim6 <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]

Erik Nordmark wrote:
> Jeroen Massar wrote:
> 
>> IMHO shim6 being able to be done in middleboxes is actually a
>> requirement if you really think this will every be deployed at all. 

I don't agree. I think the best hope of deployment of anything these
days is stealth, and that means (in this case) new versions of
host TCP/IP stacks, without the people operating the network having
to change anything.

    Brian

Delivery-date: Sat, 07 May 2005 13:11:36 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: soft state (was Re: shim6 and bit errors in data packet headers
Date: Sat, 7 May 2005 12:21:26 +0200
To: Erik Nordmark <[email-masked]>

El 07/05/2005, a las 0:47, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>>> This implies that in the bit error case above, since B can't tell =
the
>>> difference between a bit error and the case when it has=20
>>> lost/discarded
>>> the state, B needs to at least send an error message to A saying "I=20=

>>> have
>>> no matching shim6 context".
>> why?
>> i would argue that silently discarding the packet would be enough. I=20=

>> mean, i think that soft state approach is an interesting approach,=20
>> but i would like to explore the possibility of silently discarding=20
>> packets that don't match with any existent contexts.
>
> I think if you want to discard packets for which you don't have a=20
> context, then I think you effectively end up assuming some hard(er)=20
> state management, where the two ends coordinate when they discard=20
> their state. But I can't see how this can work in a soft-state=20
> approach - soft state seems to imply that a node can rebuild the state=20=

> when it receives packets.
>

But, the state can be rebuild using the initial exchange again, right?

I mean, i am thinking in the following scenario (that i think Brian=20
suggested some time ago)

Node A and Node B start a communication using IPA1 and IPA2=20
respectively,

A while after, they decide to create a SHIM context, for this=20
communication. For that, the perform the initial exchange and the=20
continue the communication for a while.

At this points i can think about 3 scenarios:

1- the "normal" situation i.e. there no abrupt lost of context for=20
external reasons. In this case, each packet received corresponding to=20
that context would extend the lifetime of the context information. If=20
no packets are exchanged for a given period T, then both ends discard=20
the state. I guess T should defined in a conservative way, i.e. long=20
enough.

2- One of the nodes reboots and all state is lost. In this case, it=20
doesn't make much sense to rebuild the context, i think, because the=20
upper layer state has also been lost, so i guess it doesn't make much=20
sense to try to resume the SHIM context when there is no upper layer=20
that wants to preserve a communication

3- There is some abrupt lost of context state in one of the nodes (and=20=

only the context state. (i am not sure how likely this is, i mean i=20
guess it could happen when because of the soft state, one of the nodes=20=

discards the state before its peer, and after that the peer wants to=20
resume the communication associated with this context. I guess the=20
occurrence of such situation becomes less likely, as the inactive time=20=

required to discard the context grows). In any case, suppose that=20
suddenly node A losses its state about the SHIM context. At this point,=20=

node B would detect that the context has been lost. How this is=20
detected, is to be analyzed in depth.
    - If the communication was still using the ULIDs as locators,
      then data packets will flow without problems and no problem
      is detected. I guess that for this case, a SHIM keepalive
      may be needed to detect this case
    - If the communication is using locators that differ from ULIDs
      then, i guess that upper layers will send an error message
      back, like port unreachable or similar, so that the context
      loss can be detected
    - If SHIM signaling packets are sent by node B, the absence
      of replies would indicate that an the context has been lost

At this point, when node B detects that the context state has been=20
lost, node B can try to perform the initial exchange again, using the=20
same information that was used during the initial exchange the first=20
time. I think this would permit node A to rebuild the lost state

I think this soft state could work without requiring the error message.

> FWIW I've suggested a way to handle a close handshake for hard state=20=

> management in the past, which has made it into the HIP spec.
>
>> I mean, i think that (as i think you mentioned a while ago) defining=20=

>> a error message in order to reply to those packets belonging to non=20=

>> existent contexts may introduce some security issues. In particular,=20=

>> it may allow an attacker to force to communicating end nodes to re-do=20=

>> the initial exchange, allowing the attacker to become a MiTM.
>
> Yes, but that isn't any worse than in today's Internet; an attacker=20
> can arrive on the path and use e.g. ARP spoofing in the local link=20
> (which might be the link between two routers in the path) to redirect=20=

> the traffic.
>

I am not sure these two cases are directly comparable...

But in any case, note that through error message spoofing the attacker=20=

may manage to impose that the context is re initiated while the=20
communication still flows (in the case that the ULIDs are still being=20
used as locators) That would allow an attacker that has a compatible=20
CGA parameter data structure for instance to place himself in the=20
middle of an ongoing communication.

>    Erik
>

Delivery-date: Sat, 07 May 2005 13:11:35 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Middleboxes [Was: Flow label versus Extension header - protocol itself]
Date: Sat, 7 May 2005 11:39:32 +0200
To: Erik Nordmark <[email-masked]>

El 07/05/2005, a las 1:35, Erik Nordmark escribi=F3:

> Jeroen Massar wrote:
>
>> IMHO shim6 being able to be done in middleboxes is actually a
>> requirement if you really think this will every be deployed at all.=20=

>> With
>> shim6 in the 'middleboxes' one can let the egress/ingress routers or=20=

>> the
>> firewalls on the boundaries of the site do the shim6. This allows you=20=

>> to
>> not touch the hosts at all and you will only have to configure those
>> boxes and not all the boxes in your network. Which gives all the
>> advantages of NAT, at least the ones that people perceive to have =
now.
>
> I've thought of shim6 middleboxes on and off, and it seems like the=20
> best we can do is that they become a 1-1 IPv6 NAT (which speaks=20
> non-shim6 to the host, and shim6 on the other side).
> It seems hard to do much better.
>
> One of the issues is that in order to do better the host needs to know=20=

> its HBA/CGA address sets. Autoconfiguring the addresses using existing=20=

> mechanisms will not produce a HBA/CGA address set. So either the host=20=

> has to be modified to implement that address generation (in which case=20=

> it can presumably implement all of shim6), or the host has to be=20
> manually configured with the HBA/CGA address set,

well, i guess that addresses could be delivered through dhcp also.
I mean, the middle box delivers the HBA/CGA through dhcp to the hosts=20
and performs proxy funtions for this hosts, since it knows the=20
associated paramenters

Regards, marcelo

>  and the middlebox takes care of doing the shim6 signaling on the=20
> host's behalf.
>
> Does anybody think we can do better?
>
>    Erik
>
>> Of course, exactly if you put this in the endhost itself or in some
>> middlebox should be left open to the person configuring the network.
>> Greets,
>>  Jeroen
>
>

Delivery-date: Sat, 07 May 2005 05:29:29 +0000
Date: Sat, 7 May 2005 08:28:39 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: Francis Dupont <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

On Fri, 6 May 2005, Erik Nordmark wrote:
> Francis Dupont wrote:
>> The point I'd like to make (and about which we should agree) is that
>> it is hard or impossible to keep full/real RFC 3697 compliance and
>> shim6 goal support, so if we decide to follow the flow label way the
>> best is to obsolete the RFC 3697 and to reserve the 20 bit field
>> currently named flow label to shim6 usage.
>
> FWIW I disagree with this conclusion.
>
> As I've stated in other emails, we can have a RFC 3697 compliant flow label 
> usage for the communication using the ULIDs as locators, and when there is a 
> need to use a different locator pair after a failure, we can have a different 
> (RFC 3697 compliant AFAIK) usage of the flow label.
>
> In all cases the <src locator, dst locator, flow label> would identify the 
> flow. The fact that each locator pair implies a different flow is inherent in 
> the desire to switch locator(s) when there is failure for the initial locator 
> pair.

Agree with Erik.  I see nothing "holy" with flow label.  If we define 
it so that it matches RFC 3697 we should be OK.  We'll just have to 
see how it looks like when a new proposal for the use of RFC 3697 
comes along.  They might be able to co-exist peacefully.  There might 
be issues before or after a failure event.  But if those are serious 
enough, the sites (and implementors) would just need to make the 
tradeoff which ones to support and how.  But that's OK -- there are 
going to be multiple (and to some degree conflicting) uses of flow 
label in any case.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 06 May 2005 23:35:07 +0000
Date: Fri, 06 May 2005 16:35:03 -0700
From: Erik Nordmark <[email-masked]>
To: Jeroen Massar <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, [email-masked], shim6 <[email-masked]>
Subject: Middleboxes [Was: Flow label versus Extension header - protocol itself]

Jeroen Massar wrote:

> IMHO shim6 being able to be done in middleboxes is actually a
> requirement if you really think this will every be deployed at all. With
> shim6 in the 'middleboxes' one can let the egress/ingress routers or the
> firewalls on the boundaries of the site do the shim6. This allows you to
> not touch the hosts at all and you will only have to configure those
> boxes and not all the boxes in your network. Which gives all the
> advantages of NAT, at least the ones that people perceive to have now.

I've thought of shim6 middleboxes on and off, and it seems like the best 
we can do is that they become a 1-1 IPv6 NAT (which speaks non-shim6 to 
the host, and shim6 on the other side).
It seems hard to do much better.

One of the issues is that in order to do better the host needs to know 
its HBA/CGA address sets. Autoconfiguring the addresses using existing 
mechanisms will not produce a HBA/CGA address set. So either the host 
has to be modified to implement that address generation (in which case 
it can presumably implement all of shim6), or the host has to be 
manually configured with the HBA/CGA address set, and the middlebox 
takes care of doing the shim6 signaling on the host's behalf.

Does anybody think we can do better?

    Erik

> Of course, exactly if you put this in the endhost itself or in some
> middlebox should be left open to the person configuring the network.
> 
> Greets,
>  Jeroen
> 

Delivery-date: Fri, 06 May 2005 23:31:31 +0000
Date: Fri, 06 May 2005 16:31:23 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Francis Dupont <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Iljitsch van Beijnum wrote:

> Anyway, in a post I don't think anybody read I suggested that we  should 
> use a sort of demux negotation. Since demux can happen on:
> 
> - unique locator sets
> - transport protocol information (port numbers)
> - flow label
> - demux option in the packet

I did read that message.
My concerns with this suggestion are:
1. Having multiple mechanisms plus some fallback rules seems very 
complex. We should figure out how to make a single mechanism work.
2. Peeking at the transport information is a no-no in my mind. We want 
this to be transport independent.

    Erik

Delivery-date: Fri, 06 May 2005 23:29:32 +0000
Date: Fri, 06 May 2005 16:29:21 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote:
> On 4-mei-2005, at 1:33, Erik Nordmark wrote:
> 
>> This is a function of how we do state management in shim6. There  has 
>> been
>> little discussion about this. We could do soft state, where there  is no
>> explicit taredown/close message, or we could do something which  tries to
>> tare down the state at the both ends in a coordinated fashion.
> 
> 
> I'm not a big fan of this. Just look at the way TCP sessions shut  down. 
> There are still many TCP sessions that end in weird ways  because both 
> ends have different assumptions.

Agreed.

> Also, it seems strange to do work because you want to end the  
> communication.

I do this every day; need to press the hangup button on the phone (or 
hang up the receiver) each time I end a phone conversation.

> On the other hand, we don't want to keep shim6 state around forever,  
> and we also don't want to refresh the state continuously when there  
> ins't any communication.

A hybrid is the thing I had in some NOID draft, and they put in HIP, 
which is basically a relatively long timeout (which requires periodic 
refresh the keep the state alive) combined with an optional CLOSE 
message to make the peer tare down the state sooner.
That approach is "hard state" in that it doesn't rely on an error 
message to recover from state loss.

The general approach of using an explicit CLOSE message to help the peer 
garbage collect earlier might be useful for a soft state approach, but I 
haven't looked into this.

>> So in conclusion, if we don't have a checksum for the shim6 context  
>> tag, then
>> we are constrained on what the shim can do when receiving a packet for
>> which it has no matching context.
> 
> 
> Is there any other action that you would like to see taken that can't  
> be without a checksum?

I don't yet know, since I don't understand the interactions with the 
state management.
But there is one style of recovery where the checksum might help.
When B receives a packet and doesn't have matching context state, 
instead of sending an error to A, B could initiate creating a new 
context with A.
This approach needs to be done with care to cope with DoS attacks (don't 
create any state on B etc). But it is an example of something which can 
benefit from the checksum.
However, if the mechanism can deal with a DoS attack, presumably it can 
deal with occasional extra work due to bit errors.

> BTW if we're just worried about single bit errors you don't need a 16  
> bit checksum for this. Even a parity bit will find single flipped  bits 
> without fail. A very short CRC may be a good alternative.

I don't think I said "single" anywhere.
I think we need to be concerned about all in-transit errors that are not 
detected by the L2 mechanisms (CRC, etc).

I don't think we need to reinvent a wheel here. If we can do without 
checksum, then fine. If we need a checksum, just use the 16 bit one the 
other protocols use.

    Erik

Delivery-date: Fri, 06 May 2005 23:19:55 +0000
Date: Fri, 06 May 2005 16:19:51 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: shim6 <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers

Greg Daley wrote:

> In some circumstances, there may be a port unreachable response before
> the checksum is even consulted (UDP-Lite).

If that's the case it sounds like a bug in UDP-Lite. UDP-lite can verify 
the checksum (which only covers part of the payload unlike UDP), before 
it generates the ICMP error.

> I believe that there's a chance of additional responding port
> unreachables or resets for flows which match but do not have upper layer
> sessions for the flow (since it is tied to different IP addresses).

There is a small probability, but not qualitatively different than for 
IPv6 itself. For this to happen the bit error would have to be such that 
the resulting packet is ok according to the TCP/UDP/ICMP checksum.

When this low probability even happens in IPv4 or IPv6 today, the result 
is quite unpredictable. Could cause undetected data corruption in the 
application payload.

I don't think the indirection via the shim (which would change the 
locators to ULIDs for the incorrectly matched context) changes much in 
terms of the probability.

>> But B probably shouldn't do any more than this, since it doesn't know 
>> whether
>> the cause was a bit error or it having lost/discarded the shim6 state.
> 
> 
> Loss of shim state is possible if a signaling packet gets lost or
> reordered.  We don't necessarily want to tell the source that there's
> a problem if the next packet is a signaling packet retry.

But we also get loss of state when B has rebooted, and lost all state.
In this case B would be unable to deliver any higher-level error (TCP 
reset, UDP port unreachable) until it either has reacquired the shim 
state, or convinced A to send using the ULIDs as locators (so no receive 
side address field replacement is necessary).

    Erik

Delivery-date: Fri, 06 May 2005 22:47:11 +0000
Date: Fri, 06 May 2005 15:47:00 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers

marcelo bagnulo braun wrote:

>> This implies that in the bit error case above, since B can't tell the
>> difference between a bit error and the case when it has lost/discarded
>> the state, B needs to at least send an error message to A saying "I have
>> no matching shim6 context".
> 
> 
> why?
> i would argue that silently discarding the packet would be enough. I 
> mean, i think that soft state approach is an interesting approach, but i 
> would like to explore the possibility of silently discarding packets 
> that don't match with any existent contexts.

I think if you want to discard packets for which you don't have a 
context, then I think you effectively end up assuming some hard(er) 
state management, where the two ends coordinate when they discard their 
state. But I can't see how this can work in a soft-state approach - soft 
state seems to imply that a node can rebuild the state when it receives 
packets.

FWIW I've suggested a way to handle a close handshake for hard state 
management in the past, which has made it into the HIP spec.

> I mean, i think that (as i 
> think you mentioned a while ago) defining a error message in order to 
> reply to those packets belonging to non existent contexts may introduce 
> some security issues. In particular, it may allow an attacker to force 
> to communicating end nodes to re-do the initial exchange, allowing the 
> attacker to become a MiTM.

Yes, but that isn't any worse than in today's Internet; an attacker can 
arrive on the path and use e.g. ARP spoofing in the local link (which 
might be the link between two routers in the path) to redirect the traffic.

    Erik

Delivery-date: Fri, 06 May 2005 22:29:59 +0000
Date: Fri, 06 May 2005 15:29:26 -0700
From: Erik Nordmark <[email-masked]>
To: Francis Dupont <[email-masked]>
CC: [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Francis Dupont wrote:
> The point I'd like to make (and about which we should agree) is that
> it is hard or impossible to keep full/real RFC 3697 compliance and
> shim6 goal support, so if we decide to follow the flow label way the
> best is to obsolete the RFC 3697 and to reserve the 20 bit field
> currently named flow label to shim6 usage.

FWIW I disagree with this conclusion.

As I've stated in other emails, we can have a RFC 3697 compliant flow 
label usage for the communication using the ULIDs as locators, and when 
there is a need to use a different locator pair after a failure, we can 
have a different (RFC 3697 compliant AFAIK) usage of the flow label.
In all cases the <src locator, dst locator, flow label> would identify 
the flow. The fact that each locator pair implies a different flow is 
inherent in the desire to switch locator(s) when there is failure for 
the initial locator pair.

    Erik

Delivery-date: Fri, 06 May 2005 22:26:38 +0000
Date: Fri, 06 May 2005 15:25:41 -0700
From: Erik Nordmark <[email-masked]>
To: Francis Dupont <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    Dealing with the same header for different purposes in different places 
>    in the header sequence doesn't make an implementation easier.
> 
> => the price has been already paid for Mobile IPv6...

Yes, but that doesn't mean we want to pay again for shim6.

>    So while 
>    this might be viewed as conceptually simple, and implementation needs to 
>    verify that a particular option (such as the MIPv6 one) is not present 
>    in the wrong "type" (aka "placement") of destination option.
>    
> => note this check will be needed by an extension header too.

I don't think so. The receiver can be liberal in what it accepts when it 
comes to the order of extension headers. The only exception is ESP and 
AH which might want to, for security as opposed to functionality 
reasons, check what extension headers are before and/or after.

>    and the additional 2 byte overhead for destination options 
> 
> => there will be no real overhead if the proposed extension header
> will be 8 byte aligned and the tag length a power of two.

In any case the minimum thing we can add to e.g. a IPv6+TCP packet, is 
an 8 byte extension header; doesn't matter whether this is a 
destinations options header or a "shim6" header.
But the overhead is due to the destination options header implying an 
extra 16 bits for the option type and length. Thus a minimum size 
destination options header would be
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  |  Option Type  |  Opt Data Len | 

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

     |       32 bit option value = shim6 payload                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Whereas with a separate extension header the minimum is
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  |                               | 

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 

     |       48 bit option value = shim6 payload                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hence the destination option approach has 16 bit more overhead.
The criticality of this depends on how big we need the shim6 payload to 
be. The "firewall uniformity" argument implies that we want to use the 
same approach for the shim6 control messages and the data messages.
Thus we need a "message type" field.
And we need a context tag. Some people has expressed that they think 
that 20 bits is too little; not clear to me how many context we want one 
host to be able to support.
I hope we can design the state management so that the shim6 payload 
doesn't need to carry its own checksum.

But in any case, this is just one of the items to consider when 
comparing the destinations options approach with an extension header 
approach.

> => how do you address my concern about new extension header handling
> (BTW more not handling :-) by classifiers/filters/etc?

There are actually two potential issues in here: implementation and policy.
1. Current classifiers/filters etc would not have code that can deal 
with either a new shim6 destination option, or a new shim6 extension 
header. Thus for classifiers/filters in firewalls and elsewhere to be 
able to make decisions about the content, there would need to be new 
code written in either case. With an extension header approach there 
would also need to be code to find the next extension header, but given 
that we can design the extension header to have the type/len in the same 
place as other headers this change is trivial compared to the other 
necessary changes.

2. Existing (and future) IPv6 firewalls might have various policies that 
allow or block packets with destination options header independent of 
content, or allow or block such packets based on the actual options.

I suspect that the firewall mindset is that "anything unknown should be 
dropped", but I don't know what policies folks currently operate with.
It does seem odd to have a firewall policy which allows destination 
options independent of the options contained therein, so I would not 
assume that a shim6 destination option can silently sneak by a firewall.

    Erik

Delivery-date: Fri, 06 May 2005 12:50:55 +0000
Subject: Re: Flow label versus Extension header - protocol itself
From: Jeroen Massar <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: [email-masked], shim6 <[email-masked]>
Organization: Unfix
Date: Fri, 06 May 2005 14:50:07 +0200

--=-UF/wjccT66n9VbBY15LG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-05-05 at 10:55 +0200, Iljitsch van Beijnum wrote:
> On 4-mei-2005, at 8:32, Greg Daley wrote:
>=20
> >> (It should be possible to implement the  shim in middleboxes.)
>=20
> > Please, Please let's not go there!
>=20
> Too late... This has been on my list of desired features for years.
>=20
> > I don't think changing packets by insertion of headers unbeknownst
> > to the host is a good idea.
>=20
> Why not? It happens at lower layers all the time. As long as the =20
> packet that is eventually processed by the upper layer protocol is =20
> the same as the one sent by the remote upper layer entity there =20
> shouldn't be any problems.

IMHO shim6 being able to be done in middleboxes is actually a
requirement if you really think this will every be deployed at all. With
shim6 in the 'middleboxes' one can let the egress/ingress routers or the
firewalls on the boundaries of the site do the shim6. This allows you to
not touch the hosts at all and you will only have to configure those
boxes and not all the boxes in your network. Which gives all the
advantages of NAT, at least the ones that people perceive to have now.

Of course, exactly if you put this in the endhost itself or in some
middlebox should be left open to the person configuring the network.

Greets,
 Jeroen

--=-UF/wjccT66n9VbBY15LG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-UF/wjccT66n9VbBY15LG--

Envelope-to: [email-masked]
Delivery-date: Fri, 06 May 2005 08:30:17 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Greg Daley <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Fri, 06 May 2005 10:30:02 +0200

 In your previous mail you wrote:

   Is the incompatability you're considering based on a semantic 
   interpretation
   of different bits within the flow label (perhaps a little like 
   diffserv)?

=> this was proposed and rejected so I don't believe we'll get
a consensus about a proposal using this.

   Or (potentially) that hosts select flow labels in negotiation with the
   routing infrastructure?
   
=> this is more likely but the key point is the definition of flows.
The RFC gives only a vague idea of what is a flow and explains what
to do waiting the "flow labels for QoS" proposal.

   I guess these are uses which may clash with shim6.
   
=> two proposals for very different purposes are likely to clash so IMHO
there will be only one. The problem is this one is not yet written even
we know its purpose: QoS.

   Did you have something else in mind?
   
=> my advice is to give up because the QoS people will never endanger
the use of flow labels for their purposes. The RFC is illusion, its only
idea is to not leave an unspecified field in the IPv6 idea, it is *not*
to open the door to not standard (i.e., not for QoS) uses of flow labels.

   I think I've been treating it as an immutable number for a
   particular path.
   
=> perhaps we'll see how it will be amazingly easy to overwrite for
a flow labels for QoS good proposal (:-)?

Regards

[email-masked]

PS: shim6 is end-to-end so an end-to-end mechanism should be used.
The standard one is the destination option...

Delivery-date: Fri, 06 May 2005 08:27:12 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Fri, 6 May 2005 10:26:40 +0200
To: Greg Daley <[email-masked]>

El 06/05/2005, a las 2:47, Greg Daley escribi=F3:

> Hi Marcelo,
>
> ----- Original Message -----
> From: marcelo bagnulo braun <[email-masked]>
> Date: Thursday, May 5, 2005 7:06 pm
> Subject: Re: Flow label versus Extension header - protocol itself
>
> [cut]
>>>
>>> Yes, it's always needed, but the time ordering of the packets to do
>>> the signalling may not be strict.
>>>
>>> If the upper layer protocol is ESP with authentication (or AH),
>>> for example, it will be possible to identify that the flow
>>> belongs to an upper-layer data stream because of the SPI, and the
>>> fact that the packet authenticates using the right HMAC.
>>>
>>
>> Are you considering the situation where the verification of the
>> new locator is done through IPSec?
>>
>> I mean, so far, i think we had considered the case where the
>> addition of new locators had its own security mechanism
>> (different from IPSec) and that there was an explicit signalling
>> message for adding new locators to the set, and that these
>> messages carry their own authentication information.
>> I mean, i think it is important to properly define what scenarios
>> are we considering...
>
> Certainly.
>
> I was actually thinking that if signalling and data are in separate
> messages, data plane messages are unprotected.
>

agree

> If the upper layer on the data plane is only AH or authenticated ESP,
> there's no need to be particularly careful about the matching and
> whether
> the source and destination addresses are in the locator set, since
> the authentication mechanism will take care of it.
>

ok, so you are considering a scenario that depending on what the next=20
header, the demux operation is performed based on different context=20
tags, i.e. if there IPSec is done based on the SPI, if no IPSec use the=20=

flow label, for example?

My only concern about this multi-context tag situation is the added=20
complexity, especially considering that we need a general purpose=20
mechanism to deal with the general case, where the next header is no=20
useful for us

> The signaling scheme needs a separate and robust scheme for
> communicating
> mappings.  I wasn't recommending use of IKE/AH for that because people
> will
> throw stones at me (it's Internet Area not Security Area ;)
>

ok

> We'll discuss this soon.
>
> As a slightly comical solution: we could use AH (or a trusty
> authenticated ESP)
> as our already defined extension header.  SPI's are already sender
> assigned,
> and are even bigger than flow labels.
>

in the data packets, you mean?

but wouldn't this imply that all data packets need to be protected with=20=

ESP or AH, imposing crypto for all data packets?

> Worse ideas have got to Proposed Standard.
>
>>> This may not be palatable to all, but the possibility is there
>>> (and may be dismissed later).
>>>
>>> Packets sent before the signaling wouldn't be guaranteed to get
>>> through, but if the actual signaling took computation time
>>
>> Well, i my understanding data packets carrying new lcoators that
>> have not been added to the locator set through proper signaling
>> will be discarded... I mean this is similar to MIP RO, a CN won't
>> understna packets coming from a CoA before the BU binding the new
>> CoA to the HoA has been received and verified, right?
>
>
> I see a difference with MIPv6 in that even if a locator has been added
> to the set, the address mappings aren't 1-to-1 (like MIPv6). There
> may be N valid <source,label> pairs with M valid destinations in a =
one-
> way
> stream.
>

agree

> So it may be possible for someone to quickly shift to a valid source
> and destination pair without explicitly signalling at that instant.
>
> essentially, the signalling could say: all these are valid locators,
> please be ready for these packets.
>

fully agree, so this is not a problem, right?

i mean, before accepting packets from a given locator, this locator has=20=

to be be contained in the locator set and properly verified. through=20
this verification process, it is possible to guarantee that the context=20=

tag associated to this locator is good for uniquely identify the=20
associated shim context...

I mean, i don't see a problem which is specific to the context tag=20
assignment mechanism....

> If there was only a label to check initially, this would limit the
> forwarding plane processing and storage requirements (limiting them
> to a small known set of addresses for a particular tag, rather than
> matching <source,tag> pairs).

>
>>> (or a longer, reliable signaling path), this is an optimization
>>> which would work well for some data.
>>>
>>> Please note that if strict ordering of signaling before packet
>>> arrival is required, then receiver side flow label allocation
>>> isn't required itself for ensuring decodability just based on
>>> the IPv6 header.
>>
>> I ma not sure i agree here
>
> Well, perhaps it doesn't matter in the general "I haven't seen the
> address
> but I know the label", but for a previously known valid=20
> <src,dest,label>
> mapping, you shouldn't need to signal that the packets are about to
> arrive like MIPv6 does now.
>

agree.

What is needed is a signalling mechanism to add locators to the locator=20=

set and properly verify it (at this point a valid context tag can be=20
assoicated by the receiver, as you suggested)
Once that the locator is included in the locator set and verified, it=20
can be used without prior signalling to announce its usage in the data=20=

packets

regards, marcelo

> Greg
>

Delivery-date: Fri, 06 May 2005 03:19:18 +0000
Date: Fri, 06 May 2005 13:18:19 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Francis Dupont <[email-masked]>
Cc: [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>

Hi Francis, 

I there seem to be a lot of opinions going around, so 
instead of contributing to the torrent, I'll ask a
question for my own education.

----- Original Message -----
From: Francis Dupont <[email-masked]>
Date: Wednesday, May 4, 2005 7:22 pm
Subject: Re: Flow label versus Extension header - protocol itself

> The point I'd like to make (and about which we should agree) is that
> it is hard or impossible to keep full/real RFC 3697 compliance and
> shim6 goal support, so if we decide to follow the flow label way the
> best is to obsolete the RFC 3697 and to reserve the 20 bit field
> currently named flow label to shim6 usage.

Is the incompatability you're considering based on a semantic 
interpretation
of different bits within the flow label (perhaps a little like 
diffserv)?
Or (potentially) that hosts select flow labels in negotiation with the
routing infrastructure?

I guess these are uses which may clash with shim6.

Did you have something else in mind?

I think I've been treating it as an immutable number for a
particular path.

Greg

Delivery-date: Fri, 06 May 2005 00:49:04 +0000
Date: Fri, 06 May 2005 10:47:35 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], shim6 <[email-masked]>

Hi Marcelo, 

----- Original Message -----
From: marcelo bagnulo braun <[email-masked]>
Date: Thursday, May 5, 2005 7:06 pm
Subject: Re: Flow label versus Extension header - protocol itself

[cut]
> >
> > Yes, it's always needed, but the time ordering of the packets to do
> > the signalling may not be strict.
> >
> > If the upper layer protocol is ESP with authentication (or AH),
> > for example, it will be possible to identify that the flow
> > belongs to an upper-layer data stream because of the SPI, and the
> > fact that the packet authenticates using the right HMAC.
> >
> 
> Are you considering the situation where the verification of the
> new locator is done through IPSec?
> 
> I mean, so far, i think we had considered the case where the 
> addition of new locators had its own security mechanism
> (different from IPSec) and that there was an explicit signalling
> message for adding new locators to the set, and that these
> messages carry their own authentication information.
> I mean, i think it is important to properly define what scenarios 
> are we considering...

Certainly.   

I was actually thinking that if signalling and data are in separate
messages, data plane messages are unprotected.

If the upper layer on the data plane is only AH or authenticated ESP,
there's no need to be particularly careful about the matching and 
whether
the source and destination addresses are in the locator set, since
the authentication mechanism will take care of it.

The signaling scheme needs a separate and robust scheme for 
communicating
mappings.  I wasn't recommending use of IKE/AH for that because people 
will
throw stones at me (it's Internet Area not Security Area ;)

We'll discuss this soon.

As a slightly comical solution: we could use AH (or a trusty 
authenticated ESP)
as our already defined extension header.  SPI's are already sender 
assigned,
and are even bigger than flow labels.

Worse ideas have got to Proposed Standard.

> > This may not be palatable to all, but the possibility is there
> > (and may be dismissed later).
> >
> > Packets sent before the signaling wouldn't be guaranteed to get
> > through, but if the actual signaling took computation time
> 
> Well, i my understanding data packets carrying new lcoators that 
> have not been added to the locator set through proper signaling
> will be discarded... I mean this is similar to MIP RO, a CN won't 
> understna packets coming from a CoA before the BU binding the new
> CoA to the HoA has been received and verified, right?

I see a difference with MIPv6 in that even if a locator has been added
to the set, the address mappings aren't 1-to-1 (like MIPv6). There 
may be N valid <source,label> pairs with M valid destinations in a one-
way
stream.

So it may be possible for someone to quickly shift to a valid source 
and destination pair without explicitly signalling at that instant.

essentially, the signalling could say: all these are valid locators,
please be ready for these packets.

If there was only a label to check initially, this would limit the
forwarding plane processing and storage requirements (limiting them
to a small known set of addresses for a particular tag, rather than
matching <source,tag> pairs).

> > (or a longer, reliable signaling path), this is an optimization
> > which would work well for some data.
> >
> > Please note that if strict ordering of signaling before packet
> > arrival is required, then receiver side flow label allocation
> > isn't required itself for ensuring decodability just based on
> > the IPv6 header.
> 
> I ma not sure i agree here

Well, perhaps it doesn't matter in the general "I haven't seen the 
address
but I know the label", but for a previously known valid <src,dest,label>
mapping, you shouldn't need to signal that the packets are about to
arrive like MIPv6 does now.
 
Greg

Delivery-date: Thu, 05 May 2005 13:44:36 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 5 May 2005 15:43:55 +0200
To: Francis Dupont <[email-masked]>

On 5-mei-2005, at 14:53, Francis Dupont wrote:

Francis, I get a headache from your weird quoting style.

I also don't get what the problem is. It's like we're talking about  
two different things.

I DON'T CARE WHAT A FLOW IS.

The only thing that's important is that everything with the same flow  
label has the same ULIDs and that there aren't overlapping flow  
labels between two hosts.

These requirements are easy to meet without undue inconvience for  
other flow label use.

The receiver doesn't get any say in the flow label value. Sure, it  
would be nice if the receiver could tell the sender which flow label  
it should use, but that's simply not implementable in a reasonable  
way, too bad, move on.

Anyway, in a post I don't think anybody read I suggested that we  
should use a sort of demux negotation. Since demux can happen on:

- unique locator sets
- transport protocol information (port numbers)
- flow label
- demux option in the packet

it should be non-fatal if one or more of the first three mechanims  
aren't supported by either the sender or the receiver since they can  
always fall back on another mechanism. So even if the flow label is  
used in a manner that is incompatible with the shim flow label use  
that wouldn't be a problem, the sender should just fall back on using  
the demux option if the locator sets aren't unique and port number  
demux can't be done.

Delivery-date: Thu, 05 May 2005 13:00:01 +0000
Cc: [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 5 May 2005 14:59:40 +0200
To: Francis Dupont <[email-masked]>

So, it seems to me that:

- It would be possible to define a usage of the flow label as a context=20=

tag for the shim that is compatible with rfc 3697
- It may also be possible to define a usage of the flow label as a=20
context tag for the shim that also is compliant with an extended set of=20=

requirements that we consider that future usages of the flow label may=20=

require

However, it is clear that

- Any usage of the flow label as a context tag for the shim would=20
introduce some constraints w.r.t the label assignment which may=20
preclude some future usage of the flow label for other purposes

I guess that at this point we all have left is intuition for what the=20
chances are....

One option could be to restrict the flow label values that the shim can=20=

use to those that have the first bit set to one, and leave the other=20
values (those with the first bit to zero) untouched... i am not sure it=20=

is a good idea to add semantics to the flow label field though...

Regards, marcelo

El 05/05/2005, a las 14:34, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>>  so if you'll use flow labels for shim6, you'll remove
>> any possible use, including the unspecified QoS stuff (called flow
>> state establishment and related service in RFC 3697).
>
>    I don't see this. I think that a set of requirements of usage are
>    defined in RFC3697 and as long as we fulfill those, other apps=20
> should
>    be able to use it also.
>
> =3D> RFC 3697 was published because there was no concrete flow labels
> for QoS proposal (there is still none :-) and the situation became
> really problematic. But RFC 3697 is nearly only about defaults, i.e.,
> explains what to do waiting for the QoS stuff... which will likely
> a bit different about the critical details, for instance the flow
> definition (IMHO with layered payloads we should get more fine grain
> flows, and with aggregation more large grain flows).
>
>>  This is why
>> I used the word "real" for compliance: not only the text of RFC 3697
>> matters, but the spirit also and you can't argue any proposal using
>> flow labels for shim6 will be compatible with any proposal using
>> flow labels for QoS as soon as it is RFC 3697 compliant...
>
>    I am sorry but i am not able to see spirits, just read RFCs, so it=20=

> hard
>    for me to design a mechnansim that is compliant with the spirit.
>
> =3D> but with the years of hype about flow labels are for QoS, you =
should
> have some ideas about the background (:-).
>
>    However, i guess that you and other people (Brian) were involved in=20=

> the
>    discussions about the flow label and could provide a set of
>    requirements that represent this spirit.
>
> =3D> don't touch my bits (:-)? Seriously we should simply consider =
flow
> labels as reserved for QoS purposes.
>
>    Now, i don't think that arguments like "there cannot be two=20
> different
>    simoultaneous usages of the flow label" are good enough, though. A=20=

> set
>    of requirements that would allow future usages of the flow label=20
> would
>    be much better. Then we can see if we can define a usage of the =
flow
>    label for the shim that fulfill those.
>
> =3D> the issue is there is no concrete QoS proposal so it is hard to =
know
> what will be the real requirements... I know this doesn't help at all,
> this is why my idea is to break the reservation to something which
> perhaps will never happen, and to get rid of all the written and
> unwritten constraints.
>
>    I mean, i am all for preserving future usages of the flow label for=20=

> QoS
>    and other stuff, and i think that the flow label bits in the main
>    header are really precious and that usages that profit from hop by=20=

> hop
>    processing of these bits are the ones that really need those bits=20=

> (not
>    the shim, which is e2e)
>
> =3D> so in fact you understand the spirit (:-)!
>
>    However, i think that some proposals that have been considered, are
>    defining a usage that may not affect future usages of the flow =
label
>    and are worthy to be considered.
>
> =3D> as our purpose is not to publish a research paper we know this is
> not enough and there are some not technical problems to solve first.
>
> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Thu, 05 May 2005 12:53:44 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 05 May 2005 14:53:31 +0200

 In your previous mail you wrote:

   > => because they have a different definition of what is a flow and
   > how the flow state establishment method works.
   
   What is a flow and how it's established is of no importance to us  
   here.

=> you prove the opposite in some lines. The key point is the flow
definition, and this definition can change according to the use of
flow labels.

   At some point the source host slaps a flow label on packets  
   that it considers to be part of the same flow. How and why it does  
   that isn't important for shim6, the only thing we care about is that  

=> this only thing is a strong requirement, not a detail.

   the flow label is unique between the full set of locator addresses  
   and that after a rehoming the flow label remains the same so we get  
   to recognize the flow in question so we can map the right upper layer  
   identifier back.
   
=> so you get the receiver allocation, 10^20 limit, etc. And BTW
this is not the same than the default flow definition of RFC 3697.

   This doesn't get in the way of other uses for the flow label as it's  
   currently defined. Since we get stern warnings from the guy with many  
   hats that we can't change the flow label semantics I'll assume that  
   other people also won't be able to do that. So we are compatible with  
   the existing flow label aothers also have to, so there isn't a problem.

=> there is a problem because we are not without doubt compatible with
the not-yet-existing flow label use. We have three choices:
 -1- use something else
 -2- get rid of the QoS use because QoS is telecom junk and/or this QoS use
     won't happen
 -3- try to fulfill unknown requirements
I am in favor of -1-, -2- can be workable but please don't try -3-.

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Thu, 05 May 2005 12:35:34 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>, [email-masked]
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 05 May 2005 14:34:52 +0200

 In your previous mail you wrote:

   >  so if you'll use flow labels for shim6, you'll remove
   > any possible use, including the unspecified QoS stuff (called flow
   > state establishment and related service in RFC 3697).
   
   I don't see this. I think that a set of requirements of usage are 
   defined in RFC3697 and as long as we fulfill those, other apps should 
   be able to use it also.
   
=> RFC 3697 was published because there was no concrete flow labels
for QoS proposal (there is still none :-) and the situation became
really problematic. But RFC 3697 is nearly only about defaults, i.e.,
explains what to do waiting for the QoS stuff... which will likely
a bit different about the critical details, for instance the flow
definition (IMHO with layered payloads we should get more fine grain
flows, and with aggregation more large grain flows).

   >  This is why
   > I used the word "real" for compliance: not only the text of RFC 3697
   > matters, but the spirit also and you can't argue any proposal using
   > flow labels for shim6 will be compatible with any proposal using
   > flow labels for QoS as soon as it is RFC 3697 compliant...
   
   I am sorry but i am not able to see spirits, just read RFCs, so it hard 
   for me to design a mechnansim that is compliant with the spirit.
   
=> but with the years of hype about flow labels are for QoS, you should
have some ideas about the background (:-).

   However, i guess that you and other people (Brian) were involved in the 
   discussions about the flow label and could provide a set of 
   requirements that represent this spirit.
   
=> don't touch my bits (:-)? Seriously we should simply consider flow
labels as reserved for QoS purposes.

   Now, i don't think that arguments like "there cannot be two different 
   simoultaneous usages of the flow label" are good enough, though. A set 
   of requirements that would allow future usages of the flow label would 
   be much better. Then we can see if we can define a usage of the flow 
   label for the shim that fulfill those.
   
=> the issue is there is no concrete QoS proposal so it is hard to know
what will be the real requirements... I know this doesn't help at all,
this is why my idea is to break the reservation to something which
perhaps will never happen, and to get rid of all the written and
unwritten constraints.
   
   I mean, i am all for preserving future usages of the flow label for QoS 
   and other stuff, and i think that the flow label bits in the main 
   header are really precious and that usages that profit from hop by hop 
   processing of these bits are the ones that really need those bits (not 
   the shim, which is e2e)
   
=> so in fact you understand the spirit (:-)!

   However, i think that some proposals that have been considered, are 
   defining a usage that may not affect future usages of the flow label 
   and are worthy to be considered.
   
=> as our purpose is not to publish a research paper we know this is
not enough and there are some not technical problems to solve first.
   
Regards

[email-masked]

Delivery-date: Thu, 05 May 2005 12:22:49 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 5 May 2005 14:22:37 +0200
To: Francis Dupont <[email-masked]>

On 5-mei-2005, at 14:10, Francis Dupont wrote:

>> there can not be two different simultaneous uses of flow labels

>    Please tell us why you think this is so,

> => because they have a different definition of what is a flow and
> how the flow state establishment method works.

What is a flow and how it's established is of no importance to us  
here. At some point the source host slaps a flow label on packets  
that it considers to be part of the same flow. How and why it does  
that isn't important for shim6, the only thing we care about is that  
the flow label is unique between the full set of locator addresses  
and that after a rehoming the flow label remains the same so we get  
to recognize the flow in question so we can map the right upper layer  
identifier back.

This doesn't get in the way of other uses for the flow label as it's  
currently defined. Since we get stern warnings from the guy with many  
hats that we can't change the flow label semantics I'll assume that  
other people also won't be able to do that. So we are compatible with  
the existing flow label aothers also have to, so there isn't a problem.

Envelope-to: [email-masked]
Delivery-date: Thu, 05 May 2005 12:11:10 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 05 May 2005 14:10:44 +0200

 In your previous mail you wrote:

   On 5-mei-2005, at 10:10, Francis Dupont wrote:
   
   > there can not be two different simultaneous uses of flow labels
   
   Please tell us why you think this is so,

=> because they have a different definition of what is a flow and
how the flow state establishment method works.

   because I don't see any  
   problems with different things looking at the same flow label in  
   order to accomplish different goals.

=> the fact that all the proposed uses of flow labels are incompatible
doesn't disturb you just a bit?

Regards

[email-masked]

PS: one day someone will propose and deploy something which really uses
flow labels, and at this time he'll have to do some choices making
flow labels unsuitable for other uses. Of course if we really insist
to keep flow labels open to all proposals we should never get this.
BTW IMHO this will be accepted only if the addressed issue (aka
the related service model) is bound to QoS...

Delivery-date: Thu, 05 May 2005 11:31:05 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 5 May 2005 13:30:41 +0200
To: Francis Dupont <[email-masked]>

Hi Francis,

El 05/05/2005, a las 10:10, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    I fail to understand your conclusion here:
>
> =3D> Have you read my previous messages?
>

yes

>    the mechanism describe by Greg and Erik seem to be compliant with
>    RFC3697 to me...
>
> =3D> don't joke:

i am not

>  there can not be two different simultaneous uses of
> flow labels,

why? as long as none of the two parties that are trying to use don't=20
need to change it once it has been assigned and that the assignment=20
requirements are compatible i don't see any problem...

>  so if you'll use flow labels for shim6, you'll remove
> any possible use, including the unspecified QoS stuff (called flow
> state establishment and related service in RFC 3697).

I don't see this. I think that a set of requirements of usage are=20
defined in RFC3697 and as long as we fulfill those, other apps should=20
be able to use it also.

>  This is why
> I used the word "real" for compliance: not only the text of RFC 3697
> matters, but the spirit also and you can't argue any proposal using
> flow labels for shim6 will be compatible with any proposal using
> flow labels for QoS as soon as it is RFC 3697 compliant...
>

I am sorry but i am not able to see spirits, just read RFCs, so it hard=20=

for me to design a mechnansim that is compliant with the spirit.

However, i guess that you and other people (Brian) were involved in the=20=

discussions about the flow label and could provide a set of=20
requirements that represent this spirit.

Now, i don't think that arguments like "there cannot be two different=20
simoultaneous usages of the flow label" are good enough, though. A set=20=

of requirements that would allow future usages of the flow label would=20=

be much better. Then we can see if we can define a usage of the flow=20
label for the shim that fulfill those.

I mean, i am all for preserving future usages of the flow label for QoS=20=

and other stuff, and i think that the flow label bits in the main=20
header are really precious and that usages that profit from hop by hop=20=

processing of these bits are the ones that really need those bits (not=20=

the shim, which is e2e)

However, i think that some proposals that have been considered, are=20
defining a usage that may not affect future usages of the flow label=20
and are worthy to be considered.

>    I mean, in this approach the flow label used for a exchanging=20
> packets
>    with a given src and dst addresses remains constant during the=20
> lifetime
>    of the communication, so could you point out exactly which part of
>    RFC3697 they are not compliant with?
>
> =3D> I've considered only approachs which fulfill some requirements:
>  - shim6 negociation during communication (vs. before communication)
>  - mobility (i.e., unpredictable address) support.
> (parts of what I called shim6 goals)

agree with both goals and i think that the receiver based flow label=20
allocation mechanism described by Greg et al. fulfill those.

Regards, marcelo

>
> Regards
>
> [email-masked]
>

Delivery-date: Thu, 05 May 2005 09:42:03 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 5 May 2005 11:41:41 +0200
To: Francis Dupont <[email-masked]>

On 5-mei-2005, at 10:10, Francis Dupont wrote:

> there can not be two different simultaneous uses of flow labels

Please tell us why you think this is so, because I don't see any  
problems with different things looking at the same flow label in  
order to accomplish different goals.

Delivery-date: Thu, 05 May 2005 09:06:35 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Thu, 5 May 2005 11:06:26 +0200
To: [email-masked]

El 05/05/2005, a las 1:37, Greg Daley escribi=F3:

> Hi Marcelo,
>
> marcelo bagnulo braun wrote:
> [cut]
>>>
>>>
>>> Yes, this is the case.  If the existing 3697 (sender side) =
allocation
>>> for flow labels is used, then explicit signaling to add each
>>> <source,dest,label> to a multihoming context has to precede packet
>>> delivery.
>>>
>> Maybe i am missing something here, but this is the case,=20
>> independently of the mechanisms you choose to carry the context tag,=20=

>> because of security issues....
>> I mean when a node is adding a new locator into an established shim=20=

>> context, it must send an explicity message, informing of that new=20
>> locator and including security information in order to validate this=20=

>> new locator. In this exchange used to add and verify the new locator,=20=

>> the receiver could inform the transmitter about the new flow label=20
>> value (if needed)
>> So i would say that explicit signaling when adding a new locator is=20=

>> always needed.
>
> Yes, it's always needed, but the time ordering of the packets to do
> the signalling may not be strict.
>
> If the upper layer protocol is ESP with authentication (or AH), for
> example, it will be possible to identify that the flow belongs to an
> upper-layer data stream because of the SPI, and the fact that the
> packet authenticates using the right HMAC.
>

Are you considering the situation where the verification of the new=20
locator is done through IPSec?

I mean, so far, i think we had considered the case where the addition=20
of new locators had its own security mechanism (different from IPSec)=20
and that there was an explicit signalling message for adding new=20
locators to the set, and that these messages carry their own=20
authentication information.
I mean, i think it is important to properly define what scenarios are=20
we considering...

> This may not be palatable to all, but the possibility is there
> (and may be dismissed later).
>
> Packets sent before the signaling wouldn't be guaranteed to get
> through, but if the actual signaling took computation time

Well, i my understanding data packets carrying new lcoators that have=20
not been added to the locator set through proper signaling will be=20
discarded... I mean this is similar to MIP RO, a CN won't understna=20
packets coming from a CoA before the BU binding the new CoA to the HoA=20=

has been received and verified, right?

> (or a longer, reliable signaling path), this is an optimization
> which would work well for some data.
>
> Please note that if strict ordering of signaling before packet
> arrival is required, then receiver side flow label allocation
> isn't required itself for ensuring decodability just based on
> the IPv6 header.

I ma not sure i agree here

>  Only unique-to-sender label allocation is
> needed to avoid label collision,

right, but the problem here is how to deal with the case where the=20
sender runs out of flow label values and he needs to start re-using=20
flow labels. In this case, the receiver based flow label allocation=20
mechanism that you suggested seems to provide an elegant solution to=20
this problem.

regards, marcelo

> since no label selected on the
> host will collide with its own (going to any of its destinations),
> and the <source, label> pair is sufficient to identify it
> to the receiver.

>
>> a possible question would be if it would be possible to include the=20=

>> signalling in the same packet that carry the new locator as source=20
>> address... i guess this depends on how you define the packet=20
>> processing, but i guess it may be possible in any case.
>
> I'm not really fond of piggybacking data.
>
> It's possible of course but has potential issues with MTU.
>
> Separate signaling is also much easier to describe and
> implement.
>
> Greg
>

Delivery-date: Thu, 05 May 2005 08:55:23 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Thu, 5 May 2005 10:55:04 +0200
To: [email-masked]

On 4-mei-2005, at 8:32, Greg Daley wrote:

>> (It should be possible to implement the  shim in middleboxes.)

> Please, Please let's not go there!

Too late... This has been on my list of desired features for years.

> I don't think changing packets by insertion of headers unbeknownst
> to the host is a good idea.

Why not? It happens at lower layers all the time. As long as the  
packet that is eventually processed by the upper layer protocol is  
the same as the one sent by the remote upper layer entity there  
shouldn't be any problems.

Delivery-date: Thu, 05 May 2005 08:47:33 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers
Date: Thu, 5 May 2005 10:47:17 +0200
To: Erik Nordmark <[email-masked]>

On 4-mei-2005, at 1:33, Erik Nordmark wrote:

> This is a function of how we do state management in shim6. There  
> has been
> little discussion about this. We could do soft state, where there  
> is no
> explicit taredown/close message, or we could do something which  
> tries to
> tare down the state at the both ends in a coordinated fashion.

I'm not a big fan of this. Just look at the way TCP sessions shut  
down. There are still many TCP sessions that end in weird ways  
because both ends have different assumptions.

Also, it seems strange to do work because you want to end the  
communication.

On the other hand, we don't want to keep shim6 state around forever,  
and we also don't want to refresh the state continuously when there  
ins't any communication.

> If we assume that we do soft state management, then a host like B  
> needs to
> be prepared to receive shim6 packets where it has no context. This is
> because B might have discarded the shim6 state before A did, or B  
> might
> have crashes and lost all state while A retained the shim6 state.

> This implies that in the bit error case above, since B can't tell the
> difference between a bit error and the case when it has lost/discarded
> the state, B needs to at least send an error message to A saying "I  
> have
> no matching shim6 context".
> But B probably shouldn't do any more than this, since it doesn't  
> know whether
> the cause was a bit error or it having lost/discarded the shim6 state.

Right.

Or a DoS.

> So in conclusion, if we don't have a checksum for the shim6 context  
> tag, then
> we are constrained on what the shim can do when receiving a packet for
> which it has no matching context.

Is there any other action that you would like to see taken that can't  
be without a checksum?

BTW if we're just worried about single bit errors you don't need a 16  
bit checksum for this. Even a parity bit will find single flipped  
bits without fail. A very short CRC may be a good alternative.

Envelope-to: [email-masked]
Delivery-date: Thu, 05 May 2005 08:11:22 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6 <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Thu, 05 May 2005 10:10:38 +0200

 In your previous mail you wrote:

   I fail to understand your conclusion here:
   
=> Have you read my previous messages?

   the mechanism describe by Greg and Erik seem to be compliant with 
   RFC3697 to me...

=> don't joke: there can not be two different simultaneous uses of
flow labels, so if you'll use flow labels for shim6, you'll remove
any possible use, including the unspecified QoS stuff (called flow
state establishment and related service in RFC 3697). This is why
I used the word "real" for compliance: not only the text of RFC 3697
matters, but the spirit also and you can't argue any proposal using
flow labels for shim6 will be compatible with any proposal using
flow labels for QoS as soon as it is RFC 3697 compliant...

   I mean, in this approach the flow label used for a exchanging packets 
   with a given src and dst addresses remains constant during the lifetime 
   of the communication, so could you point out exactly which part of 
   RFC3697 they are not compliant with?
   
=> I've considered only approachs which fulfill some requirements:
 - shim6 negociation during communication (vs. before communication)
 - mobility (i.e., unpredictable address) support.
(parts of what I called shim6 goals)

Regards

[email-masked]

Delivery-date: Thu, 05 May 2005 05:55:04 +0000
Date: Thu, 05 May 2005 15:53:49 +1000
From: Greg Daley <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers
To: Erik Nordmark <[email-masked]>
Cc: shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

I like the general trend, but I'd like to raise some ideas...

Erik Nordmark wrote:
[cut]
> 
> If there is a bit error in B2 (turning it into B2') the packets wouldn't be
> delivered to the host B, but they might be delivered to a different 
> host, which would presumably(??), not have any context state for <A1, B2', CT>.
> If it does have such shim6 state, it would apply the ULID replacement from
> that context state and pass the packet to the ULP. The ULP checksum 
> would most likely fail in this case.

In some circumstances, there may be a port unreachable response before
the checksum is even consulted (UDP-Lite).

If UDP checks checksums after port occupancy, I guess port-unreachables
could be sent instead of silent discards (don't think this will happen).

> This doesn't seem any different than the case in base IPv6 and a bit error
> in the destination address field; we rely on the ULP checksum to discard 
> such
> packets.
> 
> If there is a bit error in A1 or CT, the packet would be delivered to B,
> but most likely B would not have any context state which matches <A1', 
> B2, CT>
> or <A1, B2, CT'>. If there is matching context state, the argument above
> about the ULP checksum applies.
> When there is no matching context state at B, the question is what B
> does in such a case.
> 
> This is a function of how we do state management in shim6. There has been
> little discussion about this. We could do soft state, where there is no
> explicit taredown/close message, or we could do something which tries to
> tare down the state at the both ends in a coordinated fashion.
> 
> If we assume that we do soft state management, then a host like B needs to
> be prepared to receive shim6 packets where it has no context. This is
> because B might have discarded the shim6 state before A did, or B might
> have crashes and lost all state while A retained the shim6 state.
> 
> This implies that in the bit error case above, since B can't tell the
> difference between a bit error and the case when it has lost/discarded
> the state, B needs to at least send an error message to A saying "I have
> no matching shim6 context".

I believe that there's a chance of additional responding port
unreachables or resets for flows which match but do not have upper layer
sessions for the flow (since it is tied to different IP addresses).

In most cases, any ICMPv6 errors or TCP resets will be sent to a port
which isn't expecting feedback of this sort...

It's worth finding out how important this is, though.
Most errors aren't single bit errors, and we're assuming that there's
a problem just in the context tag.

> But B probably shouldn't do any more than this, since it doesn't know 
> whether
> the cause was a bit error or it having lost/discarded the shim6 state.
> 
> [Note that B can't just silently pass up such packets to the ULP, because
> if B doesn't do the locator->ULID replacement, the packets will (most 
> likely)
> be dropped by the ULP to to a checksum error. Thus there would *not* be 
> e.g.,
> a TCP reset which would tell the peer ULP to restart.]
> 
> So in conclusion, if we don't have a checksum for the shim6 context tag, 
> then
> we are constrained on what the shim can do when receiving a packet for
> which it has no matching context.
> 
> If we add a checksum (covering at least the source locator, destination
> locator, and context tag), then the receiving shim6 layer can silently 
> discard
> packets with bit errors, and we have the flexibility to do something
> different in order to recover from lost/discarded state at the
> receiver
> Comments?
>     Erik
> 
> 
> But B probably shouldn't do any more than this, since it doesn't know 
> whether
> the cause was a bit error or it having lost/discarded the shim6 state.

Loss of shim state is possible if a signaling packet gets lost or
reordered.  We don't necessarily want to tell the source that there's
a problem if the next packet is a signaling packet retry.

Greg

Delivery-date: Wed, 04 May 2005 23:38:20 +0000
Date: Thu, 05 May 2005 09:37:11 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: marcelo bagnulo braun <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, Francis Dupont <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Marcelo,

marcelo bagnulo braun wrote:
[cut]
>>
>>
>> Yes, this is the case.  If the existing 3697 (sender side) allocation
>> for flow labels is used, then explicit signaling to add each
>> <source,dest,label> to a multihoming context has to precede packet
>> delivery.
>>
> 
> Maybe i am missing something here, but this is the case, independently 
> of the mechanisms you choose to carry the context tag, because of 
> security issues....
> 
> I mean when a node is adding a new locator into an established shim 
> context, it must send an explicity message, informing of that new 
> locator and including security information in order to validate this new 
> locator. In this exchange used to add and verify the new locator, the 
> receiver could inform the transmitter about the new flow label value (if 
> needed)
> 
> So i would say that explicit signaling when adding a new locator is 
> always needed.

Yes, it's always needed, but the time ordering of the packets to do
the signalling may not be strict.

If the upper layer protocol is ESP with authentication (or AH), for
example, it will be possible to identify that the flow belongs to an
upper-layer data stream because of the SPI, and the fact that the
packet authenticates using the right HMAC.

This may not be palatable to all, but the possibility is there
(and may be dismissed later).

Packets sent before the signaling wouldn't be guaranteed to get
through, but if the actual signaling took computation time
(or a longer, reliable signaling path), this is an optimization
which would work well for some data.

Please note that if strict ordering of signaling before packet
arrival is required, then receiver side flow label allocation
isn't required itself for ensuring decodability just based on
the IPv6 header.  Only unique-to-sender label allocation is
needed to avoid label collision, since no label selected on the
host will collide with its own (going to any of its destinations),
and the <source, label> pair is sufficient to identify it
to the receiver.

> a possible question would be if it would be possible to include the 
> signalling in the same packet that carry the new locator as source 
> address... i guess this depends on how you define the packet processing, 
> but i guess it may be possible in any case.

I'm not really fond of piggybacking data.

It's possible of course but has potential issues with MTU.

Separate signaling is also much easier to describe and
implement.

Greg

Delivery-date: Wed, 04 May 2005 15:29:47 +0000
Cc: shim6 <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Wed, 4 May 2005 17:29:37 +0200
To: Francis Dupont <[email-masked]>

Hi Francis,

I fail to understand your conclusion here:

the mechanism describe by Greg and Erik seem to be compliant with=20
RFC3697 to me...
I mean, in this approach the flow label used for a exchanging packets=20
with a given src and dst addresses remains constant during the lifetime=20=

of the communication, so could you point out exactly which part of=20
RFC3697 they are not compliant with?

thanks, marcelo

El 04/05/2005, a las 11:22, Francis Dupont escribi=F3:

> The point I'd like to make (and about which we should agree) is that
> it is hard or impossible to keep full/real RFC 3697 compliance and
> shim6 goal support, so if we decide to follow the flow label way the
> best is to obsolete the RFC 3697 and to reserve the 20 bit field
> currently named flow label to shim6 usage.
>
> Regards
>
> [email-masked]
>

Delivery-date: Wed, 04 May 2005 15:22:36 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, Francis Dupont <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Wed, 4 May 2005 17:22:31 +0200
To: [email-masked]

Hi Greg,

El 04/05/2005, a las 3:00, Greg Daley escribi=F3:

> Hi Francis,
>
> Francis Dupont wrote:
>>  In your previous mail you wrote:
>>    Sorry to keep returning to this point.
>>    =3D> so I return to my main concern too..
>>    I'm not sure that this is necessary (changing 3697) or even=20
>> desirable,
>>    even for proponents of flow-label-as-shim6.
>>    =3D> if we keep full 3697 compliance, the only thing we can do is =
to
>> improve the flow label allocation in the shim6-capable sending node,
>> mainly making them looking as unique (easy with less than 10^10
>> concurrent comminucations which should be the common case).
>>  But what happens between two different sending nodes communicating
>> with the same receiver? They can use the same flow label value and
>> the same destination address: the receiver can distinguish between=20
>> them
>> only with the source address. This works with multi-homing because
>> the lists of possible addresses per sender are known and do not share
>> a value, but this does not work with mobility where the next source
>> address is not predictable.
>>  So IMHO RFC 3697 is not compatible with mobility when destination
>> options have no problem at all...
>
> Yes, this is the case.  If the existing 3697 (sender side) allocation
> for flow labels is used, then explicit signaling to add each
> <source,dest,label> to a multihoming context has to precede packet
> delivery.
>

Maybe i am missing something here, but this is the case, independently=20=

of the mechanisms you choose to carry the context tag, because of=20
security issues....

I mean when a node is adding a new locator into an established shim=20
context, it must send an explicity message, informing of that new=20
locator and including security information in order to validate this=20
new locator. In this exchange used to add and verify the new locator,=20
the receiver could inform the transmitter about the new flow label=20
value (if needed)

So i would say that explicit signaling when adding a new locator is=20
always needed.

a possible question would be if it would be possible to include the=20
signalling in the same packet that carry the new locator as source=20
address... i guess this depends on how you define the packet=20
processing, but i guess it may be possible in any case.

regards, marcelo

> So it is possible, but has undesirable properties.
>
> The receiver based allocation scheme doesn't have this problem,
> and preserves RFC3697 compliance on the originally homed path.
>
>>    Within the sender and receiver host, receiver side allocation
>>    causes some complexity, which may interfere with future uses
>>    (I guess it would be predictable though).
>>    =3D> IMHO the main issue with a receiver allocation of flow labels
>> is this won't work at all with not-shim6-capable nodes, i.e.,
>> there shall be a major interoperability issue with legacy nodes...
>
> Yes, but only with not-shim6-capable hosts.  There is no problem
> with routers, if the new labels are used in the same way as
> RFC3697 labels on the new paths (and old paths are unmodified).
>
> The not-shim6-capable hosts won't be doing multihoming anyway, and
> won't understand a new destination option, let alone a new
> extension header.
>
> Thanks for your patience.
>
> Greg
>

Delivery-date: Wed, 04 May 2005 15:08:07 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 and bit errors in data packet headers
Date: Wed, 4 May 2005 17:07:45 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

some comments below...

El 04/05/2005, a las 1:33, Erik Nordmark escribi=F3:

>
...
>
> For the part of shim6 which performs the state exchange, locator=20
> changes, and
> testing the paths, presumably it is easy to just add the regular 16 =
bit
> checksum.
>

I am not sure about this yet... i mean for the initial exchange where=20
the alternative locators are exchanged, the security mechanisms that=20
are in place would be enough to deal with bit error i guess. I mean, if=20=

there is an error in a bit of the locator, it would be similar than if=20=

an attacker has tried to include a different address in the context i=20
think. I guess that the question is what to do when the security check=20=

fails...

But in any case, i also agree that it wouldn't be much problem to add a=20=

checksum in those packets, since they are few of them. I guess we could=20=

do a more in depth analysis of this once that we have a clear view of=20
what information would be included in this packet exchange. (for=20
instance an error in the messages that informs about the context tag=20
selected for that context may cause problems, i guess)

> But for the data packets adding one more 16 bit checksum would be more=20=

> costly,
> since if we need it we can't use the flow label, and a destination=20
> option
> header would either be 16 bytes (an 8 byte destination option can only=20=

> hold
> 32 bits of payload, and a 16 bit checksum would imply only a 16 bit=20
> context
> tag, which is probably too small.)
>

agree

> Let's assume the receiver identifies the shim6 state based on the
> <source locator, destination locator, context tag>. This is done=20
> before the
> packet is passed to the ULP, that is, the ICMP/UDP/TCP/SCTP checksums
> are not of any use to detect a potentially corrupt packet.
>
> As an example, assume that A and B has established shim6 state for
> communication between ULID A1 and B1, using the locator sets
> <{A1, A2}, {B1, B2}>, and that the communication using <A1, B1> has=20
> failed
> so that things switches to the locator pair <A1, B2>.
>
> B will now receive packets with the shim identifying information
> being <A1, B2, CT>, which will identify the shim6 state and the state
> indicates that the ULIDs should be set to <A1, B1> before passing the=20=

> packet
> to the ULP.
>
> What happens if there is a bit error in the locators in the packet or=20=

> the
> context tag field? (Doesn't matter whether the context tag is carried=20=

> in
> the flow label field or somewhere else for this analysis).
>
> If there is a bit error in B2 (turning it into B2') the packets=20
> wouldn't be
> delivered to the host B, but they might be delivered to a different=20
> host, which
> would presumably(??), not have any context state for <A1, B2', CT>.
> If it does have such shim6 state, it would apply the ULID replacement=20=

> from
> that context state and pass the packet to the ULP. The ULP checksum=20
> would most
> likely fail in this case.
> This doesn't seem any different than the case in base IPv6 and a bit=20=

> error
> in the destination address field; we rely on the ULP checksum to=20
> discard such
> packets.
>
> If there is a bit error in A1 or CT, the packet would be delivered to=20=

> B,
> but most likely B would not have any context state which matches <A1',=20=

> B2, CT>
> or <A1, B2, CT'>. If there is matching context state, the argument=20
> above
> about the ULP checksum applies.
> When there is no matching context state at B, the question is what B
> does in such a case.
>
> This is a function of how we do state management in shim6. There has=20=

> been
> little discussion about this. We could do soft state, where there is =
no
> explicit taredown/close message, or we could do something which tries=20=

> to
> tare down the state at the both ends in a coordinated fashion.
>
> If we assume that we do soft state management, then a host like B=20
> needs to
> be prepared to receive shim6 packets where it has no context. This is
> because B might have discarded the shim6 state before A did, or B =
might
> have crashes and lost all state while A retained the shim6 state.
>
> This implies that in the bit error case above, since B can't tell the
> difference between a bit error and the case when it has lost/discarded
> the state, B needs to at least send an error message to A saying "I=20
> have
> no matching shim6 context".

why?
i would argue that silently discarding the packet would be enough. I=20
mean, i think that soft state approach is an interesting approach, but=20=

i would like to explore the possibility of silently discarding packets=20=

that don't match with any existent contexts. I mean, i think that (as i=20=

think you mentioned a while ago) defining a error message in order to=20
reply to those packets belonging to non existent contexts may introduce=20=

some security issues. In particular, it may allow an attacker to force=20=

to communicating end nodes to re-do the initial exchange, allowing the=20=

attacker to become a MiTM.

So i would think that not defining errors for non existent contexts may=20=

be a good option.

> But B probably shouldn't do any more than this, since it doesn't know=20=

> whether
> the cause was a bit error or it having lost/discarded the shim6 state.
>
> [Note that B can't just silently pass up such packets to the ULP,=20
> because
> if B doesn't do the locator->ULID replacement, the packets will (most=20=

> likely)
> be dropped by the ULP to to a checksum error. Thus there would *not*=20=

> be e.g.,
> a TCP reset which would tell the peer ULP to restart.]
>
> So in conclusion, if we don't have a checksum for the shim6 context=20
> tag, then
> we are constrained on what the shim can do when receiving a packet for
> which it has no matching context.
>
> If we add a checksum (covering at least the source locator, =
destination
> locator, and context tag), then the receiving shim6 layer can silently=20=

> discard
> packets with bit errors,
>  and we have the flexibility to do something
> different in order to recover from lost/discarded state at the
> receiver.
>
> Comments?
>     Erik
>
>
>
Regards, marcelo

PS: nice analysis, thanks

Envelope-to: [email-masked]
Delivery-date: Wed, 04 May 2005 13:23:12 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Wed, 04 May 2005 15:22:52 +0200

 In your previous mail you wrote:

   Er, with my flow label hat on, I don't think that is OK
   at all. Shim6 has no particular right to take over the
   Flow Label, any more than 6LSA does.
   
=> note that:
 - I've put an *if* at the critical place.
 - I've clearly stated I am in favor of the destination option.
I'll talk about 6LSA after...
   
Regards

[email-masked]
   
   Francis Dupont wrote:
   > The point I'd like to make (and about which we should agree) is that
   > it is hard or impossible to keep full/real RFC 3697 compliance and
   > shim6 goal support, so if we decide to follow the flow label way the
                            ^^
   > best is to obsolete the RFC 3697 and to reserve the 20 bit field
   > currently named flow label to shim6 usage.

Delivery-date: Wed, 04 May 2005 12:57:34 +0000
Date: Wed, 04 May 2005 14:56:00 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Francis Dupont <[email-masked]>
CC: [email-masked], Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Er, with my flow label hat on, I don't think that is OK
at all. Shim6 has no particular right to take over the
Flow Label, any more than 6LSA does.

     Brian

Francis Dupont wrote:
> The point I'd like to make (and about which we should agree) is that
> it is hard or impossible to keep full/real RFC 3697 compliance and
> shim6 goal support, so if we decide to follow the flow label way the
> best is to obsolete the RFC 3697 and to reserve the 20 bit field
> currently named flow label to shim6 usage.
> 
> Regards
> 
> [email-masked]
> 

Envelope-to: [email-masked]
Delivery-date: Wed, 04 May 2005 09:23:23 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Wed, 04 May 2005 11:22:49 +0200

The point I'd like to make (and about which we should agree) is that
it is hard or impossible to keep full/real RFC 3697 compliance and
shim6 goal support, so if we decide to follow the flow label way the
best is to obsolete the RFC 3697 and to reserve the 20 bit field
currently named flow label to shim6 usage.

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Wed, 04 May 2005 08:36:11 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Wed, 04 May 2005 10:35:50 +0200

 In your previous mail you wrote:

   Dealing with the same header for different purposes in different places 
   in the header sequence doesn't make an implementation easier.

=> the price has been already paid for Mobile IPv6...

   So while 
   this might be viewed as conceptually simple, and implementation needs to 
   verify that a particular option (such as the MIPv6 one) is not present 
   in the wrong "type" (aka "placement") of destination option.
   
=> note this check will be needed by an extension header too.

   To me this,

=> this (extra complexity) should be only a matter of taste if you
accept by counter-arguments.

   and the additional 2 byte overhead for destination options 

=> there will be no real overhead if the proposed extension header
will be 8 byte aligned and the tag length a power of two.

   compared to a new extension header, means that I rank a new extension 
   header better than defining a new destination option.

=> how do you address my concern about new extension header handling
(BTW more not handling :-) by classifiers/filters/etc?

   But I still want to explore the hybrid receiver-based allocation of flow 
   labels, that Greg suggested, more.
   
=> if we are ready for a major change in IPv6 specs the flow label way
is the best, and BTW has no issue with middleboxes or legacy (if there
is no unknown deployed use of flow labels?).

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Wed, 04 May 2005 08:07:24 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Wed, 04 May 2005 10:06:53 +0200

 In your previous mail you wrote:

   > => yes, this is what I believe.
   
   Well, I find that unacceptable. If you and other people feel this  
   strongly, we need to do something about RFC 2460 so it becomes  
   possible to add new extension headers more easily.
   
=> it seems you don't understand the power of IETF: if to publish a
document is enough to enforce something, why not bannish NATs?

   >    Since in this case the only problem that they have is that they  
   > won't
   >    be able to use the new feature (shim6 multihoming) I don't see why
   >    this should be a problem at all.
   
   > => perhaps you should consider the difference between a host and a  
   > router?
   
   Is there a difference?  :-)
   
=> for this discussion yes, shim6 will be implemented into end nodes,
and my concern is about routers and middleboxes.

   There is no requirement that routers be able to parse the entire  
   protocol chain for all packets they forward.
   
=> in fact IMHO they should not... but it is not reasonnable to
ignore classifiers and all kinds of filters.

   >    And since only a tiny percentage of all users has IPv6 in the first
   >    place and a tiny percentage of those users has a firewall, I really
   >    fail to see the problem.
   
   > => you are considering IPv6 as a toy (worse, as your toy) (:-)!
   
   Nope, certainly not. I actually make some money with IPv6. Not a lot,  
   but enough to take it seriously.
   
=> so you should understand that breaking already deployed networks will
cost money and delays.

   But since there isn't a huge installed base we still have the  
   opportunity to "do the right thing"

=> we still have no consensus about what is the right thing, and
only one proposal has clearly a deployment issue...

   even if it's inconvenient for currently deployed systems, because
   the number of such systems is still limited.

=> so we should put the destination address before the source one
in the IPv6 header (to fix a clear mistake of IPv6) too? Even
Steve Deering gave up about this many years ago...
BTW one of the goals of SHIM6 is to be deployed in a reasonnable
time scale, isn't it?
   
   >    The trouble with a destination option is that you need to spend 8
   >    bytes so you get a 4 byte payload, and the possibility of having
   >    multiple destination options that need to be in different places in
   >    the protocol chain is just asking for nasty bugs.
   
   > => so Mobile IPv6 should not work?
   
   Not sure what you mean.

=> Mobile IPv6 uses a destination option at a not-standard-at-its-time place.

   I have no first hand knowledge that MIPv6  
   indeed works, nor do I have a great desire to see it work, because I  
   don't believe it fills much of a need. But obviously mechanisms that  
   use destination options CAN work. It's just that in my opinion,  
   having a destination option costs more in overhead (2 extra bytes)  

=> this overhead is an illusion if the shim6 extension header is 8-byte
aligned and the tag size a power of two...

   and complexity

=> don't joke: destination options are not so complex!

   than it saves in compatibility and potential to save  
   overhead by having more than one option in the header.
   
=> IMHO the main advantage of a destination option is the action about
an unknown one is already known (and encoded into its type), when
the action about an unknown extension header is not or unfortunately
restricted to drop the packet...

   >    Also, we need two
   >    other mechanisms (reachability detection and capability/security
   >    negotiation) that aren't naturally suited to being destination
   
   > => they are not end-to-end?
   
   In most cases they will be. (It should be possible to implement the  
   shim in middleboxes.) However, the reachability detection and  
   negotiation packets will generally not carry higher-layer data so  
   then there would be a destination option as sole payload,

=> piggy-backing or not again... Seriously you should look at the
discussion about this in Mobile IPv6 which, BTW, opened the path
(cf RFC2401bis for instance).

Regards

[email-masked]

Delivery-date: Wed, 04 May 2005 06:34:46 +0000
Date: Wed, 04 May 2005 16:32:29 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Iljitsch van Beijnum <[email-masked]>
Cc: Francis Dupont <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Iljitsch,

Iljitsch van Beijnum wrote:
[chop]
>> => they are not end-to-end?
> 
> 
> In most cases they will be. (It should be possible to implement the  
> shim in middleboxes.) However, the reachability detection and  
> negotiation packets will generally not carry higher-layer data so  then 
> there would be a destination option as sole payload, or we'd  have to 
> use another protocol (UDP?) to implement parts of the shim,  creating 
> the opportunity for some shim packets to pass filters and  some to be 
> blocked, which is a headache.

Please, Please let's not go there!

I don't think changing packets by insertion of headers unbeknownst
to the host is a good idea.

Even with the knowledge of the edge device, it's better not to have
these modifications by the network.

I didn't even think Routing Headers (Type 0 or IPv4) were a good idea.

A clever hack, but not a good idea.

Lets leave the source routing to the end devices and MPLS!

Greg

Delivery-date: Wed, 04 May 2005 03:36:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Firewall "uniformity" issue
Date: Wed, 4 May 2005 06:32:28 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Erik,

> > If we want end-to-end options to not be blocked by firewalls, the =
best
> > solution is to encrypt them. That is, run shim6 inside IPSEC, end to
> > end.
>=20
> FWIW I've visited "visitor networks" where UDP port 500 (IKE) was=20
> blocked. So it it is a goal to sneak through any firewall, I think we=20
> need to make the protocol look like a http get for www.cnn.com's front =

> page, (or some other innocuous site that isn't likely to be blocked).
>=20
> But can we please not solve that problem in the shim6 WG; I think it =
is=20
> out of scope.

FWIW, I agree.  Designing SHIM6 to work in reasonable cases should be
the goal; if a network admin really wants to block traffic, even
IPsec can/will be blocked.

See =
http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-04.txt=

for a discussion of different IP connectivity types. =20

I don't think we can say that SHIM6 can work in all of them.

John

Delivery-date: Wed, 04 May 2005 01:00:37 +0000
Date: Wed, 04 May 2005 11:00:21 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Francis Dupont <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Francis,

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    Sorry to keep returning to this point.
>    
> => so I return to my main concern too..
> 
>    I'm not sure that this is necessary (changing 3697) or even desirable,
>    even for proponents of flow-label-as-shim6.
>    
> => if we keep full 3697 compliance, the only thing we can do is to
> improve the flow label allocation in the shim6-capable sending node,
> mainly making them looking as unique (easy with less than 10^10
> concurrent comminucations which should be the common case).
>  But what happens between two different sending nodes communicating
> with the same receiver? They can use the same flow label value and
> the same destination address: the receiver can distinguish between them
> only with the source address. This works with multi-homing because
> the lists of possible addresses per sender are known and do not share
> a value, but this does not work with mobility where the next source
> address is not predictable.
>  So IMHO RFC 3697 is not compatible with mobility when destination
> options have no problem at all...

Yes, this is the case.  If the existing 3697 (sender side) allocation
for flow labels is used, then explicit signaling to add each
<source,dest,label> to a multihoming context has to precede packet
delivery.

So it is possible, but has undesirable properties.

The receiver based allocation scheme doesn't have this problem,
and preserves RFC3697 compliance on the originally homed path.

>    Within the sender and receiver host, receiver side allocation
>    causes some complexity, which may interfere with future uses
>    (I guess it would be predictable though).
>    
> => IMHO the main issue with a receiver allocation of flow labels
> is this won't work at all with not-shim6-capable nodes, i.e.,
> there shall be a major interoperability issue with legacy nodes...

Yes, but only with not-shim6-capable hosts.  There is no problem
with routers, if the new labels are used in the same way as
RFC3697 labels on the new paths (and old paths are unmodified).

The not-shim6-capable hosts won't be doing multihoming anyway, and
won't understand a new destination option, let alone a new
extension header.

Thanks for your patience.

Greg

Delivery-date: Wed, 04 May 2005 00:36:32 +0000
Date: Wed, 04 May 2005 10:34:54 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Erik Nordmark <[email-masked]>
Cc: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

Erik Nordmark wrote:
[cut]
> 
>>> And when switching to a different locator pair, and some flow 
>>> signaling is used, one would need to do the flow signaling for that 
>>> locator pair in any case. So using a different flow label for the 
>>> different locator pair shouldn't be much of an issue.
>>
>>
>>
>> I guess you'd only want to do the signalling when you had to:
>>
>> You wouldn't want to require signalling (or a new label)
>> for every locator pair change, if the label was receiver unique.
> 
> 
> By "signaling" I was referring to things like RSVP and NSIS. Those would 
> need to be triggered for every new <source IP, dest IP, flow label> 
> combination that needs whatever QoS is used. Thus if such protocols are 
> used before there is a change to a different locator pair, they would 
> need to be triggered for every new locator pair that is used for that 
> communication. And there doesn't seem to be a need to use the same flow 
> label across those reservations.

Indeed.

Since the device is on a new path, passing the receiver allocated
flow-label to the path signalling system would probably work OK.
If it doesn't, the sender will allocate a label (maybe the original
label from the original path), and it will be added to the set.

Where new labels are chosen, the <source IP, dest IP, flow label>
will need to be signalled to the peer before packets begin to use the
path (which may be OK, considering the order of the operations detailed
above).

Greg

Delivery-date: Tue, 03 May 2005 23:40:00 +0000
Date: Tue, 03 May 2005 16:39:46 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Greg Daley wrote:

> Yes, I was thinking that some APIs may allow explicit access to flow
> labels (perhaps as RFC3542bis), or a separate extension of to the
> advanced sockets API (new socket options?)
> 
> The constant flow label would be required in this case, as it could
> have particular semantics with the ULP or application.

Yep.

>> And when switching to a different locator pair, and some flow 
>> signaling is used, one would need to do the flow signaling for that 
>> locator pair in any case. So using a different flow label for the 
>> different locator pair shouldn't be much of an issue.
> 
> 
> I guess you'd only want to do the signalling when you had to:
> 
> You wouldn't want to require signalling (or a new label)
> for every locator pair change, if the label was receiver unique.

By "signaling" I was referring to things like RSVP and NSIS. Those would 
need to be triggered for every new <source IP, dest IP, flow label> 
combination that needs whatever QoS is used. Thus if such protocols are 
used before there is a change to a different locator pair, they would 
need to be triggered for every new locator pair that is used for that 
communication. And there doesn't seem to be a need to use the same flow 
label across those reservations.

    Erik

Delivery-date: Tue, 03 May 2005 23:33:33 +0000
Date: Tue, 03 May 2005 16:33:11 -0700
From: Erik Nordmark <[email-masked]>
To: Francis Dupont <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Francis Dupont wrote:

>    The trouble with a destination option is that you need to spend 8  
>    bytes so you get a 4 byte payload, and the possibility of having  
>    multiple destination options that need to be in different places in  
>    the protocol chain is just asking for nasty bugs.
> 
> => so Mobile IPv6 should not work?

Part of the complexity with destinations options is that they can appear 
in multiple places. RFC 2460 says that this is the order an 
implementation must support:

            IPv6 header
            Hop-by-Hop Options header
            Destination Options header (note 1)
            Routing header
            Fragment header
            Authentication header (note 2)
            Encapsulating Security Payload header (note 2)
            Destination Options header (note 3)
            upper-layer header

Mobile IPv6 then added a need for a destination options header in a 3rd 
place; between the routing header and the fragment header in the above list.

Dealing with the same header for different purposes in different places 
in the header sequence doesn't make an implementation easier. So while 
this might be viewed as conceptually simple, and implementation needs to 
verify that a particular option (such as the MIPv6 one) is not present 
in the wrong "type" (aka "placement") of destination option.

To me this, and the additional 2 byte overhead for destination options 
compared to a new extension header, means that I rank a new extension 
header better than defining a new destination option.
But I still want to explore the hybrid receiver-based allocation of flow 
labels, that Greg suggested, more.

    Erik

Delivery-date: Tue, 03 May 2005 23:33:33 +0000
Date: Tue, 03 May 2005 16:33:32 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: shim6 and bit errors in data packet headers

One issue we haven't discussed is what happens when there is a bit error
in the shim information, and whether a checksum is needed on the shim
information.

For the IPv6 header there was a case analysis for all the header fields
to determine what would happen if there was a bit error in the field.
The result (as I recall it) is that not much bad happens.
Bit errors can cause the packet to fail the ULP checksum and be silently
dropped as a result, cause the routers to send an ICMP error (because the
IPv6 destination with the error in it is unreachable) etc.

We need to do the same type of analysis for the shim6 protocol, but we can
also adjust the design of the protocol to make sure bit errors don't have
a detrimental effect.

For the part of shim6 which performs the state exchange, locator 
changes, and
testing the paths, presumably it is easy to just add the regular 16 bit
checksum.

But for the data packets adding one more 16 bit checksum would be more 
costly,
since if we need it we can't use the flow label, and a destination option
header would either be 16 bytes (an 8 byte destination option can only hold
32 bits of payload, and a 16 bit checksum would imply only a 16 bit context
tag, which is probably too small.)

Let's assume the receiver identifies the shim6 state based on the
<source locator, destination locator, context tag>. This is done before the
packet is passed to the ULP, that is, the ICMP/UDP/TCP/SCTP checksums
are not of any use to detect a potentially corrupt packet.

As an example, assume that A and B has established shim6 state for
communication between ULID A1 and B1, using the locator sets
<{A1, A2}, {B1, B2}>, and that the communication using <A1, B1> has failed
so that things switches to the locator pair <A1, B2>.

B will now receive packets with the shim identifying information
being <A1, B2, CT>, which will identify the shim6 state and the state
indicates that the ULIDs should be set to <A1, B1> before passing the packet
to the ULP.

What happens if there is a bit error in the locators in the packet or the
context tag field? (Doesn't matter whether the context tag is carried in
the flow label field or somewhere else for this analysis).

If there is a bit error in B2 (turning it into B2') the packets wouldn't be
delivered to the host B, but they might be delivered to a different 
host, which
would presumably(??), not have any context state for <A1, B2', CT>.
If it does have such shim6 state, it would apply the ULID replacement from
that context state and pass the packet to the ULP. The ULP checksum 
would most
likely fail in this case.
This doesn't seem any different than the case in base IPv6 and a bit error
in the destination address field; we rely on the ULP checksum to discard 
such
packets.

If there is a bit error in A1 or CT, the packet would be delivered to B,
but most likely B would not have any context state which matches <A1', 
B2, CT>
or <A1, B2, CT'>. If there is matching context state, the argument above
about the ULP checksum applies.
When there is no matching context state at B, the question is what B
does in such a case.

This is a function of how we do state management in shim6. There has been
little discussion about this. We could do soft state, where there is no
explicit taredown/close message, or we could do something which tries to
tare down the state at the both ends in a coordinated fashion.

If we assume that we do soft state management, then a host like B needs to
be prepared to receive shim6 packets where it has no context. This is
because B might have discarded the shim6 state before A did, or B might
have crashes and lost all state while A retained the shim6 state.

This implies that in the bit error case above, since B can't tell the
difference between a bit error and the case when it has lost/discarded
the state, B needs to at least send an error message to A saying "I have
no matching shim6 context".
But B probably shouldn't do any more than this, since it doesn't know 
whether
the cause was a bit error or it having lost/discarded the shim6 state.

[Note that B can't just silently pass up such packets to the ULP, because
if B doesn't do the locator->ULID replacement, the packets will (most 
likely)
be dropped by the ULP to to a checksum error. Thus there would *not* be 
e.g.,
a TCP reset which would tell the peer ULP to restart.]

So in conclusion, if we don't have a checksum for the shim6 context tag, 
then
we are constrained on what the shim can do when receiving a packet for
which it has no matching context.

If we add a checksum (covering at least the source locator, destination
locator, and context tag), then the receiving shim6 layer can silently 
discard
packets with bit errors, and we have the flexibility to do something
different in order to recover from lost/discarded state at the
receiver.

Comments?
     Erik

Delivery-date: Tue, 03 May 2005 23:13:47 +0000
Date: Tue, 03 May 2005 16:12:56 -0700
From: Erik Nordmark <[email-masked]>
To: Christian Huitema <[email-masked]>
CC: Francis Dupont <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Firewall "uniformity" issue

Christian Huitema wrote:
>>   > Of course, once there are shim6 aware firewalls, we don't know
> 
> how
> 
>>   > they will behave. But we could at least recommend that they take
>>   > this issue into consideration, by recommending
>>   > 1) that they not block shim6 by default, but instead look at the
>>   > carried (TCP, UDP, etc) payload
> 
> 
> You may ask firewall admins to "please not block shim6". You may even
> shout from the hill tops. Whether they will heed your advice is
> anybody's guess. After all, these are the same folks who routinely block
> ICMP. 

I was pretty leery about adding the above text to the message, since I 
feared it would detract from the topic of the uniformity of firewall 
handling of the shim6 control messages and the data messages.

Either that part of my message was utterly non-controversial, or my fear 
was to the point :-)

> If we want end-to-end options to not be blocked by firewalls, the best
> solution is to encrypt them. That is, run shim6 inside IPSEC, end to
> end.

FWIW I've visited "visitor networks" where UDP port 500 (IKE) was 
blocked. So it it is a goal to sneak through any firewall, I think we 
need to make the protocol look like a http get for www.cnn.com's front 
page, (or some other innocuous site that isn't likely to be blocked).

But can we please not solve that problem in the shim6 WG; I think it is 
out of scope.

    Erik

Delivery-date: Tue, 03 May 2005 19:35:25 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Tue, 3 May 2005 21:34:50 +0200
To: Francis Dupont <[email-masked]>

On 3-mei-2005, at 12:14, Francis Dupont wrote:

>    So basically what you're saying is that we need to have a  
> moratorium
>    on new extension headers just because SOME hard/software used by  
> SOME
>    people may not support it.

> => yes, this is what I believe.

Well, I find that unacceptable. If you and other people feel this  
strongly, we need to do something about RFC 2460 so it becomes  
possible to add new extension headers more easily.

>    Since in this case the only problem that they have is that they  
> won't
>    be able to use the new feature (shim6 multihoming) I don't see why
>    this should be a problem at all.

> => perhaps you should consider the difference between a host and a  
> router?

Is there a difference?  :-)

There is no requirement that routers be able to parse the entire  
protocol chain for all packets they forward.

>    And since only a tiny percentage of all users has IPv6 in the first
>    place and a tiny percentage of those users has a firewall, I really
>    fail to see the problem.

> => you are considering IPv6 as a toy (worse, as your toy) (:-)!

Nope, certainly not. I actually make some money with IPv6. Not a lot,  
but enough to take it seriously.

But since there isn't a huge installed base we still have the  
opportunity to "do the right thing" even if it's inconvenient for  
currently deployed systems, because the number of such systems is  
still limited.

>    The trouble with a destination option is that you need to spend 8
>    bytes so you get a 4 byte payload, and the possibility of having
>    multiple destination options that need to be in different places in
>    the protocol chain is just asking for nasty bugs.

> => so Mobile IPv6 should not work?

Not sure what you mean. I have no first hand knowledge that MIPv6  
indeed works, nor do I have a great desire to see it work, because I  
don't believe it fills much of a need. But obviously mechanisms that  
use destination options CAN work. It's just that in my opinion,  
having a destination option costs more in overhead (2 extra bytes)  
and complexity than it saves in compatibility and potential to save  
overhead by having more than one option in the header.

>    Also, we need two
>    other mechanisms (reachability detection and capability/security
>    negotiation) that aren't naturally suited to being destination

> => they are not end-to-end?

In most cases they will be. (It should be possible to implement the  
shim in middleboxes.) However, the reachability detection and  
negotiation packets will generally not carry higher-layer data so  
then there would be a destination option as sole payload, or we'd  
have to use another protocol (UDP?) to implement parts of the shim,  
creating the opportunity for some shim packets to pass filters and  
some to be blocked, which is a headache.

>    options but could very well live in the same extension header as a
>    demux option.

> => I don't buy this argument!

We'll have to disagree then.

Delivery-date: Tue, 03 May 2005 10:41:14 +0000
Date: Tue, 03 May 2005 12:40:26 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Christian Huitema <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Firewall "uniformity" issue

Iljitsch van Beijnum wrote:
> On 3-mei-2005, at 4:14, Christian Huitema wrote:
> 
>> If we want end-to-end options to not be blocked by firewalls, the best
>> solution is to encrypt them. That is, run shim6 inside IPSEC, end to
>> end.
> 
> 
> Say hello to key management...
> 
> I think trying to second-guess firewall admins is the wrong thing to  
> do. If they want to block shim6, why should we try to sneak by them?
> 
> If the initial shim6 packet gets back some kind of ICMP unreachable  or 
> after several retransmissions there ins't an answer, we can just  
> continue to operate in backward compatibility mode without any loss  in 
> connectivity. (Until there is a failure, of course.)

On the "do no harm" principle, we should ensure that even if a firewall
drops shim6 traffic, at least monohoming will continue to work (i.e. the
original locator pair can still be used as long as there is connectivity).

    Brian

Envelope-to: [email-masked]
Delivery-date: Tue, 03 May 2005 10:15:13 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Tue, 03 May 2005 12:14:58 +0200

 In your previous mail you wrote:

   > => I am sorry but I believe to propose major changes in IPv6 is no  
   > more
   > a good idea today. Perhaps you have a little deployment where you are
   > but don't expect it is the case everywhere...
   
   So basically what you're saying is that we need to have a moratorium  
   on new extension headers just because SOME hard/software used by SOME  
   people may not support it.
   
=> yes, this is what I believe.

   Since in this case the only problem that they have is that they won't  
   be able to use the new feature (shim6 multihoming) I don't see why  
   this should be a problem at all.

=> perhaps you should consider the difference between a host and a router?

   Either upgrade or be single homed.

=> you suppose that everybody has the choice of his ISP...

   And since only a tiny percentage of all users has IPv6 in the first  
   place and a tiny percentage of those users has a firewall, I really  
   fail to see the problem.
   
=> you are considering IPv6 as a toy (worse, as your toy) (:-)!

   The trouble with a destination option is that you need to spend 8  
   bytes so you get a 4 byte payload, and the possibility of having  
   multiple destination options that need to be in different places in  
   the protocol chain is just asking for nasty bugs.

=> so Mobile IPv6 should not work?

   Also, we need two  
   other mechanisms (reachability detection and capability/security  
   negotiation) that aren't naturally suited to being destination  

=> they are not end-to-end?

   options but could very well live in the same extension header as a  
   demux option.
   
=> I don't buy this argument!

Regards

[email-masked]

Delivery-date: Tue, 03 May 2005 09:53:48 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Firewall "uniformity" issue 
Date: Tue, 3 May 2005 11:53:39 +0200
To: Christian Huitema <[email-masked]>

On 3-mei-2005, at 4:14, Christian Huitema wrote:

> If we want end-to-end options to not be blocked by firewalls, the best
> solution is to encrypt them. That is, run shim6 inside IPSEC, end to
> end.

Say hello to key management...

I think trying to second-guess firewall admins is the wrong thing to  
do. If they want to block shim6, why should we try to sneak by them?

If the initial shim6 packet gets back some kind of ICMP unreachable  
or after several retransmissions there ins't an answer, we can just  
continue to operate in backward compatibility mode without any loss  
in connectivity. (Until there is a failure, of course.)

Delivery-date: Tue, 03 May 2005 09:49:53 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Tue, 3 May 2005 11:49:05 +0200
To: Francis Dupont <[email-masked]>

On 2-mei-2005, at 11:53, Francis Dupont wrote:

>> => basically as there is no way to deal with a new extension header
>> without
>> modifying code or more, this will kill all the boxes which are  
>> looking
>> inside packets for good or less good reasons.

>    I don't think that in this stadium of IPv6 deployment this is that
>    huge a deal.

> => I am sorry but I believe to propose major changes in IPv6 is no  
> more
> a good idea today. Perhaps you have a little deployment where you are
> but don't expect it is the case everywhere...

So basically what you're saying is that we need to have a moratorium  
on new extension headers just because SOME hard/software used by SOME  
people may not support it.

Since in this case the only problem that they have is that they won't  
be able to use the new feature (shim6 multihoming) I don't see why  
this should be a problem at all. Either upgrade or be single homed.  
And since only a tiny percentage of all users has IPv6 in the first  
place and a tiny percentage of those users has a firewall, I really  
fail to see the problem.

>    pretty clear that using the flow label for demux can be
>    done without impact to other flow label use, at the cost of some
>    extra complexity when selecting the flow label for a new session.

> => but the flow label selection is already an essential part of
> RFC 3697.

So? How does what we're proposing to do with the flow label break RFC  
3697?

> PS: I still believe the best is a destination option.

The trouble with a destination option is that you need to spend 8  
bytes so you get a 4 byte payload, and the possibility of having  
multiple destination options that need to be in different places in  
the protocol chain is just asking for nasty bugs. Also, we need two  
other mechanisms (reachability detection and capability/security  
negotiation) that aren't naturally suited to being destination  
options but could very well live in the same extension header as a  
demux option.

Envelope-to: [email-masked]
Delivery-date: Tue, 03 May 2005 08:08:58 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Tue, 03 May 2005 10:08:11 +0200

 In your previous mail you wrote:

   Sorry to keep returning to this point.
   
=> so I return to my main concern too..

   I'm not sure that this is necessary (changing 3697) or even desirable,
   even for proponents of flow-label-as-shim6.
   
=> if we keep full 3697 compliance, the only thing we can do is to
improve the flow label allocation in the shim6-capable sending node,
mainly making them looking as unique (easy with less than 10^10
concurrent comminucations which should be the common case).
 But what happens between two different sending nodes communicating
with the same receiver? They can use the same flow label value and
the same destination address: the receiver can distinguish between them
only with the source address. This works with multi-homing because
the lists of possible addresses per sender are known and do not share
a value, but this does not work with mobility where the next source
address is not predictable.
 So IMHO RFC 3697 is not compatible with mobility when destination
options have no problem at all...

   Within the sender and receiver host, receiver side allocation
   causes some complexity, which may interfere with future uses
   (I guess it would be predictable though).
   
=> IMHO the main issue with a receiver allocation of flow labels
is this won't work at all with not-shim6-capable nodes, i.e.,
there shall be a major interoperability issue with legacy nodes...

Regards

[email-masked]

Delivery-date: Tue, 03 May 2005 03:35:32 +0000
Date: Tue, 03 May 2005 13:35:15 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Erik Nordmark <[email-masked]>
Cc: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>>> I don't think it makes sense switching from F1 to a different locator 
>>> for the "main" path as you parenthetically suggest, though.
>>
>>
>>
>> Fair enough.  The main value of retaining the flow label F1 though,
>> is for applications which are interested in flow identification.
> 
> 
> By "applications" do you mean something running on the host?
> 
> My assumption is that the shim on the receiver would not only restore 
> the IPv6 address fields to be the ULIDs, but also restore the flow label 
> to F1. Thus ULPs on the host would see a constant flow label.

Yes, I was thinking that some APIs may allow explicit access to flow
labels (perhaps as RFC3542bis), or a separate extension of to the
advanced sockets API (new socket options?)

The constant flow label would be required in this case, as it could
have particular semantics with the ULP or application.

>> The main thing I guess is that it doesn't break any existing flows while
>> the flow remains on the original path.
> 
> 
> Yep.
> And when switching to a different locator pair, and some flow signaling 
> is used, one would need to do the flow signaling for that locator pair 
> in any case. So using a different flow label for the different locator 
> pair shouldn't be much of an issue.

I guess you'd only want to do the signalling when you had to:

You wouldn't want to require signalling (or a new label)
for every locator pair change, if the label was receiver unique.

Greg

Delivery-date: Tue, 03 May 2005 03:28:05 +0000
Date: Tue, 03 May 2005 13:27:30 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Francis Dupont <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Francis,

Sorry to keep returning to this point.

I really think that Extension headers (and even Destination
Options) are a undesirable.

[chop]
> 
>    I think  
>    they make it pretty clear that using the flow label for demux can be  
>    done without impact to other flow label use, at the cost of some  
>    extra complexity when selecting the flow label for a new session.
> 
> => but the flow label selection is already an essential part of
> RFC 3697. IMHO this proposal is acceptable only because there is
> currently no standard flow label use at all... I.e., it is possible
> to get rid of RFC 3697 and to reserve the flow label for shim6, but
> you have to go this way clearly if you'd like to take it.

I'm not sure that this is necessary (changing 3697) or even desirable,
even for proponents of flow-label-as-shim6.

When I was talking off-list to others about this issue, the role of
3697 flow labels came up and I was encouraged to look into the RFC.

I agree that the labels need to be preserved in their existing sense,
if new flow-label usage schemes are to be supported.

The role of a receiver oriented scheme doesn't interfere with this
though, because for every (src,dest) pair upon which a receiver based
allocation is performed, there's no difference to the routing
infrastructure as to which allocation scheme is used:

The first packet on the path always contains the context tag as label,
since label allocation on subsequent paths (not the original source &
destination), prerequires context tag allocation.

Within the sender and receiver host, receiver side allocation
causes some complexity, which may interfere with future uses
(I guess it would be predictable though).

It doesn't interfere explicitly with simple source selection of
labels, though, except to (slightly) reduce the amount of potential
tags able to be selected by the sender.

> Regards
> 
> [email-masked]
> 
> PS: I still believe the best is a destination option.
> 

:)

At this stage we're in polite disagreement.

Greg

Delivery-date: Tue, 03 May 2005 03:14:47 +0000
Date: Tue, 03 May 2005 13:14:28 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Detailed approaches for demux
To: Francis Dupont <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Francis,

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    When re-homing, also use the same flow label value with alternative 
>    locators.
>    
>    Demux at the receiver side is performed based on (flow label, src, dst)
>    
> => as the triple is chosen by the transmitter after a re-homing the
> receiver side should not rely on src (*) so there is a possible
> collision with another node using the same flow label value (**).

The original 3697 compliant flow label allocation is done on uniquely
on (label, src, dest), so it is easy to track these, on both the sender
and receiver, and they're unlikely to change.

This means that systems using sender side allocation should be able
to mark these as in-use.

Only if the receiver then allocates a label for multiple hosts (or
multiple conversations)(+), will there be a possibility of collision
with another (src, label) pair.

Regards,

Greg

PS +: for example, if there are > 2^20 conversations on the receiver.

Delivery-date: Tue, 03 May 2005 02:26:43 +0000
Date: Tue, 03 May 2005 12:26:19 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Francis Dupont <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Francis,

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    I think that at the moment I agree with you that flow labels should be
>    used if the existing definitions of flow labels can be accomodated
>    (few though they are).
>    
> => the problem with the overloading of flow labels is this should likely
> break all other possible usages of flow labels (not a surprise).
> For instance if flow labels are changed to be allocated after the first
> packet and/or by the receiver.

I guess this is right, except that we can make a change to the semantics
which don't impact the existing label path, and won't be visible to
applications.

>    The original assumption was that flow labels (in general, rather than in
>    shim) would be sender selected.  Marcelo has mentioned that there may
>    therefore be pre-shim flow labels in existence at negotiation time.
>    
> => the flow label is selected by the sender before it sends the first
> packet. IMHO shim stuff should not touch the flow label, i.e., the only
> real but marginal question is whether the flow label should be reset when
> an address in the IPv6 header is changed (there are pros and cons, and in
> fact it doesn't really matter :-).

I agree that the existing requirements for sender place a limitation on
what can be changed (nothing) on the original path where the
communications are established.

If receiver based allocation of labels is useful (which is still under
debate, I guess), then the allocation of labels on other paths when
addresses change can be used to provide that receiver allocation
without impairing the semantics of flow labels for applications or
on the forwarding path (regardless of which path that is).

Whether this is the right approach or not needs to be weighed
against the costs and ease of other ideas.

I'm looking forward to discussion about these issues.

Greg

Delivery-date: Tue, 03 May 2005 02:15:19 +0000
Content-class: urn:content-classes:message
Subject: RE: Firewall "uniformity" issue 
Date: Mon, 2 May 2005 19:14:58 -0700
From: "Christian Huitema" <[email-masked]>
To: "Francis Dupont" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "shim6" <[email-masked]>

>    > Of course, once there are shim6 aware firewalls, we don't know
how
>    > they will behave. But we could at least recommend that they take
>    > this issue into consideration, by recommending
>    > 1) that they not block shim6 by default, but instead look at the
>    > carried (TCP, UDP, etc) payload

You may ask firewall admins to "please not block shim6". You may even
shout from the hill tops. Whether they will heed your advice is
anybody's guess. After all, these are the same folks who routinely block
ICMP.=20

> =3D> I am pretty sure than the default action on unknown extension
header
> (but not unknown destination option) will be to block packets (I am
> speaking about not shim6 aware firewalls, i.e., all currently
available
> firewalls).

If we want end-to-end options to not be blocked by firewalls, the best
solution is to encrypt them. That is, run shim6 inside IPSEC, end to
end.

-- Christian Huitema

Delivery-date: Tue, 03 May 2005 00:08:33 +0000
Date: Mon, 02 May 2005 17:07:43 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Greg Daley wrote:

>> I don't think it makes sense switching from F1 to a different locator 
>> for the "main" path as you parenthetically suggest, though.
> 
> 
> Fair enough.  The main value of retaining the flow label F1 though,
> is for applications which are interested in flow identification.

By "applications" do you mean something running on the host?

My assumption is that the shim on the receiver would not only restore 
the IPv6 address fields to be the ULIDs, but also restore the flow label 
to F1. Thus ULPs on the host would see a constant flow label.

> The main thing I guess is that it doesn't break any existing flows while
> the flow remains on the original path.

Yep.
And when switching to a different locator pair, and some flow signaling 
is used, one would need to do the flow signaling for that locator pair 
in any case. So using a different flow label for the different locator 
pair shouldn't be much of an issue.

    Erik

Delivery-date: Mon, 02 May 2005 23:54:16 +0000
Date: Tue, 03 May 2005 09:51:06 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Erik Nordmark <[email-masked]>
Cc: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> The original assumption was that flow labels (in general, rather than in
>> shim) would be sender selected.  Marcelo has mentioned that there may
>> therefore be pre-shim flow labels in existence at negotiation time.
>>
>> I think it will be possible to accomodate these pre-existing labels
>> for the path between the original source and destination while still
>> allowing receiver selected flow labels for all other paths (and maybe
>> replace the original label on the home path after flow state timeout).
> 
> 
> This is an interesting suggestion. I don't think there is anything which 
> prevents using a different flow label for the communication between ULID 
> A and ULID B, and the communication that is using a different locator 
> pair, but is part of the same upper layer communication. Any devices on 
> the paths would need to identify the flow based on <source locator, 
> destination locator, flow label>, thus when the shim switches to a 
> different locator pair, if an explicit flow signaling protocol is used, 
> it would need to signal something along the new path.
> 
> So I think we can make it so that the hosts start communicating using 
> the ULID pair A, B, and a flow label F1 (which could be zero; it isn't 
> used by the shim, but the shim preserves it e2e).
> Thus F1 is sender allocated as today. (And for the packets from B to A, 
> B could have picked flow label F2.)
> 
> When the shim sets up the context, then each receiver allocates a 
> separate flow label, and uses this to identify the shim state.
> Thus B would allocate F3 and send it to A, and A would allocate F4 and 
> send it to B.
> 
> When the ULP sends packets from A to B before a shim failover, the 
> packets have
>     source locator A1
>     destination locator B1
>     flow label F1
> 
> After a failure, the shim would send packets with replaced values
>     source locator A2
>     destination locator B2
>     flow label F3
> and the receiver would use this to find the context state, so that the 
> packet is passes to the ULP has <A1, A2, F1>.

Well, it could even be before failure, so long as it's on a
different path.

I agree though.

> I don't think it makes sense switching from F1 to a different locator 
> for the "main" path as you parenthetically suggest, though.

Fair enough.  The main value of retaining the flow label F1 though,
is for applications which are interested in flow identification.

In the distant future, if someone returns to a path they've not visited
there's not going to be any retained state in the routers.

It doesn't seriously harm things to retain the flow label for that
pair of <source,dest,flow> triples.

> The benefits of this hybrid is that the flow label that is used to 
> identify the shim state can be receiver allocated, which means that the 
> receiver can easily ensure that the flow label uniquely identifies its 
> context state (for all its current and future locators). Thus the 
> receiver might only need to lookup <destination locator, flow label> to 
> find the context state.
> It might even be possible for the receiver to reuse flow labels for 
> different senders, because the context state setup can exchange the 
> unique ids that Iljitsch suggested recently. (But in such a case, the 
> receiver needs to use the source in the lookup.)

I was talking with Marcelo on this before, and he seemed less interested
in non-unique labels (comments Marcelo?).  I think was largely an issue
if the label could be moved to a new source address before signaling
started.

> The only difference between this and using the same flow label for the 
> communication before and after the locator switch, is a slight change 
> for explicit flow signaling protocols. In either case, initially the 
> signaling protocol setups flow state for <A1, B1, F1> (and <B1, A1, F2> 
> for the reverse path).
> If we use the same flow label, then after a locator switch, the 
> signaling protocol needs to signal <A2, B2, F1>.
> If we use a different (receiver allocated label), it needs to signal 
> <A2, B2, F3> instead.
> Doesn't seem like a big difference to me.

The main thing I guess is that it doesn't break any existing flows while
the flow remains on the original path.

Greg

Delivery-date: Mon, 02 May 2005 12:34:53 +0000
Cc: Pekka Savola <[email-masked]>, shim6 <[email-masked]>
From: Brian Haberman <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Mon, 2 May 2005 08:34:13 -0400
To: Iljitsch van Beijnum <[email-masked]>

--Apple-Mail-4--708899973
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Iljitsch,

On May 1, 2005, at 14:06, Iljitsch van Beijnum wrote:

> On 1-mei-2005, at 20:01, Pekka Savola wrote:
>
>>> Also, looks like RFC 2460 dropped the ball here. It actually draws  
>>> extension headers as having a next header and a length field in a  
>>> fixed place, but then doesn't say that all extension headers should  
>>> look like that.
>
>> That's what  
>> http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling 
>> -02.txt section 3 tried to specify, and there are implementation(s)  
>> which assume all the unspecified extension headers are in TLV format.
>
>> Unfortunately, there apparently wasn't sufficient interest for this  
>> spec, maybe it was focusing on too many different communities.
>
> I was actually surprised that RFC 2460 is the most recent IPv6 spec.  
> With all the rewriting of RFCs going on I'd have expected this one to  
> see a new version at least biannually.  :-)

Sorry we let you down.  The base spec is rather solid, as far as I  
know. :)

>
> But isn't there an RFC2640bis effort underway right now? Seems the  
> natural place for this, and five lines in an existing RFC-to-be is  
> always easier than making it an RFC of its own.
>

No, the IPv6 working group is updating ICMPv6, the Addressing
Architecture, NDP, and Stateless Autoconf.

Regards,
Brian
--Apple-Mail-4--708899973
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-4--708899973--

Envelope-to: [email-masked]
Delivery-date: Mon, 02 May 2005 12:33:58 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Detailed approaches for demux 
Date: Mon, 02 May 2005 14:33:28 +0200

 In your previous mail you wrote:

   When re-homing, also use the same flow label value with alternative 
   locators.
   
   Demux at the receiver side is performed based on (flow label, src, dst)
   
=> as the triple is chosen by the transmitter after a re-homing the
receiver side should not rely on src (*) so there is a possible
collision with another node using the same flow label value (**).

Regards

[email-masked]

PS *: as you explain it is possible to solve the source locator issue
because possible values are known and should not be shared. This doesn't
work with mobility but works well with multi-homing.
PS **: this is the drawback of the assignment by the transmitter: when
the tag is assigned by the side using it for demux the tag itself is enough.

Envelope-to: [email-masked]
Delivery-date: Mon, 02 May 2005 09:54:10 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Mon, 02 May 2005 11:53:57 +0200

 In your previous mail you wrote:

   > => basically as there is no way to deal with a new extension header  
   > without
   > modifying code or more, this will kill all the boxes which are looking
   > inside packets for good or less good reasons.
   
   I don't think that in this stadium of IPv6 deployment this is that  
   huge a deal.
   
=> I am sorry but I believe to propose major changes in IPv6 is no more
a good idea today. Perhaps you have a little deployment where you are
but don't expect it is the case everywhere...

   Also, looks like RFC 2460 dropped the ball here. It actually draws  
   extension headers as having a next header and a length field in a  
   fixed place, but then doesn't say that all extension headers should  
   look like that.
   
=> as a new extension header needs new code this doesn't matter.

   Have you been reading other posts to this list the past week?

=> yes.

   I think  
   they make it pretty clear that using the flow label for demux can be  
   done without impact to other flow label use, at the cost of some  
   extra complexity when selecting the flow label for a new session.

=> but the flow label selection is already an essential part of
RFC 3697. IMHO this proposal is acceptable only because there is
currently no standard flow label use at all... I.e., it is possible
to get rid of RFC 3697 and to reserve the flow label for shim6, but
you have to go this way clearly if you'd like to take it.

Regards

[email-masked]

PS: I still believe the best is a destination option.

Envelope-to: [email-masked]
Delivery-date: Mon, 02 May 2005 09:39:06 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Firewall "uniformity" issue 
Date: Mon, 02 May 2005 11:38:04 +0200

 In your previous mail you wrote:

   > Of course, once there are shim6 aware firewalls, we don't know how  
   > they will behave. But we could at least recommend that they take  
   > this issue into consideration, by recommending
   > 1) that they not block shim6 by default, but instead look at the  
   > carried (TCP, UDP, etc) payload

=> I am pretty sure than the default action on unknown extension header
(but not unknown destination option) will be to block packets (I am
speaking about not shim6 aware firewalls, i.e., all currently available
firewalls).

   Another firewalling issue is whether we put the initial shim header  
   in a packet that also has payload, or if we give it its own packet.  

=> this is the Mobile IPv6 piggy-backing issue... but now we have
RFC2401bis IPsec so it can work.

Regards

[email-masked]

Delivery-date: Sun, 01 May 2005 18:06:34 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Sun, 1 May 2005 20:06:11 +0200
To: Pekka Savola <[email-masked]>

On 1-mei-2005, at 20:01, Pekka Savola wrote:

>> Also, looks like RFC 2460 dropped the ball here. It actually draws  
>> extension headers as having a next header and a length field in a  
>> fixed place, but then doesn't say that all extension headers  
>> should look like that.

> That's what http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops- 
> firewalling-02.txt section 3 tried to specify, and there are  
> implementation(s) which assume all the unspecified extension  
> headers are in TLV format.

> Unfortunately, there apparently wasn't sufficient interest for this  
> spec, maybe it was focusing on too many different communities.

I was actually surprised that RFC 2460 is the most recent IPv6 spec.  
With all the rewriting of RFCs going on I'd have expected this one to  
see a new version at least biannually.  :-)

But isn't there an RFC2640bis effort underway right now? Seems the  
natural place for this, and five lines in an existing RFC-to-be is  
always easier than making it an RFC of its own.

Delivery-date: Sun, 01 May 2005 18:03:05 +0000
Date: Sun, 1 May 2005 21:01:33 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Francis Dupont <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 

On Sat, 30 Apr 2005, Iljitsch van Beijnum wrote:
> [pruned CC list before my mail client runs out of memory...]
> On 29-apr-2005 Francis Dupont wrote:
>
>>    Why not adding a new extension header?
>
>> => basically as there is no way to deal with a new extension header without
>> modifying code or more, this will kill all the boxes which are looking
>> inside packets for good or less good reasons.
>
> I don't think that in this stadium of IPv6 deployment this is that huge a 
> deal.
>
> Also, looks like RFC 2460 dropped the ball here. It actually draws extension 
> headers as having a next header and a length field in a fixed place, but then 
> doesn't say that all extension headers should look like that.

That's what 
http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling-02.txt 
section 3 tried to specify, and there are implementation(s) which 
assume all the unspecified extension headers are in TLV format.

Unfortunately, there apparently wasn't sufficient interest for this 
spec, maybe it was focusing on too many different communities.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Sun, 01 May 2005 04:09:01 +0000
Date: Sat, 30 Apr 2005 21:08:30 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: Francis Dupont <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

Greg Daley wrote:
> The original assumption was that flow labels (in general, rather than in
> shim) would be sender selected.  Marcelo has mentioned that there may
> therefore be pre-shim flow labels in existence at negotiation time.
> 
> I think it will be possible to accomodate these pre-existing labels
> for the path between the original source and destination while still
> allowing receiver selected flow labels for all other paths (and maybe
> replace the original label on the home path after flow state timeout).

This is an interesting suggestion. I don't think there is anything which 
prevents using a different flow label for the communication between ULID 
A and ULID B, and the communication that is using a different locator 
pair, but is part of the same upper layer communication. Any devices on 
the paths would need to identify the flow based on <source locator, 
destination locator, flow label>, thus when the shim switches to a 
different locator pair, if an explicit flow signaling protocol is used, 
it would need to signal something along the new path.

So I think we can make it so that the hosts start communicating using 
the ULID pair A, B, and a flow label F1 (which could be zero; it isn't 
used by the shim, but the shim preserves it e2e).
Thus F1 is sender allocated as today. (And for the packets from B to A, 
B could have picked flow label F2.)

When the shim sets up the context, then each receiver allocates a 
separate flow label, and uses this to identify the shim state.
Thus B would allocate F3 and send it to A, and A would allocate F4 and 
send it to B.

When the ULP sends packets from A to B before a shim failover, the 
packets have
	source locator A1
	destination locator B1
	flow label F1

After a failure, the shim would send packets with replaced values
	source locator A2
	destination locator B2
	flow label F3
and the receiver would use this to find the context state, so that the 
packet is passes to the ULP has <A1, A2, F1>.

I don't think it makes sense switching from F1 to a different locator 
for the "main" path as you parenthetically suggest, though.

The benefits of this hybrid is that the flow label that is used to 
identify the shim state can be receiver allocated, which means that the 
receiver can easily ensure that the flow label uniquely identifies its 
context state (for all its current and future locators). Thus the 
receiver might only need to lookup <destination locator, flow label> to 
find the context state.
It might even be possible for the receiver to reuse flow labels for 
different senders, because the context state setup can exchange the 
unique ids that Iljitsch suggested recently. (But in such a case, the 
receiver needs to use the source in the lookup.)

The only difference between this and using the same flow label for the 
communication before and after the locator switch, is a slight change 
for explicit flow signaling protocols. In either case, initially the 
signaling protocol setups flow state for <A1, B1, F1> (and <B1, A1, F2> 
for the reverse path).
If we use the same flow label, then after a locator switch, the 
signaling protocol needs to signal <A2, B2, F1>.
If we use a different (receiver allocated label), it needs to signal 
<A2, B2, F3> instead.
Doesn't seem like a big difference to me.

    Erik