Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

2023-12-12 Thread Dale W. Carder
Thus spake gengnan (gengnan=40huawei@dmarc.ietf.org) on Tue, Dec 12, 2023 
at 09:30:06AM +:
> Hi,
> 
> I support the adoption of the draft. Some comments that may need to be 
> considered: 
> 
> 1. The draft was proposed to GROW WG, but the wg info on the top of the first 
> page of the draft is opsec. 
> 
> 2. The meanings of "upstream" in this draft and the ASPA draft are different. 
> According to the term definition in this draft, the ASPA upstream 
> verification should be conducted for the routes from *downstream* or peer. 
> In section 3: "
> Upstream:
>   In a direct relationship between two ASes the one providing
>   upstream to the other.  (See: [RFC9234], also known as the
>   provider in a customer-provider relationship.)
> "
> In section 7.2.2: "
> In [I-D.ietf-sidrops-aspa-verification], see following sections based
>on the neighbor relationship:
> 
>*  Section 6.1 for routes received from upstreams and lateral peers.
> 
>*  Section 6.2 for routes received from downstreams and mutual-
>   transits.
> "
> 
> 3. The term "Mutual Upstream" is not used. It should be "mutual transit" or 
> "sibling". Also, some terms should be unified, e.g., "upstream" "upstream 
> provider"; "Internet peer" "lateral peer" "peer"; etc.
> 
> 4. In my understanding, some recommended operations have overlapped 
> protections/functions. For example, both OTC RFC 9234 and RPKI-ASPA can 
> detect route leaks. Should an operator deploy both techniques or just one of 
> them (under which conditions)?

Both!  See section 7.2 of draft-ietf-sidrops-aspa-verification

   While the ASPA-based AS_PATH verification method (Section 7.1)
   detects and mitigates route leaks that were created by preceding ASes
   listed in the AS_PATH, it lacks the ability to prevent route leaks
   from occuring at the local AS.  The use of the Only to Customer (OTC)
   Attribute [RFC9234] fills in that gap.


Dale

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


Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

2023-12-12 Thread gengnan
Hi,

I support the adoption of the draft. Some comments that may need to be 
considered: 

1. The draft was proposed to GROW WG, but the wg info on the top of the first 
page of the draft is opsec. 

2. The meanings of "upstream" in this draft and the ASPA draft are different. 
According to the term definition in this draft, the ASPA upstream verification 
should be conducted for the routes from *downstream* or peer. 
In section 3: "
Upstream:
  In a direct relationship between two ASes the one providing
  upstream to the other.  (See: [RFC9234], also known as the
  provider in a customer-provider relationship.)
"
In section 7.2.2: "
In [I-D.ietf-sidrops-aspa-verification], see following sections based
   on the neighbor relationship:

   *  Section 6.1 for routes received from upstreams and lateral peers.

   *  Section 6.2 for routes received from downstreams and mutual-
  transits.
"

3. The term "Mutual Upstream" is not used. It should be "mutual transit" or 
"sibling". Also, some terms should be unified, e.g., "upstream" "upstream 
provider"; "Internet peer" "lateral peer" "peer"; etc.

4. In my understanding, some recommended operations have overlapped 
protections/functions. For example, both OTC RFC 9234 and RPKI-ASPA can detect 
route leaks. Should an operator deploy both techniques or just one of them 
(under which conditions)?


Best,
Nan


> -Original Message-
> From: GROW  On Behalf Of Job Snijders
> Sent: Wednesday, December 6, 2023 11:45 PM
> To: grow@ietf.org
> Subject: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start
> 06/Dec/2023 end 06/Jan/2024)
> 
>  Wed, Dec 06, 2023 at 04:42:05PM +0100, Job Snijders wrote:
> Dear GROW,
> 
> The author of draft-fiebig-grow-bgpopsecupd asked whether the GROW
> working group could consider adoption of their internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: Updated BGP Operations and Security
> Abstract:
>   The Border Gateway Protocol (BGP) is the protocol almost exclusively
>   used in the Internet to exchange routing information between network
>   domains. Due to this central nature, it is important to understand the
>   security and reliability measures that can and should be deployed to
>   prevent accidental or intentional routing disturbances.
>   ... [abstract snipped for brevity] ...
> 
> This internet-draft aims to update RFC7454 / BCP 194.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-fiebig-grow-bgpopsecupd-00.html
> 
> Please share with the mailing list if you would like this work to be adopted 
> by
> GROW, are willing to review and/or otherwise contribute to this draft!
> 
> WG Adoption call ends January 6th, 2024.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs
> 
> ___
> 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