Subject: Re: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

From: Job Snijders <[email-masked]>
Date: Mon, 16 Apr 2018 15:47:06 +0000

Dear SIDROPS chairs,

Can you share with us the outcome of this adoption call?

Kind regards,

Job

On Mon, Mar 05, 2018 at 05:09:16PM -0500, Christopher Morrow wrote:
> ah sweet... can we end this adoption call:
>   26 Mar 2018
> 
> thanks!
> 
> On Mon, Mar 5, 2018 at 5:05 PM, Roque Gagliano (rogaglia) <
> [email-masked]> wrote:
> 
> > Hi Job,
> >
> > I agree on adoption.
> >
> > Roque
> >
> > —
> > Roque Gagliano
> >
> > Automation Software Architect EMEAR
> >
> > +41 76 449 8867
> >
> > Join the NSO Digital Ecosystem:
> > NSO on DevNet: www.cisco.com/go/nsodevnet <http://www.cisco.com/go/
> > nsodevnet>
> > NSO Developer Hub: www.cisco.com/go/nsohub <http://www.cisco.com/go/nsohub
> > >
> >
> >
> > On 05/03/18 19:15, "Sidrops on behalf of Job Snijders" <
> > [email-masked] on behalf of [email-masked]> wrote:
> >
> >     Dear working group,
> >
> >     This document has gone through a number of revisions outside the
> > working group.
> >
> >     As authors we think it may be time to consider a call for adoption and
> >     continue work on this document in context of the working group.
> >
> >     Thoughts?
> >
> >     Kind regards,
> >
> >     Job
> >
> >
> >     ---------- Forwarded message ----------
> >     From:  <[email-masked]>
> >     Date: Mon, Mar 5, 2018 at 7:09 PM
> >     Subject: New Version Notification for draft-yossigi-rpkimaxlen-02.txt
> >     To: Job Snijders <[email-masked]>, Kotikalapudi Sriram
> >     <[email-masked]>, Ben Maddison <[email-masked]>,
> >     Yossi Gilad <[email-masked]>, Sharon Goldberg <[email-masked]>
> >
> >     A new version of I-D, draft-yossigi-rpkimaxlen-02.txt
> >     has been successfully submitted by Job Snijders and posted to the
> >     IETF repository.
> >
> >     Name:           draft-yossigi-rpkimaxlen
> >     Revision:       02
> >     Title:          The Use of Maxlength in the RPKI
> >     Document date:  2018-03-05
> >     Group:          Individual Submission
> >     Pages:          10
> >     URL:
> >     https://www.ietf.org/internet-drafts/draft-yossigi-rpkimaxlen-02.txt
> >     Status:         https://datatracker.ietf.org/
> > doc/draft-yossigi-rpkimaxlen/
> >     Htmlized:       https://tools.ietf.org/html/
> > draft-yossigi-rpkimaxlen-02
> >     Htmlized:
> >     https://datatracker.ietf.org/doc/html/draft-yossigi-rpkimaxlen-02
> >     Diff:           https://www.ietf.org/rfcdiff?
> > url2=draft-yossigi-rpkimaxlen-02
> >
> >     Abstract:
> >        This document recommends that operators avoid using the maxLength
> >        attribute when issuing Route Origin Authorizations (ROAs) in the
> >        Resource Public Key Infrastructure (RPKI).  These recommendations
> >        complement those in [RFC7115].
> >
> >
> >     Please note that it may take a couple of minutes from the time of
> > submission
> >     until the htmlized version and diff are available at tools.ietf.org.
> >
> >     The IETF Secretariat
> >
> >     _______________________________________________
> >     Sidrops mailing list
> >     [email-masked]
> >     https://www.ietf.org/mailman/listinfo/sidrops
> >
> >
> > _______________________________________________
> > Sidrops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sidrops
> >

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 25 Apr 2018 17:30:34 +0000

> Can you share with us the outcome of this adoption call?

Sure! I think there's at least 5 people interested in moving this document
forward, let's get a version re-named properly and submitted into the
repository?

thanks! (for the reminder and the document)

-chris
co-chair-1 of 2

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 26 Apr 2018 14:44:37 +0000

This is going to make the ROA table as large as the BGP table. The ROA table must be stored in routers, some of which are already memory challenged.
Instead of removing maxlen from RPKI, wouldn’t it be better to add a maxlen to BGP?
Then we could reduce the size of the BGP table instead of growing the ROA table.

I said this years ago, but I’ll say it again.
If you own a prefix matched by a ROA, then you MUST announce it in BGP.
If you own a prefix that you don’t want to announce in BGP, then you SHOULD issue a ROA that associates that prefix with AS0. Then nobody can announce it.

Thanks,
Jakob.

> On Mar 5, 2018, at 10:15 AM, Job Snijders <[email-masked]> wrote:
> 
> Dear working group,
> 
> This document has gone through a number of revisions outside the working group.
> 
> Status:         https://datatracker.ietf.org/doc/draft-yossigi-rpkimaxlen/
> Htmlized:       https://tools.ietf.org/html/draft-yossigi-rpkimaxlen-02
> Htmlized:
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-yossigi-rpkimaxlen-02
> 
> Abstract:
> Please note that it may take a couple of minutes from the time of submission

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Apr 2018 10:32:27 -0700

> If you own a prefix matched by a ROA, then you MUST announce it in

why?

> If you own a prefix that you don’t want to announce in BGP, then you
> SHOULD issue a ROA that associates that prefix with AS0. Then nobody
> can announce it.

except that is not true.  as0 is not trump; there can be other better
matching (or not) roas.

randy

---

From: Job Snijders <[email-masked]>
Date: Thu, 26 Apr 2018 17:33:47 +0000

On Thu, Apr 26, 2018 at 02:44:37PM +0000, Jakob Heitz (jheitz) wrote:
> This is going to make the ROA table as large as the BGP table.

What is the problem?

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 26 Apr 2018 17:35:23 +0000

The part that you snipped:

The ROA table must be stored in routers, some of which are already memory challenged.

Thanks,
Jakob

From: Job Snijders <[email-masked]>
Sent: Thursday, April 26, 2018 10:34 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Ben Maddison <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

What is the problem?

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 26 Apr 2018 17:43:11 +0000

> The ROA table must be stored in routers, some of which are already memory

If you can’t store 100 megabyte - what are you doing with a full table? I
find it hard to consider this a serious argument in favor of Maxlength.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 26 Apr 2018 20:05:25 +0000

I'd rather add a maxLength to BGP routes and use the 100 megabytes for something else.

If you added a maxLength path-attribute to BGP routes, you could solve all the subprefix
hijacks in the draft.

Thanks,
Jakob

From: Sidrops <[email-masked]> On Behalf Of Job Snijders
Sent: Thursday, April 26, 2018 10:43 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]; Ben Maddison <[email-masked]>; [email-masked]; Job Snijders <[email-masked]>
Subject: Re: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

On Thu, 26 Apr 2018 at 19:35, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
The part that you snipped:

If you can’t store 100 megabyte - what are you doing with a full table? I find it hard to consider this a serious argument in favor of Maxlength.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 26 Apr 2018 20:05:27 +0000

-----Original Message-----
From: Randy Bush <[email-masked]> 
Subject: Re: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

why?

[[jheitz]] To prevent the subprefix attack described in the draft

[[jheitz]] How is it not true?
If there is only a ROA matching AS0 for a prefix, then any BGP announcement
of that prefix will be invalid. There cannot be other ROAs unless the 
prefix owner issues them.

Jakob.

---

From: Ben Maddison <[email-masked]>
Date: Fri, 27 Apr 2018 00:15:30 +0000

Hi Jakob,

Surely then an attacker just adds a correspondingly higher value to the maxLength path-attribute to the sub-prefix hijack announcement, and you're back to where we started: working out which to trust?
Or am I missing something obvious?

Not to mention of course -

rfc4271#section-9.1:
   The function that calculates the degree of preference for a given
   route SHALL NOT use any of the following as its inputs: the existence
   of other routes, the non-existence of other routes, or the path
   attributes of other routes.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     021 200 9000
Fax:         086 614 2342
Cell:         +27 (0) 82 415 5545
Email:       [email-masked]
SIP:          [email-masked]

________________________________________
From: Jakob Heitz (jheitz) [[email-masked]]
Sent: 26 April 2018 10:05 PM
To: Job Snijders
Cc: [email-masked]; Ben Maddison; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

Thanks,
Jakob

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 27 Apr 2018 00:46:55 +0000

The prefix owner will issue the ROA

  ROA:(168.122.0.0/16-20, AS:64496)

and a BGP announcement

  BGP:(168.122.0.0/16-20, AS:64496)

Same maxlen in both the ROA and the BGP.

Routes that an attacker could send:

BGP:(168.122.0.0/21, AS:64511)          - invalid (covered)
BGP:(168.122.0.0/20, AS:64511 64496)    - valid, longer AS-PATH
BGP:(168.122.0.0/16-21, AS:64511 64496) 
  - the routes with netmask 16 to 20 are valid, longer AS-PATH
  - the routes with netmask 21 are invalid (covered)

What you're missing is my description of what maxLength would mean in a BGP route.
BGP would create all the routes within the cone described down to the
maxLength. It would not physically create them, but store enough information
so that it can act as if it did. It would run bestpath as if all those
routes actually existed. Then longest netmask would not win anymore.
It's like advertising all the routes in the cone with the same attributes,
but in a single NLRI.

Thanks,
Jakob

-----Original Message-----
From: Ben Maddison <[email-masked]> 
Sent: Thursday, April 26, 2018 5:16 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

Hi Jakob,

rfc4271#section-9.1:

Cheers,

Ben Maddison

Director

Office:     021 200 9000
Fax:         086 614 2342

Thanks,
Jakob

If you can't store 100 megabyte - what are you doing with a full table? I find it hard to consider this a serious argument in favor of Maxlength.

Kind regards,

Job

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 27 Apr 2018 19:16:03 +0000

Jakob:

How does your scheme work if own 168.122.0.0/16 and want to announce 
only 168.122.0.0/16 and 168.122.0.0/24 from AS 64496,
and want to prevent all hijacks / forged-origin hijacks of
anything else in my address space?

With the proposal in the draft (i.e., avoid using maxlength),
I would still be vulnerable to forged-origin hijack of
168.122.0.0/16 and 168.122.0.0/24, but I am assured that 
I am totally protected from hijacks / forged-origin hijacks 
of all my subprefixes (within 168.122.0.0/16)
except 168.122.0.0/24 which is vulnerable only to forged-origin hijack.
IOW, the attack surface is significantly reduced.

Sriram  

-----Original Message-----
From: Jakob Heitz (jheitz) [mailto:[email-masked]] 
Sent: Thursday, April 26, 2018 8:47 PM
To: Ben Maddison <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

and a BGP announcement

What you're missing is my description of what maxLength would mean in a BGP route.
BGP would create all the routes within the cone described down to the maxLength. It would not physically create them, but store enough information so that it can act as if it did. It would run bestpath as if all those routes actually existed. Then longest netmask would not win anymore.
It's like advertising all the routes in the cone with the same attributes, but in a single NLRI.

Thanks,
Jakob

-----Original Message-----
From: Ben Maddison <[email-masked]>
Sent: Thursday, April 26, 2018 5:16 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

Hi Jakob,

rfc4271#section-9.1:

Cheers,

Ben Maddison

Director

Office:     021 200 9000
Fax:         086 614 2342

If you added a maxLength path-attribute to BGP routes, you could solve all the subprefix hijacks in the draft.

Thanks,
Jakob

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 27 Apr 2018 22:02:05 +0000

My scheme simplifies your advertisements if you want to
advertise a lot of your sub-prefixes. It allows you to
advertise them all in one shot. And protect them all in one shot.

You only want to announce two prefixes, that's your choice.

As for the attack surface from the forged-origin hijack,
it's the same. Attacking a single /16 is the same as
attacking all the sub-prefixes under it. It is the same
address space.

I do agree with the aim of the draft: do not issue a ROA
for a prefix you don't announce in BGP.

The trouble is that if you have an urgent need to
advertise a sub-prefix, then it would take a day
to get the ROA out.

Thanks,
Jakob

-----Original Message-----
From: Sriram, Kotikalapudi (Fed) <[email-masked]> 
Sent: Friday, April 27, 2018 12:16 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Ben Maddison <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

Jakob:

Sriram  

-----Original Message-----
From: Jakob Heitz (jheitz) [mailto:[email-masked]] 
Sent: Thursday, April 26, 2018 8:47 PM
To: Ben Maddison <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

and a BGP announcement

Thanks,
Jakob

-----Original Message-----
From: Ben Maddison <[email-masked]>
Sent: Thursday, April 26, 2018 5:16 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Sidrops] Fwd: New Version Notification for draft-yossigi-rpkimaxlen-02.txt

Hi Jakob,

rfc4271#section-9.1:

Cheers,

Ben Maddison

Director

Office:     021 200 9000
Fax:         086 614 2342

Thanks,
Jakob

Kind regards,

Job