Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)
Dear Working Group, Thank you all for your comments and feedback. The draft-fiebig-grow-bgpopsecupd document has been adopted by the GROW working group. Tobias, please re-submit as 'draft-ietf-grow-bgpopsecupd-00' Kind regards, Job GROW co-chair On Wed, Dec 06, 2023 at 04:45:20PM +0100, Job Snijders wrote: > 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
Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)
Hello, On 06/12/2023 16:45, Job Snijders wrote: 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. RFC7454 could certainly use a refresher. I support adoption. Kind regards, Martin ___ 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)
Hi, > -Original Message- > From: Dale W. Carder > Sent: Tuesday, December 12, 2023 11:28 PM > To: gengnan > Cc: Job Snijders ; grow@ietf.org > Subject: Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd > (start 06/Dec/2023 end 06/Jan/2024) > > 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. > Thanks. I'd like to say (out of the scope of the draft): it would be better if one kind of problems can be solved by one technique. But here it seems that two techniques are needed for complete protection. > > 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)
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)
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
Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)
> The author of draft-fiebig-grow-bgpopsecupd asked whether the > GROW working group could consider adoption of their internet-draft. imiho, not only should we consider adopting it, but we should adopt it :) i have quibbles, of course, but it would be useful randy ___ 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)
Wed, Dec 06, 2023 at 11:05:41AM -0500, Jeffrey Haas: > On Dec 6, 2023, at 10:45 AM, Job Snijders > wrote: > > 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 > > I support adoption of this work. support. ___ 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)
On Dec 6, 2023, at 10:45 AM, Job Snijders wrote: > 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 I support adoption of this work. -- Jeff ___ 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)
Hi, On Wed, Dec 06, 2023 at 04:45:20PM +0100, Job Snijders wrote: > 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. Support, as one of the authors of 7454. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[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
