![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> Agreed. The function itself is reasonable, but it should only be used > in private by consenting adult ISPs. If a Network operator is not acknowledging the DISCARD community (due to any reason) and accepting the advertisment, then simply he will forward the traffic to the sender BGP neighbor (won't hurt anything) and the sender will forward the traffic eventually to the discard bin. The receiving BGP neighbor may or may not change the DISCARD community when forward the prefix to other peers. Again, it won't be any issue. Am I missing anything here or any threat/issue? Obviously wherever possible, a network operator does prefix filtering otherwise just leave open to accept everything (e.g., from Transit/ISP link.... 125,000 routes today). As Tariq mentioned the threat exists regardless to this functionality. For example, a peer can advertise a specif prefix for someone else aggregate prefix without DISCARD community as follows: 1. Prefix 2.10.0.0/16 belongs to AS#abc 2. Prefix 2.10.0.0/17 and 2.10.128.0/17 advertise from another AS#xyz (just an attack). Is there any way to NOT accept this prefix if coming from Transit link (without prefix filtering)? Due to longest match rule all the traffic will forward to AS#xyz (assume 2.10.0.0/16 is the only aggregate prefix advertisng from AS#abc). So IMO, this new community will not create any loophole or potential threat. If globally disabled, then what should be the default behaviour (a) Do not accept prefix if DISCARD community is attached or (b) Do not take any action by default (setting next hop for those prefix to discard bin)? We could define a set of rules to use this community properly (like today's Inetnet network, an external peer normally accept /24 or smaller prefix).
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.