Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04
David Mandelberg <david@mandelberg.org> Wed, 21 October 2020 02:12 UTC
Return-Path: <david@mandelberg.org>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA503A0A06 for <lisp@ietfa.amsl.com>; Tue, 20 Oct 2020 19:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org
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 fzR7weSQPwDn for <lisp@ietfa.amsl.com>; Tue, 20 Oct 2020 19:12:12 -0700 (PDT)
Received: from mail-pg1-x564.google.com (mail-pg1-x564.google.com [IPv6:2607:f8b0:4864:20::564]) (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 E92683A0A22 for <lisp@ietf.org>; Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
Received: by mail-pg1-x564.google.com with SMTP id r10so497796pgb.10 for <lisp@ietf.org>; Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oElIbPxmRpyqh9clPS0BSjRBHVs1/9zsrQdXnf/m6xI=; b=JCoVloGObHAArHnUjJlaH7ECB1GHLNgMesiHTJ21Q4Oli7bJRiAdM3ksGiy9kFARQA P1Bv5oaloxigAiqFaSlub8uGoxle90MdK0bPbGmcTdPsbRkLdbjm/5SMPX1B6/epC0B6 Hwk92higSEsNOO1tzstzOFYLUEUNEJN7nOmSZl76UYtemtbpY1fuEIsEBn4iVusUAC/s oAvH7gXOLSAqB900NnXL9eXrD5GlXy/5AIc/fe5S/J+e+/05PpZZrY7s4QGRRFBMtv8I Ld4Qsldft16PjQcmK91AFdzNmtVIbKLMlH29VPR1taDcoc9kSlWRdUpNXJKHp6f0eGgs Texg==
X-Gm-Message-State: AOAM530i5YAZYcTGWtU8z7rwjHeuIpOns0G8habhlecFsoWrZiGuZVnr fjVKW0150HHyRBVvCZ7dsU24QJ1i4m03pCG87lpowcXOHqI2Hg==
X-Google-Smtp-Source: ABdhPJyCi5DA4rsJfxiuWxExN9WV3b+cN8iuNdA/nSVtjtIUXAaxUIGnUcZY68K8Lrxr2lDWixv0ii7MR47j
X-Received: by 2002:aa7:962f:0:b029:156:51aa:d0a2 with SMTP id r15-20020aa7962f0000b029015651aad0a2mr975503pfg.20.1603246331188; Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
Received: from uriel.mandelberg.org (pool-100-0-196-177.bstnma.fios.verizon.net. [100.0.196.177]) by smtp-relay.gmail.com with ESMTPS id m7sm94823pjk.13.2020.10.20.19.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
X-Relaying-Domain: mandelberg.org
Received: from [192.168.1.162] (nevia [192.168.1.2]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6F0911C6066; Tue, 20 Oct 2020 22:12:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202009; t=1603246329; bh=z5HtFHbxdp1upFH7jVQwFXnx5LhxzzZKyWkMQ4JA62A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AcivY0c6beHC8LLfZJ6KTL6cFMoy/+fxRzrVpDXKRvnNCqVeVGDT4AclzGvItK279 +KbDHpxD9dpYx2qoHqh4m0uI/mR9w4D0ZzlNYKMUvtt/qNRcORg7qOdtDU6Jcta241 EMhsodAznENiZKzNKEEcq0U9CO8R0P1QTz+oNRAllMsZFIhpmBZh+gKQELk2m/w/WJ tXpWMWRUroBHH67gwpDFR4PfSfSS3dotj07Dox+RsbmjrfEEVy4PprP6Y7BBrwWTrv HdWc9pRZIY2sIxJhAqIvk1m5FoVbA/PuIb+QhINKZsZ5/NacJqiJWBWBYn8s0atWOH Ih7Ft8nCJKZQA==
To: Sharon Barkai <sharon.barkai=40getnexar.com@dmarc.ietf.org>
Cc: secdir@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-nexagon.all@ietf.org
References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> <5bd465d2-449c-6b1d-f83f-0e3489f1bf22@mandelberg.org> <EDED58F4-E82F-4B14-8633-3B02B6F082D9@getnexar.com>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <1f0f6ce9-06b1-d92d-200b-29477efe4c38@mandelberg.org>
Date: Tue, 20 Oct 2020 22:12:07 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <EDED58F4-E82F-4B14-8633-3B02B6F082D9@getnexar.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/XuOG5EtWDd_mm91vYkDL4cnGIc4>
Subject: Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2020 02:12:15 -0000
Thanks, draft-ietf-lisp-nexagon-06 addresses all of my concerns. (And sorry about the email issues and associated delays.) On 10/20/20 1:34 AM, Sharon Barkai wrote: > > >> On Oct 20, 2020, at 02:34, David Mandelberg >> <david=40mandelberg.org@dmarc.ietf.org >> <mailto:david=40mandelberg.org@dmarc.ietf.org>> wrote: >> >> (I previously sent the email below on 2020-10-10, but I don't think it >> went through due to an email server misconfiguration. Sending again >> now that my email issues are fixed, I think) > > Made it! > >> >> On 10/9/20 1:32 PM, Sharon Barkai wrote: >>> Sorry for the confusion, David! really want to thank you for putting >>> in the time, you clearly understood the draft completely and point to >>> areas we invested thought on but can improve the wording. >> >> No worries. I'm just glad I noticed that my initial review email >> didn't go through. Hopefully this one does? >> >>> Before adjusting the draft would like to rehash together with the >>> group, Joel, and Luigi the themes pointed, which are spot on, so to >>> reach the best possible language. >>> 1) End to end encryption - >>> Nexagon uses LISP overlay encapsulations end to end: >>> - between EIDClients and EdgeRTRs >>> - between ingress and egress EdgeRTR >>> - between EdgeRTRs and H3EIDServices >> >> That doesn't cover "The H3ServiceEIDs themselves decrypt and parse >> actual H3-R15 annotations" though, right? Is there any encryption of >> the H3-R15 information all the way from EIDClient to H3EIDService? >> >>> Depending on the specific nexagon as service we would like to offer >>> the option to encrypt all communications on these dynamic encapsulations. >>> We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies >>> RFC2631 key exchange over LISP tunnels, also DTLS was suggested. >>> Should we determine one or just describe the geo privacy and >>> commercial exposure if encryption is not used, especially on the >>> tunnels between MobilityEIDClients and EdgeRTRs? >> >> You understand the specifics of where this protocol will be used much >> better than I do, so I think you're in a better place to choose >> between picking one option or explaining the issues and letting >> implementers decide on the encryption mechanism. In general, I'd lean >> towards picking one good cipher suite and sticking to that (without >> making it difficult to change things up in the future), but there can >> be good reasons not to do that. > > I think we are in sync. Encryption is on a tunnel by tunnel basis (or > dynamic encapsulation to be more accurate) to and from the LISP edge > tunnel router/s (EdgeRTRs), IPSec by default, leaving room for work like > lisp-crypto and lisp-wiregaurd being done, but not coupling the clients > and servers in that respect. There is still unclarity about the mismatch > between car-compute and edge-compute hw/sw updates and depreciation, and > car-compute and the car itself for that matter./ > >> >>> 2) Spoofing and imposters - >>> EdgeRTRs and H3EIDServices are provisioned in the service provider >>> edge network. EdgeRTRs which are added to the network are provisioned >>> with the mapping system, H3EIDServices are whitelist provisioned with >>> their designated EdgeRTRs. >>> We rely on the edge network routers to detect and stop spoofing using >>> industry standard double-lookup source/dest mechanisms. >>> Should we state so? >> >> I think so, yes. I generally think it's good to be explicit when >> relying on underlying infrastructure for security, so that if anybody >> later tries to adapt a protocol to some different infrastructure, they >> know what to pay attention to. > > Done. > >> >>> The MobilityEIDClients are behind mobile access networks and go >>> through AAA step before receiving ephemeral EIDs and EdgeRTR RLOCs >>> as anchors. >>> This EID is based on their client ID credentials, and this EID is >>> whitelist provisioned by the AAA to the EdgeRTR given to the client >>> as an anchor. >>> The ipv6 EIDs given to these clients reflect their credibility >>> reputation and authorization level to pub-sub into the nexagon network. >>> It is going to be very hard to guess a valid EIDClient which an >>> EdgeRTR expects after AAA to whitelist provision. These EIDs are >>> temporary and expire after 15 minutes. >>> Spoofed EIDClients which are sniffed are going to be detected by the >>> EdgeRTRs because of mismatched client RLOC. Spoofed client RLOCs are >>> detected by the mobile packet core. >> >> Oh, I didn't realize incoming packets on the EdgeRTR were dropped if >> the source EID doesn't match the RLOC associated with that EID. I >> thought that was a typical roaming case. If an attacker has to guess >> both a valid EID and its matching RLOC, I suspect that makes the >> attack much more difficult. (Though still far from impossible, >> depending on how many EID-RLOC pairs an EdgeRTR knows about at a time >> and how many guesses the attacker can get. IP allocation for the RLOC >> would play a huge factor too. If an ISP allocates RLOCs sequentially, >> it might be much easier to guess than if RLOCs are random /128s within >> guessable /64s. Though if an attacker can sniff RLOCs, the math >> changes again.) > > Right. LISP Mapped Overlay in this context is used to load-balance > clients as they network-login, and to “map-reduce” compute aggregation > to EID context. There is no change of EID-RLOC binding due to random > roaming. EID-RLOC pairs are whitelisted in EdgRTRs by AAA and dev-ops. > > >> >>> Should we detail these aspects in security considerations ? >> >> Yes please. > > Done. >> >>> 3) Fake news and client trust - >>> This is a higher level concern as it is with many other protocols. >>> Privacy and reputation require trade-offs. The lisp-nexagon network >>> uses crowd-sourced street sampling to reflect current geo-state. Even >>> the most honest client may still be wrong, have faulty vision gear, >>> gps interruption, or buggy AI. Malicious clients may try to >>> manipulate geo-state to their advantage, clear their path from >>> traffic, or simply try to saw confusion. >>> For this reason all detections are corroborated and trust level of >>> each client is constantly scored by the H3EIDServices and updates the >>> AAA system. This credit score update reflects the behavior of the >>> assigned ephemeral client EID not the client, a car for ecample. But >>> the AAA system knows which client ID credentials the EID map to. The >>> AAA system does not need to know the geo association of these EID >>> scores. They can be aggregated from all H3EIDServices before handed >>> to AAA. >>> We can describe this general behavior even though its part of >>> management and orchestration and not part of the LISP-Nexagon >>> interface specification. >> >> Sounds good, even if you mention it only at a high level. I think the >> fact that H3EIDServices are sharing reputation information back to the >> AAA service is important to mention. > > Done. > >> >>> After we clear these 3 key items to everyone satisfaction we can >>> quickly turn around the doc to one more iteration. >>> Thank you in advance! >>> --szb >>> Cell: +972.53.2470068 >>> WhatsApp: +1.650.492.0794 > > > This is the updated related security considerations text in > https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06 > > In summary of main risk mitigations for the lisp-nexagon interface we can say: > > (1) tapping: all communications are through dynamic tunnels therefore may be > encrypted using IP-Sec or other supported point to point underlay standards. > These are not static tunnels but lisp re-tunneling routers (RTRs) perform all > nexagon Overlay aggregation. > > (2) spoofing: it is very hard to guess a MobilityClientEID valid for a short > period of time. Clients and H3Services EIDs are whitelisted in EdgeRTRs, > Clients using the AAA procedure, H3Services via dev-ops. > > (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should > be caught by the underlying service provider edge and access networks. EID > impersonating is caught by EdgeRTR EID RLOC whitelist mismatch. > > (4) credibility: the interface crowd-sources geo-state and does not assume to > trust single detections. Credit history track to MobilityClientEIDs by as part > of normal H3Services fact checking, aggregate scores affect AAA credentials. > > (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and geo-location, > only AAA is aware of client IDs credentials and credit but not geo-location. > aggregate credit score span all H3Services administratively without source. > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >
- [lisp] Secdir early review of draft-ietf-lisp-nex… Tero Kivinen via Datatracker
- Re: [lisp] Secdir early review of draft-ietf-lisp… Sharon Barkai
- Re: [lisp] Secdir early review of draft-ietf-lisp… Sharon Barkai
- Re: [lisp] Secdir early review of draft-ietf-lisp… Dino Farinacci
- Re: [lisp] Secdir early review of draft-ietf-lisp… Tero Kivinen
- Re: [lisp] Secdir early review of draft-ietf-lisp… Sharon Barkai
- Re: [lisp] [secdir] Secdir early review of draft-… David Mandelberg
- Re: [lisp] [secdir] Secdir early review of draft-… Sharon Barkai
- Re: [lisp] [secdir] Secdir early review of draft-… David Mandelberg
- Re: [lisp] [secdir] Secdir early review of draft-… Sharon Barkai