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

On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <joelja@bogus.com> 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.

> 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.
>
> 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.

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

Regards.

>> Regards
>>
>>
>> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli <joelja@bogus.com> 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 <randy@psg.com> 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