Subject: [MEXT] New draft "Router Advertisements for Routing between Moving Networks"

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Jul 2010 17:50:15 +0200

Dear MEXTers,

I have submitted a new draft "Router Advertisements for Routing between
Moving Networks" :

http://www.ietf.org/id/draft-petrescu-autoconf-ra-based-routing-00.txt

This is a evolution of a previous draft doing prefixes in the RAs.  We
added some scenarios such as route deletion and 3rd MR arrival.

The prefix exchanges between two MRs can be seen as a form of Route
Optimization between MRs when infrastructure is not available.

I am interested in any discussion that may relate the idea presented in
this draft to the MEXT activities.  If discussed, then I am eager to
present in Maastricht.

(Also posted to AUTOCONF).
(The idea in this draft is very much related to another draft by J-H.
Lee, M.Tuskada and T. Ernst, which was discussed on this list.)

Alex

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 5 Jul 2010 22:28:51 +0200

Hi, Alex.

Good to see this draft. Here are my comments on yours.

1. In page 5, 6, and 7, you describe the route deletion case. Before an MR
leaves from a fixed scene (place), it sends an RA message with the D flag or
lifetime zero. Here, how does the MR know that it will leave from the fixed
scene? In addition, can you plz define the fixed scene?

2. In page 5, you describe a routing table update operation for enabling a
direction communication between LFNs. Well, the routing table must be
added/updated based on the SLLA and MNP obtained from the RA message. But,
the text describing the routing table update operation is written obscurely.

3. In page 6, you describe a scenario of arrival of a new MR. Here, I failed
to understand the last step of the algorithm executed by the newly joining
MR: "(5) For each received RA, ... and insert the corresponding number of
routing table entries; these entries will help reach the LFNs in the moving
networks of MR1 and MR2." Can you provide more details?

4. In this draft, the use of RS message is also mentioned to quickly obtain
RA messages. But, I cannot see the message format or option for the RS in
Section 3.4.

5. For security considerations, I suppose that you took it lightly.
Announcing MNP information to neighbor MRs gives rise to much more threats
than the identified threats in RFC 3756. In addition, the address ownership
provided by SEND cannot be extended to ensure the MNP ownership without
involving the use of certificate.

Cheers.

On Mon, Jul 5, 2010 at 5:50 PM, Alexandru Petrescu <
[email-masked]> wrote:

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

-- 
IMARA Team, INRIA, France.
Jong-Hyouk Lee.

#email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Jul 2010 20:42:23 +0200

Hi Jong-Hyouk, thank you for the reply.  I will have to update the draft
following your comments.

Le 05/07/2010 22:28, Jong-Hyouk Lee a écrit :
> 1. In page 5, 6, and 7, you describe the route deletion case. Before
> an MR leaves from a fixed scene (place), it sends an RA message with
> the D flag or lifetime zero. Here, how does the MR know that it will
> leave from the fixed scene?

In some cases it may know.  It depends on the kind of deployment:
vehicles diligently following each other (convoy), wagons in a train
reformed every  morning, and more - are specific vehicular cases where
the leaving operation is planned and known in advance.  In other cases
such as arbitrary movement of vehicles on a highway the leaving
operation is less predictable, thus 'D' bit less usable.

Even in those arbitrary cases, though, the indication of 'leaving' could
be hinted at by link layer signal deterioration following known
decreasing patterns.

> In addition, can you plz define the fixed scene?

The bullet saying "Fixed Scene" is a leftover from earlier text which,
for information, described an incident scene where vehicles arrive, stay
connected for 3 hours and then leave each at a different moment.  This
scene is another kind of vehicular scenario that we could describe but
which is not our focus at this time.  For this reason, I may need to
remove the "Fixed Scene" reason for 'D' bit, and the associated text.

> 2. In page 5, you describe a routing table update operation for
> enabling a direction communication between LFNs. Well, the routing
> table must be added/updated based on the SLLA and MNP obtained from
> the RA message.

Right.

> But, the text describing the routing table update operation is
> written obscurely.

Yes, I agree, the text describing how to update the routing table may
read obscurely and, moreover, it is present at several places in the
draft.  It may be necessary to detail it more and in a single section,
probably only in the section "Operation on a Mobile Router".

If any other suggestion to clarify the obscurity then I am open to comments.

> 3. In page 6, you describe a scenario of arrival of a new MR. Here,
> I failed to understand the last step of the algorithm executed by
> the newly joining MR: "(5) For each received RA, ... and insert the
> corresponding number of routing table entries; these entries will
> help reach the LFNs in the moving networks of MR1 and MR2." Can you
> provide more details?

Right, it is very compressed text.  It means the following:

for each received RA
    extract the [source address] of this RA
    extract each MNP from this RA
      for each [MNP] thus extracted
          insert a routing table entry of the form
               [MNP;source address]

This is actually simplified code copied from our implementation of the
mechanism.

> 4. In this draft, the use of RS message is also mentioned to quickly
> obtain RA messages. But, I cannot see the message format or option
> for the RS in Section 3.4.

I agree.  RS format is absent from the draft because we have not
modified it at all.  It may be the case that an extension of RS may be
needed to solicit the kind of special RA.  Do you have an idea?

> 5. For security considerations, I suppose that you took it lightly.

Hmm... lightly... yes, in the sense that we have not described the
detail.  But we do take security seriously.  In our implementation we
vary from no security to using "WPA-NONE" which does use a form of
encryption.

It is important to have the MNPs exchanged securely.

> Announcing MNP information to neighbor MRs gives rise to much more
> threats than the identified threats in RFC 3756.

I agree.  The RA-MNP risks are more than RFC3756 "ND Trust Models and
Threats", simply because not only two Nodes are at risk (typically a
Host and a Router doing classical ND), but all nodes potentially forming
addresses from these MNPs are at risk.

> In addition, the address ownership provided by SEND cannot be
> extended to ensure the MNP ownership without involving the use of
> certificate.

Hmmm... well depends, SeND could be extended to use RSA Signature Option
over a prefix and rightmost filled with 0s, instead of over an address.
  CGAs may be harder to adapt to the use of a prefix (less bits than an
address), but still.

Certificates: I suppose their use depends on the availability of an
Internet connection.  This is something (obtain and verify the certs in
a MR connected to Internet on one hand and to another vehicle on another
hand) we have tried in practice but not yet sure whether it's the right
way, because we'd like this RA-MNP mechanism to stay completely
independent of infrastructure availability.

Comments welcome,

Alex

>
> Cheers.
>
> On Mon, Jul 5, 2010 at 5:50 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Dear MEXTers,
>
> I have submitted a new draft "Router Advertisements for Routing
> between Moving Networks" :
>
This is a evolution of a previous draft doing prefixes in the RAs.
> We added some scenarios such as route deletion and 3rd MR arrival.
>
> I am interested in any discussion that may relate the idea presented
> in this draft to the MEXT activities.  If discussed, then I am eager
> to present in Maastricht.
>
> (Also posted to AUTOCONF). (The idea in this draft is very much
> related to another draft by J-H. Lee, M.Tuskada and T. Ernst, which
> was discussed on this list.)
>
>
> Alex
>
> _______________________________________________ MEXT mailing list
> [email-masked] <mailto:[email-masked]>
> -- IMARA Team, INRIA, France. Jong-Hyouk Lee.
>
> #email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria
> (dot) fr #webpage: https://sites.google.com/site/hurryon/

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 6 Jul 2010 22:19:29 +0200

Hi, Alex.

Thanks for your responses on the comments. Below are my responses.

On Tue, Jul 6, 2010 at 8:42 PM, Alexandru Petrescu <
[email-masked]> wrote:

> the leaving operation is planned and known in advance.

Yes, I agree with it. Actually, for such situations, a direct communication
between two vehicles are extremely required. Here, I'd like to notice that
IEEE 802.11p designed for vehicular communications support its transmission
range up to 1km.

> In other cases

For a highway scenarios where vehicles run along the highway within almost
the same velocity and direction, a direct communication by exchanging MNPs
can be achievable. But, for a city area scenarios where vehicles run in
different velocities and direction, the efficiency of exchanging MNPs may be
not good as we expect. Well, this is because of the unpredictable movements
of vehicles, as you mentioned.

I'd like to encourage you to add some texts regarding some use cases of the
mechanism presented in this draft. Note that I wanted to put such a summary
in our draft ( http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 ), but I
couldn't do that due to many other works.

> remove the "Fixed Scene" reason for 'D' bit, and the associated text.

OK.

> If any other suggestion to clarify the obscurity then I am open to

Yes, I'll give some texts if you're OK.

> This is actually simplified code copied from our implementation of the

OK. I see. Here, I'm a little bit confusing. The source address must be the
link-local address, right? Don't you use the link-layer address for the
routing table?

> needed to solicit the kind of special RA.  Do you have an idea?

I suppose that you can easily reuse the original RS message format with some
additional options as you need.

> It is important to have the MNPs exchanged securely.

Sure. ;-)

> addresses from these MNPs are at risk.

I also agree.

>  CGAs may be harder to adapt to the use of a prefix (less bits than an

Hmmm...I don't think so. Without the use of certificate assigned by a trust
anchor (CA), securing the message involving the MNP is quite limited. OK,
here, I'd note only the use case of SEND approach. In SEND, each node
generates their public and private keys. Then, the public is used in
generating a CGA. Then, the message includes the CGA, CGA parameters, etc
are signed by the private key. Here, the issue is that a malicious node also
can claim that a CGA generated by other node's address (actually not his
address) is the malicious node's one. This issue directly effects on the
mechanism you proposed. The malicious node can send fake RA messages
including fake MNPs. This threats cause the redirect and DoS attacks. Many
other threats are also. How can we prevent it? We need the MNP ownership
(more accurately, the MNP authorization). How to achieve it? Certificate.
;-)

> independent of infrastructure availability.

I'm not sure why you hesitate to use the certificate. Well, the mechanism
proposed in this draft is mainly for vehicular communications. In other
words, we should follow the rule (environment) of ITS, where the PKI (CA and
certificate) is a common way to secure vehicular communications.

Cheers.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Jul 2010 22:34:12 +0200

Le 06/07/2010 22:19, Jong-Hyouk Lee a écrit :
> On Tue, Jul 6, 2010 at 8:42 PM, Alexandru Petrescu
> Hi Jong-Hyouk, thank you for the reply.  I will have to update the
> draft following your comments.
>
> reformed every  morning, and more - are specific vehicular cases
> where the leaving operation is planned and known in advance.
>
>
> Yes, I agree with it. Actually, for such situations, a direct
> communication between two vehicles are extremely required. Here, I'd
>  like to notice that IEEE 802.11p designed for vehicular
> communications support its transmission range up to 1km.

Hmm... it is good to know 802.11p aims for a transmission range of up to
1km... I guess a fixed segment (fixed Access Points?) are involved to
reach that distance with an unlicensed spectrum.

> In other cases such as arbitrary movement of vehicles on a highway
> the leaving operation is less predictable, thus 'D' bit less usable.
>
>
> For a highway scenarios where vehicles run along the highway within
> almost the same velocity and direction, a direct communication by
> exchanging MNPs can be achievable. But, for a city area scenarios
> where vehicles run in different velocities and direction, the
> efficiency of exchanging MNPs may be not good as we expect. Well,
> this is because of the unpredictable movements of vehicles, as you
> mentioned.

That may be right.  With respect to this, we noticed that setting up an
initial vehicle-to-vehicle (MR-to-MR) cell may take some time whereas
dettach-reattach could be relatively fast, to accommodate some
unpredictable movements.

> I'd like to encourage you to add some texts regarding some use cases
>  of the mechanism presented in this draft. Note that I wanted to put
>  such a summary in our draft (
> http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 ), but I couldn't
> do that due to many other works.

WEll yes, I could add use case discussion if needed, no problem.
(although I see this as a separate document).

> Yes, I agree, the text describing how to update the routing table
> may read obscurely and, moreover, it is present at several places in
> the draft.  It may be necessary to detail it more and in a single
> section, probably only in the section "Operation on a Mobile
> Router".
>

Sure.

> 3. In page 6, you describe a scenario of arrival of a new MR. Here, I
> failed to understand the last step of the algorithm executed by the
> newly joining MR: "(5) For each received RA, ... and insert the
> for each received RA extract the [source address] of this RA extract
>  each MNP from this RA for each [MNP] thus extracted insert a routing
>  table entry of the form [MNP;source address]
>
> This is actually simplified code copied from our implementation of
> the mechanism.
>
>
> OK. I see. Here, I'm a little bit confusing. The source address must
>  be the link-local address, right? Don't you use the link-layer
> address for the routing table?

No, we don't use the link-layer address in the routing table but the IP
link-local address (self-formed from the MAC address).  This avoids the
need to dynamically allocate a globally-routable address on the egress
interfaces of the MRs, no need of it.  It also avoids the ULA discussion.

> modified it at all.  It may be the case that an extension of RS may
> be needed to solicit the kind of special RA.  Do you have an idea?
>
>
> I suppose that you can easily reuse the original RS message format
> with some additional options as you need.

Probably yes.
[...]

> Hmmm... well depends, SeND could be extended to use RSA Signature
> Option over a prefix and rightmost filled with 0s, instead of over an
> address. CGAs may be harder to adapt to the use of a prefix (less
> bits than an address), but still.
>
>
> Hmmm...I don't think so. Without the use of certificate assigned by a
> trust anchor (CA), securing the message involving the MNP is quite
> limited. OK, here, I'd note only the use case of SEND approach. In
> SEND, each node generates their public and private keys. Then, the
> public is used in generating a CGA. Then, the message includes the
> CGA, CGA parameters, etc are signed by the private key. Here, the
> issue is that a malicious node also can claim that a CGA generated by
> other node's address (actually not his address) is the malicious
> node's one. This issue directly effects on the mechanism you
> proposed. The malicious node can send fake RA messages including fake
> MNPs. This threats cause the redirect and DoS attacks. Many other
> threats are also. How can we prevent it? We need the MNP ownership
> (more accurately, the MNP authorization). How to achieve it?
> Certificate. ;-)

Hmm.. yes generally speaking certificates could be usable to prove MNP
ownership, it is a useful idea.

In certain contexts where a single operator controls all vehicles
(public transportation is my use case here) the vehicle-to-vehicle
communication could be secured also by the use of a common shared secret
key, no certs.

> Internet connection.  This is something (obtain and verify the certs
>  in a MR connected to Internet on one hand and to another vehicle on
>  another hand) we have tried in practice but not yet sure whether
> it's the right way, because we'd like this RA-MNP mechanism to stay
> completely independent of infrastructure availability.
>
>
> I'm not sure why you hesitate to use the certificate. Well, the
> mechanism proposed in this draft is mainly for vehicular
> communications. In other words, we should follow the rule
> (environment) of ITS, where the PKI (CA and certificate) is a common
>  way to secure vehicular communications.

Hmm... why do I hesitate about certs... I consider currently (in this
context) _only_ vehicles talking to each other and disconnected from the
Internet.  If Internet is not available then certs don't make much
sense, I guess.

I think about this as a feasible first step: to secure RA-MNP without
certs as long as Internet is unavailable in the picture.  When we
consider Internet connected vehicles (another thread, draft?) then certs
may be necessary.

I find difficult to consider the Internet connection to a V2V setting,
right now, because of the addresses - it's hard to decide and agree on
the manner that IP addresses are assigned, distributed among vehicles,
with route updates.

If we get MR-to-MR communication documented in an agreed manner then we
could think about how to add Internet in the picture, using this
MR-to-MR building block.  I am afraid if we consider Internet in the
picture from the beginning we may hit too many disagreements and stop
progress.

Think that now only you and me seem to be agreeing about this MR-to-MR
mechanism...

Alex
PS: ITS - yes, good to follow the ITS recommendation of PKI.  IMHO it's
also good to consider the few scenarios currently outside ITS.

> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>
> wrote:
>
> Dear MEXTers,
>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>