MIME-Version: 1.0
References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com>
 <CAEGSd=AAQqL6kbZKOEjRABd00n27VKSnMRW6W3Xyb=6y6q-ziA@mail.gmail.com>
 <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com>
In-Reply-To: <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Fri, 5 Jul 2019 00:55:20 +0300
Message-ID: <CAEGSd=DOC012T94zvPbMAv0pXQb6WUmv7uvRt2fxAK-9KbdSuA@mail.gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: sidrops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008a4a16058ce209ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nmilPjJGYTThka1KxwxMW0v85mA>
Subject: Re: [Sidrops] On validating AS paths
Precedence: list

--0000000000008a4a16058ce209ff
Content-Type: text/plain; charset="UTF-8"

Hi, bellow my additional comments.
Just in case - I removed from quote those parts where we are on the same
side.

a1 ^ a2 / a3 \ a4
>
> ^/\ is not a valid path. So a3 has to register its C2P relationship with
> a2.
>
You can't enforce it. Sibling occurs not only between parties under single
administrative control.
And you don't want to have such kind of dependency for your security
configuration.


> Maybe it can be fixed by adding a sibling flag to the c2p record, but at
> the moment I'm not sure about security consequences.
>
>
> In the draft you mention that it's important that the customer can claim
> the relationship and not the provider. So I would be hesitant to have a S2S
> relationship record is that would either be too easy to claim (if one
> sibling can do it) or complex to implement (only valid when both siblings
> claim the relationship).
>
IMO the moment we require two (or more) independent parties synchronize
their configuration without automation - we lose.
My idea was to add one-side s2s (or c2c) to make it work. But I'm still not
sure about this.


> And to follow up my previous email, if we have a network with malicious
> intent that would hijack/disaggregate prefixes + create a 'virtual peering
> link' between it and victim ASN, its customers will not able to detect it
> anyway since it will look like a valid path: '-\'.
>
>
> You mean a virtual sibling link? No, we certainly don't want that to be
> possible.
>
No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes
with a malformed path to my customer.
To bypass filters based on your proposal I just need to have a 'virtual'
link with the originator.

If the original path was 'a1 a2 a3 attacker customer', the path 'a1
attacker customer' will be also valid. (the path is again reversed, just to
keep it same to the previous email).

So, if we are not speaking about BGPSec-like signatures, your approach will
not protect from ASPATH violation.
The thing it might bring is the detection of mistake route leaks that are
received from providers. So, it can bring benefit at the state of early
adoption.

I will try to integrate into ASPA logic. I have a feeling that it can be
done without registering siblings.

-- 
Best regards,
Alexander Azimov

--0000000000008a4a16058ce209ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi, bellow my additional comments.<br>Just in case - =
I removed from quote those parts where we are on the same side.</div><div><=
br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div><div><div>a1 ^ a2 / a3 \ a4</div><div><br></div><div>^/\ is=
 not a valid path. So a3 has to register its C2P relationship with a2.</div=
></div></div></blockquote>You can&#39;t enforce it. Sibling occurs not only=
 between parties under single administrative control.<br>And you don&#39;t =
want to have such kind of dependency for your security configuration.<br><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><=
div><blockquote type=3D"cite"><div dir=3D"ltr">Maybe it can be fixed by add=
ing a sibling flag to the c2p record, but at the moment I&#39;m not sure ab=
out security consequences.<br></div></blockquote><div><br></div><div>In the=
 draft you mention that it&#39;s important that the customer can claim the =
relationship and not the provider. So I would be hesitant to have a S2S rel=
ationship record is that would either be too easy to claim (if one sibling =
can do it) or complex to implement (only valid when both siblings claim the=
 relationship).</div></div></div></blockquote><div>IMO the moment we requir=
e two (or more) independent parties synchronize their configuration without=
 automation - we lose.=C2=A0</div><div>My idea was to add one-side s2s (or =
c2c) to make it work. But I&#39;m still not sure about this.</div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><b=
lockquote type=3D"cite"><div dir=3D"ltr"><div>And to follow up my previous =
email, if we have a network with malicious intent that would hijack/disaggr=
egate prefixes + create a &#39;virtual peering link&#39; between it and vic=
tim ASN, its customers will not able to detect it anyway since it will look=
 like a valid path: &#39;-\&#39;.</div></div></blockquote></div><div><div d=
ir=3D"ltr"><div><br></div><div>You mean a virtual sibling link? No, we cert=
ainly don&#39;t want that to be possible.</div></div></div></div></blockquo=
te><div>No. Imagine I&#39;m an attacker (or BGP optimizer) and I want to se=
nd prefixes with a malformed path to my customer.</div><div>To bypass filte=
rs based on your proposal I just need to have a &#39;virtual&#39; link with=
 the originator.</div><div><br></div><div>If the original path was &#39;a1 =
a2 a3 attacker customer&#39;, the path &#39;a1 attacker customer&#39; will =
be also valid. (the path is again reversed, just to keep it same to the pre=
vious email).</div><div><br></div><div>So, if we are not speaking about BGP=
Sec-like signatures, your approach will not protect from ASPATH violation. =
<br>The thing it might bring is the detection of mistake route leaks that a=
re received from providers. So, it can bring benefit at the state of early =
adoption.<br><br>I will try to integrate into ASPA logic. I have a feeling =
that it can be done without registering siblings.<br></div><div><br></div><=
div>--=C2=A0<br></div></div><div dir=3D"ltr" class=3D"m_4179103037987182529=
m_3072214518391217410gmail_signature"><div dir=3D"ltr">Best regards,<div>Al=
exander Azimov</div></div></div></div>

--0000000000008a4a16058ce209ff--