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

[joel jaeggli <[e-mail]>]

On 1/15/17 6:35 AM, Marco Marzetti wrote:
> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <[e-mail]> wrote:
>> On 1/14/17 3:58 AM, Marco Marzetti wrote:
>>> Joel,
>>>
>>> So you don't want your upstreams to honor RPKI just because they're
>>> 3rd parties between you and the other end?
>>
>> An ixp route-server is not a transit provider, all of the nexthops
>> exposed are in fact peers. So no I do not consider such a  device an
>> "upstream" it exists to service the policy needs of the peers on the
>> fabric  rather than that of the exchange operator.
>>
> 
> You can easily do the same in transit providers by disabling next-hop-self.

Nope, The router expressing nexthop self retains the available nexthops.
Under no circumstance is the router-server in the forwarding path, were
it, the route-server would be an upstream.

> 
>> I would  expect that a ixp route server that had a state policy of
>> validating rpki would not propagate invalid routes.
>>
>>> 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.

Consider the case where the invalid route masks an valid but longer path
from being advertised via the route server as the best path. in that
case the validating route-server is facilitating a prefix hijacking
which it would not have, had it discarded the route. You might argue
that this is no worse than not validating, however I think that is a
somewhat dubious point given that the rib on the route-server would show
otherwise.

>> No, I setup bilateral peering arrangements because they actually load
>> balance to my multiple ports, because the loci of control is
>> unambiguous, because it facilitates greatly build per session prefix
>> filters, and because they converge the control and forwarding path,
>> which has a tendency to fail much more gracefully in the face of l2
>> failures in distributed exchange fabric designs then does the route-server.
>>
> 
> Aren't we saying the same thing?
> Bilateral peering brings more control over what you send and receive.

we have a similar concurrence respecting the advantages. We appear to
differ on whether the route server offering a feature or not confers a
similar outcome.

> I just take an additional step and say that RPKI should be part of the
> default decision process of RSs

To confer the advantage you need to not allow invalid routes into your
best path selection processing.

> Regards.
> 
>>> Regards
>>>
>>>
>>> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli <[e-mail]> 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 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 <[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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
> 
>