Re: US patent 5473599
The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting. Todd On 5/6/2014 6:51 PM, Jared Mauch wrote: On May 6, 2014, at 9:11 PM, Constantine A. Murenin muren...@gmail.com wrote: On 6 May 2014 15:17, David Conrad d...@virtualized.org wrote: Constantine, On May 6, 2014, at 4:15 PM, Constantine A. Murenin muren...@gmail.com wrote: Protocol 112 was assigned by IANA for VRRP in 1998. When did OpenBSD choose to squat on 112? If you don't use it, you lose it. Are you suggesting no one is running VRRP? Surprising given RFC 5798. By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. Your point being? That the BSD community sometimes doesn't play well with others, and certainly won't fess up when they make a mistake and cause collateral damage. It's clear to me this discussion is becoming a losing prospect for all sides, it reminds me of all the small ways the BSD community has frustrated me, from not fixing defects found in -RC images that would prevent successful upgrades due to driver bugs to lack of hardware support. There are only so many protocol numbers; out of those potentially available and non-conflicting, Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned. it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise. Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. Can you explain why exactly do you find this odd? Because it's further polluting the ecosystem that we all depend on to operate properly. Asking for a number shouldn't be that hard and there are many people who can help shepherd these things through the community. The problem is when folks just squat on numbers and don't move. There have been collisions over the years that one can see documented in /etc/services on hosts that have been worked around, this isn't the first time, nor i'm sure will it be the last. VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else. Yes, I think the issue here is that CARP is the interloper. You don't mind me coming over and bringing my trash to your back yard do you? To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a cute (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP). Any complaints for Google using the https port 443 for SPDY? AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those? I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more thanks vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here. or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
Bill - anything that puts another routable network alongside of the card processing info is in scope. The real; issue is that the PCI-SSC decided to formally create a policy to hold the auditors harmless in their actions and that is about to change. Todd On 5/1/2014 8:52 AM, William Herrin wrote: On Thu, May 1, 2014 at 6:29 AM, Alain Hebert aheb...@pubnix.net wrote: Bill Telnet... I hope that QSA didn't let you keep that telnet facing any public interface without any protection. Hi Alain, The point I made, successfully, was that it was outside the firewall hence out of scope for the audit. What I do in a different security domain from the one which handles the credit card transactions is none of their business. Regards, Bill Herrin -- - Personal Email - Disclaimers Apply
Re: What Net Neutrality should and should not cover
On 4/27/2014 9:57 AM, Rick Astley wrote: I wish you would expand on that to help me understand where you are coming from but what I pay my ISP for is simply a pipe, I don't know how it would make sense logically to assume that every entity I communicate with on the Internet must be able to connect for free because I am covering the tab as a subscriber. 0)No you're not. What you are covering is a percentage of the aggregate use model - the problem is what happens when you using 3% of your local end-node service capability run into the other 300 people who want to do the same. The use fees dont cover the bulk transit that is generally controlled through backhaul agreements so... I am not talking about JUST Netflix here as they are a large company more capable than some smaller ones at buying their own pipes out to the world. 1) The pipe issue is that of the last mile providers and not Netflix. The issue is the failure of the IETF to put controls in place which address this. It would be sort of the same concept of my grandmother calling my cell phone yet we both need to pay for our individual phone lines to at least reach the carrier tasked with connecting our call. Even if my grandmother calls a business, that business have phone lines they pay for. Technically this would be double dipping but it's been the norm for a very long time. How so? You are paying for the individual routing of data to that independent end node per the contract. If Grandma's cell and yours was covered under the same use contracts or shared minutes contract then that would make sense but otherwise they are independent services and whether that person is family or not they are a separate account - and billing. Hence 2 bills there. 2)The idea pertains to the concept that everyone has a digital persona and that persona is legally real, i.e. it has similar rights to their physical persona. In places like France this is now law. Now if we will lets talk about where this concept falls apart. Pretend I run a lemonade stand and my ISP offers to give it free Internet access, how generous of them! I then meet a businessman from town who is complaining about what it costs him to connect to the Internet because he has a lot of equipment that serves data to people all over the place. I see this as an opportunity to make more money and I say hey, they don't charge me at all for Internet access I will make you a deal, I will connect your equipment to them for 1/3 what you are paying today. Good deal says the businessman. I eagerly ride my bicycle home, pick up my phone, call my ISP and tell them the news Hey, thanks for the free service but I need you to upgrade my connection x5 because I decided to do content delivery for the businesses in town. Oh hell no says my ISP, that was not at all the agreement, your lemonade stand is still free but if you want us to carry the extra traffic you have to buy more ports the same as everyone else. 3)So the other issue is the Use Contract you have most likely has a no-commercial or minimum commercial use clause in the licensing agreement. Likely also a no-resale as a service as well in the same agreement so what they actually say is How long have you been doing this? and you reply you have been testing it for a month now. So they send you a bill and when you as the Lemonade stand operator get it and choke, and then call them - they say have you read the no resale clause in the contract? and its over. I didn't build a successful lemonade stand because I take being treated like this sitting down! Our now much larger volume of traffic is slow to the ISP and they are refusing to upgrade it for free, so I call up the media and have them run a story about how the ISP is intentionally limiting our traffic and they simply need to upgrade it for free. 4)Yes you do - and you scream how this is also racial profiling because anyone who hates lemonade is unAmerican or un-something. People are already paying for the Internet, if they don't give me my free ride they are double dipping! How so - how are people already paying for the service you are now talking about selling which you are taking from someone else in violation of their provisioning agreement? Public opinion is in, that mean ISP should be giving me my free access but the reality of the situation is perhaps a bit different. My lemonade stand pulled a coup when it became a content provider and demanded a free ride, and railroading my ISP for it in the media was probably a dishonest thing to do. How so? Again - your stand is a bandwidth thief and your business is breaking the terms of its end-user agreement with the ISP as well. I reluctantly agree to pay them for ports for content I am delivering but local businessman from my town has tasted blood and he's not done yet Who else has a lemonade stand with free Internet?! he proclaims. I changed some names to protect the Innocent :)
Re: US patent 5473599
Henning I understand your work is important - and that its open source but that is part of the problem with global patent law today. No one wants it around when their works are impacted by it. But patent publications are binding under the treaties and in fact CARP clearly is an infringement. The issue is what to do do about it. Todd Glassey On 4/23/2014 9:47 AM, Henning Brauer wrote: * Paul WALL pauldotw...@gmail.com [2014-04-22 19:30]: Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made). we're an open source project, running on a rather small budget almost exclusively from donations, so quite reasonable doesn't cut it. The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck. you're interpreting way too much in here. carp has been based on an earlier, never published vrrp implementatoin we had before realizing the patent problem. i don't remember any discussion about the OUI or, more general, the mac address choice. it's 10 years ago now, so i don't remember every single detail, changing the mac addr has pbly just been forgotten. not at least using sth but 00:01 for the 4th and 5th octet was likely a mistake. changing that now - wether just 4th/5th octet or to an entirely different, donated OUI - wouldn't be easy, unfortunately. acadmic discussion as long as we don't have a suitable OUI anyway. If either of these decisions had not been made, we would not be having this discussion today. we weren't really given a choice. as I said before, I'd much prefer we had just been given a multicast address etc. we tried. the IEEE/IETF/IANA processes have been an utter failure in our (limited) experience, not just in this case. might be different if you're $big_vendor with deep pockets, but that doesn't help either. fortunately this obviously isn't a big problem in practice, based on the fact that we don't get any complaints/reports in that direction. still would be way micer if that situation had been created in the first place, but as said - we weren't given that choice. Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. huge? nah. mistake? probably. If your lawyers have advised you not to apologize because of liability concerns (despite that no warranty bit in the BSD license) it's OK - I completely understand. you live in a bizarre world apparently. but then, that's what the US (dunno wether that is your actual background, sounds that way tho) is when it comes to patents and liability in the eyes of the rest of the world. neither of us can change that, so be it. and just to prevent confusion: I didn't implement most of carp, but was involved, and I wasn't the one dealing with IANA/IETF/whatever either. No pun intended if I mixed up IETF, IANA, IEEE somewhere here, it's not like we create new protocols every other day. -- - Personal Email - Disclaimers Apply
Re: DNS Issue with proofpoint.com
Wouldn't it make sense if we created a specific mail alias for requesting DNS flushes? This seems to happen statistically often enough it might be a valuable service to bundle under the NANOG umbrella. Todd On 4/16/2014 2:27 AM, Jaren Angerbauer wrote: All, Sending this out (to multiple lists -- apologies for the potential duplicates) in the hopes to proactively resolve any mail flow issues to / from Proofpoint customers. Earlier this evening, we had some DNS issues with our domain (proofpoint.com). We've resolved the main problem, however, due to old cached DNS information, the fall out now is that *many* (i.e. hundreds at this point) customers are are seeing major email delays. For any DNS operators, it would be much appreciated if you could flush your DNS servers for proofpoint.com. Among other providers, we are still seeing delays with mail flow to ATT Wireless and Verizon Wireless. Thanks in advance for your assistance on this. Jaren Angerbauer Deliverability ISP Relations Manager Proofpoint -- - Personal Email - Disclaimers Apply
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
BAE did this cute poster on the attack model https://image-store.slidesharecdn.com/6f0027d2-c58c-11e3-af1f-12313d0148e5-original.jpeg?goback=%2Egde_1271127_member_5862330295302262788 On 4/16/2014 7:50 PM, Barry Shein wrote: On April 17, 2014 at 10:03 g...@gdt.id.au (Glen Turner) wrote: Jason Iannone wrote: I can't cite chapter and verse but I seem to remember this zeroing problem was solved decades ago by just introducing a bit which said this chunk of memory or disk is new (to this process) and not zeroed but if there's any attempt to actually access it then read it back as if it were filled with zeros, or alternatively zero it. Actually those were my words trying to describe kernel management of disk blocks, sparse files, etc, not user space. -b -- - Personal Email - Disclaimers Apply
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Yes Matthew it should. The question is whether they do or not. Todd On 4/14/2014 7:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. matthew black california state university, long beach -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Sunday, April 13, 2014 7:31 AM To: Bengt Larsson Cc: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] It's quite plausible that they watch the changes in open-source projects to find bugs. They could do nice diffs and everything. the point of open source is that the community is supposed to be doing this. we failed. randy -- - Personal Email - Disclaimers Apply
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Vladis is %100 on the money here. Lets take this a step farther and ask is there a criminal liability for the person who checked that code in - Oh you bet there is... Todd On 4/11/2014 5:49 PM, valdis.kletni...@vt.edu wrote: On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: The interesting thing to me is that the article claims the NSA have been using this for over two years, but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA found it *amazingly* quickly (they're very good at what they do, but I don't believe them have superhuman talents); or You seriously think the NSA *isn't* watching the commits to security-relevant open source? Remember - it was a bonehead bug, it's *not* unreasonable for somebody who was auditing the code to spot it. Heck, there's a good chance that automated tools could have spotted it. -- - Personal Email - Disclaimers Apply
Re: Level 3 blames Internet slowdowns on Technica
I want to ask you folks something... How do you as the people operating the network think two exabytes of data gets pushed across your networks to each of the PRISM Collection Sites (daily) with no one noticing... Know what I mean? Todd Glassey On 3/21/2014 6:54 PM, Larry Sheldon wrote: On 3/21/2014 9:13 AM, Sholes, Joshua wrote: How do you get around the problem of natural monopolies, then? My strongly held belief is that if the natural monopoly* becomes oppressive somebody in their garage will find another way, and absent regulation and force of arms available to the natural monopoly, eliminate the monopoly situation and maybe the natural monopolist. Or should we be moving to a world where, say, a dozen or more separate companies are all running fiber or coax on the poles on my street in an effort to get to my house? Could be--we have two energy companies at our house. And two communications companies have boxes on the back wall. Beyond the piped-in water service, we have several competing beverage sources (including for water) in service. The house across the street has, it appears, at least three companies providing TV service (and Internet service?). Three outfits provide waste disposal service in the neighborhood, although I am not bright enough to see a competitor for the sewage component. I wasn't bright enough to see the World Wide Web, either. Nobody uses poles. IMHO, the only way to get real competition on the last mile is to have the actual fiber/wire infrastructure being owned by a neutral party that's required to pass anyone's traffic. As soon as required is in the discussion, we have a monopoly, and a monopoly has the power to abuse the situation. Wire and glass are not the only media available, as if that mattered. And we already have duplicates; what is the big deal? OH! And the reason why one set of wires is idle, is that provider got beat by the completion on the other set. (For this discussion, coaxial cable is a set of wires.) *too old, failing memory and all, I'll have to go read up on natural monopoly--I can not think of one that does not require regulation and force of arms to exist. -- - Personal Email - Disclaimers Apply
Re: Filter NTP traffic by packet size?
Type Enforcement in the OS Kernel is the place to do that. Todd On 2/20/2014 2:12 PM, Damian Menscher 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 -- - Personal Email - Disclaimers Apply
You need a VLAN to the foot of NIST ITS services - no problem - we got you covered. Re: Need trusted NTP Sources
Raspberry Pi --- This unfortunately doest give you trusted time. It gives you David's Raspberry Pi with an Adafruit Ultimate GPS breakout board which is a waste of time if you need an evidence grade of time service. It also means you assemble it and run it yourself. If you need access to NTP - we can handle that --- As to how to get NTP into your networks - why screw around??? What do you need - your own VLAN into the back of the switch hosting the NIST ITS server... yeah no problem. Go to the source and join USTiming.ORG and use our landing switch to cross connect your network into a VLAN type management network bringing NIST ITS services to the perimeter of your network - poof - no DDoS, and hey you get to work with us to expand the availability of the services across the US so its a win-win. We have them spread out through the US under USTiming and are looking for more sites that are telco hotels in particular - so if you have space and want to host is in a balance-of-trade type deal let us know. Todd On 2/7/2014 12:32 PM, Anthony Williams wrote: With a quick and easy mod, another option for $35 is a Sure Electronics GPS board. GPS: http://www.sureelectronics.net/goods.php?id=99 Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm -Alby On 2/7/2014 1:14 PM, Jared Mauch wrote: Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is cheap as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. -- - Personal Email - Disclaimers Apply
Re: TWC (AS11351) blocking all NTP?
How about this - I have proposed to NIST we start filtering - realize that the NIST ITS program itself was setup to run NTP in an open access mode - we host a dozen or so of those systems and so we get hit all the time. The solution is actually not running timing services across UDP because of the hand shaking over the open Internet - and that obviously isnt going to happen. My suggestion is that for those that need access we set up VLAN trunked private networking models to your ISP MPOE as it were in a digital context. If this interests you contact me off list. Todd Glassey - USTiming.ORG On 2/2/2014 7: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. Sent on the TELUS Mobility network with BlackBerry -Original Message- From: Cb B cb.li...@gmail.com Date: Sun, 2 Feb 2014 15:09:55 To: Matthew Petachmpet...@netflight.com Cc: nanog@nanog.org Subject: 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. ;) -- - Personal Email - Disclaimers Apply
Re: TWC (AS11351) blocking all NTP?
Or a whole bunch of small ones Vladis - and yes we are capable of handling the loads. :-) Todd On 2/3/2014 6:34 AM, valdis.kletni...@vt.edu wrote: On Mon, 03 Feb 2014 06:14:30 -0800, TGLASSEY said: My suggestion is that for those that need access we set up VLAN trunked private networking models to your ISP MPOE as it were in a digital context. That's going to be one big VLAN. /me makes popcorn. -- - Personal Email - Disclaimers Apply
Re: BCP38.info
We see this all the time with banking sites and some of the stock trading ones Todd On 1/28/2014 5:06 AM, Jared Mauch wrote: On Jan 26, 2014, at 12:47 PM, Jay Ashworth j...@baylink.com wrote: something like 6 years ago, and couldn't get any traction on it then; I'm not sure I think much has changed -- apparently, extracting your BP thoughts from mailing list postings and putting them into a wiki is more effort than most NANOGers are up to. I do have a list of the top ASNs that can be shown to allow IP spoofing by looking at the DNS scans part of the OpenResolverProject: 52731 ASN7922 31251 ASN9394 25241 ASN17964 15951 ASN4847 7576 ASN17430 5800 ASN17430 4110 ASN7497 3645 ASN9812 3492 ASN6854 http://openresolverproject.org/spoof-src-dst-asns-20140126.txt What the data is: It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.: [jared@hostname ~/spoof]$ dig @101.0.37.11 ;; reply from unexpected source: 182.19.83.65#53, expected 101.0.37.11#53 The data only includes those where the “source-ASN” and “dest-asn” of these packets don’t match. - Jared -- - Personal Email - Disclaimers Apply
Re: BCP38.info
On 1/28/2014 1:07 PM, Nick Olsen wrote: While I see what you're saying. It's still not Spoofed. The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget. No in this case the system is being hit with a MITM type attack Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRCOurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRCDNS-DST. Obviously, This only works because it's UDP. And TCP would be broken. Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Tuesday, January 28, 2014 3:04 PM To: n...@flhsi.com Cc: David Miller dmil...@tiggee.com, valdis.kletni...@vt.edu, NANOG nanog@nanog.org Subject: Re: BCP38.info On Jan 28, 2014, at 2:57 PM, Nick Olsen n...@flhsi.com wrote: Agreed. Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Sure, but this means that network is allowing the spoofing :) What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested. I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there. I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network. - jared -- - Personal Email - Disclaimers Apply
Re: GoDaddy DNS
This has been going on off and on for a while. Todd On 1/23/2014 7:41 AM, Adam Greene wrote: We noticed some issues to Google Level3 DNS last night: 8.8.8.8 8.8.4.4 4.2.2.2 1/23/1400:55:17 - 00:55:47 (UTC-5) 1/23/1401:09:32 - 01:11:03 (UTC-5) Have not yet determined if it was a local carrier issue. Someone on outa...@outages.org reported issues getting to eBay / Paypal IP's at roughly the same time. I wonder if there was a general brief carrier issue last night. -Original Message- From: Jason [mailto:ja...@viviotech.net] Sent: Thursday, January 23, 2014 3:57 AM To: nanog@nanog.org Subject: GoDaddy DNS We're starting to see errors with Go Daddy DNS. Is anyone else experiencing issues? -J -- - Personal Email - Disclaimers Apply
Re: Open source hardware
Arnd - the German Government is most likely a partner meaning overloading the NSA is pointless if you could. Todd On 1/5/2014 1:15 AM, Arnd Vehling wrote: Hi, On 04.01.2014 21:07, Daniël W. Crompton wrote: To my surprise I am seeing a theme fatalistic acceptance in this thread, thats not really suprising. Then most poeple dont understand the implications this has. A number have mentioned that if you are targeted there is little you can do, and this is something that I agree with to a certain extent. Here i agree too. But i think it should be in possible to overload them by mass-creating fake data and honey pots. They dont have endless resources especially when it comes to decrypting. So, if just 10% of the aware persons start firing up NSA honeypots they get a resource problem and will fail at selecting targets. // Arnd -- - Personal Email - Disclaimers Apply
Looking for contact at COGENT routing team
I am looking for a contact at Cogent's route management team if you have one? Todd -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Anyone from google networking on this list?
If there is anyone from Google Networking here on the list can you contact me offlist please. I want to talk about 60 Hudson. Todd Glassey -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: OOB core router connectivity wish list
On 1/9/2013 9:12 AM, Leo Bicknell wrote: I think this list goes too far, and has a decent chance of introducing other fun failure modes as a result. The goal of OOB is generally to gain control of a misbehaving device. Now, misbehaving can take many forms, from the device actually being ok and all of it's circuits going down (fiber cut isolating it), to the device being very much not ok with a bad linecard trying to lock up the bus, core dumps, etc. I'm going to pick on one specific example: In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). Most Cisco high end devices can do this today from the CLI (test mbus power off on a GSR, for example). Let's consider what it would take to move that functionality from the live software to some sort of etherent oob as proposed... Install an Embedded Peer (a Bus Level Peering Card like a SlotServer or the Fuji Module and provide console level access through the peer. Then the Peer itself becomes the controller interface. Todd The first big step is that some sort of computer to operate the ethernet oob is required. I think where you're going with this is some sort of small SoC type thing connected to the mangement buss of the device, not unlike an IPMI device on a server. Using IPMI devices on servers as an example this is now another device that must be secured, upgraded, and has the potential for bugs of its own. Since only a small fraction of high end users will use the OOB at all (inband is fine for many, many networks), there will not be a lot of testing of this code, or demand for features/fixes. So while I agree with the list of features in large part, I'm not sure I agree with the concept of having some sort of ethernet interface that allows all of this out of band. I think it will add cost, complexity, and a lot of new failure modes. The reality is the current situation on high end gear, a serial console plus ethernet management port is pretty close to a good situation, and could be a really good situation with a few minor modifications. My list would be much simpler as a result: 1) I would like to see serial consoles replaced with USB consoles. They would still appear to be serial devices to most equipment, but would enable much faster speeds making working on the console a much more reasonable option. For bonus points, an implementation that presents 2-4 serial terminals over the same USB cable would allow multiple people to log into the device without the need for any network connectivity. This would also allow USB hubs to be used to connect multiple devices in a colo, rather than the serial terminal servers needed today. 2) I would like to see manangement ethernets that live in their own walled off world out of the box. Yes, I know with most boxes you can put them in a VRF or similar, but that should be the default. I should be able to put an IP and default route on a management ethernet and still have a 100% empty (main) routing table. This would allow the management port to be homed to a separate network simply and easily. 3) I would like to see legacy protocols dumped. TFTP, bye bye. FTP, bye bye. rcp, bye bye. HTTP, HTTPS, and SCP should be supported for all operations at all levels of the OS. In this ideal world, the deployment model is simple. A small OOB device would be deployed (think like a Cisco 1900, or Juniper SRX 220), connected to a separate network (DSL, cable modem, cell modem, ethernet to some other provider, or gasp, even an old school analog modem). Each large router would get an ethernet port and usb console to that device. SSH to the right port would get the USB console, ideally with the 2-4 consoles exposed where hitting the same port just cycles through them. At that point all of the functionality described in the original post should be available in the normal CLI on the device. File transfer operations should be able to specify the management port copy [mangement]http://1.2.3.4/newimage.code flash: to use that interface/routing table. I also think on most boxes this would require no hardware changes. The high end boxes have Ethernet, they have USB...it's just updating the software to make them act in a much more useful way, rather than the half brain-dead ways they act now... -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Folks - changes to USTiming.ORG NIST Time Servers access names...
So I wanted to bring up we are making some changes in the NIST Server addresses and creating two pools they are: east-pool.ustiming.org west-pool.ustiming.org Also there is a new VLAN which can provide you your own /24 of access space for the NIST infrastructure anywhere in the NY/NJ corridor. If your in 60 Hudson, 100 William, NJ2, NY4, or our anchor spots with NYI at 100 William or 999 Frontier we can wire you for time... Anyway - for internet access please feel free to use the two pools. The East Pool is all of the external NIST UTC ITS systems we operate there under USTiming.ORG banners. Have fun Todd -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
