Hi Benjamin,
I’m Younghwan.
This is response on your DISCUSS and COMMENT about draft-ietf-6lo-nfc-13.
Actually, I have already answered your DISCUSS and COMMENT before, and I have
already produced -14 and -15.
However, I wonder I have addressed your DISCUSS and COMMENT about the
draft-ietf-6lo-nfc well or not.
Even though a lot of time has passed and so it is difficult for you to remember
details, I give you my answers again as bellows inline for the next step. If
you have another concerns, please response me..
Thanks a lot.
BRs,
Younghwan
-----Original Message-----
From: Benjamin Kaduk via Datatracker
<[email protected]<mailto:[email protected]>>
Sent: Thursday, March 14, 2019 11:19 AM
To: The IESG <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
Carles Gomez <[email protected]<mailto:[email protected]>>; Samita
Chakrabarti <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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.
Partially agreed with your concern, so 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.
It is true that RFC7217 is not providing the prefect solution for NFC. I will
mention your concern in the next version of draft.
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 have changed them for clarification (in version-15).
" 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 have changed 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.
(in version-15)
"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.
So, I have changed them like this (in version-15).
" 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.)
I have removed and changed the marketing-languages. (in version-15)
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".
Agreed, so I have changed them. (in version -15)
" 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 removed 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 removed 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 have changed the figure with new one.
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.
So, I merged MAC/PHY of NFC in the figure 3 (in version -15).
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 have changed 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 have changed 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 removed 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 mentioned them in version-15.
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?
So, I have changed 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 have removed 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 have removed 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 have already removed the paragraph in section 7 (in version -15).
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 have removed 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 have removed 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 have removed "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 have removed 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 have put the reference to section 9.1
Thanks again for your valuable comments.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
