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

2017-01-17 Thread Marco Marzetti 
On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli  wrote:
> On 1/15/17 6:35 AM, Marco Marzetti wrote:
>> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli  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.
>

That;s correct.
But is the specific device really relevant?

I mean: you send your traffic to another network's forwarding plane.
Do you really care about the role of the devices your packets pass through?

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

I argue that the same could happen with transit and we would consider it legit.
Why?

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

Again, I really do think that the same logic of transit applies here.

Regards


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

2017-01-16 Thread joel jaeggli 
On 1/15/17 6:35 AM, Marco Marzetti wrote:
> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli  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  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 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

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

2017-01-16 Thread i3D.net - Martijn Schmidt 
Hi all,

Invalid is invalid: it means that someone is hijacking the prefix,
because the owner of the resource is telling us through RPKI that the
route should be originated by a different ASN. If your BGP
implementation is able to detect that it should not propagate the
hijacked route. If your BGP implementation is not able to understand
RPKI (hi Brocade), then it would be nice to receive at least some form
of protection via the route-server if you choose to use it.

The argument that it should just be another parameter for the best path
election on the route-server is weak at best, many networks wouldn't
advertise their valid prefix with correct origin to that specific
route-server - or not to any route-server at all. And that'd
automatically mean that the invalid prefix is going to be propagated by
the route-server.. which is undesirable.

Best regards,
Martijn Schmidt

On 01/16/2017 12:03 AM, Matthias Waehlisch wrote:
> I don't know if we are losing sight. The argument that RS is doing best 
> path selection was stated several times.
>
> However, I still don't buy the argument "route servers and rpki are an 
> uncomfortable fit."
>
> I buy the argument that fine-grained policy configuration challenges RS 
> operation. And for sure the principle is indepdent of RPKI. In the most 
> boring case, the decision results in "Prefer the route received from the 
> lowest peer address." Ups, is this the IP address of the peering LAN, 
> given by the IXP.
>
> What is specific to RPKI is proxying of security-related meta data 
> (i.e., easier deployment of new protocols via RS).
>
> For example, in the case of policy prefer-valid-over-invalid AND there 
> is no valid, RS would announce the (invalid) prefix to peer P. P also 
> established private peering and receives announcement for the invalid 
> prefix. Without deploying RPKI, this BGP speaker could benefit from RS 
> meta data, dropping both.
>
>
>
> Cheers
>   matthias
>
> On Sat, 14 Jan 2017, Nick Hilliard wrote:
>
>> Matthias Waehlisch wrote:
>>> the current discussion makes clear that documentation of 
>>> origin-validation-signaling in IXP context is needed
>> rpki is conceptually no different to any other type of signaling
>> mechanism: it's simply another input into the BGP decision engine
>> process, just like communities or meds or as-path.
>>
>> What we're losing sight of here is that it's the route server which
>> calculates the best path for each route using the routing decision
>> engine, and then sends a _single_ best path to the client. Conceptually,
>> it doesn't matter whether the tie-breaker on the route server is
>> communities, meds, as-path or rpki: the point is that the policy
>> decision mechanism needs to be configured on the route server itself,
>> because the route server is the device which is calculating the best
>> path.  If the route server operator doesn't do this, the clients will
>> end up with path hiding (see 2.3.1 in rfc7947).  I.e. it's nothing
>> specific to rpki.
>>
>> This is already extensively documented in rfc7947 and rfc7948.
>>
>> Nick
>>
>

___
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

2017-01-15 Thread Marco Marzetti 
On Sun, Jan 15, 2017 at 3:49 PM, Job Snijders  wrote:
> On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote:
>> On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush  wrote:
>> > [ first, i do not use route serves (because of the data/control non-
>> >   congruence), so my opinion here is worth even less than it normally
>> >   is. ]
>> >
>> >> 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.
>> >
>> > to repeat my previous; those policy needs might vary across ix members.
>> > some may want the ix to enforce origin validation for them, some may
>> > not.  those exchanges which offer validation today offer the choice.  i
>> > think that is the right thing; let the member make the choice at set-up
>> > with the route server.
>>
>> I think RSs should do RPKI by default and allow for two behaviors:
>> 1) Drop (default)
>> 2) Add ext-community as this draft suggests (upon request)
>
> Or perhaps we consider a Route Server to be "Just Yet Another Autonomous
> System"? Why should there be a difference between Autonomous Systems
> with regard to routing security recommendations?
>

I do consider it "another AS".

> If the recommendation is to drop/ignore/reject "RPKI Invalid"
> announcements, then that applies to Route Servers too, if the
> recommendation is to just attach an Extended BGP Community, then that
> will apply to all ASNs.

What's the current recommendation now?

Regards

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

2017-01-15 Thread Job Snijders 
On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote:
> On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush  wrote:
> > [ first, i do not use route serves (because of the data/control non-
> >   congruence), so my opinion here is worth even less than it normally
> >   is. ]
> >
> >> 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.
> >
> > to repeat my previous; those policy needs might vary across ix members.
> > some may want the ix to enforce origin validation for them, some may
> > not.  those exchanges which offer validation today offer the choice.  i
> > think that is the right thing; let the member make the choice at set-up
> > with the route server.
> 
> I think RSs should do RPKI by default and allow for two behaviors:
> 1) Drop (default)
> 2) Add ext-community as this draft suggests (upon request)

Or perhaps we consider a Route Server to be "Just Yet Another Autonomous
System"? Why should there be a difference between Autonomous Systems
with regard to routing security recommendations?

If the recommendation is to drop/ignore/reject "RPKI Invalid"
announcements, then that applies to Route Servers too, if the
recommendation is to just attach an Extended BGP Community, then that
will apply to all ASNs.

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

2017-01-15 Thread Marco Marzetti 
On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush  wrote:
> [ first, i do not use route serves (because of the data/control non-
>   congruence), so my opinion here is worth even less than it normally
>   is. ]
>
>> 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.
>
> to repeat my previous; those policy needs might vary across ix members.
> some may want the ix to enforce origin validation for them, some may
> not.  those exchanges which offer validation today offer the choice.  i
> think that is the right thing; let the member make the choice at set-up
> with the route server.

I think RSs should do RPKI by default and allow for two behaviors:
1) Drop (default)
2) Add ext-community as this draft suggests (upon request)


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

2017-01-15 Thread Marco Marzetti 
On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli  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  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 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

2017-01-14 Thread Randy Bush 
[ first, i do not use route serves (because of the data/control non-
  congruence), so my opinion here is worth even less than it normally
  is. ]

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

to repeat my previous; those policy needs might vary across ix members.
some may want the ix to enforce origin validation for them, some may
not.  those exchanges which offer validation today offer the choice.  i
think that is the right thing; let the member make the choice at set-up
with the route server.

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

there's a draft for that :)

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

2017-01-14 Thread Nick Hilliard 
Matthias Waehlisch wrote:
> the current discussion makes clear that documentation of 
> origin-validation-signaling in IXP context is needed

rpki is conceptually no different to any other type of signaling
mechanism: it's simply another input into the BGP decision engine
process, just like communities or meds or as-path.

What we're losing sight of here is that it's the route server which
calculates the best path for each route using the routing decision
engine, and then sends a _single_ best path to the client. Conceptually,
it doesn't matter whether the tie-breaker on the route server is
communities, meds, as-path or rpki: the point is that the policy
decision mechanism needs to be configured on the route server itself,
because the route server is the device which is calculating the best
path.  If the route server operator doesn't do this, the clients will
end up with path hiding (see 2.3.1 in rfc7947).  I.e. it's nothing
specific to rpki.

This is already extensively documented in rfc7947 and rfc7948.

Nick

___
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

2017-01-14 Thread joel jaeggli 
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.

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.

> Regards
> 
> 
> On Fri, Jan 13, 2017 at 11:28 PM, 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 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

2017-01-14 Thread Christopher Morrow 
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:
>>> 
>>> 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.
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 <ma...@lamehost.it>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: joel jaeggli <joe...@bogus.com>
Cc: Randy Bush <ra...@psg.com>, sidr...@ietf.org, GMO Crops <grow@ietf.org>,
 Job Snijders <j...@ntt.net>
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 <ma...@lamehost.it>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Christopher Morrow <christopher.mor...@gmail.com>
Cc: Randy Bush <ra...@psg.com>, sidr...@ietf.org, GMO Crops <grow@ietf.org>,
 Job Snijders <j...@ntt.net>
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 <ma...@lamehost.it>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Nick Hilliard <n...@foobar.org>
Cc: Christopher Morrow <christopher.mor...@gmail.com>, sidr...@ietf.org,
 GMO Crops <grow@ietf.org>, Job Snijders <j...@ntt.net>
Date: Sat, 14 Jan 2017 16:49:02 +0100

Nick,

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

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

2017-01-14 Thread Matthias Waehlisch 
On Sat, 14 Jan 2017, Nick Hilliard wrote:

> Matthias Waehlisch wrote:
> >   I think there are two cases: (1) RS client peers only with route 
> > server, (2) RS client peers additionally with other BGP speakers that 
> > don't peer with the RS.
> > 
> >   In case (1) (and assuming that the RS selects the best path on behalf 
> > of the client), the IXP provisioning system needs to provide all knobs 
> > to implement potential policies -- as you mentioned below. Should be s 
> > side note.
> > 
> >   In case (2), route-server-rpki-light would be still helpful.
> 
> Case (1) is not an ietf problem.
> 
> Case (2) is already documented in
> draft-ietf-sidr-origin-validation-signaling, which proposes a generic
> BGP signaling mechanism, i.e. nothing particularly to do with route
> servers.  In fact, if the -sidr- draft progresses, it should probably be
> mentioned somewhere that the proposed mechanism is likely to cause
> unexpected behaviour on route servers unless add-path tx is enabled on
> the route server.
> 
  the current discussion makes clear that documentation of 
origin-validation-signaling in IXP context is needed, either in 
sidr-origin-validation-signaling or in a separate document such as 
route-server-rpki-light. Personally, I tend to a separate doc 
(informational or best practice).



Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

___
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

2017-01-14 Thread Nick Hilliard 
Marco Marzetti wrote:
> Why RPKI can't be part of that?

tl;dr: route servers and rpki are an uncomfortable fit.

rpki can be part of that, but it's problematic because the route server
is running the routing decision engine on the part of the client.  RPKI
is a relatively fine-grained tool in the list of things that are taken
into account for the best path calculation, which means that there is a
genuine difficulty in providing enough fine-grained levers so that the
route server can handle this in a way that works well for clients.

As others have pointed out, the control mechanisms that rpki allows are
much easier to handle on bilateral bgp sessions than multilateral.

These problems mostly disappear if the route server and client use
add-path, because that shifts the burden of handling the policy
application fully to the client.  Where add-path is used, there is no
requirement to mark routes with communities firstly because no routing
policy action has been taken by the route server and secondly because
the client can check the ROA themselves.  The usual caveats about
add-path apply.

Stepping back a bit, most organisations who use route servers are
sufficiently small that they don't need anything more than highly
simplistic exterior routing policies, where almost everything is handled
by the default bgp decision process documented in rfc4271, and final
tweaks are handled by applying a single med or localpref for all peers
or all transits or whatever.  This is the category of ASNs that route
servers work best for. Once an organisation grows beyond a certain size,
it's quite usual to move away from using route servers - and at a later
stage still, to move away from using IXPs in favour of PNIs.

If an organisation's routing policies are more complicated than most,
then route servers are generally unsuitable anyway.  RPKI will reduce
that boundary of suitability, but not by much.  I'd hazard a guess that
if an IXP were to provide a primitive facility in their provisioning
system to allow clients to specify whether they wanted rpki-invalid or
rpki-notfound dropped or used in the decision engine, that would satisfy
most route server client organisations' policy requirements.  Obviously
this is not going to work for all organisations, but adding in more
fine-grained controls runs into diminishing returns very quickly indeed,
as has been implicitly noted in the ixp industry by the scarcity of
generally accepted policy controls outside the usual "redistribute or
don't redistribute my prefixes to ASN X" community tags.

If AS path validation ever happens, then this probably not work with
route servers at all, but that's a different thing, outside the scope of
this conversation.

Nick

___
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

2017-01-14 Thread Marco Marzetti 
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


On Fri, Jan 13, 2017 at 11:53 PM, Christopher Morrow
 wrote:
>
>
> 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
>
>



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

2017-01-14 Thread Marco Marzetti 
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


On Fri, Jan 13, 2017 at 11:28 PM, 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 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

2017-01-14 Thread Matthias Waehlisch 
Hi Nick,

  interesting. You are arguing who is doing the best path selection for 
a specific prefix.

  I think there are two cases: (1) RS client peers only with route 
server, (2) RS client peers additionally with other BGP speakers that 
don't peer with the RS.

  In case (1) (and assuming that the RS selects the best path on behalf 
of the client), the IXP provisioning system needs to provide all knobs 
to implement potential policies -- as you mentioned below. Should be s 
side note.

  In case (2), route-server-rpki-light would be still helpful.


  Maybe this should be clarified in route-server-rpki-light.
  


Cheers
  matthias

On Fri, 13 Jan 2017, Nick Hilliard wrote:

> j...@ntt.net wrote:
> > Adding grow@ietf.org for reality check.
> 
> We live in a post-truth world.
> 
> On a more serious note, this draft is the wrong way around and this
> probably means it's not operationally useful in most cases.
> 
> Let's say there's a route server R with clients A, B and C.  Clients A
> and B announce a prefix, the intention being that the route server will
> propagate this to C.  The route server will inject both prefixes into
> client C's Loc-RIB, and will then run the routing decision engine on
> that Loc-RIB.  The best path will be computed and the result will be
> sent to C.
> 
> If this draft is implemented the way it's stated, and client A injects a
> prefix which is has a valid rpki signature, and client B illegitimately
> injects the same prefix with an attribute set which ensures that it's
> the preferred prefix (doesn't matter whether it's signed or not), then
> the RDE will run and will unilaterally prefer the prefix from client B,
> ignoring the signed prefix from client A.  Client C will receive the
> hijacked prefix.  Not good.
> 
> Or assume that client A injects a prefix which has an invalid rpki
> signature, and client B legitimately injects the same prefix with an
> attribute set which ensures that it's not the preferred prefix (again,
> it doesn't matter whether it's signed or not), the prefix from client A
> will be preferred in client C's Loc-RIB.  If client C drops invalid
> prefixes, then the route server R has contributed to path hiding (see
> rfc7947).
> 
> In both these cases, and some other easily identifiable situations, the
> draft as stated contributes to topologically surprising results which
> wouldn't necessarily be what any of clients A, B or particularly C might
> expect or want.
> 
> There are two ways to fix this:
> 
> 1. either this draft should mandate that add-path must be used for tx
> from the point of view of the route server.  This is not operationally
> very useful because most clients and many route servers don't support
> ebgp add path, either due to policy or technical limitations.
> 
> 2. by far the easiest and best way to solve this particular problem
> would be for the IXP operator to allow the IXP participants to specify
> how to handle rpki-signed prefixes for their route server configs.  You
> would need two binary tickboxes in the IXP's provisioning system: drop
> or don't drop notfound, and drop or don't drop invalid.  I would assume
> that there's no requirement for the same sort of tickbox for valid
> prefixes.  If the IXP operator implemented this, then the Adj-RIB-In to
> Loc-RIB-out prefix filter would be able to make a decision about whether
> to accept or drop the RPKI notfound/invalid prefixes on a per client
> basis, which is what IXP route server client operators would want and
> expect.
> 
> Obviously, this is a local IXP provisioning system issue, and it would
> be up to the IXP as to how to implement it, i.e. allow the customer to
> modify this themselves using a portal, or raise a ticket with the IXP
> support desk.  Consequently, as this is not an problem which would be
> best solved by the IETF, I'd suggest it would be better for this draft
> not to progress further.
> 
> Nick
> 
> ___
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
> 


-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

___
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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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

2017-01-13 Thread 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