[Roll] security for multi-link subnets

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 March 2013 18:20 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888F11E810F; Tue, 12 Mar 2013 11:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level:
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQCxa3RJd2H8; Tue, 12 Mar 2013 11:20:28 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC111E80FB; Tue, 12 Mar 2013 11:20:27 -0700 (PDT)
Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 1653922060; Tue, 12 Mar 2013 18:20:27 +0000 (UTC)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EDEB1CA0C7; Tue, 12 Mar 2013 14:20:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: saag@ietf.org
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 12 Mar 2013 14:20:23 -0400
Message-ID: <12252.1363112423@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org, Ted Lemon <mellon@fugue.com>, Ralph Droms <rdroms@cisco.com>
Subject: [Roll] security for multi-link subnets
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 18:20:29 -0000

It was pointed out in a private discussion that the inclusion of
security parameters in the ROLL applicability statements might be
surprising to some.  For those who want a quick look:
  http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/
  http://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicability/
  http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-building/

Specifically, people wouldn't not normally think to look at
applicability statements for a routing protocol to see that it is
specifying not just security parameters for the routing protocol 
itself, but in some cases, requirements on access to the LLN as well.

I agreed that perhaps this needed additional socialization, which I'm
trying to do with this email.

Some of my logic of what we are doing is that by (securely) assembling
a bunch of links into a multi-link subnet, that in effect the ROLL
applicability statements are in effect a kind of IP-over-FOO document.

To parallel it to other IP-over-FOO documents better, they often specify
things like how to encapsulate, and how to do address resolution on the
subnet. 

RPL LLNs do not use stock-ND/ARP (which normally would be specified in an
IP-over-FOO document), but rather use the RPL messages to discover other
nodes on the subnet.     I have asked that the applicability statements
be clear about if they use RFC6775 (6lowpan-ND), and if so, how. 

It was suggested really, we never did that before: specify security of
the network in IP-over-FOO documents.  Well, that's true, because we
never did a an IP-over-802.11, because it was ethernet.

When WIFI's various incarnations happened (remember borrowing 2Mb/s *FH*
wireless PCICIA cards back at IETF46?), they tried hard to make it look
like ethernet, with ethernet-like physical security (WEP == "Wired Equivalent
Privacy").  It's too bad that we didn't get more involved at the time,
in the end, we did EAP and keyprov in great part to get that part done
right.  I still think that the 802.11 security is largely a disaster. 

It is possible that the problem is the word "applicability", and perhaps
we should have a different term.  I would welcome discussion here, or
even just +1 that this is the right approach.




-- 
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/