Re: [manet] Ben Campbell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)

Rick Taylor <rick@tropicalstormsoftware.com> Thu, 15 December 2016 14:59 UTC

Return-Path: <rick@tropicalstormsoftware.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDE21296C9; Thu, 15 Dec 2016 06:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wtGskkVpV0HY; Thu, 15 Dec 2016 06:59:24 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25212129FA4; Thu, 15 Dec 2016 06:59:00 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Thu, 15 Dec 2016 14:58:19 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "ben@nostrum.com" <ben@nostrum.com>, "hrogge@gmail.com" <hrogge@gmail.com>
Thread-Topic: [manet] Ben Campbell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)
Thread-Index: AQHSVZ1UhsyOQarrJkGfk1iUDwr8gqEGpssAgAD9IACAARANAIAAZu4AgAABQIA=
Date: Thu, 15 Dec 2016 14:58:27 +0000
Message-ID: <1481813907.2566.16.camel@tropicalstormsoftware.com>
References: <148167372944.10880.17965532160271098693.idtracker@ietfa.amsl.com> <CALtoyokUNSOypVaiVXk=_6fx7TfsQr5ETGatd3t-Qa=edr=Tmw@mail.gmail.com> <D0192C79-F7EC-4DED-9AE8-23EC89F2DA8C@nostrum.com> <CAGnRvupCTaXwDf1y4k0FDeOjTYTjRG0P4twcw4Fzxc1zsKPcrg@mail.gmail.com> <770ED361-BE84-4C10-918D-1A99C6D5EDC2@nostrum.com>
In-Reply-To: <770ED361-BE84-4C10-918D-1A99C6D5EDC2@nostrum.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-ID: <885953cc-399c-404e-8b30-677280e8cf88>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/D0GMpgupbhWWyWGl3COMY8Xl6r4>
Cc: "manet@ietf.org" <manet@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-manet-dlep@ietf.org" <draft-ietf-manet-dlep@ietf.org>, "manet-chairs@ietf.org" <manet-chairs@ietf.org>
Subject: Re: [manet] Ben Campbell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 14:59:27 -0000

On Thu, 2016-12-15 at 08:53 -0600, Ben Campbell wrote:
> On 15 Dec 2016, at 2:45, Henning Rogge wrote:
> 
> > 
> > On Wed, Dec 14, 2016 at 5:31 PM, Ben Campbell <ben@nostrum.com>
> > wrote:
> > > 
> > > > 
> > > > We (the co-authors) have received feedback from some radio
> > > > vendors 
> > > > stating
> > > > that a "MUST use TLS" in all cases would be a show-stopper. We
> > > > see
> > > > deployments where a small number of devices co-exist on the
> > > > LAN 
> > > > segment -
> > > > for example, a router, a line-of-sight radio, a satellite
> > > > terminal, 
> > > > and a
> > > > small number of other devices. We're open to the construction
> > > > you 
> > > > suggest,
> > > > and will discuss it.
> > > Understood. That suggests there are reasons to not _use_ TLS
> > > other 
> > > than the
> > > listed one, so "MUST unless" may not be what you want.  Any
> > > thoughts 
> > > on why
> > > TLS should not be mandatory to _implement_?
> > I might exaggerate it a little bit but I think using TLS for DLEP
> > is
> > at best a waste of time to implement. I have yet to hear about an
> > attacker model for a single hop DLEP connection (which is necessary
> > because otherwise the bridged datapath is broken!) which is not
> > easily
> > dealt with MAC-layer security.
> > 
> > At worst TLS will kill one of the most important aspects of DLEP,
> > easy
> > integration and autodiscovery of radios by different vendors to any
> > kind of router.
> > 
> > TLS also opens  can of worms (additional questions). How is the
> > DLEP
> > certificates be handled? Are there mandatory types of certificate
> > algorithms (if not, you break interoperability)? How do you secure
> > the
> > UDP part of DLEP for discovery (DTLS?) ? How do you make sure that
> > the
> > DTLS connection is to the same endpoint as the TLS connection?
> > 
> > There is a LOT of work in this direction without any gain.
> IIRC, you are arguing against even the existing "SHOULD implement" 
> requirement?
> 
> When you talk about a single-hop connection, are you assuming a
> direct 
> connection from the router to the modem, or that the router and
> modem 
> are on the same LAN segment?

Most of the discussed use-cases where TLS is viewed as unnecessary are
direct connections, but some are single-hop with an 'externally secured
perimeter'.

The authors are happy with 'SHOULD' if it removes any blocks from the
IESG, and the WG consensus is that 'MUST' will not work for
implementers.

Rick