Re: [manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)

Lou Berger <lberger@labn.net> Mon, 06 May 2019 01:01 UTC

Return-Path: <lberger@labn.net>
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 88E3F1202C4 for <manet@ietfa.amsl.com>; Sun, 5 May 2019 18:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 ONJ7v_L-cQRh for <manet@ietfa.amsl.com>; Sun, 5 May 2019 18:01:05 -0700 (PDT)
Received: from outbound-ss-879.bluehost.com (outbound-ss-879.bluehost.com [69.89.30.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D679120440 for <manet@ietf.org>; Sun, 5 May 2019 17:58:21 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 6CA531E0C28 for <manet@ietf.org>; Sun, 5 May 2019 18:58:17 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NRxRhAP4EVLCbNRxRhaJ5m; Sun, 05 May 2019 18:58:17 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=EgUUTas6rGeQ/ErVOORTxtUI823bBatOOYSAthrjnkg=; b=OYrT6p8kkIelfw7eYKIrF26DAL 1lRdN28e7216wNDcMQR9/9BcqQxMh7etuCk1+LcZ8vW4K7lW2XqP1ZirQnX/+9GYGare1vaHHAn4L bFEZJOj9ozf2v/Mr2og3j3Fsg;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:52894 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hNRxR-00229W-1L; Sun, 05 May 2019 18:58:17 -0600
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff <sratliff@idirect.net>, aretana.ietf@gmail.com, manet-chairs@ietf.org, manet@ietf.org
References: <155493243926.22516.16080901486479388697.idtracker@ietfa.amsl.com>
From: Lou Berger <lberger@labn.net>
Openpgp: preference=signencrypt
Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU=
Message-ID: <84e2a05c-7729-d02e-3536-f6429476cc91@labn.net>
Date: Sun, 5 May 2019 20:58:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <155493243926.22516.16080901486479388697.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hNRxR-00229W-1L
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:52894
X-Source-Auth: lberger@labn.net
X-Email-Count: 14
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/Uu99exccDg0F6vr_6Jc5O-V214Y>
Subject: Re: [manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 06 May 2019 01:01:09 -0000

Hi,
	Please see below.

On 4/10/19 5:40 PM, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-manet-dlep-pause-extension-06: 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-manet-dlep-pause-extension/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Unauthenticated shutdown of the network seems exceedingly dangerous.  An
> expansion of the implementation scenarios described in Section 4 of RFC8175 and
> the architecture laid out in Figure 1 of RFC8175 appears to be:
> 
> (a) single direct connect (1x modem + 1x router)
> (b) single dedicated switch (1x modem + 1x switch + 1x router)
I think (a) and (b) are the normal expected configuration, but of course
defer to the WG and DLEP authors.

> (c) multiple connect (>1x modem + >=0 switches + 1x router)
I think this is allowed.

> (d) mobile environment (>=1x modem + switch + router + other devices in the
> switch) 
DLEP runs on the wired side, i.e., always between a modem and a local
router - never over a wireless network.  At least as I understand it.

>
(e) networked deployment (as stated in RFC8175/anything more
> complicated)
I don't think so.

> 
> I believe that the safest thing is that using TLS with this extension should be
> a MUST.  If that is problematic, then I’d only soften it to (text that amounts
> to) “in environments and deployment scenarios (a) and (b), TLS SHOULD be used. 
> In all other environments, TLS MUST be used.”
> 
I think this comment is really WRT base DLEP 8175 and that this
extension should be consistent with 8175.

> Warren: I believe that your neighbor scenario is likely scenario (c).
> 
how so?  when would a neighbor ever share a connection between a CPE
(modem) and a user's router?

> As the current security considerations say, using TLS in scenario (a) won’t
> help if the modem gets compromised.  In the above recommendation, there is an
> assumption that the switch(s) isn’t compromised (and that should be documented).
> 
Added to draft.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (0) I support Warren and Magnus’s DISCUSS positions.
> 
> (1) Section 3.1.  Per the Query Parameters data item, what is the router
> behavior when it receives:
> 
> ** Num Queues = 0
> ** Num Queues <> the queues sent?
> 

This is covered by the current text:

      Queue Parameter Sub Data Items are an unordered list composed of
      sub data items with a common format.  The format of the Queue
Parameter Sub
      Data Item is patterned after the standard DLEP data item format,
      see <xref target="RFC8175"/> Section 11.3.  Any errors
      or inconsistencies encountered in parsing Sub Data Items are
      handled in the same fashion as any other Data Item parsing error
      encountered in DLEP.

> (2) Section 3.1.  Nit.  The size of the Reserved field is not indicated in the
> text (like the other fields)
corrected!

> 
> (3) Section 3.1.1, Please provide a section reference into RFC8175 on error
> parsing.
I've added text extracted from 8175:

      In particular, the receiving implementation MUST issue a
      Session Termination Message containing a Status Data Item with
      status code set to 130 'Invalid Data' and transition to the
      Session Termination state.


> 
> (4) Section 3.2  Per “Each Pause Data Item identifies the traffic to be
> suppressed by the Queue Index defined by Section 3.1”, am I reading it right
> that a Queue Parameter Data Item needs to be sent before a Pause is sent?  If
> so, I’m not sure that is said anywhere and should be.  Furthermore, how does a
> router behave if it does get a Pause message prior to getting a Parameter Data
> Item message?

This isn't possible as defined since it states in the Queue Parameter
section:
   This data item MUST be
  included in a Session Initialization Response Message that also
  contains the Control Plane Based Pause Extension Type Value in the
  Extensions Supported Data Item.

and this exchange takes place before data can be sent.

> 
> (5) Section 3.3  Related to comment-4, How does a router behave if it gets a
> Restart message prior to getting a Parameter Data Item or Pause message?
> 

same response.

Thanks for the comments. Please let me know if you still have any
outstanding comments/DISCUSSes..

Lou
> 
>