[Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments

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] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments

Attachment: draft-irtf-mobopts-l2-abstractions-05.txt