Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
I think you mean paths with valleys are all instances of unintended routing. Surely, that can be fixed: A provider can reject valleyed routes from a customer BY DEFAULT, but allow some through if so configured. The point is that such a valley attribute can provide good information to prevent the majority of route leaks without leaking customer relationship information. --Jakob. -Original Message- From: Geoff Huston [mailto:g...@apnic.net] Sent: Friday, November 22, 2013 3:21 PM To: Jakob Heitz Cc: Christopher Morrow; g...@ietf.org g...@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt If you are referring to the proposal that valley free paths are all instances of unintended routing, then as I recall there is a line of argument that says that some paths that contain valleys are intentional. On 23 Nov 2013, at 7:03 am, Jakob Heitz jakob.he...@ericsson.com wrote: Wasn't there once a proposal along the lines of: The originator adds a signed attribute that says this update is going up the chain. Each AS signs it before passing it on. When an AS sends the update down the chain, it removes the attribute. When an AS receives an update clearly from below, it checks for the presence of the attribute. What were the objections to this? --Jakob. -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Geoff Huston Sent: Friday, November 22, 2013 11:44 AM To: Christopher Morrow Cc: g...@ietf.org g...@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt On 23 Nov 2013, at 2:57 am, Christopher Morrow christopher.mor...@gmail.com wrote: On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston g...@apnic.net wrote: On 22 Nov 2013, at 3:43 pm, Christopher Morrow christopher.mor...@gmail.com wrote: On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston gih...@gmail.com wrote: but in our haste to comply with the timelines dictated by DHS's project funding I guess we've got what DHS were prepared to pay for, and not what we actually wanted or need. And for many its an unsatisfactory outcome. just asking about one part here... so DHS aside, because i'm not sure that who the funder is is relevant to the work, exactly... what options are there for securing more than the aspath? As I understand the draft correctly, the draft is saying even if you secure ASPATH along the lines proposed in secure BGP, there are still ways in which an attacker can inject a path that was not intended by the originator. inject a path... hrm, I'm not parsing that properly I bet. Did you mean prepend on random asns? (no, don't think so, not and stay validated) Did you mean pull a route down a customer link and pass it back up the hill to the other transit? (sure, but that's known, right?) Chris, you have READ the draft I assume? So the question that the draft raises in my head is is it possible to communicate routing policies in a secure manner? so far this keeps coming up and keeps ending in a deathspiral of: People don't want to share their byzantine routing policy stuff 'publicly' or: sure, you could make a global registry of routing policy... isn't rpsl that? and it's working out how well so far? I hear different responses in other parts of the network, where communities have invested significant levels of effort in publishing routing policies and attempting to compute across them. It seems to me that ensuring that the protocol operates correctly does not provide sufficient levels of assurance that a BGP speaker can reliably distinguish between routing information that is in some sense genuine and routing information that is intended to corrupt the speaker's forwarding state. Additionally, the draft in question here still doesn't say how you'd know 'thats a route leak' more than 1 as-hop away form the 'leak'. (it also doesn't take into account any of the comments I provided to the authors :( which is another matter entirely) so we get back to RPSL. maybe? though I'm not sure that it's any more helpful than just IRR based filtering with prefixes only and no policy-foo. I'm not sure its worth repeating the arguments that lead to the work in RPSL. Apparently, folk at the time who worked on RPSL held the belief that it was more helpful. People have to be willing to be pretty damned specific in their policy language there.. Is 702 going to publish that they are a transit of NTT in Japan? good question - the folk in Japan seem to have been one of the communities that invested heavily in populating a local route registry with current information. But its tue that in many communities a local route policy registry is variously populated with current and lapsed information, as well as large gaps. I think that the draft that triggered this interchange is spot on when it
Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
On Fri, Nov 22, 2013 at 6:40 PM, Jakob Heitz jakob.he...@ericsson.com wrote: I think you mean paths with valleys are all instances of unintended routing. Surely, that can be fixed: A provider can reject valleyed routes from a customer BY DEFAULT, but allow some through if so configured. The point is that such a valley attribute can provide good information to prevent the majority of route leaks without leaking customer relationship information. is this a default-on property? or do I configure bgp-peer-A as 'i am a customer' and peer-b as 'I am a transit'? what is the default expected value? how do I verify that the value is correct? or do I just trust the 3-as-hops away path I see? how is this better than today's: filter your routes situation? -Original Message- From: Geoff Huston [mailto:g...@apnic.net] Sent: Friday, November 22, 2013 3:21 PM To: Jakob Heitz Cc: Christopher Morrow; g...@ietf.org g...@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt If you are referring to the proposal that valley free paths are all instances of unintended routing, then as I recall there is a line of argument that says that some paths that contain valleys are intentional. On 23 Nov 2013, at 7:03 am, Jakob Heitz jakob.he...@ericsson.com wrote: Wasn't there once a proposal along the lines of: The originator adds a signed attribute that says this update is going up the chain. Each AS signs it before passing it on. When an AS sends the update down the chain, it removes the attribute. When an AS receives an update clearly from below, it checks for the presence of the attribute. What were the objections to this? --Jakob. -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Geoff Huston Sent: Friday, November 22, 2013 11:44 AM To: Christopher Morrow Cc: g...@ietf.org g...@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt On 23 Nov 2013, at 2:57 am, Christopher Morrow christopher.mor...@gmail.com wrote: On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston g...@apnic.net wrote: On 22 Nov 2013, at 3:43 pm, Christopher Morrow christopher.mor...@gmail.com wrote: On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston gih...@gmail.com wrote: but in our haste to comply with the timelines dictated by DHS's project funding I guess we've got what DHS were prepared to pay for, and not what we actually wanted or need. And for many its an unsatisfactory outcome. just asking about one part here... so DHS aside, because i'm not sure that who the funder is is relevant to the work, exactly... what options are there for securing more than the aspath? As I understand the draft correctly, the draft is saying even if you secure ASPATH along the lines proposed in secure BGP, there are still ways in which an attacker can inject a path that was not intended by the originator. inject a path... hrm, I'm not parsing that properly I bet. Did you mean prepend on random asns? (no, don't think so, not and stay validated) Did you mean pull a route down a customer link and pass it back up the hill to the other transit? (sure, but that's known, right?) Chris, you have READ the draft I assume? So the question that the draft raises in my head is is it possible to communicate routing policies in a secure manner? so far this keeps coming up and keeps ending in a deathspiral of: People don't want to share their byzantine routing policy stuff 'publicly' or: sure, you could make a global registry of routing policy... isn't rpsl that? and it's working out how well so far? I hear different responses in other parts of the network, where communities have invested significant levels of effort in publishing routing policies and attempting to compute across them. It seems to me that ensuring that the protocol operates correctly does not provide sufficient levels of assurance that a BGP speaker can reliably distinguish between routing information that is in some sense genuine and routing information that is intended to corrupt the speaker's forwarding state. Additionally, the draft in question here still doesn't say how you'd know 'thats a route leak' more than 1 as-hop away form the 'leak'. (it also doesn't take into account any of the comments I provided to the authors :( which is another matter entirely) so we get back to RPSL. maybe? though I'm not sure that it's any more helpful than just IRR based filtering with prefixes only and no policy-foo. I'm not sure its worth repeating the arguments that lead to the work in RPSL. Apparently, folk at the time who worked on RPSL held the belief that it was more helpful. People have to be willing to be pretty damned specific in their policy language there.. Is 702 going to publish that they are a transit of NTT in Japan? good question - the folk in Japan seem to have been
Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
On 23 Nov 2013, at 10:40 am, Jakob Heitz jakob.he...@ericsson.com wrote: I think you mean paths with valleys are all instances of unintended routing. sorry, yes, that is what I meant to say! :-) geoff ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
On 23 Nov 2013, at 1:17 pm, Geoff Huston g...@apnic.net wrote: On 23 Nov 2013, at 10:40 am, Jakob Heitz jakob.he...@ericsson.com wrote: I think you mean paths with valleys are all instances of unintended routing. sorry, yes, that is what I meant to say! :-) and lest this be misunderstood, then I said: but as I recall there is a line of argument that says that some paths that contain valleys are intentional. Geoff ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
is this a default-on property? or do I configure bgp-peer-A as 'i am a customer' and peer-b as 'I am a transit'? that can vary by prefix randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
