< draft-urien-tls-llcp-09.txt   draft-urien-tls-llcp-10.txt >
TLS Working Group P. Urien TLS Working Group P. Urien
Internet Draft Telecom ParisTech Internet Draft Telecom ParisTech
Intended status: Experimental Intended status: Experimental
January 6 2017 July 16 2017
Expires: July 2017 Expires: January 2018
LLCPS LLCPS
draft-urien-tls-llcp-09.txt draft-urien-tls-llcp-10.txt
Abstract Abstract
This document describes the support of the TLS protocol over the NFC This document describes the support of the TLS protocol over the NFC
(Near Field Communication) LLCP (Logical Link Control Protocol) (Near Field Communication) LLCP (Logical Link Control Protocol)
layer, which is referred as LLCPS. The NFC peer to peer (P2P) layer, which is referred as LLCPS. The NFC peer to peer (P2P)
protocol may be used by any application that needs communication protocol may be used by any application that needs communication
between two devices at very small distances (a few centimeters). between two devices at very small distances (a few centimeters).
LLCPS enforces a strong security in NFC P2P exchanges, and may be LLCPS enforces a strong security in NFC P2P exchanges, and may be
deployed for many services, in the Internet of Things (IoT) deployed for many services, in the Internet of Things (IoT)
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2017. This Internet-Draft will expire on January 2018.
. .
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
LLCPS January 2017
Table of Contents Table of Contents
Abstract........................................................... 1 Abstract........................................................... 1
Requirements Language.............................................. 1 Requirements Language.............................................. 1
Status of this Memo................................................ 1 Status of this Memo................................................ 1
Copyright Notice................................................... 2 Copyright Notice................................................... 2
1 Overview......................................................... 5 1 Overview......................................................... 5
1.1 About the NFC protocol...................................... 5 1.1 About the NFC protocol...................................... 5
1.2 The LLCP layer.............................................. 7 1.2 The LLCP layer.............................................. 7
1.3 LLCPS basic guidelines...................................... 9 1.3 LLCPS basic guidelines...................................... 9
skipping to change at page 4, line 4 skipping to change at page 4, line 4
3.5 Disconnection Process...................................... 26 3.5 Disconnection Process...................................... 26
3.5.1 Disconnection initiated by the Initiator ............ 26 3.5.1 Disconnection initiated by the Initiator ............ 26
3.5.2 Disconnection initiated by the Target ............... 26 3.5.2 Disconnection initiated by the Target ............... 26
3.5.3 Disconnection choreography .......................... 27 3.5.3 Disconnection choreography .......................... 27
3.6 Sending Process............................................ 27 3.6 Sending Process............................................ 27
3.7 Receiving Process.......................................... 29 3.7 Receiving Process.......................................... 29
4 Example of LLCPS session, connected mode........................ 32 4 Example of LLCPS session, connected mode........................ 32
4.1 Protocol Activation and Parameters Selection............... 32 4.1 Protocol Activation and Parameters Selection............... 32
4.1.1 Initiator ATR-REQ ................................... 32 4.1.1 Initiator ATR-REQ ................................... 32
4.1.2 Target ATR-RESP ..................................... 32 4.1.2 Target ATR-RESP ..................................... 32
LLCPS January 2017
4.2 LLCP connection............................................ 32 4.2 LLCP connection............................................ 32
4.3 Target: sending Client Hello............................... 33 4.3 Target: sending Client Hello............................... 33
4.4 Inactivity Process......................................... 33 4.4 Inactivity Process......................................... 33
4.5 Server: sending Server Hello............................... 33 4.5 Server: sending Server Hello............................... 33
4.6 LLCP Inactivity Process.................................... 34 4.6 LLCP Inactivity Process.................................... 34
4.7 Client: sending Client Finished............................ 34 4.7 Client: sending Client Finished............................ 34
4.8 Exchanging Data............................................ 35 4.8 Exchanging Data............................................ 35
4.8.1 Sending data from client to server .................. 35 4.8.1 Sending data from client to server .................. 35
4.8.2 Sending data from server to client .................. 35 4.8.2 Sending data from server to client .................. 35
4.9 Closing TLS session, initiated by the Initiator............ 36 4.9 Closing TLS session, initiated by the Initiator............ 36
skipping to change at page 5, line 4 skipping to change at page 5, line 4
5.6 Exchanging Data............................................ 38 5.6 Exchanging Data............................................ 38
5.6.1 Sending data from client to server .................. 38 5.6.1 Sending data from client to server .................. 38
5.6.2 Sending data from server to client .................. 39 5.6.2 Sending data from server to client .................. 39
5.7 End of Session............................................. 39 5.7 End of Session............................................. 39
6 Security Considerations......................................... 40 6 Security Considerations......................................... 40
7 IANA Considerations............................................. 40 7 IANA Considerations............................................. 40
8 References...................................................... 40 8 References...................................................... 40
8.1 Normative References....................................... 40 8.1 Normative References....................................... 40
8.2 Informative References..................................... 41 8.2 Informative References..................................... 41
9 Authors' Addresses.............................................. 41 9 Authors' Addresses.............................................. 41
LLCPS January 2017
1 Overview 1 Overview
1.1 About the NFC protocol 1.1 About the NFC protocol
The Near Field Communication protocol (NFC) is based on standards The Near Field Communication protocol (NFC) is based on standards
such as [ECMA340] or [ISO/IEC 18092]. It uses the 13,56 MHz 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 frequency, with data rates ranging from 106 To 848 kbps. The working
distance between two nodes is about a few centimeters, with distance between two nodes is about a few centimeters, with
electromagnetic fields ranging between 1 and 10 A/M. electromagnetic fields ranging between 1 and 10 A/M.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
(Attribute-Request) message, which is confirmed by a Target ATR-RESP (Attribute-Request) message, which is confirmed by a Target ATR-RESP
(Attribute-Response) message. These messages fix the device IDs (Attribute-Response) message. These messages fix the device IDs
(DIDi, Device ID Initiator and DIDt, Device ID Target) used in (DIDi, Device ID Initiator and DIDt, Device ID Target) used in
further packet exchanges. Optional information fields (Gi for the further packet exchanges. Optional information fields (Gi for the
Initiator, and Gt for the Target) identify the protocol to be used 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 over the MAC level; in this document it is assumed that the LLCP
[LLCP] (Logical Link Control Protocol) protocol is selected by the [LLCP] (Logical Link Control Protocol) protocol is selected by the
Gi and Gt bytes. Optionally some parameters are negotiated by Gi and Gt bytes. Optionally some parameters are negotiated by
additional packets. additional packets.
LLCPS January 2017
3) Data Exchange. Frames are exchanged via the DEP (Data Exchange 3) Data Exchange. Frames are exchanged via the DEP (Data Exchange
Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted
by the Initiator and DEP-RESP (DEP-Response) delivered by the by the Initiator and DEP-RESP (DEP-Response) delivered by the
Target. DEP provides error detection and recovery. It uses small Target. DEP provides error detection and recovery. It uses small
data unit size (from 64 to 256 bytes); however it supports a data unit size (from 64 to 256 bytes); however it supports a
chaining mode for larger sizes. DEP frames typically transport LLCP chaining mode for larger sizes. DEP frames typically transport LLCP
packets, and provide an error free service packets, and provide an error free service
4) De-Activation. The Initiator may deactivate the Target by sending 4) De-Activation. The Initiator may deactivate the Target by sending
a RLS-REQ (Release Request) message acknowledged by a RLS-RESP a RLS-REQ (Release Request) message acknowledged by a RLS-RESP
(Release Response). (Release Response).
skipping to change at page 7, line 5 skipping to change at page 7, line 5
MAC services implemented by NFC controllers usually support such MAC services implemented by NFC controllers usually support such
dissymmetric primitives for Initiator and Target procedures (MAC dissymmetric primitives for Initiator and Target procedures (MAC
Data.request-i/t and Data.Indication-i/t). Data.request-i/t and Data.Indication-i/t).
The timeout value (between DEP-REQ and DEP-RESP messages) is deduced The timeout value (between DEP-REQ and DEP-RESP messages) is deduced
from the RWT attribute (Response Waiting Time) returned by the 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 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 = 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. RTOX x RWT) between 1 and 60, so the maximum value is about 6s.
LLCPS January 2017
Initiator Target Initiator Target
| | | | | | | |
| | | | | | | |
| Data.Request-i --- DEP-REQ --> Data.Indication-t | | Data.Request-i --- DEP-REQ --> Data.Indication-t |
| | | | | |
| RWT-INT ms | | RWT-INT ms |
| | | | | |
Data.Indication-i <---- DEP-RESP --------- Data.Request-t Data.Indication-i <---- DEP-RESP --------- Data.Request-t
Figure 2. NFC-P2P MAC layer service, based on DEP frames Figure 2. NFC-P2P MAC layer service, based on DEP frames
skipping to change at page 8, line 5 skipping to change at page 8, line 5
There are sixteen types of LLCP packets, identified by PTYPE values 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 ranging between 0 and 15. In this draft we use only nine of these
PDUs. PDUs.
1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, No Sequence, No 1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, No Sequence, No
Information). This PDU is produced as soon as there is no Information). This PDU is produced as soon as there is no
information to provide. This mechanism avoids timeout at the MAC information to provide. This mechanism avoids timeout at the MAC
(DEP) level. SYMM SHOULD be generated after an inactivity period of (DEP) level. SYMM SHOULD be generated after an inactivity period of
about LTO/2, where LTO is the link timeout. about LTO/2, where LTO is the link timeout.
LLCPS January 2017
2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU 2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU
MUST include a SN (service name parameter) that identified the TLS 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 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 (the SAP of the Service Discovery Protocol, SDP) and a SSAP value
ranging between 16 and 31. It indicates the connection the well- ranging between 16 and 31. It indicates the connection the well-
known service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral known service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral
SAP (SAP-client) ranging between 16 and 31. SAP (SAP-client) ranging between 16 and 31.
3) Connection Complete (CC, PTYPE=6, No sequence, Optional 3) Connection Complete (CC, PTYPE=6, No sequence, Optional
Information). This PDU notifies the successful connection to the Information). This PDU notifies the successful connection to the
skipping to change at page 9, line 5 skipping to change at page 9, line 5
9) Unnumbered Information (UI, PTYPE=3, no Sequence, Optional 9) Unnumbered Information (UI, PTYPE=3, no Sequence, Optional
Information). This PDU is used to transfer service data units to the Information). This PDU is used to transfer service data units to the
peer LLC without prior establishment of a data link connection. peer LLC without prior establishment of a data link connection.
According to [LLCP] some LLCP functional parameters are updated by According to [LLCP] some LLCP functional parameters are updated by
LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ
and ATR-RESP messages. Parameters are encoding according to TLV and ATR-RESP messages. Parameters are encoding according to TLV
format, in which Type size is one byte, Length size is one byte and 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. Value is a set of L bytes. In this document we use 6 parameters.
LLCPS January 2017
1) Version Number (VERSION, T=01h, L=01h, V=10h). In this document 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 this option MUST be included in the general bytes of ATR-REQ and
ATR-RESP. ATR-RESP.
2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This 2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This
parameter extends the maximum size of the LLCP PDU (MIU), whose parameter extends the maximum size of the LLCP PDU (MIU), whose
default value is 128 bytes, according to the relation: MIU = MIUX + default value is 128 bytes, according to the relation: MIU = MIUX +
128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ 128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ
and ATR-RESP, and in LLCP PDUs CONNECT and CC. and ATR-RESP, and in LLCP PDUs CONNECT and CC.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
deduced from the TLS protocol rules, according to a half-duplex deduced from the TLS protocol rules, according to a half-duplex
paradigm. Therefore as soon as the beginning of the TLS session is paradigm. Therefore as soon as the beginning of the TLS session is
detected, the two TLS entities alternatively send and receive a set detected, the two TLS entities alternatively send and receive a set
of record messages, whose synchronization is handled by the of record messages, whose synchronization is handled by the
knowledge of TLS protocol. knowledge of TLS protocol.
The EAP-TLS protocol [RFC 5216] demonstrates how TLS record messages The EAP-TLS protocol [RFC 5216] demonstrates how TLS record messages
may be gathered in blocks exchanged according to a half-duplex may be gathered in blocks exchanged according to a half-duplex
mechanism. mechanism.
LLCPS January 2017
LLCPS specifies the TLS session establishment and release, and the LLCPS specifies the TLS session establishment and release, and the
transport of TLS packets in a NFC P2P context. transport of TLS packets in a NFC P2P context.
Applications secured by LLCPS are identified by the service name Applications secured by LLCPS are identified by the service name
"urn:nfc:sn:tls:service" where "service" is the application name. "urn:nfc:sn:tls:service" where "service" is the application name.
2 TLS support over LLCP, Connection-oriented Transport 2 TLS support over LLCP, Connection-oriented Transport
In NFC P2P mode the Initiator detects a Target and afterwards starts In NFC P2P mode the Initiator detects a Target and afterwards starts
and manages a data exchange session; it may optionally feeds the and manages a data exchange session; it may optionally feeds the
skipping to change at page 11, line 4 skipping to change at page 11, line 4
reception errors notified by the MAC primitives. reception errors notified by the MAC primitives.
As a consequence an LLCP session is assumed to be released at the As a consequence an LLCP session is assumed to be released at the
first MAC error. first MAC error.
Once a NFC P2P link is established, TLS server and client software Once a NFC P2P link is established, TLS server and client software
entities are activated. Procedures such as: entities are activated. Procedures such as:
- SOCKET acceptllcp (char *ServiceName), and - SOCKET acceptllcp (char *ServiceName), and
- SOCKET connectllcp(char *ServiceName) - SOCKET connectllcp(char *ServiceName)
LLCPS January 2017
MAY be used respectively on Initiator and Target sides, in order to MAY be used respectively on Initiator and Target sides, in order to
get a SOCKET. get a SOCKET.
A SOCKET object supports additional facilities, typically the A SOCKET object supports additional facilities, typically the
following procedures: following procedures:
- int sendllcp(SOCKET s, char *buffer, int length) - int sendllcp(SOCKET s, char *buffer, int length)
- int recvllcp(SOCKET s, char *buffer, int length) - int recvllcp(SOCKET s, char *buffer, int length)
- int closellcp(SOCKET s) - int closellcp(SOCKET s)
which are used for the LLCP session management. which are used for the LLCP session management.
LLCPS January 2017
Initiator Target Initiator Target
| | | |
Connection Process Connection Process Connection Process Connection Process
| | | |
Send SYMM ---------------> Receive SYMM Send SYMM ---------------> Receive SYMM
Receive CONNECT <---------------- Send CONNECT Receive CONNECT <---------------- Send CONNECT
Send CC ----------------> Receive CC Send CC ----------------> Receive CC
Receive SYMM <---------------- Send SYMM Receive SYMM <---------------- Send SYMM
| | | |
=========================TLS Session============================ =========================TLS Session============================
skipping to change at page 13, line 4 skipping to change at page 13, line 4
| | | |
Inactivity Process Inactivity Process Inactivity Process Inactivity Process
| | | |
Disconnection Process | Disconnection Process |
| | | |
Send DISC -------------------> Receive DISC Send DISC -------------------> Receive DISC
Receive DM <------------------- Send DM Receive DM <------------------- Send DM
| | | |
Figure 4. Overview of Operations, Connected Mode Figure 4. Overview of Operations, Connected Mode
LLCPS January 2017
2.2 Inactivity Process 2.2 Inactivity Process
When the LLCP layer detects an inactivity period greater than a When the LLCP layer detects an inactivity period greater than a
given timeout value (see figure 5), it generates a SYMM PDU. 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 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 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. maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined.
The Inactivity Process (IP) MAY start between the Receiving Process The Inactivity Process (IP) MAY start between the Receiving Process
(RP) and the Sending Process (SP). (RP) and the Sending Process (SP).
skipping to change at page 14, line 5 skipping to change at page 14, line 5
The Initiator MUST transmit a SYMM LLCP PDU. The Initiator MUST transmit a SYMM LLCP PDU.
The Initiator MUST receive a CONNECT PDU, with DSAP=1, including the 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 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 the SN value is incorrect the Initiator transmits a DM PDU with a
reason code. reason code.
The Initiator MUST send a CC PDU, with an SSAP ranging between 16 The Initiator MUST send a CC PDU, with an SSAP ranging between 16
and 31. and 31.
LLCPS January 2017
The Initiator SHOULD receive a SYMM PDU. It MAY receive an The Initiator SHOULD receive a SYMM PDU. It MAY receive an
INFORMATION PDU but this behavior is not recommended, since it INFORMATION PDU but this behavior is not recommended, since it
complicates the implementation of the acceptllcp (and connectllcp) complicates the implementation of the acceptllcp (and connectllcp)
procedure. procedure.
2.3.2 Target side 2.3.2 Target side
The Target MUST wait for the reception of a SYMM PDU The Target MUST wait for the reception of a SYMM PDU
The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging
skipping to change at page 15, line 5 skipping to change at page 15, line 5
2.4 Connection Process, the Initiator is Client, the Target is Server 2.4 Connection Process, the Initiator is Client, the Target is Server
2.4.1 Initiator side 2.4.1 Initiator side
The Initiator MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 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 between 16 and 31, including the SN option, whose value MUST be set
to "com.ietf.tls. to "com.ietf.tls.
The Initiator MUST receive a CC PDU. The Initiator MUST receive a CC PDU.
LLCPS January 2017
2.4.2 Target side 2.4.2 Target side
The Target MUST receive a CONNECT PDU, with DSAP=1, including the SN 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 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 SN value is incorrect the Initiator transmits a DM PDU with a reason
code. code.
The Target MUST send a CC PDU, with an SSAP ranging between 16 and The Target MUST send a CC PDU, with an SSAP ranging between 16 and
31. 31.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
The Target MUST send the DM PDU. The Target MUST send the DM PDU.
The Initiator MUST receive the DM PDU. The Initiator MUST receive the DM PDU.
2.5.2 Disconnection initiated by the Target 2.5.2 Disconnection initiated by the Target
The Target receives a LLCP PDU. If it receives DISC then it sends The Target receives a LLCP PDU. If it receives DISC then it sends
DM; else it sends the DISC PDU. DM; else it sends the DISC PDU.
LLCPS January 2017
The target waits for an LLCP PDU. Upon reception of a LLCP PDU it The target waits for an LLCP PDU. Upon reception of a LLCP PDU it
MUST send the SYMM or the DM PDU. MUST send the SYMM or the DM PDU.
2.5.3 Disconnection choreography 2.5.3 Disconnection choreography
Initiator Target Initiator Target
| | | |
closellcp(socket) | closellcp(socket) |
| | | |
Send DISC --------------> Receive DISC Send DISC --------------> Receive DISC
skipping to change at page 17, line 5 skipping to change at page 17, line 5
2.6 Sending Process 2.6 Sending Process
The data transmission is managed by the sendllcp(SOCKET s, char The data transmission is managed by the sendllcp(SOCKET s, char
*buffer, int length) procedure. *buffer, int length) procedure.
2.6.1 Initiator side 2.6.1 Initiator side
The buffer to be transmitted is segmented in LLCP INFORMATION The buffer to be transmitted is segmented in LLCP INFORMATION
packets. packets.
LLCPS January 2017
Each packet MUST be acknowledged by the Target with a RR PDU. 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 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 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 the target is still overloaded) or by a RR PDU (if the target is
ready again to process INFORMATION PDUs). ready again to process INFORMATION PDUs).
Initiator Target Initiator Target
| | | |
Sendllcp(buffer) recvllcp() Sendllcp(buffer) recvllcp()
skipping to change at page 18, line 5 skipping to change at page 18, line 5
be acknowledged by a RR PDU. be acknowledged by a RR PDU.
If a RNR PDU is received instead of a RR PDU then the target sends a 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 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 initiator is still overloaded) or by a RR PDU (if the initiator is
ready again to process INFORMATION PDUs). ready again to process INFORMATION PDUs).
Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the
Target to the Initiator. Target to the Initiator.
LLCPS January 2017
Initiator Target Initiator Target
| | | |
recvllcp() sendllcp(buffer) recvllcp() sendllcp(buffer)
| | | |
Send SYMM --------> Receive SYMM Send SYMM --------> Receive SYMM
| | | |
Receive INFORMATION PDU <------- Send INFORMATION PDU Receive INFORMATION PDU <------- Send INFORMATION PDU
| NS-t++ | NS-t++
| | | |
SEND RR(NR-i) -------> Receive RR SEND RR(NR-i) -------> Receive RR
skipping to change at page 19, line 4 skipping to change at page 19, line 4
PDU received from the Target is either an INFORMATION PDU or a SYMM PDU received from the Target is either an INFORMATION PDU or a SYMM
PDU. PDU.
B2) Else, while there is not enough data in the buffer, the B2) Else, while there is not enough data in the buffer, the
following loop is performed following loop is performed
- Send RR PDU - Send RR PDU
- Receive INFORMATION PDU - Receive INFORMATION PDU
B2.1) at this end of this loop the size requested by the recvllcp() B2.1) at this end of this loop the size requested by the recvllcp()
procedure is returned. If the buffer gets empty after this procedure is returned. If the buffer gets empty after this
LLCPS January 2017
operation, a RR PDU is sent to the Target. The PDU received from the operation, a RR PDU is sent to the Target. The PDU received from the
Target is either an INFORMATION PDU or a SYMM PDU. Target is either an INFORMATION PDU or a SYMM PDU.
Initiator Target Initiator Target
| | | |
buffer empty sendllcp() buffer empty sendllcp()
| | | |
recvllcp() ===> Send SYMM --------> Receive SYMM recvllcp() ===> Send SYMM --------> Receive SYMM
| | | |
Receive INFORMATION PDU <------- Send INFORMATION PDU Receive INFORMATION PDU <------- Send INFORMATION PDU
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Send RR(NR-i) -------> Receive RR Send RR(NR-i) -------> Receive RR
| | | |
| buffer empty | buffer empty
| | | |
Receive SYMM <------- Send SYMM Receive SYMM <------- Send SYMM
| | | |
Done Done Done Done
Figure 12. Receiving Process, Initiator side. Figure 12. Receiving Process, Initiator side.
LLCPS January 2017
2.7.2 Target side 2.7.2 Target side
A1) If the reception buffer stores enough data, then the size A1) If the reception buffer stores enough data, then the size
requested by the recvllcp() procedure is returned. requested by the recvllcp() procedure is returned.
B1) Else, while there is not enough data in the buffer, the B1) Else, while there is not enough data in the buffer, the
following loop is performed following loop is performed
- Receive INFORMATION PDU - Receive INFORMATION PDU
- Send RR PDU - Send RR PDU
skipping to change at page 21, line 5 skipping to change at page 21, line 5
| | | |
Receive RR <------------ Send RR(NR-t) Receive RR <------------ Send RR(NR-t)
| | | |
buffer empty | ===> enough data buffer empty | ===> enough data
| buffer empty | buffer empty
Done | Done |
Done Done
Figure 13. Receiving Process, Initiator side. Figure 13. Receiving Process, Initiator side.
LLCPS January 2017
3 TLS support over LLCP, Connectionless Transport 3 TLS support over LLCP, Connectionless Transport
In NFC P2P mode the Initiator detects a Target and afterwards starts In NFC P2P mode the Initiator detects a Target and afterwards starts
and manages a data exchange session; it may optionally feed the and manages a data exchange session; it may optionally feed the
Target device. Target device.
The Initiator has consequently a longer useful life than the Target; The Initiator has consequently a longer useful life than the Target;
it is a legitimate place to host TLS server in a permanent way. 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 However the TLS server MAY be hosted on the Initiator or on the
skipping to change at page 22, line 5 skipping to change at page 22, line 5
- The Disconnection Process (DP) - The Disconnection Process (DP)
- The Sending Process (SP) - The Sending Process (SP)
- The Receiving Process (RP) - The Receiving Process (RP)
- The Inactivity Process (IP) - The Inactivity Process (IP)
The Inactivity Process MAY be started (see figure 14) each time a The Inactivity Process MAY be started (see figure 14) each time a
receiving or sending buffer is empty; in this case it is assumed receiving or sending buffer is empty; in this case it is assumed
that the computing time or the delay required before the next that the computing time or the delay required before the next
input/output operation is greater than the LLCP timeout (LTO). input/output operation is greater than the LLCP timeout (LTO).
LLCPS January 2017
Initiator Target Initiator Target
| | | |
Connection Process Connection Process Connection Process Connection Process
| | | |
| Sending Process | Sending Process
| | | |
Send SYMM ---------------> Receive SYMM Send SYMM ---------------> Receive SYMM
Receive UI <---------------- Send UI Receive UI <---------------- Send UI
| | | |
Receiving Process | Receiving Process |
skipping to change at page 23, line 4 skipping to change at page 23, line 4
Receive SYMM <---------------- Send SYMM Receive SYMM <---------------- Send SYMM
| | | |
| | | |
Disconnection Process | Disconnection Process |
| | | |
Send DM --------------> Receive DM Send DM --------------> Receive DM
Receive SYMM or DM <------------ Send SYMM or DM Receive SYMM or DM <------------ Send SYMM or DM
| | | |
Figure 14. Overview of Process Operations, connectionless mode Figure 14. Overview of Process Operations, connectionless mode
LLCPS January 2017
3.1 Peer To Peer Link Establishment 3.1 Peer To Peer Link Establishment
As described in section 1, the Initiator periodically probes the As described in section 1, the Initiator periodically probes the
presence of a Target. At the end of the "Protocol Activation and presence of a Target. At the end of the "Protocol Activation and
Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been
exchanged, and LLCP services are available on both Initiator and exchanged, and LLCP services are available on both Initiator and
Target nodes, including in particular the Data-Request-i/t and Data- Target nodes, including in particular the Data-Request-i/t and Data-
Indication-i/t primitives. Indication-i/t primitives.
Due to the ephemeral intrinsic nature of an NFC connection, the P2P Due to the ephemeral intrinsic nature of an NFC connection, the P2P
skipping to change at page 24, line 5 skipping to change at page 24, line 5
MAY be used respectively on Initiator and Target sides, in order to MAY be used respectively on Initiator and Target sides, in order to
get a SOCKET. This object supports additional facilities, typically get a SOCKET. This object supports additional facilities, typically
the following procedures: the following procedures:
- int sendllcp(SOCKET s, char *buffer, int length) - int sendllcp(SOCKET s, char *buffer, int length)
- int recvllcp(SOCKET s, char *buffer, int length) - int recvllcp(SOCKET s, char *buffer, int length)
- int closellcp(SOCKET s) - int closellcp(SOCKET s)
which are used for the LLCP session management. which are used for the LLCP session management.
LLCPS January 2017
3.2 Inactivity Process 3.2 Inactivity Process
When the LLCP layer detects an inactivity period greater that a When the LLCP layer detects an inactivity period greater that a
given timeout value (see figure 15), it generates a SYMM PDU. 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 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 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. 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 Upon the reception of an UI PDU, the packet is stored in the
reception buffer. reception buffer.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
If the Initiator receives a SYMM then it sends a SYMM. 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- 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 known value that identifies the TLS service, then the service data
unit transported by the UI is stored in the reception buffer. unit transported by the UI is stored in the reception buffer.
If the DSAP value is incorrect the Initiator transmits a DM PDU with If the DSAP value is incorrect the Initiator transmits a DM PDU with
a reason code. a reason code.
LLCPS January 2017
3.3.2 Target side 3.3.2 Target side
The Target allocates an ephemeral SSAP ranging between 16 and 31, The Target allocates an ephemeral SSAP ranging between 16 and 31,
and sends a SYMM. and sends a SYMM.
The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a
well-known value that identifies the TLS service. well-known value that identifies the TLS service.
3.3.3 Connection choreography 3.3.3 Connection choreography
skipping to change at page 26, line 5 skipping to change at page 26, line 5
3.4.2 Target side 3.4.2 Target side
If target receives a SYMM, then it sends A SYMM. 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 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 value that identifies the TLS service, then the service data unit
transported by the UI is stored in the reception buffer. transported by the UI is stored in the reception buffer.
Upon success the Target sends a SYMM. Upon success the Target sends a SYMM.
LLCPS January 2017
If the DSAP value is incorrect the Initiator transmits a DM PDU with If the DSAP value is incorrect the Initiator transmits a DM PDU with
a reason code. a reason code.
3.4.3 Connection choreography 3.4.3 Connection choreography
Initiator Target Initiator Target
| | | |
socket= connectllcp(TLS-SAP) socket= acceptllcp(TLS-SAP) socket= connectllcp(TLS-SAP) socket= acceptllcp(TLS-SAP)
| | | |
DSAP=well-known value | DSAP=well-known value |
skipping to change at page 27, line 5 skipping to change at page 27, line 5
The Target sends a SYMM or a DM PDU. The Target sends a SYMM or a DM PDU.
3.5.2 Disconnection initiated by the Target 3.5.2 Disconnection initiated by the Target
If the Target receives a DM PDU, then it sends the DM or the SYMM If the Target receives a DM PDU, then it sends the DM or the SYMM
PDU. PDU.
Else the Target sends the DM PDU. Else the Target sends the DM PDU.
LLCPS January 2017
3.5.3 Disconnection choreography 3.5.3 Disconnection choreography
Initiator Target Initiator Target
| | | |
closellcp(socket) | closellcp(socket) |
| | | |
Send DM -----------------> Receive DM Send DM -----------------> Receive DM
| | | |
Receive SYMM or DM <---------------- Send SYMM or DM Receive SYMM or DM <---------------- Send SYMM or DM
| | | |
skipping to change at page 28, line 5 skipping to change at page 28, line 5
| | | |
Send UI PDU -----------------> Receive UI PDU Send UI PDU -----------------> Receive UI PDU
Receive SYMM <----------------- Send SYMM Receive SYMM <----------------- Send SYMM
| | | |
Buffer Empty | Buffer Empty |
| |
Done Done
Figure 19. Sending Process, Initiator side. Figure 19. Sending Process, Initiator side.
LLCPS January 2017
The following loop is performed The following loop is performed
- The Initiator sends an UI PDU - The Initiator sends an UI PDU
- The initiator receive a SYMM PDU - The initiator receive a SYMM PDU
3.6.2 Target side 3.6.2 Target side
The Target switches to the sending process, managed by the The Target switches to the sending process, managed by the
sendllcp() procedure. sendllcp() procedure.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
| | | |
Receive UI <------- Send UI Receive UI <------- Send UI
| Buffer Empty | Buffer Empty
| | | |
Receive SYMM <------- Send SYMM Receive SYMM <------- Send SYMM
| | | |
| Done | Done
Figure 20. Sending Process, Target side. Figure 20. Sending Process, Target side.
LLCPS January 2017
3.7 Receiving Process 3.7 Receiving Process
The Receiving process is handled by the The Receiving process is handled by the
recvllcp(SOCKET s, char *buffer, int length) recvllcp(SOCKET s, char *buffer, int length)
procedure, which manages a reception buffer. procedure, which manages a reception buffer.
3.7.1 Initiator side 3.7.1 Initiator side
A1) If the reception buffer is empty, the Initiator sends a SYMM A1) If the reception buffer is empty, the Initiator sends a SYMM
PDU. This PDU starts the Target receiving process. The expected PDU PDU. This PDU starts the Target receiving process. The expected PDU
skipping to change at page 30, line 5 skipping to change at page 30, line 5
B2.1) at this end of this loop the size requested by the recvllcp() B2.1) at this end of this loop the size requested by the recvllcp()
procedure is returned. If the buffer gets empty after this procedure is returned. If the buffer gets empty after this
operation, the SYMM PDU SHOULD be sent to the Target. The PDU 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. 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 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. gets empty. This rule avoids un-needed transition to the IP process.
It is a "double checking" of the empty buffer event. It is a "double checking" of the empty buffer event.
LLCPS January 2017
Initiator Target Initiator Target
| | | |
buffer empty sendllcp() buffer empty sendllcp()
| | | |
recvllcp() ===> Send SYMM --------> Receive SYMM recvllcp() ===> Send SYMM --------> Receive SYMM
| | | |
Receive UI <------- Send UI PDU Receive UI <------- Send UI PDU
enough data <=== | | enough data <=== | |
| | | |
recvllcp() ===> | | recvllcp() ===> | |
skipping to change at page 31, line 5 skipping to change at page 31, line 5
| | | |
| Inactivity Process | Inactivity Process
| | | |
Send SYMM --------> Receive SYMM Send SYMM --------> Receive SYMM
Receive SYMM <-------- Send SYMM Receive SYMM <-------- Send SYMM
| | | |
Done Done Done Done
Figure 21. Receiving Process, Initiator side. Figure 21. Receiving Process, Initiator side.
LLCPS January 2017
3.7.2 Target side 3.7.2 Target side
A1) If the reception buffer stores enough data, then the size A1) If the reception buffer stores enough data, then the size
requested by the recvllcp() procedure is returned. requested by the recvllcp() procedure is returned.
B1) Else, while there is not enough data in the buffer, the B1) Else, while there is not enough data in the buffer, the
following loop is performed following loop is performed
- Receive UI PDU - Receive UI PDU
- Send SYMM PDU - Send SYMM PDU
skipping to change at page 32, line 5 skipping to change at page 32, line 5
Receive SYMM <------------ Send SYMM Receive SYMM <------------ Send SYMM
| | | |
Done | ===> enough data Done | ===> enough data
| buffer empty | buffer empty
| | | |
| | | |
Done Done
Figure 22. Receiving Process, Target side. Figure 22. Receiving Process, Target side.
LLCPS January 2017
4 Example of LLCPS session, connected mode 4 Example of LLCPS session, connected mode
4.1 Protocol Activation and Parameters Selection 4.1 Protocol Activation and Parameters Selection
4.1.1 Initiator ATR-REQ 4.1.1 Initiator ATR-REQ
Raw-data: Raw-data:
5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66
6D 01 01 10 03 02 00 01 04 01 01 10 64 6D 01 01 10 03 02 00 01 04 01 01 10 64
skipping to change at page 33, line 4 skipping to change at page 33, line 4
4.2 LLCP connection 4.2 LLCP connection
Initiator: Sending SYMM, ssap=0 dsap=0 Initiator: Sending SYMM, ssap=0 dsap=0
Tx-i: 00 00 Tx-i: 00 00
Target: Sending CONNECT, ssap=27 dsap=1, option=SN("com.ietf.tls") Target: Sending CONNECT, ssap=27 dsap=1, option=SN("com.ietf.tls")
Rx_i: 05 1B 06 0C 63 6F 6D 2E 69 65 74 66 2E 74 6C 73 Rx_i: 05 1B 06 0C 63 6F 6D 2E 69 65 74 66 2E 74 6C 73
Initiator: Sending ConnectionComplete, ssap=16 dsap=27 Initiator: Sending ConnectionComplete, ssap=16 dsap=27
Tx-i: 6D 90 Tx-i: 6D 90
Target: Sending SYMM, ssap=0 dsap=0 Target: Sending SYMM, ssap=0 dsap=0
Rx-i: 00 00 Rx-i: 00 00
LLCPS January 2017
4.3 Target: sending Client Hello 4.3 Target: sending Client Hello
RecvLLCP Initiator: request size=5, buffer empty, sending SYMM RecvLLCP Initiator: request size=5, buffer empty, sending SYMM
Initiator: Sending SYMM, ssap=0 dsap=0 Initiator: Sending SYMM, ssap=0 dsap=0
Tx-i: 00 00 Tx-i: 00 00
SendLLCP Target: request size=82 bytes, Waiting for SYMM SendLLCP Target: request size=82 bytes, Waiting for SYMM
Target: Receiving SYMM, ssap=0 dsap=0 Target: Receiving SYMM, ssap=0 dsap=0
Target: Sending INFORMATION, ssap=27 dsap=16 Nr=0, Ns=0 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=0, Ns=0
Rx-i: 43 1B 00 16 03 01 00 4D 01 00 00 49 03 01 50 1A Rx-i: 43 1B 00 16 03 01 00 4D 01 00 00 49 03 01 50 1A
skipping to change at page 34, line 4 skipping to change at page 34, line 4
4.5 Server: sending Server Hello 4.5 Server: sending Server Hello
SendLLCP_Initiator: request size=122 bytes SendLLCP_Initiator: request size=122 bytes
Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0
Tx-i: 6F 10 01 16 03 01 00 4A 02 00 00 46 03 01 50 1A Tx-i: 6F 10 01 16 03 01 00 4A 02 00 00 46 03 01 50 1A
A9 6B 6C 0E 31 E1 F3 0E CD 18 E7 6F 81 BF 5F 3C A9 6B 6C 0E 31 E1 F3 0E CD 18 E7 6F 81 BF 5F 3C
FD DE 00 4C A4 12 AE DC DF E4 FF 82 09 5E 20 E7 FD DE 00 4C A4 12 AE DC DF E4 FF 82 09 5E 20 E7
0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22
05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00
04 00 14 03 01 00 01 01 16 03 01 00 20 83 18 D1 04 00 14 03 01 00 01 01 16 03 01 00 20 83 18 D1
LLCPS January 2017
E3 BC 3A 94 26 91 3D FC F3 8E 01 46 5E 52 8E 67 E3 BC 3A 94 26 91 3D FC F3 8E 01 46 5E 52 8E 67
A2 66 FC 5F D5 89 78 59 66 14 BA D3 B0 A2 66 FC 5F D5 89 78 59 66 14 BA D3 B0
RecvLLCP_Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 RecvLLCP_Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0
RecvLLCP_Target: sending RR(1), ssap=27 dsap=16 RecvLLCP_Target: sending RR(1), ssap=27 dsap=16
RecvLLCP_Target: request size=74 bytes RecvLLCP_Target: request size=74 bytes
RecvLLCP_Target: request size=5 bytes RecvLLCP_Target: request size=5 bytes
RecvLLCP_Target: request size=1 byte RecvLLCP_Target: request size=1 byte
SendLLCP Initiator: Receiving RR(1), ssap=27 dsap=16 SendLLCP Initiator: Receiving RR(1), ssap=27 dsap=16
skipping to change at page 35, line 4 skipping to change at page 35, line 4
Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1
RecvLLCP_Initiator: request size= 5 bytes, buffer=43 bytes RecvLLCP_Initiator: request size= 5 bytes, buffer=43 bytes
RecvLLCP_Initiator: request size= 1 bytes, buffer=38 bytes RecvLLCP_Initiator: request size= 1 bytes, buffer=38 bytes
RecvLLCP_Initiator: request size= 5 bytes, buffer=37 bytes RecvLLCP_Initiator: request size= 5 bytes, buffer=37 bytes
RecvLLCP_Initiator: request size=32 bytes, buffer=32 bytes RecvLLCP_Initiator: request size=32 bytes, buffer=32 bytes
RecvLLCP_Initiator: empty buffer, sending RR(2) RecvLLCP_Initiator: empty buffer, sending RR(2)
Initiator: Sending RR(2), ssap=16 dsap=27 Initiator: Sending RR(2), ssap=16 dsap=27
Tx-i: 6F 50 02 Tx-i: 6F 50 02
Target: Receiving RR(2), ssap=16 dsap=27 Nr=2 Target: Receiving RR(2), ssap=16 dsap=27 Nr=2
LLCPS January 2017
SendLLC_Target: empty buffer, Done, sending SYMM SendLLC_Target: empty buffer, Done, sending SYMM
Target: Sending SYMM, ssap=0 dsap=0 Target: Sending SYMM, ssap=0 dsap=0
Initiator: Receiving SYMM ssap=0 dsap=0 Initiator: Receiving SYMM ssap=0 dsap=0
Rx-i: 00 00 Rx-i: 00 00
4.8 Exchanging Data 4.8 Exchanging Data
4.8.1 Sending data from client to server 4.8.1 Sending data from client to server
skipping to change at page 36, line 4 skipping to change at page 36, line 4
RecvLLCP_Target: request size= 5 bytes RecvLLCP_Target: request size= 5 bytes
Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1
RecvLLCP_Target: sending RR(2) RecvLLCP_Target: sending RR(2)
Target: Sending RR(2), ssap=27 dsap=16 Target: Sending RR(2), ssap=27 dsap=16
RecvLLCP_Target: request size=22 bytes, buffer=22 bytes, Done RecvLLCP_Target: request size=22 bytes, buffer=22 bytes, Done
Initiator: Receiving RR(2), ssap=27 dsap=16 Initiator: Receiving RR(2), ssap=27 dsap=16
Rx-i: 43 5B 02 Rx-i: 43 5B 02
SendLLCP Initiator: empty buffer, Done SendLLCP Initiator: empty buffer, Done
LLCPS January 2017
4.9 Closing TLS session, initiated by the Initiator 4.9 Closing TLS session, initiated by the Initiator
Initiator: Sending DISC, ssap=16 dsap=27 Initiator: Sending DISC, ssap=16 dsap=27
Tx-i: 6D 50 Tx-i: 6D 50
Target: Receiving DISC, ssap=16 dsap=27 Target: Receiving DISC, ssap=16 dsap=27
Target: Sending DM, ssap=27 dsap=16 Target: Sending DM, ssap=27 dsap=16
Initiator: Receiving DM, ssap=27 dsap=16 Initiator: Receiving DM, ssap=27 dsap=16
Rx-i: 41 DB 00 Rx-i: 41 DB 00
skipping to change at page 37, line 4 skipping to change at page 37, line 4
DIDt (Target ID)= 00 DIDt (Target ID)= 00
BSt= 00 BSt= 00
BRt= 00 BRt= 00
TO= 09, WT= 6363 ms TO= 09, WT= 6363 ms
PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes
available available
Magic Bytes: 46666d Magic Bytes: 46666d
Option: Version, Major=1, Minor=0 Option: Version, Major=1, Minor=0
Option: WKS: Well-Known Service List 0x0001 Option: WKS: Well-Known Service List 0x0001
Option: LTO: Link TimeOut 0x64 (1000 ms) Option: LTO: Link TimeOut 0x64 (1000 ms)
LLCPS January 2017
5.2 LLCP connection 5.2 LLCP connection
Initiator: Sending SYMM, ssap=0 dsap=0 Initiator: Sending SYMM, ssap=0 dsap=0
Tx-i: 00 00 Tx-i: 00 00
Target: Setting DSAP to 13 (well known-value), setting ephemeral Target: Setting DSAP to 13 (well known-value), setting ephemeral
SSAP to 27 SSAP to 27
5.3 Client Hello 5.3 Client Hello
skipping to change at page 38, line 4 skipping to change at page 38, line 4
26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11 26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11
44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 04 44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 04
00 14 03 01 00 01 01 16 03 01 00 20 B9 0C 3F E8 00 14 03 01 00 01 01 16 03 01 00 20 B9 0C 3F E8
C8 48 F3 8B 1A 1C 59 01 6C C9 A0 7F 33 FB E9 A3 C8 48 F3 8B 1A 1C 59 01 6C C9 A0 7F 33 FB E9 A3
1E 9E 25 B8 FA AE FE 77 06 51 3D E4 1E 9E 25 B8 FA AE FE 77 06 51 3D E4
Target: Receiving UI, ssap=13 dsap=27, 122 bytes Target: Receiving UI, ssap=13 dsap=27, 122 bytes
RecvLLC Target: request size= 5, buffer size= 122 RecvLLC Target: request size= 5, buffer size= 122
RecvLLC Target: request size=74, buffer size= 117 RecvLLC Target: request size=74, buffer size= 117
LLCPS January 2017
RecvLLC Target: request size= 5, buffer size= 43 RecvLLC Target: request size= 5, buffer size= 43
RecvLLC Target: request size= 1, buffer size= 42 RecvLLC Target: request size= 1, buffer size= 42
RecvLLC Target: request size= 5, buffer size= 37 RecvLLC Target: request size= 5, buffer size= 37
RecvLLC Target: request size=32, buffer size= 32 RecvLLC Target: request size=32, buffer size= 32
RecvLLC Target: empty buffer RecvLLC Target: empty buffer
Target: Sending SYMM, ssap=0 dsap=0 Target: Sending SYMM, ssap=0 dsap=0
Initiator: Receiving SYMM, ssap=0 dsap=0 Initiator: Receiving SYMM, ssap=0 dsap=0
Rx-i: 00 00 Rx-i: 00 00
skipping to change at page 39, line 4 skipping to change at page 39, line 4
5.6 Exchanging Data 5.6 Exchanging Data
5.6.1 Sending data from client to server 5.6.1 Sending data from client to server
Initiator: Sending SYMM, ssap=0 dsap=0 Initiator: Sending SYMM, ssap=0 dsap=0
Tx-i: 00 00 Tx-i: 00 00
Target: Receiving SYMM, ssap=0 dsap=0 Target: Receiving SYMM, ssap=0 dsap=0
Target: Sending UI, ssap=27 dsap=13, 27 bytes Target: Sending UI, ssap=27 dsap=13, 27 bytes
LLCPS January 2017
Rx-i: 34 DB 17 03 01 00 16 EA 91 72 8A DA 5A DD F0 C7 Rx-i: 34 DB 17 03 01 00 16 EA 91 72 8A DA 5A DD F0 C7
6A E0 82 15 B4 8F 5E 72 F6 BE 64 9D 0E 6A E0 82 15 B4 8F 5E 72 F6 BE 64 9D 0E
Initiator: Receiving UI, ssap=27 dsap=13, 27 bytes Initiator: Receiving UI, ssap=27 dsap=13, 27 bytes
SendLLC Initiator: request size= 5, buffer size=32 SendLLC Initiator: request size= 5, buffer size=32
SendLLC Initiator: request size=27, buffer size=27 SendLLC Initiator: request size=27, buffer size=27
SendLLC Initiator: buffer empty SendLLC Initiator: buffer empty
Initiator: Sending SYMM, ssap=0 dsap=0 Initiator: Sending SYMM, ssap=0 dsap=0
skipping to change at page 40, line 4 skipping to change at page 40, line 4
Initiator: Receiving SYMM, ssap=0 dsap=0 Initiator: Receiving SYMM, ssap=0 dsap=0
Rx-i: 00 00 Rx-i: 00 00
5.7 End of Session 5.7 End of Session
Initiator: Sending DM, ssap=0 dsap=0 Initiator: Sending DM, ssap=0 dsap=0
Target: Receiving DM, ssap=0 dsap=0 Target: Receiving DM, ssap=0 dsap=0
Target: Sending SYMM, ssap=0 dsap=0 Target: Sending SYMM, ssap=0 dsap=0
Initiator: Receiving SYMM, ssap=0 dsap=0 Initiator: Receiving SYMM, ssap=0 dsap=0
LLCPS January 2017
6 Security Considerations 6 Security Considerations
To be done. To be done.
7 IANA Considerations 7 IANA Considerations
8 References 8 References
8.1 Normative References 8.1 Normative References
skipping to change at page 41, line 4 skipping to change at page 41, line 4
NFC ForumTM, NDEF 1.0, July 2006. NFC ForumTM, NDEF 1.0, July 2006.
[ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards
with Contacts", The International Organization for Standardization with Contacts", The International Organization for Standardization
(ISO) (ISO)
[IEEE 802.2] IEEE Std 802.2, "IEEE Standard for Information [IEEE 802.2] IEEE Std 802.2, "IEEE Standard for Information
technology Telecommunications and information exchange between technology Telecommunications and information exchange between
systems Local and metropolitan area networks, Specific requirements, systems Local and metropolitan area networks, Specific requirements,
Part 2: Logical Link Control", 1998 Part 2: Logical Link Control", 1998
LLCPS January 2017
8.2 Informative References 8.2 Informative References
[NPP} "Android NDEF Push Protocol Specification Version 1", February [NPP} "Android NDEF Push Protocol Specification Version 1", February
2011 2011
9 Authors' Addresses 9 Authors' Addresses
Pascal Urien Pascal Urien
Telecom ParisTech Telecom ParisTech
23 avenue d' Italie 23 avenue d' Italie
 End of changes. 42 change blocks. 
82 lines changed or deleted 4 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/