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

Jari Arkko <jari.arkko@piuha.net> Thu, 13 December 2007 21:36 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 1J2vir-0002tA-Fm; Thu, 13 Dec 2007 16:36:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2viq-0002t5-Go for mobopts@irtf.org; Thu, 13 Dec 2007 16:36:00 -0500
Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vip-0002dR-VG for mobopts@irtf.org; Thu, 13 Dec 2007 16:36:00 -0500
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id AC9181986CC; Thu, 13 Dec 2007 23:35:58 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 34DD719863E; Thu, 13 Dec 2007 23:35:58 +0200 (EET)
Message-ID: <4761A5BE.8050509@piuha.net>
Date: Thu, 13 Dec 2007 23:35:58 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: Rajeev Koodli <rajeev.koodli@nokia.com>, draft-irtf-mobopts-l2-abstractions@tools.ietf.org
References: <C368CFA5.1D589%rajeev.koodli@nokia.com>
In-Reply-To: <C368CFA5.1D589%rajeev.koodli@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -0.6 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: "mobopts@irtf.org" <mobopts@irtf.org>
Subject: [Mobopts] 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

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.

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.

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.

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.

Finally, some editorial issues:

The document would probably benefit from a reference to RFC 4957.

Draft-iab-link-indications has been published as RFC 4907.

Author's name in [7] should be "Aboba", not "Adoba".

Jari


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