Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Chris,

Please see inline.

-Original Message-
From: Christopher Morrow [mailto:christopher.mor...@gmail.com] 
Sent: Friday, March 22, 2019 4:28 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: Robert Raszuk ; grow@ietf.org
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

On Mon, Mar 18, 2019 at 3:21 AM Guyunan (Yunan Gu, IP Technology Research Dept. 
NW)  wrote:
>
>
>
>
>
> From: Robert Raszuk [mailto:rob...@raszuk.net]
> Sent: Monday, March 18, 2019 6:05 PM
> To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
> 
> Cc: grow@ietf.org; Brian Dickson 
> Subject: Re: [GROW] I-D Action: 
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
>
>
> > In the BGP Update received from the eBGP peer, the eBGP peer has 
> > already placed the local AS number in the
>
> > AS-PATH. Thus, the device needs to analyze if the local AS is placed 
> > improperly in the AS-PATH when it receives
>
> > the Update.
>
>
>
> How is this different from basic AS-PATH loop detection done by any real BGP 
> speaker today ?
>
>
>
> Yunan: To the best of my knowledge, currently when an as loop is detected, 
> the message is simply dropped without further analysis. If using the proposed 
> inbound check, possible hijack can be detected.
>

this is what BMP is for, it'll send along pre-policy content which would 
include this route.
(I believe it would also be fine to use BMP to detect the outbound case you 
chatted with Robert about already)


Yunan: Per the current definitions in draft-ietf-grow-bmp-adj-rib-out-03:

5.1 Post-Policy: "...Adj-RIB-Out Post-Policy MUST convey what is actually 
transmitted to the peer, next-hop and any attribute set during transmission 
should also be set and transmitted to the BMP receiver..."
5.2 Pre-Policy: "... Depending on BGP peering session type (IBGP, IBGP route 
reflector client, EBGP, BGP confederations, Route Server Client) the candidate 
routes that make up the Pre-Policy Adj-RIB-Out do not contain all local-rib 
routes. Pre-Policy Adj-RIB-Out conveys only routes that are available based on 
the peering type. Post-Policy represents the filtered/changed routes from the 
available routes ..."

In the case that eBGP as split-horizon is enabled, this detected route can be 
reported through pre-policy adj-rib-out, but not post-policy adj-rib-out (since 
it's not allowed to be advertised).
In the case that eBGP as split-horizon is not enabled, then both pre/post 
policy adj-rib-out contains this route.  

It's actually a very good suggestion of using BMP server to do such analysis. 
In fact we have also thought about this option previously. We can add this in 
the new version.   


-chris
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Christopher Morrow]

On Mon, Mar 18, 2019 at 3:21 AM Guyunan (Yunan Gu, IP Technology
Research Dept. NW)  wrote:
>
>
>
>
>
> From: Robert Raszuk [mailto:rob...@raszuk.net]
> Sent: Monday, March 18, 2019 6:05 PM
> To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
> Cc: grow@ietf.org; Brian Dickson 
> Subject: Re: [GROW] I-D Action: 
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
>
>
> > In the BGP Update received from the eBGP peer, the eBGP peer has already 
> > placed the local AS number in the
>
> > AS-PATH. Thus, the device needs to analyze if the local AS is placed 
> > improperly in the AS-PATH when it receives
>
> > the Update.
>
>
>
> How is this different from basic AS-PATH loop detection done by any real BGP 
> speaker today ?
>
>
>
> Yunan: To the best of my knowledge, currently when an as loop is detected, 
> the message is simply dropped without further analysis. If using the proposed 
> inbound check, possible hijack can be detected.
>

this is what BMP is for, it'll send along pre-policy content which
would include this route.
(I believe it would also be fine to use BMP to detect the outbound
case you chatted with Robert about already)

-chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Jeffrey Haas]

On Thu, Mar 21, 2019 at 11:57:00AM +, Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) wrote:
> 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.

You are pleasantly optimistic about how this sort of scenario usually
resolves.

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

Such a section would be reasonable for your proposal.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

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

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Warren Kumari]

On Thu, Mar 21, 2019 at 12:59 AM Jeffrey Haas  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
> 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