[Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments
Fumio Teraoka <tera@ics.keio.ac.jp> Mon, 07 January 2008 01:42 UTC
Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBh0j-0000jr-23; Sun, 06 Jan 2008 20:42:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBWcg-0008T8-35 for mobopts@irtf.org; Sun, 06 Jan 2008 09:37:10 -0500
Received: from maro.tera.ics.keio.ac.jp ([131.113.71.3] helo=smtp.tera.ics.keio.ac.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JBWca-00029t-Ne for mobopts@irtf.org; Sun, 06 Jan 2008 09:37:10 -0500
Received: (qmail 67529 invoked from network); 6 Jan 2008 23:36:55 +0900
X-Authentication: tera was authenticated by 0 at 6 Jan 2008 23:36:55 +0900
Received: from unknown (HELO hotaka.ics.keio.ac.jp) (2001:200::6800::3) by 0 with SMTP; 6 Jan 2008 23:36:55 +0900
Message-Id: <6.2.3.4.2.20080106232845.079864c0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2
Date: Sun, 06 Jan 2008 23:36:52 +0900
To: Jari Arkko <jari.arkko@piuha.net>, Rajeev Koodli <rajeev.koodli@nokia.com>
From: Fumio Teraoka <tera@ics.keio.ac.jp>
In-Reply-To: <4761A5BE.8050509@piuha.net>
References: <C368CFA5.1D589%rajeev.koodli@nokia.com> <4761A5BE.8050509@piuha.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_789366046==_"
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f526f24f459cc7a00934c463cb2f9eb6
X-Mailman-Approved-At: Sun, 06 Jan 2008 20:42:40 -0500
Cc: "mobopts@irtf.org" <mobopts@irtf.org>
Subject: [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org
Dear Jari Arkko, Rajeev Koodli, We revised the document and submitted it (draft-irtf-mobopts-l2- abstractions-05.txt). Replies to the comments are described in line: At 07/12/13 23:35 +0200, Jari Arkko wrote: >FYI -- this document was on the IESG telechat a few weeks ago for the >does-not-conflict-with-WG-efforts check. The IESG had no problem in >publishing it. > >However, I also read the document for its technical content and wanted >post a personal opinion, as well as copy you on the some comments that >we received from other ADs during the review. > >Basically, I believe the specification of the interface is not detailed >enough to be implemented in the general case. Not that this is a >requirement for research work, but I hope no one thinks the work is now >done. > >For example, even after re-reading the document and its appendix, it is >unclear to me how the document proposes dealing with the intricacies >related to what it means to be associated with a wireless end point. In >802.11 having an association, having completed EAP/RSN, and having a >working IP interface are all different things. Presumably one would >prefer getting an indication when authentication and all required link >layer tasks complete, but the document does not say this. Link layer >fast handoff designs, web authentication, firewalls, etc complicate this >further. This document proposes interfaces between the link layer and other layers. We think how to deal with intricacies related to devices is implementation- dependent. As a hint, we added a new appendix (Appendix C. Example Mapping between L2 Primitives and Primitives in IEEE802.11 and IEEE802.16e) to show how to implement the proposed primitives in case of IEEE802.11 and IEEE802.16e. We modified the document as follows: - Sec. 4.5 L2-LinkUp (Type 2): - old: The L2-LinkUp.indication primitive is asynchronously provided to an upper layer when a new link is connected. - new: The L2-LinkUp.indication primitive is asynchronously provided to an upper layer when a new link is connected and IP packets can be transmitted through the new link. As described in RFC 4957[7], what "link is connected" means depends on link types. For example, in case of the infrastructure mode in IEEE802.11 (WiFi), this primitive is provided when an association to an access point is established. - Sec. 4.6 L2-LinkDown (Type 2): - old: The L2-LinkDown.indication primitive is asynchronously provided to an upper layer when an existing link is disconnected. - new: The L2-LinkDown.indication primitive is asynchronously provided to an upper layer when an existing link is disconnected and IP packets cannot be transmitted through the link. >Another example is the use of the link quality indicators. They appear >simple, but their use is far from trivial. Would you move from FAIR >802.11n to EXCELLENT 802.11b? What about BAD 802.11 to GOOD GPRS? > >To be usable the interfaces would have to have many of these details >worked out. For instance, RFC 4957 focused on one event for one purpose, >and it turned out that the interactions are far from trivial. The quality levels of a device are independent of those of other devices. We added sentences at the last of "Sec. 6.2 Condition" as follows: The quality levels of a L2 device are independent of those of other devices. An example of the thresholds among the five levels are described in Appendix E. We also added the description about the example thresholds in Appendix E. >In addition, Tim Polk was not convinced that the points raised in IAB >link indications document were adequately addressed. For example, >iab-link-indications notes for spoofing attacks: "However, even where >the link layer incorporates security, attacks may still be possible if >the security model is not consistent." Yet this document addresses >spoofing with a single sentence: " "Our proposal is nor more insecure >than a particular link layer on which it is implemented". These >statements appear to be a contradiction. Tim believed that the >treatment of spoofing >and denial of service should be expanded in the security considerations >section to clearly demonstrate the issues raised in iab-link-indications >have been fully addressed. We modified "Sec. 8. Security Considerations" as follows. - "Spoofing" part: - old: Our proposal is no more insecure than a particular link layer on which it is implemented. - new: The proposed primitives suffer from spoofed link layer control frames. For example, if a malicious access point is set up and spoofed beacon frames are transmitted, L2-PoAFound.indication is generated in the mobile node. As a result, the mobile node may establish an association with the malicious access point by L2- LinkConnect.request. - "Denial of service" part: - old: Our proposal is no more insecure than a particular link layer on which it is implemented. - new: Since this proposal does not change link layer protocols, no more insecurity is added to a particular link layer protocol. However, the proposed primitives suffer from denial of service attack by spoofed link layer frames. For example, L2- PoAFound.indication and L2-PoALost.indication may frequently be generated alternately if a malicious access point frequently transmits control frames that indicate strong RSSI and weak RSSI alternately. >Also, Dan Romascanu had questions about the usage or some link layer >specific terms. For example he was not sure whether the LinkUp and >LinkDown terms are aligned with the RFC 2863 terminology. In RFC 2863, linkUp is defined as "ready to pass packets". We think LinkUp and LinkDown in this document are aligned with RFC 2863. >Finally, some editorial issues: > >The document would probably benefit from a reference to RFC 4957. As described above, RFC 4975 is referred in Sec. 4.5. >Draft-iab-link-indications has been published as RFC 4907. Fixed. >Author's name in [7] should be "Aboba", not "Adoba". Fixed. >Jari Best regards, Fumio Teraoka
_______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] IRSG review of draft-irtf-mobopts-l2-ab… Rajeev Koodli
- [Mobopts] Request to publish draft-irtf-mobopts-l… Aaron Falk
- [Mobopts] draft-irtf-mobopts-l2-abstractions-04.t… Jari Arkko
- Re: [Mobopts] draft-irtf-mobopts-l2-abstractions-… Rajeev Koodli
- Re: [Mobopts] draft-irtf-mobopts-l2-abstractions-… Fumio Teraoka
- [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-… Fumio Teraoka
- [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-… Jari Arkko
- [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-… Fumio Teraoka
- Re: [Mobopts] Re: draft-irtf-mobopts-l2-abstracti… Rajeev Koodli
- Re: [Mobopts] Re: draft-irtf-mobopts-l2-abstracti… Jari Arkko
- Re: [Mobopts] Re: draft-irtf-mobopts-l2-abstracti… Fumio Teraoka