Subject: [OPSEC] [Opsec] RFC7454: clarification about AS-Path Filtering

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 12 May 2015 19:19:39 +0200

Hi,

I am reading this RFC and I have a question about this paragraph (p19,
Section 9):
"Network administrators SHOULD NOT advertise prefixes with a nonempty AS
path unless they intend to provide transit for these prefixes."

What about prefixes being originated by a network?

IMHO, if the announcements for such prefixes are compliant with this
requirement (i.e., AS path is empty as the prefixes are not transited but
originated), there should be an issue with the previous requirement:
"Network administrators SHOULD NOT accept prefixes when the first AS number
in the AS path is not the one of the peer's unless the peering is done
toward a BGP route server [17 <https://tools.ietf.org/html/rfc7454#ref-17>]
(for example, on an IXP) with transparent AS path handling. In that case,
this verification needs to be deactivated, as the first AS number will be
the one of an IXP member, whereas the peer AS number will be the one of the
BGP route server."

Am I wrong? Did I miss something?

Thanks in advance for your reply.

Best regards,

JMC.

---

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 12 May 2015 19:47:18 +0200

Hi Ivan,

Thanks for this (very) quick reply :)

But what happens regarding the inbound filters on the peer?
I mean, this peer knows that the local AS is not a transit provider for
these prefixes and so, it should wait for an empty AS path, no?

The sentence "Network administrators SHOULD NOT advertise prefixes with a
nonempty AS path unless either they intend to provide transit for these
prefixes or they are originated these prefixes." would not be simply more
correct?

Thanks again!

Best regards,

JMC.

2015-05-12 19:31 GMT+02:00 Ivan Pepelnjak <[email-masked]>:

> Local AS (the AS of the BGP speaker) is inserted in the BGP AS path
> attribute after the path has been filtered by the outgoing filters. The
> local filters will thus NOT see device’s own AS in the AS path, the
> neighbor receiving the update will.
>
> Hope this helps,
>
> Ivan Pepelnjak
> www.ipSpace.net <http://www.ipspace.net/> / blog.ipSpace.net
> <http://blog.ipspace.net/>
> Need a quick expert advice? Try ExpertExpress (
> www.ipspace.net/ExpertExpress)
>
> On 12 May 2015 at 19:19:44 , Jean-Michel Combes (
> [email-masked]) wrote:
>
>     Hi,
>
> "Network administrators SHOULD NOT accept prefixes when the first AS
> number in the AS path is not the one of the peer's unless the peering is
> done toward a BGP route server [17
> <https://tools.ietf.org/html/rfc7454#ref-17>] (for example, on an IXP)
> with transparent AS path handling. In that case, this verification needs to
> be deactivated, as the first AS number will be the one of an IXP member,
> whereas the peer AS number will be the one of the BGP route server."
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 May 2015 22:43:52 +0200

Hi,

> prefixes or they are originated these prefixes." would not be simply more

Advertising your own prefixes is actually matched by filtering on the
path ^$ in Cisco regex speak - read: "the empty path".

So, it is a slightly complicated way to formulate the thing, but it is
correct - a nonempty path means "transit for other ASes", and the empty
path is "yourself".  On outbound.

Your peer, on inbound, won't see an empty path of course.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279