Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB (non) use of beacons

John Kenney <jkenney@us.toyota-itc.com> Thu, 02 February 2017 18:12 UTC

Return-Path: <jkenney@us.toyota-itc.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7094B129502 for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 10:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73oG-PQpq-Ho for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 10:12:16 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3B512941D for <its@ietf.org>; Thu, 2 Feb 2017 10:12:16 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id u143so13981387oif.3 for <its@ietf.org>; Thu, 02 Feb 2017 10:12:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uAMhVw7j3dLUo4D7GXt4M/fkI6WAPdZKsFBXO/CVl6U=; b=rY3MFGJMqkh3AXhQRXqIXzIf+HXFGf9YMVRv/KKv7XXnRt2Y8ZF+vaPoBIJ2Ws53BD Ah1KeRoky0BuLTLOClC8MRIgNFvUOiDBQ7dp2bOLkadxcPMs2A7+BiJDUNSkglGsQC+8 +22W2+vseyGgZjTOBo6yDmU7POAfWNV7/z87aYx+bEAQjOyjCiX8ANhtEGQr35lkf+Ab NtTP7p8z1CFKSONUDQcVYfbqdx+Pklm5RWYZ0su0VYET2LoVORl+lcmIvgVWBX0lQmFe 1eufjdSr6pK1CBiEu7yt6FkRH5GQ2zhMBrMcKBXxXDIyzwa2VGDyhRsd6rk7JIGRbqFK KmbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uAMhVw7j3dLUo4D7GXt4M/fkI6WAPdZKsFBXO/CVl6U=; b=uQuJwBwp5MiCFP8oeuRH5URiREiB397MwKf3AkZ60HSg9dbrhpqf5aRcabmtjmZvq1 Mep8QSu/nA7DgY/FPpdNoA5r+G21LQokiZu/MQDjYZsKKsjG6Z5231diCaqi+GYMvCuN kjWZnTiP84FbE3XJ+HJ38JzA2HAvdjhfLZ2DhXaJBdTh81/MWE9TNTEWlbZoxFS+JjSy tzPdBwUBFZjOjIWzzEiy8ry6VHfHryqQJJI6ct1xPP6U6Vb+5vGVOya0DWMwEakVcyxE 5bKqZJtVLW3vS1elFYxn7ikiED3TBkv2Ou43LnlG39g2QaYB5iqtDr5PVVaMnyetLHHm UxDw==
X-Gm-Message-State: AIkVDXIQKP2v8NDGfFKRyjxmwzqXTFMrFMD8o3ZjbjLez6PM85Cahd1+EpepgyPlc3CNWCXbq+OANIQDQoG/HaWH
X-Received: by 10.202.172.195 with SMTP id v186mr4285081oie.8.1486059135383; Thu, 02 Feb 2017 10:12:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.59.180 with HTTP; Thu, 2 Feb 2017 10:12:14 -0800 (PST)
In-Reply-To: <008301d27d7d$a913d940$fb3b8bc0$@eurecom.fr>
References: <148052970170.9607.12043916621198119260.idtracker@ietfa.amsl.com> <222853d1-235d-cd4e-844b-4ea6091bfb2b@cea.fr> <009901d27c83$3bd599e0$b380cda0$@eurecom.fr> <ABE9BD89094E4DCBA199B459F8176F2E@SRA6> <687e75fd-7e89-211e-bce3-fea861d7baf0@gmail.com> <2B86CDDB-C9AA-4605-B9B6-3DA6F2ABBE7F@eurecom.fr> <07e5f826-b99a-9308-8ede-9fb659a9c248@gmail.com> <CD72343E-1358-4A29-AD98-CEFBD9DA4492@eurecom.fr> <79bec1de-c306-45a5-51a3-a00163566633@gmail.com> <008301d27d7d$a913d940$fb3b8bc0$@eurecom.fr>
From: John Kenney <jkenney@us.toyota-itc.com>
Date: Thu, 02 Feb 2017 10:12:14 -0800
Message-ID: <CAP6QOWQZCAojhKFC-US_h4P58eXDVyskzhZtsEWidwaYPhMtYQ@mail.gmail.com>
To: Jérôme Härri <jerome.haerri@eurecom.fr>
Content-Type: multipart/alternative; boundary="001a113ce7e2e1509d0547901a96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/HtwTakG4HAuhwSI-NNrsmBcVbs0>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "R. Roy" <dickroy@alum.mit.edu>, "its@ietf.org" <its@ietf.org>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB (non) use of beacons
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 18:12:19 -0000

I completely agree with Jérôme.

If a device is sending a beacon, it is simply not conforming to "outside
the context of a BSS" 802.11 operation.

That might be fine, insofar as a device that supports DSRC might also
support regular 802.11 (or other completely different protocols). Most DSRC
prototypes do in fact support other protocols as well.

But, it is clear that a beacon is not permitted by the portion of the
standard that specifies OCB operation (the language was quoted in a
separate email). So, a device cannot claim to be conforming to OCB when it
sends a beacon. It would be incorrect for the ID to say that a device might
legitimately send a beacon while operating OCB.

You are hearing this directly from several people who actually wrote the
standard.  I hope this input is useful to you.

I will note one other possible source of confusion, in case some people
have run into this.  One important message type used in DSRC is the Basic
Safety Message (or equivalent messages in other standards, e.g. CAM).  In
research literature, it is not uncommon (especially in older papers) to see
these safety messages referred to as "beacons".  That is an entirely
different usage of the word beacon from the 802.11 sense that we are
discussing in this thread.

Best Regards,
John


On Thu, Feb 2, 2017 at 9:56 AM, Jérôme Härri <jerome.haerri@eurecom.fr>
wrote:

> Hi Alex,
>
> Well, again we need to check who 'validated' the conformance of an OCB
> implementation, if any? I mean, even if we capture a beacon, it can also be
> a wrong implementation of a standard...we need to stay on facts from the
> standard, not from available implementations...
>
> btw, as this draft is aimed as a WG RFC, should we only refer to standards
> and not to implementations ?
>
> Best Regards,
>
> Jérôme
>
> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Thursday 02 February 2017 18:39
> To: Jerome Haerri
> Cc: dickroy@alum.mit.edu; its@ietf.org
> Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB
> (non) use of beacons
>
> Jérôme,
>
> I agree to avoid creating alternative facts.
>
> Is there a packet capture showing Beacons on 802.11-OCB?  If not then
> that's it.
>
> Alex
>
> Le 02/02/2017 à 18:17, Jerome Haerri a écrit :
> > Alex,
> >
> > Look, I also have to read standards to understand them and sometimes,
> > they are ambiguous...
> > But here, we have people who actually _took part of the writting_, of
> > the 802.11p/OCB mode, and clearly and with absolutely no ambiguity
> > stated that beacons are not sent in OCB...we should listen to them I
> think..
> >
> > let's not create '_alternative facts_' here...a 'trumpization' of the
> > standard work process will get us nowhere..
> >
> > Best Regards,
> >
> > Jérôme
> >
> > Envoyé de mon iPhone
> >
> > Le 2 févr. 2017 à 17:58, Alexandre Petrescu
> > <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> a
> > écrit :
> >
> >> Dear Jérôme,
> >>
> >> Le 02/02/2017 à 17:00, Jerome Haerri a écrit :
> >>> Dear Alex,
> >>>
> >>> well, If I cross on red lights, we cannot then say that as I did,
> >>> then crossing on red lights is allowed..
> >>
> >> Except that here we are making the red lights too :-)
> >>
> >>> if OCB implementations are sending beacons, then it is an
> >>> implementation issue..it does not mean that beacons should be
> >>> transmitted by the standards..
> >>
> >> Or vice-versa: the stds may need to reflect what's happening in
> practice.
> >>
> >> In my lab there are such beacons.  In other lab too.  It is for this
> >> reason that I have the doubt.
> >>
> >> I can not put in an Internet Draft (I-D) text that simply comes from
> >> other standards.  I-D should contain text that is about running code.
> >>
> >> And, of course, I need to put in this I-D what the WG thinks is good.
> >> This is why I am asking.
> >>
> >>> Would still suggest to keep the original version or cut-past the
> >>> exact statement from 802.11-2016 about allowed messages in OCB mode.
> >>>
> >>> But just asking frankly: why do you want to keep this statement
> >>> about beacons (allowing them to be sent) ? we spend too much time on
> >>> useless details and not on other key issues..
> >>
> >> Because I have no guarantee that if I put there "Beacons MUST NOT be
> >> sent" implementers will do so.
> >>
> >> I wonder whether there is a reason why Beacons are there in these OCB
> >> implementations that send them.  Or maybe it's just because they are
> >> forgotten there during migration from .11bgn driver to .11-OCB driver.
> >>
> >> Alex
> >>
> >>>
> >>> Best Regards,
> >>>
> >>> Jérôme
> >>>
> >>> Envoyé de mon iPhone
> >>>
> >>>> Le 2 févr. 2017 à 16:20, Alexandre Petrescu
> >>>> <alexandre.petrescu@gmail.com
> >>>> <mailto:alexandre.petrescu@gmail.com>>
> >>>> a écrit :
> >>>>
> >>>> But some OCB implementations do send Beacons.
> >>>>
> >>>> In that sense, I propose to say the following.
> >>>>
> >>>>>> 4.  Aspects introduced by the OCB mode to 802.11
> >>>>>>
> >>>>>> In the IEEE 802.11 OCB mode, all nodes in the wireless range can
> >>>>>> directly communicate with each other without authentication/
> >>>>>> association procedures.  Briefly, the IEEE
> >>>>>> 802.11 OCB mode has the following properties:
> >>>>>>
> >>>>>> o  Wildcard BSSID (i.e., all bits are set to 1) used by each node
> >>>>
> >>>> old:
> >>>>>> o  No beacons transmitted
> >>>>
> >>>> new:
> >>>>>> o  OCB implementations do not receive beacons and most OCB
> >>>>>> implementations do not transmit Beacons.
> >>>>
> >>>> Alex
> >>>>
> >>>>
> >>>>> Le 01/02/2017 à 20:20, Dick Roy a écrit : To reiterate, in OCB
> >>>>> operation there are NO beacons and there are NO APs.
> >>>>>
> >>>>>
> >>>>>
> >>>>> RR
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ------
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >> *From:*Jérôme Härri [mailto:jerome.haerri@eurecom.fr] *Sent:*
> >>>>> Wednesday, February 1, 2017 4:04 AM *To:* 'Alexandre Petrescu';
> >>>>> its@ietf.org <mailto:its@ietf.org> *Subject:* Re: [ipwave]
> >>>>> draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dear all,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I do not agree and I would be happy to have the reference in the
> >>>>> IEEE 802.11-2016 stating otherwise.
> >>>>>
> >>>>>
> >>>>>
> >>>>> In the 802.11 standard, it clearly state the following line:
> >>>>>
> >>>>>
> >>>>>
> >>>>> When dot11OCBActivated is true in a STA:
> >>>>>
> >>>>> " The STA _may send management frames of subtype Action_ and, if
> >>>>> the STA maintains a TSF Timer, subtype Timing Advertisement "
> >>>>>
> >>>>> " The STA may send _control frames_, _except_ those of _subtype
> >>>>> PS-Poll, CF-End, and CF-End + CFAck_ "
> >>>>>
> >>>>> " The STA may send _data frames of subtype Data, Null, QoS Data,
> >>>>> and QoS Null_. "
> >>>>>
> >>>>>
> >>>>>
> >>>>> A beacon is a management frame, but not of a class Action, so it
> >>>>> _cannot be transmitted when dot11OCBActivated_ is true in a STA.
> >>>>> But I agree that it is ambiguous…nevertheless, I would then
> >>>>> replace in the draft the mention of what OCB can do or can’t do
> >>>>> (e.g. sending beacons) with the exact 802.11-2016 statements.
> >>>>> This would avoid misunderstanding.
> >>>>>
> >>>>>
> >>>>>
> >>>>> But even if it could be possible, this does not make much sense.
> >>>>> A beacon is transmitted on a channel you need to connect to get
> >>>>> BSS information and also to get the right frequency. In case of
> >>>>> OCB (outside context of a BSS), it is not required. But the real
> >>>>> question is ‘why’ would we need beacon, assuming it could be
> >>>>> transmitted?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Best Regards,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Jérôme
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----Original Message----- From: its [mailto:its-bounces@ietf.org]
> >>>>> On Behalf Of Alexandre Petrescu
> >>>>> Sent: Wednesday 01 February 2017 11:51 To: its@ietf.org
> >>>>> <mailto:its@ietf.org> Subject:
> >>>>> [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use
> >>>>> beacons
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hello IPWAVErs,
> >>>>>
> >>>>>
> >>>>>
> >>>>> It was suggested in private that, contrary to what the draft says,
> >>>>> the .11-OCB does use beacons.
> >>>>>
> >>>>>
> >>>>>
> >>>>> As such, the following line should disappear from the draft:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> 4.  Aspects introduced by the OCB mode to 802.11
> >>>>>
> >>>>>>
> >>>>>
> >>>>>> In the IEEE 802.11 OCB mode, all nodes in the wireless range can
> >>>>>
> >>>>>> directly communicate with each other without authentication/
> >>>>>
> >>>>>> association procedures.  Briefly, the IEEE 802.11 OCB mode has
> >>>>>> the
> >>>>>
> >>>>>> following properties:
> >>>>>
> >>>>>>
> >>>>>
> >>>>>> o  Wildcard BSSID (i.e., all bits are set to 1) used by each node
> >>>>>
> >>>>>>
> >>>>>
> >>>>>> o  [strike through] No beacons transmitted
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yours,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Alex
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>



-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644