Re: [Anima] MACsec as an alternative to L3-tunnels

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 12 August 2019 21:09 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18728120125 for <anima@ietfa.amsl.com>; Mon, 12 Aug 2019 14:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 stUILuqxIxvf for <anima@ietfa.amsl.com>; Mon, 12 Aug 2019 14:09:54 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE7B1210F1 for <anima@ietf.org>; Sun, 11 Aug 2019 19:45:36 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id 4so40309690pld.10 for <anima@ietf.org>; Sun, 11 Aug 2019 19:45:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=iRxHgey5XDNs8vYFrIEW7b/0WVp5kVSrE7YsF3oUeN0=; b=KOBDDRSYK4lzt/47J/7tjerarf3Q/J1txGnTWk0s6KXqd4QTl7ivfW8ViFaQSqN/VU PmRAfkDetqDjKQVMR1llElrQAG87be7zQJKRNf+dm1fguczpVsfw8VUdIg3LVJFZ8KzB 54i/Z1CrHt6rH03H3SPTHb/fVJHMd8ssROhV7/3XB2ExPXpG4DG2vIG1hmWkvkYRjl7a ex/mC7U9fBNhuASLCn5pQRKI6fRpDSPdrMqe1IA0NCbr6uZ5IZ4RvzUm6GGU5OzM46nY PTOMScu1tko2am4Z0gbXm8ncHSlUIC8Et5nDMuEZWTIm7XRNE23EQG14b3+ZhVAA0X0f J6xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iRxHgey5XDNs8vYFrIEW7b/0WVp5kVSrE7YsF3oUeN0=; b=cjMnFy2rvtwm7+P9Kc3Fj6Oud0tN/TDB6wg/Drnm8BE0B6u9HaHfsRGzbu123em23P yxw8TnyZH2Lu6pbU7TlFsmQo277ofmw0L+TYaf5kf7jvMu7+USikACTvjxC9zztS4Z7H nCeBOIn1YprblHSapi5rKg9rTWIEq2ZrksH4TLjzxEul1ALdknBzxyLvA4kVrZXE5Se7 FDZEnPd6sD/hUEZUz9xudXTVQ4JOkk7uoW5UzzptDJ/v+tuRTwvGEzqNnyFHdb0Wb0vO k6i2lPYSxB6LKVAHPt5kl8JCUsBBD5x6EWXh1o/svRjasJveKeG6LxSASmI9hejmx7F0 VhBQ==
X-Gm-Message-State: APjAAAWCMzK0qWTIjM8ESMgy59CiQHH5XPjHfUifEq9tRcqouU1b/O/c O9x8/QR3rjL80n7Q+n8++zFwzwW0
X-Google-Smtp-Source: APXvYqwBMWBNtt4A1QJ1pBOPpml/BZeQQ7g9u3QCz/lVwdZjh/JgRgJXf+42cWsDAD4CQmlJCcl6gQ==
X-Received: by 2002:a17:902:b193:: with SMTP id s19mr31162225plr.258.1565577935693; Sun, 11 Aug 2019 19:45:35 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id v8sm7811954pjb.6.2019.08.11.19.45.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Aug 2019 19:45:34 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>, "Liubing (Leo)" <leo.liubing@huawei.com>, Anima WG <anima@ietf.org>
References: <DM6PR11MB3385255D58A133B186AA547EDBC60@DM6PR11MB3385.namprd11.prod.outlook.com> <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f91778de-9e0f-e61c-e86f-5bbf4aa5eba8@gmail.com>
Date: Mon, 12 Aug 2019 14:45:30 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <6709.1564009422@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/CN7EbS6jQ-Uf_2muitZKD3KpcKY>
Subject: Re: [Anima] MACsec as an alternative to L3-tunnels
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2019 21:09:58 -0000

Hi,

In the context of the L2ACP draft (draft-carpenter-anima-l2acp-scenarios):

It seems that MACsec keying and associations are generally pair-wise, but IEEE Std 802.1AE-2018 says:

"The guarantees provided by MACsec support the following security services for stations participating in MACsec:
a) Connectionless data integrity [6.8a), 6.8b)]
b) Data origin authenticity [6.8a)]. If the connectivity model is point-to-point, the originator is authenticated, but _if the connectivity model is multipoint, then the authenticated originator is any member of the CA, rather than a particular individual station._
c) Confidentiality [6.8d)]
d) Replay protection [6.8c), 6.8d)]
e) Bounded receive delay"

Also 802.1 bridges do forward MACsec. So multicast should work. However

1) This does not carry over to 802.11. An L2ACP that was a mixture of 802.1 and 802.11 would need to deal with two different security solutions.

2)

On 25-Jul-19 11:03, Michael Richardson wrote:

> I was asked to decode words mangled at the mic at Tuesday morning's ANIMA
> meeting.
> The word was "MACsec", and 
>     https://en.wikipedia.org/wiki/IEEE_802.1AE
>     https://1.ieee802.org/security/802-1ae/        
> 
> provides a reasonable description, and probably the getieee mechanism
> might get you a copy for free, but IEEE doesn't have a URL that
> leads to the actual document.  I did read it once.
> (One of the URLs in the wikipedia page leads to 404)
> 
>     https://ieeexplore.ieee.org/document/8585421
> might get you the document if you have a valid password, which
> I used to, but apparently not anymore.

We should use the 2018 version of the standard, which should be freely available via
https://ieeexplore.ieee.org/browse/standards/get-program/page

> Given my newly acquired understanding that MACsec applies on a per-port
> basis, not on a per-VLAN basis, this means that it would be rather difficult
> to do peer discovery and security for a L2-bridged LAN.

As I read the current standard, it should work, but if you do MACsec then the user plane VLAN is apparently protected by the same keys as the ACP VLAN. However, the two VLANs would still be completely protected from each other by 802.1Q, so I think it's OK.

On 31-Jul-19 08:41, Toerless Eckert wrote:
...
> I think my reference was more to what chips can do as to what
> necessarily existing standaerds may say. There is this one issue of
> having an 802.1ae capable switch port connected via a hub to multiple
> host, in which case you could imagine to use a different set of keys to
> each host but the public vendor documentation i found was quite
> inconclusive whether this actually works in todays products.

Yes, Google finds various different proprietary explanations that seem incompatible. Re the VLAN question, StackExchange says: "There is no standard for MACSec and 802.1Q, so manufacturers have come up with their own solutions." That is no longer true; 802.1AE-2018 explains exactly how it co-exists with 802.1Q. But I doubt if the products have all been updated yet. We need an expert.

I like this explanation, but it's now out of date:
https://developers.redhat.com/blog/2016/10/14/macsec-a-different-solution-to-encrypt-network-traffic/

    Brian