Re: request for help w/ ATT and terminology
All of the arguments of whether ATT should do it or would do it aside, my guesses are that it is either (a) the people he is talking to really don't understand him, (b) do understand but don't know how to get it done, or (c) ATT only does things like that for customers buying such-and-such level of service or better. It would be nice if he could find out which it is. I do know they[0] will do this, since they are doing it for us (look up who is originating 206.220.216.0/21 in the BGP and to whom it is assigned at ARIN). [0] For a company the size of ATT/Cingular/SBC and the varied business units therein, it may very well be that he is dealing with a completely different company than we are. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: DreamHost Contact?
On 12/30/2007 at 8:27 PM, Gregory Hicks [EMAIL PROTECTED] wrote: Date: Sun, 30 Dec 2007 21:42:21 -0500 From: Michael Greb [EMAIL PROTECTED] To: nanog@merit.edu Subject: DreamHost Contact? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've attempted to contact DreamHost NOC or Abuse departments via the numbers in whois but just get voice mail and no call back. I've got a user sending a lot of UDP traffic to 208.113.189.13 port 22. This traffic is very likely undesirable and I'd be willing to pull the plug immediately if I can get confirmation from DreamHost. Failing that Port 22? Isn't that ssh? Doesn't ssh have the capability to forward X or whatever via ssh? SSH uses only TCP, not UDP. 22/udp traffic used to be indicative of old, buggy PCAnywhere. PCAnywhere is supposed to use 5632/udp (0x1600), but there was an endian bug in some old versions that had it using 0x0016, 22/udp. Haven't seen that for a long time. May or may not have anything to do with this traffic. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
RE: BitTorrent swarms have a deadly bite on broadband nets
On 10/22/2007 at 3:02 PM, Frank Bulk [EMAIL PROTECTED] wrote: I wonder how quickly applications and network gear would implement QoS support if the major ISPs offered their subscribers two queues: a default queue, which handled regular internet traffic but squashed P2P, and then a separate queue that allowed P2P to flow uninhibited for an extra $5/month, but then ISPs could purchase cheaper bandwidth for that. But perhaps at the end of the day Andrew O. is right and it's best off to have a single queue and throw more bandwidth at the problem. How does one squash P2P? How fast will BitTorrent start hiding it's trivial to spot .BitTorrent protocol banner in the handshakes? How many P2P protocols are already blocking/shaping evasive? It seems to me is what hurts the ISPs is the accompanying upload streams, not the download (or at least the ISP feels the same download pain no matter what technology their end user uses to get the data[0]). Throwing more bandwidth does not scale to the number of users we are talking about. Why not suck up and go with the economic solution? Seems like the easy thing is for the ISPs to come clean and admit their unlimited service is not and put in upload caps and charge for overages. [0] Or is this maybe P2P's fault only in the sense that it makes so much more content available that there is more for end-users to download now than ever before. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Content Delivery Networks
On 8/10/2007 at 11:55 AM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Aug 10, 2007, at 12:46 PM, John Levine wrote: Very interesting. We've all heard and probably all passed along that little bromide at one time or another. Is it possible that at one time it was true (even possibly for AOL) but with the rise of CDNs, policies of not honoring TTL's have fallen by the wayside? I think you'll still see it in spam zombies, some of which have the DNS info pre-loaded into them in order to avoid split-horizon anti-spam techniques. Not much we can do about that until we get sufficient backbone to deal with the zombie problem and its software enablers. Actually, I think the fact Zombies do not honor TTLs is a feature. :) Fast-flux my MX records to avoid spam? Throw the spammers' technology back at 'em! I changed some MX records in mid-July for a domain. Spam was still flowing into the old MX hosts until I closed the firewall 25/tcp holes just today. Now just logging those zombies still banging on the gates. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Interesting new dns failures
On 5/21/2007 at 2:09 PM, Edward Lewis [EMAIL PROTECTED] wrote: At 3:50 PM -0500 5/21/07, Gadi Evron wrote: As to NS fastflux, I think you are right. But it may also be an issue of policy. Is there a reason today to allow any domain to change NSs constantly? Although I rarely find analogies useful when trying to explain something, I want to use one now to see if I understand this. Let's say you rob convenience stores as a career choice. Once your deed is done, you need to get away fast. So moving fast is a real help to criminals. Since moving fast is rarely helpful for decent folk, maybe we should just slow every one down - this certainly would make it easier for law enforcement to catch the criminals. There are these things called speed limits on all[0] public streets (in the USA, at least). Also things like stop signs and traffic lights. People exceeding the limit and driving recklessly can and regularly are stopped by police. When such drivers attempt to evade police, they are chased, even though it is dangerous to the police, bystanders, and the people being pursued, because there is a good chance that they are running because they've done something else, something worse. So, yeah. We do have speed limits. And suspicion of nefarious activity is put on anyone who grossly exceeds them. If the above is not an accurate analogy to the NS fastflux issue, I'd like to know what the deviations are. I don't doubt there are any, but from what little I've gathered, the problem isn't the NS fastflux but the activity that it hides - if it is indeed hiding activity. As in, not every one speeding around town is running from the law. No, but it's still prohibited. But yeah, it's just an analogy. And like many, you can bend it to support either side. [0] Last I knew, the experiments with speed-limitless roads after the drop of the federal 55 mph limit had all gone back to some arbitrary limits. Even Montana. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Request for topic death on Cold War history (was RE: Every incident is an opportunity)
On 2/12/2007 at 3:13 PM, Alexander Harrowell [EMAIL PROTECTED] wrote: Causality? WW2=nukes, cold war=arpanet=internet, surely? Hitler=WW2=... Godwin! Please? Anyway, we all know Al Gore invented the Internet. On 2/12/07, micky coughes [EMAIL PROTECTED] wrote: Hmm, let's see. Nukes = cold war = arpanet = internet Yup, looks ok. On 2/12/07, Olsen, Jason [EMAIL PROTECTED] wrote: Of course, but the point was the goal of that targetting. The US public by and large believed, and seems to still believe [snip] If anniliation is the goal than it's of no importance, just bomb the densest population centers. To borrow from snarky comments past: Unless Vendor C has introduced a no nuclear-apocalpyse command that I need to enable in IOS, it seems that this thread has wandered far from the flock and subsequently lost most any relevance to the listserv and/or topic that spawned it. Cold War strategy is fascinating and all (I do mean that in a non-snarky way) but does it really belong on NANOG after it has seemingly dropped any pretense of being an analogy for anything list-relevant? -Feren Sr Network Engineer DeVry University B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
RE: Google wants to be your Internet
On 1/30/2007 at 12:19 AM, [EMAIL PROTECTED] wrote: IPv6 makes NAT obsolete because IPv6 firewalls can provide all the useful features of IPv4 NAT without any of the downsides. IPv6 firewalls? Where? Good ones? Why good ones. NAT is a basic IPv4 firewall. All IPv6 needs to obsolete NAT is a firewall that offers all the features of NAT without requiring the address translation. Then, instead of setting up a port translation for a particular incoming protocol, you simply open up that port without modifying the packets as they flow through. Suddenly, SIP works and incoming VoIP phonecalls work just like on the phone network. Oh, if it were so easy. Even without NAT our firewalls still need to meddle in the application layer. You'll still need smarts in the firewall to use the bad ol' FTP. And of course although SIP itself usually uses a fixed port, the calls it sets up generally do not. You don't have to modify packets, but you still need to read them, understand the protocol, and add state entries to your firewall. The absence of NAT doesn't really save you much work. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
SBC RBL
We started getting these, for reasons unknown, for some pacbell.net email addresses, 550 5.0.0 ylpvm35.prodigy.net Access Denied. To request removal, send the complete error message, including your ip addresses, in an E-mail to [EMAIL PROTECTED] With great trepidation, I went ahead and tried the email address despite Googling it first and seeing few success stories and in fact some chat on this list about the sooper-lameness. But I had to laugh when I got this bounce back, On 12/5/2006 at 12:50 PM, [EMAIL PROTECTED] wrote: User's mailbox is full: [EMAIL PROTECTED] Unable to deliver mail Guess they're a little behind on their removals. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Spain was offline
On 8/31/2006 at 8:22 AM, [EMAIL PROTECTED] wrote: [snip] An ISP could run a modified DNS relay that replicates all responses to a special cache server which does not time out the responses and which is only used to answer queries when specified domains are unreachable on the Internet. For instance, if you specified that all .es responses were to be replicated to the cache and that your DNS relay should divert queries to the cache when .es nameservers are *ALL* unreachable, then the impact of this type of outage is greatly reduced. You could specify important TLDs to be cached this way as well as important domains like google.com and yahoo.com. The actual data cached would only be data that *YOUR* customers are querying anyway. In fact, you could specify that any domain which receives greater than x number of queries per day should be cached in this way. From what I've inferred from some other comments about the failure, it seems that the DNS servers were not unreachable or otherwise unavailable, but rather that the .es zone data was corrupted. Such a failure wouldn't trip the backup system you describe. How does an automated system tell the difference between a real NXDOMAIN and a erroneous one? It would take human intervention to turn it on in many potential failure modes. How much of a window is there where the ISP can positively identify a failure and start up their backup before the TLD, or whatever external DNS entity, gets its own act together? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Billing Humor
New plan? We used to have similar contracts with MCI and ATT. http://www.theonion.com/content/node/51834 -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: key change for TCP-MD5
On 6/20/2006 at 12:33 PM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 20-jun-2006, at 21:23, Randy Bush wrote: What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet? again: try reading the draft I've read the draft and it solves this problem with timing. That's insufficient because it requires that both sides do the right thing at the right time without any way to verify whether the other side is ready. What if one side didn't make the change, or entered the wrong key? Uh, isn't what this, In particular, if a key change has just been attempted but such segments are not acknowledged, it is reasonable to fall back to the previous key and issue an alert of some sort. Is for? Automated fallback if a new key doesn't work? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: WSJ: Big tech firms seeking power
On 6/16/2006 at 2:24 PM, Alex Rubenstein [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006, Matthew Crocker wrote: I wonder just how much power it takes to cool 450,000 servers. 450,000 servers * 100 Watts/Server = 45,000,000 watts / 3.413 watts/BTU = 13.1 Million BTU / 12000 BTU/Ton = 1100 Tons of cooling Error: you MULTIPLY 3.413 to go from watts to BTU, not divide. It's be more like 154,000,000 BTU, /12000 or 12,798 tons. Well, the bigger problem here is that a watt is a measure of power (engergy/time) and a BTU is a unit of energy. There is no dimensionless conversion factor between the two. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Is your ISP Influenza-ready?
Barry Shein wrote: [snip] So if you're really expecting something as macro as 40% of the population dropping dead I think one has to think much bigger and much more in the realm of unexpected consequences. Uhh... I think, I _hope_ that we are talking about 40% of your workforce NOT SHOWING UP TO THE OFFICE for days or weeks, not dropping dead, not even necessarily getting sick. A 40% mortality rate among otherwise healthy adults, and we have much bigger issues to worry about. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Wifi SIP WPA/PSK Support
Mike Leber wrote: [snip] I've had a few people say that there was some sort of conspiracy to keep US citizens from using secure phones, however I found that laughable because [snip] Because domestically the US gov't (or local LEOs) can just intercept the calls when they hit the PSTN. They don't bother intercepting between the phone and its access point. Now, whether there are LEOs pushing against end-to-end encryption becoming widely available to consumers is a whole separate issue. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Sprint Problems?
Having trouble getting anything out of our Sprint rep. Rumors of fiber whack. Problems out here in San Jose, California and in Texas, Waco vicinity. Hard to say whether some of our problems over the rest of North America are related to Texas and California or more widespread. Voice and data problems. Anyone have better info on what, where, and resolution? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Receiving route with metric 0
Glen Kent wrote: Am all the more confused now :) In pre-RFC1058 implementations the sender increments the metric, so a directly-connected route's metric is 1 on the wire. In post-RFC1058 implementations the receiver increments the metric, so a directly-connected route's metric is 0 on the wire. In both cases, the metric in a reciever's database one hop away is 1. Lets say we have A -- B. A is pre-RFC1058 and B is post RFC 1058. A sends a directly connected route as 1. B increments this by 1, and thus stores it as 2. Let's start over, looking at the text that was in the erlier mail from RFC1058. A is a pre-RFC1058 and B is post-RFC1058. Host A stores directly connected networks with metric 0, Using the previous perspective, the internal routing table has a metric of 0 for all directly-connected networks. The cost (which is always 1) is added to the metric when the route is sent in an update message. So host A sends RIP messages with metric 1 for directly connected networks. Now, for post-RFC1058, host B, By contrast, in this document directly-connected networks appear in the internal routing table with metrics equal to their costs; So, a directly connected network, unless it has for some reason a higher cost, host B will have a cost of 1. The value in the internal table is 1. Metrics from the routing table are sent in update messages without change (unless modified by split horizon). So host B will send RIP updates for directly connected networks with a metric of 1. You appear to have it backwards. As it says in the section you quoted, These two viewpoints result in identical update messages being sent. Either approach results in messages with metric 1. The metrics on the Hmmm .. not sure. A post 1058 implementation would send a metric 0 for a directly connected route, assuming that the other end would increment the value and things would work out fine. A post-RFC1058 implementation adds the cost before putting it in its internal routing table so a directly connected network has a cost of greater than or equal to one. This seems to be the point of confusion. A directly connected network in an RFC1058-style implementation must have a cost =1. Why must a post-RFC1058 have a non-zero cost for a directly connected network? Imagine A and B were both post-RFC1058 and both had zero cost for directly connected networks. A would send updates to B with a zero metric for one of its directly connected networks. B would then add the cost of its link to A, which is zero, before putting it in its table. But 0 + 0 = 0... That is, the metrics never increment. It doesn't work. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Receiving route with metric 0
Stephen Stuart wrote: I am a little confused here. You yourself say that a valid metric starts from 1, then how come 0 be valid for a directly connected route. Are you saying that seeing a RIP metric of 0 on the wire is valid? A metric of 0 from a host would mean that the host itself is the endpoint for the route. See the discussion in section 2 of RFC1058. RFC1058 says: 3.6. Compatibility The protocol described in this document is intended to interoperate with routed and other existing implementations of RIP. However, a different viewpoint is adopted about when to increment the metric than was used in most previous implementations. Using the previous perspective, the internal routing table has a metric of 0 for all directly-connected networks. The cost (which is always 1) is added to the metric when the route is sent in an update message. By contrast, in this document directly-connected networks appear in the internal routing table with metrics equal to their costs; the metrics are not necessarily 1. In this document, the cost is added to the metrics when routes are received in update messages. Metrics from the routing table are sent in update messages without change (unless modified by split horizon). These two viewpoints result in identical update messages being sent. Metrics in the routing table differ by a constant one in the two descriptions. Thus, there is no difference in effect. The change was made because the new description makes it easier to handle situations where different metrics are used on directly-attached networks. Implementations that only support network costs of one need not change to match the new style of presentation. However, they must follow the description given in this document in all other ways. In other words: In pre-RFC1058 implementations the sender increments the metric, so a directly-connected route's metric is 1 on the wire. In post-RFC1058 implementations the receiver increments the metric, so a directly-connected route's metric is 0 on the wire. In both cases, the metric in a reciever's database one hop away is 1. You appear to have it backwards. As it says in the section you quoted, These two viewpoints result in identical update messages being sent. Either approach results in messages with metric 1. The metrics on the internal routing tables of the machines differ in the two cases. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: the iab simplifies internet architecture!
Christopher L. Morrow wrote: On Thu, 2005-11-10 at 20:37 -1000, Randy Bush wrote: btw, for another great giggle (many thanks to brian candler for reporting it) From the documentation for Cisco's VPN client software for Linux: http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_user_guide_chapter09186a0080234617.html User profiles [which contain all your IPSEC parameters: pre-shared key, username and password] reside in the /etc/CiscoSystemsVPNClient/Profiles/ directory. Leave the permissions for the Profiles folder set at drwxrwxrwx. Each profile in the Profiles folder should have the follwoing permissions: -rw-rw-rw-. The password string is encrypted in the Profile, however, when you save it... encrypted how? cyrpt? md5? cisco7? Some way proven to take 'very long' to decrypt? is the passwd really necessary or is only the hash required? this is just wholey irresponsible of any vendor, nevermind one that should really know better :( http://www.cisco.com/warp/public/707/cisco-sn-20040415-grppass.shtml The Group Password used by the Cisco Internet Protocol Security (IPsec) virtual private network (VPN) client is scrambled on the hard drive, but unscrambled in memory. This password can now be recovered on both the Linux and Microsoft Windows platform implementations of the Cisco IPsec VPN client. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: cogent+ Level(3) are ok now
Eric Louie wrote: Now, one really needs to wonder why the agreement could not be reached *prior* to the depeering on 10/5 It's not rocket science. As people have pointed out repeatedly, this was surely not rocket science since it wasn't a technical problem at all. It was a business conflict. It seems clear to me what probably happened. First-round negotaitions failed 'cause Level 3 thought Cogent was bluffing (and perhaps vice versa). Level 3 called the bluff, but it wasn't a bluff, and Level 3 then blinked (or so it appears from reading between the lines of what I've seen). They both got back to negotiation, and with a better understanding of to how much pain the other willing to take to get what they want, this time they came out with an agreement. Doesn't seems mysterious. [snip] Who are the next discontent couples? And how do I protect myself and my customers from any problems these kinds of events cause regardless of who the next players might be? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: What is multihoming was (design of a real routing v. endpoint id seperation)
Robert Bonomi wrote: From [EMAIL PROTECTED] Mon Oct 24 15:33:02 2005 Date: Mon, 24 Oct 2005 13:31:17 -0700 Subject: Re: What is multihoming was (design of a real routing v. endpoint id seperation) Stephen Sprunk wrote: [snip] Other people use this term in very different ways. To some people it means using having multiple IP addresses bound to a single network interface. To others it means multiple websites on one server. That is virtual hosting in a NANOG context. Some undereducated MCSEs might call it multihoming, but let's not endorse that here. Unfortunately, this is a common and standards blessed way to refer to any host with multiple interfaces/addresses (real or virtual). For example, from the Terminology section, 1.1.3, of RFC1122, Requirements for Internet Hosts -- Communication Layers, says, Multihomed A host is said to be multihomed if it has multiple IP addresses. For a discussion of multihoming, see Section 3.3.4 below. *sigh* Multi-homing simply means 'having external connections to more than one network' -- be it a network with multiple, disjoint, ingress/egress paths, or a host with interfaces (real or virtual) on distinct LAN subnets (even if those subnets are agregated into a single net somewhere upstream. A host with multiple adresses utilizing the _same_ netblock/netmask _should_ _not_ be called multi-homed (because there is only one path to that host), it is simply a single-homed host with multiple identities. might be called poly-ip-any or some such. grin Depends who you ask. Again, RFC1122 says (section 1.1.1), A host is generally said to be multihomed if it has more than one interface to the same or to different networks. And also section 3.3.4.1, A multihomed host has multiple IP addresses, which we may think of as logical interfaces. These logical interfaces may be associated with one or more physical interfaces, and these physical interfaces may be connected to the same or different networks. As far as a multihomed host is concerned, RFC1122 sure seems to call anything with multiple IPs multihomed. Multihomed is a trait of the host independent of any network topology around the host. But whatever. It just means people need to be clear what they are talking about when they say multihomed. As is clear from this thread, there is not clear agreement on what the precise meaning is. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: What is multihoming was (design of a real routing v. endpoint id seperation)
Stephen Sprunk wrote: [snip] Other people use this term in very different ways. To some people it means using having multiple IP addresses bound to a single network interface. To others it means multiple websites on one server. That is virtual hosting in a NANOG context. Some undereducated MCSEs might call it multihoming, but let's not endorse that here. Unfortunately, this is a common and standards blessed way to refer to any host with multiple interfaces/addresses (real or virtual). For example, from the Terminology section, 1.1.3, of RFC1122, Requirements for Internet Hosts -- Communication Layers, says, Multihomed A host is said to be multihomed if it has multiple IP addresses. For a discussion of multihoming, see Section 3.3.4 below. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
IANA Blackhole Servers Ill?
We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: IANA Blackhole Servers Ill?
John van Oppen wrote: It is probably important to know that those servers are anycasted via the AS112 project (www.as112.net). Perhaps the AS112 operator you are seeing is having issues. You could try to identify which one and let them know. Three things: 1) At least one other person reports the same problem. 2) They've been going up and down, so even if you go check and it works that one time, you may have caught it up. 3) I'd try to ask it which anycast instance it is, but both are sending ICMP unreachables at the moment. A traceroute says, traceroute to 192.175.48.42 (192.175.48.42), 64 hops max, 44 byte packets [snip] 6 p4-3-0.RAR2.SanJose-CA.us.xo.net (65.106.5.161) 34.390 ms 5.774 ms 5.280 ms 7 p1-0.IR1.PaloAlto-CA.us.xo.net (65.106.5.178) 44.123 ms 21.508 ms 5.672 ms 8 207.88.240.70.ptr.us.xo.net (207.88.240.70) 5.473 ms 26.629 ms 14.045 ms 9 ix-4-6.core3.PDI-PaloAlto.Teleglobe.net (207.45.196.66) 6.637 ms 10.697 ms 5.863 ms 10 blackhole-2.iana.org (192.175.48.42) 6.547 ms 6.561 ms 8.935 ms I don't have a BGP view of the world from XO, our provider on this link. Anyone know which instance that is? It's close to Palo Alto? From, http://public.as112.net/node/2 My best guess is ISC? But F-Root seems to be OK from here, FWIW, and a traceroute to F doesn't jump through that IX. -Ursprüngliche Nachricht- Von: Peter Dambier [mailto:[EMAIL PROTECTED] Gesendet: Friday, October 21, 2005 2:20 PM An: [EMAIL PROTECTED] Cc: nanog Betreff: Re: IANA Blackhole Servers Ill? To me they do answer: ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-1.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20469 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 113 msec ;; SERVER: 192.175.48.6#53(blackhole-1.iana.org.) ;; WHEN: Fri Oct 21 23:15:39 2005 ;; MSG SIZE rcvd: 162 ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-2.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43116 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 112 msec ;; SERVER: 192.175.48.42#53(blackhole-2.iana.org.) ;; WHEN: Fri Oct 21 23:15:49 2005 ;; MSG SIZE rcvd: 162 Regards, Peter and Karin Dambier Crist Clark wrote: We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review
Re: IANA Blackhole Servers Ill?
Looks like it was ISC? And they withdrewn their routes for a bit? For a while I got (from XO in CA), $ host -t txt -c chaos hostname.bind 192.175.48.6 Using domain server 192.175.48.6: hostname.bind CHAOS descriptive text black-1.sth.netnod.se Goin' transatlantic! Traceroutes seemed to verify. But now I'm back on, $ host -t txt -c chaos hostname.bind 192.175.48.6 Using domain server 192.175.48.6: hostname.bind CHAOS descriptive text hazel.isc.org ISC. Got a note from an ISC reader verifying they are/were having issues with their AS112 server. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: shim6 (was Re: IPv6 news)
Daniel Roesen wrote: On Fri, Oct 14, 2005 at 07:27:37PM +, [EMAIL PROTECTED] wrote: the kicker here is that the applications then need some serious smarts to do proper source address selection. Nope. The ULID is supposed to be static, globally unique. Just not globally routed. Seperating topology from identification. Something I didn't see discussed yet is that shim6 sites would need to get a globally unique, provider independent /48 or larger... which folks could start to announce. But I guess that address space would come from blocks earmarked as non-routable, it's a bogon, bad IP space, filter in BGP at first sight!. :-) Actually, doing multihoming and getting PI space are orthogonal in shim6 last I knew. That is, you could get address space from your N providers and have one of the providers, say Provider X, to be the ULID for the end points. Should Provider X's link(s) go down, shim6 will ensure it all still works (which is, after all, the whole point). Getting PI space is really an administrative and economic issue. It is not a technical requirement of shim6. From draft-ietf-shim6-arch-00.txt, 3. Endpoint Identity There are a number of options in the choice of an endpoint identity realm, including the use of existing addresses as an identity tokens, the use of distinguished (possibly non-routeable) addresses as tokens, or the use of tokens drawn from a different realm (such as use of a fully qualified domain name). Shim6 uses the first of these options, and the endpoint identity for a host is one of the locator addresses that are normally associated with the host. The particular locator address selected to be the endpoint identity (or ULID) is specified in [RFC3484]. Shim6 does not mandate the use of distinguished addresses as identities, although the use non-routeable distinguished addresses in this context is described as an option in this approach. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: shim6 (was Re: IPv6 news)
Daniel Roesen wrote: On Fri, Oct 14, 2005 at 01:11:18PM -0700, Crist Clark wrote: Actually, doing multihoming and getting PI space are orthogonal in shim6 last I knew. That is, you could get address space from your N providers and have one of the providers, say Provider X, to be the ULID for the end points. Should Provider X's link(s) go down, shim6 will ensure it all still works (which is, after all, the whole point). But when the contract with this supplier is terminated, I have to renumber the whole network. Excellent. Well, you can get by on shim6 until the supplier reissues the address space elsewhere. Not too reassuring? But with IPv6, renumbering is easy! Uh, yeah, right. Getting PI space is really an administrative and economic issue. It is not a technical requirement of shim6. That's the problem. Ignorance regarding economical problems. We don't have technical problems, we have economical ones (if at all). Multihoming in IPv6 is a technical problem if you consider unrestricted growth of the routing tables to be a technical problem (there are those who think is it economic, throw more memory and CPU at it). As the section of the draft quoted, using unrouted RFC1918-like address space, which would presumably be PI, is also covered by shim6, but it is not the only way in which it work. There is plenty of finger pointing about the economic problems, or ignorance thereof, in IPv6, including the occasional conspiracy theory. We had similar problems with IPv4. We still feel pain from the switch from Classful networking to CIDR occasionally. That was a technical change driven by an economic reality. Then there is that evil spawn of IPv4, NAT. The way these things get worked out ain't always pretty. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: IPv6 news
[EMAIL PROTECTED] wrote: Percentage of available address space announced: 38.6 You misunderstand what IP addresse are. They have nothing whatsoever to do with the Internet. The address space announced on the Internet is an entirely separate issue. IP addresses were established as part of the development of a networking protocol called the Internet Protocol, or IP for short. This protocol was designed to allow many independent networks to interconnect or internetwork and exchange traffic. In order for such internetworks to work they need to be allocated unique IP addresses. The prerequisite for receiving globally unique IP addresses is that you have to be using IP technology and have a need to internetwork with other networks. There are several such IP internetworks that are entirely separate from the public (big I) Internet. That's where the other addresses are used and their usage is growing at about the same rate as Internet usage is growing. While I do not necessarily disagree with this point of view (as I work for a company who uses allocated space in such a manner), others may argue that addresses that are assigned through the Internet Assigned Numbers Authority (that's Internet with the I) are meant for Internet, with an I, use. As it says at the top of their web page, Dedicated to preserving the central coordinating functions of the global Internet for the public good. Note, global Internet. ObOnSubject: Of course, getting PI space for non-global Internet use is one of the big problems with current IPv6 allocation policy that make it difficult to start building private IPv6 networks now. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Weird DNS issues for domains
Peter wrote: Crist Clark [EMAIL PROTECTED] wrote: [...] The problem I've seen is when an SMTP server does not accept emails which have non-resolvable MAIL FROM domain. When the sender is a dumb SMTP client, not an MTA, this can cause problems. Well, that dumb SMTP client should stop pretending to be a MTA then. If it can't queue and retry, it shouldn't even *think* about looking for MX records. Sorry, I guess I was not clear. The dumb client is not pretending to be an MTA. The dumb client is sending to its smart host. The MTA, the smart server for the dumb clients, does a reality check on the envelope sender. (This is not unusual.) A dumb client tries to send, MAIL FROM:[EMAIL PROTECTED] Via the MTA, but the MTA rejects this because it cannot resolve the domain. Now even if our MTA does the right thing and rejects with a 4xx error, a dumb client may not be equipped to handle this well. Besides, what sort of dumb SMTP client did you have in mind? Formmail scripts? Worms? Outlook Express? I can't say I'd miss mail from any of those. Well, the reality check on the sender domain is meant to stop a lot of traffic from some of those sources, so I won't miss that either. However, due to the nature of our business, we have lots of people with very, uh, interesting SMTP clients. I know of a few who have integrated PPP/IP/TCP/SMTP stacks for custom hardware, i.e. they wrote network code for a device with less CPU and RAM horsepower than your modern wrist watch to only send email. They tend not to handle exceptional conditions well (and sometimes have cool features like the sender address is hardcoded, hardcoded in NVRAM, or hardcode the IP address of the smart host which is fun when we move those or bring one down for maintenance). (I noticed this happen to a high traffic customer who had both of their DNS servers in the same /24 located in Slidell, LA. Needless to say, they were down for more than a few hours when Katrina rolled through.) Having reachable DNS isn't going to help anyway if the MX host is also unreachable for an extended period. Mail is still going to bounce after a few days if somebody doesn't fiddle with DNS. But even if the destination MTA is reachable, the mail was not going through since the MAIL FROM domain was unresolvable. The mail would have been delivered promptly had the sender's DNS been available. The sender's MX MTA never enters into the picture. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Weird DNS issues for domains
Todd Vierling wrote: On Thu, 29 Sep 2005, John Dupuy wrote: If you are talking about strictly http, then you are probably right. If you are hosting any email, then this isn't the case. A live DNS but dead mail server will cause your mail to queue up for a later resend on the originating mail servers. A dead DNS will cause the mail to bounce as undeliverable. If a mail server is bouncing immediately on a DNS SERVFAIL (which is what you'll get when a remote DNS server is down), then that mail server is badly broken and will break quite a bit during tier1 failure situations. Failure to resolve != resolves to NXDOMAIN/empty. A failure to resolve (SERVFAIL) should result in the same queueing behavior that the remote SMTP server uses for failure to establish a TCP connection. The problem I've seen is when an SMTP server does not accept emails which have non-resolvable MAIL FROM domain. When the sender is a dumb SMTP client, not an MTA, this can cause problems. (I noticed this happen to a high traffic customer who had both of their DNS servers in the same /24 located in Slidell, LA. Needless to say, they were down for more than a few hours when Katrina rolled through.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
Adam McKenna wrote: On Tue, Sep 13, 2005 at 04:31:05PM -0700, william(at)elan.net wrote: Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port. Application layer firewalls have existed for at least 6 years. AAAGGHH! But the point is that you would still establish a TCP connection before a MTA, firewall, IPS, or whatever could know it was telnet! The FEMA address that started this whole thing was timing out. You can tell the difference between a telnet filter and something completely, silently blocking 25/tcp. CAN THIS DIE NOW? Pueese... -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
Igor Gashinsky wrote: [snip] Moving everything to the end-hosts is simply not a good idea imho. But isn't that what IP is supposed to be about? Smart endpoints, dumb network (a.k.a. the stupid network)? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Any issue with www.cisco.com
Yet another Me too! response. We often use pings to www.cisco.com as a Internet connectivity test from globally dispersed sites. These are typical ploss for ICMP pings. The most likely answer, as others have pointed out, is throttling at the destination. The fact that so many people use www.cisco.com for this purpose is probably why they need to throttle traffic. Hyunseog Ryu wrote: Last night I had a maintenance so I use www.cisco.com for testing the network connectivity. But it seems that I'm seeing about 20% packet loss from www.cisco.com. I did same test from various points including my home cable modem connection, which is not my company's network, but I'm getting same result. Are you guys seeing same thing or different result? Is there any issue with cisco.com network? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
SWIP and Rwhois in the Real World
As best I can tell from ARIN documents, ISP still are supposed to SWIP or use Rwhois for subassignments of /29 and greater. However, is this still widely practiced these days? Especially among smaller ISPs? I know the privacy pros and cons, so I don't seek to start those threads again. I'm interested in what smaller ISPs are actually doing these days. Thanks. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: LAN to LAN dial solution
[EMAIL PROTECTED] wrote: Can anyone suggest, other than using Cisco's a brand of UK-compliant boxes that effectively will perform a PSTN dial up function, so that when the two boxes are connected, the LAN's are effectively bridged together Basically what we want to be able to do is connect a PC on a LAN, so that at will, a number can be dialed and you can then telnet to the far end You may be asking something else, but pretty much every PPP implementation I've ever seen on a UNIX-like system or router has dial on demand capabilities. However, I do wonder if you are trying to express something unusual about this setup by the use of the term bridged as opposed to normal layer-3 routing. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Way OT: RE: @Home's 119 domain names up for sale
[I know, I know, don't feed the trolls. But some are just too cute not to. Just this once.] Matthew Black wrote: It's kind of funny that people keep making these general claims as though the money is wasted or goes to some unproductive purpose. Personally, I don't consider subsidized housing for the lower-class to be wasteful or a misuse of money. I wonder how many people who decry wasteful government spending would consider road and highway construction a waste of money. If traffic moves to slow to work for your pleasure, get a job closer to home or vice versa. After all, this is the land of opportunity and nobody FORCED you to buy a home far from work. Highway spending is all government financed, but few complain about that as a waste. Funny you should say that with the pork laden highway bill that just went through Congress. There were 6371 individual special (i.e. pork) projects in the huge bill. I'd say spending $223 million to build one of the largest bridges in the country to an island Alaska with 50 residents is a severe misallocation of limited resources. That kind of spending IS a waste. Discussion of government spending often spins into a discussion of simplifying the tax code or attempts to make it fairer. Keep in mind that almost all of the tax code consists of rules lobbied by and for corporate Amerika. Very little of the income tax code applies to individuals. As to the fairness question, most of the lower and middle class class are in a higher marginal tax bracket than the well-to-do. The latter get a 7.6% marginal tax break (no FICA or Medicare). So the middle class pay 32.6%; the wealthy pay 20% or less. Talk about disincentives! It matters how you look at income taxes (figures never lie, but liars figure). The top 3% of earners pay about 40% of all income taxes. The top 1/12% pay about 10% of the taxes. Why do the super rich guys want a flat tax? And the other obvious problem, you pay a lot of taxes, probably more than you realize, besides income tax. A nice reference from the definitive source: http://www.straightdope.com/classics/a5_139.html -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: You're all over thinking this
Steve Sobol wrote: Crist Clark wrote: Gratuitous-Plug=Employer If you really want high reliability during and after a natural disaster, satellite phones are probably your best option. That's who I thought you worked for, but the only satellite phone provider whose name I consistently remember is Iridium (aren't they bankrupt and/or gone?) They did go bankrupt, but were bought and still do operate. Of course, Globalstar went bankrupt and was bought too. The new ownership has been expanding the Globalstar business (new ground gateways, buying existing gateways from external service providers, planning launches to replenish the constellation, etc.). I don't think new-Iridium has plans to replenish. Both are big on gov't and corporate customers, but Globalstar is much more popular with smaller customers and consumers. I'm not impartial, but both services have pros and cons depending on your needs. But I believe the real thing that kept Iridium going was some of their DoD customers (i.e. customers that would take the business over before letting it go under). Of course, you have issues with satellite phones too. Cost is one such issue. Even when I signed up for my first cell phone in 1993, long before the wireless boom, airtime was still only about 40 to 50 cents per minute[0] - about 1/2 or 1/3 of what you'll pay per minute for a satellite phone today, IIRC. (Please correct me if necessary!) Like so many things, price depends on the volume you buy, http://www.globalstarusa.com/en/airtime/voicepricing/ The range is from $1 to $0.14 per minute. There are also other special plans not mentioned including emergency use only plans. Although many of those are individually arranged when large gov't or private agencies make bulk purchaces of equipment and services. The Ready-Sat-Go! (I didn't name it) plan might be a reasonable emergency package, http://www.readysatgo.net/index.php?main_page=product_infocPath=1_13products_id=19 advertisement acting-school=cheesy commercial empathy-mode=on actor=deep-voiced anchorman or Sally Struthers Isn't the safety of your family and your peace of mind for one year worth $999? Then only the cost of pre-paid minutes for the years after that. /advertisement Another, potentially worse, problem occurs if you don't have line of sight to the bird... that's precisely why I ended up with cable TV instead of satellite when I lived in Lake County, Ohio - three *very* tall trees to the south of my house, with DirecTV's satellite *and* Dish's satellite both requiring line of sight to the southwest. Trees could potentially cause a problem, but not in the situation you describe. Globalstar, and Iridium too for that matter, have large LEO constellations, not GEO. There are typically multiple satellites in view at any given time, and they are mo-o-oving by. A stand of trees off in one direction probably is not a problem. OTOH, standing under solid rain forest canopy may or may not present problems. Again, an overview from the website, http://www.globalstarusa.com/en/content.php?cid=601 during hurricane season. (Although I'd rather not slide into the discussion about how 911 works for us.) It doesn't? ;) It does, afterall, FCC says it has to. How do we do it? Your GPS coords are belong to us, http://www.globalstarusa.com/en/about/newsevents/press_display.php?pressId=41 But funky things happen when we start talking about international roaming. (Before any more detailed questions come in, I'll warn you I'm a terrestrial data networking guy, not a telco switching or RF guy.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: You're all over thinking this
Sam Crooks wrote: Didn't the US Navy buy Iridium? Nope. http://www.iridium.com/corp/iri_corp-story.asp?storyid=2 In December 2000, a group of private investors led by Dan Colussy organized Iridium Satellite LLC which acquired the operating assets of the bankrupt Iridium LLC including the satellite constellation, the terrestrial network, Iridium real property and intellectual capital. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: You're all over thinking this
Austin McKinley wrote: But a land line? If I pick up an analog phone anywhere, I expect a dial tone, and local calling. If I don't have access to emergency services after a blackout/natural disaster that knocks cell towers down (think hurricane season in Florida last year) then you'd never get me to drop my local carrier. I think it is quite a bit to expect very high reliability even from land lines during and immediately following a hurricane. In fact, the odds may not be bad that your cellular service could be restored before your land line. Funny thing about blackouts, you're IP phone is dead if your ISP link depends on utility power. Your cell phone is OK. Your land line is OK... as long as you don't just have cordless phones that require a base station that only operates plugged in. Gratuitous-Plug=Employer If you really want high reliability during and after a natural disaster, satellite phones are probably your best option. We just opened a new gateway in Florida, partly due to demand for emergency services support during hurricane season. (Although I'd rather not slide into the discussion about how 911 works for us.) /Gratuitous-Plug As any network engineer knows, the best engineered systems still do fail. Your best bet for reliability is diversity. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Non-English Domain Names Likely Delayed
Iljitsch van Beijnum wrote: On 19-jul-2005, at 1:43, Crist Clark wrote: [snip] If almost none of the phishing emails I get now bother to play these kinds of games today, how much does this really help? And burglars also manage to get inside your house even though you lock the door. So better not lock the door then? I lock the door. But it's just a regular door, I haven't spent the time and money fitting a bank vault door to the front of the house. That would be silly. If the homograph problem isn't too hard, yeah, fix it. If it is hard, it may not be worth it. From what I know, this isn't easy, but technically, not impossible. However, it seems rather expensive to implement to me, since it requires buy-in from lots of independent groups, and if one group decides not to play, it really screws up the whole works. If that's what we're arguing about, where the cost-benefit line lies, reasonable people can disagree. Expansion of 1: don't trust any unsollicited communication. This includes all incoming email (unless it's signed but it never is) and phone calls. Good advice. Always weigh the risks. This message might not really be from Iljtch van Beijnum, but how would I really know the difference anyway? This mail here might not be from my mom, but why would someone impersonate her to send me some fake stories about their trip to Maine? Maybe that link in the mail isn't really to their snap shots from the trip... but they sure did find an actor that looks an awful lot like my dad. This other mail might not really be from my manager. If he asks me to kill the circuit to our alternate site, I might lean over and ask him or give him a call about it. This other email says I won a lottery in Amsterdam that I've neve heard of. Somehow, I'm not buying that one at all. If someone calls me and claims to be my new account representative at my bank, I'd probably believe her and listen to her sales pitch, but if she were to start asking a lot of questions that she should already know the answers to, I'd get suspicious. (Law enforcement at your door? How do I know those badges are real?) Are guns drawn? They, whoever they are, gonna bust the door down if I don't open it? Do I have a choice? Are they asking questions that I would answer if this was just anyone at the door whether it was someone claiming to be a reporter, a private detective, or just curious neighbor? Is anything about them making you uncomfortable? Do feel free to call up the police station (non-emergency though, please) to check up on them. Some do advise people, especially women travelling alone, not pull over for what appear to be police vehicles in secluded areas, but to have them follow to someplace with other people around. Not sure I would give that advise. For similar reasons, some police departments have policies whereby unmarked police cars never make routine traffic stops at night. But I would definately advise someone who feels vulnerable to not let in someone like a utililty employee who shows up unannounced at their house even if they produce an ID badge without calling the utility to check up on them (and don't get the number from the person at the door). Never give out your password to ANYONE, EVER. Always sound advice. Unless you watch _Seinfeld_ and have a bank that violates fire codes. Then you know when you may need to give it away to save a life, Bosco! Bosco! -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
Brad Knowles wrote: At 10:31 AM +0200 2005-07-19, Iljitsch van Beijnum wrote: And for 99% of the users out there, 4) the caching servers for their ISP/employer/other access provider Actually, you don't. If the DNS provides false information, the public key crypto will catch this. Sure, you won't be able to communicate, but you can't be fished that way. What public key crypto are you talking about? You seem to think that something like DNSSEC is in wide use throughout the world, which is a very strange notion for someone to have when they damn well should know better. He is making the assumption that if someone has got a cert for, www.blah.com From one of the well known CAs, no one else can get one from one of the well-known CAs for that same name. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
Isn't someone more eloquent than I going to point out that that spending a lot of effort eliminating homographs from DNS to stop phishing is a security measure on par with cutting cell service to underground trains to prevent bombings? It focuses on one small vulnerability that phishers exploit, and fixing this one vulnerability just may make things worse. It wastes resources that could go to coming up with a *real* solution, and it may provide a false sense of security. There are dozens of ways we know of, and probably more that lie undiscovered, to exploit vulnerabilities in DNS, browsers, and in human nature to conduct phishing. Worrying about homographs is probably something about which we should let the trademark lawyers get there undies in a bunch (knowing ICANN, that may very well be what's driving this, not phishing worries) while the IT security community concerns itself with a usable, and actually secure, end-to-end security model for e-commerce. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
Iljitsch van Beijnum wrote: On 18-jul-2005, at 23:43, Crist Clark wrote: Isn't someone more eloquent than I going to point out that that spending a lot of effort eliminating homographs from DNS to stop phishing is a security measure on par with cutting cell service to underground trains to prevent bombings? It focuses on one small vulnerability that phishers exploit, and fixing this one vulnerability just may make things worse. If you make a bunch of assumptions Well, that's just it. There are a whole ton of assumptions here. That the name that pops up in the navi-bar kinda-maybe-looks-sorta like the site you think it should is just one of many and may not even be the weakest. (SSL certificate chain is ok, Yeah, make sure Verisign isn't issuing Microsoft certificates to someone who isn't Microsoft again. And hey, can we play homograph games inside of X.509 certs too!? Fun! binary is trustworthy, etc) Plus, you have to trust DNS, which means you have to trust: 1) the root 2) the gTLD 3) the authorative servers for the domain And for 99% of the users out there, 4) the caching servers for their ISP/employer/other access provider That is, trust that they are not actively malicious nor have been exploited by some new or old cache poisoning trick, had a bogus registrar switch (like Panix's recent experience), etc. you can be sure that when it says https:// www.blah.com/ in your browser, you're actually communicating with the entity holding the name www.blah.com in a secure way. So when something that looks exactly like www.blah.com is in fact different from www.blah.com, that's a pretty big deal because it breaks the whole system. Assuming the system works. SSL doesn't really work now since so many users reflexively click through warnings about bad certificates. And while we're at it, does any of this fix whether any of the following, www.blah-inc.com www.blah.net www.blah.biz Might trick a user into thinking he's connected to the same entity that owns www.blah.com? So how would fixing this make things worse? Wrong question. How will fixing this one problem make things any better? If almost none of the phishing emails I get now bother to play these kinds of games today, how much does this really help? Yeah, if it's easy, go ahead, but as the mere existence of this thread seems to indicate this is not an easy problem. I worry that like many of the other spam-related problems while we have a lot of very smart people like yourself thinking hard about how to prevent abuse, we may just be rearranging the deck chairs on the Titanic. It may be time to head for the lifeboats, let this ship go down, and start building a new, better boat now that we better understand the threats.[0] And what else should we be doing instead? Many things, perhaps the two most important we can do: 1) Pounding it into the users that you don't ever trust what it says in the navigation bar unless you typed it there yourself. Corrorlaries: (a) When following links on webpages, your level of trust should only be that of the least trusted page in the chain of links. (b) NEVER EVER, EVER, EVER trust a link in an unsigned email. 2) Pounding it into merchants, banks, etc., to make sure they never ask their customers to violate (1). But sorry, I do not have all of the answers either. [0] Perhaps a better analogy is that by cleaning up DNS, we are trying to prevent the iceburgs. We should be letting the indvidual merchants, banks, and other secure sites, the ships, make their own schemes for avoiding them. We could be helping them build stronger ships, something better than today's SSL, and mapping out where the iceburgs are, figuring out where they need to balance convenience versus security, than trying to clear the seas of all possible hazards. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: London incidents
[EMAIL PROTECTED] wrote: On Wed, 13 Jul 2005 09:26:33 +1200, Mark Foster said: Using phone company records, researchers assessed phone use immediately before the crash. They found a third of calls in the 10 minutes before the crash were made on cellphones. And the *other* 2/3rd of the calls were made on what, exactly? A land line just before departure, followed by a crash less than 10 minutes into the drive? (This would tie in well with the agitated by the phone call theory advanced by JC Dill...) Oh, gawd. Now I have to go read it myself. You can track this down pretty easily at the BMJ site, bmj.com, and download a PDF version. It's only 5 pages long. I don't see where they got that one third of the calls number above. As far as I can tell, the study only looks at mobile phone calls. As for the inattentive-risky driver and agitated driver theories, the researchers took (tried to take) this into acount by using a case-crossover design whereby individual drivers are their own control. Feel free to argue the results of the study, but read the study, not some confused newspaper summary, and please don't do it on NANOG. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Jay R. Ashworth wrote: On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Not really. Consider the logic in a NAT box: [ ... ] and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Now I'm confused. Who runs *on-machine* NAT? I guess that's another nice option for firewalls. It doesn't matter whether your firewall runs locally or on a remote gateway. Also, when people here are talking about NAT, note that we are only talking about many-to-one, overloading, PAT, or whatever you want to call it. If you are using NAT pools or one-to-one NAT, it buys you no protection at all unless you add firewalling to the mix. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Fred Baker wrote: [snip] A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. [snip] No, you can't use AH, but yes, you can use IPsec through NAT. See RFC3947 and RFC3948. But it is not pretty. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Petri Helenius wrote: Crist Clark wrote: And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. Any by connecting to one of the p2p overlay networks you'll have a few million in-use addresses momentarily. Preventing abuse of information available from databases maintained by P2P services is an emerging and interesting area of info sec. It may become more so as other means of harvesting live addresses become less productive. In The Future, the addresses of live hosts to attack may become an underworld commodity like valid email addresses are now. All of those are better than having Blaster or Slammer propagate so easily. At least make the malware authors work for it. If you were behind NAT, you couldn't use those P2P applications. So, yeah, you were safe on your limited-functionality, pseudo-IP, NATed connection from the Big Bad P2P. And if you still want the protection of NAT, any stateful firewall will do it. IMHO, if there is any reason NAT will live on in IPv6 it is the PI space issue. Even the NAP draft comes out and says, 4.7 Multihoming and renumbering Multihoming and renumbering remain technically challenging with IPv6... That plus the problems with the unique local proposals make it quite likely that NAT will not completely disappear should IPv6 become widespread. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: VerizonWireless.com Mail Blacklists
Mad props out to Mr. John Bittenbender who got me in contact with someone at VZW who was quick and helpful getting this fixed. Apparently, VZW did decide that our IAP as a whole originated too much spam and just blocked the whole thing. I don't know if they made their filters more precise or whitelisted our subnet, but mail to verizonewireless.com works for us now. Personally, I feel verizonwireless.com can filter whatever they want, BUT should stick to SMTP standards. Dropping connections with no SMTP banner, no error code is a Bad Thing. Give me a hint of why you don't like me with an error message and fail hard so outgoing messages don't sit queued up for days before my users get failure messages. And of course, if you're gonna block wide swaths of Internet, you should have mechanisms in place for your help desk to deal with blocked senders, customer and non-customers alike. But as usual, once you penetrate the front line of help desk drones, the real technical people are professional and helpful. Crist Clark wrote: It appears VerizonWireless.com has some rather aggressive mail filters. Verizon.net's blocking of Europe, Asia, Africa... well, everything but North America has made some headlines and even some lawsuits. Anyone know if VerizonWireless.com and Verizon.net are independent operations from an SMTP point of view? Verizon.net has, http://verizon.net/whitelist And I haven't found an equivalent for VerizonWireless.com. And given the differences in Verizon.net's and VerizonWireless.com's MX setup, I doubt they use common resources. Anyone here ever get off of their blacklist or even know what they are using? Even though we have accounts with them, I haven't been successful in getting through to clueful help *shock*. FWIW, it really looks like an IP-based blacklist. From our main mail server to any of their MX hosts, the 25/tcp connection completes, but then their server drops the connection, no banner, no nothing. I get a banner and can send mail to their servers from other IP addresses outside of that network. My guess is that they're using SPEWS? We're collateral damage in a SPEWS block. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
VerizonWireless.com Mail Blacklists
It appears VerizonWireless.com has some rather aggressive mail filters. Verizon.net's blocking of Europe, Asia, Africa... well, everything but North America has made some headlines and even some lawsuits. Anyone know if VerizonWireless.com and Verizon.net are independent operations from an SMTP point of view? Verizon.net has, http://verizon.net/whitelist And I haven't found an equivalent for VerizonWireless.com. And given the differences in Verizon.net's and VerizonWireless.com's MX setup, I doubt they use common resources. Anyone here ever get off of their blacklist or even know what they are using? Even though we have accounts with them, I haven't been successful in getting through to clueful help *shock*. FWIW, it really looks like an IP-based blacklist. From our main mail server to any of their MX hosts, the 25/tcp connection completes, but then their server drops the connection, no banner, no nothing. I get a banner and can send mail to their servers from other IP addresses outside of that network. My guess is that they're using SPEWS? We're collateral damage in a SPEWS block. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: what will all you who work for private isp's be doing in a few years?
Jim Popovitch wrote: Wow! You can buy groceries at Kohls now? :-) (1) Kohls is/was a regional (Wisconsin) grocery store chain[0]. (2) Please do not feed the trolls. On Wed, 2005-05-11 at 11:08 -0700, Matt Bazan wrote: why in the world would anyone want to purchase dsl from a private reseller when i can get 4mb down 384 up from comcast for $25? think you dsl resellers out there are doomed. in fact, just a matter of time before most of you isps are down the toilet. im reminded of the mom and pop grocery store phenomenon that has now been replaced by the kohls, ap, whole foods etc. of course there will always be niche markets but this is less applicable for a pure commodity like bandwidth. yeah, i suppose you'll say something about value added services and such and you may have a point but i doubt that will keep the ship afloat for long. [0] That's kind of a funny reference when you know what happened to Kohls Foods. They were bought by AP who subsequently closed or sold off the individual stores. Kohls Foods suffered the ma and pa-like fate described above. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Internet email performance study
aljuhani wrote: On Thu, Apr 28, 2005 at 23:42, Robert Beverly [EMAIL PROTECTED] ..snip Yes, our SMTP greetings are valid and up to spec. Again, it's the non-deterministic loss that we're most concerned about. If there were a problem with the SMTP exchange, we would see our emails always rejected (for instance). Our measurement study only includes emails that were successfully delivered (indicated by a complete series of successful status codes returned during SMTP exchange). Many thanks, rob Hi, Perhaps this explains it. http://www.albury.net.au/netstatus/derouted.html No, it doesn't. Please read their paper. In the paper and as he stated again in the response above, their definition of a loss requires the message to be delivered successfully in the first place. The anti-spam measure described in the above URL causes the remote MTA to not accept mail at all from the blocked source. This would not be counted as a loss in their methodology, but possibly as an error. BTW your subnet (18.0.0.0/8) is listed there as well. I don't see it there. And those are not censures of the entire /8 networks, but just a list of how many individual hosts in that network are currently blocked. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Internet email performance study
Brad Knowles wrote: At 3:05 PM -0700 2005-04-28, Crist Clark wrote: http://www.albury.net.au/netstatus/derouted.html No, it doesn't. Please read their paper. In the paper and as he stated again in the response above, their definition of a loss requires the message to be delivered successfully in the first place. The anti-spam measure described in the above URL causes the remote MTA to not accept mail at all from the blocked source. This would not be counted as a loss in their methodology, but possibly as an error. Yeah, but there are plenty of other places that will otherwise do the same sort of thing, but instead of de-routing the address, they will silently discard all messages from that IP address. AOL is one known big offender in that area, because I helped set up the bounce processing system at AOL that did exactly that. So, while albury.net themselves would not cause the kinds of results that are being seen, they do have an otherwise good explanation for the kinds of things that many sites tend to do when faced with excessive probes or other activity that they believe is likely to be an indication of spam or something that is spam-related. It's possible. Those with very sensitive threasholds that would pick up one email every fifteen minutes as a scan could produce drop rates between zero and one. Assuming the threashold detection is a well defined algorithm, however, one would expect the drops to be deterministic, e.g. after one hour (four sets) of attempts, they fall into black hole, come out after one hour, two hours, eight hours, or a day, and then the whole thing repeats. The authors couldn't find patterns, but that does not mean that there are not any patterns to find. I considered looking at their raw data myself until I saw it was a 100+ MB gzipped tarball. Anyone can test these kinds of theories if they are willing to download and slog through the data. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Slashdot: Providers Ignoring DNS TTL?
Dean Anderson wrote: I'd rather expect this sort of behavior with anycasted servers... I would not expect this kind of behavior from an anycasted address. You'd need a LOT of routing churn to see different caches every few seconds. It's much more likely some kind of load balancer in front of a DNS server farm. With a cache, the behavior is confusing, but also harms DNS TCP support, just like that described for authoritative servers. I verified it wasn't anycast by trying to exploit this very issue. I did a query that fell back to TCP while doing multiple small queries. I ran a network capture to pick out the short quries that occurred while the TCP query was going on. Short quries during the TCP connection came back with verying TTLs indicating that I was talking to different caches, i.e. different servers. Yet the TCP query continued without any hiccups. This indicates there is some type of per-session load balancing going on, not anycast routing. Further there isn't a good reason to have anycasted caches. Indeed, with DHCP-learned nameservers, there is negative reasons to have anycast. Anycast balancing will never be as good as random selection from the appropriate set given by DHCP. Frequently, [judging by the questions asked on DNSOP about setting up anycast caches, anyway], the goal of such gyration is high availability. However, its [been] fairly easilly shown that this goal isn't achieved. Since this isn't anycast routing, can we save the religious diatribes for another thread? On Tue, 19 Apr 2005, Crist Clark wrote: FWIW, I did some 'dig'ing on my Comcast home service. The DHCP is handing out 204.127.198.4 and 63.240.76.4 for DNS at the moment. I ran a query for a name in a zone I control that has a five minute TTL on 204.127.198.4. The first query came up with 5 minutes. I quickly made a change to the zone. hirty seconds after the initial query, I try again... err... and come up with the change. Hmm... Not caching at all? Another 30 seconds and I get the change, with 5m TTL. Thirty seconds later, I get the original response with appropriately decremented TTL. Another thirty seconds, I get the change, with 4m TTL. My findings: Comcast is now using some kind of load balancing that messes with this kind of testing. 204.127.198.4 is not a single resolver. However, as far as I could tell, they were obeying the TTL. After 5 minutes, all of the responses were coming back with the change. The TTL values in the responses were decrementing as expected. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Survey of interest ..
[EMAIL PROTECTED] wrote: [snip] I'll predict that if we *don't* have an attack on the power grid in the next 10 years, it's because the attackers have come up with something else they consider even more interesting as a target. A downed power line, even though it may have more economic impact, has less emotional impact. And between natural disasters, ice storms, fat operator fingers, and hot evenings that strain the grid to breaking, most people have delt with power outages enough that there is nothing novel about them. These regular outages do not cause sigificant injury or loss of life. Not a lot there to cause terror. OTOH, coordinating an attack on a power grid with some other attack(s), that could get them some bang for the buck. Remember that last big one in the northeast? The government kept reassuring that it wasn't terrorism... like that means there isn't a security issue. If a few dopes at a one power company can collapse the whole northeast grid, there IS a security problem. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Clueful DNS Contact at XO?
We have some Direct Internet Access (DIA) through XO. We have several netblocks with them and would like to get the IN-ADDR.ARPA domains for these blocks delegated to us. Should be just a couple of NS records in the parent zone, right? No big deal, right? After several attempts over years and months to get this done, I'm appealling for an out-of-band source. All DNS stuff is handled through the Web Hosting end of the house, but we have no web hosting accounts, only DIA. Plus, our DIA account dates far enough back (to Concentric days), that the DNS servers that do secondary for some of our forward zones aren't even ones that the web hosting people run. (Not that this really should have anything to do with IN-ADDR.ARPA zones, but try explaining that to the phone droid.) This all causes much confusion, and I never seem to get anywhere. It would be really super-duper cool if we could even get RFC2317-style delegation for some /27's we also have, but I was always afraid I'd hear the *pop* of the head on the other end of the phone exploding if I brought that up. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Anycast 101
Iljitsch van Beijnum wrote: Due to limitations in the DNS protocol, it's not possible to increase the number of authoritative DNS servers for a zone beyond around 13. I believe you misspelled, Due to people who do not understand the DNS protocol being allowed to configure firewalls... -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Anycast 101
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Crist Clark writes: Iljitsch van Beijnum wrote: Due to limitations in the DNS protocol, it's not possible to increase the number of authoritative DNS servers for a zone beyond around 13. I believe you misspelled, Due to people who do not understand the DNS protocol being allowed to configure firewalls... No, firewalls have nothing to do with it. Section 4.2.1 of RFC 1035 says: Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). There's a large installed base of machines that conform to that limit and don't understand EDNS0. I'll leave the packet layout and arithmetic as an exercise for the reader (cheaters may want to run tcpdump on 'dig ns .' and examine the result), but the net result is what Iljitsch said: you can only fit about 13 servers into a response. Into a UDP response. A resolver will recieve the first 512 bytes of the truncated response and may then use TCP to get the complete response... unless there is a firewall blocking 53/tcp in the way. But how often does that happpen? The root servers sustaining the ensuing SYN flood is another issue. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: verizon.net and other email grief
Krzysztof Adamski wrote: On Fri, 10 Dec 2004, Jeffrey I. Schiller wrote: On Fri, Dec 10, 2004 at 12:26:59PM -0500, Rich Kulawiec wrote: One thing that's not clear is whether or not Verizon caches any of this information. It appears that they do some amount of caching. -Jeff It does not appear that they are caching it, here is a sample from my log file: Dec 6 19:18:15 white sm-mta[25976]: iB70IF6n025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:15 white sm-mta[25977]: iB70IF6n025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6n025976: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6n025977: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: [EMAIL PROTECTED]... User unknown Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: lost input channel from sc006pub.verizon.net [206.46.170.182] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25976]: iB70IF6o025976: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc006pub.verizon.net [206.46.170.182] Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: lost input channel from sc019pub.verizon.net [206.46.170.68] to MTA after rcpt Dec 6 19:18:16 white sm-mta[25977]: iB70IF6o025977: from=[EMAIL PROTECTED], size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=sc019pub.verizon.net [206.46.170.68] What happens when verizon tries to send email to somebody who does the same type of check, does this not create an infinite loop? Not if Verizon treats the antispam[0-9]+ mailboxes in a special manner and answers without a check. And they have to answer that the box exists or things are gonna _really_ break. Doing a quick test using the last antispam[0-9]+ address in my SMTP logs, I got all 250 responses without a more recent call back. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: ULA and RIR cost-recovery
Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 ULA answer be the same as the IPv4 RFC1918 answer, I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.) I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too? If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a corporate VPN or layer two network to route private addresses. Wouldn't providers be happy to offer the same service, for the same extra $$$, in IPv6? Especially when you consider that you can just drop the routes for the ULAs in your interior routing tables since ULAs are well, unique, and you're done. No tunnelling or other levels of indirection required. Charge the same or more for the business-level service that you offer now, but there is less work for you to do it. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Stupid Ipv6 question...
Lars Erik Gullerud wrote: On Fri, 2004-11-19 at 16:36, Stephen Sprunk wrote: /127 prefixes are assumed for point-to-point links, and presumably an organization will divide up a single /64 for all ptp links -- unless they have more than 9,223,372,036,854,775,808 of them. While that would seem logical for most engineers, used to /30 or /31 ptp links in IPv4 (myself included) Aren't most engineers used to the fact that point-to-point links are not broadcast links and therefore the concept of a network/netmask for the interface is somewhat useless? In addition, link-local addressing eliminates many situations where you need to allocate tiny blocks for p2p links. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
KAME on IPv4? (was: Re: IPV6 renumbering painless?)
Daniel Roesen wrote: On Fri, Nov 12, 2004 at 05:19:36PM +0100, Simon Leinen wrote: specified the entire 128 bits... how do you specify only part of it? On Solaris, you would use the token option (see the extract from man ifconfig output below). You can simply put token ::1234:5678 into /etc/hostname6.bge0. I assume that other sane OSes have similar mechanisms. Ah thanks. No, not seen anywhere in Linux or *BSD. I would expect it to be an configuration option for rtsold(8) in KAME- derived stacks and not in ifconfig(8). Errr... Not that I see it in there either. Trying to check a more recent KAME code base brings me to a real question I've had. Does http://www.kame.net/ have an IPv4 mirror somewhere? $ dig @orange.kame.net www.kame.net any ; DiG 8.3 @orange.kame.net www.kame.net any ; (2 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54483 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.kame.net, type = ANY, class = IN ;; ANSWER SECTION: www.kame.net. 1D IN 2001:200:0:8002:203:47ff:fea5:3085 ;; AUTHORITY SECTION: kame.net. 1D IN NSorange.kame.net. kame.net. 1D IN NSns1.itojun.org. ;; ADDITIONAL SECTION: orange.kame.net.1D IN A 203.178.141.194 orange.kame.net.1D IN 2001:200:0:8002:203:47ff:fea5:3085 ;; Total query time: 160 msec ;; FROM: sec-tools.corp.globalstar.com to SERVER: 203.178.141.194 ;; WHEN: Fri Nov 12 14:05:13 2004 ;; MSG SIZE sent: 30 rcvd: 151 -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Slightly OT: Flannery VS RSA
Mike Lyon wrote: I haven't heard much lately about Flannery. Have their been any implementations or benchmarks of the flannery Cayley-Purser algorithm in comparison to RSA in the real world? Non-starter. http://mathworld.wolfram.com/Cayley-PurserAlgorithm.html -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: ICMP weirdness
Jim Popovitch wrote: From Comcast Cable, at my home in Atlanta, I can ping 10.10.1.1 which is pong'ed from a private client network hanging somewhere off of Insight Broadband's network in the North Central part of the US. Why on god's green earth do network operators allow such nonsense as this? FWIW, I get the same result from Comcast residential coax service from Santa Clara, CA using a plain ol' *nix UDP traceroute. (This is not ICMP specific.) raceroute 10.10.1.1 traceroute to 10.10.1.1 (10.10.1.1), 64 hops max, 44 byte packets [snip my internal net] 3 12.244.25.145 (12.244.25.145) 17.315 ms 17.378 ms 17.492 ms 4 12.244.67.17 (12.244.67.17) 33.548 ms 23.702 ms 13.066 ms 5 12.244.72.206 (12.244.72.206) 21.554 ms 18.118 ms 18.589 ms 6 gbr2-p50.sffca.ip.att.net (12.123.13.62) 23.677 ms 31.973 ms 18.647 ms 7 tbr1-p012702.sffca.ip.att.net (12.122.11.69) 24.447 ms 19.266 ms 19.036 ms 8 tbr1-cl2.sl9mo.ip.att.net (12.122.10.41) 73.801 ms 66.745 ms 71.541 ms 9 gbr2-p10.sl9mo.ip.att.net (12.122.11.102) 68.524 ms 62.157 ms 66.172 ms 10 gar1-p370.sl9mo.ip.att.net (12.123.24.213) 68.568 ms 65.325 ms 62.455 ms 11 12-220-0-69.client.insightBB.com (12.220.0.69) 93.072 ms 98.102 ms 91.132 ms 12 12-220-7-198.client.insightBB.com (12.220.7.198) 88.131 ms 83.943 ms 85.713 ms 13 10.10.1.1 (10.10.1.1) 159.507 ms 101.956 ms 95.575 ms I know that Comcast (formerly ATT BB) uses the 10-net internally on their transit networks so they can't just blackhole the stuff. Insight's ISP is ATT (now Comcast?). Looking quickly at the ATT looking glass, Insight appears to not have its own AS. RFC1918 successfully crossing between ASes would be a Very Bad Thing. However, it looks like it is completely within ATT here. Not a Good Thing, but not the end of the world. For all I know, 10.10.1.1 might be ATT equipment using their internal 10-net. Traceroute -I 10.10.1.1 produces the following: traceroute to 10.10.1.1 (10.10.1.1), 30 hops max, 38 byte packets 1 10.238.10.1 (10.238.10.1) 29.089 ms 25.387 ms 28.574 ms 2 66.56.22.66 (66.56.22.66) 30.923 ms 31.305 ms 33.142 ms 3 66.56.22.70 (66.56.22.70) 35.945 ms 35.874 ms 36.832 ms 4 c-66-56-23-38.atl.client2.attbi.com (66.56.23.38) 34.740 ms 35.041 ms 37.537 ms 5 12.118.184.41 (12.118.184.41) 41.967 ms 45.584 ms 43.997 ms 6 gbr2-p70.attga.ip.att.net (12.123.21.6) 44.988 ms 44.706 ms 43.033 ms 7 tbr2-p013602.attga.ip.att.net (12.122.12.37) 49.353 ms 44.010 ms 45.244 ms 8 12.122.10.138 (12.122.10.138) 62.244 ms 62.269 ms 62.148 ms 9 gbr1-p40.sl9mo.ip.att.net (12.122.11.114) 60.922 ms 67.005 ms 60.264 ms 10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 59.572 ms 64.013 ms 60.198 ms 11 12-220-0-69.client.insightBB.com (12.220.0.69) 77.000 ms 76.050 ms 77.926 ms 12 12-220-7-198.client.insightBB.com (12.220.7.198) 95.437 ms 80.068 ms 84.076 ms 13 10.10.1.1 (10.10.1.1) 93.612 ms 97.280 ms 192.994 ms -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Website contact for www.cisco.com
Temkin, David wrote: Can someone responsible for either security or operations of www.cisco.com please contact me? We are seeing an issue where you may be blocking one of our source IP addresses from accessing the website. Hmmm... Weird. We're having a similar issue. If you are at liberty to, could you please publicly or privately let me know what's going on here and whether it is a bug or feature? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Senator Diane Feinstein Wants to know about the Benefits of P2P
Scott Call wrote: On Mon, 30 Aug 2004, Mike Tancsa wrote: I recall even seeing posts about people claiming this meant original data being reconstructed from the checksum! That would be truly amazing since I could reconstruct a 680MB ISO from just 61d38fad42b4037970338636b5e72e5a. Wow! Technically, using an Infinate Monkeys approach, you could rebuild the ISO by generating the expentially huge quantity of all possible data and check them and find the one that matches the ISO. Not practical but possible. Not possible. There are, theoretically, many 680 MB ISOs that have that hash. That you produce _a_ 680 MB ISO that has that hash does not mean that you have _the_ particular 680 MB ISO that produced it. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Senator Diane Feinstein Wants to know about the Benefits of P2P
Gregory Hicks wrote: Date: Mon, 30 Aug 2004 16:39:56 -0400 From: Mike Tancsa [EMAIL PROTECTED] At 04:12 PM 30/08/2004, Dan Hollis wrote: yep md5 made the news recently because it's been cracked: http://techrepublic.com.com/5100-22-5314533.html http://www.rtfm.com/movabletype/archives/2004_08.html#001055 Thats a misleading over simplification. A collision being found implies something different than its cracked. A weakness that was theorized sometime ago has been demonstrated in practice. Finding collisions and altering files in a useful way to produce a duplicate hash are different things. There are FAR bigger security concerns than this one right now IMHO. I recall even seeing posts about people claiming this meant original data being reconstructed from the checksum! That would be truly amazing since I could reconstruct a 680MB ISO from just 61d38fad42b4037970338636b5e72e5a. Wow! Actually... The collision problem discovered means that there might be MULTIPLE 680MB files that give the same checksum. There MUST BE multiple 680 MB files that give the same checksum. A checksum is a many-to-one operation. If MD5 were a perfect checksum, it would map each and every 128-bit strings to another 128-bit string. However, for an 129-bit string, you have twice as many initial strings, but still just 128-bits of hash values. If the checksum is perfectly distributed, each 128-bit hash would have to correspond to _two_ initial strings. If you think about it for a second, if you have an initial bit string of length 'n' and a hash of length 'm,' the number of collisions for a perfectly distributed checksum (the number of initial strings that produce the same hash) is, 2^(n - m) Now, a 680 MB file is about a 5704253440-bit string. That would imply there are about 2^5704253312 strings that correspond to that one hash. Good luck generating _one_ of those. And extra good luck in finding the ones of the 2^5704253312 that comply with ISO 9660. And a tad more good luck in finding the ones in there that might make sense being the particular ISO image you want. The issue with MD5 is that there may be techniques for an attacker to generate collisions (and again, there MUST BE collisions) using many fewer operations than a brute force approach. The brute force approach has always existed. There is no perfectly secure crypto, only crypto that is secure enough for this application for now. MD5 is still safe enough for most applications for now (hell, DES is safe enough for most applications for now). However, it should be looked at as depricated and phased out, i.e. not used in new protocols and products. The Death of the Internet has not been predicted. There will be no film at eleven. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: SPF again (Re: XO Mail engineers?)
Edward B. Dreger wrote: DAU Date: Wed, 4 Aug 2004 15:46:17 -0700 DAU From: David A. Ulevitch DAU SPF's use of TXT records doesn't bother me so much. It's Perhaps some other technology would like to use TXT RRs. If something hogs an entire RRTYPE at a given scope, it really should have its own RRTYPE. An acceptable alternative would be KRB5-style _foo entries. All IMHO. Last time I looked, draft-ietf-marid-protocol-00.txt addressed this issue, 2.1.1 DNS Record Type The record type is a textual RR type to be allocated by the IANA for this purpose. However, because there is a large number of domains with these records already deployed as TXT type records, and because there are a number of DNS server and resolver implementations in common use that cannot handle new RR types, the record type can be TXT. Domains SHOULD publish records under both types. If a domain does publish under both types, then they MUST have the same content. Mail receivers SHOULD query for both types of records. If both are returned, then the new RR type MUST be preferred. It is recognized that the current practice (using a TXT type record), is not optimal, but a practical reality due to the state of deployed records and software. The two record type scheme provides a forward path to the better solution of using a RR type reserved for this purpose. For either type, the character content of the record is encoded as US-ASCII. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Attn MCI/UUNet - Massive abuse from your network
Jeff Shultz wrote: ** Reply to message from Brad Knowles [EMAIL PROTECTED] on Fri, 25 Jun 2004 18:14:43 +0200 At 8:44 AM -0700 2004-06-25, Jeff Shultz wrote: At least if someone in this clearing house sells it to the terrorists, they will have had to work for it a bit, instead of having us hand it to them on a silver platter, as the FCC seems to want. Not true. If the information is forced to be completely in the open, then everyone knows it's not insecure and no one depends on the fact that it was supposed to be kept secret. This is a case where you are more secure the more open the information is -- indeed, as we are in most cases, which is why we have the age-old security mantra of security through obscurity is not secure. Do you realize that the basic element of security, the password, is based on the entire premise you just dismissed? And yet we still use them - and depend on the fact that they are supposed to be kept secret. The problem with being totally open about infrastructure is that there are some vulnerabilities that simply cannot or will not be fixed - wires sometimes have to run across bridges, redundant pumping stations are too expensive... in these cases is it not better to hide where these vulnerabilities are? Not really. Security through obscurity in some circumstance can help, but rarely when it comes to something like that. When it comes to wires crossing a bridge or pumping stations, anyone who tries hard enough will find out pretty easily. You end up with two groups knowing where the vulnerabilities are, the handful of good guys who oversee the resources and the bad guys. It strikes me as similar to the outcry from the locksmith community when the vulnerabilities of various master key mechanisms were widely published. Who knew about the vulnerabilities? The good guy locksmiths who used the vulnerabilities to break into your office when you lost your keys (and sold you the locks) all knew, and the bad guys who broke into your office to steal stuff knew. Who didn't know? The consumer who was unable to make an informed decision about the security of the various choices of key-lock mechanisms he had available. So the problem with the pumping station or the wires over the bridge are that the limited number of experts know, the bad guys know, but other people who should know (the network engineer judging the reliability of his links or the civil engineer deciding the capacity for an emergency water tower for an industrial site) may not understand the true vulnerability of the system. But that doesn't mean we shouldn't put a fence around the pumping station or a padlock on the door because a key is just security through obscurity through some convoluted logic. The problem with your point is that even if the information is forced to be completely in the open, that is no guarantee that it will be fixed, and people _do_ depend on this stuff, regardless of its reliability or security. Somethings cannot be and should not be fixed. Making the public water supply invulnerable to earthquake damage is not practical. Individuals have the responsibility (even if most don't) to keep a few days supply of potable water available in the inevitable, but unlikely on any given day, event of a powerful earthquake. Making various infrastructure invulnerable to every foreseeable, let alone unforeseeable, attack is not practical either. But those who are affected by the failure of any piece of infrastructure need to know how reliable it is and plan accordingly. Do you really think that if we publish all the insecurities of the Internet infrastructure that anyone is gonna stop using it, or business, government, and private citizens are going to quit depending on it? Of course not. But they may be better able to quantify their risks in depending on the 'Net and make contingency plans where it is prudent. The real world is about risk management; even the US federal government has given up on a risk avoidance model and moved to risk management. Security through obscurity is not secure - but sometimes it's all you have. But it is worse than nothing when you obscure the truth from people who should know. If the vulnerability is exploited, the impact is worse than if those who should have known had had the ability to plan for the contingency. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Can a customer take IP's with them?
David Schwartz wrote: On Tue, 22 Jun 2004, David Schwartz wrote: [snip] For instance, if what you say were true, all an ISP would have to do in order to sell their IP space is to create a contract stating that they are doing so. Exactly. If they did that, a court would likely enjoin them from making any action to interfere with the customer's use of those IP addresses. A court would likely find the contract binding upon the parties that entered into it. Hey, I've got a bridge I'd like to sell you. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Even you can be hacked
Richard Welty wrote: On Fri, 11 Jun 2004 17:51:00 -0400 (EDT) Scott McGrath [EMAIL PROTECTED] wrote: But wouldn't an interocitor with electron sorter option give you much more reliable packet delivery... that works fine until someone reverse the polarity of the neutron flow. And for heaven's sake, don't cross the streams! (It must be Friday.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Even you can be hacked
Sean Donelan wrote: If you leave your lights on, the electric company will send you a bill. If the neighbor taps into your power lines after the meter...? If you leave your faucets running, the water company will send you a bill. If you leave your computer infected, ??? If you lose your credit card and someone runs up thousands of dollars in charges, the credit card company sends you a bill... But you can at most be held responsible for $50. Does that really mean anything with respect to Mr. Donelan's quoted article? Not really. But neither do electric and water bills. I have some sympathy for the malware victim. But I don't expect the ISP to eat all of the costs. The article is more balanced than the selected quotes portray. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Even you can be hacked
Andy Dills wrote: On Thu, 10 Jun 2004, Laurence F. Sheldon, Jr. wrote: Jeff Shultz wrote: But ultimately, _you_ are responsible for your own systems. Even if the water company is sending me 85% TriChlorEthane? Right. Got it. The victim is always responsible. There you have it folks. Change the word victim to negligent party and you're correct. It would be great if there always was a negligent party, but there is not always one. If Widgets Inc.'s otherwise ultra-secure web server gets 0wn3d by a 0-day, there is no negligence[0]. Who eats it, Widgets Inc. or the ISP? So how about this analogy: Someone breaks into my house and spends a few hours on the phone to Hong Kong. Who eats the bill, me or my LD carrier? Neither of us was negligent. [0] Unless someone can prove the software flaw was sloppy enough that it constitutes negligence and goes after the software authors. Good luck with that. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: IT security people sleep well
Sean Donelan wrote: Survey: Despite dangers, IT personnel sleep well By Bill Brenner, News Writer 27 May 2004 | SearchSecurity.com I liked this quote, About 43% of respondents said they're using the Secure Shell (SSH) protocol to protect data, secure remote access, and perform network management. But while the current SSH2 is considered to be significantly more secure, nearly 45% said they are continuing to mostly use the older SSH1 protocol. A cause for greater concern, according to the surveyors, is that 54.9% said they continue to configure their network devices via Telnet, which is known by network security experts to be severely vulnerable to intruders because it sends data as clear text and offers only weak password authentication. For Marc Orchant, head of communications at VanDyke, that was one of the biggest shockers, especially since it costs little or nothing to upgrade these protocols. It costs little or nothing to upgrade? Does it seem a bit disingenuous for a remark like that to come from someone at a company that sells a commerical SSH distribution? Anyone from the real world knows that there are real and significant costs to convert an existing infrucstructure with telnet, the r-protocols, ftp, and all of their unencrypted, unauthenticated friends to SSH and SSL secured connections. Yeah, maybe the software licencing costs are little to nothing, but the administrative overehead of converting all of your other scripts and software, plus lots and LOTS of retraining of admin and users can be very expensive or simply infeasible. And just one more quote, I guess the message here is that ignorance is bliss, said Steve Birnkrant, chief executive officer of Amplitude Research Inc., which conducted the survey on behalf of Albuquerque, N.M.-based VanDyke Software Inc. What most surprised me was the general sense of complacency. Much has been written in the media about security issues, and this makes me wonder if people are listening. Why aren't people listening? I think Mr. Birnkrant needs to go way back to old childhood fables and have a refresher on the boy who cried, Wolf! -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: ntp config tech note
C. Jon Larsen wrote: [snip] Its interesting to hear what other folks are doing. I had assumed folks normally don't run ntpd on each and every server and that ntpdate + cron was much preferred; maybe I am off-base. After the last big xntpd vulnerability a few years ago, I went through and made sure that I had the permissions set appropriately, restrict server1noquery nomodify restrict server2noquery nomodify ... restrict 127.0.0.1 nomodify restrict defaultignore On UNIXen servers. Of course, I upgraded my daemons where possible, but the vulnerability occurred late enough in the message processing that the approprate restrictions prevented exploit (the packet was dropped before the vulernable code was reached). Of course, there still is the potential for vulnerabilities very, very early in message processing, or in spoofed query responses if someone knows what servers I use and is behind the firewall. But overall, I like it much better than what the UNIX admin here used to do, 0 2 * * * rdate timehost -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Secondary MX user list filter for Sendmail
Todd Vierling wrote: A colleague asked me offlist about how to make a Sendmail secondary MX properly return 550 for invalid recipient addresses. [snip] For those with an LDAP directory containing mailbox information, I'd recommend using sendmail's built-in LDAP capabilities. I've found it a good way to test for existence of mailboxes at border MTAs. My example (NOTE: I've pulled out the LDAP stuff from a rather complex .mc file, and it can be done in a more straightforward way without all of the other hacks I'm simultaenously supporting in my rulesets), LOCAL_CONFIG Kldap_rcpt ldap -b dc=example,dc=com -h directory.example.com -TTMPF -v mail -k ((objectClass=inetLocalMailRecipient)(!(inetUserStatus=deleted))(!(inetMailGroupStatus=deleted))(|(mail=%0)(mailAlternateAddress=%0)(mailEquivalen tAddress=%0))) LOCAL_RULESETS # Check if local addresses really exist on central server. SLocal_check_rcpt R $+ $1 R$+ @ $=R $: $1 @ $2 $| $(ldap_rcpt [EMAIL PROTECTED] $: NOMATCH $) R$* $| NOMATCH$#error $@ 5.1.1 $: 550 User unknown -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: TCP/BGP vulnerability - easier than you think
David Luyer wrote: [snip] With ipsec, you have crypto overhead before you have any opportunity to do the basic sanity check. Minor point, but with IPsec, the 32-bit SPI and the 32-bit replay counter are very low cost ways to drop the majority of traffic from a flood of random junk with no crypto calculations. You actually have more bits with AH or ESP than with TCP. The 32-bit SPI must be an exact match like the two 16-bit port fields, and you have 32-bits of sequence number in both, but the TCP window is much larger than the IPsec window (usually 6-bit by default) leaving you more bits to check. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: TCP RST attack (the cause of all that MD5-o-rama)
E.B. Dreger wrote: PG Date: Wed, 21 Apr 2004 07:45:36 +0100 PG From: Peter Galbavy PG E.B. Dreger wrote: PG I don't think we're even that far along. If I'm reading FreeBSD PG 4.9 and NetBSD 1.6.2 source correctly, PG PG /usr/src/sys/netinet/in_pcb.c PG PG Should have stretched as far as OpenBSD then. Same file. Didn't have it handy, too lazy to grab a tarball, and didn't want to overreach. :-) CVS Web is da bomb. http://cvsweb.freebsd.org/ http://cvsweb.netbsd.org/ http://www.openbsd.org/cgi-bin/cvsweb/ -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: TCP RST attack (the cause of all that MD5-o-rama)
Patrick W.Gilmore wrote: On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote: On Tue, 20 Apr 2004, James wrote: i can see this 'attack' operational against a multihop bgp session that's not md5'd. now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1. you can engineer packets to make sure they have the right ttl when they arrive, ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :) Not if you use the TTL hack. Seems like that would be much more useful, and less CPU intensive, and less prone to user error, etc., etc. than MD5 But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: TCP RST attack (the cause of all that MD5-o-rama)
Dan Hollis wrote: On Tue, 20 Apr 2004, Crist Clark wrote: But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers. Does MD5 open the door to cpu DOS attacks on routers though? Eg can someone craft a DOS attack to take out the CPU on a router by forcing it to MD5 authenticate torrents of junk packets, using less bandwidth than it would take to DOS the links themselves? A reasonable implementation of RFC2385 would only do the cryptographic MD5 check after matching the TCP 4-tuple and the sequence number. So, with respect to the attack under discussion, only the packets that would have succeded in reseting the session make it to MD5 processing where they then would be dropped. Still, hitting the TCP stack even without doing the MD5 checks can kill a router. That's what the TTL hack was suggested for in the first place. As has been pointed out, blind attacker needs to guess the source port as well, which would seem to multiply the search space blind attackers need to hit (the tcpsecure paper states as much - assuming the attacker can accurately guess both ports) Are such attacks still practical in that light? Yes. Most OSs do not randomize port numbers, but start at a fixed value at reboot. On top of that, many do not use much of the 16-bit space before wrapping. Now add that most BGP speakers don't initiate much TCP and fire up their long lived BGP sessions at boot time. The search space is not that big. Then there's always going to a looking glass and just looking one up. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Lazy network operators
Chris Palmer wrote: When evaluating spam solutions, the first thing I ask is, Does this empower users? If the answer is no, it's probably the wrong solution. Spammers are users too. You can't spell abuser without user. You are inherently trying to diminish the power of the abuser users. No spam mitigation solution can ever answer, yes, to that question without the qualification that at least some users, the abusers, will be disempowered. The equation will always come to balancing how hard you hit the spammers versus minimizing the collateral damage. Or it's another classic example of security versus usability. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: DNS requests for 1918 space
Geo. wrote: Can anyone point me at any papers that talk about security issues raised by private networks passing dns requests for RFC 1918 private address space out to their ISP's dns servers? I've never seen the whole paper on the topic. Leaking the fact that you use 10.10.10.0/24 or whatever internally is not a big deal. It's security by obscurity of the very weak kind. Anyone with half of a clue will drop traffic with a source or destination address of their internal RFC1918 networks at the border, (and even if one uses registered addresses internally, you would be dropping traffic with a souce address of the internal network from entering at the border). That's the real security. I'm aware of the issues involved with an ISP passing the requests on to the root servers but was looking specifically for security type issues relating to a private network passing the requests out to their ISP's dns servers. These requests will not go to the root servers any more than any other reverse lookups ISP's DNS, $ dig -x 10 ns ; DiG 8.3 -x ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUERY SECTION: ;; 10.in-addr.arpa, type = NS, class = IN ;; ANSWER SECTION: 10.in-addr.arpa.1W IN NSblackhole-1.iana.org. 10.in-addr.arpa.1W IN NSblackhole-2.iana.org. ;; ADDITIONAL SECTION: blackhole-1.iana.org. 16m43s IN A 192.175.48.6 blackhole-2.iana.org. 16m43s IN A 192.175.48.42 ;; Total query time: 53 msec ;; FROM: sec-tools.corp.globalstar.com to SERVER: default -- 207.88.152.10 ;; WHEN: Tue Mar 16 09:53:44 2004 The IN-ADDR.ARPA delegations for RFC1918 space are just like any other block. You'll just end up hitting IANA's blackhole servers, and not all that much, the cache times are one week. Of course, the obvious fix is to run your own internal DNS which is authorative for your RFC1918 addresses. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: DNS requests for 1918 space
Duane Wessels wrote: The IN-ADDR.ARPA delegations for RFC1918 space are just like any other block. You'll just end up hitting IANA's blackhole servers, and not all that much, the cache times are one week. In theory, yes. In reality there are quite a few resolvers that, apparently, do not receive the delegation response and continue to hit the roots with PTR queries for RFC1918 space. Is there something special about RFC1918 in this respect? Wouldn't these resolvers not work for all of the IN-ADDR.ARPA space? Wouldn't they be hitting the roots with all kinds of PTR queries? Recent measurements at a single instance of an anycasted root server show that at least 250 such resolvers generate between 60-120 RFC1918 PTR queries/sec. I assume (and no idea really if it is a good assumption or not) that the bulk of these broken resolvers do not belong to ISPs. The original recipient said specficially that he was using his ISP's nameservers. If he has broken resolvers, but the ISP servers are sane, he'll obviously end up pounding the ISP servers and perhaps the IANA blackhole servers if the queries are unique, but not the root servers. But yes there are plenty of broken resolvers out there. One of my current favorites is something in Novell print services that likes to do A queries on a single printer name several dozen times per second, wait a few seconds or minutes, then do a query storm on another printer name. These account for over 90% of the queries on some internal DNS servers. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Enterprise Multihoming
Jay Ford wrote: [snip] Many/most of my external connectivity problems are provider-related rather than circuit-related. Having two circuits to a single provider doesn't help when that provider is broken. I'm not saying that multi-ISP BGP-based multi-homing is risk-free, but I don't see multi-circuit single-provider as a viable alternative. FWIW, I've had almost the exact opposite experience. Almost all of our connectivity problems have been circuit issues. Two T1s to the same ISP at one site has saved us from a lot of pain. OTOH, we also do have some ISP diversity, though we haven't needed it nearly as much as redundant circuits. YMMV. HAND. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: dealing with w32/bagle
Laurence F. Sheldon, Jr. wrote: Jeff Shultz wrote: ** Reply to message from Laurence F. Sheldon, Jr. [EMAIL PROTECTED] on Wed, 03 Mar 2004 22:04:44 -0600 Curtis Maurand wrote: Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this. [snip] My personal favorite that at one time would have been the easiest to develop has a MUA that attaches the document by storing the text in an HTTP-accessible archive (on the sender's machine? on the sender's MTA machine?) and including a URL in the email. And how is this going to slow viruses passed around by the mad clickers? The email has a link they click on and the MUA downloads the message. This is pretty much how IMAP works anyway, just that the attachment is available for download at their IMAP server and arrived there over SMTP rather than some remote HTTP, FTP, or whatever server. My personal objection to embedded attachments is not a product of the virus rage going on-- Ah, so this method of delivering content really is not meant to deal with this. We have to face it. The only real technical solution I am aware of is not allowing users to run arbitrary code on their systems. It looks like if you allow that, someone will be able to socially engineer enough moro^W users to download malicious code and execute it. C'mon, the current Bagle strains require the user to unzip the file, manually enter the password to the zip that's in the message body, then execute the unzipped file. It's spreading like wildfire. And we wonder who is gullible enough to buy spamvertized organ enlargement products or fall for a phishing scam? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
Sam Stickland wrote: [EMAIL PROTECTED] wrote: P.S. I think a solution lies in the general direction of converting the entire world to use 112 for emergency services and having the VoIP services set up an automated system that rings back whenever your phone connects using a different IP address and asks you where you are. For what it's worth, I believe here in the UK dialing just 99 will also connect you to the emergency services. The rational is that if you are behind a switchboard you have to dial 9 to get an outside line, and in the heat of the moment you might forget to dial four nines. That's definately an advantage that 999 has, taht 911 and 112 don't? No, 911 wouldn't work that way, but I do know that just dialing '91' will get you there too (in some places anyway). I'm so used to typing '9' before dialing out from the office that sometimes at home I hit the '9' first. I did it once before trying a long distance number. I hit '91,' and perhaps another digit, but definately not another '1,' before realizing what I had done and hung up. A few seconds later my phone rang. A 911 operator was on the other end asking me if everything was OK. So, if '99' works there and '91' here, I'm not sure if it is an actual intended feature or an explanation someone thought up after the fact (like what does USR in /usr stand for?). Also, '9' is common, but by no means the universal digit to get an outside line for a PBX. To steer a little ways back on topic, perhaps looking at the standards for how mobile phones deal with emergency services is better analogue for mobile IP phones than how POTS does things. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Interesting BIND error
Brian Bruns wrote: On Thu, February 12, 2004 4:52 pm, Brian Wallingford said: We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same. Seems harmless enough, but the logging is eating a disproportionate amount of cpu. Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Its possible that someone is spoofing UDP packets to your nameserver from that IP range (which is IANA reserved space). That's the old Class E space. Definately not routed over the Internet. It looks like BIND is refusing to send to that address, and thus the error. Or the OS is. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1
Martin Hepworth wrote: Alexei Roudnev wrote: Checkpoint is a very strange brand. On the one hand, it is _well known brand_, _many awards_, _editors choice_, etc etc. I know network consultant, who installed few hundred of them, and it works. On the other hand, every time, when I have a deal with this beasts (we do not use them, but some our customers use), I have an impression, that it is the worst firewall in the world: - for HA, you need very expansive Solaris cluster (compare with PIX-es) /I can be wrong, but it is overall opinion/. - to change VPN, you must reapply all policy, causing service disruption (I saw 1 day outage due to unsuccesfull Checkpoint reconfiguration); - VPN have numerous bugs (it is not 100% compatible with Cisco's by default; of couse, I can blame Cisco, but Checkpoint is _the only_ one of my peers which have this problem); - Configuration is not packed in 1 single file, so making difficult change control, etc etc... All this is _very_ subjective, of course; but - those customers, who uses Checkpoints, are the only ones who had a problems with firewalls. If I compare it with plain, reliable and _very simple_ PIX (PIX is not state of art, of course) and some others... I begin to think about checkpoint as about one more _brand bubble_. At least, I always advice _against_ it. PS. Security for dummies... interesting idea. Unfortunately, this book should start with _100% secure computer = dead computer_ -:) Why not? People really need such book! Of course 'back in days' when Firewall-1 started and [EMAIL PROTECTED] was *the* network security ML, PIX was an utter pile of poo and F-1 was very nice thankyou. Now PIX is quite good, Is it still very counter intuitive to set up a PIX to _not_ do the eevul NAT? Is the PIX no longer PeeCee hardware underneath (I know they got rid of the HDD) so not as to bring NOs down to the level of the great unwashed throngs of desktop users? and Firewall-1 has become the Microsoft of firewalls - ie everywhere and not particularly well administratored. Interesting how things change isn't it? At least Checkpoint had the sense to kill the FWZ VPN protocol early and go with IPsec. More than I can say for M$. Not that IPsec interoperability is fully realized. Checkpoint has its own proprietary icky tricks to try to sneak IPsec through NAT just like every other commercial vendor. But Checkpoint admins are worst part, I check the box to use IKE VPN but someone said that uses the ESP service. Which port number is that? I read port 50 somewhere, but should I make it a TCP or UDP service? The Checkpoint feature/bug that frustrates me is at the GUI level there is no association between a rule and an interface. To cover up this problem, there is the automatic anti-spoofing feature which is a bitch, if not impossible, to properly configure for a complicated topology. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1
Rubens Kuhl Jr. wrote: Checkpoint Firewall-1 HTTP Parsing Format String Vulnerabilities Vendor Notification Schedule: Vendor notified - 2/2/2004 Checkpoint patch developed and made available - 2/4/2004 ISS X-Force Advisory released - 2/4/2004 Checkpoint VPN-1/SecureClient ISAKMP Buffer Overflow Vendor Notification Schedule: Vendor notified - 2/2/2004 Checkpoint patch developed and made available - 2/4/2004 ISS X-Force Advisory released - 2/4/2004 Isn't it curious that two unrelated issues have been reported to CheckPoint at the same day and the patches came out on the same day ? Am I too paranoid, or it seems that CheckPoint had previous knowledge of the bugs and they agreed with ISS which date would be stated as notification to CP to make it appears that a quick response (two days) has been achieved on those issues ? Uh... yeah, that's how these things are _supposed_ to work. Did you read the ISS advisory? Checkpoint has released an update to address this issue. The update is available at the following address: http://www.checkpoint.com/techsupport/alerts/index.html Vendor Notification Schedule: Vendor notified 2/2/2004 Checkpoint patch developed and made available 2/4/2004 ISS X-Force Advisory released 2/4/2004 ISS X-Force published this Security Advisory in coordination with the affected vendor in accordance to our published Vulnerability Disclosure Guidelines, available at the following address: http://documents.iss.net/literature/vulnerability_guidelines.pdf - Original Message - From: Ingevaldson, Dan (ISS Atlanta) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:32 AM Subject: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1 Nanog- ISS X-Force release two X-Force Security Advisories this evening detailing high-risk issues in Checkpoint Firewall-1 and VPN-1. Please refer to the following URLs for more information: http://xforce.iss.net/xforce/alerts/id/162 http://xforce.iss.net/xforce/alerts/id/163 -- Daniel Ingevaldson Director, X-Force RD [EMAIL PROTECTED] 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: sniffer/promisc detector
Alexei Roudnev wrote: Please, do it: time nmap -p 0-65535 $target You will be surprised (and nmap will not report applications; to test a response, multiply time at 5 ). Yes. It will, http://www.insecure.org/nmap/versionscan.html -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Upcoming change to SOA values in .com and .net zones
Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. The current serial number format is MMDDNN. (The zones are generated twice per day, so NN is usually either 00 or 01.) The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1 January 1970.) For example, a zone published on 9 February 2004 might have serial number 1076370400. The .com and .net zones will still be generated twice per day, but this serial number format change is in preparation for potentially more frequent updates to these zones. Agghh! The y2038 bug! -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Trace and Ping with Record Option on Cisco Routers
[EMAIL PROTECTED] wrote: Hey, Group. In my production network, I'm trying to do some extended traces and pings with the record option turned on to see what route my packets take going and returning. It's not working. If I do the extended traceroute or ping without the record option, it works fine. There is a firewall (PIX) a few hops in front of the destination I'm trying to record the route for. What part of ICMP is this that needs to be opened on the firewall to allow this to come back? First time I'm coming across this. It's not ICMP. It's the IP Options. Most firewalls will drop any packet with an IP Options. Many firewalls will not let you turn this off. I do not know how to allow IP Options through a PIX, but I know how to do it in Cisco IOS. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: AOL rejecting mail from IP's w/o reverse DNS ?
Adam McKenna wrote: On Wed, Dec 03, 2003 at 09:53:37AM -0800, Adam McKenna wrote: On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote: How can delegating in-addr.arpa on a per-ip basis be any different or worse than delegating it using an rfc2317 scheme? consider the label of the ns rr to delegate only 1.2.3.42 Do you mean ns.42.3.2.1.in-addr.arpa? I still don't see what's wrong with the following, or how it leads to cache poisoning or leaky name space. 42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa. ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86 Eight hours later, and I'm still waiting for a reply on this. Were the original attacks by Pete Ehlke warranted, or would he care to retract his statements? $ dig 3.2.1.in-addr.arpa soa $ dig 42.3.2.1.in-addr.arpa soa -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: MTU path discovery and IPSec
Joe Maimon wrote: Tony Rall wrote: On Wednesday, 2003-12-03 at 09:38 PST, David Sinn [EMAIL PROTECTED] wrote: snipped (And note that frag 1 often is not the first fragment to arrive at downstream nodes. In my example in (1), frequently frag 2 will reach places before frag 1 does (if any router along the path reorders its transmit queue based on packet size).) I agree with all I have snipped. I was wondering would it not be wiser for fraggers to frag in half instead of just the overflow? For instance, suppose router has to fragment 1500 byte packet to go over 1476 GRE. Instead of having a big packet/little fragment why not just divide in half? This would give them more equal buffer treatment, but an even bigger potential win is to avoid perhaps a second (maybe ipsec?) fragmenting later on down the pipe. Once you are going to do it, do it right. It is not as if your decreasing header overhead by producing small fragment packets. And I am assuming the whole packet is already in buffer when it comes time to fragment it. Programmers are lazy. Excerise for the reader: Devise an algorthm that will take an arbitrarily sized packet 20-65535 octets and an arbitrarily sized MTU, 576 octets, and split the packet into the minimum number of n fragments where each fragment is (1) less than the MTU, (2) no two fragments differ by more than 8 octets, and the fragments obey the IP fragmentation rules, (3) data payload must end on an 8-octet boundary for all but the last fragment and (4) each fragment has an exact copy of the original header except for differences in the fragmentation fields and checksum. Compare to the algorithm of cutting the data in to m (mtu - ip_hl)- chunks and putting the leftovers into the final fragment. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Router with 2 (or more) interfaces in same network
Leo Bicknell wrote: In a message written on Tue, Nov 11, 2003 at 08:35:34AM +, Sugar, Sylvia wrote: I am curious to know if its possible to have a router with its two interfaces, say configured as, 1.1.1.1/16 and 1.1.1.2/16. Theoretically, i see nothing which can stop a router from doing this. Cisco's don't let you do this. I have always considered that broken, although I'm sure Cisco thinks it's a feature. Other routers (of note FreeBSD boxes) do this just fine. Errr, no. FreeBSD won't let you do this. # ifconfig fxp0 inet 10.0.0.1 # ifconfig ep0 inet 10.0.0.2 ifconfig: ioctl (SIOCAIFADDR): File exists The error is a round-about way for the system to tell you, hey, genius, I've already got a route for that network. You _used_ to be able to do this (oh, over two years ago?). The address was assigned to the interface, and the error from trying to add a duplicate route was simply ignored, no route got added anywhere. You can figure out when the change was made by examining the code or by seeing when the maillists started to get flooded by people who could no longer do, # ifconfig if0 inet 10.0.0.1 # ifconfig if0 alias 10.0.0.2 When they meant, # ifconfig if0 inet 10.0.0.1 # ifconfig if0 alias 10.0.0.2 netmask 0x But to reiterate the problem here, it's not really assigning addresses to interfaces, but trying to assign a route to the same network to different places. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: [arin-announce] IPv4 Address Space (fwd)
Owen DeLong wrote: It's much the same problem as FTP. The reason FTP doesn't BORK is because most NAT gateways understand about the need to proxy FTP and because PASSIVE mode FTP doesn't have the same call-setup problems. Passive mode has the same problems that PORT FTP does. It just pushes the problems to the server end. If you put a FTP server behind a NATed address, you'll need to proxy PASV (and also inverse to the client behind NAT, PORT needs none at the server end). -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
Jack Bates wrote: David Raistrick wrote: You seem to be arguing that NAT is the only way to prevent inbound access. While it's true that most commercial IPv4 firewalls bundle NAT with packet filtering, the NAT is not required..and less-so with IPv6. I think the point that was being made was that NAT allows the filtering of the box to be more idiot proof. Firewall rules tend to be complex, which is why mistakes *do* get made and systems still get compromised. NAT interfaces and setups tend to be more simplistic, and the IP addresses of the device won't route publicly through the firewall or any unknown alternate routes. NAT for security is a bogus argument. NAT provides you nothing that a simple stateful firewall provides[0]. The only reason a firewall is less idiot proof, is because NAT has such limited capabilities. People may do more with a firewall simply because they can. If you want complex rules, look at what happens to a NAT set up when you want to set up a few static mappings. That's asking for trouble. For a firewall to hobble the hosts behind it like NAT does takes only a few simple rules. NAT also takes considerably more resources than a stateful firewall. [0] The only bonus in NAT is for the truly paranoid who want to hide their network topology. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
Jeff Wasilko wrote: What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). And none of ATT's legitimate business partners, clients, and customers have dynamic IP addresses? None of them go home and relay through their home ISP? Or use YourFreeFlyByNightWebMailPopUpAdSite.com when off site? I mean dealing with spam and email borne worms costs money, but I cannot imagine how much $$$ in administrative overhead this policy will cost. This is going to burn many man-hours to build and then to maintain forever and ever and ever. Any ATTers on this list know the inside story? And I would think something like this will show up in the trade rags if not the techology section of mainstream media outlets. Anyone seen anything (or should I wait for it to hit /.)? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Fw: Re: Block all servers?
Chris Brenton wrote: [snip] True this only works for one to one NAT. Many to one NAT will still break IPSec, even if ESP is used alone. This is a functionality issue however (IPSec using a fixed source port of 500), rather than a preventing packet modification to thwart man-in-the-middle attacks thing. IPsec does not use port 500. IKE uses port 500/udp. IKE is an additional protocol that is widely used to establish SAs and provide keying materials for IPsec, but it is not required for a compliant IPsec implementation. In addition, most IKE implementations do not care whether the source port on a IKE packet is 500/udp or not. As I explained previously, ESP alone is un-NAT able in the general case due to the fact that it is a peer-to-peer protocol, not client-to- server, and the SPIs in either direction are unrelated. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Block all servers?
Stefan Mink wrote: On Sat, Oct 11, 2003 at 08:28:11AM -0700, ken emery wrote: I use IPSEC and it works fine behind NAT. Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance. why not? We use it here, works fine (with certificates for auth). OK, let's do this one more time. Many-to-one NAT of a many-to-one ESP VPN does not work. (Period) Why? There is no way for the NAT device to map the ESP packets to the nodes it hides. You say, The SPI field is perfect for maintaining a translation table! It would be accept for one very big problem. IPsec is a peer-to-peer protocol. Either side may renegotiate the SAs at any time. While using IKE[0], the SPI passes the NAT device in the _encrypted_ payloads. The NAT device never sees the SPI until the ESP starts flowing. Also, keep in mind the SPI is _not_ symmetric. So, now we have two machines behind a NAT device, and both want to have an ESP VPN to the same machine. What does the NAT device do when it receives an ESP packet from the exterior end of the ESP VPN tunnel? How does it decide which of the internal ends to send it to? The SPI has nothing to do with the outgoing SPIs (if it even has seen any outgoing ESP yet). It cannot pull the SPI out of the IKE. You can try timing, if it's a new SPI, try sending it to the last one that had a IKE conversation, but that is a guess, what happens if two happen to negotiate at once? And if you guess wrong, things do not fail and recover for the VPN players. So, you cannot NAT ESP in the general case. Thus we have all of the rather grotesque kludges of wrapping the ESP in another transport layer of UDP or TCP so that the NAT devices have some port numbers to play with. If your IPsec VPN works through NAT, the NATer is making some assumptions (usually it only will support a single IPsec end point behind it which solves the who do I send the ESP to problem) or your VPN software has a Draft or vendor kludge to wrap the IPsec in something more NAT friendly. Note again that NAT above implies many-to-one NAT. This problem disappears in a one-to-one NAT configuration where only authentication and integrity issues, which can be dealt with within IPsec, come into play. If someone has figured out a way around this, I would love to hear about it. [0] The fact you don't need to use IKE to set up SAs makes the problem even more intractable. A NAT device would have to know of every possible way to configure SPIs. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Why not UUNet too? (was Re: first Yahoo, now RoadRunner?)
Since the topic is mysterious rejections from MTAs, I have one from UUNet. One of our business partners has UUNet for an ISP and is using UUNet for a tertiary MTA. Occasionally, mail ends up going to that MTA (quite often actually, their primary gets unresponsive from time to time and I've _never_ actually been able to reach the secondary) and gets bounced at the MAIL FROM:, $ telnet relay.eu.mail.uu.net 25 Trying 199.171.54.122... telnet: connect to address 199.171.54.122: Connection refused Trying 199.171.54.202... telnet: connect to address 199.171.54.202: Operation timed out Trying 199.171.54.203... telnet: connect to address 199.171.54.203: Operation timed out Trying 199.171.54.245... Connected to relay.eu.mail.uu.net. Escape character is '^]'. 220 mr0.ash.ops.us.uu.net ESMTP Please see http://www.worldcom.com/global/terms/a_u_p/ for Acceptable Use Policy HELO gibraltar.globalstar.com 250 mr0.ash.ops.us.uu.net Hello gibraltar.globalstar.com [207.88.248.142], pleased to meet you MAIL FROM:[EMAIL PROTECTED] 550 no QUIT 221 mr0.ash.ops.us.uu.net closing connection Connection closed by foreign host. Quite a helpful error message there, 550 no. (That's not even to mention the addresses that time out or aren't listening on 25/tcp. I see seven A records for that domain name.) Has anyone out there an idea of why UUNet does not like our domain? I would _guess_ the problem might be some weird spam filter, but AFAIK, our domain and IP space is damn clean WRT spam. The AUP link is not any help. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
