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

From: Alexander Azimov <[email-masked]>
Date: Fri, 1 Mar 2019 13:24:52 +0300

In #1 I meant to say 'victim':

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.

чт, 28 февр. 2019 г. в 20:53, Alexander Azimov <[email-masked]>:

> Sriram,
>
> I'm glad to see your comments! Please see my answers below.
>
> Comment #1:
>>
>> I would strongly suggest deletion of the last two sentences of
>>
>> the second paragraph in the Intro section.
>>
>> You talk about downgrade attacks with BGPsec there.
>>
>> The two sentences in question are inconsistent with how
>>
>> incremental deployment of BGPsec really works.
>>
>> Please read RFC 8205 Section 7.9 -- the idea of contiguous BGPsec ASes.
>>
>> Regarding your attacker downgrading BGPsec comments,
>>
>> John Scudder also suggested to you in IETF 102,
>>
>> “It is not necessary to make that extreme claim for your proposal,
>>
>> if I were you, I wouldn’t.”  See video at ~48 minute mark:
>>
>> https://www.youtube.com/watch?v=LnXLB_MlpAs
>>
> 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 Upstream, adds its ASN in
>    the beginning of ASPath, doesn't use BGPSec
>
> Will Upsream, according to RFC8205, accept hijacked route from Attacker?
> Anyway, I'm open for discussion about proper wording here.
>
>
>> Comment #2: Improvement of the algorithm for detection
>>
>> Consider this topology example:
>>
>>
>>
>>          AS3              AS5
>>
>>          /       \        /
>>
>>     AS2         AS4
>>
>>    /
>>
>> AS1
>>
>>
>>
>> The peering relations are C2P going up and P2C going down (in the pic).
>>
>> AS1, AS2 and AS4 have created ASPAs. AS3 has not created ASPA.
>>
>> Let us say AS4 accidentally leaks to AS5 the route received from AS3.
>>
>> The route’s AS_PATH is AS4 AS3 AS2 AS1.
>>
>> I think your algorithm (section 5) would fail to detect the leak.
>>
>> But I would suggest a modified algorithm which is as follows:
>>
>> At AS5, when it sees that AS3 does not have ASPA, it then considers
>>
>> the ASPA of the next more recent AS in the path which is AS4 here.
>>
>> From AS4’s ASPA, AS5 determines that AS3 is a provider of AS4,
>>
>> and hence successfully detects that the update is a route leak.
>>
>> So, I think the algorithm in section 5 needs to be modified per
>> suggestion above.
>>
> 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...
>
>
>> Comment #3:
>>
>> In the figure below, AS1 originates p1 and AS2 originates p2.
>>
>> AS1 is a provider of AS2 for p1 and AS1 is a customer of AS2 for p2.
>>
>> AS1 announces p1 to AS2 as P2C. AS2 announces p2 to AS1 as P2C.
>>
>> AS3 is provider of AS2.
>>
>>
>>
>>                    ---------P2C------->
>>
>>                            p1 AS1
>> --->                                      -----p1 AS2 AS1--->
>>
>> AS1------------------(hybrid/complex)----------AS2---------- C2P
>> ----------->AS3
>>
>>                          <--- p2 AS2
>>
>>                    <---------P2C-------
>>
>> AS1 creates an ASPA: {AS1, AS2, IPv4}
>>
>> AS2 creates an ASPA: {AS2, AS1, IPv4}
>>
>>
>>
>> Now consider AS2 leaks route for p1 to AS3. Then AS3 is unable to detect
>> the leak.
>>
>> AS3 looks at the ASPA: {AS1, AS2, IPv4} and determines that AS1 is a
>> customer of AS2,
>>
>> and hence determines incorrectly that the Update: p1 AS2 AS1 is not a
>> leak.
>>
>> The ASPA scheme fails to work in this case for leak detection.
>>
>> This is a limitation of the ASPA scheme because ASPAs are per AFI and not
>> per prefix.
>>
> Fully agreed. Simplicity comes with its own cost.
> And that's why we still need community-based leak detection that can work
> per-prefix. And it's our duty as-coauthors (and my debt, which I need to
> admit) to finally push it forward.
> I'm going to add an explicit statement in the next version of the draft.
>
>
>> 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.
>
>>
>> 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.
>
> Comment #6:
>>
>> In paragraph #1 in the Intro section, [I-D.ymbk-idr-bgp-eotr-policy] is
>> referenced.
>>
>> Based on WG consensus, we merged [I-D.ymbk-idr-bgp-eotr-policy] and
>>
>> [I-D.idr-route-leak-detection-mitigation] and the latter is the WG
>> document
>>
>> that we are working on together since April 2018.
>>
>> So, [I-D.idr-route-leak-detection-mitigation] is the more appropriate
>>
>> document to cite for the ongoing WG effort.
>>
> I don't think there was a need in such a detailed history of the question.
> :)
> Valid point. I'll change the link with the next update.
>
>
> --
> Best regards,
> Alexander Azimov
>

-- 
Best regards,
Alexander Azimov

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 3 Mar 2019 01:36:08 +0000

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.

>>Comment #1
--- snip ---

> - Victim advertises /23 to Upstream, does use BGPSec, 
>    has ROA record with maxlength 24
> - Attacker, advertises /24 that belongs to Victim, adds its ASN at 
>Will Upstream, according to RFC8205, accept the hijacked route from Attacker?

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.)

The wording I can suggest is: 
BGPsec [RFC 8205] is computationally expensive and it is uncertain 
when its adoption/deployment may happen.

Just FYI…
BGPsec is computationally expensive but there are optimization
efforts that may be helpful (if BGPsec adoption ever gets going):

http://www.freepatentsonline.com/y2019/0036943.html    
(Juniper’s BGPsec optimization patent)

https://www.nanog.org/meetings/abstract?id=3043 
   
https://www.sciencedirect.com/science/article/pii/S0140366417303365   

---- snip -----

> creates ASPA it may result in rejection of valid routes, which will make

Yes, agree. ASPA has a shortcoming nevertheless.

--- snip ---

> I'm going to add an explicit statement in the next version of the draft.

Yes, the per-prefix solution (existing WG draft) is a necessary component.

>> illegitimate but defies detection despite all ASes participating in ASPA.
>>
>>          AS3                                                              AS5
>>               \  p1 AS2 AS1                                     /
>>                 \ p2 AS2 AS1                                 /
>>                    \                                                 /
>>                      \         <----p2 AS4 AS1--    /

> 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.  

> 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). 

Thanks.

Sriram

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 5 Mar 2019 20:37:54 +0300

Dear Sriram,

Please see my inline comments.

> 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.

> 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?

> 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.

> 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.

> 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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 6 Mar 2019 00:27:49 +0000

Honorable Chairs: You may count me in as ‘support’.

Hi Alex,

Thanks for clarifying ASPA0 use for Tier1. I overlooked before. I am good now.

For the BGPsec downgrade vulnerability (or lack thereof),
let discuss that in Prague with white board/paper.
If I were you, I would remove negative statements concerning this in the draft.
I am sure I can clarify and help with this.

We can further discuss/clarify some of the other points also when we meet.

Thanks.

Sriram

From: Alexander Azimov <[email-masked]>
Sent: Tuesday, March 5, 2019 12:38 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification

Dear Sriram,

вс, 3 мар. 2019 г. в 04:36, Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>:
Hi Alex,

Comment#0:

   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.

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?

---- snip -----

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.

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?

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