Subject: [Idr] BGP Roles: Transition to Transit Attribute

From: Alexander Azimov <[email-masked]>
Date: Sun, 6 Oct 2019 23:39:41 +0300

Dear WG,

As you might be aware, in the last version of the draft non-transit iOTC
attribute was transformed into transit OTC, which covers both inner leak
prevention and external leak detection. The authors believe that this way
it will provide a complete solution, which will supplement other works in
the field of securing BGP: ASPA and community-based leak detection.

I want to believe that the draft is ready but there is an issue that should
be resolved before WGLC. The code point was reserved by IANA to iOTC
(Internal Only To Customer). I'd like to ask what is the proper process to
reuse this code point for OTC. At the moment there are already two
compatible implementations and another two are in progress.

-- 
Best regards,
Alexander Azimov

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Oct 2019 22:59:31 +0200

Hi Alexander,

I am assuming you mean "transitive" not "transit".

Still I have few main observations/questions:

A) How do you prevent spoofing (on purpose or by accident) content of this
attribute ? You you still need to validate by local policy check does it
really make sense to send this from the peer ?

B) Draft says:

   As opposed to communities, BGP attributes may not be generally
   modified or filtered by the operator.  The router(s) enforce them.
   This is the desired property for the OTC marking.  Hence, this
   document specifies OTC as an attribute.

Well take any attribute .. you can modify most of them with fancy policy
language. Even critical attributes like AS_PATH can be altered at will in
transit by most popular BGP implementations. So I guess if you count on
this one to be immutable make it clearly so as MUST in the draft.

C) How do you plan to handle aggregation of prefixes with different OTCs ?

Many thx,
R.

On Sun, Oct 6, 2019 at 10:40 PM Alexander Azimov <[email-masked]>
wrote:

> I want to believe that the draft is ready but there is an issue that
> should be resolved before WGLC. The code point was reserved by IANA to iOTC
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Alexander Azimov <[email-masked]>
Date: Sat, 12 Oct 2019 23:46:14 +0300

Hi Robert,

Please see my comments below.

> I am assuming you mean "transitive" not "transit".
Yes, it was a typo.

> really make sense to send this from the peer ?
I might not be getting your point. At the receiver side, you can't check
the correctness of the policy several (or even one) hops away. The
attribute limits the way the route is propagated, so I don't see how it can
be maliciously abused. And the roles that are described in the draft should
significantly limit the number of mistakes during configuration.

> this one to be immutable make it clearly so as MUST in the draft.
Of course, the attribute is not immutable, but the way BGP implementations
should treat unknown attributes should make it more reliable compared to
the community.

> C) How do you plan to handle aggregation of prefixes with different OTCs ?
Since normally you are aggregating customer routes, and the draft says that
if you are receiving route with OTC attribute set from customer it MUST be
rejected. So I don't see scenario when we need to aggregate such routes.