+1 |I thought I covered this (a few times?) on the list discussion of the |reqs-00 draft, but I'd like to know if an update I see from a peer, if |selected, is one in which a party altered the as-path in order to draw |traffic to them. It's possible this happens for any number of reasons, |the simplest (and easiest to point to being 'bad') is: | <http://www.wired.com/threatlevel/2008/08/how-to-intercep/> | |In this case, with signing of the path at each path-hop you would be |able to determine if the route announcement should be used or not |(presuming a 'secure is better' policy, of course).
In my opinion, origin validation only catches a small number of "bad" routing information. Additionally this "bad" routing information is typically the type created by fat fingering, and I would argue is the easiest to detect and get fixed. Anyone who is manipulating routing for nefarious purposes can avoid being caught by origin validation. These cases are more frequent, harder to detect, and more difficult to get resolved. If there is any value in securing inter-domain routing it has to validate the AS path. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schil...@uu.net UUNET / Verizon jason.schil...@verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Fri, 18 Feb 2011, Christopher Morrow wrote: |Date: Fri, 18 Feb 2011 12:30:57 -0500 |From: Christopher Morrow <christopher.mor...@gmail.com> |To: Russ White <r...@cisco.com> |Cc: sidr-cha...@ietf.org, Adrian Farrel <adrian.far...@huawei.com>, | sidr@ietf.org |Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work | |On Fri, Feb 18, 2011 at 11:35 AM, Russ White <r...@cisco.com> wrote: |> |>> * Is an Autonomous System (AS) authorized to originate an IP prefix |>> * Is the AS-Path represented in the route the same as the path |>> through which the route update traveled |> |> As we've been discussing on the list --I don't think this is a good |> goal. The first goal should be to determine what it is we want to show | |'this' refers to which of the two items above? | |> about the AS Path in relation to other things, and then work on filling |> that goal. | |I thought I covered this (a few times?) on the list discussion of the |reqs-00 draft, but I'd like to know if an update I see from a peer, if |selected, is one in which a party altered the as-path in order to draw |traffic to them. It's possible this happens for any number of reasons, |the simplest (and easiest to point to being 'bad') is: | <http://www.wired.com/threatlevel/2008/08/how-to-intercep/> | |In this case, with signing of the path at each path-hop you would be |able to determine if the route announcement should be used or not |(presuming a 'secure is better' policy, of course). | |> Starting with the assumption that proving an update travels a specific |> path seems, to me, to be going about things the wrong way. | |propose text then? dancing around the rosemary bush is tiring, given |the ideas expressed here and in the other thread you should have an |idea of what the goal is, propose some text that you think moves the |ball in the right direction, please. | |-chris |_______________________________________________ |sidr mailing list |sidr@ietf.org |https://www.ietf.org/mailman/listinfo/sidr |
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
