[Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/

[Alvaro Retana <[e-mail]>]

Hi!

I support this document moving forward.  It is time to
proscribe/deprecate/prohibit the use of AS_SETs and AS_CONFED_SETs.  Their
use is low and the advantage of this action facilitates the deployment of
BGP security mechanisms.

However, the intent to proscribe/deprecate/prohibit doesn not match the
text.  From §3:

153   BGP speakers conforming to this document (i.e., conformant BGP
154   speakers) SHOULD NOT locally generate BGP UPDATE messages containing
155   AS_SETs or AS_CONFED_SETs.  Conformant BGP speakers SHOULD NOT send
156   BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs.  Upon
157   receipt of such messages, conformant BGP speakers SHOULD use the
158   "treat-as-withdraw" error handling behavior as per [RFC7606].

160   The document uses normative language such as "SHOULD NOT send" rather
161   than "MUST NOT send" with the intention of allowing some transition
162   time for existing implementations and avoiding abrupt disruptions for
163   the operators currently using AS_SETs or AS_CONFED_SETs.  However, it
164   is strongly urged that operators stop sending UPDATEs with AS_SETs or
165   AS_CONFED_SETs as quickly as possible to avoid having UPDATEs dropped
166   by BGP security mechanisms such as RPKI-ROV and BGPsec.

Regardless of the text in an RFC, the transition won't be immediate.  I
don't agree with the use of "SHOULD NOT" with the explicit intent "of
allowing some transition time".  Using this language provides a hole that
allows conformant implementations to continue to use AS_SETs or
AS_CONFED_SET indefinitely.

Also, the Introduction mentions that "aggregation that involves AS_SETs is
very seldom used", so the impact would be minimum.

I haven't been following the discussions about this document in detail, so
my point may have already been addressed on the list.  If that is the case,
I will stand in the rough.


I included other comments below.

Thanks!

Alvaro.


[Line numbers from idnits.]

...
151 3.  Recommendations
...
168   If a network operator wishes to consider BGP UPDATE messages with
169   AS_SETs or AS_CONFED_SETs received from an external BGP peers, they
170   MAY have a feature (knob) in their implementation to do so on a per-
171   peer basis.  The operator should understand the full implications of
172   choosing this option.

"network operator...MAY have a feature"

The action is not for the network operators, but for the implementation.

Suggestion>

   An implementation MAY include the ability to consider BGP UPDATE
   messages with AS_SETs or AS_CONFED_SETs received from external BGP
   peers on a per-peer basis.  Network operators should understand
   the full implications of choosing this option.



174   Network operators SHOULD NOT locally generate any new announcements
175   containing AS_SETs or AS_CONFED_SETs.

This text is a duplicate of the text in the first paragraph of this section.



177   BGP security technologies (such as those that take advantage of X.509
178   extensions for IP addresses and AS identifiers ([RFC3779], [RFC6480],
179   [RFC6811], [RFC8205]) might not support routes with AS_SETs or
180   AS_CONFED_SETs in them.  Routes with AS_SETs have no possibility of
181   ever being considered RPKI-ROV valid [RFC6811] [RFC6907].

BGPSec also doesn't support the AS_SET (not "might not").



183 4.  Updates to Existing RFCs

Except for these first 3 paragraphs, none of the subsections (4.*) contain
any Updates to Existing RFCs.

185   This document deprecates the origination of BGP routes with AS_SET
186   (type 1) (see [RFC4271], Section 4.3).

188   This document also deprecates the origination of BGP routes with
189   AS_CONFED_SET (type 4) AS_PATH segments (see [RFC5065], Section 3).

191   BGP speakers conforming to this document — i.e., conformant BGP
192   speakers — SHOULD NOT originate BGP UPDATE messages containing
193   AS_SETs or AS_CONFED_SETs.  Upon receipt of BGP routes containing
194   AS_SETs, conformant BGP speakers SHOULD use the "treat-as-withdraw"
195   error handling behavior as per [RFC7606].

This is the same text that is in §3.  Keep the specification in one place:
it is easy for maintenance of the document, it avoids potential conflict,
getting out of sync, etc.



...
232 4.2.  Issues with "Brief" AS_PATH Aggregation and RPKI-ROV
...
245   *  In the presence of such varying origin ASes, it would be necessary
246      for the resource holder to register Route Origin Authorizations
247      (ROAs) [RFC6482] for each potential origin AS that may result from
248      the expected aggregated AS_PATHs.

RFC6482 is Obsolete; use RFC9582 instead.



250 4.3.  Recommendations to Mitigate Unpredictable AS_PATH Origins for
251      RPKI-ROV Purposes

253   In order to ensure a consistent BGP origin AS is announced for
254   aggregate BGP routes for implementations of "brief" BGP aggregation,
255   the implementation should be configured to truncate the AS_PATH after
256   the right-most instance of the desired origin AS for the aggregate.
257   The desired origin AS could be the aggregating AS itself.

Should there be Normative language in this paragraph?

The obvious place seems to be s/implementation should be configured to
truncate/implementation SHOULD be configured to truncate   But, should that
be a "MUST" instead?  If the aggregation is to be "consistent", then the
operation should be REQUIRED and not just RECOMMENDED.



...
268 4.4.  Interactions with Four-octet AS Numbers

270   [RFC4893] created support for four-octet AS numbers in BGP.  A BGP
271   speaker not supporting four-octet AS numbers, termed an "OLD speaker"
272   in that document, might have routes that carry the AS4_PATH Path
273   Attribute.  This attribute is used to carry four-octet AS paths
274   across OLD speakers and may contain AS_PATH segments of type AS_SET.

RFC4893 is Obsolete; use RFC6793 instead.



276   BGP speakers conforming to this specification MUST NOT use the
277   information contained in the AS4_PATH for treat-as-withdraw purposes.
278   Instead, only the AS_PATH should be used.

I'm assuming that this reference to "treat-as-withdraw purposes" refers to
the specification in §3.

If so, it might be helpful to add to the specification in §3 the fact that
the receive part only applies to the AS_PATH.  Suggestion> s/Upon receipt
of such messages.../Upon receipt of such messages in the AS_PATH...



...
370 9.2.  Informative References
...
413   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
414              Patel, "Revised Error Handling for BGP UPDATE Messages",
415              RFC 7606, DOI 10.17487/RFC7606, August 2015,
416              <https://www.rfc-editor.org/info/rfc7606>.

This reference should be Normative: it is used to specify an action in §3.



418   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
419              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
420              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

This reference should be Normative.

[EoR-14]


On July 8, 2024 at 9:36:48 PM, Susan Hares ([e-mail]) wrote:

This begins a 2 week WG LC for

draft-ietf-idr-deprecate-as-set-confed-set-14.txt

https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/



All authors should respond to this email with an IPR statement.



Here is a short summary of why this document is:



   BCP 172 (i.e., RFC 6472) recommends not using AS_SET and

   AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol

   (BGP).  This document advances that recommendation to a standards

   requirement in BGP; it proscribes the use of the AS_SET and

   AS_CONFED_SET path segment types in the AS_PATH.



FYI the verb proscribe means:

   1. forbid, especially by law.
   2. denounce or condemn.



It is a complex English word, but it fits the document.

One similar word is “prohibit”.



Questions to consider in your comments:



   1. Is now the time to proscribe AS_SETs and

AS-CONF_SET path segments types in AS_PATH?



   2. Is the document clear and ready for standardization?



    Both Keyur and I wrote shepherd reports,

    so we’ll post a joint shepherd report.



    Our comments focus on the clarity of the document.



   3. Does this help BGP security in the network?





Cheers, Sue






_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]