Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04

David Mandelberg <> Wed, 21 October 2020 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DA503A0A06 for <>; Tue, 20 Oct 2020 19:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.346
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fzR7weSQPwDn for <>; Tue, 20 Oct 2020 19:12:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::564]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E92683A0A22 for <>; Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
Received: by with SMTP id r10so497796pgb.10 for <>; Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( []) by with ESMTPS id m7sm94823pjk.13.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 19:12:11 -0700 (PDT)
Received: from [] (nevia []) by (Postfix) with ESMTPSA id 6F0911C6066; Tue, 20 Oct 2020 22:12:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
Cc:, " list" <>,
References: <> <> <> <>
From: David Mandelberg <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
>> < 
>> <>> 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 
> 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
> wiki: