Subject: [netlmm] DNAv6/SEND and timestamp synchronization problems

From: Julien Laganier <[email-masked]>
Date: Tue, 11 Sep 2007 16:20:02 +0200

Folks,

It has been discussed on the mailing list that synchronizing time across 
different MAGs to allow reordering of pBUs might be a problem. While 
thinking about the issue I got the idea to leverage on SEND to solve 
that issue.

When the MN uses DNAv6 for movement detection along with SEND to secure 
ND signaling (which includes DNAv6), all ND messages sent by the MN 
will contain a timestamp representing the local time on the MN. Thus, 
all MAGs to which a given MN attached to have access to a single per-MN 
timestamp source.

Using pBU timestamps from that source will avoid issues with time 
synchronization of different MAGs since timestamps are synchronized at 
the source.

Thoughts?

--julien

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Sep 2007 00:29:09 -0700

Hi Julien,

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 7:20 AM
> To: [email-masked]
> Subject: [netlmm] DNAv6/SEND and timestamp synchronization problems
> 
> Folks,
> 

Good idea ! 

Will this require the RS as the only trigger for PMIP signaling ?
Currently, any network attachment event or auth completion event
can be used by the MAG as a trigger to start the PMIP signaling.
This change requires the timestamp in PMIP message and that can
come only in ND messages from the MN. 

Other comment is from the deployment perspective, do you think,
we can expect operators to put DNAv6 in the handsets, right away ?
That will be a factor as well.

Sri

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Wed, 12 Sep 2007 11:54:45 +0200

Hi Julien,

the concept looks good to me, but only useful when SEND is present
I'm not uptodate with SEND, may I ask a pointer to this protocol?

In my opinion in order to enable this solution, there should also be the following requirements/constraints:
   - Each BU should be preceded by a SEND message: this phrasing is intentional to cover not only the scenario of "HO from pMAG to nMAG" (which seems to be the one that everybody has in mind) but also the scenario of "lifetime expiration" (thus BU refresh)
   - The number of MAGs to which the MN is associated should be constrained to only 1: if the MN can be connected to pMAG and nMAG concurrently (from SEND point of view), then avoiding race conditions in PMIP HO would become more complex

A final comment is that the idea could be generalized to allow using a sequence number or a timestamp generated by the MN whenever there's a protocol (e.g. SEND) which is guaranteed to be executed before sending a BU

Regards

federico

-----Message d'origine-----
De : Julien Laganier [mailto:[email-masked]] 
Envoyé : mardi 11 septembre 2007 16:20
À : [email-masked]
Objet : [netlmm] DNAv6/SEND and timestamp synchronization problems

Folks,

It has been discussed on the mailing list that synchronizing time across different MAGs to allow reordering of pBUs might be a problem. While thinking about the issue I got the idea to leverage on SEND to solve that issue.

When the MN uses DNAv6 for movement detection along with SEND to secure ND signaling (which includes DNAv6), all ND messages sent by the MN will contain a timestamp representing the local time on the MN. Thus, all MAGs to which a given MN attached to have access to a single per-MN timestamp source.

Using pBU timestamps from that source will avoid issues with time synchronization of different MAGs since timestamps are synchronized at the source.

Thoughts?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 13:12:41 +0200

Hi Sri,

On Wednesday 12 September 2007, Sri Gundavelli wrote:
> > different MAGs to allow reordering of pBUs might be a problem.
> > While thinking about the issue I got the idea to leverage on SEND
> > to solve that issue.
> >
> > will contain a timestamp representing the local time on the MN.
> > Thus, all MAGs to which a given MN attached to have access to a
> > single per-MN
> > timestamp source.
>
> Good idea !

Glad you like it.

> Will this require the RS as the only trigger for PMIP signaling ?

Not necessarily. 

> come only in ND messages from the MN.

It is true that the methods requires the AR to receive a SEND-protected 
ND messages from the MN to get the SEND Timestamp. 

However the trigger to PMIP could still be something else (e.g. L2 
link-up indication), while the timestamp to fill-in the pBU would still 
come from SEND, provided that the AR gets such a SEND-protected ND 
message from the MN.

The AR can get a SEND-protected ND message from the MN in the following 
cases:

 - the MN has DNAv6 support and sends to all-routers a SEND-protected 
RA.

 - the AR gets to know a link-local IPv6 address of the MN (e.g. because 
the MN does DAD for the link-local, or via the AR sending a MLDv2 
general query and getting a reply sourced from the MN link local, etc.) 
and can solicit that link local address with a NS, and will get a 
SEND-protected NA.

> That will be a factor as well.

I don't think DNAv6 is necessary per se. The requirements are that the 
MN and MAG supports SEND and that the AR receives a SEND-protected ND 
message from the MN. The latter doesn't necessarily requires DNAv6, as 
explained above.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 13:20:50 +0200

Hi Federico,

> I'm not uptodate with SEND, may I ask a pointer to this protocol?

Right: RFC3971 <http://www.ietf.org/rfc/rfc3971.txt>

> - Each BU should be preceded by a SEND message: this phrasing is
> intentional to cover not only the scenario of "HO from pMAG to nMAG"
> (which seems to be the one that everybody has in mind) but also the 
> scenario of "lifetime expiration" (thus BU refresh)  

That could also be phrased as: When both the MAG and the MN supports 
SEND, the MAG MAY use a pBU timestamp obtained from ND signalling 
issued by the MN. In such case, sending a pBU MUST be preceded by 
obtention of fresh SEND-protected ND message from the MN.

> - The number of MAGs to which the MN is associated should be
> constrained to only 1: if the MN can be connected to pMAG and nMAG
> concurrently (from SEND point of view), then avoiding race conditions
> in PMIP HO would become more complex 

The race condition problem occuring from simultaneous connexion at two 
MAGs cannot be defeated by timestamping alone, and is not specific to 
this SEND method. The only way to defeat such race conditions is that 
the MN can't be attached to more than one MAG, and a MAG must not send 
pBU when a MN is not attached. Otherwise it's not going to work, 
timestamps or not.

> A final comment is that the idea could be generalized to allow using
> a sequence number or a timestamp generated by the MN whenever there's
> a protocol (e.g. SEND) which is guaranteed to be executed before
> sending a BU

Yeah, I thought about that generalization, but could not find examples 
of appropriate MN-generated sequence numbers. For example, it is 
possible that an L2 sequence number is reset or randomized after each 
L2 attachment, making it useless for the purpose of ordering pBUs.

--julien

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 12 Sep 2007 14:13:58 +0200

Hi Julien, 

I like your idea of utilizing a timestamp or sequence number maintained
by the MN for re-ordering PBU msgs. 

> L2 attachment, making it useless for the purpose of ordering pBUs.

Yes, generalization would be nice. 

L2 sequence number would be one option, but as you said this may not
always work. Any other? How about the EAP Identifier?

At least the spec could say that if there is a MN-generated sequence
number or timestamp available at the MN that is maintained across MAG
attachements (i.e., not reset or randomized after each attachement) and
signaled to the network at least after each MAG attachement, this
sequence number/timestamp can be used in PBUs even if no context
transfer is available. SeND is one example.

BR,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Wed, 12 Sep 2007 14:40:48 +0200

Julien,

See inline
Regards

federico

-----Message d'origine-----
De : julien laganier [mailto:[email-masked]] De la part de Julien Laganier
Envoyé : mercredi 12 septembre 2007 13:21
À : DE JUAN HUARTE FEDERICO
Cc : [email-masked]
Objet : Re: [netlmm] DNAv6/SEND and timestamp synchronization problems

Hi Federico,

On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote:
> Hi Julien,
>
> the concept looks good to me, but only useful when SEND is present I'm 
> not uptodate with SEND, may I ask a pointer to this protocol?

[FDJ] Thanks

> scenario of "lifetime expiration" (thus BU refresh)

That could also be phrased as: When both the MAG and the MN supports SEND, the MAG MAY use a pBU timestamp obtained from ND signalling issued by the MN. In such case, sending a pBU MUST be preceded by obtention of fresh SEND-protected ND message from the MN.
[FDJ] That's fine

> in PMIP HO would become more complex

The race condition problem occuring from simultaneous connexion at two MAGs cannot be defeated by timestamping alone, and is not specific to this SEND method. 
[FDJ] Indeed, the race condition problem is not specific to SEND. But I thought proposing SEND was aimed to address the problem
Otherwise, SEND is just another protocol for time synchronization (instead of NTP)

The only way to defeat such race conditions is that the MN can't be attached to more than one MAG, and a MAG must not send pBU when a MN is not attached. Otherwise it's not going to work, timestamps or not.
[FDJ] Very well described. Only one nuance: with context transfers there's no race condition problem
Is the assumption that we can prevent a MAG to send BU when MN is not attached?
Depending on the deployment, there can be a significant delay between MN detachment and MAG noticing it

> A final comment is that the idea could be generalized to allow using a 
> sequence number or a timestamp generated by the MN whenever there's a 
> protocol (e.g. SEND) which is guaranteed to be executed before sending 
> a BU

Yeah, I thought about that generalization, but could not find examples of appropriate MN-generated sequence numbers. For example, it is possible that an L2 sequence number is reset or randomized after each
L2 attachment, making it useless for the purpose of ordering pBUs.
[FDJ] A secured L2 wireless interface should support sequence numbers for replay protection
In fact, it looks like SEND proposes timestamps for the sake of replay protection
Personally, I don't think that using timestamp for replay protection is as secure as using sequence numbers, but that's a different topic

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 15:16:47 +0200

On Wednesday 12 September 2007, Kilian Weniger wrote:
> Hi Julien,
>
> I like your idea of utilizing a timestamp or sequence number
> maintained by the MN for re-ordering PBU msgs.
>
> > > A final comment is that the idea could be generalized to allow
> > > using a sequence number or a timestamp generated by the MN
> > > whenever there's a protocol (e.g. SEND) which is guaranteed to be
> > > executed before sending a BU
> >
> > Yeah, I thought about that generalization, but could not find
> > examples of appropriate MN-generated sequence numbers. For example,
> > it is possible that an L2 sequence number is reset or randomized
> > after each L2 attachment, making it useless for the purpose of
> > ordering pBUs.
>

EAP does not require the Identifier to be monotonically increasing. And 
EAP will presumably be reset after each handover when no context 
transfer mechanism is present.

Right know I can't think of any such identifier at L2 since they will 
most likely be reset/randomized on handover. At L3 we have only SEND 
timestamps AFAICS. 

> attachements (i.e., not reset or randomized after each attachement)
> and signaled to the network at least after each MAG attachement, this

Agree.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 15:44:13 +0200

Federico,

> See inline

Ditto,

> Julien Laganier wrote:
>
>  [...]
> > > In my opinion in order to enable this solution, there should also
> > > be the following requirements/constraints:
> > >
> > > intentional to cover not only the scenario of "HO from pMAG to
> > > nMAG" (which seems to be the one that everybody has in mind) but
> > > also the scenario of "lifetime expiration" (thus BU refresh)
> >
> > That could also be phrased as: When both the MAG and the MN
> > supports SEND, the MAG MAY use a pBU timestamp obtained from ND
> > signalling issued by the MN. In such case, sending a pBU MUST be
> > preceded by obtention of fresh SEND-protected ND message from the
> > MN. 
>
> That's fine 
> 
> > > constrained to only 1: if the MN can be connected to pMAG and
> > > nMAG concurrently (from SEND point of view), then avoiding race
> > > conditions in PMIP HO would become more complex
> >
> > The race condition problem occuring from simultaneous connexion at
> > two MAGs cannot be defeated by timestamping alone, and is not
> > specific to this SEND method. 
> 
> Indeed, the race condition problem is not specific to SEND. But I
> thought proposing SEND was aimed to address the problem. Otherwise,
> SEND is just another protocol for time synchronization (instead of
> NTP) 

Simultaneous attachments to different MAGs causes issues with PMIPv6 
which are outside the scope of this specification. The problem cannot 
be addressed without protocol extensions. 
 
> > The only way to defeat such race conditions is that the MN can't be
> > attached to more than one MAG, and a MAG must not send pBU when a
> > MN is not attached. Otherwise it's not going to work, timestamps or
> > not. 
> 
> Very well described. Only one nuance: with context transfers there's
> no race condition problem. 

With context transfer you would in effect prevent attachment to more 
than two MAGs.

> Is the assumption that we can prevent a MAG to send BU when MN is not

At least I have been making that assumption.

> MN detachment and MAG noticing it  

If a MAG always test reachability of the MN before extending an existing 
binding (i.e. beyond initial registration) there we would have no 
problem.

Maybe we should complete that part of Section 6.9.1.:

>    Binding Re-Registration:
>
>    o  For extending the lifetime of a currently existing binding at
> the local mobility, the mobile access gateway MUST send a Proxy
> Binding Update message to the local mobility anchor.  The prefix
> value in the Home Network Prefix option present in the request SHOULD
> be set to the currently registered home network prefix and the value
> in the Link-local Address option may be set to ALL_ZERO or to the
> link-local address of the mobile node.

with this sentence "the MAG MUST make sure the MN is still attached to 
it before extending the lifetime of an existing binding. That MAY be 
done by using Neighbor Unreachibility Detection (i.e. an NS/NA 
exchange.)"

That could also be included in the MN-MAG interface draft 
(draft-ietf-netlmm-mn-ar) via inclusion of a new method 
MAG_TEST_MN_REACHABILITY.

> A secured L2 wireless interface should support sequence numbers for
> replay protection In fact, it looks like SEND proposes timestamps for
> the sake of replay protection Personally, I don't think that using
> timestamp for replay protection is as secure as using sequence
> numbers, but that's a different topic.

Yes, that's a difference topic. Anyway for the record, SEND deals with 
security of signaling that are not always request/response, hence 
making it impossible to use Nonces, or to initialy synchronize a 
sequence number. That's why a timestamp is included to provide reduced, 
but still useful security.

--julien

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 13 Sep 2007 12:57:15 +0200

Hi Julien,

Julien> If a MAG always test reachability of the MN before extending an existing binding (i.e. beyond initial registration) there we would have no problem. Maybe we should complete that part of Section 6.9.1.: ...
[FDJ] It makes sense to me to avoid the race condition problem when using timestamps. For the case of context transfer, I don't think it's necessary

Note that if the concern is only the case I mentioned (race condition because MN attached to nMAG but pMAG didn't notice) then it may be unnecesary if the LMA can tell when a BU is a refresh
There are other corner cases (ping-pong between MAGs, fast HO from pMAG to nMAG1 and then to nMAG2) where it helps but is not bullet-proof
If the timestamp came from the MN (as per you SEND proposal) it would be bullet-proof

Still, the case of MN connected/reachable by multiple MAGs would need further consideration (I'm fine if it's out of scope)

Regards

federico

-----Message d'origine-----
De : julien laganier [mailto:[email-masked]] De la part de Julien Laganier
Envoyé : mercredi 12 septembre 2007 15:44
À : DE JUAN HUARTE FEDERICO
Cc : [email-masked]
Objet : Re: [netlmm] DNAv6/SEND and timestamp synchronization problems

Federico,

Ditto,

> > > concurrently (from SEND point of view), then avoiding race 

Simultaneous attachments to different MAGs causes issues with PMIPv6 which are outside the scope of this specification. The problem cannot be addressed without protocol extensions. 
 
> > attached to more than one MAG, and a MAG must not send pBU when a MN 
> > is not attached. Otherwise it's not going to work, timestamps or 
> > not.
> 

With context transfer you would in effect prevent attachment to more than two MAGs.

> MN detachment and MAG noticing it

If a MAG always test reachability of the MN before extending an existing binding (i.e. beyond initial registration) there we would have no problem.

Maybe we should complete that part of Section 6.9.1.:

> Binding Update message to the local mobility anchor.  The prefix value 
> in the Home Network Prefix option present in the request SHOULD be set 
> to the currently registered home network prefix and the value in the 
> Link-local Address option may be set to ALL_ZERO or to the link-local 
> address of the mobile node.

with this sentence "the MAG MUST make sure the MN is still attached to it before extending the lifetime of an existing binding. That MAY be done by using Neighbor Unreachibility Detection (i.e. an NS/NA exchange.)"

That could also be included in the MN-MAG interface draft
(draft-ietf-netlmm-mn-ar) via inclusion of a new method MAG_TEST_MN_REACHABILITY.

> numbers, but that's a different topic.

Yes, that's a difference topic. Anyway for the record, SEND deals with security of signaling that are not always request/response, hence making it impossible to use Nonces, or to initialy synchronize a sequence number. That's why a timestamp is included to provide reduced, but still useful security.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 14:15:03 +0200

Hi Federico,

On Thursday 13 September 2007, DE JUAN HUARTE FEDERICO wrote:
> Hi Julien,
>
> Julien Laganier wrote:
> > If a MAG always test reachability of the MN before extending
> > an existing binding (i.e. beyond initial registration) there we
> > would have no problem. Maybe we should complete that part of Section
> > 6.9.1.: ... 
>
> It makes sense to me to avoid the race condition 
> problem when using timestamps. For the case of context transfer, I
> don't think it's necessary

With context transfer inter-MAG handover synchronization would have less 
problem, I agree.

> Note that if the concern is only the case I mentioned (race condition
> because MN attached to nMAG but pMAG didn't notice) then it may be
> unnecesary if the LMA can tell when a BU is a refresh. 

Yes, it might be useful to differentiate between pBU establishing a 
binding at a new MAG, and pBU extending an existing binding. We could 
have a flag in the pBU to do that.

FWIW, the NETLMM Design Team protocol was making this distinction IIRC.

> There are other corner cases (ping-pong between MAGs, fast HO from
> pMAG to nMAG1 and then to nMAG2) where it helps but is not
> bullet-proof. 

What would be needed to avoid all race conditions would be a message 
that is sent LMA to pMAG to delete a previous binding when the LMA 
receives a pBU from a nMAG with the 'new binding' flag

FWIW again the NETLMM Design Team protocol had such a functionality.

> If the timestamp came from the MN (as per you SEND proposal) it would

Agree. I like the SEND scheme since beside the added value of SEND 
itself it defeats all race conditions with timestamping.

> Still, the case of MN connected/reachable by multiple MAGs would need
> further consideration (I'm fine if it's out of scope)

This cases actually requires more work than just taking care of race 
conditions. It needs protocol extensions (e.g. how does the LMA know to 
which MAG route packets), but that is another topic.

Best,

--julien

> De : julien laganier [mailto:[email-masked]] De la part de
> Julien Laganier Envoyé : mercredi 12 septembre 2007 15:44
> > > > In my opinion in order to enable this solution, there should
> > > > also be the following requirements/constraints:
> > > >
> > > > - Each BU should be preceded by a SEND message: this phrasing
> > > > is intentional to cover not only the scenario of "HO from pMAG
> > > > to nMAG" (which seems to be the one that everybody has in mind)
> > > > but also the scenario of "lifetime expiration" (thus BU
> > > > refresh)
> > >
> > > The race condition problem occuring from simultaneous connexion
> > > at two MAGs cannot be defeated by timestamping alone, and is not
> > > The only way to defeat such race conditions is that the MN can't
> > > be attached to more than one MAG, and a MAG must not send pBU
> > > when a MN is not attached. Otherwise it's not going to work,
> > > timestamps or not.
> >
> > Very well described. Only one nuance: with context transfers
> > there's no race condition problem.
>
> > Depending on the deployment, there can be a significant delay
> > between MN detachment and MAG noticing it
>
> If a MAG always test reachability of the MN before extending an
> existing binding (i.e. beyond initial registration) there we would
> have no problem.
>
> > value in the Home Network Prefix option present in the request
> > SHOULD be set to the currently registered home network prefix and
> > the value in the Link-local Address option may be set to ALL_ZERO
> > or to the link-local address of the mobile node.
>
> with this sentence "the MAG MUST make sure the MN is still attached
> to it before extending the lifetime of an existing binding. That MAY
> be done by using Neighbor Unreachibility Detection (i.e. an NS/NA
> exchange.)"
>
> > > > whenever there's a protocol (e.g. SEND) which is guaranteed to
> > > > be executed before sending a BU
> > >
> > > examples of appropriate MN-generated sequence numbers. For
> > > example, it is possible that an L2 sequence number is reset or
> > > randomized after each L2 attachment, making it useless for the
> > > purpose of ordering pBUs.
> >
> > replay protection In fact, it looks like SEND proposes timestamps
> > for the sake of replay protection Personally, I don't think that
> > using timestamp for replay protection is as secure as using
> > sequence numbers, but that's a different topic.
>
> Yes, that's a difference topic. Anyway for the record, SEND deals
> with security of signaling that are not always request/response,
> hence making it impossible to use Nonces, or to initialy synchronize
> a sequence number. That's why a timestamp is included to provide
> reduced, but still useful security.
>
> --julien