341 lines
18 KiB
TeX
Executable file
341 lines
18 KiB
TeX
Executable file
\documentclass[10pt,conference,twocolumn,final]{IEEEtran}
|
|
|
|
\usepackage{ifluatex}
|
|
\ifluatex
|
|
\usepackage{fontspec}
|
|
\defaultfontfeatures{Ligatures=TeX} % To support LaTeX quoting style
|
|
%\setromanfont{Vollkorn}
|
|
\else
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[utf8]{inputenc}
|
|
\fi
|
|
|
|
\usepackage{clrscode}
|
|
\usepackage{xcolor}
|
|
\usepackage[]{graphicx}
|
|
|
|
% svg conversion support
|
|
\usepackage{ifluatex}
|
|
\ifluatex
|
|
\usepackage{pdftexcmds}
|
|
\makeatletter
|
|
\let\pdfstrcmp\pdf@strcmp
|
|
\let\pdffilemoddate\pdf@filemoddate
|
|
\makeatother
|
|
\fi
|
|
\usepackage[]{svg}
|
|
|
|
\usepackage{acronym}
|
|
\usepackage{hyperref}
|
|
|
|
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
|
|
\newenvironment{changed}{\red}{\color{black}}
|
|
\newcommand{\todo}[1]{ \color{red} \footnote{ \color{red}[#1] \color{black}} \color{black}}
|
|
\newcommand{\Hide}[1]{%
|
|
{
|
|
\parindent0pt
|
|
\emph{\scriptsize #1}
|
|
}
|
|
}
|
|
%\renewcommand{\Hide}[1]{}
|
|
|
|
\newcommand{\documenttitle}{An ETSI look at the State of the Art of pseudonym scheme in Vehicle-to-Everything (V2X) communication}
|
|
|
|
\begin{document}
|
|
|
|
%----------------------------------------------------------------------
|
|
% Title Information, Abstract and Keywords
|
|
%----------------------------------------------------------------------
|
|
\title{\documenttitle}
|
|
|
|
% % %
|
|
% In case of double blind submissions:
|
|
\author{
|
|
\IEEEauthorblockN{Anonymous}
|
|
\IEEEauthorblockA{Some Research Group\\
|
|
Some Institution\\
|
|
Some Email Addresses%
|
|
}
|
|
}
|
|
|
|
%\author{
|
|
% \IEEEauthorblockN{Oliver Schmidt}
|
|
% \IEEEauthorblockA{TU Dresden\\
|
|
% oliver.schmidt3$[$at$]$mailbox.tu-dresden.de%
|
|
% }
|
|
%}
|
|
|
|
|
|
\maketitle
|
|
|
|
% % %
|
|
% sources on writing papers:
|
|
% look for a /good/ outline at the end of this text, the /why/ is found at this link:
|
|
% http://homepages.inf.ed.ac.uk/bundy/how-tos/writingGuide.html
|
|
% http://www-net.cs.umass.edu/kurose/writing/
|
|
% http://www.cs.columbia.edu/~hgs/etc/writing-style.html
|
|
% Read ``Zen - or the art of motorcycle maintenance'' to understand what science and research is
|
|
% Read ``The craft of research'' to /really/ learn how to conduct research and report about it! :-)
|
|
% some hints on plagiarism: http://www.williamstallings.com/Extras/Writing_Guide.html
|
|
% read the text above again. the most important part (that we all tend to forget) is only 5 paragraphs
|
|
|
|
\begin{abstract}
|
|
|
|
\Hide{
|
|
1) Problem statement: The Problem (one is more than sufficient for each paper!)\\
|
|
2) Relevance: Why ist this problem /really/ a problem?\\
|
|
3) Response: What is our solution to the problem?\\
|
|
4) Confidence: how do we show in this paper, that our solution is good?
|
|
}
|
|
\end{abstract}
|
|
|
|
\begin{IEEEkeywords}
|
|
% Are NOT: Peer-To-Peer, Anonymity, Privacy.
|
|
% BUT TAKEN FROM THIS LIST:
|
|
% http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
|
|
Networks, Intelligent transportation systems, Security, Mesh networks, Privacy
|
|
\end{IEEEkeywords}
|
|
% }
|
|
|
|
\maketitle
|
|
|
|
\IEEEpeerreviewmaketitle
|
|
|
|
\section{Introduction}
|
|
|
|
% % %
|
|
% Broad Topic
|
|
\Hide{Broad Topic, potentially little broad background}
|
|
|
|
% \IEEEPARstart{F}{irst} word
|
|
|
|
|
|
% % %
|
|
% Thema, special problem we're looking at, motivation
|
|
% pbly more background for our problem (why is it actually hard?)
|
|
% Broad background, general definitions
|
|
\Hide{Topic, some background}
|
|
|
|
% % %
|
|
% our goal and our claims (what are we solving in this work?)
|
|
\Hide{Our goal, research question, motivation and relevance (Why is it a problem the reader should care about? Why is it hard?)}
|
|
% % %
|
|
% Requirements for our solution
|
|
\Hide{Requirements for a good solution}
|
|
% % %
|
|
% Which metrics can we use to show the quality/quantity of our solution?
|
|
% pbly rough definition of metrics
|
|
\Hide{Metrics to measure how good a solution is}
|
|
|
|
\Hide{\{If space missing the related work may be presented in a paragraph here\}}
|
|
|
|
% % %
|
|
% Summary of our solution
|
|
\Hide{Overview of our solution and first confidence (how do we show that it's good?)}
|
|
|
|
\Hide{Our contributions in this paper}
|
|
|
|
% % %
|
|
% outline of the paper / reader's digest
|
|
\Hide{Reader's digest}
|
|
|
|
- I look only at middle layers \\
|
|
- look at ETSI ITS
|
|
|
|
% % %
|
|
% Literature Survey and Background
|
|
\section{Background}
|
|
\label{sec:background}
|
|
|
|
\subsection{ITS Architecture}
|
|
|
|
This section gives a brief overview of the \ac{ETSI} architecture for Intelligent Transport Systems. It isn't meant to be elaborate but has a focus on identifiers and other message contents allowing linkability of messages.
|
|
|
|
\acp{VANET} have some special requirements: Due to many nodes being constantly on the move at higher speeds, tolerance for quickly changing topologies and low-latency communication are important points. Multi-hop mesh-networking is an important ability to keep the network functional in areas without designated infrastructure.
|
|
|
|
A \ac{VANET} consists of different kinds of ITS stations: \\
|
|
\acfp{OBU} residing inside vehicles can be divided into the communication and \acl{CCU}, managing the \ac{ITS} specific network communication over the car's wireless interfaces, and \acfp{AU} utilising the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack. \\
|
|
On the stationary infrastructure side, \acfp{RSU} can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the internet.
|
|
|
|
The protocol architecture of \ac{ITS} stations according to the \ac{ETSI} reference architecture \cite{europeantelecommunicationsstandardsinstituteetsiETSI3026652010} is mostly based on the well-known \ac{OSI} layer model.
|
|
|
|
\begin{figure}
|
|
% center graphic
|
|
%\centering
|
|
\includegraphics[width=0.51\textwidth]{figures/etsi-its-architecture.png}
|
|
\caption{The ETSI ITS-station reference architecture, based on \cite{europeantelecommunicationsstandardsinstituteetsiETSI3026652010}}
|
|
\label{fig:etsi-its-arch}
|
|
\end{figure}
|
|
|
|
\ac{OSI} layers 1 and 2 are combined into the \textit{Access} layer, \ac{OSI} layers 3 and 4 into the \textit{Networking \& Transport} layer and \ac{OSI} layers 5, 6 and 7 are put into the \textit{Facilities} layer (see Fig. \ref{fig:etsi-its-arch} ). \\
|
|
The two vertical \textit{Management} and \textit{Security} layers provide supporting functionality throughout the whole stack. \textit{Applications} make use of the \ac{ITS}-station services and thus sit on top of it all.
|
|
|
|
\todo{participants, structure, special requirements: changing topology, speed, realtime}
|
|
|
|
Designed for modularity, the \ac{ETSI} \ac{ITS} architecture allows for a big number of access protocols. Similarly, a great variety of applications can run on top of the stack. Because of that variety, these two layers are considered out-of-scope of this survey.
|
|
|
|
The \textbf{Networking \& Transport} layer takes care of addressing and routing of messages within the ITS network and multiplexing them to higher-level services. Similarly to the \ac{OSI} model, the groundwork of this functionality is provided by various networking protocols: \\
|
|
\ac{ETSI} explicitly mentions the usage of \ac{IPv6} (possibly equipped with mobility support), the CALM FAST protocol \cite{TN_libero_mab2} and the \acf{GN} protocol, which can also be used to encapsulate \ac{IPv6} packets.
|
|
|
|
CALM FAST \cite{TN_libero_mab2} is a non-IP port-mapper protocol designed for single-hop communication between ITS stations and extensible with additional features. Due to a lack of proper access to the standard document, this protocol is considered out-of-scope of this survey.
|
|
|
|
\subsubsection{GeoNetworking}
|
|
|
|
\acf{GN} (\cite{europeantelecommunicationsstandardsinstituteetsiETSI30263612014} and following) is an \ac{ETSI}-standardized networking protocol for routing and forwarding packets through \acp{VANET} based on geographical Information. It sits between the link and network layer and provides its services to other networking and transport protocols. The background section of \cite{sandonisVehicleInternetCommunications2016} gives a good high-level overview of the \ac{GN} networking architecture and the rationale behind it.
|
|
|
|
Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS}, for the routing to work. The services provided by \ac{GN} are:
|
|
|
|
\begin{itemize}
|
|
\item geo-unicast: routing a packet to a single node at a specific location
|
|
\item geo-multicast: first routing a packet to a specified destination area, then flooding it to all nodes within that area
|
|
\item topology-scoped broadcast: broadcast of packet within a a certain depth of neighbouring nodes
|
|
\item single-hop broadcast: sending packets to all neighbouring nodes
|
|
\item geo-anycast: routing packet to an arbitrary node within a specified geographical area
|
|
\end{itemize}
|
|
|
|
For this to work, each node maintains a \ac{LT} with the positions of its direct neighbours. This \ac{LT} is populated with information from periodically-sent beaconing messages, advertising a node's position, \ac{GN} address, its speed, station type \todo{check advertised information}. This information is also included in all other sent \ac{GN} packets. \ac{LT} entries have a lifetime attached, after which they expire if not refreshed periodically.
|
|
For allowing to retrieve the position of non-neighbour nodes, the \ac{LS} forwards request packets, until the node with the destination \ac{GN} address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
|
|
|
|
Security properties of \ac{GN} messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausability and consistency. The necessary information for that is given in a security header \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}.
|
|
|
|
\subsubsection{IPv6}
|
|
|
|
\acsu{IPv6} \cite{RFC8200} \nocite{baeckerRFCE014IPv6} specifies the 6th version of the Internet Protocol, the routing protocol used in the Networking layer of the internet. Relevant details for \acp{VANET} are the addressing using 128 bit long IP addresses \cite{RFC4291} with the first up to 64 bits specifiying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable address, nodes are also addressable in the scope of the same \ac{OSI} layer 2 link using their link-local address automatically derived from lower-layer identifiers. Together with the huge number of globally unique \ac{IPv6} addresses, this new property makes it usable for vehicular ad-hoc networks. Another improvement in \ac{IPv6} is the \textit{router advertisement} \cite{RFC4861} of clients, where routers just periodically announce their parameters so clients are able to derive an address themselves without further negotiation.
|
|
|
|
\subsubsection{IPv6 over GeoNetworking}
|
|
|
|
Transparently exposing IP networking to higher layers allows re-using existing services based on the classical internet TCP/IP stack without modification. The \acf{GN6ASL} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} specifies a mechanism for sending \ac{IPv6} packets over the GN protocol by using it as a sub-IP coupling layer. \ac{GN} takes care of encapsulating and routing the IP packet to its final destination node, so that the whole underlying \ac{VANET} looks like a flat layer 2 network to IP services.
|
|
\ac{GN6ASL} specifies how to derive a \ac{GN} address from an \ac{IPv6} address and extends \ac{IPv6} with some \acl{GN} specific extensions like geographic multicast, Geographically
|
|
Scoped stateless Address Configuration or (un)reachability detection.
|
|
|
|
\subsubsection{BTP}
|
|
|
|
The transport layer protocol above \acl{GN} is the \acf{BTP} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636512017}. It provides a connectionless multiplexing/ demultiplexing of datagrams to the layers above, adding minimal overhead while providing an unreliable packet transport comparable to UDP.
|
|
|
|
If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like TCP and UDP from the standard internet protocol suite can of course be used, too.
|
|
|
|
\todo{facilities layer, management and security layer too?}
|
|
|
|
\subsection{Identifiers}
|
|
|
|
There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of relevant identifiers and the information encoded in them. Media-dependent additional identifiers are considered out-of-scope.
|
|
|
|
\subsubsection{GeoNetworking}
|
|
|
|
Each \ac{GN} node is identified by a 64bit GN\_ADDR address \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}, containing information about the \ac{ITS} station type (passenger car, cyclist, pedestrian, \ac{RSU}, …) and 48bit derived from the link-layer address. In case of a pseudonym change, only the latter part is supposed to change.
|
|
|
|
\begin{figure}
|
|
\includegraphics[width=0.47\textwidth]{figures/GeoNetworking_structure.png}
|
|
\caption{structure of an unsecured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
|
|
\label{fig:GNstructure}
|
|
\end{figure}
|
|
|
|
As shown in fig. \ref{fig:GNstructure}, \ac{GN} packets have a basic, a common and an optional extended header. The \textit{basic header} contains information like the packet's maximum lifetime and the remaining hop limit. These information are non-critical for identification. The \textit{common header} also doesn't contain identifying, only the flag indicating a mobile or stationary \ac{ITS} station could slightly reduce the anonymity set. The \textit{extended header} fields depend on the actual \ac{GN} package type and can contain information like the sequence number (initialized with 0) and position vectors.
|
|
|
|
The \ac{LT} is populated with information from beaconing messages and all other messages received by the \ac{ITS} node. \acl{LT} entries also contain identifying data: Additionally to the GN\_ADDR, station type and link-layer address of the peer node it contains a timestamped geographical position (including accuracy), its current speed and its heading. \todo{update position/ reacquire it when changing pseudonym}
|
|
|
|
\begin{figure}
|
|
\includegraphics[width=0.47\textwidth]{figures/GeoNetworking_structure_secured.png}
|
|
\caption{structure of a secured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
|
|
\label{fig:GNstructure_secured}
|
|
\end{figure}
|
|
|
|
Parts of \ac{GN} packets can be secured by wrapping them into security headers as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032017} as shown in fig. \ref{fig:GNstructure_secured}. This service is provided by the vertical security layer in the \ac{ETSI} \ac{ITS} architecture and secures all parts shown in fig. \ref{fig:GNstructure_secured} between security header and trailer according to the chosen security profile. The standard defines security profiles for encrypted, signed, externally signed, and signed encrypted messages.
|
|
|
|
The certificates used contain information about signer subject (name, type, keys), validity restrictions and the actual certificate signature from the \ac{CA}.
|
|
The signer information can be given in form of a digest, certificate or certificate chain.
|
|
|
|
The security trailer contains a signature for verifying authenticity and integrity of the message.
|
|
|
|
\todo{sequence number initialized with 0}
|
|
\todo{packet buffers: LS, forwarding}
|
|
|
|
\subsubsection{BTP}
|
|
|
|
The \ac{BTP} header as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636512017} is only 4 bytes long and has a quite simple structure. \\
|
|
There are 2 modes of operation for BTP: \textit{interactive packet transport} using the BTP-A header, meant for services requiring replies to their messages, and \textit{non-interactive packet transport} using the BTP-B header.
|
|
The BTP-A header consists out of 2 16bit numbers denoting the source and destination ports. The BTP-B header contains the 16bit long destination port and 16bit for optional destination port information (depending on the service).
|
|
Some of the facility layer services have well-known ports assigned in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032016}, so the destination port might identify the service used.
|
|
|
|
\section{Pseudonym Schemes}
|
|
|
|
\subsection{Pseudonym Schemes for ETSI ITS Systems}
|
|
|
|
\subsection{Pseudonym Change Strategies}
|
|
|
|
\subsection{Further Pseudonym Techniques}
|
|
|
|
\section{Evaluation}
|
|
|
|
\subsection{Attacker Model}
|
|
|
|
\section{Summary}
|
|
% % %
|
|
% Theory (probably)
|
|
|
|
% % %
|
|
% Specifications
|
|
|
|
% % %
|
|
% Implementation
|
|
|
|
% % %
|
|
% Evaluation
|
|
|
|
% % %
|
|
% Related work (can be done together with literature survey)
|
|
% STATE HOW THE RELATED WORK RELATES TO YOUR WORK!! (how is it similar, how is it different?)
|
|
% Related work is not your enemy, but gives you ``the shoulders of giants'' you can stand on
|
|
% (and besides: some of the authors might review your paper... ;)
|
|
|
|
% % %
|
|
% Further work and conclusion
|
|
|
|
|
|
\section{Glossary}
|
|
|
|
\nobreak
|
|
|
|
\input{glossary.tex}
|
|
|
|
\bibliographystyle{IEEEtran}
|
|
\bibliography{mybib}
|
|
|
|
%----------------------------------------------------------------------
|
|
|
|
\end{document}
|
|
|
|
|
|
% % %
|
|
% A good outline for a computer science paper (according to Al Bundy)
|
|
%
|
|
% Title
|
|
% * - ideally the title should state the hypothesis of the paper
|
|
%
|
|
% Abstract
|
|
% * - state hypothesis and summarise the evidence that supports or refutes it
|
|
%
|
|
% Introduction
|
|
% * - motivate the contribution!
|
|
%
|
|
% Literature Survey
|
|
% * - broad and shallow account of the field, rival approaches, drawbacks of each, major outstanding problems
|
|
%
|
|
% Background
|
|
% * - states previous work in more detail, where this is necessary for understanding
|
|
%
|
|
% Theory
|
|
% * - underlying theory, definitions, theorems etc.
|
|
%
|
|
% Specification
|
|
% * - requirements and specs of implementation
|
|
%
|
|
% Implementation Evaluation Related Work
|
|
% * - narrow but deep comparison with main rivals
|
|
%
|
|
% Further Work Conclusion
|
|
% * - summarise research, discuss significance, restate hypothesis and the evidence for and against it, - recapitulate original motivation, reassess the state of the field in the light of this new contribution
|
|
%
|
|
% Appendices
|
|
%
|