[6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-nfc-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In general, I'm worried that this document is so unreadable that I can't
give it a proper review.  I just don't have a clear picture of how all
the pieces fit together, and which pieces are new as opposed to reused
from other specifications.  That said, here are my notes as they stand
at present.

If I understand correctly, the statements about "distance of 10 cm or
less" and "safe" or "secure communications" apply only for usage
compliant with the relevant legal regulations.  We cannot expect
attackers to abide by such regulations, and large (directional) antennas
and/or high-power transmitters should be presumed to expand that
distance by some factor, in adversarial environments.

Section 4.3 should probably provide some guidance on choosing the PRF
F().  We are implicitly relying on RFC 7217 for a lot of things, some of
which 7127 doesn't even cover, and the suggested construction in RFC
7127 may not still be best practice.

I don't understand why MIUX is not mandatory (and thus we could get rid
of all the "FAR is NOT RECOMMENDED" stuff).  Is there known demand for
IPv6 over NFC on devices that cannot do MIUX?

Some section-by-section points as well:

Section 3.1

   peer mode is used for ipv6-over-nfc.  In addition, NFC-enabled
   devices can securely send IPv6 packets to any corresponding node on
   the Internet when an NFC-enabled gateway is linked to the Internet.

I don't see anything in the document that justifies the usage of
"securely".

Section 3.4

   When the MIUX parameter is encoded as a TLV option, the TLV Type
   field MUST be 0x02 and the TLV Length field MUST be 0x02.  The MIUX
   parameter MUST be encoded into the least significant 11 bits of the
   TLV Value field.  The unused bits in the TLV Value field MUST be set
   to zero by the sender and ignored by the receiver.  A maximum value

Either the MIUX occupies 11 bits and there are five unused bits to be
set to zero, or the four bits marked in the figure are 1011 and there is
only one unused bit (singular) to be marked as zero.  This needs to be
more clear, as right now I can't tell what's intended.

Section 4.4

How does a device know that the link-local address is a public address?

Section 4.5

   o  When an NFC-enabled device (6LN) is directly connected to a 6LBR,
      an NFC 6LN MUST register its address with the 6LBR by sending a

How does the device know that it's talking NFC to a 6LBR as opposed to
some non-border-router peer?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A lot of this document reads like marketing material for NFC, which is a
bit off-putting in a technical specification.  (Some examples:
"outstanding performance", "NFC builds upon RFID systems by allowing
two-way communication between endpoints, where earlier systems such as
contactless smart cards were one-way only", "NFC also has the strongest
ability (e.g., secure communication distance of 10 cm) to prevent a
third party from attacking privacy", "NFC technology enables simple and
safe two-way interactions between electronic devices", "NFC's
bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch", etc.)

Section 1

   Considering the potential for exponential growth in the number of
   heterogeneous air interface technologies, NFC would be widely used as
   one of the other air interface technologies, such as Bluetooth Low
   Energy (BT-LE), Wi-Fi, and so on.

nit: I think there's a word missing here or something, maybe "as widely
used".

Section 3

   NFC's bidirectional communication ability is ideal for establishing
   connections with other technologies by the simplicity of touch.  In

nit: other technologies, or other devices?

Section 3.2

There's no "IPv6 layer" in Figure 1.

Section 3.3

                      Address values between 10h and 1Fh SHALL be
   assigned by the local LLC to services registered by local service
   environment.  [...]

Is this duplicating a requirement from LLCP-1.3 or new to this spec?

Section 3.4

   MIUX extension parameter within the information field.  If no MIUX
   parameter is transmitted, the default MIU value is 128 bytes.

nit: I think this reads better (in context) without "default" here.

   When the MIUX parameter is encoded as a TLV option, the TLV Type
   field MUST be 0x02 and the TLV Length field MUST be 0x02.  The MIUX
   parameter MUST be encoded into the least significant 11 bits of the
   TLV Value field.  The unused bits in the TLV Value field MUST be set
   to zero by the sender and ignored by the receiver.  A maximum value

(Figure 2 is a little confusing because the '|' separator inside the
value field occupies a bit position; this type of diagram is frequently
laid out "double width", to allow a '| separator between each bit, with
'+' characters in the horizontal delimiting lines to mark off bit
boundaries.)

Also, you say "least significant bits" without specifying network byte
order.

nit: isn't this "The" maximum value?

   of the TLV Value field can be 0x7FF, and a maximum size of the MTU in
   NFC LLCP is 2176 bytes including the 128 byte default of MIU.

How can we use all 128 bytes of MIU when we need to spend four bytes on
the MIUX TLV?

Section 4.1

It's unclear to me what information I'm supposed to get from Figure 3
that differs from what was in Figure 1.

Section 4.2

   This document does NOT RECOMMEND using FAR over NFC link due to
   simplicity of the protocol and implementation.  [...]

nit: this isn't clear about what is simple.  ("If FAR is simple,
wouldn't that make it easy to implement and use?")

Section 4.3

   An NFC-enabled device (i.e., 6LN) performs stateless address
   autoconfiguration as per [RFC4862].  A 64-bit Interface identifier
   (IID) for an NFC interface is formed by utilizing the 6-bit NFC LLCP
   address (see Section 3.3).  In the viewpoint of address
   configuration, such an IID SHOULD guarantee a stable IPv6 address
   because each data link connection is uniquely identified by the pair
   of DSAP and SSAP included in the header of each LLC PDU in NFC.

(Just to check: these DSAP and SSAP are only unique within the context
of the current NFC pairing between two devices?)

The writing here is hard to follow -- I'm supposed to utilize the 6-bit
NFC LLCP address to form an IID (with nothing about how), but then we
see that IIDs for unicast are randomly generated (without using the LLCP
address), and only finally at the end do we mention the RFC 7217 PRF
(and not even by name!)

Section 4.4

Show me where the "Universal/Local" bit is, in the figure.

Expand 6LBR (and 6LR) on first use, and/or have a terminology section
that mentions that familiarity with the 6LoWPAN RFCs is assumed.

Section 4.5

      accordingly.  In addition, if DHCPv6 is used to assign an address,
      Duplicate Address Detection (DAD) is not necessary.

Not necessary in the DHCPv6 server or some other element?

   o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
      is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop

I thought we said that NFC was a two-party thing only.  How are we
getting multi-hop connections?  If I assume that this is talking about
the IPv6 layer, how do we guarantee that only NFC-capable devices are
participating in the IPv6 network?

      router.  When the NFC nodes are not of uniform category (e.g.,
      different MTU, level of remaining energy, connectivity, etc.), a
      performance-outstanding device can become a router.  [...]

This seems rather under-specified.

Section 4.9

A link to Section 4.6.1 of RFC 4861 and a note that the field
descriptions are largely copied therefrom would be helpful.

Section 5.1

This section is laying out the physical mechanics of how a NFC node can
be connected to the Internet, but does not say why this is "typical" or
what the NFC node would be talking to on the Internet.

   One of the key applications of using IPv6 over NFC is securely
   transmitting IPv6 packets because the RF distance between 6LN and
   6LBR is typically within 10 cm.  If any third party wants to hack
   into the RF between them, it must come to nearly touch them.

Or use a big and ungainly high-gain antenna/illegal transmit power, right?

Section 5.2

This example does a little better than the previous one at conveying
what might motivate such a topology, but it's still pretty vague.

What is "outstanding performance"?  This doesn't seem actionable.

Section 7

   IPv6-over-NFC is, in practice, not used for long-lived links for big
   size data transfer or multimedia streaming, but used for extremely
   short-lived links (i.e., single touch-based approaches) for ID
   verification and mobile payment.  This will mitigate the threat of
   correlation of activities over time.

This mitigation only occurs if the IID is freshly generated for each
link, which isn't mentioned until the next paragraph, so it's an
unsupported claim at this point in the text.

   IPv6-over-NFC uses an IPv6 interface identifier formed from a "Short
   Address" and a set of well-known constant bits (such as padding with
   '0's) for the modified EUI-64 format.  However, the short address of

nit: Is the zero-padding really a "such as" or just a fact, given the
protocol specification?

   NFC link layer (LLC) is not generated as a physically permanent value
   but logically generated for each connection.  Thus, every single
   touch connection can use a different short address of NFC link with

nit: I don't think this is "can use"; I think this is "uses".

   an extremely short-lived link.  This can mitigate address scanning as
   well as location tracking and device-specific vulnerability
   exploitation.

These last two seem to have high overlap with the "correlation of
activities over time" from the previous paragraph.

   Thus, this document does not RECOMMEND sending NFC packets over the
   Internet or any unsecured network.

I don't see any preceding argument that leads into or supports this
claim; why is the word "thus" present?
Also, such a recommendation seems like it should be more prominently
made near the start of the document and not relegated to the security
considerations.

This document also does not give any indication of what might be
considered to be a "secure" network.  Note that per the RFC 3552 threat
model, we generally do not place any trust in the network.

Section 9.2

Isn't the whole point of this work that you are doing IPv6 over NFC?
How do you not need to implement NFC in order to implement this?