Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Mar 27, 2014 3:03 PM, John Curran jcur...@istaff.org wrote: And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - that is very much up to this community and its participation far more than ARIN.. /John How about we fold ARIN into RIPE? Why not? I agree with all of Randy's points. I am sure RIPE can easily scale up to take on ARIN services, with fees being reduced for all involved due to economies of scale. CB On Mar 28, 2014, at 5:27 AM, Randy Bush ra...@psg.com wrote: john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. this is not about address policy, but arin thinks of itelf as a regulator not a registry. contrast with the ripe community and the ncc, which is not nirvana but is a hell of a lot better. among other key differences, the ncc is engaged with the community through technical and business working groups. e.g. the database working group covers what you think of as whois and the routing registry. the wg developed the darned irr definition and continues to evolve it. consequence? the irr is actively used in two regions in the world, europe and japan (which likes anything ocd:-). the routing wg works with the ops to develop routing technology such as route flap damping. there is a reason that serious ops attend ripe meetings. yes, a whole lot of folk with enable are engaged. for years there has been a wg on the global layer nine issues. the dns wg deals with reverse delegation, root server ops, etc. and guess what, all the dns heavy techs and ops are engaged. there is a wg for discussing what services the ncc offers. the recent simplification and opening of services to legacy and PI holders happened in the ncc services wg, it was about services not addressing policy. and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. randy
Re: misunderstanding scale (was: Ipv4 end, its fake.)
On Sun, Mar 23, 2014 at 11:27 AM, Philip Dorr tagn...@gmail.com wrote: On Mar 23, 2014 1:11 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote: I was at work last week and because I have IPv6 at both ends I could just log into the machines at home as easily as if I was there. When I'm stuck using a IPv4 only service on the road I have to jump through lots of hoops to reach the internal machines. I expect this to change little in the enterprise space. I think use of ULA and NAT66 will be one of the things enterprises will push for, because how can a printer have a public IPv6 address that is reachable directly from the Internet, despite the fact that there is a properly configured firewall at the perimetre offering half-decent protection? That is what a firewall is for. Drop new inbound connections, allow related, and allow outbound. Then you allow specific IP/ports to have inbound traffic. You may also only allow outbound traffic for specific ports, or from your proxy. i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default. i would hate for people to think that a middle box is required, when the best place to provide security is in the host. Other layers are needed as required, but it is sad that we don't look to the host it self as a first step. CB
Re: misunderstanding scale (was: Ipv4 end, its fake.)
On Sun, Mar 23, 2014 at 12:13 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Sunday, March 23, 2014 09:05:54 PM Cb B wrote: i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default. i would hate for people to think that a middle box is required, when the best place to provide security is in the host. Other layers are needed as required, but it is sad that we don't look to the host it self as a first step. I would support adding security at the host-level, especially because with a centralized firewall, internal infrastructure is usually left wide open to internal staff, with trust being the rope we all hang on to to keep things running. However, if pratical running of the Internet has taught us anything, host-based firewalling (especially in purpose- specific devices like printers, Tv sets, IP phones, IP cameras, e.t.c.) is a long way away from what you can get with a centralized firewall appliance. Do I like it? No. I run a simple packet filter (IPfw) on my MacBook - it does what I need. But we know Joe and Jane won't want things they can't click; and even though they had things they could click, they don't want to have to understand all these geeky things about their computers. Mark. Mark, i think we are largely on the same page. I believe that home firewalls in the residential broadband space are likely the most insecure part of the entire internet. They are very rarely updated with software and frequently ship with terrible terrible bugs, much worse than what we have seen in Windows for the last 10 years. For example, http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd Why try to hack all the devices in your home when the hackers can simply crack your CPE / firewall / router and own all your traffic, reset your DNS server to a malware box, . I am sure this community knows there are many many more problems just like this one in CPE. I don't see a lot of accountability or change in this space, yet people believe these firewalls help. My hope is that folks stop equating firewalls with security, when the first step is to secure the host, accountability is with the host, then layer other tools as needed. CB
Re: Ipv4 end, its fake.
On Mar 22, 2014 12:08 AM, Bryan Socha br...@digitalocean.com wrote: As someone growing in the end of ipv4, its all fake.Sure, the rirs will run out, but that's boring.Don't believe the fake auction sites. Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no spam and $4 for legacy.Stop the inflation. Millions of IPS exist, there is no shortage and don't lie for rirs with IPS left. That's cute that you think millions of ipv4 on the market solves anything for someone who growing end-points ... especially the VM business, you can only sell as many VMs as you have IPv4. Your business is tightly coupled to ipv4, so i understand you *want* to believe. You can pay $3 per ipv4, that is your business. But, it may be worth noting that ATT, Verizon, Comcast, T-Mobile, TWT, Google Fiber all have have double digit ipv6 penetration today. Google, Yahoo, Wikipedia and Facebook all have v6 today, and Facebook is shifting to an ipv6-only data center https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf T-Mobile US is also close to 10% ipv6-only end-points a la rfc6877/464xlat today So, perhaps, what you are saying is, ipv4 address utility has peaked, the price is coming down due to supply/demand forces (less people need ipv4, so more are willing to sell, more sellers with less demand equals lower prices) That said, have a ball with that. I bet there is someone out there that is buying x.25 switches for pennies on the dollar by the pallet. But you may find that performance of ipv4-only service will struggle to get through transition mechansism that are rationing and ipv4 ports ...after all, google and facebook just work on v6, so your ipv4 quality issue may not bubble up so quick. CB
Re: misunderstanding scale (was: Ipv4 end, its fake.)
On Mar 22, 2014 2:32 AM, Bryan Socha br...@digitalocean.com wrote: Oh btw, how many ipv4s are you hording with zero justification to keep them? I was unpopular during apricot for not liking the idea of no liability leasing of v4. I don't like this artificial v4 situation every eyeball network created.Why is v4 a commodity and asset? Where is the audits.I can justify my 6 /14s, can you still? You seem to be missing something, it is called Metcalfe's Law, google it. There is no long-term solution for you using ipv4 and me using ipv6. To derive value from the internet, we all need to be on one technology that supports end to end communication for us all. CB On Mar 22, 2014 4:36 AM, TJ trej...@gmail.com wrote: Millions of IPs don't matter in the face of X billions of people, and XX-XXX billions of devices - and this is just the near term estimate. (And don't forget utilization efficiency - Millions of IPs is not millions of customers served.) Do IPv6. /TJ On Mar 22, 2014 3:09 AM, Bryan Socha br...@digitalocean.com wrote: As someone growing in the end of ipv4, its all fake.Sure, the rirs will run out, but that's boring.Don't believe the fake auction sites. Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no spam and $4 for legacy.Stop the inflation. Millions of IPS exist, there is no shortage and don't lie for rirs with IPS left.
Re: Filter NTP traffic by packet size?
On Tue, Feb 25, 2014 at 8:58 AM, Blake Hudson bl...@ispn.net wrote: I talked to one of our upstream IP transit providers and was able to negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within our aggregate policer. As mentioned, the legitimate traffic levels of these services are near 0. We gave each service many times the amount to satisfy subscribers, but not enough to overwhelm network links during an attack. --Blake Blake, What you have done is common and required to keep the network up at this time. It is perfectly appropriate to have a baseline and enforce some multiple of the baseline with a policer. People who say this is the wrong thing to do are not running a network of significant size, end of story. CB Chris Laffin wrote the following on 2/23/2014 8:58 AM: Ive talked to some major peering exchanges and they refuse to take any action. Possibly if the requests come from many peering participants it will be taken more seriously? On Feb 22, 2014, at 19:23, Peter Phaal peter.ph...@gmail.com wrote: Brocade demonstrated how peering exchanges can selectively filter large NTP reflection flows using the sFlow monitoring and hybrid port OpenFlow capabilities of their MLXe switches at last week's Network Field Day event. http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin claf...@peer1.com wrote: Has anyone talked about policing ntp everywhere. Normal traffic levels are extremely low but the ddos traffic is very high. It would be really cool if peering exchanges could police ntp on their connected members. On Feb 22, 2014, at 8:05, Paul Ferguson fergdawgs...@mykolab.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/22/2014 7:06 AM, Nick Hilliard wrote: On 22/02/2014 09:07, Cb B wrote: Summary IETF response: The problem i described is already solved by bcp38, nothing to see here, carry on with UDP udp is here to stay. Denying this is no more useful than trying to push the tide back with a teaspoon. Yes, udp is here to stay, and I quote Randy Bush on this, I encourage my competitors to block udp. :-p - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M =FTxg -END PGP SIGNATURE-
Re: Filter NTP traffic by packet size?
On Sat, Feb 22, 2014 at 12:38 AM, Carsten Bormann c...@tzi.org wrote: On 22 Feb 2014, at 08:47, Saku Ytti s...@ytti.fi wrote: I'm surprised MinimaLT and QUIC have have not put transport area people in high gear towards standardization of new PKI based L4 protocol, I think its elegant solution to many practical reoccurring problem, solution which has become practical only rather recently. Oh, the transport area people *are* in their high gear. Their frantic movements may just seem static to you as they operate on more drawn-out time scales. (The last transport protocol I worked on became standards-track 16 years after I started working on it.) At this IETF, there will be a Transport Services BOF to help find out what exactly the services are that a new transport protocol should provide to the applications. Research platforms such as QUIC, tcpcrypt, MINION etc. are very much in the focus of attention. This time, it would be nice if the operations people got to have a say early on in what gets standardized. (Just be careful not to try to fight yesterday's war.) Grüße, Carsten yesterday's war = don't bring up that operators are having a real problem with UDP, and that operators have and will continue to block it? Because, i think that is what this thread is about. i did bring yesterday's war to the IETF RTCWweb group and got the expected answer My concern: https://www.ietf.org/mail-archive/web/rtcweb/current/msg11425.html Summary IETF response: The problem i described is already solved by bcp38, nothing to see here, carry on with UDP https://www.ietf.org/mail-archive/web/rtcweb/current/msg11477.html CB
Re: Filter NTP traffic by packet size?
On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher dam...@google.com wrote: On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote: On Feb 20, 2014, at 3:51 PM, John Weekes j...@nuclearfallout.net wrote: On 2/20/2014 12:41 PM, Edward Roels wrote: Curious if anyone else thinks filtering out NTP packets above a certain packet size is a good or terrible idea. From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP server. If I query a server for it's list of peers (ntpq -np ip) I've seen packets as large as 522 bytes in a single packet in response to a 54 byte query. I'll admit I'm not 100% clear of the what is happening protocol-wise when I perform this query. I see there are multiple packets back forth between me and the server depending on the number of peers it has? If your equipment supports this, and you're seeing reflected NTP attacks, then it is an effective stopgap to block nearly all of the inbound attack traffic to affected hosts. Some still comes through from NTP servers running on nonstandard ports, but not much. Also, don't forget to ask those sending the attack traffic to trace where the spoofed packets ingressed their networks. Standard IPv4 NTP response packets are 76 bytes (plus any link-level headers), based on my testing. I have been internally filtering packets of other sizes against attack targets for some time now with no ill-effect. You can filter packets that are 440 bytes in size and it will do a lot to help the problem, but make sure you conjoin these with protocol udp and port=123 rules to avoid collateral damage. Preferably just source-port 123. You may also want to look at filtering UDP/80 outright as well, as that is commonly used as an I'm going to attack port 80 by attackers that don't quite understand the difference between UDP and TCP. Please don't filter UDP/80. It's used by QUIC ( http://en.wikipedia.org/wiki/QUIC). Damian The folks at QUIC have been advised to not use UDP for a new protocol, and they would be very well advised to not use UDP:80 since that is a well known target port used in the DDoS reflection attacks. As Jared noted, UDP:80 is a cesspool today. Attempting to use it for legit traffic is not smart. CB
Re: Filter NTP traffic by packet size?
On Feb 22, 2014 5:30 AM, Damian Menscher dam...@google.com wrote: On Fri, Feb 21, 2014 at 1:22 PM, Cb B cb.li...@gmail.com wrote: On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher dam...@google.com wrote: On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote: You may also want to look at filtering UDP/80 outright as well, as that is commonly used as an I'm going to attack port 80 by attackers that don't quite understand the difference between UDP and TCP. Please don't filter UDP/80. It's used by QUIC ( http://en.wikipedia.org/wiki/QUIC). The folks at QUIC have been advised to not use UDP for a new protocol, and they would be very well advised to not use UDP:80 since that is a well known target port used in the DDoS reflection attacks. Please suggest which protocol has less blocking on the internet today (keeping in mind the full end-to-end stack of CPE, various ISPs, country-level proxies, backbone providers, etc). Damian Tcp. But the actual answer is , if you want a new transport protocol, create a new transport protocol with a new protocol number. Overloading the clearly polluted UDP pool will have problems. Happy eyeballs negotiation may be required for L4. QUIC can do what it wants. Like anyone else, they pay their money and take their chances. But, the data point that UDP is polluted is clearly documented with several folks on this list suggesting tactical fixes that involve limiting UDP, especially udp:80
ddos attack blog
Good write up, includes name and shame for ATT Wireless, IIJ, OVH, DTAG and others http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack Standard plug for http://openntpproject.org/ and http://openresolverproject.org/ and bcp38 , please fix/help. For those of you paying attention to the outage list, this is a pretty big deal that has had daily ramification for some very big networks https://puck.nether.net/pipermail/outages/2014-February/date.html In general, i think UDP is doomed to be blocked and rate limited -- tragedy of the commons. But, it would be nice if folks would just fix the root of the issue so the rest of us don't have go there... Regards, CB
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On Feb 3, 2014 10:23 AM, Paul Ferguson fergdawgs...@mykolab.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/2/2014 2:17 PM, Cb B wrote: And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was ...published 14 years ago (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)? I hope not, because BCP38 filtering would still help stop spoofed traffic now perpetuating these attacks, 14 years after BCP38 was published, because spoofing is at the root of this problem (reflection/amplification attacks). This horse is not dead, and still deserves a lot of kicking. $.02, - - ferg (co-author of BCP38) I completely agree. My sphere of influence is bcp38 compliant. And, networks that fail to support some form of bcp38 are nothing short of negligent. That said, i spend too much time taking defensive action against ipv4 amp udp attacks. And wishing others would deploy bcp38 does not solve today's ddos attacks. CB - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi =W2wU -END PGP SIGNATURE-
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. And, i agree bcp38 would help but that was published 14 years ago. CB -- Jonathan Towne On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: # This evening all of my servers lost NTP sync, stating that our on-site NTP # servers hadn't synced in too long. # # Reference time noted by the local NTP servers: # Fri, Jan 31 2014 19:11:29.725 # # Apparently since then, NTP has been unable to traverse the circuit. Our # other provider is shuffling NTP packets just fine, and after finding an # NTP peer that return routed in that direction, I was able to get NTP back # in shape. # # Spot checking various NTP peers configured on my end with various looking # glasses close to the far-end confirm that anytime the return route is # through AS11351, we never get the responses. Outbound routes almost always # take the shorter route through our other provider. # # Is anyone else seeing this, or am I lucky enough to have it localized to # my region (Northern NY)? # # I've created a ticket with the provider, although with it being the weekend, # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk # response to the monlist garbage. Still, stopping time without warning is # Uncool, Man. # # -- Jonathan Towne #
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 2:54 PM, Matthew Petach mpet...@netflight.com wrote: On Sun, Feb 2, 2014 at 2:17 PM, Cb B cb.li...@gmail.com wrote: On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. Please note that it's not that UDP is at fault here; it's applications that are structured to respond to small input packets with large responses. I dont want to go into fault, there is plenty of that to go around. If NTP responded to a single query with a single equivalently sized response, its effectiveness as a DDoS attack would be zero; with zero amplification, the volume of attack traffic would be exactly equivalent to the volume of spoofed traffic the originator could send out in the first place. I agree the source obfuscation aspect of UDP can be annoying, from the spoofing perspective, but that really needs to be recognized to be separate from the volume amplification aspect, which is an application level issue, not a protocol level issue. Source obfuscation is not annoying. Combined with amplification, it is the perfect storm for shutting down networks... whereby the only solution is to shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, patches boxes, and so on. My point is: dont expect these abbused services on UDP to last. We have experience in access networks on how to deal with abused protocols. Here is one reference http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ My crystal ball says all of UDP will show up soon. CB Thanks! Matt PS--yes, I know it would completely change the dynamics of the internet as we know it today to shift to a 1:1 correspondence between input requests and output replies...but it *would* have a nice side effect of balancing out traffic ratios in many places, altering the settlement landscape in the process. ;)
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 7:41 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/2/2014 9:17 PM, ryang...@gmail.com wrote: I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. We had to burn down the village to save it. Close. More like a hurricane is landing in NYC so we are forcing an evacuation. But. Your network, your call. CB -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
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: 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 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: 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: best practice for advertising peering fabric routes
On Jan 14, 2014 6:01 PM, Eric A Louie elo...@yahoo.com wrote: I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure. All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it as is, and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric Advantages and disadvantages, pros and cons? Recommendations? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. That's another issue completely from a planning perspective. thanks Eric http://tools.ietf.org/html/rfc5963 I like no-export
Re: best practice for advertising peering fabric routes
On Jan 14, 2014 7:13 PM, Patrick W. Gilmore patr...@ianai.net wrote: Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. Doing so endangers your peers the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they can't do this. +1. Rfc5963 needs to update that guidance. Set next hop self loopback0 and done CB -- TTFN, patrick On Jan 14, 2014, at 21:22 , Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Jan 14, 2014 at 9:09 PM, Cb B cb.li...@gmail.com wrote: On Jan 14, 2014 6:01 PM, Eric A Louie elo...@yahoo.com wrote: I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. good plan. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure. All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it as is, and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric 4. all peering-fabric routes get next-hop-self on your peering router before going into ibgp... all the rest of your network sees your local loopback as nexthop and things just work. Advantages and disadvantages, pros and cons? Recommendations? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. That's another issue completely from a planning perspective. thanks Eric http://tools.ietf.org/html/rfc5963 I like no-export
