Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
[Job] >> Given the description: >> >>> "A multi-homed AS learns a route from one upstream ISP and announces >>> a subprefix (subsumed in the prefix) to another upstream ISP." >> >> I'd classify this type of announcement a "hijack" or "attack", not a route >> leak. [Chris] >this makes sense to me, this is the equivalent of several well known >instances of someone's 'internap' box leaking outside their span of >control. So, I agree this is a hijack, not a leak... though clearly >the subnets were 'leaked' outside the span of control, the effect is >really a hijack of the remote prefix. [Joel Jaeggli] >hijack is the practical result of the more specific. >intent is of course something else. Job and I discussed this in person, and as I understand he makes the following two important points regarding Type 5 (U-Turn with more specific) and why perhaps it should be omitted from the list of route-leak types: 1. In Type 5, the offending AS receives a less specific and crafts an update with a more specific (with AS path intact, Kapela-Pilosov style). The update with the more specific basically was never announced by a neighbor and was not there in the RIB. So it is a newly crafted update, and not a route leak as such. 2. The other instance of Type 5 was that the update with the more specific was there in the RIB but only for regional TE purpose, and was not meant to be announced via transit, but it was leaked. In this case, the leaked more specific route existed in the RIB, and was not crafted. The leak, however, can be thought of as a Type 1 (prefix) leak; no need to characterize it as a Type 5 (more specific). I am OK with Job’s line of reasoning. Hoping this is agreeable to others in the WG as well, I will proceed to update the draft to omit Type 5. However, if anyone feels there is some merit/rationale to keep Type 5, please speak up. Thanks. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
On 11/2/15 8:39 AM, Christopher Morrow wrote: > oh well, since this conversation got re-ingnited.. > > On Sat, Oct 31, 2015 at 1:15 AM, Job Snijders wrote: >> I think "type 5: U-Shaped Turn with More Specific Prefix" should be >> removed from the document. >> >> Given the description: >> >> "A multi-homed AS learns a route from one upstream ISP and announces >> a subprefix (subsumed in the prefix) to another upstream ISP." >> >> I'd classify this type of announcement a "hijack" or "attack", not a >> route leak. > > this makes sense to me, this is the equivalent of several well known > instances of someone's 'internap' box leaking outside their span of > control. So, I agree this is a hijack, not a leak... though clearly > the subnets were 'leaked' outside the span of control, the effect is > really a hijack of the remote prefix. hijack is the practical result of the more specific. intent is of course something else. > ___ > 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] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
oh well, since this conversation got re-ingnited.. On Sat, Oct 31, 2015 at 1:15 AM, Job Snijders wrote: > I think "type 5: U-Shaped Turn with More Specific Prefix" should be > removed from the document. > > Given the description: > > "A multi-homed AS learns a route from one upstream ISP and announces > a subprefix (subsumed in the prefix) to another upstream ISP." > > I'd classify this type of announcement a "hijack" or "attack", not a > route leak. this makes sense to me, this is the equivalent of several well known instances of someone's 'internap' box leaking outside their span of control. So, I agree this is a hijack, not a leak... though clearly the subnets were 'leaked' outside the span of control, the effect is really a hijack of the remote prefix. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
>There's seemingly 1 comment set not responded to on-list (job's last), >but overall support seems positive. I have just posted responses to Job's comments. >I'll ship a document shepherd >review northbound post-ietf-meeting week. Thank you. >by then sriram should have an updated revision with comments dealt >with as well I beleive? Yes, we can co-ordinate that. Thanks. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Job, Thanks for your comments. My responses below. >I think "type 5: U-Shaped Turn with More Specific Prefix" should be >removed from the document. >Given the description: >"A multi-homed AS learns a route from one upstream ISP and announces >a subprefix (subsumed in the prefix) to another upstream ISP." >I'd classify this type of announcement a "hijack" or "attack", not a >route leak. There are a few things to note here: * A route leak can be either accidental or attack (i.e. deliberate). (We have said earlier – may be 99% are accidental and 1% deliberate. see slide 13: https://www.ietf.org/proceedings/93/slides/slides-93-sidr-5.pdf ) * Type 1 (U-Shaped Turn with Full Prefix) can be a deliberate attack as well. * Type 5 is same as Type 1 except it has a more specific. In both cases, the update is “propagated” by offending AS with the AS path left intact (i.e. takes advantage of loop detection). A hijack (or accidental mis-origination) is different because there the offending AS removes the AS path in essence and “re-originates” (so data path to legitimate destination is not preserved in a hijack unlike Type 1 or Type 5). * If someone is being deliberate, they may prefer to use Type 5 over Type 1 because Type (with more specific) is far more effective. Please let me know if the above clarification helps. >Also, the two mentioned examples are at odds with each other, in the >first example an artificially crafted AS_PATH is used to exploit AS-PATH >loop detection, in the second example, the more specifics observed by >[Toonk2015-B] were more specifics not crafted by the offending ASN but >by peers of the offending ASN for traffic engineering purposes. Those >peers consciously deaggregated, assuming a limited, regionalized >visibility of said prefixes. The way I read [Toonk2015-B] is different. It says: “One explanation for this could be that these are more specific prefixes announced by peers of Telekom Malaysia to Telekom Malaysia and are normally supposed to stay regional and not visible via transit.” So the customers of Telekom Malaysia normally announce these more specifics to their transit but it is the transit Telekom Malaysia who is responsible to keep them regional but failed to do so. Let me know if you feel that is not the correct interpretation of [Toonk2015-B]. Thanks again. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Thinking about this a bit, I prefer "hairpin turn" over "U-turn". In my mind a "hairpin turn" is talking about a tight turn in a road and by necessity a tight turn for the traffic on the road, the road itself turns back on itself. Where as a "U-turn" talks about a tight turn traffic makes on road, usually to reverse direction on the road or where only the traffic is turning back on itself. Put another way, you can make a "U-turn" on a perfectly strait road, but you can't make a "hairpin turn" on a strait road. In the Internet we have a different term for a "U-turn", we generally call that a "loopback". Therefore I think "hairpin turn" is the most appropriate in this case, unless we really mean a "loopback". Whichever term we use, it should be clearly defined, it should be obvious at this point there is no clear unambiguous common understanding to rely on here. Thanks. -- === David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 === > On Nov 1, 2015, at 07:02, George, Wes wrote: > > I just went hunting for an instance of this in IETF land, and only found > references related to two hosts talking to one another from behind the > same NAT. > So, I went hunting on the internet, and everywhere I saw an explanation, > it was of the variant "going out the same interface it came in on" and > used U-turn synonymously. I was unable to find a reference to a definition > as I outlined below. That's not necessarily an issue but we may need to > explain the term before we use it so that there is no confusion. > > Thanks, > > Wes > > > On 10/31/15, 10:07 PM, "Sriram, Kotikalapudi" > wrote: > >> Wes, >> >> Thanks, Wes, for taking another look. >> And thanks for laying out some interesting (and entertaining) alternative >> names >> that can to used instead of "U-Turn". >> Like we discussed in the hallway this morning, it makes sense to use >> "Hairpin Turn" >> instead of "U-Turn", especially considering "Hairpin Turn" has been used >> in the VPN context. >> >> Sriram >> >> >> ________ >> From: George, Wes >> Sent: Friday, October 30, 2015 10:01 AM >> To: Sriram, Kotikalapudi >> Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; >> grow-...@tools.ietf.org >> Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >> (ends: 8/24/2015 - Aug 24) >> >> On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi" >> wrote: >> >> >> Sriram, this is significantly improved. One substantial comment that I >> still have with this version: >> >>>> It is also unclear from the text exactly what you mean by U-Turn >>>> (it's not going back the way it came, so actually hairpin might be a >>>> better term), >>>> so a few words to clarify might be useful. >>> >>> Hairpin seems to have a connotation that the turn is tight/constricted. >>> So now I use the phrase “U-shaped turn” instead of “U-turn”. >> >> WG] This may be nitpicking, but I don't think that adding "shaped" is >> actually much of an improvement. I was thinking of hairpin from the way >> that it is used in VPNs, as in data that enters and leaves the network via >> the same edge device, but typically on a different physical or logical >> interface (instead of entering on one PE and leaving via another), rather >> than the way that it is used on racetracks to describe a near 180 degree >> turn. >> Here are a few ideas I had of other ways to refer to this: >> >> - a "detour leak", in that traffic will be detouring through the leaking >> ASN >> - "ASN-in-the-middle leak" - similar to MiTM such that invoking the >> concept is useful, but it's necessary to disambiguate the two since the >> latter has a specific and well-known meaning >> - "parrotting leak" or "game of telephone leak" in that it is repeating >> something it learned elsewhere, but introducing a mistake, not unlike the >> grade school game of telephone (if you're up for a reference to The >> Simpsons, you could call it a "purple monkey dishwasher leak" but that >> would likely require too much expla
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
I just went hunting for an instance of this in IETF land, and only found references related to two hosts talking to one another from behind the same NAT. So, I went hunting on the internet, and everywhere I saw an explanation, it was of the variant "going out the same interface it came in on" and used U-turn synonymously. I was unable to find a reference to a definition as I outlined below. That's not necessarily an issue but we may need to explain the term before we use it so that there is no confusion. Thanks, Wes On 10/31/15, 10:07 PM, "Sriram, Kotikalapudi" wrote: >Wes, > >Thanks, Wes, for taking another look. >And thanks for laying out some interesting (and entertaining) alternative >names >that can to used instead of "U-Turn". >Like we discussed in the hallway this morning, it makes sense to use >"Hairpin Turn" >instead of "U-Turn", especially considering "Hairpin Turn" has been used >in the VPN context. > >Sriram > > > >From: George, Wes >Sent: Friday, October 30, 2015 10:01 AM >To: Sriram, Kotikalapudi >Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; >grow-...@tools.ietf.org >Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >(ends: 8/24/2015 - Aug 24) > >On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi" > wrote: > > >Sriram, this is significantly improved. One substantial comment that I >still have with this version: > >>>It is also unclear from the text exactly what you mean by U-Turn >>>(it's not going back the way it came, so actually hairpin might be a >>>better term), >>>so a few words to clarify might be useful. >> >>Hairpin seems to have a connotation that the turn is tight/constricted. >>So now I use the phrase “U-shaped turn” instead of “U-turn”. > >WG] This may be nitpicking, but I don't think that adding "shaped" is >actually much of an improvement. I was thinking of hairpin from the way >that it is used in VPNs, as in data that enters and leaves the network via >the same edge device, but typically on a different physical or logical >interface (instead of entering on one PE and leaving via another), rather >than the way that it is used on racetracks to describe a near 180 degree >turn. >Here are a few ideas I had of other ways to refer to this: > >- a "detour leak", in that traffic will be detouring through the leaking >ASN >- "ASN-in-the-middle leak" - similar to MiTM such that invoking the >concept is useful, but it's necessary to disambiguate the two since the >latter has a specific and well-known meaning >- "parrotting leak" or "game of telephone leak" in that it is repeating >something it learned elsewhere, but introducing a mistake, not unlike the >grade school game of telephone (if you're up for a reference to The >Simpsons, you could call it a "purple monkey dishwasher leak" but that >would likely require too much explanation ;-) ) >- "[accidental | unintentional] transit leak" since the net result of the >leak is that traffic will transit the leaking AS rather than its normal >path > > >Thanks, > >Wes > > >Anything below this line has been added by my company’s mail server, I >have no control over it. >--- > > > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
There's seemingly 1 comment set not responded to on-list (job's last), but overall support seems positive. I'll ship a document shepherd review northbound post-ietf-meeting week. by then sriram should have an updated revision with comments dealt with as well I beleive? On Sat, Oct 31, 2015 at 11:07 PM, Sriram, Kotikalapudi wrote: > Wes, > > Thanks, Wes, for taking another look. > And thanks for laying out some interesting (and entertaining) alternative > names > that can to used instead of "U-Turn". > Like we discussed in the hallway this morning, it makes sense to use "Hairpin > Turn" > instead of "U-Turn", especially considering "Hairpin Turn" has been used in > the VPN context. > > Sriram > > > > From: George, Wes > Sent: Friday, October 30, 2015 10:01 AM > To: Sriram, Kotikalapudi > Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org > Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition > (ends: 8/24/2015 - Aug 24) > > On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi" > wrote: > > > Sriram, this is significantly improved. One substantial comment that I > still have with this version: > >>>It is also unclear from the text exactly what you mean by U-Turn >>>(it's not going back the way it came, so actually hairpin might be a >>>better term), >>>so a few words to clarify might be useful. >> >>Hairpin seems to have a connotation that the turn is tight/constricted. >>So now I use the phrase “U-shaped turn” instead of “U-turn”. > > WG] This may be nitpicking, but I don't think that adding "shaped" is > actually much of an improvement. I was thinking of hairpin from the way > that it is used in VPNs, as in data that enters and leaves the network via > the same edge device, but typically on a different physical or logical > interface (instead of entering on one PE and leaving via another), rather > than the way that it is used on racetracks to describe a near 180 degree > turn. > Here are a few ideas I had of other ways to refer to this: > > - a "detour leak", in that traffic will be detouring through the leaking > ASN > - "ASN-in-the-middle leak" - similar to MiTM such that invoking the > concept is useful, but it's necessary to disambiguate the two since the > latter has a specific and well-known meaning > - "parrotting leak" or "game of telephone leak" in that it is repeating > something it learned elsewhere, but introducing a mistake, not unlike the > grade school game of telephone (if you're up for a reference to The > Simpsons, you could call it a "purple monkey dishwasher leak" but that > would likely require too much explanation ;-) ) > - "[accidental | unintentional] transit leak" since the net result of the > leak is that traffic will transit the leaking AS rather than its normal > path > > > Thanks, > > Wes > > > Anything below this line has been added by my company’s mail server, I > have no control over it. > --- > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Wes, Thanks, Wes, for taking another look. And thanks for laying out some interesting (and entertaining) alternative names that can to used instead of "U-Turn". Like we discussed in the hallway this morning, it makes sense to use "Hairpin Turn" instead of "U-Turn", especially considering "Hairpin Turn" has been used in the VPN context. Sriram From: George, Wes Sent: Friday, October 30, 2015 10:01 AM To: Sriram, Kotikalapudi Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24) On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi" wrote: Sriram, this is significantly improved. One substantial comment that I still have with this version: >>It is also unclear from the text exactly what you mean by U-Turn >>(it's not going back the way it came, so actually hairpin might be a >>better term), >>so a few words to clarify might be useful. > >Hairpin seems to have a connotation that the turn is tight/constricted. >So now I use the phrase “U-shaped turn” instead of “U-turn”. WG] This may be nitpicking, but I don't think that adding "shaped" is actually much of an improvement. I was thinking of hairpin from the way that it is used in VPNs, as in data that enters and leaves the network via the same edge device, but typically on a different physical or logical interface (instead of entering on one PE and leaving via another), rather than the way that it is used on racetracks to describe a near 180 degree turn. Here are a few ideas I had of other ways to refer to this: - a "detour leak", in that traffic will be detouring through the leaking ASN - "ASN-in-the-middle leak" - similar to MiTM such that invoking the concept is useful, but it's necessary to disambiguate the two since the latter has a specific and well-known meaning - "parrotting leak" or "game of telephone leak" in that it is repeating something it learned elsewhere, but introducing a mistake, not unlike the grade school game of telephone (if you're up for a reference to The Simpsons, you could call it a "purple monkey dishwasher leak" but that would likely require too much explanation ;-) ) - "[accidental | unintentional] transit leak" since the net result of the leak is that traffic will transit the leaking AS rather than its normal path Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. --- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Hi all, On Mon, Aug 10, 2015 at 01:29:41PM -0400, Christopher Morrow wrote: > Howdy grow folk, > please consider this a WGLC for: > draft-ietf-grow-route-leak-problem-definition > > Abstract: > "A systemic vulnerability of the Border Gateway Protocol routing >system, known as 'route leaks', has received significant attention in >recent years. Frequent incidents that result in significant >disruptions to Internet routing are labeled "route leaks", but to >date we have lacked a common definition of the term. In this >document, we provide a working definition of route leaks, keeping in >mind the real occurrences that have received significant attention. >Further, we attempt to enumerate (though not exhaustively) different >types of route leaks based on observed events on the Internet. We >aim to provide a taxonomy that covers several forms of route leaks >that have been observed and are of concern to Internet user community >as well as the network operator community." > > there have been 3 revisions of this document in the WG, along with 2 > prior to adoption. A new read-through of the document and comments > prior to sending this along to the IESG would be great! > > Let's get that done in the next 14 days and pass this up the chain for > further review/comment/process. I think "type 5: U-Shaped Turn with More Specific Prefix" should be removed from the document. Given the description: "A multi-homed AS learns a route from one upstream ISP and announces a subprefix (subsumed in the prefix) to another upstream ISP." I'd classify this type of announcement a "hijack" or "attack", not a route leak. Also, the two mentioned examples are at odds with each other, in the first example an artificially crafted AS_PATH is used to exploit AS-PATH loop detection, in the second example, the more specifics observed by [Toonk2015-B] were more specifics not crafted by the offending ASN but by peers of the offending ASN for traffic engineering purposes. Those peers consciously deaggregated, assuming a limited, regionalized visibility of said prefixes. Thoughts? Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
On 10/12/15, 11:40 PM, "Sriram, Kotikalapudi" wrote: Sriram, this is significantly improved. One substantial comment that I still have with this version: >>It is also unclear from the text exactly what you mean by U-Turn >>(it's not going back the way it came, so actually hairpin might be a >>better term), >>so a few words to clarify might be useful. > >Hairpin seems to have a connotation that the turn is tight/constricted. >So now I use the phrase “U-shaped turn” instead of “U-turn”. WG] This may be nitpicking, but I don't think that adding "shaped" is actually much of an improvement. I was thinking of hairpin from the way that it is used in VPNs, as in data that enters and leaves the network via the same edge device, but typically on a different physical or logical interface (instead of entering on one PE and leaving via another), rather than the way that it is used on racetracks to describe a near 180 degree turn. Here are a few ideas I had of other ways to refer to this: - a "detour leak", in that traffic will be detouring through the leaking ASN - "ASN-in-the-middle leak" - similar to MiTM such that invoking the concept is useful, but it's necessary to disambiguate the two since the latter has a specific and well-known meaning - "parrotting leak" or "game of telephone leak" in that it is repeating something it learned elsewhere, but introducing a mistake, not unlike the grade school game of telephone (if you're up for a reference to The Simpsons, you could call it a "purple monkey dishwasher leak" but that would likely require too much explanation ;-) ) - "[accidental | unintentional] transit leak" since the net result of the leak is that traffic will transit the leaking AS rather than its normal path Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. --- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Andrei, >I think that the document is ready to move forward. >My only comment is that it seems that cases 2&3 are sub-cases of 1 and >may also apply to 5,6,7 (i.e. specifics can also be announced in >"lateral" peering). Perhaps it is worth highlighting this fact for >completeness. Thank you for your suggestions and support. In the version-03 draft that was just submitted, I put in a new paragraph to incorporate your suggestion. Please see Section 4, second paragraph. Please note that the Types are now organized as subsections, and also reordered. So the Type numbers (#1 through #7) have been shuffled. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Charles, Thank you for your suggestions and support. Just submitted a version-03 draft in which your suggestions have been incorporated. >Seems like a good document, the only thing I noticed was some of the >citations have trailing slashes when not needed, leading to 404. >[Kapela-Pilosov] [Khare] [Mauch-nanog] for me at least. I have removed the trailing slashes. So the URLs should be good now. Just fyi – added a new reference -- [Anwar]. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Jeff, Thanks a lot for your comments and support. Just submitted a version-03 draft in which your suggestions/comments have been incorporated. Also, please see responses below. >Please consider updating the "replaces-by" for the draft to the original >draft-sriram... I think that is a comment for the chairs. >In general, this document is clear and very well written. It does an >excellent job at summarizing the landscape for route-leaks and provides lots >of citations (which I haven't validated for >correctness vs. the issues) for study. Thank you for the kind compliments. >The majority of my comments are minor terminology tweaks, some additional >explanations which might or might not be useful content and one discussion >point for re-organizing some of the types. >I'm supportive of this document moving forward even if my comments were not >immediately addressed. Thank you. Your comments have pretty much all been addressed in the revised -03 version just submitted. >In your section on "type 2", where you use the term "aggregates", consider >normalizing your terminology on "more specific" and "less specific" routes. >While aggregate is semantically clear in this section, aggregation is often >considered in the context of taking multiple more-specific prefixes and >generating a new, less specific prefix. Done. I now use the "more specifics / less specifics" terminology per your suggestion (avoided using "aggregates" where ever not relevant). >Type 3 attacks may also be called a "re-origination" attack. Consider >working that into the text, please. Done. >Similar to my comment on type 2, Type 4 is treating the matter as a >"de-aggregation" rather than simply announcing internal more specific >routes. Some of this is perspective, as seen by a receiver, but >understanding the issue is perhaps better done >from the perspective of the originator. Done. Changes made in the document accordingly. >One source of type 4 issues have included how some older vendor implementations >handled its configuration, leading to a trasient announcement of the more >specifics. A related one may be related to intentional generation of less >specifics from internal more specifics. In this case, routes contributing >to the aggregate are configured with policy that is intended to suppress >contributing routes, but such policy is only effective after the less >specific aggregate route is created; this creation may lag for various >implementation reasons. Thank you for sharing the insight. I understand it is not meant for making changes in the document. >Consider s/prefix-routes/routes/. The prefix- seems a bit redundant, at >least in a BGP routing context. The substitution has been made in the revised doc. >Types 5,6 and 7 are effectively forms of type 1. The only thing varying is >the *context* of the leaked route source AS and destination AS roles. >Perhaps it's worth considering re-grouping the four sections in a way that >highlights that? I have changed the Types list into Subsections (3.1. through 3.7) per Wes's suggestion. And then I reordered/regrouped those sections (Types) per your suggestion. Basically, I've put the types you noted above together (now they are Sections 3.1 through 3.4). Also, please see the related comment I have added in the 1st paragraph in Section 4. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Wes, >I've reviewed the latest version, and generally think that it is ready to >proceed once the below comments are addressed. Thank you for your comments and support. Just submitted a version-03 draft in which your suggestions/comments have been incorporated. Also, please see responses below. >There are several areas in Section 3 where you use attack and leak >interchangeably in a way that adds a bit of confusion. I think it'd be >better to pick one and stick with it, probably leak rather than attack, >and only use attack if you are describing something that is almost always >malicious rather than accidental. >I.e. >attack type 1 - "The update basically makes a >U-turn at the attacker's multi-homed AS. >The attack (accidental or deliberate) often succeeds" >Previously, you say that you refer to the leaking AS as the "offending >AS". I'd suggest using that here instead of "the attacker's". Done. Replaced “attacker” with “offending AS” in all places except where malicious intent involved. >Similarly, you've already said that most leaks are unintentional, so it might >be >better to simplify that next sentence by saying "the leak often succeeds" >and eliminate the parenthetical. Done. >It is also unclear from the text exactly what you mean by U-Turn >(it's not going back the way it came, so actually hairpin might be a better >term), >so a few words to clarify might be useful. Hairpin seems to have a connotation that the turn is tight/constricted. So now I use the phrase “U-shaped turn” instead of “U-turn”. >Type 2 - "Update is crafted by the attacker...success of the attack" - >same comment here about attack vs leak vs offending AS Done. Changes made in the new version per your suggestion. >Type 4 - While often the increase in prefixes causes its own problems >(dramatically increased routing table size, exceeded max prefix limit, >etc) you may want to add some text to the effect of "these more specifics >may cause the routes to be preferred over other aggregate announcements, >thus redirecting traffic from its normal best path" as that makes it >clearer what the impact of the leak is in this case. Done. I have added the wording that you have suggested above. >Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically >peering" really add a lot to the explanation. The rest of your text sounds >more like you're describing a non-transit relationship (typically only >announce their customer routes to each other), which I think would be an >easier term to define and more likely to be something readers would be >familiar with. Either way, the explanation in this section could benefit >from a good editing pass for clarity. I have put in a definition of "lateral" and clarified that it means the same as "non-transit". I have used both names where relevant, like, "lateral (i.e. non-transit)". >Type 6/7- "its provider" - do you mean its transit provider? Otherwise >it's unclear what distinguishes this from type 5, and again would be >useful to use transit/non-transit to clarify. I now use "transit provider" wherever I was using "provider" before. >Also, an editorial nit/personal preference: since there are so few >sections to this document, it might be useful to take each of the subtypes >and make it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's >easier to refer to it in text and reviews - subsections can have HTML >anchors so that you can link right to them, and they show up in the table >of contents as well. Good idea. Done. I have also re-ordered the seven subsections (3.1 through 3.7) in accordance with a suggestion from Jeff. Thanks again. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
On Mon, Aug 10, 2015 at 01:29:41PM -0400, Christopher Morrow wrote: > Howdy grow folk, > please consider this a WGLC for: > draft-ietf-grow-route-leak-problem-definition I'm late as usual. :-) Please consider updating the "replaces-by" for the draft to the original draft-sriram... In general, this document is clear and very well written. It does an excellent job at summarizing the landscape for route-leaks and provides lots of citations (which I haven't validated for correctness vs. the issues) for study. The majority of my comments are minor terminology tweaks, some additional explanations which might or might not be useful content and one discussion point for re-organizing some of the types. I'm supportive of this document moving forward even if my comments were not immediately addressed. In your section on "type 2", where you use the term "aggregates", consider normalizing your terminology on "more specific" and "less specific" routes. While aggregate is semantically clear in this section, aggregation is often considered in the context of taking multiple more-specific prefixes and generating a new, less specific prefix. Type 3 attacks may also be called a "re-origination" attack. Consider working that into the text, please. One potential source of type 3 attacks may occur when BGP routing information is redistributed into a non-BGP protocol and then later taken from that protocol and redistributed. E.g. BGP->OSPF->BGP. The wisdom of ever redistributing BGP into other protocols is left for a different rant. Similar to my comment on type 2, Type 4 is treating the matter as a "de-aggregation" rather than simply announcing internal more specific routes. Some of this is perspective, as seen by a receiver, but understanding the issue is perhaps better done from the perspective of the originator. One source of type 4 issues have included how some older vendor implementations handled its configuration, leading to a trasient announcement of the more specifics. A related one may be related to intentional generation of less specifics from internal more specifics. In this case, routes contributing to the aggregate are configured with policy that is intended to suppress contributing routes, but such policy is only effective after the less specific aggregate route is created; this creation may lag for various implementation reasons. Consider s/prefix-routes/routes/. The prefix- seems a bit redundant, at least in a BGP routing context. Types 5,6 and 7 are effectively forms of type 1. The only thing varying is the *context* of the leaked route source AS and destination AS roles. Perhaps it's worth considering re-grouping the four sections in a way that highlights that? -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Sue, Thank you. I welcome the cross-review, assuming GROW WG chairs are OK with it. Sriram >-Original Message- >From: Susan Hares [mailto:sha...@ndzh.com] >Sent: Tuesday, August 25, 2015 5:07 PM >To: Sriram, Kotikalapudi ; 'George, Wes' >; 'Christopher Morrow' >; grow-cha...@ietf.org; grow- >a...@tools.ietf.org; grow@ietf.org >Cc: 'John G. Scudder' >Subject: RE: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >(ends: 8/24/2015 - Aug 24) > >Siram: > >Do you want me to post this for a cross-review in IDR? > >Sue Hares > >-Original Message- >From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi >Sent: Tuesday, August 18, 2015 8:18 AM >To: George, Wes; Christopher Morrow; grow-cha...@ietf.org; >grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org >Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >(ends: 8/24/2015 - Aug 24) > >Thank you, Wes. >The comments you've offered are greatly helpful for improving accuracy as >well as clarity in what is being said. >I plan to incorporate them in the next revision (v. -03) soon. > >Sriram > >From: GROW on behalf of George, Wes > >Sent: Monday, August 17, 2015 2:45 PM >To: Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org; >grow@ietf.org grow@ietf.org >Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >(ends: 8/24/2015 - Aug 24) > >I've reviewed the latest version, and generally think that it is ready to >proceed once the below comments are addressed. A cross-review from IDR >might >also be useful before it goes to IETF LC. > >There are several areas in Section 3 where you use attack and leak >interchangeably in a way that adds a bit of confusion. I think it'd be >better to pick one and stick with it, probably leak rather than attack, and >only use attack if you are describing something that is almost always >malicious rather than accidental. >I.e. >attack type 1 - "The update basically makes a > U-turn at the attacker's multi-homed AS. The attack (accidental > or deliberate) often succeeds" >Previously, you say that you refer to the leaking AS as the "offending AS". >I'd suggest using that here instead of "the attacker's". Similarly, you've >already said that most leaks are unintentional, so it might be better to >simplify that next sentence by saying "the leak often succeeds" >and eliminate the parenthetical. It is also unclear from the text exactly >what you mean by U-Turn (it's not going back the way it came, so actually >hairpin might be a better term), so a few words to clarify might be useful. >Type 2 - "Update is crafted by the attacker...success of the attack" - same >comment here about attack vs leak vs offending AS > >Type 4 - While often the increase in prefixes causes its own problems >(dramatically increased routing table size, exceeded max prefix limit, >etc) you may want to add some text to the effect of "these more specifics >may cause the routes to be preferred over other aggregate announcements, >thus redirecting traffic from its normal best path" as that makes it clearer >what the impact of the leak is in this case. > >Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically >peering" really add a lot to the explanation. The rest of your text sounds >more like you're describing a non-transit relationship (typically only >announce their customer routes to each other), which I think would be an >easier term to define and more likely to be something readers would be >familiar with. Either way, the explanation in this section could benefit >from a good editing pass for clarity. > >Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's >unclear what distinguishes this from type 5, and again would be useful to >use transit/non-transit to clarify. > >Also, an editorial nit/personal preference: since there are so few sections >to this document, it might be useful to take each of the subtypes and make >it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to >refer to it in text and reviews - subsections can have HTML anchors so that >you can link right to them, and they show up in the table of contents as >well. > >Thanks, > >Wes > >___ >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] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
that seems like a good idea, thanks! On Tue, Aug 25, 2015 at 5:06 PM, Susan Hares wrote: > Siram: > > Do you want me to post this for a cross-review in IDR? > > Sue Hares > > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi > Sent: Tuesday, August 18, 2015 8:18 AM > To: George, Wes; Christopher Morrow; grow-cha...@ietf.org; > grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org > Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition > (ends: 8/24/2015 - Aug 24) > > Thank you, Wes. > The comments you've offered are greatly helpful for improving accuracy as > well as clarity in what is being said. > I plan to incorporate them in the next revision (v. -03) soon. > > Sriram > > From: GROW on behalf of George, Wes > > Sent: Monday, August 17, 2015 2:45 PM > To: Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org; > grow@ietf.org grow@ietf.org > Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition > (ends: 8/24/2015 - Aug 24) > > I've reviewed the latest version, and generally think that it is ready to > proceed once the below comments are addressed. A cross-review from IDR might > also be useful before it goes to IETF LC. > > There are several areas in Section 3 where you use attack and leak > interchangeably in a way that adds a bit of confusion. I think it'd be > better to pick one and stick with it, probably leak rather than attack, and > only use attack if you are describing something that is almost always > malicious rather than accidental. > I.e. > attack type 1 - "The update basically makes a > U-turn at the attacker's multi-homed AS. The attack (accidental > or deliberate) often succeeds" > Previously, you say that you refer to the leaking AS as the "offending AS". > I'd suggest using that here instead of "the attacker's". Similarly, you've > already said that most leaks are unintentional, so it might be better to > simplify that next sentence by saying "the leak often succeeds" > and eliminate the parenthetical. It is also unclear from the text exactly > what you mean by U-Turn (it's not going back the way it came, so actually > hairpin might be a better term), so a few words to clarify might be useful. > Type 2 - "Update is crafted by the attacker...success of the attack" - same > comment here about attack vs leak vs offending AS > > Type 4 - While often the increase in prefixes causes its own problems > (dramatically increased routing table size, exceeded max prefix limit, > etc) you may want to add some text to the effect of "these more specifics > may cause the routes to be preferred over other aggregate announcements, > thus redirecting traffic from its normal best path" as that makes it clearer > what the impact of the leak is in this case. > > Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically > peering" really add a lot to the explanation. The rest of your text sounds > more like you're describing a non-transit relationship (typically only > announce their customer routes to each other), which I think would be an > easier term to define and more likely to be something readers would be > familiar with. Either way, the explanation in this section could benefit > from a good editing pass for clarity. > > Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's > unclear what distinguishes this from type 5, and again would be useful to > use transit/non-transit to clarify. > > Also, an editorial nit/personal preference: since there are so few sections > to this document, it might be useful to take each of the subtypes and make > it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to > refer to it in text and reviews - subsections can have HTML anchors so that > you can link right to them, and they show up in the table of contents as > well. > > Thanks, > > Wes > > ___ > 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] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Siram: Do you want me to post this for a cross-review in IDR? Sue Hares -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi Sent: Tuesday, August 18, 2015 8:18 AM To: George, Wes; Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24) Thank you, Wes. The comments you've offered are greatly helpful for improving accuracy as well as clarity in what is being said. I plan to incorporate them in the next revision (v. -03) soon. Sriram From: GROW on behalf of George, Wes Sent: Monday, August 17, 2015 2:45 PM To: Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24) I've reviewed the latest version, and generally think that it is ready to proceed once the below comments are addressed. A cross-review from IDR might also be useful before it goes to IETF LC. There are several areas in Section 3 where you use attack and leak interchangeably in a way that adds a bit of confusion. I think it'd be better to pick one and stick with it, probably leak rather than attack, and only use attack if you are describing something that is almost always malicious rather than accidental. I.e. attack type 1 - "The update basically makes a U-turn at the attacker's multi-homed AS. The attack (accidental or deliberate) often succeeds" Previously, you say that you refer to the leaking AS as the "offending AS". I'd suggest using that here instead of "the attacker's". Similarly, you've already said that most leaks are unintentional, so it might be better to simplify that next sentence by saying "the leak often succeeds" and eliminate the parenthetical. It is also unclear from the text exactly what you mean by U-Turn (it's not going back the way it came, so actually hairpin might be a better term), so a few words to clarify might be useful. Type 2 - "Update is crafted by the attacker...success of the attack" - same comment here about attack vs leak vs offending AS Type 4 - While often the increase in prefixes causes its own problems (dramatically increased routing table size, exceeded max prefix limit, etc) you may want to add some text to the effect of "these more specifics may cause the routes to be preferred over other aggregate announcements, thus redirecting traffic from its normal best path" as that makes it clearer what the impact of the leak is in this case. Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically peering" really add a lot to the explanation. The rest of your text sounds more like you're describing a non-transit relationship (typically only announce their customer routes to each other), which I think would be an easier term to define and more likely to be something readers would be familiar with. Either way, the explanation in this section could benefit from a good editing pass for clarity. Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's unclear what distinguishes this from type 5, and again would be useful to use transit/non-transit to clarify. Also, an editorial nit/personal preference: since there are so few sections to this document, it might be useful to take each of the subtypes and make it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to refer to it in text and reviews - subsections can have HTML anchors so that you can link right to them, and they show up in the table of contents as well. Thanks, Wes ___ 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] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Thank you, Wes. The comments you've offered are greatly helpful for improving accuracy as well as clarity in what is being said. I plan to incorporate them in the next revision (v. -03) soon. Sriram From: GROW on behalf of George, Wes Sent: Monday, August 17, 2015 2:45 PM To: Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24) I've reviewed the latest version, and generally think that it is ready to proceed once the below comments are addressed. A cross-review from IDR might also be useful before it goes to IETF LC. There are several areas in Section 3 where you use attack and leak interchangeably in a way that adds a bit of confusion. I think it'd be better to pick one and stick with it, probably leak rather than attack, and only use attack if you are describing something that is almost always malicious rather than accidental. I.e. attack type 1 - "The update basically makes a U-turn at the attacker's multi-homed AS. The attack (accidental or deliberate) often succeeds" Previously, you say that you refer to the leaking AS as the "offending AS". I'd suggest using that here instead of "the attacker's". Similarly, you've already said that most leaks are unintentional, so it might be better to simplify that next sentence by saying "the leak often succeeds" and eliminate the parenthetical. It is also unclear from the text exactly what you mean by U-Turn (it's not going back the way it came, so actually hairpin might be a better term), so a few words to clarify might be useful. Type 2 - "Update is crafted by the attacker...success of the attack" - same comment here about attack vs leak vs offending AS Type 4 - While often the increase in prefixes causes its own problems (dramatically increased routing table size, exceeded max prefix limit, etc) you may want to add some text to the effect of "these more specifics may cause the routes to be preferred over other aggregate announcements, thus redirecting traffic from its normal best path" as that makes it clearer what the impact of the leak is in this case. Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically peering" really add a lot to the explanation. The rest of your text sounds more like you're describing a non-transit relationship (typically only announce their customer routes to each other), which I think would be an easier term to define and more likely to be something readers would be familiar with. Either way, the explanation in this section could benefit from a good editing pass for clarity. Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's unclear what distinguishes this from type 5, and again would be useful to use transit/non-transit to clarify. Also, an editorial nit/personal preference: since there are so few sections to this document, it might be useful to take each of the subtypes and make it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to refer to it in text and reviews - subsections can have HTML anchors so that you can link right to them, and they show up in the table of contents as well. Thanks, Wes ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
I've reviewed the latest version, and generally think that it is ready to proceed once the below comments are addressed. A cross-review from IDR might also be useful before it goes to IETF LC. There are several areas in Section 3 where you use attack and leak interchangeably in a way that adds a bit of confusion. I think it'd be better to pick one and stick with it, probably leak rather than attack, and only use attack if you are describing something that is almost always malicious rather than accidental. I.e. attack type 1 - "The update basically makes a U-turn at the attacker's multi-homed AS. The attack (accidental or deliberate) often succeeds" Previously, you say that you refer to the leaking AS as the "offending AS". I'd suggest using that here instead of "the attacker's". Similarly, you've already said that most leaks are unintentional, so it might be better to simplify that next sentence by saying "the leak often succeeds" and eliminate the parenthetical. It is also unclear from the text exactly what you mean by U-Turn (it's not going back the way it came, so actually hairpin might be a better term), so a few words to clarify might be useful. Type 2 - "Update is crafted by the attacker...success of the attack" - same comment here about attack vs leak vs offending AS Type 4 - While often the increase in prefixes causes its own problems (dramatically increased routing table size, exceeded max prefix limit, etc) you may want to add some text to the effect of "these more specifics may cause the routes to be preferred over other aggregate announcements, thus redirecting traffic from its normal best path" as that makes it clearer what the impact of the leak is in this case. Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically peering" really add a lot to the explanation. The rest of your text sounds more like you're describing a non-transit relationship (typically only announce their customer routes to each other), which I think would be an easier term to define and more likely to be something readers would be familiar with. Either way, the explanation in this section could benefit from a good editing pass for clarity. Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's unclear what distinguishes this from type 5, and again would be useful to use transit/non-transit to clarify. Also, an editorial nit/personal preference: since there are so few sections to this document, it might be useful to take each of the subtypes and make it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to refer to it in text and reviews - subsections can have HTML anchors so that you can link right to them, and they show up in the table of contents as well. Thanks, Wes On 8/10/15, 1:29 PM, "GROW on behalf of Christopher Morrow" wrote: >Howdy grow folk, >please consider this a WGLC for: > draft-ietf-grow-route-leak-problem-definition > >Abstract: > "A systemic vulnerability of the Border Gateway Protocol routing > system, known as 'route leaks', has received significant attention in > recent years. Frequent incidents that result in significant > disruptions to Internet routing are labeled "route leaks", but to > date we have lacked a common definition of the term. In this > document, we provide a working definition of route leaks, keeping in > mind the real occurrences that have received significant attention. > Further, we attempt to enumerate (though not exhaustively) different > types of route leaks based on observed events on the Internet. We > aim to provide a taxonomy that covers several forms of route leaks > that have been observed and are of concern to Internet user community > as well as the network operator community." > >there have been 3 revisions of this document in the WG, along with 2 >prior to adoption. A new read-through of the document and comments >prior to sending this along to the IESG would be great! > >Let's get that done in the next 14 days and pass this up the chain for >further review/comment/process. > >thanks! >-chris >(grow-co-chair) > >___ >GROW mailing list >GROW@ietf.org >https://www.ietf.org/mailman/listinfo/grow This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _
[GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)
Howdy grow folk, please consider this a WGLC for: draft-ietf-grow-route-leak-problem-definition Abstract: "A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date we have lacked a common definition of the term. In this document, we provide a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, we attempt to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. We aim to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community." there have been 3 revisions of this document in the WG, along with 2 prior to adoption. A new read-through of the document and comments prior to sending this along to the IESG would be great! Let's get that done in the next 14 days and pass this up the chain for further review/comment/process. thanks! -chris (grow-co-chair) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
