Re: Request comment: list of IPs to block outbound
Subject: Re: Request comment: list of IPs to block outbound Date: Tue, Oct 22, 2019 at 11:11:27PM -0600 Quoting Grant Taylor via NANOG (nanog@nanog.org): > On 10/22/19 10:54 PM, Måns Nilsson wrote: > > It is just more RFC1918 space, a /10 unwisely spent on stalling IPv6 > > deployment. > > My understanding is that RFC 6598 — Shared Address Space — is *EXPLICITLY* > /not/ a part of RFC 1918 — Private Internet (Space). And I do mean > /explicitly/. I understand the reasoning. I appreciate the need. I just do not agree with the conclusion to waste a /10 on beating a dead horse. A /24 would have been more appropriate way of moving the cost of ipv6 non-deployment to those responsible. (put in RFC timescale, 6598 is 3000+ RFCen later than the v6 specification. That is a few human-years. There are no excuses for non-compliance except cheapness.) Easing the operation of CGN at scale serves no purpose except stalling necessary change. It is like installing an electric blanket to cure the chill from bed-wetting. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 I'm a nuclear submarine under the polar ice cap and I need a Kleenex!
Re: Request comment: list of IPs to block outbound
On 10/22/19 10:11 PM, Grant Taylor via NANOG wrote: > The explicit nature of RFC 6598 is on purpose so that there is no chance > that it will conflict with RFC 1918. This is important because it means > that RFC 6598 can /safely/ be used for Carrier Grade NAT by ISPs without > any fear of conflicting with any potential RFC 1918 IP space that > clients may be using. > > RFC 6598 ∉ RFC 1918 and RFC 1918 ∉ RFC 6598 > RFC 6598 and RFC 1918 are mutually exclusive of each other. > > Yes, you can run RFC 6598 in your home network. But you have nobody to > complain to if (when) your ISP starts using RFC 6598 Shared Address > Space to support Carrier Grade NAT and you end up with an IP conflict. > > Aside from that caveat, sure, use RFC 6598. So, to the reason for the comment request, you are telling me not to blackhole 100.64/10 in the edge router downstream from an ISP as a general rule, and to accept source addresses from this netblock. Do I understand you correctly? FWIW, I think I've received this recommendation before. The current version of my NetworkManager dispatcher-d-bcp38.sh script has the creation of the blackhole route already disabled; i.e., the netblock is not quarantined.
Re: Request comment: list of IPs to block outbound
On 10/22/19 10:54 PM, Måns Nilsson wrote: I have a hard time finding text that prohibits me from running machines on 100.64/10 addresses inside my network. I think you are free to use RFC 6598 — Shared Address Space — in your network. Though you should be aware of caveats of doing so. It is just more RFC1918 space, a /10 unwisely spent on stalling IPv6 deployment. My understanding is that RFC 6598 — Shared Address Space — is *EXPLICITLY* /not/ a part of RFC 1918 — Private Internet (Space). And I do mean /explicitly/. The explicit nature of RFC 6598 is on purpose so that there is no chance that it will conflict with RFC 1918. This is important because it means that RFC 6598 can /safely/ be used for Carrier Grade NAT by ISPs without any fear of conflicting with any potential RFC 1918 IP space that clients may be using. RFC 6598 ∉ RFC 1918 and RFC 1918 ∉ RFC 6598 RFC 6598 and RFC 1918 are mutually exclusive of each other. Yes, you can run RFC 6598 in your home network. But you have nobody to complain to if (when) your ISP starts using RFC 6598 Shared Address Space to support Carrier Grade NAT and you end up with an IP conflict. Aside from that caveat, sure, use RFC 6598. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Request comment: list of IPs to block outbound
Subject: Re: Request comment: list of IPs to block outbound Date: Sun, Oct 13, 2019 at 09:24:39AM -0700 Quoting William Herrin (b...@herrin.us): > > > 100.64.0.0/10 Private network Shared address space[3] for > > communications between a service > > provider and its subscribers > > when using a carrier-grade NAT. > > > > This space is set aside for your ISP to use. like RFC1918 but for ISPs. It > is not specifically CGNAT. Unless you are an ISP using this space, you > should not block destinations in this space. I have a hard time finding text that prohibits me from running machines on 100.64/10 addresses inside my network. It is just more RFC1918 space, a /10 unwisely spent on stalling IPv6 deployment. /Måns, guilty. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 It's OKAY -- I'm an INTELLECTUAL, too. signature.asc Description: PGP signature
Re: BGP over TLS
> On Oct 22, 2019, at 6:31 PM, Keith Medcalf wrote: > > I see. It is an AIC problem, not a CIA problem. TLS in its default > usage is a CIA thing because, well, it was designed to solve CIA > problems where even temporary secrecy is more important than being down > for a week. As had been pointed out though, TLS does allow for non-CIA > configuration and usage such as by using PSK or fingerprint > authentication. SSH is also an AIC thing. It solves the problem by > recording the fingerprint on first connect and alarming if the > fingerprint is not subsequently what was expected. Cannot TLS be > configured to do the same thing bidirectionally? I’ve had enough of a problem with the management side of my router w/ SSH(host) keys that imagining trying to scale that to lets say 200 peers at an IXP would make it insane to touch. In my home network I ended up placing a rule due to how often I would play with embedded devices, eg: Host 10.0.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null Because each time I have a new device come up with a hostname (eg: raspberrypi.local) I would have to clear out my known hosts file. This local policy allows me to make this simpler. I think something like that is really what’s desired, but when was the last time you managed to keep the ssh daemon key on your router when you swap hardware? The simpler the tools the better. Things like ACME made it much easier for someone to manage their TLS certs and config. There’s much to be desired from the management plane of these devices. No wonder people with scale roll their own code.. Routers haven’t advanced much past the early 90s in sophistication in how you configure them. We’re still in the late 90s with kickstart techniques and manual patching vs enmasse configuration changes. I see the limitations on both the technical side and the human side. Try to tell someone who has been caretaking all the routers to become a sysadmin and watch what happens. It’s up to us as consumers of the technology to push our vendors for something better. I can’t have a router reboot itself when you type commit or similar which is still the state of the industry. - Jared
RE: BGP over TLS
On Tuesday, 22 October, 2019 13:26, Jared Mauch wrote: >No, >> On Oct 22, 2019, at 2:08 PM, Keith Medcalf wrote: >> At this point further communications are encrypted and secure against >>eavesdropping. >The problem isn't the protocol being eavesdropped on. The data is already >published publicly by many people. >The problem is one of mutual authentication and authorization of the >transport. I see. It is an AIC problem, not a CIA problem. TLS in its default usage is a CIA thing because, well, it was designed to solve CIA problems where even temporary secrecy is more important than being down for a week. As had been pointed out though, TLS does allow for non-CIA configuration and usage such as by using PSK or fingerprint authentication. SSH is also an AIC thing. It solves the problem by recording the fingerprint on first connect and alarming if the fingerprint is not subsequently what was expected. Cannot TLS be configured to do the same thing bidirectionally? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: BGP over TLS
No, > On Oct 22, 2019, at 2:08 PM, Keith Medcalf wrote: > > At this point further communications are encrypted and secure against > eavesdropping. The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people. The problem is one of mutual authentication and authorization of the transport. - Jared
Re: BGP over TLS
On Tue, Oct 22, 2019 at 2:21 PM Bjørn Mork wrote: > > Christopher Morrow writes: > > > The x.509 system, to be effective here would require a TrustAnchor / > > Root-of-Trust that both parties agreed was acceptable... > > As in a shared TrustAnchor? No. Both ends could use a simple self as an option, sure. not a great one as you say. (and I agree, today's 'web pki' model just isn't sane for networking) > signed certificate and be configured to trust the other. A hash of the > peers public key would be sufficient for the BGP peer configuration. > This is effectively the same as the md5 problem, right? and there'd have to be a bunch of not-standard machinations in the tls connection to support this behavior... never mind: "Was that E5S or E5s gosh.. can you send me this over IM please?" :) (passing around the fingerprints is hard) > Or you could use more complex PKI models, with a CA hierarchy or > whatever. The point is that TLS doesn't force you to do that > right, I think I said that in the next paragraph: "Hey, you could use psk..." > Authenticating the peer by its public key hash is as simple as using an > TCP-MD5 password. err... is it though? 'foobarbaz' is a long simpler than: SHA1 Fingerprint=A2:A8:74:E7:3C:20:49:E4:2D:5A:6E:97:EF:B2:65:C7:59:44:1A:6E > > To get around that you propose we hopscotch over to 'TLS with > > preshared keys (PSK)'...ok, that smells nice, > > Maybe. Personally I don't see the point. I think ... if we are working away from a static 'key' and to something that could be machine managed in a secure fashion (certs, for instance) we'd be in a better place for: bgp session security bgp session integrity bgp session authentication > >> My personal major gripe with certificate based systems is that many > >> routers don't have an RTC and won't know what time it is until they can > >> NTP, which likely requires protocol adjacencies, and then a dependency > >> loop. > > > > this is also a problem, but really ... your igp should get you to an > > NTP source... or we'd all get to that fairly quickly, right? :) > > (some of this is updating 'best practices' in building / maintaining > > a network, right?) > > You may ignore notAfter and notBegin like DANE does. The ntp issue is I don't know what those fields are but: notBefore=Oct 3 17:13:51 2019 GMT notAfter=Dec 26 17:13:51 2019 GMT maybe you mean these? sure, you CAN ignore those, but that's also 'non-standard, outside openssl-like behavior' so likely to cause problems :( and, you really do want certs with expiry that's 'short' so you don't need to worry about CRL distribution and such. I think anyway. > another reason. But IMHO the most important one is that you don't want > any sort of forced key rotation, where the configuration that was valid > yesterday suddenly becomes invalid. That's a policy designed for a > completely different usecase than running a routing protocol. there are many examples of (outside x509/ssl) key management systems that use date initiated keys though, on network devices. most vendors support a key table for ISIS and OSPF... and LDP (I believe) > You'll probably want to trust your configured pinned peer key for as > long as it is part of your configuration. And if you are using a CA, that seems .. bad. What if someone gets the key material that's not your peer? https://arstechnica.com/information-technology/2019/10/hackers-steal-secret-crypto-keys-for-nordvpn-heres-what-we-know-so-far/ this doesnt' happen too often... wait, yes it does. You want the ability to CRL or expire or make a lost cert less useful. keys/certs/secrets that last forever are not a thing. > then you'll probably want to use a CRL to withdraw specific certificates > instead of depending on a timeout. CRLs imply some external dependency, maybe that's ok depending on your deployment, but I imagine that if we get to a world with a CA per peer-as, there are going to be folk very busy getting CRLs and not so busy getting routes done. there's a tradeoff for each of these things, I imagine a well reasoned paper (juilien?) and some standards (possibly) + implementer work would be necessary to get true forward movement. (and desire to actually do this work) > And before someone claims that notAfter and notBegin validation is > mandated by the RFC 5280 certificate policy - The good authors of RFC > 5280 anticipated that their "Internet applications" policy wouldn't > necessarily fit all: > >Some communities will need to supplement, or possibly replace, this >profile in order to meet the requirements of specialized application >domains or environments with additional authorization, assurance, or >operational requirements. However, for basic applications, common >representations of frequently used attributes are defined so that >application developers can obtain necessary information without >regard to the issuer of a particular certificate or certificate >revocatio
Re: BGP over TLS
On 10/22/2019 14:07, Keith Medcalf wrote: That is incorrect. I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo". At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up. The Security part in Transport Layer Security is Encryption. Authentication is lathered on top as an afterthought and requires external measures be taken in order to have*any* effect whatsoever. This is unauthenticated Diffie-Hellmann key agreement, essentially. As has been pointed out, it only works if you know that, during the initial agreement, you can trust that you are talking directly to who you want to talk to without fear of a man in the middle (a passive observer will still be foiled). TLS supports this in the form of anonymous TLS. Something similar is normally used for opportunistic TLS upgrade with e.g. SMTP, but there at least one end (the "server") still presents a certificate; the client just doesn't validate it. Password-authenticated DHKA fixes the above problem, but then you're back to the status quo of a preshared secret. This is, in fact, how the DHE* suite of TLS ciphersuites works, AFAIK. Use PKI to exchange one secret (with trust of who you're talking to, where applicable, due to the PKI), then use authenticated DH to establish a session secret using that as the PSK. Then throw away that session secret when you're done. One thing that comes to mind in the context of what others have done is to have each router maintain, internally, its own long-term CA and issue a peer certificate when a session is first started to its peer. This has the same problem in that the initial session establishment could be meddled with but, assuming that does not happen (and it does not, in practice, seem especially likely except maybe on an IX), the peer can identify itself for the long term. THrow alarm bells if an unknown peer again tries to talk on that configured peer. That at least gets you some form of long-term security (at the cost of possibly NO security if the above assumptions are not met), and it happens automatically. You could do the same thing with a symmetric secret being automatically established using DHKA or similar, too, of course. -- Brandon Martin
Re: BGP over TLS
Christopher Morrow writes: > The x.509 system, to be effective here would require a TrustAnchor / > Root-of-Trust that both parties agreed was acceptable... As in a shared TrustAnchor? No. Both ends could use a simple self signed certificate and be configured to trust the other. A hash of the peers public key would be sufficient for the BGP peer configuration. Or you could use more complex PKI models, with a CA hierarchy or whatever. The point is that TLS doesn't force you to do that Authenticating the peer by its public key hash is as simple as using an TCP-MD5 password. > To get around that you propose we hopscotch over to 'TLS with > preshared keys (PSK)'...ok, that smells nice, Maybe. Personally I don't see the point. >> My personal major gripe with certificate based systems is that many >> routers don't have an RTC and won't know what time it is until they can >> NTP, which likely requires protocol adjacencies, and then a dependency loop. > > this is also a problem, but really ... your igp should get you to an > NTP source... or we'd all get to that fairly quickly, right? :) > (some of this is updating 'best practices' in building / maintaining > a network, right?) You may ignore notAfter and notBegin like DANE does. The ntp issue is another reason. But IMHO the most important one is that you don't want any sort of forced key rotation, where the configuration that was valid yesterday suddenly becomes invalid. That's a policy designed for a completely different usecase than running a routing protocol. You'll probably want to trust your configured pinned peer key for as long as it is part of your configuration. And if you are using a CA, then you'll probably want to use a CRL to withdraw specific certificates instead of depending on a timeout. And before someone claims that notAfter and notBegin validation is mandated by the RFC 5280 certificate policy - The good authors of RFC 5280 anticipated that their "Internet applications" policy wouldn't necessarily fit all: Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL). BTW, using TLS for management protocols is not completely unknown. We already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably others I haven't touched yet. The certificate management problem is pretty much the same for all these. You have a closed group of clients/servers/peers using explicitly configured sessions. You want both ends to authenticate each other. You don't necessarily want an umbrella trust anchor in the form of a CA. Defining trust per session is fine, using pinned certificates. Bjørn
Re: BGP over TLS
Once upon a time, Keith Medcalf said: > I believe that an endpoint (lets call it Alice) can connect to another > endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets > negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do > that". They then exchange some stuff to and fro and then Alice says "Righty > then, lets encrypt!" and Bob says, "Yabba Doodle Doo". > > At this point further communications are encrypted and secure against > eavesdropping. Alice still has no idea who she is talking to (other than it > is the dude that picked up the phone), and Bob has no idea who he is talking > too other than the fact it is whoever rang him up. But if Alice and Bob don't know that they're talking to each other, they could already be being eavesdropped on. Chuck could have answered Alice's call, turned around and called Bob, connected the two, and be listening in (and potentially even modifying communications between Alice and Bob). This is why encryption without some type of endpoint authentication is not secure. I could see BGP over TLS requiring each end sharing a CA public cert in advance - this would allow each end to re-gen keys at will. The BGP config could easily limit a particular peer to a particular CA (so when I peer with Google, they send me or otherwise publish their BGP CA, and I limit my Google peers to that CA). This could replace trying to securely share MD5 keys today - a BGP CA could be published (possibly even at RIRs). -- Chris Adams
RE: BGP over TLS
>TLS in the traditional sense 'requires' that there be an X.509 >certificate to use in authenticating (and to some extent authorizing - >can you be a CA? sign email? etc...) endpoints, ideally you do 'tls >mutual authentication'... That is incorrect. I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo". At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up. The Security part in Transport Layer Security is Encryption. Authentication is lathered on top as an afterthought and requires external measures be taken in order to have *any* effect whatsoever. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: BGP over TLS
On Tue, Oct 22, 2019 at 6:35 AM Julien Goodwin wrote: > > > > On 22/10/19 4:04 am, Jared Mauch wrote: > > > > > >> On Oct 21, 2019, at 12:30 PM, Joe Abley wrote: > >> > >> On 21 Oct 2019, at 12:05, Keith Medcalf wrote: > >> > >>> On Monday, 21 October, 2019 09:44, Robert McKay wrote: > >>> > The MD5 authentication is built into TCP options.. not obvious how you > would transport it over TLS which afaik doesn't offer similar > functionality. > >>> > >>> AHA! I understand now and sit corrected. I was under the mistaken > >>> impression that MD5 authentication was an application level thing, not a > >>> TCP level thing. > >> > >> Well, TLS exists within a TCP session, and that TCP session could > >> incorporate the MD5 signature option. I guess. > >> > >> Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality > >> of deploying certificates to every BGP speaker that are useful for strict > >> checking by neighbours, though. Perhaps I've been too long with my hands > >> out of routers and things have moved on, but it seems to me that the > >> history of certificate management in routers is not a rich tapestry of > >> triumph. > > > > It’s not. I talked about this in the security area session at IETF several > > meetings ago — the requirements operators have around this space, and it’s > > quite a pain to be honest. > > > > I’ve seen enough people have issues with managing a password that > > certificates would be even harder when there’s a router swap. > > > > The issue isn’t that most people want privacy, it’s they want transport > > integrity which in general the TLS community seems to think everyone NEEDS > > both. > > Yeah, I come from the perspective not just of a (now former AS15169) > operator, but also often being one of a network's very few peers, > sometimes the only non-transit a network had. > > IMO, *requiring* certificates or similar is a step too far at the > moment, however building something that allows for easy extension to > certificates (or whatever) is sensible. TLS in the traditional sense 'requires' that there be an X.509 certificate to use in authenticating (and to some extent authorizing - can you be a CA? sign email? etc...) endpoints, ideally you do 'tls mutual authentication'... The x.509 system, to be effective here would require a TrustAnchor / Root-of-Trust that both parties agreed was acceptable... Julien, you are asserting that: "yea, but that's hard, because Julien-net and Chris-net may agree on 'bobs bait and tackle CA', but certainly Jared-net is obstinate and will required only the CA at "Sams Veggie Hut & CA"" ... so we'd end up with managing a 'worse' version of the web-PKI on network devices. To get around that you propose we hopscotch over to 'TLS with preshared keys (PSK)'... ok, that smells nice, it's NOT a kernel/tcp option (hurray) it's possibly safer-ish. I think Jared's point that; "this is just gussied up md5..." isn't wrong, it is nice that this isn't in the kernel path (tcp-md5/tcp-ao HA)... I think that really it'd need some method to change PSK though over time in a sane fashion, ie the 'key table' that is used in other places for this sort of problem. Internally folk that wanted could use their own CA infra to operate / use certs on their iBGP sessions, or customer sessions... and maybe later in our lifetime we could re-use the certs that RPKI distributes as the certs for bgp session security ? (I think there are some pretty draconian restrictions on the certs here, but I don't remember off the top of my head what those are right now.) > >> Without strict checking in both directions, the threat model with TLS > >> looks pretty similar to that with TCP-MD5 with not very secret secrets, > >> which I gather is one of the deficiencies that the TLS proposal seeks to > >> address. > > > > This is a whole mess of trouble here due to the disconnect in how routers > > are managed, the technical capabilities of vendors and where the protocol > > split lives here. > > > > I will take routers that don’t reboot when we commit them and devices that > > can be managed automatically vs the keyboard jockey days that we’re all > > used to. > > > > My personal major gripe with certificate based systems is that many > routers don't have an RTC and won't know what time it is until they can > NTP, which likely requires protocol adjacencies, and then a dependency loop. this is also a problem, but really ... your igp should get you to an NTP source... or we'd all get to that fairly quickly, right? :) (some of this is updating 'best practices' in building / maintaining a network, right?)
Re: Is anybody else getting spam from cytranet.com?
On 10/22/19 5:41 AM, Rich Kulawiec wrote: I'm guessing -- because spammer Ben Reynolds (breyno...@cytranet.com) wrote to me about voice/data services -- that it's possible they've been scraping addresses from here. This exact issue received exhaustive coverage over on the Outages (outa...@outages.org) email list under "[outages] sales critter Ben Reynolds" starting back on the 19th. - John -- John Sage
Re: Is anybody else getting spam from cytranet.com?
Seems likely that they scraped the list, yes. Two more names to my Never Do Business With list I guess. :) On Tue, Oct 22, 2019 at 8:43 AM Rich Kulawiec wrote: > I'm guessing -- because spammer Ben Reynolds (breyno...@cytranet.com) > wrote to me about voice/data services -- that it's possible they've > been scraping addresses from here. > > ---rsk >
Re: Is anybody else getting spam from cytranet.com?
On 10/22/19 8:41 AM, Rich Kulawiec wrote: I'm guessing -- because spammer Ben Reynolds (breyno...@cytranet.com) wrote to me about voice/data services -- that it's possible they've been scraping addresses from here. Yes, mine came to my voiceops tagged address. -- Brandon Martin
Is anybody else getting spam from cytranet.com?
I'm guessing -- because spammer Ben Reynolds (breyno...@cytranet.com) wrote to me about voice/data services -- that it's possible they've been scraping addresses from here. ---rsk
RE: Request comment: list of IPs to block outbound
> From: Saku Ytti > Sent: Tuesday, October 22, 2019 11:54 AM > > On Mon, 21 Oct 2019 at 23:14, wrote: > > > The obvious drawback especially for TCAM based systems is the scale, > > so not only we'd need to worry if our FIB can hold 800k prefixes, but > > also if the filter memory can hold the same amount -in addition to > > whatever additional filtering we're doing at the edge (comb filters > > for DoS protection etc...) > > This is actually somewhat cheap problem, if you optimise for it. That is rules > are somewhat expensive, but N prefixes per rule are not, when designed > with that requirement. Certainly the BOM effect can be entirely ignored. > However this is of course only true if that was design goal, won't help in a > situation where HW is in place and doesn't not scale there. Just pointing out > that there are no technical or commercial problems getting there, should we > so want. > Well sure if BGP prefix=ACL prefix was true from the get go both scaling problems would be catered for in unison and we wouldn't even notice. People here would be asking for recommendations on new/replacement edge router that can support 1M routes and filter entries... But the reality is that long filters can significantly decrease performance of modern (supporting 100G interfaces) NPUs/PFEs. adam
Re: Request comment: list of IPs to block outbound
On Mon, 21 Oct 2019 at 23:14, wrote: > The obvious drawback especially for TCAM based systems is the scale, so not > only we'd need to worry if our FIB can hold 800k prefixes, but also if the > filter memory can hold the same amount -in addition to whatever additional > filtering we're doing at the edge (comb filters for DoS protection etc...) This is actually somewhat cheap problem, if you optimise for it. That is rules are somewhat expensive, but N prefixes per rule are not, when designed with that requirement. Certainly the BOM effect can be entirely ignored. However this is of course only true if that was design goal, won't help in a situation where HW is in place and doesn't not scale there. Just pointing out that there are no technical or commercial problems getting there, should we so want. -- ++ytti
Re: BGP over TLS
On 22/10/19 5:42 am, Jakob Heitz (jheitz) via NANOG wrote: > The article linked says no mainstream BGP implementation supports TCP-AO. > IOS-XE and IOS-XR support it. > > While I do not represent the Cisco view, personally I like the idea of BGP > over TLS. Excellent, that's news to me. I had been told Juniper finally also shipped TCP-AO in a very recent JunOS. Both of those are great, but without upstream OS support that leaves a bunch of purely software implementations out in the cold.
Re: BGP over TLS
On 22/10/19 4:04 am, Jared Mauch wrote: > > >> On Oct 21, 2019, at 12:30 PM, Joe Abley wrote: >> >> On 21 Oct 2019, at 12:05, Keith Medcalf wrote: >> >>> On Monday, 21 October, 2019 09:44, Robert McKay wrote: >>> The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality. >>> >>> AHA! I understand now and sit corrected. I was under the mistaken >>> impression that MD5 authentication was an application level thing, not a >>> TCP level thing. >> >> Well, TLS exists within a TCP session, and that TCP session could >> incorporate the MD5 signature option. I guess. >> >> Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality >> of deploying certificates to every BGP speaker that are useful for strict >> checking by neighbours, though. Perhaps I've been too long with my hands out >> of routers and things have moved on, but it seems to me that the history of >> certificate management in routers is not a rich tapestry of triumph. > > It’s not. I talked about this in the security area session at IETF several > meetings ago — the requirements operators have around this space, and it’s > quite a pain to be honest. > > I’ve seen enough people have issues with managing a password that > certificates would be even harder when there’s a router swap. > > The issue isn’t that most people want privacy, it’s they want transport > integrity which in general the TLS community seems to think everyone NEEDS > both. Yeah, I come from the perspective not just of a (now former AS15169) operator, but also often being one of a network's very few peers, sometimes the only non-transit a network had. IMO, *requiring* certificates or similar is a step too far at the moment, however building something that allows for easy extension to certificates (or whatever) is sensible. >> Without strict checking in both directions, the threat model with TLS looks >> pretty similar to that with TCP-MD5 with not very secret secrets, which I >> gather is one of the deficiencies that the TLS proposal seeks to address. > > This is a whole mess of trouble here due to the disconnect in how routers are > managed, the technical capabilities of vendors and where the protocol split > lives here. > > I will take routers that don’t reboot when we commit them and devices that > can be managed automatically vs the keyboard jockey days that we’re all used > to. > My personal major gripe with certificate based systems is that many routers don't have an RTC and won't know what time it is until they can NTP, which likely requires protocol adjacencies, and then a dependency loop.
