Re: [6tisch] Intelligent JP / validating the MASA

Michael Richardson <mcr@sandelman.ca> Tue, 20 August 2019 19:58 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14272120A42 for <6tisch@ietfa.amsl.com>; Tue, 20 Aug 2019 12:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ABgJ5AEHWD8a for <6tisch@ietfa.amsl.com>; Tue, 20 Aug 2019 12:58:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4763B120A41 for <6tisch@ietf.org>; Tue, 20 Aug 2019 12:58:42 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 71457380BE; Tue, 20 Aug 2019 15:57:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 81790F2A; Tue, 20 Aug 2019 15:58:41 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
cc: Benjamin Kaduk <kaduk@mit.edu>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <malisa.vucinic@inria.fr>, Tero Kivinen <kivinen@iki.fi>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <MN2PR11MB356593FEE789835AC61E7589D8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB356593FEE789835AC61E7589D8AB0@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 20 Aug 2019 15:58:41 -0400
Message-ID: <11687.1566331121@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/a_fGoobxxnnmIe2oQ_3_IB9CQfk>
Subject: Re: [6tisch] Intelligent JP / validating the MASA
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 19:58:47 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > I'm looking for a consensus on how to address the following review
    > comment on the 6TiSCH Architecture by Benjamin:

a) I don't think that any details about the Join Proxy belongs in the
   architecture document.
   Any text in the architecture document that says too much should be
   deferring to minimal security.

b) It's not an HTTP PROXY with a CONNECT, and GET HTTP://.. support.
   It's not really an COAP PROXY (RFC7252 section 5.7).
   We describe it in section 4.3.2 as an application layer proxy.
   It can only send traffic to the JRC, and no other place.
   The description of it in section 7 of minimal-security as
   a RFC7252 forward-proxy does imply that it provides any kind
   of HTTP-proxy-like functionality.

    >> I'd like to see some discussion somewhere that the Join Proxy needs to
    >> take care
    >> to not be an open redirector by which an unauthenticated pledge can
    >> attack
    >> arbitrary network elements (whether within the LLN or on the broader
    >> network), e.g., by performing some validation on the claimed MASA
    >> identifier.
    >> Similarly, that the JRC will be exposed to lots of untrusted input and
    >> needs to be

    >> implemented in an especially robust manner.

The CoJP has no business looking into any of the packets, and should
not be looking at any MASA entities, because in 6tisch-minimal there is no
MASA.
It forward packets to a single destination at a time, and that's it.

    > Then again I'd like to discuss the split of what goes in the
    > architecture and what goes in Minimal security or elsewhere.

    > What do you think?

I think that the architecture document is out of control, and I said that in
my review a few months ago :-)

It says way too much, anticipates way too much incomplete work,
and therefore has too many informative references, and thus we get into
the trouble we are here.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [