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

Robert Raszuk <> Sun, 06 October 2019 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3C0E120811 for <>; Sun, 6 Oct 2019 13:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qy0SiRGNHAlw for <>; Sun, 6 Oct 2019 13:59:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7113512011D for <>; Sun, 6 Oct 2019 13:59:42 -0700 (PDT)
Received: by with SMTP id z67so10755315qkb.12 for <>; Sun, 06 Oct 2019 13:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=phc859bCMAy7/N0k74d62U2m+uprOzug+NculuPQVns=; b=dp9F+2dpWdFkr3e8/8Q+LP601ILg7pK0ARLlQ4rO2Uj7S05xCOBqThe9ymEaIkPC8n 9gWoPZaWF4SGBunzs5HUrWYCJBqYTOPz4L7lOI8+AaGw2bHxVMMbQjprMZvd89gGELYR kGDZdCth+iv6Ui/kg4z/3gB/BzbMdV64Rlx3/14mZLkt477dKtPPQccZN9dyZIMQwWzD oYTtLLlH2DceS77HlhF4VC6GJvFoKc1+57BfO7Yj7fLWctFUduLhRt3HayGWATsXfD2D CqlmNY8Q+fWhE6Sqm93enRROmSZL7bSiBoOaKR+1KNvLq+i9wLofWwhCm7YP16O5zah1 cZAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=phc859bCMAy7/N0k74d62U2m+uprOzug+NculuPQVns=; b=gNCQT5nyFLbgC74ivoz/HIsHwrXqvtYxNYCXA+JeoTAvEX7MiYVYQMXfM0dhuEalMW AX6NQmt6FhGv1IQ9iRN9MF42kbvyTusU2ODQpZTimgudMpOsOb1tivBhSvdD37+Pkifj QxqvtIR5vPzyyqbZy94OjHncbBVLmhdXPzC8g8wOZvdwd9QfvOdpN+kZXN0s4Qvbbrrf sbwyhMhSDLxPrrx04e2BwzF1NFiIm9PVzt5Is82cTLLUHZQ4bA499Ba7/UEgBfIum0hF 9XnGAEjr4Ocd4KErjtRVnoMgdwI9+/fd7H3yZh3t7ikoK7FENV+1xHnk3KdSAdFQbMXt bepw==
X-Gm-Message-State: APjAAAVn2kfShbElhYmtn21HIVL9JCjklMIhwX+eJYTrgaaec3kd48/l TuiIhj/aCNK/IC1+y70YhRfsgsxlFO7+j8rtDficiOX60tk=
X-Google-Smtp-Source: APXvYqyr2HUcvHha+rZbrE2JvSbdhDaUZEwUnjeauwNsRwUPoWDQExPq0vNrtDY+5qrDfN6Yoy3vcJnJt+LeNYkUNLg=
X-Received: by 2002:a37:8547:: with SMTP id h68mr19974892qkd.219.1570395581124; Sun, 06 Oct 2019 13:59:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sun, 06 Oct 2019 22:59:31 +0200
Message-ID: <>
To: Alexander Azimov <>
Cc: idr wg <>
Content-Type: multipart/alternative; boundary="000000000000c526c1059444361c"
Archived-At: <>
Subject: Re: [Idr] BGP Roles: Transition to Transit Attribute
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Oct 2019 20:59:53 -0000

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,

On Sun, Oct 6, 2019 at 10:40 PM Alexander Azimov <>

> 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
> _______________________________________________
> Idr mailing list