Hi Jeffrey and Warren, Thanks for the suggestions on the “type X” usage. We’ll try better expressions in the new version.
Jeffrey, We’ll also fix the ASN usage issue. For the case you mentioned, it’s actually an interesting example of forging AS-PATH out of “good” intention, which does not belong to misconfiguration or attack. In fact, it suggests that should be enhanced inbound check/analysis instead of simply dropping the route. Operators can take actions based on the analysis and combined with other information. For example, AS65535 may contact AS64512 for further information, and work on the DDOS attack together. Inspired by that, we think adding “suggested actions” to each categorized “result type” can be useful for understanding how the proposed inbound/outbound enhancement works. We’ll update the draft with the above considerations. BR, Yunan From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Warren Kumari Sent: Thursday, March 21, 2019 4:15 PM To: Jeffrey Haas <jh...@pfrc.org> Cc: grow@ietf.org grow@ietf.org <grow@ietf.org> Subject: Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00 On Thu, Mar 21, 2019 at 12:59 AM Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote: Authors, Some various comments on the draft in no particular order: - Consider using the document ASes from the reserved ranges; i.e. RFC 5398 - Construct a unified table of the "results" and a short term for their meaning. One of my least favorite thing in RFCs that tend to be placed into code is calling something a "type X". It leads to rather confusing conversations unless you're a protocol expert. Case in point -- one of my "favorite" RFCs -- RFC7281 - Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) Basically, we realized that arguing whether users should publish TLSA records of type 3, selector 1, matching 1, or 3, 0, 1 or ... is super-unhelpful, but recommending DANE-TA, SPKI, SHA2-256 is much simpler. W A final comment is another infrequent case a provider's AS may end up in the AS-Path: Intentionally forcing that provider to discard a route *you* own. Consider the case where AS 64512 owns 192.0.2/24. AS 64512 is under a heavy DDoS attack that is substantially originated from AS 65535. By prepending 65535 to the AS-Path upon origination, 65535 will lose the route to 192.0.2/24 and, if default-free, much of the attack traffic goes away. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
