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

[최영환 <[e-mail]>]

Hello Benjamin and all,

Thanks for your valuable reviews.
Please find my answers inline.

BRs,
Younghwan Choi

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> Sent: Thursday, March 14, 2019 11:19 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Carles Gomez 
> <[e-mail]>; Samita Chakrabarti <[e-mail]>; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-6lo-nfc-13: (with 
> DISCUSS and COMMENT)
> 
> 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.

Many thanks for your DISCUSS and COMMENTs, but I believe that the IPv6 by using NFC should be useful as one of the various 6lo technologies for some IoT applications and services. I hope you understand intention of this documents.

> 
> 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.

Thanks, but partially agreed. We can think of the larger antennas, but I don't think so. Even though the third attackers have large antennas, they cannot get any of information by using their large antennas from my regular NFC antenna. If I have large antennas with NFC, that's not secured. On the contrary, If I have regular antennas, such an attack is not going to be happening. NFC RF distance is regularly less than 10cm. When I had the NFC RF with high-power transmitters in my experiments, the RF distance was less than maximum 1 m. IPv6 over NFC is actually the first try in IETF 6lo WG, and the NFC was normally just used RFID-like style these days. So, many people who are not in the NFC technologies get wrong sometimes.

> 
> 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.

Agreed with your comments. It is true that RFC7217 is not providing the prefect solution for NFC. I need to do something more for NFC in RFC7217.

> 
> 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?

I think this is good point. In the beginning stage, I also intended to MIUX is just optional in this document (IPv6 over NFC). This means FAR can be used sometimes if NFC devices do not support MIUX. In fact, the MIUX is not mandatory but option in the NFC MAC/PHY spec. However, 6lo experts has given me a lot of comments whether MIUX is going to be mandatory or not in this document. Finally, I have decided it mandatory. I believe that the MIUX can be mandatory for all NFC devices if IPv6 over NFC is widely used in the future. Therefore, this is OK I think.

> 
> 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".

I think I can change them for clarification.

" peer mode is used for ipv6-over-nfc.  In addition, NFC-enabled
  devices can securely send IPv6 packets in wireless range when
  an NFC-enabled gateway is linked to the Internet."

> 
> 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.

Agreed. I can change them like this.

" 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
  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. This value
  MUST be 0x480 to cover MTU of IPV6 if FAR is not used in IPv6 over NFC.
"

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

Agreed. I put some more explanations at the end of the section 4.4 like this.

"The "Interface Identifier" is used the secured and stable IIDs for NFC-enabled devices in section 4.3."

> 
> 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?

This document assumes that the 6LN and the 6LBR have NFC interface in this document, so they can talk to each other.
If some more explanations are required, I can change them like this.

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

> 
> 
> ----------------------------------------------------------------------
> 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.)

Thanks for your comments. I get rid of all of something like marketing in my documents.
I going to do this with helps from Suresh.

> 
> 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".

Thanks. I can change them.

" Considering the potential for exponential growth in the number of
  heterogeneous air interface technologies, NFC has been widely used like Bluetooth Low
  Energy (BT-LE), Wi-Fi, and so on."

> 
> 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?

I think these sentences are not necessary in this section. I will get rid of them.

> 
> Section 3.2
> 
> There's no "IPv6 layer" in Figure 1.

The Figure 1 shows only MAC/PHY protocols of NFC. This is introduction to NFC technologies. The IPv6 over NFC is shown in Figure 3.

> 
> 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?

Yes, this is the same and duplicated from LLCP-1.3.

> 
> 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.

I will remove the "default".

> 
>    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.)

Agreed. I will change the figure.

> 
> Also, you say "least significant bits" without specifying network byte 
> order.
> 
> nit: isn't this "The" maximum value?

You're right. It is "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?

So, I mentioned the field MUST be 0x480 for MTU of a IPv6 packet in the previous answer.

> 
> 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.

IF so, I can merge MAC/PHY of NFC in the figure 3 in the next version of this document.

> 
> 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?")

Because FAR for NFC is not required in document, it's simple. I will change it for clarification.
" This document does NOT RECOMMEND using FAR over NFC link. "

> 
> 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?)

Yes, they are unique 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!)

I can change them like the following. 

"  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 SSAP.
   address (see Section 3.3)."

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

I will remove the first sentence in section 4.4. The first draft was shown in the figure 5, but it's not necessary for final version.

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

I will mention them in the next version.

> 
> 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?

I can change them for clarification.

"     When the 6LN and 6LBR are directly connected, DHCPv6 is used for address assignment. 
      Therefore, Duplicate Address Detection (DAD) is not necessary between them."

> 
>    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?

In this document, we said two topologies with NFC devices. One is only two NFC devices connected, and the other is three or more NFC devices are connected as a mesh. Multi-hop connections of NFC devices are technically possible with IPv6 over NFC.

> 
>       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.

Agreed. I will remove the sentences, "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.  [...]" from the paragraph.

> 
> 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.

Thanks.

> 
> 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.

Agreed. I will remove the "typical".

> 
>    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?

I don't think the big and ungainly high-gain antenna/illegal transmit power of third parties are useful for security attacks in NFC RF scenarios. I have already explained and answered for this in the DISCUSS section.

> 
> 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.

It is not easy to find out examples of applications with IPv6 over NFC because IPv6 over NFC is really brand-new from the IETF 6lo. But I believe some of good applications will be developed. And I will get rid of the key word, "outstanding".

> 
> 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.

Before we considered RFC7217 in Section 4.3, we had security considerations for the mitigation. In the final version, the consideration is not necessarily required. I will remove the paragraph in section 7.

> 
>    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?

It is "such as". I think the part, "and a set of well-known constant bits (such as padding with '0's" in the sentence is not necessary in the final version. Thanks. I will remove the part.

> 
>    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".

It 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.

Agreed. I will remove them in the next version.

> 
>    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.

Agreed. I will remove "Thus" and move the sentence at the beginning of the section.

> 
> 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.

Agreed. I will remove the last paragraph.

> 
> 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?
> 

Agreed. I put the reference to section 9.1

Thanks again.