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

From: Fumio Teraoka <[email-masked]>
Date: Sun, 06 Jan 2008 23:36:52 +0900

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jan 2008 15:36:33 +0200

Fumio,

Thanks for the update. A few comments inline:

>          what "link is connected" means depends on link types. 

Good.

>  For example,

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.

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

>          transmits control frames that indicate strong RSSI and weak RSSI

Ok, I think.

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

Jari

---

From: Fumio Teraoka <[email-masked]>
Date: Tue, 15 Jan 2008 00:32:00 +0900

Jari,

Thanks for comments. Replies are inline:

At 08/01/09 15:36 +0200, Jari Arkko wrote:
(snip)

>detail level that a fully defined interface would have to go to.

In my understanding of the IEEE802.11 infrastructure mode, at first,
a mobile node is in Unauthenticated & Unassociated State. Next,
the mobile node is authenticated and then the state changes to
Authenticated & Unassociated State. Finally, an association is
established with the AP and then the state changes to Authenticated
and Associated state. Thus, we defined that L2-LinkUp is provided
when an association is established in WiFi.

(snip)

>these metrics is error prone and not guaranteed to result in optimal

I agree that "decisions based on these metrics is error prone and
not guaranteed to result in optimal choice of links."
I'll attend this sentence at the last of "6.2 Condition".

(snip)

Best Regards,

Fumio Teraoka

---

From: "Rajeev Koodli" <[email-masked]>
Date: Mon, 28 Jan 2008 10:08:53 -0800

Hi Jari,
could we close this one? We could then send the revised ID for publication.

Thanks,

-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jan 2008 13:38:49 +0200

Rajeev Koodli kirjoitti:
> On Jan 14, 2008 7:32 AM, Fumio Teraoka <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Jari,
>

OK

>     I'll attend this sentence at the last of "6.2 Condition".

OK

jari
>     [email-masked] <mailto:[email-masked]>

---

From: Fumio Teraoka <[email-masked]>
Date: Tue, 29 Jan 2008 21:41:32 +0900

Jari, Rajeev,

I will submit a new version (-06) by the end of this week.

Regards,
Fumio Teraoka