Security Problem statement for IP Wireless Access in Vehicular Environments
draft-qi-ipwave-vehicle-security-00

Document Type Active Internet-Draft (individual)
Last updated 2017-03-13
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
IPwave Working Group                                          Minpeng Qi
Internet-Draft                                              China Mobile
Intended Status: Informational
Expires: September 10, 2017                                March 10, 2017 
                                                            

  Security Problem statement for IP Wireless Access in Vehicular Environments
                      draft-qi-ipwave-vehicle-security-00

Abstract

   This document specifies security problem about IP wireless access in 
   vehicular environment.It also raise requirements for IPwave as 
   guideline for further security solutions design. At last, using typical
   IPsec/TLS solution in IPwave are evaluated.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Minpeng Qi               Expires September 10, 2017             [Page 1]

Internet-Draft  Security Problem Statement for IPwave      March 10, 2017

   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Message Protection Consideration  . . . . . . . . . . . . . . .  3
   4  Identity Protection Consideration . . . . . . . . . . . . . . .  4
   5  Current solution analysis . . . . . . . . . . . . . . . . . . .  4
   5.1  IPsec/TLS with Pre-shared key . . . . . . . . . . . . . . . .  4
   5.2  IPsec/TLS with certificate  . . . . . . . . . . . . . . . . .  5
   6  Security Consideration  . . . . . . . . . . . . . . . . . . . .  6
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  6
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   8.1  Normative References  . . . . . . . . . . . . . . . . . . . .  6
   8.2  Informative References  . . . . . . . . . . . . . . . . . . .  6
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

   

   

   

   

   
   
   

Minpeng Qi               Expires September 10, 2017              [Page 2]

Internet-Draft  Security Problem Statement for IPwave       March 10, 2017

1  Introduction

   Under IPwave scenario, a vehicle node usually connects other nodes by 
   using an IP address. The other node could be another vehicle, or a 
   server/infrastructure node with IP address. In this case, communication
   data could be eavesdropped, modified or forged by the attacker as same 
   as attacks happened in other IP connection. Therefore, IPwave 
   communication must be protected. The protection must consider 
   confidentiality and integrity for unicast and multicast. 
   The protection also need to provide authenticity and privacy for 
   IPwave communication.

   
   
2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3  Message Protection Consideration

   When a vehicle communicates with another vehicle or RSU. An attacker
   can sniff the communication nearby. If there is no confidential 
   protection. The attacker could get all information. Although vihecles
   are usually moving, attacker who want to collect information from
   specific vehicle can drive a car and follow the target. If attacker
   want to get general information rather than from specific vehicle, he
Show full document text