perhaps the abstract can say a wee bit about what the heck the new stats
are beyond that they are new? :)
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> In this draft, we introduce a recommendation to avoid the use of BGP
> Extended Communities at the Route Servers of Internet Exchange points.
actually, it says
Operators that tag or match on route announcements on the public
Internet with Extended Communities for 4-octet ASNs are
thank you
> There are quite a lot of changes there and I'm going to make a bunch
> of specific comments about the text changes in this ID in separate
> emails, but want to say some more general things first.
>
> First and foremost, bcp194 needs an update, so thanks for taking up
> the gauntlet
> The author of draft-fiebig-grow-bgpopsecupd asked whether the
> GROW working group could consider adoption of their internet-draft.
imiho, not only should we consider adopting it, but we should adopt it
:)
i have quibbles, of course, but it would be useful
randy
read. like. support adoption.
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> Ultimately it is up to network operators whether they deploy routing
> policy that reject ASPA-Invalid routes.
8481 §5
> What's important here is to mark routes that contain an AS_SET in the
> AS_PATH as 'Invalid' when performing ASPA verification.
agree
>> If the WG agrees to change
ben,
> I think that SHOULD is strong enough to justify the behaviour as part
> of aspa validation.
in my youth, i would agree with you. the last few years in this wg has
taught me to us MUST and carry a gun.
> Certainly the side effect wrt AS_SETs should be called out in
> operational
> Note that 6907 didn't register itself as an update to 6811
6811 is about *origination*. stray from that (to path) and we will end
up in endless discussions of which i will be polite and not
give examples.
randy
___
GROW mailing list
GROW@ietf.org
> In the spirit of RFC6472, any route with an AS_SET in it should not be
> considered valid (by ASPA-based validation).
what's an AS_SET? :)
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> Meaning, please add a note to the security considerations saying don't
> trust communities (this one included) from untrusted sources. See rfc
> 7999 S6.
because A trusts B, A does not know B's inbound security model. so B
could have accepted the community from C with conditions less strict
> WHAT? I'm suggesting that you not treat routes with the ANYCAST
> community learned from R peers as if they are R routes, but as if
> they are normal internet routes.
>
> I don't think you want to require or even recommend the removal of the
> ANYCAST community at an EBGP boundary.
well, in
> So if you advertise the same prefix on multiple upstream but from the
> same site, I'd say it's unicast and not anycast. Technically it should
> be Anycast once you advertise it in two or more distinct sites.
s/sites/locations in the topology/
i.e. i could see two servers in the same colo, but
> given that they're a shrinking rarity, would it not make sense to
> completely exclude non-transparent RSs from the ASPA definition? In
> the short term this would cause problems for ASNs which connect to
> non-transparent RSs, but there are hardly any left, and only one
> sizeable one.
>
> I
>> If the underlying question is "should the ASPA path validation
>> algorithm have a corner case that accommodates this?", that is a
>> very, very firm "no" from me!
>
> aol
opologies, it seems i used an american idiom, and an antique one at
that. a few folk were brave enough to ask, so ...
> If the underlying question is "should the ASPA path validation
> algorithm have a corner case that accommodates this?", that is a
> very, very firm "no" from me!
aol
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
hi job
thanks for reading and commenting!
> * 32-bit ASNs don't fit in 16-bit fields. Consider using a set of
> Extended Communities?
next you're gonna want ipv6; sheesh! :)
i think the draft tried to finesse and not get into wire format. but it
probably should.
extended or wide?
> *
six and a half year old draft rises from the dead, with modification
From: internet-dra...@ietf.org
To: Emile Aben , Randy Bush
Subject: New Version Notification for
draft-ymbk-grow-bgp-collector-communities-02.txt
Date: Thu, 17 Feb 2022 13:09:38 -0800
A new version of I-D, draft-ymbk-grow-bgp
prepending has caused real problems. an rfc damping prepending would be
useful and, imiho, this one is useful and does no harm. like job, i am
not fond of magic numbers. and, if i had to pick a magic number it
would be less than five. but i am not a fan of prepending.
randy
> I do not support adding such an interface to routers or dispersing LG
> locations in BGP.
maybe dns? rpki? x.400? :)
> Place LG info in peeringdb.com & peeringdb's api.
+1
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks
> The point Jakob follows up with in this thread strongly suggests
> communities are not a viable mechanism.
communities are rarely a viable mechanism. too malleable, forgable,
... once again, see our paper.
randy
___
GROW mailing list
GROW@ietf.org
needs work and what better place than a working group?
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> That being said, selective more specific prefix announcements are the
> bane of my existence when attempting to keep traffic local in the less
> mainstream regions of the world. When a given network has some local
> transit/peer and some backhauled transit/peer to which it sends a
> different
nice to see something starting in this space
no need to attribute nationality to bad practice examples
too much concentration on bad examples and not enough on why each of the
recommended practices is good
neglects to mention alternative TE such as longer prefix announcement
randy
> As said before and as reiterated by Jakob and Ketan BGP is not the
> right tool for p2p config push. We must stop adding such extensions to
> BGP like this one or BGP-LS or SR Policies if we really want to keep
> routing at some proper stability levels.
just in case folk missed the last time i
> Imagine I owe /19 of IPv4 and I am allocating /24s in many of my
> global DMZs. If I do not sign my /19 aggregate I have no problem as it
> will be globally not found. But the moment I sign it I must also sign
> all /24s I advertise as otherwise they will become INVALID - right ?
we have been
i'll repeat my comment on sidrops
>> how often do RPs fetch?
> As often as necessary that the RP can synchronize with a repository.
how often is 'necessary?' in units of time, please.
i suspect that we are judging 'success' by the number of ASs doing
'something,' and not
> To the topic of using Large Communities - I do recommend whichever encoding
> is chosen to always be able to insert and carry originator's ASN. All zeros
> are meaningless read: anonymous.
one can no longer assume all actors have good intent.
communities are arbitrary graffiti whose beauty
> I'm asking for 67 million AS numbers, after which there will still be
> over 4 billion AS numbers,
> not including the nearly 95 million private AS numbers.
should be enough. after all, ipv6 only had 4096 possible providers
___
GROW mailing list
> I don’t really know why the current goals were specified the way they
> are
because working groups used to have bounded and achievable goals
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> The old goals were oddly specific; the new goals are oddly
> non-specific. I'm puzzled by the shift between these two opposites.
see ocean? see match?
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
speaking as a co-author, i don't much like this draft. it was
originally a bgp attribute, now it is a community, the hammer which
makes everything look like nail, but does not actually fasten things
very well .
randy
___
GROW mailing list
at the request of the iesg,
OLD
Vendors SHOULD clearly document the behavior of "set" directive in
their implementations.
NEW
Vendors MUST clearly document the behavior of "set" directive in
their implementations.
in addition, martin vigoureux felt we had a confusing paragraph so
hi enke,
> Could you include "BGP" in the title to make it more obvious that the
> document is about BGP communities, and not any other communities?
makes sense. can do if no objection from wg.
randy
___
GROW mailing list
GROW@ietf.org
> Otherwise the definition of “timestamp” would be the same as in RFC
> 7854. So, something like this should be added in the for BMP
> ADJ-RIB-OUT draft:
>
>o Timestamp: The time when the encapsulated routes were advertised
> (one may also think of this as the time when they were
> Section 4.1:
>
> s/is not really on IANA's list/is not individually named on IANA's
> list/
more correctly, i think
not receive special treatment in Cisco IOS XR, and at least one
specific community on Cisco IOS XR's special treatment list (internet
== 0:0) is not formally a
just reread. seems fine.
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> In my opinion, this document adds new requirements or at least new
> considerations for implementations of RFC1997, I think that means it
> updates RFC1997. I liked to see it have "Updates: 1997" metadata added and
> appropriate statements in the Abstract and Intro. I think this requires and
>
> In both the Abstract and the 2nd paragraph of the Introduction,
> it might be helpful to add something like:
> This document recommends specific action items to limit future
> inconsistency.
thanks. done but not (yet) published.
randy
___
GROW
grow may, or may not, be interested in our imc paper, also presented at
ripe77, on bgp communities as weapons.
https://ripe77.ripe.net/presentations/40-communities_slides.pdf
though my slides are different and more tuned to an ietf audience.
randy
>> yeeesh :) people are touchy this week :)
> Randy pushing for more process and bureaucracy?
no, just the current process.
when under heavy load, i prefer not to start new tcp sessions,
especially ones where i do not know the authentication model.
randy
> This seems like a sane plan ... I or Job can either unilaterally accept
> this, or ask for adoption...
>
> If there's enough immediate call to avoid the 2wk call for adoption I'd be
> happy to just put it on the docket...
is there a problem following normal process? is there a criterion for
> A while ago we talked about this. I finally wrote a draft for it,
> https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt:
>
> Abstract
>
>This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>making a change to the registration procedures for several
>
this was a major war some time back. it might be fun to do it sgain.
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> But I guess we all agree that this is not the best use of BGP protocol to
> be now a vehicle of NMS only because it is easy with BGP to establish a TCP
> session and to distribute "stuff" in a relatively loop free fashion.
now that dns over tcp/tls is being deployed, we can return to the other
robin,
i am not ignoring you. i did not want to write unless i had something
possibly useful to say; and that requires pretending to think, always
difficult.
> I would also like to propose following draft for your reference which
> trigger us to move forward for better network maintenance with
> Why anyone would need BMP wrapper to monitor IGP ?
probably similar reasons that folk seem to need bgp-ls to get the
is-is/ospf databases. is-is and ospf have decades of complexity
layered on un-simple bases. so we seek yet another layer of gunk
through which to see them more 'simply.'
i
robin,
> It is not described clearly in the draft that reusing BMP is also a
> possible option for monitoring IGP. We will refine the draft.
if i could also use bmp for monitoring dns, smtp, and ntp, i could
stop using nagios!
i think what acee is trying to say is that "B" in BMP does not
i am confused as why this is in grow. it's protocol.
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
>>> I'm not saying the drafts don't work. I'm trying to look ahead. And
>>> I am convinced that route-monitoring messages should be TLV
>>> based. And if we agree that we have to make that change some day, I
>>> think we should change it asap.
>>
>> I see your point and there are good ideas you
> it strikes me as being a latter day "Go To Statement Considered
> Harmful" sort of thing.
goto is harmful!
> I don't disagree as a general principal, but also admit to secretly
> using "set" to remove pre-existing communities from time to time, as
> we all probably do, even if we don't like to
>> Please take a moment to read and evaluate the document and let the
>> working group know whether you'd like to continue work on this
>> document as working group or not.
> yep, sounds good, but what will this do to the vendors' two main
> weapons, fear and surprise?
there are so many
>>> "Operators are recommened not to use "set community" or "community
>>> set" and just explicitly remove/add what needs to be done.
>>
>> do all vendors support wildcards?
>
> Yes, I think so. Of the top of my head you can wilcard on Junos, Cisco
> Classic/XE/XR, OpenBGPD, BIRD, Brocade
> "Operators are recommened not to use "set community" or "community
> set" and just explicitly remove/add what needs to be done.
do all vendors support wildcards?
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
I believe the fundamental problem is (1) the same AS-SET name can
exist in
multiple databases (duplication), (2) you don’t know which as-set
belongs
to which ASN (ownership), and which as-set to use (discovery).
i think these may be part of the same confuddle; what is the
“identity” of an
>>> me and Job Snijders have recently submitted
>>> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an attempt
>>> to bring as-sets into RPKI to facilitate route filtering.
>>
>> in irr, an as-set may reference an as-set. could you explain the
>> authority model you have for this when
> me and Job Snijders have recently submitted
> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an attempt to
> bring as-sets into RPKI to facilitate route filtering.
in irr, an as-set may reference an as-set. could you explain the
authority model you have for this when as-sets are
> I'm not sure this is work that is a great fit for GROW.
you are being too polite. this is a poorly thought out idea. people
have already pointed out simpler approaches. but our job is not to
design this for boeing, it is to decide if this is work for this wg.
imiho, it isn't.
randy
> Can we have a 10 minute to discuss update to these drafts?
i see the bmp work as important. might more time for discussion move
things along more quickly, or are we all really in agreement on these?
randy
___
GROW mailing list
GROW@ietf.org
>> did you even know this was happening, that "set community" might
>> not replace ALL well known communities?"
>
> No, as in, "I assumed that 'set community' would stamp the communities
> listed onto the prefix, and replace everything already there".
jay was shocked when he discovered it, and i
> Trouble with WKC is that some you want to remove, some you want to
> honor, and some you just want to pass-through without taking any
> action.
and, if i was of that mind, i would want to decide which, not have the
vendors do so.
> "set community" isn't a great fit for cherry-picking.
nor is
question for ops:
did you even know this was happening, that "set community" might not
replace ALL well known communities?"
the reasom i ask is, as you see in the draft, we are hesitant to propose
changing behavior for existing wks as it might impact ops. but if we
were not aware of this
can we take ten minutes to discuss
draft-ymbk-grow-wkc-behavior-00.txt
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
really do not want to get drawn into this. but while looking into lags
a few years back, we found a lot of them split across line cards, with
resilience to line card failure being the stated reason.
randy
___
GROW mailing list
GROW@ietf.org
if the rs injects it as, then traffic will be biased against rs paths
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
>> draft-ietf-sidrops-ov-clarify-00.txt
>>
> I don't know that GROW was listening to SIDROPS docstream, though it's
> certainly a good idea to keep abreast of possible changes coming to
> their world-view.
this one effects ops pretty directly
___
GROW
> 10 days past... no replies, are there things to talk about? or should we
> give back our meeting slot?
i would listen to any comments on the last rev of
draft-ietf-sidrops-ov-clarify-00.txt
or do i need to threated wglc to get comment? :)
randy
there is an rfc to xml converter somewhere. i once used it.
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
imiho, the chicago bar bof on bmp was very productive. perhaps we
should consider a non-wg-formative bof or some other kind of get-
together on the bmp spec and implementation experience/use in praha?
randy
___
GROW mailing list
GROW@ietf.org
while i support adoption of this work, two notes:
o i should declare an involvement with the openbmp cabal for which
this is key
o clue bat please. as this changes what is transported over bmp, why
is it not in idr?
randy
___
GROW
> I was wondering if there was more scope to make mischief at a distance
> in a less less obvious way than before.
there isn't
but where were you when the blackhole community was passed?
> So you rely on the nodes that receive these community strings to
> interpret them in a common way.
no.
>> you're supposed to guess
>>
>> the normal hack here is
>>
>>this document introduces no new security issues beyond those discussed
>>in 1997
>
> Guessing is horrible, but if that is what you do, that is what you do,
> and if the risks are the accepted norm in the BGP community I am
>> 5. Security Considerations
>>
>>Operators should note the recommendations in Section 11 of BGP
>>Operations and Security [RFC7454].
>>
>> SB> You do not address the question of whether there are new
>> SB> considerations, or considerations that are of increased importance?
>
> It is
> If ISPs do not turn this *on* on their customer connections, it will not
> do anything - and given that those ISPs that *need* to turn this on are
> the ones that are not caring today, I'm still not seeing why they would
> turn this on tomorrow.
not quite. if ntt and l3 told fiber@home "on or
> With all due respect, your draft fails to acknowledge the earlier work by
> me (from 2012), outside of the recent drafts of which I am a
> co-author.
apologies. this should be corrected,
> So, perhaps it would be best to avoid claims of plagiarizing, when (a)
> there is clear evidence that
> SIDR/GROW/IDR and well documented in IDR (see Section 4)
> (
> https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06
> ).
> The solution involves AS-A setting a field (in an optional transitive
> attribute)
glad you liked the attribute approach well enough to
> Thank you for sharing this scenario. It would indeed work at the small
> cost (or perhaps not so small) to require an extra round trip at setup
> time which is most likely un-avoideable whatever is done.
then a double open. i.e. a 4096 open which has the extended capability
exchange and then
[ first, i do not use route serves (because of the data/control non-
congruence), so my opinion here is worth even less than it normally
is. ]
> An ixp route-server is not a transit provider, all of the nexthops
> exposed are in fact peers. So no I do not consider such a device an
>
> Adding grow@ietf.org for reality check.
no comment :)
when you choose to use a route server [0], you have out-sourced much of
your policy and operational responsibilities. seems to me that whether
this includes security decisions is a contract between the user and the
route server.
so i
why do folk block syslog/514?
who can come up with the first exploit based on a tricky entry?
randy
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
seems reasonable
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
> doesn't look new to me, no. and 'worse', today someone COULD just (if
> they are in the right place and can do bgp packet creation,etc) just
> tag all of your announcments to your provider(s) with the local
> provider version of this community, blackholing all of your traffic.
note the string
> It's a leaky bucket, peers can generate prefix list filters for their
> route objects.
as has been gone over a few thousand times, current hardware can not
hold prefix filters for large peers.
randy
___
GROW mailing list
GROW@ietf.org
> fine, bad terminology. was following the original.
the document is not strong on rigor
> Is it not possible to define a ROA that includes a prefix-length
> -or-longer up-to and including a /128 or /32?
quite possible. but
>> rpki-based origin authentication doe not help here because the
>>
< pedantry alert >
> I am not knowledgable of every facet of rpki, but I thought that it was
> possible to express /length-or-longer? But Randy has already pointed
> that rpki doesnt cover communities; to middle men can alter it.
rpki does not cover anything in a bgp announcement. it is a
>> and you are kinda peotected by the community not being well-known,
>> i.e. different for each upstream. the attacker has to know the
>> community for each upstream and be able to not only inject the prefix
>> but also tag it with the correct community for each upstream.
>
> Your argument comes
> I would expect this proposed community to be used along with adding
> no-export on receipt at the peer, because sending the community more
> broadly isn't as helpful.
and we all know accidents never happen. and, networks which do not
implement also will not drop export.
> I suggest that if
>>> why the security warning relating to denial of service attacks was
>>> removed.
>>
>> what could possibly go wrong with a well-known transitive attribute
>> which causes an un-authenticated prefix's traffic to be dropped on the
>> floor?
>
> Today I have 5 or six of them... and my managment
> The second major area of concern I have about this proposal is the
> transitive nature of the bgp community. The issue is that the draft
> specifies a mechanism to cause traffic to be dropped on the floor,
> that the signaling mechanism is globally transitive in scope, and the
> specific intent
> "... from the customer cone of the lateral peer.", what's the mean of
> the "customer cone" here? It's better to use a more common term here.
well known term. you want "transitive closure of customers of lateral
peer??
randy
___
GROW mailing list
> And that's enough for me to clear my discuss too, yes.
>
> I guess saying IPsec is better than maybe badly specifying
> how to do TLS, even though TLS is the more sensible thing
> to do,
and un-badly specifying tls is not possible?
randy
___
GROW
>> So... who is willing to sign your network up for this grand
>> experiment at securing your BMP?
> Otherwise, what you're saying seems to be: "be careful what you for
> because you just might get it".
first, i wish for a solid, functional, scalable bmp. to be clear, we
don't have it now, and i
>> tls will satisfy usability, presence in shipping code and likelihood of
>> deployment. It comes at the cost of either using a different port number
>> or else adding startls into the protocol. It's understandable why there
>> would be opposition to implementing this at revision -16 and with
> Or we should figure out how to make this easy to work. But there's
> also operational consequences like impact on various high availability
> solutions.
and ipsec has the same session problems with HA
>> thanks to browsers, email, and a hoard of other apps, tls is what is
>> deployed and
> "This is an inherently insecure protocol for no particularly good
> reason and mostly due to the lack of implementation of basic security
> mechanisms (SSH, TLS) but also due to a lack of customer/operator
> pressure to ensure those are present, usable and interoperate, despite
> evidence that
>Where the security considerations outlined above are a concern, users
>of this protocol should use IPsec [RFC4303] in tunnel mode with
>preshared keys.
the classic wiggle from the 1990s. and no one ever does it. and at the
using layer, you can not even detect if it is in place and
nick,
> that would be difficult, as there is no way of exchanging exact
> semantics. I.e. one provider's opinion on how a specific community
> tag should be implemented might differ from their peer's.
>
> If the aim of this + other similar drafts is to create a set of
> standardised community
> What seems to be needed more than a standard as to what communities
> everyone should use is a method of exchanging the mappings for a given
> provider.
things change over time. consider a proggy trying to do an analysis
over one rv/ris rib per month over ten years.
randy
> I do not feel comfortable overloading locally administrated bits with
> something that represents global significance. The 64xxx communites
> come dangerously close to codepoints we use internally. I'd prefer
> that the local portion of BGP Communities remains truely local.
only problem is that
>> I do not feel comfortable overloading locally administrated bits with
>> something that represents global significance. The 64xxx communites
>> come dangerously close to codepoints we use internally. I'd prefer
>> that the local portion of BGP Communities remains truely local.
>
> only problem
>> The ASN in the marking SHOULD be that of the collector peer.
> For my understanding, if AS 8283 feeds RIPE RIS, AS 8283 would be the
> 'collector peer' in the above context?
yes
>> The communities were selected from community values which were unused
>> at the time of this document and SHOULD
1 - 100 of 107 matches
Mail list logo
