Re: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
Nabil Benamar <n.benamar@est.umi.ac.ma> Wed, 10 July 2019 11:37 UTC
Return-Path: <n.benamar@est.umi.ac.ma>
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 C6F8F120153 for <its@ietfa.amsl.com>; Wed, 10 Jul 2019 04:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=est-umi-ac-ma.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 pqCB-0QPduQZ for <its@ietfa.amsl.com>; Wed, 10 Jul 2019 04:37:01 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 89E5912012B for <its@ietf.org>; Wed, 10 Jul 2019 04:36:57 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id k20so3898600ios.10 for <its@ietf.org>; Wed, 10 Jul 2019 04:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ccNVDPdevt3OqJcIajbxMW6tkuWYdyv9L6Agss5TBOE=; b=QBWH9ZhJjdnNqLqwv4RbtHcVA4HQ2Uf9vrfuZ+8dyakl/W4HOYV678WX/mu4ZN8kql zYeQomyuRZPlulIHP9p+eW4cIt07xBgRLWLwGnmSeAx5lou6KdYblFhApgne5/vJqKrB avatHZ/MTox1PxCI5EStP7pnbg4tysa1yKxbf3p7U8IfDJI1IJ+r1bNgpUb5ULAIiOiK qjyuxejt2SLXxu0kkMwCn1/+4fgqG5yiy1fenecpsQ609rlO0M212tvKRtxy1o0QItTW VfLTNQuqdsindy0HIfYCTkf0Iah56R0WL3+BV3PkkTIRCnFM/elmoVNTjZP+w4PenUuE 2c5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ccNVDPdevt3OqJcIajbxMW6tkuWYdyv9L6Agss5TBOE=; b=RWPHBaPyf1sXbnkinUCH2X3LevTqMeynVwvQpj9JhFG0g9f7e1Mv+BD5wir1xQotEA geVy4JCXQ9+utEafgEarnPwpd0s3+zabjfPEGqA1e1FGfkbvHUWGesWZTCKcyKhsQRrw Qr5iSUqYJSbkl00/cYyY7Z/HTR2/LysEGQbf808NxuyLBbLbG9d6t1IDHdVU1afc4zxf hKb6Lw1YvU0GOvRMJ2NA6qBTLOw4ENNmGEwK/3oOdr8KUkT59wkeG4Au6HzS/LNg3aiz WSxdmZQTgy+lX5AT1gBnEG7Q0rWQiNUfCOYZ4FajhjYnxi2DAPq022BwZlVNxlODSvAV YF4g==
X-Gm-Message-State: APjAAAUq2OHccIeasWT7IPfnw6Hf92/4sjvHqE2f4h4ViLzV+WM1ZNW9 6ItyvnvzBlsRLSNKsLuovx9ucK+og0mypGgs60olIQ==
X-Google-Smtp-Source: APXvYqzZ44rYW/Mp1I49lUcR2agQT5BgaRDU/Mr3AsmRqnKR0j7ew5wxNpX4gPZOUrK18w54kwV8FXmuDiiIdroiE0k=
X-Received: by 2002:a5d:88c6:: with SMTP id i6mr10089867iol.107.1562758616479; Wed, 10 Jul 2019 04:36:56 -0700 (PDT)
MIME-Version: 1.0
References: <156270262382.15819.8454309099280995022.idtracker@ietfa.amsl.com>
In-Reply-To: <156270262382.15819.8454309099280995022.idtracker@ietfa.amsl.com>
From: Nabil Benamar <n.benamar@est.umi.ac.ma>
Date: Wed, 10 Jul 2019 12:36:45 +0100
Message-ID: <CAD8vqFdf7yTAVFeiz7t4qazhcrYjDcMOPPbvfwQy2xcA9GjQ2A@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>, ipwave-chairs@ietf.org, its@ietf.org
Content-Type: multipart/alternative; boundary="000000000000348e8c058d5218b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/x40HpdvsnwQDISc2rgAQDkW3foQ>
Subject: Re: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Jul 2019 11:37:04 -0000
Hi Roman, Thank you for your detailed review. Let me start with the 'DISCUSS' comments. Please see my answers below. On Tue, Jul 9, 2019 at 9:03 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > A few items per the text in the Security Considerations (Section 5): > > (1) Section 5. Per “A previous work at SAVI WG identifies some threats > [RFC6959], while SeND presented in [RFC3971] and [RFC3972] is a solution > against address theft but it is complex and not deployed.”, a few > questions: > > ** What specific threats from RFC6959 are of concern? Which mitigations > for > them are being proposed? > > Since there is no Layer 2 security in OCB, anyone can join the same subnet and impersonate any only else, to source traffic and get the traffic back. > > There is no mitigation in this specification because it is limited to RFC 4861 and 4862 and SeND is not available in the current stacks. > > > ** Why mention SeND if it is “complex and not deployed”? > This was informational because it may be the only pertinent remediation. > (2) Section 5. Per “More IETF protocols are available in the toolbox of > the IP > security protocol designer. Some ETSI protocols related to security > protocols > in ITS are described in [ETSI-sec-archi].”: > > ** Are there specific protocols to mention here? Would they be > different/OCB-specific than what was already noted in the beginning of the > section -- “Any security mechanism as the IP layer or above that may be > carried > out …”? > > ** What specific ETSI protocols are being recommended from > [ETSI-sec-archi]? > This sentence is just informational. I propose to remove the whole sentence. > > (3) Section 5.2. Per “An Interface ID SHOULD be of length specified in > other > documents”, what other documents? > I'm afraid no other documents as mentioned by Alex in its reply. To be removed. > > (4) Section 5.3 I’m having trouble following this section – is this a > discussion of a threat or mitigation? The references to Section 4.4 and > 5.0 > didn’t clarity this for me. > > ** What is meant by the drivers’ identity in this case? What is the > pseudonym > scheme is being used to protect it or what requirements are being set for > it? > > ** What are the specific challenges of concern around pseudo-anonymization > approaches to which an allusion is made? > > ** Who is the trusted third parted needed? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (5) Section 1. Per “The resulting stack inherits from IPv6 over Ethernet > [RFC2462], but operates over …”, what exactly is being inherited? What > does > “inherited” mean in this case? > > (6) Section 4.3. Per “Among these types of addresses only the IPv6 > link-local > addresses can be formed using an EUI-64 identifier, in particular during > transition time”, the meaning of the “in particular during transition time > isn’t clear to me. > > (7) Section 5. Per “The OCB operation is stripped off of …”, is this > sentence > saying that OCB operations doesn’t use 802.11 link layer security > mechanisms, > or does the OCB operation actively remove (i.e., strips) 802.11 link layer > security mechanisms? I’m getting caught up in the use of “stripped off”. > > (8) Section 5, Per “Any attacker can therefore just sit in the near range > of > vehicles ... and performs attacks without needing to physically break any > wall”, I’d recommend revising this sentence to reflect that it isn’t just > vehicles and that active attacks are possible: > > NEW: > Therefore, an attacker can sniff or inject traffic while within range of a > vehicle or IP-RSU (by setting an interface card’s frequency to the proper > range). > > (9) Section 5. What is “protected 802.11” mentioned in “Such a link is > less > protected …”? > > (10) Section 5.2. SHA256 needs a reference. > > (11) Editorial Nits > ** Table of Contents. There is odd spacing in the title of Appendix C > > ** Section 1. Typo. s/Appendicies/Appendices/ > > ** Section 1. Typo. s/Concretly/Concretely/ > > ** Section 1. Editorial. s/[RFC1042], [RFC2464] ./[RFC1042 and > [RFC2464]./ > > ** Multiple sections. Editorial, to make an RFC citation a reference. > s/RFC2464/[RFC2464]/ and s/RFC 7217/[RFC7217]/ > > ** Section 4.5. Typo. s/.A A future/. A future/ > > ** Section 4.6. Typo. s/links; The/links. The/ > > ** Section 5.1. Typo. s/Futhermore/Furthermore/ > > ** Section 5.1. Typo. s/pricavy/privacy/ > > ** Section 5.2. Typo. s/admninistered/ administered/ > > ** Appendix B. s/Ammendment/Amendment/ > > ** Appendix H. Duplicate word. s/section Section 2/Section 2/ > > ** Appendix I. Typo. s/specificed/specified/ > > ** Appendix I. Typo. s/Moreoever/Moreover/ > > > -- Best Regards Nabil Benamar Associate Professor Department of Computer Sciences School of Technology Moulay Ismail University Meknes. Morocco
- [ipwave] Roman Danyliw's Discuss on draft-ietf-ip… Roman Danyliw via Datatracker
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Alexandre Petrescu
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Nabil Benamar
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Alexandre Petrescu
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Nabil Benamar
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Nabil Benamar
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Alexandre Petrescu