Hi Andrei,

Thank you for your explanation, I have read it https://www.rfc-editor.org/rfc/rfc2622#section-5.
I was a little busy the other week, so I can only respond now.

It doesn't look like there is a attribute that allows an ASN to only be included in a specific AS-SET?

   Attribute             Value                  Type
   aut-num             <as-number>       mandatory, single-valued, class key
   ....                            ......
   asset-allowed   <as-set-names>   optional, multi-valued
   asset-included  <as-set-names>   optional, multi-valued

asset-allowed:  Declare that this ASN can be included in the AS-SET

asset-included: Declare that this ASN can only be included in a specific AS-SET. Once enabled, AS-SETs that are not included in asset-allowed and asset-included will not be able to add this ASN as a member.

I think RIRs and software (e.g. bgpq4) working together will solve the problem better.

For RIRs, stop AS-SET from introducing unauthorized ASNs.

This also requires the help of software, because there are many IRRDBs in the world.

For software, the asset-included parameter in the ASN should be checked while updating the prefix from the AS-SET and refreshing the filter. If the AS-SET includes an ASN that has been added without authorization, then this prefixes from this ASN will be ignored.


Best,

Brandon Zhi
HUIZE LTD

www.huize.asia | www.ixp.su | Twitter


This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.



On Mon, 16 Jan 2023 at 16:52, Andrei Robachevsky <robachevsky@isoc.org> wrote:

On 16/01/2023, 15:07, "Brandon Zhi" <Brandon@huize.asia> wrote:

 

Hi guys,

 

I notice that there exists a object on the whois system which calls member-of.

 

Is this parameter designed to prevent your own ASN from being included in the AS-SET without permission?

 

In a way. It is used to allow to construct the membership of an as-set by reference (see “mbrs-by-ref:” in RFC2622, https://www.rfc-editor.org/rfc/rfc2622#section-5).

 

But I do not think this feature is widely used. Instead, people list members explicitly in the “members:” attribute. This is aggravated by the fact that the semantics of an as-set is not defined. It can be provider’s customer cone, its peers or all networks in a data-center. All three assume different routing policy, but it is not defined (or rather, the most common case is assumed – a customer cone).

 

Regards,

Andrei

 

Best,


Brandon Zhi

HUIZE LTD

www.huize.asia | www.ixp.su | Twitter

 

This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

 

 

On Tue, 10 Jan 2023 at 07:32, Brandon Zhi <Brandon@huize.asia> wrote:

 

 

> Should we consider including this recommendation into the MANRS IXP requirements?

 

 

 I guess they should, checking if the next hop is correct is not a hard task for the route server. But also I think IXPs should forced the IP address and the Mac be corrected (I don't have access to many internet exchanges, as far as I know internet exchanges only have port security.)

 

 

> the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell.

 

Well, I have a way for the regional Internet address registry to address that, not by ASPA. Even If ASPA has been completed, and it will take a lot of time to deploy it in all networks. Let's talk about it in this weekend.

 

Best,

 

Brandon Zhi
HUIZE LTD
www.huize.asia | www.ixp.su | Twitter



This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

   

 

On 2023年1月9日周一 下午4:14 Andrei Robachevsky <robachevsky@isoc.org> wrote:

Hi,

 

On 07/01/2023, 19:18, "Manrs-community" <manrs-community-bounces@elists.manrs.org> wrote:


> Are there any actual cases of such hijacking parties?

yes - this was why section 4.8 made it into rfc7948.

 

Should we consider including this recommendation into the MANRS IXP requirements?

 

Regards,

Andrei