Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Jakob Heitz (jheitz)]

With credentials.
Surely if you own the prefix, then you have power over those with credentials 
and the ability to remove all ROAs for it that point to as 42.

Thanks,
Jakob.


> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Friday, January 13, 2017 7:08 PM
> To: Jakob Heitz (jheitz) 
> Cc: Christopher Morrow ; Marco Marzetti 
> ; sidr...@ietf.org; GMO
> Crops ; Job Snijders 
> Subject: Re: [Sidrops] [GROW] I-D Action: 
> draft-ietf-sidrops-route-server-rpki-light-00.txt
> 
> > If you need to protect a prefix that you don't advertise then put ASN
> > 0 into the ROA for it.  Then nobody can advertise it.
> 
> not exactly.  someone (with credentials) can issue a roa for the same
> prefix to as 42, and it will validate the origination.  there can be
> many roas which match a single announcement; all it takes is one to be
> valid.
> 
> randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Jakob Heitz (jheitz)]

That's path validation.

Anyway, the diameter of the Internet is only about 4 to 5 AS hops.
Tier 1's only care about the radius, which is mostly 1, 2 or 3 AS hops.

Given such short AS paths, RPKI can provide a good level of protection already.
If the attacker originates a route prepended by the legitimate AS, then his 
AS-PATH will
be longer than that of the legitimate route in the large majority of the 
Internet.
But only if each AS that registers a ROA advertises every prefix matched by the 
ROA.
If it does not, then another AS can easily steal the prefix like you said.

If you need to protect a prefix that you don't advertise then put ASN 0 into 
the ROA for it.
Then nobody can advertise it.

Thanks,
Jakob.

From: Sidrops [mailto:sidrops-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Friday, January 13, 2017 2:05 PM
To: Marco Marzetti 
Cc: Randy Bush ; sidr...@ietf.org; GMO Crops ; 
Job Snijders 
Subject: Re: [Sidrops] [GROW] I-D Action: 
draft-ietf-sidrops-route-server-rpki-light-00.txt



On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti 
> wrote:

Every time one suggests a change related to the IXPs world we spend
days arguing if it affects the neutrality and how.
Do we really need that?


Anyway, i can't see why IXPs can blackhole traffic (if the destination
requests it), but cannot do the same with prefixes.
After all if a prefix is invalid the owner requested it to be verified
by the other parties.

I think part of job's point (and randy's in a way) is that you actually don't 
know if:
  192.168.0.0/23 AS1 AS3 AS8

is valid, even if you see a ROA:
192.168.0.0/16 AS8 max-len /23

... because there's nothing that keeps AS-ME from sending AS-JOB a route with 
AS8 prepended on the as-path.

I suggest to default to drop and, if possible, to switch to announce
with community if the peer requests it (for instance someone may want
to collect invalid routes for analysis).

i think you are describing implementations that the IXP may choose... I don't 
know that this draft needs to specify that at all.

-chris


On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush 
> wrote:
>> Adding grow@ietf.org for reality check.
>
> no comment :)
>
> when you choose to use a route server [0], you have out-sourced much of
> your policy and operational responsibilities.  seems to me that whether
> this includes security decisions is a contract between the user and the
> route server.
>
> so i might tell the server to drop invalids.  if i do not take that
> (configurable, i presume) option, having the server mark them seems
> helpful.
>
> randy
>
> --
>
> 0 - i suspect none of job, carlos, or i do.  so this is the experts
> telling other people what they should do. :)
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



--
Marco

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Job Snijders]

On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote:
> On 1/13/17 1:54 PM, Marco Marzetti wrote:
> > 
> > Every time one suggests a change related to the IXPs world we spend
> > days arguing if it affects the neutrality and how. Do we really
> > need that?
> > 
> >
> > Anyway, i can't see why IXPs can blackhole traffic (if the
> > destination requests it), but cannot do the same with prefixes.
> > After all if a prefix is invalid the owner requested it to be
> > verified by the other parties.
>
> In general the consequences for IX operator that either allows it
> customers to attack each other over the exchange route-server or does
> so itself seems severe. Loss of confidence in the disposition of one's
> own routes seems like immediate grounds for depeering. If the routes
> remain afterwards with the short as path; the operator is engaged in
> prefix hijakcing.
> 
> I personally find it dubious that I would choose to honor a third
> parties efforts at origin validation if I did not myself validate them
> but a signal from the exchange that it did validate the origin or that
> there an invalid roa floating around is at a minimum very interesting.

I still don't understand how there can be a justification as to why it
would be OK for route servers to redistribute poisonous routes and say
"trust me its OK i added a community!", and we expect some different
behaviour from 'the rest of the AS's'?

In a case like this 
http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html,
assuming a ROA had existed for 206.125.164.0/22, what would've been the
appropiate response from any AS involved (including route servers)?

A) "its fine, i tagged it with a community and amplified the problem
by propagating it to all my peers"

B) "the buck stops with me, the invalid route will not be propagated by me"

At the very least, i'd prefer the default mode should be a secure mode,
not a 'scientifically interesting' mode.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Christopher Morrow]

On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti  wrote:

> Christopher,
>
> I have to admit that i am not aware of the ongoing work on sidrops, so
> i may lack the needed background, but this draft only suggests to
> re-advertise all the prefixes. No matter what.
> Am i wrong? In that case i apologize.
>

it actually, I think , just says: "put a community that can be interpreted
as valid/invalid/etc"

I don't know that you'd want an RS keeping information from you, as a
downstream of that RS, would you? I'd rather see the things so I can decide
what's best for me.

I think because this seems like a 'per network' or 'per ixp' concept, let's
let the document not define the implementation, but just the capability.


>
> About the forged AS_PATHs: why is this important only when it comes to
> IXPs?
>
>
I don't think it is.


> Regards
>
>
> On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow
>  wrote:
> >
> >
> > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti 
> wrote:
> >>
> >> 
> >> Every time one suggests a change related to the IXPs world we spend
> >> days arguing if it affects the neutrality and how.
> >> Do we really need that?
> >> 
> >>
> >> Anyway, i can't see why IXPs can blackhole traffic (if the destination
> >> requests it), but cannot do the same with prefixes.
> >> After all if a prefix is invalid the owner requested it to be verified
> >> by the other parties.
> >>
> >
> > I think part of job's point (and randy's in a way) is that you actually
> > don't know if:
> >   192.168.0.0/23 AS1 AS3 AS8
> >
> > is valid, even if you see a ROA:
> > 192.168.0.0/16 AS8 max-len /23
> >
> > ... because there's nothing that keeps AS-ME from sending AS-JOB a route
> > with AS8 prepended on the as-path.
> >
> >>
> >> I suggest to default to drop and, if possible, to switch to announce
> >> with community if the peer requests it (for instance someone may want
> >> to collect invalid routes for analysis).
> >>
> >
> > i think you are describing implementations that the IXP may choose... I
> > don't know that this draft needs to specify that at all.
> >
> > -chris
> >
> >>
> >> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
> >> >> Adding grow@ietf.org for reality check.
> >> >
> >> > no comment :)
> >> >
> >> > when you choose to use a route server [0], you have out-sourced much
> of
> >> > your policy and operational responsibilities.  seems to me that
> whether
> >> > this includes security decisions is a contract between the user and
> the
> >> > route server.
> >> >
> >> > so i might tell the server to drop invalids.  if i do not take that
> >> > (configurable, i presume) option, having the server mark them seems
> >> > helpful.
> >> >
> >> > randy
> >> >
> >> > --
> >> >
> >> > 0 - i suspect none of job, carlos, or i do.  so this is the experts
> >> > telling other people what they should do. :)
> >> >
> >> > ___
> >> > GROW mailing list
> >> > GROW@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> >> --
> >> Marco
> >>
> >> ___
> >> GROW mailing list
> >> GROW@ietf.org
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> >
>
>
>
> --
> Marco
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[joel jaeggli]

On 1/13/17 1:54 PM, Marco Marzetti wrote:
> 
> Every time one suggests a change related to the IXPs world we spend
> days arguing if it affects the neutrality and how.
> Do we really need that?
> 
>
> Anyway, i can't see why IXPs can blackhole traffic (if the destination
> requests it), but cannot do the same with prefixes.
> After all if a prefix is invalid the owner requested it to be verified
> by the other parties.
In general the consequences for IX operator that either allows it
customers to attack each other over the exchange route-server or does so
itself seems severe. Loss of confidence in the disposition of one's own
routes seems like immediate grounds for depeering. If the routes remain
afterwards with the short as path; the operator is engaged in prefix
hijakcing.

I personally find it dubious that I would choose to honor a third
parties efforts at origin validation if I did not myself validate them
but a signal from the exchange that it did validate the origin or that
there an invalid roa floating around is at a minimum very interesting.
> I suggest to default to drop and, if possible, to switch to announce
> with community if the peer requests it (for instance someone may want
> to collect invalid routes for analysis).
>
>
> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
>>> Adding grow@ietf.org for reality check.
>> no comment :)
>>
>> when you choose to use a route server [0], you have out-sourced much of
>> your policy and operational responsibilities.  seems to me that whether
>> this includes security decisions is a contract between the user and the
>> route server.
>>
>> so i might tell the server to drop invalids.  if i do not take that
>> (configurable, i presume) option, having the server mark them seems
>> helpful.
>>
>> randy
>>
>> --
>>
>> 0 - i suspect none of job, carlos, or i do.  so this is the experts
>> telling other people what they should do. :)
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>
>




signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Christopher Morrow]

On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti  wrote:

> 
> Every time one suggests a change related to the IXPs world we spend
> days arguing if it affects the neutrality and how.
> Do we really need that?
> 
>
> Anyway, i can't see why IXPs can blackhole traffic (if the destination
> requests it), but cannot do the same with prefixes.
> After all if a prefix is invalid the owner requested it to be verified
> by the other parties.
>
>
I think part of job's point (and randy's in a way) is that you actually
don't know if:
  192.168.0.0/23 AS1 AS3 AS8

is valid, even if you see a ROA:
192.168.0.0/16 AS8 max-len /23

... because there's nothing that keeps AS-ME from sending AS-JOB a route
with AS8 prepended on the as-path.


> I suggest to default to drop and, if possible, to switch to announce
> with community if the peer requests it (for instance someone may want
> to collect invalid routes for analysis).
>
>
i think you are describing implementations that the IXP may choose... I
don't know that this draft needs to specify that at all.

-chris


> On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
> >> Adding grow@ietf.org for reality check.
> >
> > no comment :)
> >
> > when you choose to use a route server [0], you have out-sourced much of
> > your policy and operational responsibilities.  seems to me that whether
> > this includes security decisions is a contract between the user and the
> > route server.
> >
> > so i might tell the server to drop invalids.  if i do not take that
> > (configurable, i presume) option, having the server mark them seems
> > helpful.
> >
> > randy
> >
> > --
> >
> > 0 - i suspect none of job, carlos, or i do.  so this is the experts
> > telling other people what they should do. :)
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
>
>
>
> --
> Marco
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Marco Marzetti]

Every time one suggests a change related to the IXPs world we spend
days arguing if it affects the neutrality and how.
Do we really need that?


Anyway, i can't see why IXPs can blackhole traffic (if the destination
requests it), but cannot do the same with prefixes.
After all if a prefix is invalid the owner requested it to be verified
by the other parties.

I suggest to default to drop and, if possible, to switch to announce
with community if the peer requests it (for instance someone may want
to collect invalid routes for analysis).


On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush  wrote:
>> Adding grow@ietf.org for reality check.
>
> no comment :)
>
> when you choose to use a route server [0], you have out-sourced much of
> your policy and operational responsibilities.  seems to me that whether
> this includes security decisions is a contract between the user and the
> route server.
>
> so i might tell the server to drop invalids.  if i do not take that
> (configurable, i presume) option, having the server mark them seems
> helpful.
>
> randy
>
> --
>
> 0 - i suspect none of job, carlos, or i do.  so this is the experts
> telling other people what they should do. :)
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



-- 
Marco

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Randy Bush]

> Adding grow@ietf.org for reality check.

no comment :)

when you choose to use a route server [0], you have out-sourced much of
your policy and operational responsibilities.  seems to me that whether
this includes security decisions is a contract between the user and the
route server.

so i might tell the server to drop invalids.  if i do not take that
(configurable, i presume) option, having the server mark them seems
helpful.

randy

--

0 - i suspect none of job, carlos, or i do.  so this is the experts
telling other people what they should do. :)

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[job]

Adding grow@ietf.org for reality check.

On 13 Jan 2017, 21:19 +0100, Carlos M. Martinez , wrote:
>
> We agree to disagree then. I strongly believe the Internet strives to 
> delegate decision making and doesn’t like hierarchies very much.
>
>
> I’d prefer these decisions to be delegated as far away from the network´s 
> core as possible.
>
>
> -Carlos
>
>
> On 13 Jan 2017, at 17:13, j...@ntt.net wrote:
>
>
> > I am advocating a strong security posture, in which each ASN takes their 
> > responsibility to the best of their abilities in maintaining a healthy 
> > global routing system. KNOWINGLY distributing routes which are considered 
> > Invalid is the wrong thing to do.
> >
> > If an ASN (read Route Server) doesn't want to participate in keeping the 
> > routing system clean, they should perhaps consider ceasing their BGP 
> > operations, but certainly not hide under the guise of "offering customers 
> > all options".
> >
> > An autonomous system is an autonomous system. IXP operators do not get a 
> > free pass to propagate garbage, the same garbage we expect the rest of the 
> > operators to reject.
> >
> > This draft promotes an insecure mode of operation.
> >
> > Kind regards,
> >
> > Job
> >
> >
> >
> > On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez , 
> > wrote:
> > > Hi Job,
> > >
> > > I believe what what you propose would be deciding on behalf of people
> > > who are not your customers and with whom you only have a loose
> > > relationship based on sharing something. I don´t think a route server
> > > should in fact drop invalid routes when re-announcing them to the other
> > > peers.
> > >
> > > I understand that this could be different depending on the arrangements
> > > among members of the IXP, but, I like to have the option for marking
> > > open.
> > >
> > > Cheers!
> > >
> > > -Carlos
> > >
> > > On 13 Jan 2017, at 15:40, Job Snijders wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have trouble with the idea proposed in this draft. It reads to me
> > > > "When the route server receives a hijacked prefix, it will decorate it
> > > > with an extended community and propagate it to all its peers".
> > > >
> > > > This is not a responsible thing to do. Route Server operators should
> > > > configure there route servers to reject/drop/ignore 'RPKI invalid'
> > > > announcements, and thats should be the end of it.
> > > >
> > > > Kind regards,
> > > >
> > > > Job
> > > >
> > > > On Fri, Jan 13, 2017 at 10:28:24AM -0800, internet-dra...@ietf.org
> > > > wrote:
> > > > >
> > > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > > directories.
> > > > > This draft is a work item of the SIDR Operations of the IETF.
> > > > >
> > > > > Title : Signaling Prefix Origin Validation Results
> > > > > from a Route-Server to Peers
> > > > > Authors : Thomas King
> > > > > Daniel Kopp
> > > > > Aristidis Lambrianidis
> > > > > Arnaud Fenioux
> > > > > Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt
> > > > > Pages : 6
> > > > > Date : 2017-01-13
> > > > >
> > > > > Abstract:
> > > > > This document defines the usage of the BGP Prefix Origin
> > > > > Validation
> > > > > State Extended Community
> > > > > [I-D.ietf-sidr-origin-validation-signaling]
> > > > > to signal prefix origin validation results from a route-server to
> > > > > its
> > > > > peers. Upon reception of prefix origin validation results peers
> > > > > can
> > > > > use this information in their local routing decision process.
> > > > >
> > > > >
> > > > >
> > > > > The IETF datatracker status page for this draft is:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/
> > > > >
> > > > > There's also a htmlized version available at:
> > > > > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > > ___
> > > > > Sidrops mailing list
> > > > > sidr...@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/sidrops
> > > >
> > > > ___
> > > > Sidrops mailing list
> > > > sidr...@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sidrops
> > >
> > > ___
> > > Sidrops mailing list
> > > sidr...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sidrops
> ___
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow