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

Fumio,

Thanks for the update. A few comments inline:

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

Good.

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

Really? I was under the impression that association was an early phase
and you would need to wait for something else if security was applied. I
could be mistaken, but this discussion is an example of the sort of
detail level that a fully defined interface would have to go to.

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

The added text is good, but I'm still not convinced that you have a
generic solution capable of operating in different conditions. It might
be more useful to simply acknowledge that making decisions based on
these metrics is error prone and not guaranteed to result in optimal
choice of links.

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

Ok, I think.

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

I cannot comment on this, but I Cced Dan. Maybe he can provide some
feedback.

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

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts