TLS Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Experimental
July 16 2017
Expires: January 2018
LLCPSdraft-urien-tls-llcp-10.txt
Abstract
This document describes the support of the TLS protocol over the NFC
(Near Field Communication) LLCP (Logical Link Control Protocol)
layer, which is referred as LLCPS. The NFC peer to peer (P2P)
protocol may be used by any application that needs communication
between two devices at very small distances (a few centimeters).
LLCPS enforces a strong security in NFC P2P exchanges, and may be
deployed for many services, in the Internet of Things (IoT)
ecosystem, such as payments, access control or ticketing operations.
Applications secured by LLCPS are identified by the service name
"urn:nfc:sn:tls:service".
Requirements Language
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 2018.
.
Urien Expires January 2018 [Page 1]

Copyright Notice
Copyright (c) 2017 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
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.
Urien Expires January 2018 [page 2]

LLCPS July 20171 Overview1.1 About the NFC protocol
The Near Field Communication protocol (NFC) is based on standards
such as [ECMA340] or [ISO/IEC 18092]. It uses the 13,56 MHz
frequency, with data rates ranging from 106 To 848 kbps. The working
distance between two nodes is about a few centimeters, with
electromagnetic fields ranging between 1 and 10 A/M.
There are two classes of working operations:
- Reader/Writer and Card Emulation. A device named "Reader" feeds
another device called "Card", thanks to a 13,56 MHz electromagnetic
field coupling. This mode is typically used with [ISO7816]
contactless smartcards or with NFC RFIDs.
- Peer To Peer (P2P). Two devices, the "Initiator" and the "Target"
establish a NFC communication link. In the "Active" mode these two
nodes are managing their own energy resources. In the "Passive" mode
the Initiator powers the Target via a 13,56 MHz electromagnetic
field coupling.
This draft focuses on P2P security, which is required by many
applications, targeting access control, transport, or other Internet
of Things (IoT) items. Although the NFC protocol enables data
exchange at small physical distances, it doesn't support
standardized security features providing privacy or integrity. Thus,
protocols such as [SNEP] or [NPP], whose goal is to push NDEF [NDEF]
contents, are not today secured. In this draft we define a profile
for TLS support in P2P operations.
A P2P session (see figure 1) occurs in four logical phases:
1) Initialization and Anti-collision. The Initiator periodically
sends a request packet (and therefore generates a RF field), which
is acknowledged by a Target response packet. Because several Targets
may be located near the Initiator, an anti-collision mechanism is
managed by the Initiator in order to establish a session with a
single Target.
2) Protocol Activation and Parameters Selection. The Initiator
starts a logical session with a detected Target by sending a ATR-REQ
(Attribute-Request) message, which is confirmed by a Target ATR-RESP
(Attribute-Response) message. These messages fix the device IDs
(DIDi, Device ID Initiator and DIDt, Device ID Target) used in
further packet exchanges. Optional information fields (Gi for the
Initiator, and Gt for the Target) identify the protocol to be used
over the MAC level; in this document it is assumed that the LLCP
[LLCP] (Logical Link Control Protocol) protocol is selected by the
Gi and Gt bytes. Optionally some parameters are negotiated by
additional packets.
Urien Expires January 2018 [Page 5]

LLCPS July 2017
3) Data Exchange. Frames are exchanged via the DEP (Data Exchange
Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted
by the Initiator and DEP-RESP (DEP-Response) delivered by the
Target. DEP provides error detection and recovery. It uses small
data unit size (from 64 to 256 bytes); however it supports a
chaining mode for larger sizes. DEP frames typically transport LLCP
packets, and provide an error free service
4) De-Activation. The Initiator may deactivate the Target by sending
a RLS-REQ (Release Request) message acknowledged by a RLS-RESP
(Release Response).
Usually, and for practical reasons, P2P sessions are established
between a unique Target and an Initiator, for example a mobile phone
and another NFC device. They are automatically started when the
distance between the two NFC modes is sufficiently small. The MAC
link may be broken at any time, as soon as the distance disables
radio operations.
Initiator Target
| |
|<------ (1) Initialization and Anti-Collision ------->|
| |
|<- (2) Protocol Activation and Parameters Selection ->|
| ------------------- ATR-REQ -----------------------> |
| <------------------ ATR-RESP ----------------------- |
| |
|<---------------- (3) Data Exchange ----------------->|
| LLCP packets over DEP frames |
| TLS over LLCP |
| |
|<----------------(4) De-Activation ------------------>|
| |
Figure 1. A NFC P2P Session
Due to the dissymmetry of the DEP protocol (see figure 2), in which
the Initiator sends requests and Target returns responses, the NFC-
P2P MAC services are dissymmetric on the Initiator and Target sides.
- The Initiator delivers Data.Request-i and gets Data.Indication-i.
- The Target gets Data.Indication-t and delivers Data.Request-t
MAC services implemented by NFC controllers usually support such
dissymmetric primitives for Initiator and Target procedures (MAC
Data.request-i/t and Data.Indication-i/t).
The timeout value (between DEP-REQ and DEP-RESP messages) is deduced
from the RWT attribute (Response Waiting Time) returned by the
Target in the ATR-RESP message. RWT ranges between 0,6 ms and 9,9
ms. It may be extended to the RWT-INT by a factor RTOX (RWT-INT =
RTOX x RWT) between 1 and 60, so the maximum value is about 6s.
Urien Expires January 2018 [Page 6]

LLCPS July 2017
Initiator Target
| | | |
| | | |
| Data.Request-i --- DEP-REQ --> Data.Indication-t |
| | |
| RWT-INT ms |
| | |
Data.Indication-i <---- DEP-RESP --------- Data.Request-t
Figure 2. NFC-P2P MAC layer service, based on DEP frames
1.2 The LLCP layer
The LLCP [LLCP] protocol works like a light LLC [IEEE 802.2] layer.
It provides two classes of services, connectionless transport and
connection-oriented transport.
This draft focuses both on connection-oriented transport, in which
TLS services are identified by a Service Name (SN), and on non-
connected mode, in which a fix (well-known) Service Access Point
(SAP) is used.
A LLCP packet (see figure 3) comprises three mandatory fields, DSAP
(Destination Service Access Point, 6 bits), SSAP (Source Service
Access Point, 6 bits), and PTYPE (Protocol data unit type field, 4
bits).
An optional sequence field (8 bits) contains two 4 bits number N(S)
and N(R) respectively giving the number of the information SDU to be
sent and the number of the next information PDU to be received.
An optional Information field transports the LLCP payload.
<--------------LLCP Header--------------><-LLCP Payload ->
| DSAP | PTYPE | SSAP | Sequence | INFORMATION |
| 6 bits | 4 bits | 6 bits | 0 or 8 bits | M x 8 bits |
Figure 3. Structure of an LLCP packet
There are sixteen types of LLCP packets, identified by PTYPE values
ranging between 0 and 15. In this draft we use only nine of these
PDUs.
1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, No Sequence, No
Information). This PDU is produced as soon as there is no
information to provide. This mechanism avoids timeout at the MAC
(DEP) level. SYMM SHOULD be generated after an inactivity period of
about LTO/2, where LTO is the link timeout.
Urien Expires January 2018 [Page 7]

LLCPS July 2017
2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU
MUST include a SN (service name parameter) that identified the TLS
service ("urn:nfc:sn:tls:service"). It uses a DSAP value set to 1
(the SAP of the Service Discovery Protocol, SDP) and a SSAP value
ranging between 16 and 31. It indicates the connection the well-
known service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral
SAP (SAP-client) ranging between 16 and 31.
3) Connection Complete (CC, PTYPE=6, No sequence, Optional
Information). This PDU notifies the successful connection to the
"urn:nfc:sn:tls:service" service. It allocates the SAP (DSAP=SAP-
client) to be used for this session identified by the tuple (SAP-
server, SAP-client)
4) Disconnection (DISC, PTYPE=5, No sequence, No Information). This
PDU indicates the disconnection of the (SAP-server, SAP-client)
session. Null SAP values MAY be used to notify the disconnection of
the LLCP entity.
5) Disconnected Mode (DM, TYPE=7, No sequence, one byte of
Information). This PDU confirms the disconnection of the (SAP-
server, SAP-client) session; one information byte gives the
"Disconnected Mode Reasons". Null SAP values notify the
disconnection of the LLCP entity.
6) Information (INFORMATION, PTYPE=10, Sequence, information). This
PDU transport a SDU; N(S) indicates the SDU number, N(R) indicates
the next SDU number to be received. In this draft the Receive
Windows Size (RW) MUST be set to one, which is the default LLCP
value.
7) Receive Ready (RR, PTYPE=11, sequence N(R) only, no Information).
This PDU is used for the acknowledgment of previously received
information PDU. It indicates the next sequence number (N(R)) to be
received.
8) Receive Not Ready (RNR, PTYPE=12, sequence N(R) only, no
Information).This PDU indicates a temporary inability to process
subsequent information PDUs.
9) Unnumbered Information (UI, PTYPE=3, no Sequence, Optional
Information). This PDU is used to transfer service data units to the
peer LLC without prior establishment of a data link connection.
According to [LLCP] some LLCP functional parameters are updated by
LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ
and ATR-RESP messages. Parameters are encoding according to TLV
format, in which Type size is one byte, Length size is one byte and
Value is a set of L bytes. In this document we use 6 parameters.
Urien Expires January 2018 [Page 8]

LLCPS July 2017
1) Version Number (VERSION, T=01h, L=01h, V=10h). In this document
this option MUST be included in the general bytes of ATR-REQ and
ATR-RESP.
2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This
parameter extends the maximum size of the LLCP PDU (MIU), whose
default value is 128 bytes, according to the relation: MIU = MIUX +
128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ
and ATR-RESP, and in LLCP PDUs CONNECT and CC.
3) Well-Known Service List (WKS, T=03h, L=02h). This parameter
associates a bit to the instance of a well-known LLCP parameter. A
typical value is 00001h, indicating the availability of the DSP
service. WKS MAY be inserted in general bytes of ATR-REQ and ATR-
RESP.
4) Link Timeout (LTO, T=04h, L=01h). This parameter indicates the
timeout value for the LLCP layer, in multiples of 10ms. LTO MAY be
inserted in general bytes of ATR-REQ and ATR-RESP.
5) Receive Windows Frame (RW, T=05h, L=01h). This parameter
indicates the size of the receive windows, its value ranges between
0 and 15. The default value is one, and MUST be set to one according
to this document. It MAY be inserted in LLCP PDUs CONNECT or CC.
6) Service Name (SN, T=06h). This parameter indicates the name of a
service. It MUST be inserted in the CONNECT PDU. In this document
its value is set to "urn:nfc:sn:tls:service", where "service" is the
application name securely transported by TLS.
1.3 LLCPS basic guidelines
The TLS protocol is a series of record messages, which MAY be
encrypted or integrity-protected. Each record message includes a
five bytes prefix that comprises three attributes:
- The type (one byte) of the message,
- The version (two bytes),
- The message length (two bytes).
The client and the server exchange RECORD messages whose meaning is
deduced from the TLS protocol rules, according to a half-duplex
paradigm. Therefore as soon as the beginning of the TLS session is
detected, the two TLS entities alternatively send and receive a set
of record messages, whose synchronization is handled by the
knowledge of TLS protocol.
The EAP-TLS protocol [RFC 5216] demonstrates how TLS record messages
may be gathered in blocks exchanged according to a half-duplex
mechanism.
Urien Expires January 2018 [Page 9]

LLCPS July 2017
LLCPS specifies the TLS session establishment and release, and the
transport of TLS packets in a NFC P2P context.
Applications secured by LLCPS are identified by the service name
"urn:nfc:sn:tls:service" where "service" is the application name.
2 TLS support over LLCP, Connection-oriented Transport
In NFC P2P mode the Initiator detects a Target and afterwards starts
and manages a data exchange session; it may optionally feeds the
Target device. The Initiator has consequently a longer useful life
than the Target; it is a legitimate place to host TLS server in a
permanent way.
However the TLS server MAY be hosted on the Initiator or on the
Target side.
Each entity manages five exclusive processes
- The Connection Process (CP)
- The Disconnection Process (DP)
- The Sending Process (SP)
- The Receiving Process (RP)
- The Inactivity Process (IP)
The Inactivity Process MAY be started (see figure 4) each time a
receiving or sending buffer is empty; in this case it is assumed
that the computing time or the delay required before the next
input/output operation is greater than the LLCP timeout (LTO).
2.1 Peer To Peer Link Establishment
As described in section 1, the Initiator periodically probes the
presence of a Target. At the end of the "Protocol Activation and
Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been
exchanged, and LLCP services are available on both Initiator and
Target nodes, including in particular the Data-Request-i/t and Data-
Indication-i/t primitives.
Due to the ephemeral intrinsic nature of an NFC connection, the P2P
session may be broken at any time, which implies transmission or
reception errors notified by the MAC primitives.
As a consequence an LLCP session is assumed to be released at the
first MAC error.
Once a NFC P2P link is established, TLS server and client software
entities are activated. Procedures such as:
- SOCKET acceptllcp (char *ServiceName), and
- SOCKET connectllcp(char *ServiceName)
Urien Expires January 2018 [Page 10]

LLCPS July 2017
MAY be used respectively on Initiator and Target sides, in order to
get a SOCKET.
A SOCKET object supports additional facilities, typically the
following procedures:
- int sendllcp(SOCKET s, char *buffer, int length)
- int recvllcp(SOCKET s, char *buffer, int length)
- int closellcp(SOCKET s)
which are used for the LLCP session management.
Urien Expires January 2018 [Page 11]

LLCPS July 2017
2.2 Inactivity Process
When the LLCP layer detects an inactivity period greater than a
given timeout value (see figure 5), it generates a SYMM PDU.
Therefore each time a LLCP layer is waiting for a non SYMM PDU, and
receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A
maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined.
The Inactivity Process (IP) MAY start between the Receiving Process
(RP) and the Sending Process (SP).
Upon the reception of an INFORMATION PDU, the packet is stored in
the reception buffer, and is acknowledged by a RR PDU.
Initiator Target
| |
+------> LLCP inactivity + <-------------+
| | | |
| +----------+-----------+ +------------+-----------+ |
| + Inactivity Timeout + + Waiting for a LLCP PDU + |
| +----------+-----------+ +------------+-----------+ |
| | | |
| Send SYMM PDU ----> Reception of a PDU |
| | | | |
| | |SYMM |Other |
| Reception of a PDU <---- |Send SYMM PDU |PDU |
| | | | |Excepted|
| SYMM| |Other PDU SYMM-Ct-t++ |INFOR- |
| SYMM-Ct-i++| |Excepted | |-MATION |
+-------------+ +--+INFORMATION +------------|--------+
| |
End Of LLCP Inactivity Send a LLCP PDU
Figure 5. Inactivity Process
2.3 Connection Process, the Initiator is Server, the Target is Client
2.3.1 Initiator side
The Initiator MUST transmit a SYMM LLCP PDU.
The Initiator MUST receive a CONNECT PDU, with DSAP=1, including the
SN option, whose value MUST be set to "urn:nfc:sn:tls:service". If
the SN value is incorrect the Initiator transmits a DM PDU with a
reason code.
The Initiator MUST send a CC PDU, with an SSAP ranging between 16
and 31.
Urien Expires January 2018 [Page 13]

LLCPS July 2017
The Initiator SHOULD receive a SYMM PDU. It MAY receive an
INFORMATION PDU but this behavior is not recommended, since it
complicates the implementation of the acceptllcp (and connectllcp)
procedure.
2.3.2 Target side
The Target MUST wait for the reception of a SYMM PDU
The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging
between 16 and 31, including the option SN, whose value MUST be set
to "urn:nfc:sn:tls:service".
The Target MUST receive a CC PDU.
The Target SHOULD send a SYMM PDU. It MAY send an INFORMATION PDU
but this behavior is not recommended, since it complicates the
implementation of the connectllcp (and acceptllcp) procedure.
2.3.3 Connection choreography
Initiator Target
| |
socket= acceptllcp() socket=connectllcp()
| |
Send SYMMM ------------> Receive SYMM
| |
Receive CONNECT <------------- Send CONNECT, DSAP=1
Check SN SN = "urn:nfc:sn:tls:x"
| |
Send CC --------------> Receive CC
Allocate Ephemeral SAP |
| |
Receive SYMM <-------------- Send SYMM
| |
Done Done
Figure 6. Connection Choreography
2.4 Connection Process, the Initiator is Client, the Target is Server
2.4.1 Initiator side
The Initiator MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging
between 16 and 31, including the SN option, whose value MUST be set
to "com.ietf.tls.
The Initiator MUST receive a CC PDU.
Urien Expires January 2018 [Page 14]

LLCPS July 2017
2.4.2 Target side
The Target MUST receive a CONNECT PDU, with DSAP=1, including the SN
option, whose value MUST be set to "urn:nfc:sn:tls:service". If the
SN value is incorrect the Initiator transmits a DM PDU with a reason
code.
The Target MUST send a CC PDU, with an SSAP ranging between 16 and
31.
2.4.3 Connection choreography
Initiator Target
| |
socket= connectllcp() socket= acceptllcp()
| |
Send CONNECT, DSAP=1 --------------> Receive CONNECT
SN = "urn:nfc:sn:tls:service" Check SN
| Allocate Ephemeral SAP
| |
Receive CC <-------------- Send CC
| |
| |
Done Done
Figure 7. Connection Choreography
2.5 Disconnection Process
Due to the ephemeral nature of P2P NFC session, the disconnection
process MAY be unavailable. Nerveless it SHOULD be used for a
graceful closing of a TLS session.
The Disconnection Process is started by the Initiator or the Target.
2.5.1 Disconnection initiated by the Initiator
The Initiator MUST send a DISC PDU.
The Target receives the DISC PDU.
The Target MUST send the DM PDU.
The Initiator MUST receive the DM PDU.
2.5.2 Disconnection initiated by the Target
The Target receives a LLCP PDU. If it receives DISC then it sends
DM; else it sends the DISC PDU.
Urien Expires January 2018 [Page 15]

LLCPS July 2017
Each packet MUST be acknowledged by the Target with a RR PDU.
If a RNR PDU is received instead of a RR PDU then the initiator
sends a SYMM PDU that should be acknowledged either by a SYMM (if
the target is still overloaded) or by a RR PDU (if the target is
ready again to process INFORMATION PDUs).
Initiator Target
| |
Sendllcp(buffer) recvllcp()
| |
Send INFORMATION PDU -----------------> Receive INFORMATION PDU
NS-i++ |
| |
Receive RR <--------------------------- Send RR(NR-t)
| |
Send INFORMATION PDU -----------------> Receive INFORMATION PDU
NS-i++ |
| |
Receive RR <--------------------------- Send RR(NR-t)
| |
Buffer Empty |
|
Done
Figure 10. Sending Process, Initiator side.
2.6.2 Target side
The Target switches to the sending process, managed by the
sendllcp() procedure.
The Target MUST receive a SYMM PDU.
The buffer to be sent is segmented in INFORMATION PDUs.
Each INFORMATION PDU is sent by the Target to the Initiator and MUST
be acknowledged by a RR PDU.
If a RNR PDU is received instead of a RR PDU then the target sends a
SYMM PDU that should be acknowledged either by a SYMM (if the
initiator is still overloaded) or by a RR PDU (if the initiator is
ready again to process INFORMATION PDUs).
Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the
Target to the Initiator.
Urien Expires January 2018 [Page 17]

LLCPS July 2017
Initiator Target
| |
recvllcp() sendllcp(buffer)
| |
Send SYMM --------> Receive SYMM
| |
Receive INFORMATION PDU <------- Send INFORMATION PDU
| NS-t++
| |
SEND RR(NR-i) -------> Receive RR
| |
Receive INFORMATION PDU <------- Send INFORMATION PDU
| NS-t++
| |
SEND RR(NR-i) -------> Receive RR
| |
| Buffer Empty
| |
Receive SYMM <------- Send SYMM
| |
Done Done
Figure 11. Sending Process, Target side.
2.7 Receiving Process
The Receiving process is handled by the recvllcp(SOCKET s, char
*buffer, int length) procedure, which manages a reception buffer.
2.7.1 Initiator side
A1) If the reception buffer is empty, the Initiator sends a SYMM
PDU. This PDU starts the Target receiving process. The expected PDU
received from the Target is either an INFORMATION PDU or a SYMM PDU
(notifying an ephemeral inactivity state).
B1) If the reception buffer stores enough data, then the size
requested by the recvllcp() procedure is returned. If the buffer
gets empty after this operation, a RR PDU is sent to the Target. The
PDU received from the Target is either an INFORMATION PDU or a SYMM
PDU.
B2) Else, while there is not enough data in the buffer, the
following loop is performed
- Send RR PDU
- Receive INFORMATION PDU
B2.1) at this end of this loop the size requested by the recvllcp()
procedure is returned. If the buffer gets empty after this
Urien Expires January 2018 [Page 18]

LLCPS July 20173 TLS support over LLCP, Connectionless Transport
In NFC P2P mode the Initiator detects a Target and afterwards starts
and manages a data exchange session; it may optionally feed the
Target device.
The Initiator has consequently a longer useful life than the Target;
it is a legitimate place to host TLS server in a permanent way.
However the TLS server MAY be hosted on the Initiator or on the
Target side.
Each entity manages five exclusive processes
- The Connection Process (CP)
- The Disconnection Process (DP)
- The Sending Process (SP)
- The Receiving Process (RP)
- The Inactivity Process (IP)
The Inactivity Process MAY be started (see figure 14) each time a
receiving or sending buffer is empty; in this case it is assumed
that the computing time or the delay required before the next
input/output operation is greater than the LLCP timeout (LTO).
Urien Expires January 2018 [Page 21]

LLCPS July 20173.1 Peer To Peer Link Establishment
As described in section 1, the Initiator periodically probes the
presence of a Target. At the end of the "Protocol Activation and
Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been
exchanged, and LLCP services are available on both Initiator and
Target nodes, including in particular the Data-Request-i/t and Data-
Indication-i/t primitives.
Due to the ephemeral intrinsic nature of an NFC connection, the P2P
session may be broken at any time, which implies transmission or
reception errors notified by the MAC primitives.
As a consequence an LLCP session is assumed to be released at the
first MAC error.
Once a NFC P2P link is established, TLS server and client software
entities are activated. Procedures such as:
- SOCKET acceptllcp(char TLS-SAP), and
- SOCKET connectllcp(char TLS-SAP)
MAY be used respectively on Initiator and Target sides, in order to
get a SOCKET. This object supports additional facilities, typically
the following procedures:
- int sendllcp(SOCKET s, char *buffer, int length)
- int recvllcp(SOCKET s, char *buffer, int length)
- int closellcp(SOCKET s)
which are used for the LLCP session management.
Urien Expires January 2018 [Page 23]

LLCPS July 20173.2 Inactivity Process
When the LLCP layer detects an inactivity period greater that a
given timeout value (see figure 15), it generates a SYMM PDU.
Therefore each time a LLCP layer is waiting for a non SYMM PDU, and
receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A
maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined.
Upon the reception of an UI PDU, the packet is stored in the
reception buffer.
The Inactivity Process (IP) MAY start between the Receiving Process
(RP) and the Sending Process (SP).
Initiator Target
| |
+------> LLCP inactivity + <-------------+
| | | |
| +----------+-----------+ +------------+-----------+ |
| + Inactivity Timeout + + Waiting for a LLCP PDU + |
| +----------+-----------+ +------------+-----------+ |
| | | |
| Send SYMM PDU ----> Reception of a PDU |
| | | | |
| | |SYMM or UI |Other |
| Reception of a PDU <---- |Send SYMM PDU |PDU |
| | | | |Excepted|
| SYMM or UI| |Other PDU SYMM-Ct-t++ |UI |
| SYMM-Ct-i++| |Excepted UI | | |
+-------------+ +--+ +------------|--------+
| |
End Of LLCP Inactivity Send a LLCP PDU
Figure 15. Inactivity Process
3.3 Connection Process, the Initiator is Server, the Target is Client
3.3.1 Initiator side
The Initiator MUST transmit a SYMM PDU.
If the Initiator receives a SYMM then it sends a SYMM.
If the Initiator receives an UI PDU, with the DSAP set to a well-
known value that identifies the TLS service, then the service data
unit transported by the UI is stored in the reception buffer.
If the DSAP value is incorrect the Initiator transmits a DM PDU with
a reason code.
Urien Expires January 2018 [Page 24]

LLCPS July 2017
3.3.2 Target side
The Target allocates an ephemeral SSAP ranging between 16 and 31,
and sends a SYMM.
The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a
well-known value that identifies the TLS service.
3.3.3 Connection choreography
Initiator Target
| |
socket= acceptllcp(TLS-SAP) socket=connectllcp(TLS-SAP)
| |
| DSAP=well-known value
| Allocate Ephemeral SSAP
| |
| Done
| |
| sendllcp()
| |
Send SYMM ------------------> Receive SYMM
| |
Receive UI <------------------ Send UI
Check DSAP |
| |
Done
Figure 15. Connection Choreography
3.4 Connection Process, the Initiator is Client, the Target is Server
3.4.1 Initiator side
The initiator allocates an ephemeral SSAP ranging between 16 and 31,
and sends a SYMM.
The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a
well-known value that identifies the TLS service.
3.4.2 Target side
If target receives a SYMM, then it sends A SYMM.
If the Target receives an UI PDU, with the DSAP set to a well-known
value that identifies the TLS service, then the service data unit
transported by the UI is stored in the reception buffer.
Upon success the Target sends a SYMM.
Urien Expires January 2018 [Page 25]

LLCPS July 2017
If the DSAP value is incorrect the Initiator transmits a DM PDU with
a reason code.
3.4.3 Connection choreography
Initiator Target
| |
socket= connectllcp(TLS-SAP) socket= acceptllcp(TLS-SAP)
| |
DSAP=well-known value |
Allocate Ephemeral SSAP |
| |
Done |
| |
Sendllcp() |
| |
Send UI -------------------> Receive UI
receive SYMM <------------------ Send SYMM
| |
Done Done
Figure 16. Connection Choreography
3.5 Disconnection Process
Due to the ephemeral nature of P2P NFC session, the disconnection
process MAY be unavailable. Nerveless it SHOULD be used for a
graceful closing of a TLS session. The Disconnection Process is
initiated by the Initiator or the Target.
3.5.1 Disconnection initiated by the Initiator
The Initiator MUST send a DM PDU
The Target receives the DM PDU.
The Target sends a SYMM or a DM PDU.
3.5.2 Disconnection initiated by the Target
If the Target receives a DM PDU, then it sends the DM or the SYMM
PDU.
Else the Target sends the DM PDU.
Urien Expires January 2018 [Page 26]

LLCPS July 20173.7 Receiving Process
The Receiving process is handled by the
recvllcp(SOCKET s, char *buffer, int length)
procedure, which manages a reception buffer.
3.7.1 Initiator side
A1) If the reception buffer is empty, the Initiator sends a SYMM
PDU. This PDU starts the Target receiving process. The expected PDU
received from the Target is either an UI PDU or a SYMM PDU
(notifying an ephemeral inactivity state).
B1) If the reception buffer stores enough data, then the size
requested by the recvllcp() procedure is returned. If the buffer
gets empty after this operation, the SYMM PDU SHOULD be sent to the
Target. The PDU received from the Target is either an UI PDU or a
SYMM PDU.
B2) Else, while there is not enough data in the buffer, the
following loop is performed
- Send SYMM
- Receive UI PDU
B2.1) at this end of this loop the size requested by the recvllcp()
procedure is returned. If the buffer gets empty after this
operation, the SYMM PDU SHOULD be sent to the Target. The PDU
received from the Target is either an UI PDU or a SYMM PDU.
In B1 and B2.1 a SYMM PDU SHOULD be sent when the reception buffer
gets empty. This rule avoids un-needed transition to the IP process.
It is a "double checking" of the empty buffer event.
Urien Expires January 2018 [Page 29]