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

Benjamin Kaduk <kaduk@mit.edu> Thu, 06 June 2019 18:22 UTC

Return-Path: <kaduk@mit.edu>
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 88EAB1200C1; Thu, 6 Jun 2019 11:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7f3qZGvDIXTy; Thu, 6 Jun 2019 11:22:33 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 87C4F12006E; Thu, 6 Jun 2019 11:22:30 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x56IMPrR026092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Jun 2019 14:22:28 -0400
Date: Thu, 6 Jun 2019 13:22:25 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Lou Berger <lberger@labn.net>
Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, The IESG <iesg@ietf.org>, manet-chairs@ietf.org
Message-ID: <20190606182224.GC23396@kduck.mit.edu>
References: <155494445891.22757.7399588752085896470.idtracker@ietfa.amsl.com> <e20c4e6d-b36f-690c-2049-4bc81f5cd37a@labn.net> <20190506224055.GX19509@kduck.mit.edu> <10c43c45-877d-842d-b527-8ff0dd9cb600@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <10c43c45-877d-842d-b527-8ff0dd9cb600@labn.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/shjGk2--qDADVlaud9yWjS5gSOM>
Subject: Re: [manet] Benjamin Kaduk'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: Thu, 06 Jun 2019 18:22:36 -0000

Hi Lou,

Sorry for the long delay here; I'm in the process of moving from St. Louis
to Seattle and have had to take a bunch of time off in the process.

On Tue, May 07, 2019 at 10:34:57AM -0400, Lou Berger wrote:
> Please see responses below...
> 
> On 5/6/2019 6:40 PM, Benjamin Kaduk wrote:
> > On Sun, May 05, 2019 at 09:22:16PM -0400, Lou Berger wrote:
> >> Hi,
> >> 	My apologies, I thought I responded to this, but can't seem to find the
> >> response (hopefully my responses are consistent if I did!).
> >>
> >> On 4/10/19 9:00 PM, Benjamin Kaduk via Datatracker wrote:
> >>> Benjamin Kaduk 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:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the
> >>> values 0-3 are assigned, leaving 4-16k usable.  How will future values be
> >>> assigned?
> >>>
> >> A future revision or update of this document.  We discussed a IANA
> >> registry, but thought it overkill as future additions seem quite unlikely.
> > Okay.  The Discuss was just to make sure it was considered in some fashion;
> > we do have a bunch of documents that explictly note "additional values are
> > to be allocated by updates to this specification" but I do not insist on
> > it.
> >
> >>> In Section 3.1.1:
> >>>
> >>>     DS Field Qn:
> >>>
> >>>        The data item contains a sequence of 8 bit DS Fields.  The number
> >>>        of DS Fields present MUST equal the sum of all Num DSCPs field
> >>>        values.
> >>>
> >>> Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global
> >>> for this queue index, so there would just be one of them and no need to
> >>> take a sum.
> >> It's just saying that more than one DSCP can match to a single queue
> >> index value.
> > Okay, if I'm looking at the figure properly then this is just an editorial
> > issue, then:
> >
> >          0                   1                   2                   3
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |  Queue Index  |             Queue Size Qn                     |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         | Num DSCPs Qn  |  DS Field Qn  |              ...              :
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         :                          ...                  |  DS Field Qn  |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > So we have the chunk of stuff for a given queue (index), and the size of
> > that queue, then a separate array/length for the DS values.  The various DS
> > values that can match this queue index are the contents of this array, but
> > this is the only array in the sub data item describing this queue index.
> > If that's correct, then isn't the description of "DS Field Qn" just "The
> > sub data item contains a sequence of 8 bit DS Fields for this queue index.
> > The number of DS Fields present MUST equal this value."?
> 
> Yes - I'm fine with a specific text revision if you have one.

How about:

OLD:

      The data item contains a sequence of 8 bit DS Fields.  The number
      of DS Fields present MUST equal the sum of all Num DSCPs field
      values.

NEW:

      The data item contains a sequence of 8 bit DS Fields.  The number
      of DS Fields present MUST equal the value of the Num DSCPs field.

> 
> >
> >>> In Section 3.3:
> >>>
> >>>     A router which receives the Restart Data Item SHOULD resume
> >>>     transmission of the identified traffic to the modem.
> >>>
> >>> Why is this only a "SHOULD"?
> >> to cover the case where the router is choosing not to send data, e.g.,
> >> due to lack of available data or other policy such as traffic rate shaping.
> > Okay.  Frequently documents will give the reader some hint as to what the
> > exceptional cases might be, but I will not insist on it here.
> >
> >
> >>> Section 4
> >>>
> >>>                                   The extension does not inherently
> >>>     introduce any additional vulnerabilities above those documented in
> >>>     [RFC8175].  [...]
> >>>
> >>> As noted by others, this sentence is just not true.
> >>> I will not duplicate the suggestions for additional considerations that
> >>> need to be documented.
> >> Please see comments / discussion elsewhere on this.
> > Sorry, most of these threads have aged out of my cache; could you give me a
> > hint about whose ballot thread to look in, or a link?
> 
> Perhaps it's just best to point you at the current text and see if 
> you're okay with it -- see
> 
> https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-07#section-4
> 
> and let me/us know if you still have any unresolved comments.

My main issue is with "does not inherently introduce any additional
vunlerabilities" -- there's a new signal that if received by the router,
causes all traffic to stop.  There is some inherent risk of such a signal
being received erroneously, even if an attacker that could introduce such a
signal would need to be highly capable (and thus also capable of doing
damage in other ways), and of course the risk of random accidents is always
present.

So I think the intent here may be to say instead that "this extension does
not introduce any vulnerabilities that are inherently different from those
documented in [RFC8175]", since there are already other ways that an
attacker could cause the router to stop sending traffic to the modem.

> 
> >>> In particular, I agree with Roman that the use
> >>> of TLS needs to be mandatory, especially since this protocol is
> >>> nominally only defined for use with radio links.
> >>
> >> As covered elsewhere, in particular this is really a comment on base
> >> DLEP and I think this extension should be consistent with that document.
> >> (Consider an example from when 8175 was issued, consider the case where
> >> the modem and router use MACsec, 802.1X and 802.1 AE, why is TLS needed
> >> as well.)
> > Perhaps.  I think it's highly dependent on whether DLEP is only conveyed
> > over wired links and the physical scope of those links, though -- my
> > understanding is that most of the IESG was treating this protocol as
> > running over the radio link.
> 
> umm, DLEP is *NEVER* expected to run over the air.  This is covered in 
> RFC8175 and is not impacted by this extension.

I'm sorry that I (and the collective IESG) missed that; you are quite
correct.  (I think I was under severe time pressure reviewing this document
and only did targetted keyword searches in 8175 as I was reading.)

-Ben