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

[Christopher Morrow <[e-mail]>]

backup up a tad... somehow *(probably late-work-night clicking) I added
joel/marco to the 'reject mail' list :( (note that both are now subscribed
to the list.. if you do not want that you should go unsubscribe)

I'm sorry there were 4 messages, copied here, which didn't make it to
sidrops@

---------------- msg 1 --------------------

On 1/13/17 2:53 PM, Job Snijders wrote:
> On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote:
>> On 1/13/17 1:54 PM, Marco Marzetti wrote:
>>> <rant>
>>> 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?
>>> </rant>
>>>
>>> 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.
I do wonder about the rational for saying "this is invalid, but here you go"

if I'm validating ROAs and my posture is that I don't accept routes with
invalid ROAS then I'm not taking any action on the basis of this
community. If I don't  validate, I'm not taking any action on the basis
of this community.
> Kind regards,
>
> Job
>

---------------- end msg 1 -----------------------
---------------- msg 2 -----------------------------

From: Marco Marzetti <[e-mail]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: joel jaeggli <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail], GMO Crops <[e-mail]>,
 Job Snijders <[e-mail]>
Date: Sat, 14 Jan 2017 12:58:14 +0100

Joel,

So you don't want your upstreams to honor RPKI just because they're
3rd parties between you and the other end?
In the context of IXPs: instead of peering with the RS you should
setup direct sessions with your partners if you really want to do
prefix/path validation by yourself.

Regards

--------------- end msg 2 ----------------------
-------------- msg 3 -----------------------------
From: Marco Marzetti <[e-mail]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Christopher Morrow <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail], GMO Crops <[e-mail]>,
 Job Snijders <[e-mail]>
Date: Sat, 14 Jan 2017 13:03:56 +0100

Christopher,

As Nick has already pointed out as soon as you peer with the RS you've
already delegated some part of the decision process to the IXP.
Why RPKI can't be part of that?

After all there are IXPs that filter advertisements not covered by IRR
route objects.

Regards

--------------- end msg 3 ---------------------
--------------- msg 4 ---------------------------
From: Marco Marzetti <[e-mail]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Nick Hilliard <[e-mail]>
Cc: Christopher Morrow <[e-mail]>, [e-mail],
 GMO Crops <[e-mail]>, Job Snijders <[e-mail]>
Date: Sat, 14 Jan 2017 16:49:02 +0100

Nick,

You know the IXPs's world better then me so i take your analysis as valid.

But there's something that i would like to point out.
The concept of IXP has changed and we cannot longer consider them as
simple LANs run on top of a bunch of switches.
Of course there are small entities that fit into the original
definition, but there are also *very* large networks that move your
packets between distant locations over MPLS.
And that's much like what transit networks do.

So i can't understand why we should not encourage (in a very strong
way) RSs to run RPKI.
That doesn't mean the RS MUST drop the prefixes: They should lower the
LOCAL_PREF and as Joel has suggested add a prepend (or 2 or 3).

Regards

------------------ end msg 4 ----------------------


On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti <[e-mail]> 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.
>
> About the forged AS_PATHs: why is this important only when it comes to
> IXPs?
>
> Regards
>
>
> On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow
> <[e-mail]> wrote:
> >
> >
> > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <[e-mail]>
> wrote:
> >>
> >> <rant>
> >> 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?
> >> </rant>
> >>
> >> 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 <[e-mail]> wrote:
> >> >> Adding [e-mail] 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> >> --
> >> Marco
> >>
> >> _______________________________________________
> >> GROW mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> >
>
>
>
> --
> Marco
>