Subject: Re: [MEXT] few questions about draft-baldessari-c2ccc-nemo-req-01

From: "Roberto Baldessari" <[email-masked]>
Date: Tue, 5 Feb 2008 22:55:35 +0100

Hi Marcelo,

thanks for the comments, please see inline 

> 
> Hi,
> 
> i have been reading this document and the first question that 
> i have is that if i understood correctly, the main scope of 
> the usage of nemo in this scenario is for non safety 
> communications with any arbitrary node in the Internet, right?
> 

Not only.
NEMO in C2C is meant to be used to talk either to an arbitrary node in the Internet or to a newly deployed node for automotive applications.

> If that is the case, i think it is kind of strange that the 
> use case considered in section 5 which mainly focused in the 
> conept of CR:
> 
>   The requirements defined in this document refer to RO between MR and
>     CR (Correspondent Router).  According to C2C-CC use 
> cases, the CR can
>     be:
> 
>     o  a NEMO MR.  For example the MR running on another vehicle or
>        another mobile device connected to the Internet;
> 
>     o  a RO-enabled router, i.e. a router static or mobile 
> that does not
>        act as NEMO MR but is capable of establishing RO sessions with
>        NEMO MRs.  For example the access router serving a CN in the
>        infrastructure that offers services to vehicles, or the access
>        router serving RSUs installed along the road;
> 
> I think this kind of assumes a solution, i.e. the existance 
> of a CR, which does not exists today. I guess that if the 
> goal of the usage of nemo is mainly communications with node 
> in the internet, the makor usage case would be to talk with 
> any CN, rather than to a CR.
> 

Right, this usage of the term CR is not clear and probably breaks RFC 4885.
This was already pointed out at IETF-69 (no new version has been submitted since then). 
I proposed to change CR into CE. And CE can be one of these:

1) a NEMO MR
2) a router (not a MR) implementing NEMO RO
3) a CN, i.e. IPv6 host
4) a MIPv6 CN

What do you think?

BTW Regarding solution space, we did not want to restrict it but on the contrary make it wider (in the bullet you omitted from the above text, we wrote that a CR can be "a RO-enabled router collapsed into the CN")

> Next, in section
> 
> 6.3. Req 3 - RO Security
> 
> 
>     A RO technique MUST prevent malicious nodes to claim false MNP
>     ownership.  In order to achieve this, a RO technique MAY 
> make use of
>     security features provided by the sub-IPv6 C2C-CC Network 
> layer (e.g.
>     cryptographic protection), but it MUST NOT introduce new security
>     leaks for the C2C-CC applications or render their 
> security measures
>     ineffective.
> 
> I fail to understand this one.
> first, as i understand it, the goal is to run ro between 
> nodes in the nemo and any node in the internet. In this case, 
> it seems hardly useful to use the C2C network interface, 
> since i doesn't seems that any node in the internet will use 
> the C2C network layer. 

A similar comment was made during IETF-69. We will remove in the next version references to C2C-CC security features wrt to this requirement. So we will keep only the first sentence of the req.

The background of this text was that C2C is going anyway to implement security features probably based on certificates issued by a CA. We thought that RO security might take advantage of this in the case of MR-MR via 802.11p (excluding the MR-CN and the WLAN cases). But it doesn't seem possible as it is a too particular case.

> Moreover, if i udnerstood correctly, 
> the IPv6 layer can use directly the WLAN interface in the 
> vehicle so, we cannot rely on the C2C network layer since it 
> may not be ther.
> 

See previous comment.

> With respect to:
> 
> 6.5. Req 5 - Multihoming
> 
> Do you need to support multiple MRs in the same nemo? it 
> seems you don't because you seem to assume a single OBU, right?
> 
Right. 1 OBU per vehicle is the C2C-CC approach.

> I guess that the OBU may have multiple technologies, but it 
> deosn't seem to me that the nemo RO for non safety 
> application will be able to use them, so it seems that the 
> OBU for non safety usage will only be able to use the WLAN, 
> so, how come that multihoming is needed? I mean, you have a 
> single MR and you have a single technology, i guess that the 
> possibility is that you will be attached to different WLAN 
> simoultaneously? is that the scenario that you have in nmind?

No. In the protocol stack depicted in the draft (Figure 2), IPv6 is used over C2C-CC NET/11p and over WLAN. So, a node has 2 IPv6 interfaces (one virtual, one real). This is already a possibly multihomed MR (i.e. if the MR is attached to a 802.11p RSU and a public WLAN hotspot). Additional technologies that are not in the current focus of C2C-CC might come later (e.g. 3G). This is why RO must be compatible with multihoming.

> Moreover, are you considering the case with multiple HAs?
> 

Multiple HAs is not currently a priority for C2C. Reallocating HAs has benefits but having a standard RO solution that works even with 1 HA should come first. 

Best regards,

Roberto

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 6 Feb 2008 16:13:33 +0100

below...

El 05/02/2008, a las 22:55, Roberto Baldessari escribió:

> NEMO in C2C is meant to be used to talk either to an arbitrary node  
> in the Internet or to a newly deployed node for automotive  
> applications.
>

but non safety critical applications from what i understood in draft...

My point is that i see these are two very different scenarios (and i  
think the c2c also shares this)

On one hand you have the safety critical coomunications, which have  
important reliability, security  fault toelrance requirements, since  
safety is involved. However, i think they have a completelly different  
trust model. I mean, it seems to me that cars only need to have safety  
communications with a reduced set of CNs, which normally are operated  
by a very reduced set of entities, police, fire men and so on.

OTOH, entertainment communications are very different. They don't have  
si much requirements in terms of security, reliabilty as the previous  
ones, but the trust model is compeltelly different. You need to be  
able to talk with anyone in the Internet.

So, it would importnat imho to understand what we are targetting the  
solution for.

So far, i have unserstood that safety comunications will use the c2c  
network layer, so the nemo will be restricted to the entertainment.

This is very vaguely defined in the draft. I think the draft should  
clearly state what scenario you have in mind (safety or non safety  
communications)

> 2) a router (not a MR) implementing NEMO RO

makes sense to me

> BTW Regarding solution space, we did not want to restrict it but on  
> the contrary make it wider (in the bullet you omitted from the above  
> text, we wrote that a CR can be "a RO-enabled router collapsed into  
> the CN")
>
>
>
>> Next, in section
>>
>> 6.3. Req 3 - RO Security
>>
>>
> A similar comment was made during IETF-69. We will remove in the  
> next version references to C2C-CC security features wrt to this  
> requirement. So we will keep only the first sentence of the req.
>
> The background of this text was that C2C is going anyway to  
> implement security features probably based on certificates issued by  
> a CA. We thought that RO security might take advantage of this in  
> the case of MR-MR via 802.11p (excluding the MR-CN and the WLAN  
> cases). But it doesn't seem possible as it is a too particular case.
>

right

> No. In the protocol stack depicted in the draft (Figure 2), IPv6 is  
> used over C2C-CC NET/11p and over WLAN.

No.

in the picture include in the draft it seems to me that IPv6 is only  
used in WLAN, while C2C network is used both in 802.11p and WLAN.

if this is not the case, you may wnat to clarify it

> So, a node has 2 IPv6 interfaces (one virtual, one real).

you mean one directly to the WLAN and the other one through the C2C  
network layer?

> This is already a possibly multihomed MR (i.e. if the MR is attached  
> to a 802.11p RSU and a public WLAN hotspot). Additional technologies  
> that are not in the current focus of C2C-CC might come later (e.g.  
> 3G). This is why RO must be compatible with multihoming.
>

right. My point is that if we are using nemo only for non safety  
communications and these communications only go through WLAN, then  
even though the MR has multiple technologies, from the perspective of  
the usage of nemo,the MR only have one technology, which is WLAN, if  
you see what i mean

> Multiple HAs is not currently a priority for C2C. Reallocating HAs  
> has benefits but having a standard RO solution that works even with  
> 1 HA should come first.
>

good

Regards, marcelo

---

From: "Roberto Baldessari" <[email-masked]>
Date: Wed, 6 Feb 2008 19:37:32 +0100

Marcelo,

See below 

[removed some text]

> > Not only.
> > NEMO in C2C is meant to be used to talk either to an 
> arbitrary node in 
> > the Internet or to a newly deployed node for automotive 
> applications.
> >
> 
> My point is that i see these are two very different scenarios 
> (and i think the c2c also shares this)
> 
> On one hand you have the safety critical coomunications, 
> which have important reliability, security  fault toelrance 
> requirements, since safety is involved. However, i think they 
> have a completelly different trust model. I mean, it seems to 
> me that cars only need to have safety communications with a 
> reduced set of CNs, which normally are operated by a very 
> reduced set of entities, police, fire men and so on.
> 
> OTOH, entertainment communications are very different. They 
> don't have si much requirements in terms of security, 
> reliabilty as the previous ones, but the trust model is 
> compeltelly different. You need to be able to talk with 
> anyone in the Internet.
> 
> So, it would importnat imho to understand what we are 
> targetting the solution for.
> 
> So far, i have unserstood that safety comunications will use 
> the c2c network layer, so the nemo will be restricted to the 
> entertainment.
> 
> This is very vaguely defined in the draft. I think the draft 
> should clearly state what scenario you have in mind (safety 
> or non safety
> communications)
> 

We wrote an entire sub-section to state that NEMO in C2C is limited to non-safety.
I'm refering to Section 4.1 "Scope of NEMO".

It says:
"...This implies that the usage of NEMO in vehicular
   communications does not target safety-of-life applications but rather
   less restrictive, non-safety applications."

I think this is clear enough and you just missed it. 

> the usage of nemo,the MR only have one technology, which is WLAN, if  

Here is probably the misunderstanding.
C2C NET layer can be used for both safety and non-safety. NEMO will not be used for safety. IPV6 can be used over C2C NET to enjoy multi-hop access and over WLAN to enjoy (single-hop) public hotspot access.

I will try to make this clearer in the draft.

Regards,

Roberto