Hi, > -----Original Message----- > From: Dale W. Carder <dwcar...@es.net> > Sent: Tuesday, December 12, 2023 11:28 PM > To: gengnan <geng...@huawei.com> > Cc: Job Snijders <j...@fastly.com>; 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 +0000: > > 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
