identifiers for GeoNetworking, certs and BTP
This commit is contained in:
parent
d35df3f15b
commit
996d11bfd8
BIN
figures/GeoNetworking_structure.png
Normal file
BIN
figures/GeoNetworking_structure.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 10 KiB |
BIN
figures/GeoNetworking_structure_secured.png
Normal file
BIN
figures/GeoNetworking_structure_secured.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 13 KiB |
|
@ -6,6 +6,8 @@
|
|||
|
||||
\acro{BTP}{Basic Transport Protocol}
|
||||
|
||||
\acro{CA}{Certificate Authority}
|
||||
|
||||
\acro{CCU}{communication \& control unit}
|
||||
|
||||
\acro{ETSI}{European Telecommunications Standards Institute}
|
||||
|
@ -22,8 +24,12 @@
|
|||
|
||||
\acro{LS}{GeoNetworking Location Service}
|
||||
|
||||
\acro{LLC}{Logical Link Control}
|
||||
|
||||
\acro{LT}{GeoNetworking Location Table}
|
||||
|
||||
\acro{MAC}{Medium Access Control}
|
||||
|
||||
\acro{OBU}{on-board unit}
|
||||
|
||||
\acro{OSI}{Open Systems Interconnection}
|
||||
|
|
37
main.tex
37
main.tex
|
@ -183,7 +183,7 @@ CALM FAST \cite{TN_libero_mab2} is a non-IP port-mapper protocol designed for si
|
|||
|
||||
\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:
|
||||
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
|
||||
|
@ -218,16 +218,45 @@ If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like
|
|||
|
||||
\subsection{Identifiers}
|
||||
|
||||
There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of these identifiers and the information encoded in them.
|
||||
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 \ac{GN} address
|
||||
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.
|
||||
|
||||
\ac{GN} packets have a basic, a common and an optional extended header.
|
||||
\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}
|
||||
|
|
|
@ -447,4 +447,13 @@
|
|||
note = {http://www.rfc-editor.org/rfc/rfc4861.txt}
|
||||
}
|
||||
|
||||
@misc{europeantelecommunicationsstandardsinstituteetsiETSITS1032016,
|
||||
title = {{{ETSI TS}} 103 248 {{V1}}.1.1 {{Intelligent Transport Systems}} ( {{ITS}} ); {{GeoNetworking}}; {{Port Numbers}} for the {{Basic Transport Protocol}} ({{BTP}})},
|
||||
lccn = {ETSI TS 103 248 V1.1.1},
|
||||
author = {{European Telecommunications Standards Institute (ETSI)}},
|
||||
month = nov,
|
||||
year = {2016},
|
||||
file = {/home/spiollinux/Zotero/storage/U3RMDZ2I/ts_103248v010101p.pdf}
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue