Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification

Alexander Azimov <a.e.azimov@gmail.com> Tue, 05 March 2019 17:38 UTC

Return-Path: <a.e.azimov@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF8D1312D0; Tue, 5 Mar 2019 09:38:13 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7B1p1VwWHXhf; Tue, 5 Mar 2019 09:38:10 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 6C8EE131055; Tue, 5 Mar 2019 09:38:07 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id b3so8147576otp.4; Tue, 05 Mar 2019 09:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CQLoyE2L5G3276wWi/JZH/4GE2rsMiH6D/cIZxa0+xo=; b=PkkX9sg0aZ9OqA8AFKlOLCursumpCmT3ec3tqwF1JkHfqvd/1oMltNZxTrOc7u8v7f 5duAN11khP1awdOml+mM5+3kpvMsauMjem1O1NvbO1ocZzx+qqCde7H795+gsn0meJU6 xVLKnEVMGqlTF+v7NUKiqxJvWiLnbb9SuPbMGZfafiU1HI282f2b5Q7oG2CUctD/UhCi Y1vVqKRRaIXALR8/q7yVyhfnYeMnALxiHgwJdxyek1ajwMzJ1fmHhNPSMp70+l1M8Ags +Co8CkvRmRHCcbbMlLlOzXAjDXw2Msx8yN4ve7eN34lf9BP1e38YPm8CyPaf/2cPntoy ICYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CQLoyE2L5G3276wWi/JZH/4GE2rsMiH6D/cIZxa0+xo=; b=koQE5eLCdSHzzeGYwC1UNSyN/jHI1iMbC9I9PQkj7iz7+DLWdLu4I4mRaL/pX18vTP 2Om1tCT/50Vk4NRtwDdwLjNptbWAewGMhL3OsihQI4XOsJsYdXehU3llSgr2AYSSw5x/ 6VVN6tI/EahzqGnHEhHaF6W6sNpfhsLyxPPoi5ooNDDok81VZN6DgfqzrFIlUFxQ+mPV kRYrKE0GXsNVXUudY6F5v0z0xI5KL8lfTxo48lW3p3CODWmFbmIde4VRUqhbzzGqT2Lv 07ZCvganjoyZ3L3wUs/4GgfDs3gc1eqH6o0QWqZNGn84BfWi3xjI2VnpMb1fgKfOicBG QYzw==
X-Gm-Message-State: APjAAAX7RAaLzJoXbb+HyV6K6iHwaT7XWRdZLJINHxZ3cNLpc61x6B82 G8W00kaYwokXVr1ZoIm508W/7DC0d4BBPSOxW+k=
X-Google-Smtp-Source: APXvYqyMZXlElZ4KFQhDn8K0vkezynQspk0qZXE2bW7kK+Cl4Dss2m6nAzhp7/ixQqYZ3FLIs0jANvsqfJ6x4HpeNCo=
X-Received: by 2002:a9d:3f24:: with SMTP id m33mr1557398otc.147.1551807486421; Tue, 05 Mar 2019 09:38:06 -0800 (PST)
MIME-Version: 1.0
References: <SN6PR0901MB236620AD0F6209170C9BD9A384750@SN6PR0901MB2366.namprd09.prod.outlook.com> <CAEGSd=AF=1Tf0-fL5Cy6uRx71nA0sCuSYbtKCUKQEoNvw=8B3w@mail.gmail.com> <CAEGSd=CEUKDbuabEaqPznBvVa1kJ+9GgBD8y_YumoUDK=cdAQA@mail.gmail.com> <SN6PR0901MB2366F6BAAB2E8E1B3DDD5E2084700@SN6PR0901MB2366.namprd09.prod.outlook.com>
In-Reply-To: <SN6PR0901MB2366F6BAAB2E8E1B3DDD5E2084700@SN6PR0901MB2366.namprd09.prod.outlook.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 5 Mar 2019 20:37:54 +0300
Message-ID: <CAEGSd=AGN_mJCF6tkxd+G3zRCqAPNJg7Tj2jGqbRaJ4GviGeuA@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fcf48605835c5518"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/KM-jMibfkIl4WlHKSVi67ZZF9WM>
Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 17:38:19 -0000

Dear Sriram,

Please see my inline comments.

вс, 3 мар. 2019 г. в 04:36, Sriram, Kotikalapudi (Fed) <
kotikalapudi.sriram@nist.gov>gt;:

> Hi Alex,
>
> So, yes there are things we need to careful about in the design.
> Also, got to be careful about claiming, “this mechanism
> guarantees detection of both malicious and accidental route leaks”.
>
> There is a new Comment #0 that I have added here.
> And I have other comments inline below.
>
> Comment#0:
> One more thing occurred to me. This is very basic.
> Consider these frequently occurring examples of route leaks:
>
> AS1 (Tier 1)----P2C---->AS2 (customer)----C2P-----> AS3
> AS1 (Tier 1)----p2p---->AS2 (Tier 1)----p2p-----> AS3 (Tier 1)
>
> AS2 leaks the route learned from AS1 in both cases above.
> AS1 being a Tier 1, never has to create an ASPA (has no providers).
> Regardless of whether AS2 created an ASPA or not,
> AS3 is not able to detect the leaks in both cases above
> (per algorithm in the draft).
> This same issue arises even in the example of Comment #2
> if AS3 in that example were a Tier 1.
>
You seem to be misreading in section 6. Quote:

   An ASPA with a provider AS of 0 is a statement by the customer AS
   that the its routes should not be received by any relying party AS
   from any of its customers or peers.

So, Tier1/IXes should create only ASPA0 - and it will be enough to detect
anomalies with its prefixes by any other ISP in the world.

>Can you please clarify to me next scenario with three ISPs:
> > - Victim advertises /23 to Upstream, does use BGPSec,
> >    has ROA record with maxlength 24
> > - Upstream, does use BGPSec
> > - Attacker, advertises /24 that belongs to Victim, adds its ASN at
> >    the beginning of ASPath, doesn't use BGPSec
> >Will Upstream, according to RFC8205, accept the hijacked route from
> Attacker?
> >Anyway, I'm open for discussion about proper wording here.
>
> The idea of a BGPsec cloud (some call it island) needs to be understood.
> I hope you had chance to read RFC 8205 Section 7.9 –
> the idea of contiguous BGPsec ASes.
> A group of contiguous BGPsec ASes decides that they
> require signed updates (i.e., BGPsec) from Day X *within their cloud*.
> What that means is that they have knowledge that they are
> contiguous (all connected to each other by some # of hops),
> and they all do BGPsec. And they decide that BGPsec must be done
> end-to-end within their BGPsec cloud.
> Then from Day X, they require signed/valid paths for prefixes
> that *originate within their BGPsec cloud*.
> (Prefixes originated from outside the cloud may be unsigned
> and may possibly be subject to signature stripping.)
> Then in your example, the attack is not possible within the cloud
> (i.e., if attacker strips the signatures for any prefix that originated
> in that BGPsec cloud, his unsigned update is Invalid and not accepted;
> it would be the same as the attacker himself suppressing the update.)
>
I've read 7.9 section multiple times, and there wasn't able to find
anything related to 'clouds' or conditional acceptance of unsigned routes
if there are signed less specifics.
May be you would like to write another document that will clearly describe
this procedure?

  >>Comment #2: Improvement of the algorithm for detection
> ---- snip -----
>
> > This suggestion sounds great but it has an issue. Imagine that AS3 and
> AS4
> > have what is commonly named 'complex' relation. So they are both
> > customer-provider to one another. And in your scenario, where only AS4
> > creates ASPA it may result in rejection of valid routes, which will make
> > AS4 quite unhappy...
>
> Yes, agree. ASPA has a shortcoming nevertheless.
>
You have suggested an improvement and I explained why it is not applicable.
I've never heard that careful design is a shortcoming.


> >> Comment #4: Not all malicious leaks / hijacks are detected
> >>
> >> In the topology below, AS2 leaks the path it learned from its peer AS4
> to
> >> its provider AS3 with path modification to avoid route leak detection,
> >> or one may think of it as a hijack with feasible path insertion.
> >> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is
> >> illegitimate but defies detection despite all ASes participating in
> ASPA.
> >>
> >>          AS3
>   AS5
> >>               \  p1 AS2 AS1                                     /
> >>                 \ p2 AS2 AS1                                 /
> >>                    \                                                 /
> >>                      \         <----p2 AS4 AS1--    /
> >>                        AS2 -------p2p----------AS4
> >>                           \                              /
> >>                              \ p1 AS1           /p2 AS1
> >>                                  \                 /
> >>                                       AS1
> >>                                    (p1, p2)
> >>
>
> > Thinking about it as hijack adds simplicity to the picture. Customers may
> > still be hijacked by its direct or indirect providers. While it
> > significantly limits the attacker vector and highly unlikely to happen in
> > the real world, it must be clearly stated in the draft. Pushed to stack.
>
> It is both. Hard to rule out malicious leak with path modification.
> When considering malicious scenarios, the above would not be unlikely.
> I think this is typically what the determined attacker (AS2) might do to
> maliciously increase their revenue.

Do you think that malicious attack from the provider, that has contracted
agreement with its customer (and already propagates customer's prefixes) is
likely to happen?
>From what I know from real hijack issues - it's not.


> >> Comment #5: Path verification vs. path feasibility
> >>
> >> Based on the above examples, in the draft, perhaps it is better to say
> >>
> >> that the path is assessed feasible rather than say that the path is
> >> verified.
> >>
>
> > I'm not a native speaker but for me 'feasibility' sounds a bit odd. I
> > would be glad to learn other opinions from the wg members. Anyway, this
> > question should not become a showstopper.
>
> BGPsec provides hard assurance that path seen in the update is correct.
> ASPA can provide confirmation that the path is possible/feasible.
> It cannot assure that path seen in the update is the actual path
> that the update traversed. This is clear from the above example (Comm. #4).
>

> We can meet in Prague. I'll be happy to discuss
> and we can try to help resolve these (to the extent possible).
>
Arguing about BGPSec isn't my goal at this point in time, nor it is the
purpose of the draft.
I can't say you convinced me about naming, but as you know, I'm always open
to constructive discussions.

-- 
Best regards,
Alexander Azimov