Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 2 Jul 2018 14:57:32 +0200

Hi Keyer, WG,

Time permitting I would like to present on the Signed TAL document again. I have done so before, e.g. asking for input whether unplanned rolls should be supported. But.. I found I did not get a very clear response from the WG on this.

To make things more tangible I want to focus on:
1) limiting the scope to just planned key rolls (as the -01 document does)
2) lessons from 5011 (and I will be doing some more homework on that between now and 16 July..)

Kind regards

Tim Bruijnzeels

> On 27 Jun 2018, at 18:41, Keyur Patel <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi folks,
>  
> SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm. Please forward any SIDROPS agenda items you may have to Chris and me. Please also make sure that your slides are available to the chairs by Friday morning (07/13/2018). Slides received after the deadline may not be available for use during the meeting.
>  
> Regards,
> Chris and Keyur
>  
> _______________________________________________
> Sidrops mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Keyur Patel <[email-masked]>
Date: Mon, 2 Jul 2018 15:22:59 +0000

Done. Thanks.

Regards,
Keyur

From: Tim Bruijnzeels <[email-masked]>
Date: Monday, July 2, 2018 at 5:47 AM
To: Keyur Patel <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items

Hi Keyer, WG,

Kind regards

Tim Bruijnzeels

On 27 Jun 2018, at 18:41, Keyur Patel <[email-masked]<mailto:[email-masked]>> wrote:

Hi folks,

Regards,
Chris and Keyur

_______________________________________________
Sidrops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidrops

---

From: George Michaelson <[email-masked]>
Date: Tue, 3 Jul 2018 09:45:54 +1000

we aren't presenting a draft at this time, I just have slides. Its a
conversation.

-George

On Tue, Jul 3, 2018 at 1:22 AM, Keyur Patel <[email-masked]> wrote:
> Time permitting I would like to present on the Signed TAL document again. I
> have done so before, e.g. asking for input whether unplanned rolls should be
> supported. But.. I found I did not get a very clear response from the WG on
> this.
>
>
>
> On 27 Jun 2018, at 18:41, Keyur Patel <[email-masked]> wrote:
>
>
>
> Hi folks,
>
>
>
> SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm.
> Please forward any SIDROPS agenda items you may have to Chris and me. Please
> also make sure that your slides are available to the chairs by Friday
> morning (07/13/2018). Slides received after the deadline may not be
> available for use during the meeting.
>
>
>
> Regards,
>
> Chris and Keyur
>
>
>
> [email-masked]
> [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 4 Jul 2018 09:01:54 +1000

On Tue, Jul 3, 2018 at 5:55 PM, Tim Bruijnzeels <[email-masked]> wrote:
> Hi George,
>
> Just to be clear. You are referring here to validation deployment planning, right.

yes. I have asked for 5-10 minutes to talk about validation deployment
planning, there is no published draft to be presented at this meeting
on that topic, its just a conversation right now.

-George

>
> Tim
>
>> On 3 Jul 2018, at 01:45, George Michaelson <[email-masked]> wrote:
>>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 5 Jul 2018 12:01:48 +0200

Hi Alexander,

Nice drafts! I have some questions that may come back when you present, but let me ask here as well.

In-line

> On 28 Jun 2018, at 15:57, Alexander Azimov <[email-masked]> wrote:
> 
> I would like to reserve 15 minutes for:
> https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/ <https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/>

Since it’s the customer ASN who signs would it be a good idea if they listed all provider ASNs in a single object? There is no fate sharing risk like we have in ROAs when including multiple signing prefixes. On the other hand this would guarantee atomicity.

One small thing, eventually this will need a filename extension to be included in the IANA “RPKI Repository Name Scheme” registry. See also:
https://tools.ietf.org/html/rfc6481#section-7.2 <https://tools.ietf.org/html/rfc6481#section-7.2>

> https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ <https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/>

I am not entirely clear on the AS_PATH verification in section 5. It reads to me like the outcome is invalid, or unverifiable if not all of the ASNs on the path have published ASPAs. And that unverifiable is considered close to invalid. But I may have misunderstood.. so I would be particularly interested in this part of your presentation.

All that said, I think that it would be extremely useful if a partial, incremental deployment can be supported. IMHO one of the big issues with BGPSec deployment is that it’s all or nothing, so there really is no incentive to deploy until everybody else has done so. With ASPAs you could argue that a route should be dropped if any of the pairs in the path turns out to be invalid, but it’s okay to accept unknowns. This would allow ASNs to get benefits from publishing ASPAs without requiring that everyone else does so as well. Of course things will be better when they do as well, but until that time there still is a benefit. So, there is incentive for ASNs to be pro-active.

But as I said.. I am not sure that I got this section 5 completely..

Regards,

Tim

> 
> 2018-06-28 1:33 GMT+03:00 Keyur Patel <[email-masked] <mailto:[email-masked]>>:
> Done. Thanks.
> 
> Regards,
> Keyur
> 
> > On Jun 27, 2018, at 3:32 PM, George Michaelson <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > I have been asked by my RIR colleagues to talk about modified
> > validation deployment planning. I think about 10 minutes should do it.
> > 
> > cheers
> > 
> > -george
> > 
> >> On Thu, Jun 28, 2018 at 6:34 AM, Keyur Patel <[email-masked] <mailto:[email-masked]>> wrote:
> >> Done. Thanks.
> >> 
> >> Regards,
> >> Keyur
> >> 
> >> On 6/27/18, 1:32 PM, "Randy Bush" <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >>> SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30
> >>> pm. Please forward any SIDROPS agenda items you may have to Chris and
> >>> me. Please also make sure that your slides are available to the chairs
> >>> by Friday morning (07/13/2018). Slides received after the deadline may
> >>> not be available for use during the meeting.
> >> 
> >>    i would appreciate 10-15 minutes to discuss
> >> 
> >>        draft-ymbk-sidrops-ov-signal-01
> >> 
> >>    i do NOT plan to present it.  folk who want to discuss it and/or have
> >>    questions MUST have read it beforehand.
> >> 
> >>    randy
> >> 
> >> 
> -- 
> | Alexander Azimov  | HLL l QRATOR
> | tel.: +7 499 241 81 92
> | mob.: +7 915 360 08 86
> | skype: mitradir
> | mailto: [email-masked] <mailto:[email-masked]>
> | visit: www.qrator.net <http://www.qrator.net/>_______________________________________________
> Sidrops mailing list
> [email-masked]

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 6 Jul 2018 23:07:01 +0300

Hi Tim,

Thank you for the feedback! Please see my inline comments

2018-07-05 13:01 GMT+03:00 Tim Bruijnzeels <[email-masked]>:

> Since it’s the customer ASN who signs would it be a good idea if they
> listed all provider ASNs in a single object? There is no fate sharing risk
> like we have in ROAs when including multiple signing prefixes. On the other
> hand this would guarantee atomicity.
>
Interesting point. We will consider changing it this way.

> One small thing, eventually this will need a filename extension to be
> included in the IANA “RPKI Repository Name Scheme” registry. See also:
> https://tools.ietf.org/html/rfc6481#section-7.2
>
> https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/
>
>
> I am not entirely clear on the AS_PATH verification in section 5. It reads
> to me like the outcome is invalid, or unverifiable if not all of the ASNs
> on the path have published ASPAs. And that unverifiable is considered close
> to invalid. But I may have misunderstood.. so I would be particularly
> interested in this part of your presentation.
>
> All that said, I think that it would be extremely useful if a partial,
> incremental deployment can be supported. IMHO one of the big issues with
> BGPSec deployment is that it’s all or nothing, so there really is no
> incentive to deploy until everybody else has done so. With ASPAs you could
> argue that a route should be dropped if any of the pairs in the path turns
> out to be invalid, but it’s okay to accept unknowns. This would allow ASNs
> to get benefits from publishing ASPAs without requiring that everyone else
> does so as well. Of course things will be better when they do as well, but
> until that time there still is a benefit. So, there is incentive for ASNs
> to be pro-active.
>
Yes, it seems that here is a misunderstanding. Behind section 5 there is a
simple idea:

   1. If there is 'invalid' subpath - then the outcome is 'invalid';
   2. If the AS_PATH can't be fully verified even if all corresponding
   ASPAs exist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable';
   3. Otherwise - 'valid'.

So, the procedure may return 'valid' also in case if part of AS_PATH isn't
fully covered by ASPAs.
And to support detection of intentionally malformed AS_PATH for selected
ASN it's enough if all its upper providers create ASPAs. For transit-free
networks this rule is even more simplified - they just need to create
ASPA0. IMHO - it provides a quite powerful mechanism even at the state of
partial deployment.

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 10 Jul 2018 12:55:56 +0200

Alexander,

Alexander Azimov wrote on 06/07/2018 22:07:
> Yes, it seems that here is a misunderstanding. Behind section 5 there is
> a simple idea:
> 

In case the speaker understands 32-bit ASNs a path may be reconstructed
using the AS4_PATH attribute. Do you refer to AS_PATH in a sense of
constructed AS path (where AS_TRANS may be replaced), rather then the
AS_PATH received from a neighbor who doesn't support 32-bit ASNs?

>  3. Otherwise - 'valid'.>
> So, the procedure may return 'valid' also in case if part of AS_PATH
> isn't fully covered by ASPAs. 

It doesn't make much sense to me to declare the path valid even if some
of the segments cannot be verified. As opposed to BGPsec it is not all
or nothing in this case, as I understand it. Valid ASPAs linking
segments on both ends of the path provide value since an attacker cannot
craft a shorter path, and will probably lose because of that. So in this
sense every ASPA is an incremental improvement.

> ASN it's enough if all its upper providers create ASPAs. For
> transit-free networks this rule is even more simplified - they just need
> to create ASPA0. IMHO - it provides a quite powerful mechanism even at
> the state of partial deployment.

I like the simplicity of the approach, are different types of
relationships between the two AS'es outside the scope?

Thanks,

Andrei

---

From: Alexander Azimov <[email-masked]>
Date: Wed, 11 Jul 2018 17:36:05 +0300

Andrei,

Thank you for the comments.

> AS_PATH received from a neighbor who doesn't support 32-bit ASNs?
I had in mind two scenarios:

   - Provide a limited opportunity to 'old' BGP software to verify routes
   using ASPA;
   - Provide solution for a case when AS_PATH wasn't properly reconstructed
   and there are AS_TRANS left.

> sense every ASPA is an incremental improvement.
Yes, each ISP by signing ASPA will improve the level of its own security
and security of its customers - that's a really important motivation. If
there is a complete sequence of signed ASPAs from edge to Tier1 - then the
attacker will have no opportunity to create a valid AS_PATH in terms of the
verification procedure.

We can consider adding additional state 'unknown' or 'partial valid'. It
will have similar semantics to 'unknown' output of ROA validation
procedure. But as you know, the current practices are focussing on dropping
'invalid' routes, there is no difference in processing 'unknown' and
'valid' routes.

> relationships between the two AS'es outside the scope?
For me it seems that we don't need any additional information to verify
routes received from customers and peers.
So, I've tried to make it as simple as possible.

| mailto: [email-masked]
| visit: www.qrator.net

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 12 Jul 2018 09:16:29 +0200

Alexander Azimov wrote on 11/07/2018 16:36:
[...]
> procedure. But as you know, the current practices are focussing on
> dropping 'invalid' routes, there is no difference in processing
> 'unknown' and 'valid' routes. 

Yes, and calling the "unknown" "valid" does not solve that problem :).

You have already defined "unverifiable", which has the same meaning as
"unknown". I just do not see much difference between gaps in the ASPA
chain and the presence of AS_TRANS.

Thanks,

Andrei

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 12 Jul 2018 10:32:28 +0200

Hi,

> On 12 Jul 2018, at 09:16, Andrei Robachevsky <[email-masked]> wrote:
> 

It’s this paragraph in section 5 that threw me off a bit:

   If the output of the AS_PATH verification procedure is 'unverifiable'
   it means that AS_PATH can't be fully verified.  Such routes should be
   treated with caution and MAY be processed the same way as "invalid"
   routes.

'MAY be processed the same way as  “invalid” routes’ indicates a local choice, which is fine I believe. But, under partial deployment this can lead to routes being dropped a little too aggressively, no? Reading your comments in the email thread the advice during partial deployment would be to accept, rather than drop, right?

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 13 Jul 2018 10:59:57 +0200

> 'MAY be processed the same way as  “invalid” routes’ indicates a local choice, which is fine I believe. But, under partial deployment this can lead to routes being dropped a little too aggressively…

Yes, that is correct. A partly validated path is slightly better that
non-validated and is much better than a path contradicting with ASPAs.

Andrei

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 15 Jul 2018 17:49:03 -0400

Last call for meeting slides... Send please, or I make ascii art .... Not
of cats.

On Wed, Jun 27, 2018, 12:41 Keyur Patel <[email-masked]> wrote:

> Please forward any SIDROPS agenda items you may have to Chris and me.
> Please also make sure that your slides are available to the chairs by
> Friday morning (07/13/2018). Slides received after the deadline may not be