Automotive Industry Requirements for NEMO Route Optimization IETF71, MEXT WG 12/03/2008 draft-ietf-mext-nemo-ro-automotive-req-00 Roberto Baldessari Thierry Ernst Andreas Festag Massimiliano Lenardi

Background Several automotive projects and consortia are looking at NEMO for deployment of vehicular networks ISO CALM and ETSI TC ITS to request liasons with IETF Draft initiated by C2C-CC, now gathering input from ISO and ETSI too Deployments already presented in past meetings (see MEXT interim meeting 7/02/2008) here focusing only on the requirements

RO Scenarios Highest priority to non-nested NEMO RO case NEMO MR runs on automotive On-board Units (OBU), embedded into car’s electronics CE classification: 1.Another vehicle 2.Dedicated node in the infrastructure a.On the roadside (topologically close to MR) b.In the Internet 3.Arbitrary node in the Internet

Req 1: Separability Switching to RO is subject to policy table Policies include MNP and end points addresses Policies may change dynamically (affecting establishment of new RO sessions) Rationales: avoiding unnecessary RO sessions RO establishment not always worth (external information used to set the policies) privacy protection

Req 2: Security As a minimum security feature, MNP ownership should be checked against off-path attackers I.e. if more sophisticated protection is not applicable, a RR- like procedure is minimum req Req to be extended for better protection -> feedback is needed Automotive MRs likely to be equipped with certificates based on PKI (to be harmonized among different consortia) Given that, the req could include authentication of RO signaling verification of ownership based on the certificate

Req 3: Privacy Protection Exposing the MNP must be limited to CE (obviously) nodes on the path MR-CE Better protection desirable -> feedback is needed If PKI in place, existing IPsec techniques should be applicable to MR-CE

Req 4: Multihoming RO technique must not prevent different NEMO multihoming configurations from working (RFC 4980) (1,n,n): different purpose MNPs/HAs (n,1,1): additional MR added in later stage (n,n,n): combination of the previous

Req 5: Efficient Signaling Signaling for establishment of RO as small as possible Text in the draft outdated we want to remove maximum number of signaling messages and keep the req generic Criterion to choose among different RO solutions

Req 6: Switching HA HA switch considered in ISO CALM, not in C2C-CC RO should not prevent it from working Details not yet available To be provided in next version