implement suggested changes from 2nd feedback
This commit is contained in:
parent
6fcb77fd6e
commit
de1af68ea4
18
glossary.tex
18
glossary.tex
|
@ -1,14 +1,16 @@
|
|||
\todo{include long version of abbreviations at first mention}
|
||||
|
||||
\begin{acronym}[GN6ASL]
|
||||
|
||||
\acro{AU}{application unit}
|
||||
\acro{AA}{Authorization Authority}
|
||||
|
||||
\acro{AU}{Application Unit}
|
||||
|
||||
\acro{BTP}{Basic Transport Protocol}
|
||||
|
||||
\acro{CA}{Certificate Authority}
|
||||
|
||||
\acro{CCU}{communication \& control unit}
|
||||
\acro{CCU}{Communication \& Control Unit}
|
||||
|
||||
\acro{EA}{Enrolment Authority}
|
||||
|
||||
\acro{ETSI}{European Telecommunications Standards Institute}
|
||||
|
||||
|
@ -32,16 +34,16 @@
|
|||
|
||||
\acro{MAC}{Medium Access Control}
|
||||
|
||||
\acro{OBU}{on-board unit}
|
||||
\acro{OBU}{On-Board Unit}
|
||||
|
||||
\acro{OSI}{Open Systems Interconnection}
|
||||
|
||||
\acro{RA}{Router Advertisement}
|
||||
|
||||
\acro{RSU}{road-site unit}
|
||||
\acro{RSU}{Road-Site Unit}
|
||||
|
||||
\acro{VANET}{vehicular ad-hoc network}
|
||||
\acro{VANET}{Vehicular Ad-Hoc Network}
|
||||
|
||||
\acro{V2X}{vehicle-to-everything}
|
||||
\acro{V2X}{Vehicle-to-Everything}
|
||||
|
||||
\end{acronym}
|
||||
|
|
14
main.tex
14
main.tex
|
@ -216,13 +216,13 @@ If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like
|
|||
|
||||
The \textbf{Facilities Layer} unifies the three upper \ac{OSI} layers (application, presentation, session layer) and provides different support tasks to services and applications like time management, position management, database management and session management. It is also responsible to manage service priorities when passing down data to the Network and Transport Layer.
|
||||
|
||||
The \textbf{Security Layer} is a vertical layer providing security functionality like identity, key and certificate management to all other layers. It also executes all cryptographic functions like encryption or verification of data.
|
||||
The \textbf{Security Layer} is a vertical layer providing security functionality like identity, key and certificate management to all other layers. It also contains all cryptographic functions like encryption or verification of data.
|
||||
|
||||
The \textbf{Management Layer} takes care of software changes like updates and installation of additional components and is considered out-of-scope of this survey.
|
||||
|
||||
\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.
|
||||
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, that means bound to a certain physical or data link layer, additional identifiers are considered out-of-scope.
|
||||
|
||||
\subsubsection{GeoNetworking}
|
||||
\label{GN-identifiers}
|
||||
|
@ -231,21 +231,21 @@ Each \ac{GN} node is identified by a 64bit GN\_ADDR address \cite{europeanteleco
|
|||
|
||||
\begin{figure}
|
||||
\includegraphics[width=0.47\textwidth]{figures/GeoNetworking_structure.png}
|
||||
\caption{structure of an unsecured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
|
||||
\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.
|
||||
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.49\textwidth]{figures/GeoNetworking_structure_secured.png}
|
||||
\caption{structure of a secured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
|
||||
\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.
|
||||
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.
|
||||
|
@ -264,7 +264,7 @@ Some of the facility layer services have well-known ports assigned in \cite{euro
|
|||
|
||||
\subsubsection{IPv6}
|
||||
|
||||
While each IPv6-capable network interface can have multiple addresses, it has at least one link-local address with the interface ID (the lower 64bits) uniquely derived from its data-link layer address. The mapping of IPv6 link-local address and GN\_ADDR is straight-forward, as both addresses are deterministically derived from the same 48bit link layer address. Additionally to the IPv6 address, the IPv6 header can also contain a 20bit \textit{flow label} which could lead to partial linkability of packets even after an address change.
|
||||
While each IPv6-capable network interface can have multiple addresses, it has at least one link-local address with the interface ID (the lower 64bits) uniquely derived from its data-link layer address. The mapping of IPv6 link-local address and GN\_ADDR is straight-forward, as both addresses are deterministically derived from the same 48bit link layer address. Additionally to the IPv6 address, the IPv6 header can also contain a 20bit \textit{flow label} \cite{RFC6437} which could lead to partial linkability of packets even after an address change: Although a flow shall be identified by the triplet of flow label, source and destination address, an equal flow label could indicate the resumption of a connection even after an address change.
|
||||
|
||||
There exists a static mapping between IPv6 multicast groups and geographical areas (relative to the station). That means it is possible to contact IPv6-based services within a node's surrounding. But as this mapping is static and relative, it shouldn't help reidentifying hosts.
|
||||
\acfp{GVL} are another important concept for understanding the visibility scope of IPv6 packets to other nodes. These virtual links are defined as non-overlapping, restricted geographical areas wherein all IPv6 multicasts within the same subnet are forwarded via \ac{GN} to all nodes of that \ac{GVL}. Usually this is a zone around a specific \ac{RSU} serving as an internet uplink and thus managing the whole subnet and its addresses. Globally routable IPv6 addresses are usually obtained via the stateless autoconfiguration with the help of \acp{RA}. So changing the \ac{GVL} means getting another IPv6 prefix announced via \ac{RA} and thus implies a change in the node's global IPv6 address.
|
||||
|
|
14
mybib.bib
14
mybib.bib
|
@ -25,7 +25,7 @@
|
|||
author = {{European Telecommunications Standards Institute (ETSI)}},
|
||||
month = jun,
|
||||
year = {2012},
|
||||
keywords = {standards,unread},
|
||||
keywords = {standards,unread,pseudonyms},
|
||||
file = {/home/spiollinux/Zotero/storage/QTWZ48M8/ts_102941v010101p.pdf}
|
||||
}
|
||||
|
||||
|
@ -456,4 +456,16 @@
|
|||
file = {/home/spiollinux/Zotero/storage/U3RMDZ2I/ts_103248v010101p.pdf}
|
||||
}
|
||||
|
||||
@techreport{RFC6437,
|
||||
type = {{{RFC}}},
|
||||
title = {{{IPv6 Flow Label Specification}}},
|
||||
number = {6437},
|
||||
institution = {{RFC Editor}},
|
||||
author = {Amante, S. and Carpenter, B. and Jiang, S. and Rajahalme, J.},
|
||||
month = nov,
|
||||
year = {2011},
|
||||
issn = {2070-1721},
|
||||
howpublished = {Internet Requests for Comments}
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue