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

최영환 <yhc@etri.re.kr> Tue, 24 March 2020 12:14 UTC

Return-Path: <yhc@etri.re.kr>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F993A0967 for <6lo@ietfa.amsl.com>; Tue, 24 Mar 2020 05:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIZWigZDqWb6 for <6lo@ietfa.amsl.com>; Tue, 24 Mar 2020 05:14:01 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD7C3A095C for <6lo@ietf.org>; Tue, 24 Mar 2020 05:13:59 -0700 (PDT)
Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.141) by 129.254.9.16 with ESMTP; 24 Mar 2020 21:13:50 +0900
X-Original-SENDERIP: 129.254.27.141
X-Original-MAILFROM: yhc@etri.re.kr
X-Original-RCPTTO: 6lo-chairs@ietf.org, 6lo@ietf.org, jari.arkko@piuha.net, carlesgo@entel.upc.edu, noreply@ietf.org, iesg@ietf.org, draft-ietf-6lo-nfc@ietf.org
Received: from SMTP5.etri.info (129.254.28.75) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 24 Mar 2020 21:13:52 +0900
Received: from SMTP2.etri.info ([169.254.2.81]) by SMTP5.etri.info ([129.254.28.75]) with mapi id 14.03.0439.000; Tue, 24 Mar 2020 21:13:51 +0900
From: =?utf-8?B?7LWc7JiB7ZmY?= <yhc@etri.re.kr>
To: Alissa Cooper via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-nfc@ietf.org" <draft-ietf-6lo-nfc@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "jari.arkko@piuha.net" <jari.arkko@piuha.net>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS and COMMENT)
Thread-Index: AQHU2awX2QpvTq1510C65T1kyPmomahZ8FWg
Date: Tue, 24 Mar 2020 12:13:50 +0000
Message-ID: <B2C0C4C29044814AB285BBB7C754D9249C496472@SMTP2.etri.info>
References: <155248861382.28045.423543698576779836.idtracker@ietfa.amsl.com>
In-Reply-To: <155248861382.28045.423543698576779836.idtracker@ietfa.amsl.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.254.26.37]
Content-Type: multipart/alternative; boundary="_000_B2C0C4C29044814AB285BBB7C754D9249C496472SMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/1v4CJg8JAcYB3c0DOKsCaMBkw_8>
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 12:14:04 -0000

Hi Alissa,

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 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: Alissa Cooper via Datatracker <noreply@ietf.org>
     Sent: Wednesday, March 13, 2019 11:50 PM
     To: The IESG <iesg@ietf.org>
     Cc: draft-ietf-6lo-nfc@ietf.org; Carles Gomez <carlesgo@entel.upc.edu>du>; Samita Chakrabarti <samitac.ietf@gmail.com>om>; 6lo-chairs@ietf.org; carlesgo@entel.upc.edu; 6lo@ietf.org; jari.arkko@piuha.net
     Subject: Alissa Cooper's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS and COMMENT)

     Alissa Cooper 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:
     ----------------------------------------------------------------------

     I support Benjamin's DISCUSS point about large antennas.

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 regular NFC antennas. 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.


     RFC 2119 specifies the keywords "RECOMMENDED" and "NOT RECOMMENDED." This document uses these in verb form ("RECOMMEND" and "NOT RECOMMEND"). Please change these instances so that the actual 2119 keywords are used.

I have checked them again as you concerned.

     = Section 4.8 =

     I think the Gen-ART reviewer's question about fragmentation is unresolved. How is interoperability achieved if some nodes implement MIUX and not FAR, and some nodes implement FAR and not MIUX? It seems as though IPv6-over-NFC needs to be restricted to nodes that support one or the other (presumably MIUX).

IPv6-over-NFC is restricted to NFC devices that support MUIX in the final draft.

     = Section 5.1 and 7 =

     Per the Gen-ART review, one of these sections needs to say something about how connecting to the Internet potentially changes the threat model for devices that were perhaps not originally envisioned to connect to the Internet.

Agreed. I will put more explanations about the threat model at the end in section 7.
" This document does not RECOMMEND sending NFC packets over the Internet or any unsecured network.
Especially, there can be a threat model in the scenario of section 5.1. when the NFC-enabled device links to a NFC-enabled gateway for connectivity with the Internet, the gateway can be attacked. Even though IPv6 over NFC guarantees security between the two NFC devices, there can be another threat during packet forwarding. "

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

     = General =

     I agree with Benjamin that the marketing-type language in the document should be removed.

Agreed. I have removed the marketing-like languages in the document (-15).

     I wonder about the claims of security based on proximity in this document.
     Presumably attacks in which users are induced to tap their device against another node or terminal which has been compromised by an attacker are becoming more common as NFC becomes more common; adding IPV6 connectivity to the terminal stack surely broadens the potential damage done in such a case. This seems worth noting.

     = Section 1 =

     OLD
     It has been used in devices such as mobile phones, running Android operating
        system, named with a feature called "Android Beam".  In addition, it
        is expected for the other mobile phones, running the other operating
        systems (e.g., iOS, etc.) to be equipped with NFC technology in the
        near future.

     NEW
     At the time of this writing, it had been used in devices such as mobile phones, running Android operating
        system, named with a feature called "Android Beam".  It was expected for the
        other mobile phones, running the other operating systems (e.g., iOS, etc.)
        to be equipped with NFC technology in the near future.

Thanks a lot. I have already put the new one. (in ver.-15)

     = Section 4.5 =

     Per the Gen-ART review, the use of the term "meet" is confusing in this section. Please re-phrase.

Agreed, I have changed it with "are connected". (in ver.-15)