Re: OpenNTPProject.org
BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard. On 14/01/2014 10:36 AM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/13/2014 11:18 PM, Saku Ytti wrote: On (2014-01-13 21:33 +), Bjoern A. Zeeb wrote: BCP38! I am always surprised when people need crypto if they fail the simple things. Saying that BCP38 is solution to the reflection attacks is not unlike 5 year old wishing nothing but world peace for christmas, endearing, but it's not going to change anything. BCP38 is completely unrealistic, many access networks are on autopilot, many don't have HW support for BCP38, one port configured has low-benefit, only that machine can stop attacking (but whole world). That does *not* make it an unworthy goal, nor should it stop people from encouraging it's implementation. - - ferg (co-author of BCP38) - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs =Al3Y -END PGP SIGNATURE-
Re: Internet Routing Registries - RADb, etc
Eric Krichbaum wrote the following on 1/15/2014 5:30 PM: I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle. Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date. The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects. Eric -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Wednesday, January 15, 2014 3:31 PM To: Blake Hudson; nanog@nanog.org Subject: Re: Internet Routing Registries - RADb, etc On 15/01/2014 21:22, Blake Hudson wrote: I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly (radb-supp...@merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable. I have contacted Merit and found them to be responsive. I will look at securing a spot in ARIN's and RIPE's databases, if possible. Hopefully this will make it unnecessary for someone to post an entry in a 3rd party IRR and possibly more difficult as well. --Blake
Re: OpenNTPProject.org
On Jan 15, 2014, at 12:05 AM, Saku Ytti s...@ytti.fi wrote: (We do BCP38 on all ports and verify programmatically, but I know it's not at all practical solution globally for access). Anti-spoofing is eminently practical for most types of access network topologies using even slightly modern equipment; uRPF, ACLs, cable IP source verify, DHCP Snooping (which works just fine with fixed-address hosts), PACLs/VACLs, et. al. are some of the more prevalent mechanisms available. In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: OpenNTPProject.org
On (2014-01-16 14:30 +), Dobbins, Roland wrote: In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible. We must disagree on definition of practical. Maybe if I'd reword it realistic we might be closer. It is not going to happen, the most suspect places are places where it's going to be most difficult to get, either fully on autopilot with no technical personnel capable or having the power to make the change or ghetto gear with no capability for it. The longer we endorse fantasy the longer it'll take to promote practical solutions. There is nothing near consensus that IP transit should or even can be ACLd, but it's really simple and I'm happy to volunteer my time with any network wishing to implement it. Very modest amount of ports will produce significant reduction in spoofing pay-off. -- ++ytti
Re: OpenNTPProject.org
On Jan 16, 2014, at 9:56 PM, Saku Ytti s...@ytti.fi wrote: It is not going to happen, the most suspect places are places where it's going to be most difficult to get, either fully on autopilot with no technical personnel capable or having the power to make the change or ghetto gear with no capability for it. That may well be the case, unfortunately; my point was that at or near the access edge is the most *technically* and *topologically* feasible place to implement antispoofing mechanisms, as you indicated in your reply. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
trivial changes to DNS (was: OpenNTPProject.org)
On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: Proxy ARP detection
* c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 01:25 CET]: On Jan 15, 2014, at 4:03 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it’s something that only happens when proxy ARP is enabled? Maybe. I don't think I've ever dealt with a situation in which Proxy ARP was enabled on a Juniper router. I've certainly not seen them reply to a request with a broadcast, and frankly that sounds like such a weird implementation decision that I'm going to need to see pcaps before I believe it. Even if this were a regular occurrence - which it evidently is not - it's still better to trigger this when you know you're doing something rather than have to step in later when another misconfiguration triggers routing problems like described in an earlier mail, renumbering into a larger subnet. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 2:27 PM, Andrew Sullivan asulli...@dyn.com wrote: On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? Perhaps the problem with EDNS0 is exactly its backward compatibility. A parallel protocol adopted by the usual suspects of authoritative and recursive names servers that at some point becomes required for query volumes larger than x qps could account for most of name resolution on the planet in much less than 10 years. Rubens
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:27 AM, Andrew Sullivan asulli...@dyn.com wrote: On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? pretty easy to believe that quic would be helpful right? especially if you were interested in: 1) keeping resource utilization down/same on dns servers 2) rtt and latency impacts of extra rtt on upper layer protocols 3) the Xmillions of embedded devices that end users rely upon for dns in their homes seems totally feasible. -chris
Re: Proxy ARP detection
Cisco ASA's still have proxy ARP enabled by default when certain NAT types are configured. http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_objects.html Default Settings (8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot configure this setting. (8.4(2) and later) The default behavior for identity NAT has proxy ARP enabled, matching other static NAT rules. You can disable proxy ARP if desired. See the Routing NAT Packets section for more information. On 1/15/2014 7:54 PM, Eric Rosen wrote: Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. - Original Message - On Jan 15, 2014, at 4:03 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it’s something that only happens when proxy ARP is enabled? -c -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. People who believe there are going to be easy fixes to the issues coming from DNS are deluding themselves. A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. People who believe there are going to be easy fixes to the issues coming from DNS are deluding themselves. I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. So... what other options are there to solve the larger problem of: Some service is running on a public host, and it can be used to attack a third party where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet. -chris
Re: Proxy ARP detection
* vrist...@ramapo.edu (Vlade Ristevski) [Thu 16 Jan 2014, 17:46 CET]: Cisco ASA's still have proxy ARP enabled by default when certain NAT types are configured. That wasn't the question. The question was what equipment would send proxy ARP replies as broadcasts, possibly causing poisoning in other routers (which still sounds far-fetched to me). -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! So... what other options are there to solve the larger problem […] If I knew, I'd run out an implement it rather than talk about it! A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: Proxy ARP detection
I seem to recall some video encoders doing that, but I can't remember the vendor. Sent from my Mobile Device. Original message From: Niels Bakker niels=na...@bakker.net Date: 01/16/2014 8:54 AM (GMT-08:00) To: nanog@nanog.org Subject: Re: Proxy ARP detection * vrist...@ramapo.edu (Vlade Ristevski) [Thu 16 Jan 2014, 17:46 CET]: Cisco ASA's still have proxy ARP enabled by default when certain NAT types are configured. That wasn't the question. The question was what equipment would send proxy ARP replies as broadcasts, possibly causing poisoning in other routers (which still sounds far-fetched to me). -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 9:08 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! So... what other options are there to solve the larger problem […] If I knew, I'd run out an implement it rather than talk about it! A Well. These reflection attacks have something in common. The big ones (chargen, dns, ntp) are all IPv4 UDP. And these are all *very* big. I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. CB -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: Internet Routing Registries - RADb, etc
On 16/01/2014 14:32, Blake Hudson wrote: Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable. Oh yeah. I got hit by that sort of thing a week or two back. It wasn't origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been hijacking chunks of space from the various registries. Nick
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. Best regards, A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 9:31 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. I white listed google and facebooks auth servers, so its cool. CB Best regards, A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:39:46AM -0500, Andrew Sullivan wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds
Probably not a bug, but par for their technical prowess. The SpamTeq website includes your account number and password in every URI. I'm not sure I'd trust a company that does something as terrible as that to practice good coding elsewhere and not cause major damage with their data feeds. -richard On Fri, Jan 10, 2014 at 6:15 AM, Eric Tykwinski eric-l...@truenet.comwrote: Looks like a bug, if you stick a 1 in total email users: Per Year: $504.00 -Original Message- From: Adam Greene [mailto:maill...@webjogger.net] Sent: Friday, January 10, 2014 9:11 AM To: 'NANOG Mailing List' Subject: RE: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Hi TR, This looks like a very promising service to me as well. Could you hit me off list with the pricing contact? The pricing on http://www.spamhaustech.com/datafeed/pricecalculator.lassois a little high ($9,223,372,036,854,780,000.00/yr). :) Thanks, Adam -Original Message- From: TR Shaw [mailto:ts...@oitc.com] Sent: Thursday, January 09, 2014 5:49 PM To: Bryan Socha Cc: NANOG Mailing List Subject: Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Replied off list. On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: I would also like that contact, i've been trying to get the same quote for feed only for months. Thanks, Bryan
Re: trivial changes to DNS (was: OpenNTPProject.org)
On 16 Jan 2014, at 17:30 , Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. Why not? .org and nanog.org have IPv6-enabled DNS, mailman.nanog.org has an IPv6 address. What else do you need to reply to this list? — Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, ??? ? ?? ?, ?.???
Re: trivial changes to DNS (was: OpenNTPProject.org)
On (2014-01-16 09:19 -0800), Cb B wrote: I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't add support to it, because failure rate is too high, and stateful box vendors won't add support, because no customer demand. And what becomes to deployment pace, good technologies which give benefits to end users can and have been deployed very fast. IPv6 does not give benefit to end users, EDNS does not give benefit to end users. QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end users, all persistent connections like ssh would keep running when you jump between networks. You could in your homeserver specifically allow /you/ to connect to any service, regardless of your IP address, because key is your identity, not your IP address. (So sort of LISPy thing going on here, we'd make IP more low-level information which it should be, it wouldn't be identity anymore) Parity packets have potential to give much better performance in packet loss conditions. Packet pacing seems much better on fast to slow file transfers. -- ++ytti
[NANOG-announce] NANOG Reminders
Colleagues: A few reminders regarding the Education Series, Routing Fundamentalshttps://www.nanog.org/meetings/education/routing_fundamentals_class/home, class Sunday, February 9, 2014 and NANOG 60https://www.nanog.org/meetings/nanog60/home, February 10-12, 2014 in Atlanta, GA. In addition to the exciting NANOG 60 activities, NANOG is offering an Educational Series class Routing Fundamentals on Sunday, February 9, 2014. This is a great opportunity for folks who would like to advance their Network Operations Career. Registration remains open, and does include a One (1) day NANOG 60 meeting registration. The Program Committee delivered another great NANOG meeting agendahttps://www.nanog.org/meetings/nanog60/agenda. The NANOG 60 program includes a Keynote address Monday morning, presentations on Security, BGP, Performance Measurement, IPv6, and the ever popular Data Center and Peering tracks. Don't delay, register soon as early Registrationhttps://www.nanog.org/meetings/nanog60/registrationends on January 24, 2014, (non-member $450, member $425, student $100), If you, or someone you know, might benefit from a bit of help with travel to attend NANOG 60, please be sure to check out the NANOG Fellowship programhttps://www.nanog.org/resources/fellowships. Don't delay, NANOG 60 selections will be awarded soon. The Education class and NANOG 60 will take place at the Westin Peachtree Plaza. Make your room reservationshttps://www.nanog.org/meetings/nanog60/hotelinformation soon, the room rate of $169. expires, Friday, January 24, 2014. There are a few NANOG 60 Sponsorship Opportunitieshttps://www.nanog.org/sponsors/opportunities remaining. Be sure to contact the NANOG Development Committee via marketing@nanog.orgto reserve your opportunity. Should you have any questions regarding NANOG activities, feel free to send your message to nanog-supp...@nanog.org. We look forward to seeing you in Atlanta! Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 ___ NANOG-announce mailing list nanog-annou...@mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 10:16 AM, Saku Ytti s...@ytti.fi wrote: On (2014-01-16 09:19 -0800), Cb B wrote: I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't add support to it, because failure rate is too high, and stateful box vendors won't add support, because no customer demand. And what becomes to deployment pace, good technologies which give benefits to end users can and have been deployed very fast. IPv6 does not give benefit to end users, EDNS does not give benefit to end users. QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end users, all persistent connections like ssh would keep running when you jump between networks. You could in your homeserver specifically allow /you/ to connect to any service, regardless of your IP address, because key is your identity, not your IP address. (So sort of LISPy thing going on here, we'd make IP more low-level information which it should be, it wouldn't be identity anymore) Parity packets have potential to give much better performance in packet loss conditions. Packet pacing seems much better on fast to slow file transfers. -- ++ytti Then let's go all the way with ILNP. I like that. CB
Re: Internet Routing Registries - RADb, etc
On 16/01/2014 14:32, Blake Hudson wrote: Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable. Oh yeah. I got hit by that sort of thing a week or two back. It wasn't origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been hijacking chunks of space from the various registries. Nick -- Another possible scenario. a.b.c.d/24-small_isp-regional_isp-Level3 Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don’t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. a.b.c.d/24-small_isp-new_regional_isp-Level3 or a.b.c.d/24-new_small_isp-new_regional_isp-Level3 The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn’t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate?
Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds
In article 030101cf0e0e$71088af0$5319a0d0$@truenet.com you write: Looks like a bug, if you stick a 1 in total email users: Per Year: $504.00 No, that's right. If you're a tiny little network, you can use the public DNS servers for the BL lookups, and you can FTP the text version of DROP and turn in into firewall rules or whatever. That's what I do (hack perl scripts available on request.) The BGP feed is intended for networks large enough to need BGP. R's, John
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 12:55:18PM -0500, Jared Mauch wrote: I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. You could also (and for most cases, I recommend you do) enable the Response Rate Limiting patches available on most of the open-source authoritative servers. Sorry I didn't think to mention it earlier. I thought everyone already knew that. But it does appear to help. A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: So... what other options are there to solve the larger problem of: Some service is running on a public host, and it can be used to attack a third party where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet. Standardizing some UDP service-neutral PRE-Authentication system comes to mind; operating at the host level, independent of the various services, requiring the client to perform at least as much work as the response packet. E.g. Fwknop Single-Packet Authentication/Port-Knocking Style The application doesn't see any UDP packets from a source:port number pair, until a source address authenticity event occurs, for that source ip:port number pair. Say instead of port knocking though, the client is required to estimate the size of the response to its first round trip of UDP request messages. Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. UDP response packets and new queries above the estimated initial reply size or after the 5th packet are delayed until definitive confirmation or silently dropped, instead of returned to the claimed source. -chris -- -JH
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, 16 Jan 2014 13:35:00 -0600, Jimmy Hess said: Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. How is this any better than a TCP 3-packet handshake with syncookies? pgpBLWmPZkfD_.pgp Description: PGP signature
Re: Internet Routing Registries - RADb, etc
courtneysm...@comcast.net wrote the following on 1/16/2014 12:26 PM: On 16/01/2014 14:32, Blake Hudson wrote: Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable. Oh yeah. I got hit by that sort of thing a week or two back. It wasn't origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been hijacking chunks of space from the various registries. Nick -- Another possible scenario. a.b.c.d/24-small_isp-regional_isp-Level3 Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don’t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. a.b.c.d/24-small_isp-new_regional_isp-Level3 or a.b.c.d/24-new_small_isp-new_regional_isp-Level3 The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn’t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate? I can understand the scenarios you've described. In fact, the timing does seem to indicate that someone was thinking they were doing something helpful (the route objects were introduced around the time we started announcing the allocation). The part that doesn't make sense is that one of the route objects has valid information and the other three were entered for AS #'s that are not peers of ours and should not have ever been transit paths to L3. We do peer with folks that peer with L3, however the route objects in L3's databases are for different ASs. I'm glad that ARIN provides an IRR, and hope to use it. With an authority that actually has the information necessary to perform authorization checks, I'm not sure why there's a need for independent IRRs to exist. Perhaps they filled a gap at some point in the past? --Blake
Re: trivial changes to DNS (was: OpenNTPProject.org)
We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds
On Thu, Jan 16, 2014 at 11:04 AM, John Levine jo...@iecc.com wrote: If you're a tiny little network, you can use the public DNS servers for the BL lookups, and you can FTP the text version of DROP and turn in into firewall rules or whatever. That's what I do (hack perl scripts available on request.) Here's working Bash script to sync the freely available DROP/EDROP lists into a quagga/linux route server. https://gist.github.com/dotysan/8463112 I ran that awhile back without issue. But not anymore. Last year I added the $250/yr BOTNETCC list which is BGP-only. And it was too convenient to move the DROP/EDROP lists into BGP for an additional $250. It works as advertized. The BOTNETCC list is only v4/32s and more dynamic than the other lists. It's up to you to set it up correctly so an accident doesn't blackhole your own prefixes...or favorite offshore gambling site. :-p ../C
RE: Internet Routing Registries - RADb, etc
On Wed, 15 Jan 2014, Eric Krichbaum wrote: I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle. Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date. The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects. Also, at least of the ones I've dealt with, there is no verification of records as they're entered. If your ASN/IPs are not already there, anyone can put them in under their own maintainer object. Since some providers do use IRR data to build and maintain customer prefix filters, it's not unusual for service providers to put customer ASNs/IPs into an IRR on behalf of their customers...and when the customer leaves, there's really no incentive to clean up and remove the objects. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Internet Routing Registries - RADb, etc
On 16/01/2014 21:22, Jon Lewis wrote: Also, at least of the ones I've dealt with, there is no verification of records as they're entered. on the RIPE IRRDB, there is validation, so you can't just go in and register route: objects for someone else's allocations or assignments. Not sure about the other RIRs, except for ARIN which doesn't support this on rr.arin.net. Nick
Re: OpenNTPProject.org
In message 52d7e98b.4040...@userid.org, Pierre Lamy writes: BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard. Except the targets are *everybody* including the access networks. This really is if you are not part of the solution, you are part of the problem and applies 100% to access networks. And it doesn't require governments, it just requires CEO's with the gumption to say we are not going to accept routes from you, via transit or direct, until you publically state that you are implementing BCP38 within your network and then follow through. If you implement BCP the publish the fact on you sites. This lets others know they are not alone in the fight to make the net a better place. e.g. We implement BCP 38 on XX% of customer links We implement BCP 38 on all of our single homed customers We implement BCP 38 on all our data centers traffic We implement BCP 38 on all our NOC traffic We implement BCP 38 on all our outgoing traffic We implement BCP 38 on all our traffic Machines get owned everywhere including data centers and NOCs. BCP 38 filters should be everywhere. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Internet Routing Registries - RADb, etc
On 2014-01-16 23:11, Nick Hilliard wrote: On 16/01/2014 21:22, Jon Lewis wrote: Also, at least of the ones I've dealt with, there is no verification of records as they're entered. on the RIPE IRRDB, there is validation, so you can't just go in and register route: objects for someone else's allocations or assignments. You mean auth for RIPE region prefixes, as one can also register ARIN/APNIC/etc prefixes in the RIPEdb and then, there is no auth (but a mail to d...@ripe.net resolves any issues quite quickly if something fake is there) Greets, Jeroen
Re: OpenNTPProject.org
--- ma...@isc.org wrote: In message 52d7e98b.4040...@userid.org, Pierre Lamy writes: BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard. Except the targets are *everybody* including the access networks. This really is if you are not part of the solution, you are part of the problem and applies 100% to access networks. And it doesn't require governments, it just requires CEO's with the gumption to say we are not going to accept routes from you, via transit or direct, until you publically state that you are implementing BCP38 within your network and then follow through. Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, What's the business case? Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... scott
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What would your fix be for the Chargen and SNMP protocols? -- Mark Andrews, ISC -- -JH
Re: OpenNTPProject.org
On 01/16/2014 03:45 PM, Scott Weeks wrote: Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, What's the business case? What I've tried to explain to people is that not being used as a botnet will reduce their outbound traffic. It's not much, but it's something. Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Just have the NSA paint it as a national security issue. :) Doug
Re: OpenNTPProject.org
--- do...@dougbarton.us wrote: From: Doug Barton do...@dougbarton.us On 01/16/2014 03:45 PM, Scott Weeks wrote: Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, What's the business case? What I've tried to explain to people is that not being used as a botnet will reduce their outbound traffic. It's not much, but it's something. -- Maybe it's just Hawaii, but many managers I've had would not be able to understand the importance of that. CEOs? ferget it! Plus I've done only eyeball networks since the early 2000s, so outbound is orders of magnitude lower than inbound and that also means I'm probably biased. I do those things trying to be a good netizen, but I don't tell the managers. It's not even on their radars. Further, I have met a lot of enterprise-level network folks along the way that don't know and/or just don't care. Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Just have the NSA paint it as a national security issue. :) -- Since they're p0wning the entire internet globally that's one way to get it implemented, I suppose... :) scott
Re: trivial changes to DNS (was: OpenNTPProject.org)
In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Proxy ARP detection
On Thu, Jan 16, 2014 at 10:51 AM, Niels Bakker niels=na...@bakker.netwrote: That wasn't the question. The question was what equipment would send proxy ARP replies as broadcasts, possibly causing poisoning in other routers (which still sounds far-fetched to me). Which current routers will actually _listen_ to a broadcast ARP response involving an IP address that is outside the subnet assigned to that IP interface, and override the routing table with that entry? -- -J
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote: In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. Somebody has it on. I can confirm multi gb/s size chargen attacks going on regularly. I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big problem here and now CB SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: trivial changes to DNS (was: OpenNTPProject.org)
In message CAD6AjGTE-raK1AnFha+tz+WQGAuUrB7Pr0vfc3J=qnhfu63...@mail.gmail.com , Cb B writes: On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote: In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. Somebody has it on. I can confirm multi gb/s size chargen attacks going on regularly. I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big problem here and now So go and *report* the traffic streams so that chargen service can be turned off or if the box doesn't support that, the box is replaced / filter. I don't know anyone that *needs* chargen turned on all the time. Most *never* need it to be turned on. India was just declared polio free. Fixing chargen is easier than that. Step 1. make sure you do not have chargen sources. Step 2. report traffic. Step 3. stop accepting all traffic to/from the if step 2 does not help. Mark CB SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org --047d7bfd030c59198804f02057ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable p dir=3Dltrbr On Jan 16, 2014 5:10 PM, quot;Mark Andrewsquot; lt;a href=3Dmailto:mar= k...@isc.orgma...@isc.org/agt; wrote:br gt;br gt;br gt; In message lt;a href=3Dmailto:CAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqw= nxrsud55%2bh9...@mail.gmail.comCAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqwNXrsu= d55+h9...@mail.gmail.com/agt;br gt; , Jimmy Hess writes:br gt; gt; On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews lt;a href=3Dmail= to:ma...@isc.orgma...@isc.org/agt; wrote:br gt; gt;br gt; gt; gt; We don#39;t need to change transport, we don#39;t need to = port knock. =A0Webr gt; gt; gt; just need to implementent a slightly modified dns cookies wh= ichbr gt; gt; gt; reminds me that I need to review Donald Eastlake#39;s new d= raft to be.br gt; gt; gt;br gt; gt;br gt; gt; But a change to DNS doesn#39;t solve the problem for the other t= housand or sobr gt; gt; UDP-based protocols.br gt;br gt; What thousand protocols? =A0There really are very few protocols widely= br gt; deployed on top of UDP.br gt;br gt; gt; What would your fix be for the Chargen and SNMP protocols?br gt;br gt; Chargen is turned off on many platforms by default. =A0Turn it offbr gt; on more. =A0Chargen loops are detectable.br gt;/p p dir=3DltrSomebody has it on. /p p dir=3DltrI can confirm multi gb/s size chargen attacks going on regul= arly. /p p dir=3DltrI agree. More chargen off, more bcp 38, but ...yeh.. chargen= is a big problem here and now/p p dir=3DltrCB/p p dir=3Dltrgt; SNMP doesn#39;t need to be open to the entire world. = =A0It#39;s not likebr gt; authoritative DNS servers which are offering a service to everyone.br= gt;br gt; New UDP based protocols need to think about how to handle spoofbr gt; traffic.br gt;br gt; You look at providing extending routing protocols to providebr gt; information about the legitimate source addresses that may be emitted= br gt; over a link. =A0SIDR should help here with authentication of the data.= br gt; This will enable better automatic filtering to be deployed.br gt;br gt; You continue to deploy BCP38. =A0Every site that deploys BCD is onebr= gt; less site where owened machines can be used to launch attacks from.br= gt;br gt; Markbr gt; --br gt; Mark Andrews, ISCbr gt; 1 Seymour St., Dundas Valley, NSW 2117, Australiabr gt; PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: a hr= ef=3Dmailto:ma...@isc.org;ma...@isc.org/abr gt;br /p
BCP38.info (was: Re: OpenNTPProject.org)
- Original Message - From: Scott Weeks sur...@mauigateway.com And it doesn't require governments, it just requires CEO's with the gumption to say we are not going to accept routes from you, via transit or direct, until you publically state that you are implementing BCP38 within your network and then follow through. Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, What's the business case? Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Then we aren't doing our educational job correctly. In part, that's my fault, because I dropped the ball on http://www.bcp38.info So let me pick the ball back up: would everyone who has asserted in this thread that BCP38 is the New Hawtness from 20 years ago, please take 30 minutes out of your weekend, and go find a place 'pon that wiki that you can usefully apply a Vulcan Nerve Pinch to make it more suitable for us to wave in front of the faces of the people about whom Scott is concerned here? I have just rewritten the front page a bit, in recognition of the fact that as it was, it did not really address that audience itself, but more detail work on the interior about who should enable BCP38 filtering, how they can do it, and why they don't -- and why those reasons are spurious -- would be very helpful. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Windows Update subnets
Does anyone have a list of all of the ranges Microsoft uses for Windows Update? I've found domains but not a full list of subnets.
Re: Windows Update subnets
I think you'll find that windows update heavily leverages 3rd party CDN providers as well as their own... http://technet.microsoft.com/en-us/library/cc627316.aspx On 1/16/14, 11:04 PM, shawn wilson wrote: Does anyone have a list of all of the ranges Microsoft uses for Windows Update? I've found domains but not a full list of subnets. signature.asc Description: OpenPGP digital signature
