Re: update
On 9/29/2014 00:32, Pete Carah wrote: For that matter, has the*specification* of tcp/ip been proven to be correct in any complete way? I find that question in this forum really confusing. I thought all of the RFC-descriptions of protocols were taken to be statements that if you do it this way, we think we can inter-operate but at no time to be taken as right or wrong. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: update
for two asynchronous, otherwise unconnected systems, using TCP/IP there is a state transition sequence which can be shown to work if you stick to it. There are also (I believe) corner cases when you send unexpected sequences, and some of them have known behaviours in that sense, the question: does the RFC adequately document the state transition sequences which are understood to be valid states and transitions is a well formed question. Robin Milner, in his calculus of communicating systems tried to codify a formal mathematics of async communicating systems. I don't know if anyone either extended the idea(s) or applied it to TCP/IP. Certainly I believe there are formally verified protocols. Thats a space Erlang occupies isn't it? On Mon, Sep 29, 2014 at 4:14 PM, Larry Sheldon larryshel...@cox.net wrote: On 9/29/2014 00:32, Pete Carah wrote: For that matter, has the*specification* of tcp/ip been proven to be correct in any complete way? I find that question in this forum really confusing. I thought all of the RFC-descriptions of protocols were taken to be statements that if you do it this way, we think we can inter-operate but at no time to be taken as right or wrong. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: update
On 09/28/2014 11:14 PM, Larry Sheldon wrote: I thought all of the RFC-descriptions of protocols were taken to be statements that if you do it this way, we think we can inter-operate but at no time to be taken as right or wrong. Correct. That gave birth to the original interop conferences, informal gatherings of people to test out their implementations of the RFCs that eventually grew into the full-blown conference we know today. Frankly, this is where Mr. Stevens was instrumental in making the Internet what it is today.
Perfsonar and shellshock
Please guys, If everybody could patch their perfsonar boxen against shellshock LIKE RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines out of their misery with a shotgun, that would be great. Thank you, -- Leif Nixon - Security officer National Supercomputer Centre - Swedish National Infrastructure for Computing Nordic Data Grid Facility - European Grid Infrastructure pgp5Crf_EJCsF.pgp Description: PGP signature
Re: Perfsonar and shellshock
On 09/29/2014 05:23 AM, Leif Nixon wrote: Please guys, If everybody could patch their perfsonar boxen against shellshock LIKE RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines out of their misery with a shotgun, that would be great. Thank you, From the perfSonar site: perfSONAR is recommending that all users run yum update to download the latest packages from the CentOS repositories This will need to be done again in a couple of weeks, when a better patch becomes available from the FSF or wherever. By the way, the history of the development of bash is mildly interesting. http://www.wired.com/2014/09/shellshocked-bash/
Re: Perfsonar and shellshock
On Sep 29, 2014, at 8:55 AM, Stephen Satchell l...@satchell.net wrote: On 09/29/2014 05:23 AM, Leif Nixon wrote: Please guys, If everybody could patch their perfsonar boxen against shellshock LIKE RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines out of their misery with a shotgun, that would be great. Thank you, From the perfSonar site: perfSONAR is recommending that all users run yum update to download the latest packages from the CentOS repositories This will need to be done again in a couple of weeks, when a better patch becomes available from the FSF or wherever. By the way, the history of the development of bash is mildly interesting. http://www.wired.com/2014/09/shellshocked-bash/ Proper operation of a host requires automated updating (yum-updatesd, yum-cron) to pick up these packages. Those who are paranoid or afraid of damage from automatic updates should exclude packages that require specific versions. - Jared
Re: GMail contact - misroute / security issue
On Sun, 28 Sep 2014 20:57:41 -0700, Mike Lyon said: I have the same issue and have had it for quite a while. I've met some great new friends because of it as well! Odd. Never seen it happen to me. I wonder why. pgpAO5hwZDb7r.pgp Description: PGP signature
Re: update
On Mon, 29 Sep 2014 00:32:49 -0500, Pete Carah said: The halting problem comes up in connection with _data_ handling in any computer with even a language interpreter (e.g. is browser-based javascript complete enough for the halting problem to apply to it? The halting problem applies to *any* language/system that's Turing-complete. And the bar is *really* low for that. If you have an increment or decrement operator, a branch operator, and a test-and-skip-on-zero, you're Turing-complete. In fact, you can design a CPU with *one* opcode that's Turing complete. Part of the fun is that since there's only one opcode, you can omit it, and then instructions consist only of operand addresses. Then remember that von Neumann architectures allow self-modifying code http://en.wikipedia.org/wiki/One_instruction_set_computer pgpJjS1lADyIf.pgp Description: PGP signature
Re: GMail contact - misroute / security issue
On Sun, Sep 28, 2014 at 10:42:56PM -0500, Grant Taylor wrote: Specifically she is receiving emails for first namemiddle initiallast name@gmail.com (no dots) when her email address is really same first name.same middle initial.same last name@gmail.com (dots). I don't know if this is a feature or a bug, but either way, it's disquieting my wife. (Unhappy wife = unhappy life.) Have your wife log in while omitting the dots, using e.g. janeqpublic instead of jane.q.public as the username. She'll see there's only one account, and it's her's, and that someone just typed the wrong address. Most likely reason: gmail is so common that someone mistypes johnsm...@example.com as johnsm...@gmail.com, not paying attention to what they're doing. It happens. Nicolai
Re: Match.com contact - Previously: GMail contact - misroute / security issue
You sure you wife did not sign up or Match.com and using this as a cover story? On Sep 29, 2014 6:17 AM, John Fraizer j...@op-sec.us wrote: Set up a filter in the GMAIL console to match (pun intended) the Match emails and filter them into their own label. Then, hide that label. Don't delete them though. You might have a gold mine there. Think of the comedic relief you could provide others with www.My-wife-keeps-getting-sent-pics-of-some-guys-tiny.org You could post the emails, the profile names of the pervs, etc. Sort of like a 20/20 To catch a... only instead of predator, it would be perv. -- John Fraizer ΥΣΜΧ
Re: GMail contact - misroute / security issue
On Mon, Sep 29, 2014 at 10:06 AM, Nicolai nicolai-na...@chocolatine.org wrote: Have your wife log in while omitting the dots, using e.g. janeqpublic instead of jane.q.public as the username. She'll see there's only one account, and it's her's, and that someone just typed the wrong address. This is what I was going to suggest. Have your wife login to the match.com site (using the forgot password feature), and then just deactivate / delete the account. Or as other have pointed out, gmail filters with hidden labels or direct to spam also works great.
Re: update
Heh….this reminded me of a project I had to do circa 1991/2 when getting my Master's in EE where we used this book and mechanism to 'validate' TCP. http://spinroot.com/gerard/popd.html Although as a student homework assignment I wouldn't say what we did was in any way rigorous but certainly had me learning some interesting concepts (and as I was actually creating a backbone with routers at the time it was kind of fun to see where academics and operations went a bit orthogonal) :) And no, I can't for the life of me remember that far back except to remember that I was the only one in class with practical knowledge. And then of course there's the 'how did one actually implement the protocols' and hence the Interop conferences as someone already mentioned. Even a formal proof of 'protocol validation and correctness' doesn't alter the implementation creativities… - merike On Sep 28, 2014, at 11:41 PM, George Michaelson g...@algebras.org wrote: for two asynchronous, otherwise unconnected systems, using TCP/IP there is a state transition sequence which can be shown to work if you stick to it. There are also (I believe) corner cases when you send unexpected sequences, and some of them have known behaviours in that sense, the question: does the RFC adequately document the state transition sequences which are understood to be valid states and transitions is a well formed question. Robin Milner, in his calculus of communicating systems tried to codify a formal mathematics of async communicating systems. I don't know if anyone either extended the idea(s) or applied it to TCP/IP. Certainly I believe there are formally verified protocols. Thats a space Erlang occupies isn't it? On Mon, Sep 29, 2014 at 4:14 PM, Larry Sheldon larryshel...@cox.net wrote: On 9/29/2014 00:32, Pete Carah wrote: For that matter, has the*specification* of tcp/ip been proven to be correct in any complete way? I find that question in this forum really confusing. I thought all of the RFC-descriptions of protocols were taken to be statements that if you do it this way, we think we can inter-operate but at no time to be taken as right or wrong. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes signature.asc Description: Message signed with OpenPGP using GPGMail
Re: update
On September 28, 2014 at 13:22 j...@baylink.com (Jay Ashworth) wrote: The Internet is the only endeavour of man in which a single-character typographical error in a file on a computer on the other side of the planet *which you do not even know exists* can take your entire business off line for the better part of a day. -- Someone, in the wake of the (I think) Turkish YouTube BGP hijacking; damn if I remember who. I might be embellishing. :-) Oh I dunno. I know someone who accidentally brought down the entire Manhattan phone system (monopoly, pre-mobile days) installing a carefully tested patch with a hot failover running (oh well, the best laid schemes o' Mice an' Men, Gang aft agley.) Sure, that was just Manhattan, and of course everyone on the other side of those connections. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: GMail contact - misroute / security issue
Gmail will strip out periods. So it's not like there was some OTHER email address that your wife is suddenly getting. There is only her address. Dots or No Dots. Your wife's email address IS THE SAME as the dotless-version. On Sun, Sep 28, 2014 at 8:42 PM, Grant Taylor gtay...@tnetconsulting.net wrote: Hi, I'm looking for a GMail contact. My wife is receiving someone else's emails. Specifically she is receiving emails for first namemiddle initiallast name@gmail.com (no dots) when her email address is really same first name.same middle initial.same last name@gmail.com (dots). I don't know if this is a feature or a bug, but either way, it's disquieting my wife. (Unhappy wife = unhappy life.) I view this as both non-RFC compliant behavior -and- a potential security risk. (Registering a GMail account as someonefamous@gmail.com (no dot) to capture email for someone.famous@gmail.com (dot) emails.) Please reply or email me directly at gtaylor (at) tnetconsulting (dot) net for additional details. Thank you and have a nice day. -- Grant. . . . unix || die P.S. Thus far messages to postmas...@gmail.com and ab...@gmail.com have gone unanswered. -- James Welcher
Re: Match.com contact - Previously: GMail contact - misroute / security issue
Does anyone have any Match.com contacts? I'll try going that route to get the messages stopped. (Including emailing postmaster@ and abuse@ to see if they can help.) I've contacted Grant offlist to provide him with a contact. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Accreditation Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose https://www.linkedin.com/in/annemitchell 303-731-2121 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell
Re: update
On Sun, 28 Sep 2014 13:22:57 -0400, Jay Ashworth said: The Internet is the only endeavour of man in which a single-character typographical error in a file on a computer on the other side of the planet *which you do not even know exists* can take your entire business off line for the better part of a day. -- Someone, in the wake of the (I think) Turkish YouTube BGP hijacking; damn if I remember who. I might be embellishing. :-) A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable. -- Leslie Lamport, 1987. http://research.microsoft.com/en-us/um/people/lamport/pubs/distributed-system.txt pgpXYKRqYy3sY.pgp Description: PGP signature
Re: Match.com contact - Previously: GMail contact - misroute / security issue
- Original Message - From: Grant Taylor gtay...@tnetconsulting.net *sigh* So this is a non-RFC compliant feature. Nope. The LHS of an email address *is system defined*; no one outside of the destination mailserver is permitted to make any assumptions about it. RFC5322 3.4.1: The local-part portion is a domain-dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox. Note that using a real name as an email address is Not The Best Idea: http://www.sendmail.com/sm/open_source/support/support_faq/faq_ver_8_issues/#3.5 Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
YouTube CDN down?
Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from multiple ASNs in multiple locations in the United States. Tried multiple operating systems and browsers...all have the same issue. (The very few that do play stall out, even though they're buffered.) Is this just me, or is there an issue afoot?
Re: YouTube CDN down?
On 09/29/2014 05:12 PM, Blair Trosper wrote: Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from multiple ASNs in multiple locations in the United States. Tried multiple operating systems and browsers...all have the same issue. (The very few that do play stall out, even though they're buffered.) Is this just me, or is there an issue afoot? Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint). -- Brandon Martin
Re: YouTube CDN down?
Watching in dev tools, the CDN is returning the dreaded HTTP header 204 (No Content), even though the entire video is buffering. This reminds me of an outage a while back that only affected IPv6. I've confirmed with other users, and YouTube is dead to us from these networks: - AS22645 (Texas Gigapop) - v4/v6 - AS19108 (Suddenlink) - v4 - AS40285 (Northland Cable) - v4/v6 - AS40244 (TurnKey) - v4/v6 It does seem to be regional. People in SC/NC who are presumably hitting the Charleston DC are unaffected. On Mon, Sep 29, 2014 at 4:16 PM, Brandon Martin lists.na...@monmotha.net wrote: On 09/29/2014 05:12 PM, Blair Trosper wrote: Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from multiple ASNs in multiple locations in the United States. Tried multiple operating systems and browsers...all have the same issue. (The very few that do play stall out, even though they're buffered.) Is this just me, or is there an issue afoot? Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint). -- Brandon Martin
Re: GMail contact - misroute / security issue
On 09/29/14 10:06, Nicolai wrote:
Most likely reason: gmail is so common that someone mistypes
johnsm...@example.com as johnsm...@gmail.com, not paying attention to
what they're doing. It happens.
More likely, I think, is that newbies think that email addresses already
exist for everyone on the planet at firstl...@gmail.com, and they just
give that when asked (maybe they think it's throwaway and never actually
expect to get any email there). I'm in the same boat. It doesn't
bother me all that much because gmail is not my primary mail service. I
use it to store big stuff that's clogging the mail service I do pay
for. In fact, it can be entertaining, as I get usernames and passwords
for sites that this guy signed up for. He's also a poker player and has
recently tried to enroll at an art college. The latter I could reply to
and explain that their prospective student is an idiot and should not be
accepted, but that's what will happen anyway if I don't say anything.
--
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and unused storage capacity.
Delete! Delete! OK! -Dr. Bronner on disk space management
Card sorting, Joel. -me, re Solitaire
Re: YouTube CDN down?
yt is working for me: 2607:f2f8:a2c4:/48 / 206.125.168.64/28 On 09/30/14 00:22, Blair Trosper wrote: Watching in dev tools, the CDN is returning the dreaded HTTP header 204 (No Content), even though the entire video is buffering. This reminds me of an outage a while back that only affected IPv6. I've confirmed with other users, and YouTube is dead to us from these networks: - AS22645 (Texas Gigapop) - v4/v6 - AS19108 (Suddenlink) - v4 - AS40285 (Northland Cable) - v4/v6 - AS40244 (TurnKey) - v4/v6 It does seem to be regional. People in SC/NC who are presumably hitting the Charleston DC are unaffected. On Mon, Sep 29, 2014 at 4:16 PM, Brandon Martin lists.na...@monmotha.net wrote: On 09/29/2014 05:12 PM, Blair Trosper wrote: Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from multiple ASNs in multiple locations in the United States. Tried multiple operating systems and browsers...all have the same issue. (The very few that do play stall out, even though they're buffered.) Is this just me, or is there an issue afoot? Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint). -- Brandon Martin
Internet in Venezuela
I have lots of questions, feel free to contact me privately if you have some time or interest in answering some of them. -Paige paigead...@gmail.com PGP: 0x0d5d2688 (keys.gnupg.net), also attached. 0d5d2688.pub.asc Description: application/pgp-encrypted
Re: update
On 09/29/2014 01:14 AM, Larry Sheldon wrote: On 9/29/2014 00:32, Pete Carah wrote: For that matter, has the*specification* of tcp/ip been proven to be correct in any complete way? I find that question in this forum really confusing. I was adding it to Valdis's statement about proven correctness of the TCP/IP stack. It is only possible to prove correctness of software in relation to a (assumed) correct (and complete) specification. Correct software relative to a spec that doesn't relate to the real world may be considered correct but will still fail in application. Many of the famous failures of military systems (and many more from commercial systems) come from bad (or missing) assumptions in the spec, (and many also from bad implementation, to be sure...) The thread in question is more about security than interoperation, and real-world effects of both compliant and non-compliant uses of the net. The real point is that many of the features included in tcp/ip to handle random occurrences make purposeful interference *worse*. In a world with purposeful attacks, those specifications have to be amended; in that sense they are not correct. I thought all of the RFC-descriptions of protocols were taken to be statements that if you do it this way, we think we can inter-operate but at no time to be taken as right or wrong. The use of modals (MUST, MUST NOT, SHOULD) in the specification implies a sense of correctness. Indeed that is mostly there to guarantee interoperation. In the early days (pre-mid-80's) the security aspects of the protocols was minimal; it was assumed that people would pay attention to the specs. Now we have players that (use spam for an example, again) (mostly) completely comply to the technical specifications but manage to bring the net to its knees anyhow, and also players that test what (mostly) minor violations to the spec will do to the rest of the net. (try to defend against a joe-job using stock qmail, for example; that system is completely compliant to the (older) RFCs and cannot handle significant amounts of forged mail, mostly due to its completely compliant handling of bounces. And some of the MUST statements in earlier application protocols (821/822, for example) have had to be turned off in order to defend against such purposeful actions (e.g. bounce all messages that fail delivery; doing so makes the spam problem MUCH worse.) The protocols have to be adapted to handle attacks, there is no alternative. In that way, there is (in some sense) correctness or not. At least the RFC system does allow for fairly easy (but not too easy) modification with experience. -- Pete
IPv6 Extension Headers in the Real World
Folks, Earlier in September we published a revision of our I-D IPv6 Extension Headers in the Real World (https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world). At this point in time, we're interested in knowing whether our I-D is of value for the IPv6 ops community, such that we can decide whether to continue working/improving it. Additionally, if there's anything you think we've missed in the document, we'd like to hear from you. Overall, our I-D is meant to provide a reality-check with respect to the issues surrounding IPv6 Extension Headers and their use on the public Internet. More specifically, its goals are: 1) Provide data regarding support of IPv6 EHs in the real world. This is interesting data to refer people to (e.g., folks developing protocols) regarding the extent to which IPv6 EHs are usable on the public Internet (at least with web, mail, and name servers). 2) Summarize the issues associated with IPv6 EHs (performance, security, etc.) This is of use for folks concerned with the issues surrounding IPv6 EHs, and covers practical issues. 3) Summarizes the implications of the aforementioned filtering. For example, if you're designing a protocol that is meant to work on the public Internet, you may want to provide some fall-back mechanism that does not employ IPv6 EHs. Yet another of the implications is the security issue that has been discussed on-list: if e.g. IPv6 fragments are dropped and you can be tricked into generating them, you may be subject to a DoS attack. 4) Flag possible further work Here we try to flag areas where the further work may be needed, such as adding fall-back mechanisms to some existing protocols, or avoiding the use of IPv6 EHs where possible. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
