Slashdot Mirror

let's start work on IPv7+!

IPv7 was officially deprecated in 2012. In practice IPv7 was obsolete before IPv6 was finalized.

let's start work on IPv7+!

IPv7 was officially deprecated in 2012. In practice IPv7 was obsolete before IPv6 was finalized.

I'm shocked they didn't go ahead and add a .local TLD just to really fuck it up.

Considering that RFC 6762 (Multicast DNS) has taken over .local already, making it a global TLD would be beyond stupid. RFC6762 could have used .mdns with hardly a chance of collision. The .local TLD was already in use on private networks, but I guess everybody wants a nice name.

ICANN should just reserve a TLD or two for private networks similar to how some IP ranges were reserved in RFC1918. For example:
.private (broad scope - for internal/private use)
.here (narrower scope - limited to a particular location e.g. different starbucks outlets could be using whats.here and at each of those outlets it resolves to that specific outlet's stuff )
Feel free to think of other TLDs for private but different usage.

I actually proposed .here many years ago: http://tools.ietf.org/html/dra...

But seems they were too busy approving "Yet More Dot Coms" (e.g. .biz, .info etc).

That's one of the reasons I have a low opinion of ICANN. Anyone in the field could see this problem years ago, but they have done little to help and maybe even made things worse.

Thank you, ICANN, for returning to us a problem resolved in 1993.

See RFC-1535

Ehud

Actually, email is intended to be a file transfer method. It wasn't originally, but now it is. That's what the little paper clip is for. It isn't intended for large file transfers, but that is an ever changing definition as bandwidth becomes more cheap, fast, and ubiquitous. What was once considered a "large file", say 1 or 2 megabytes, is now considered not very large at all. E-Mail will still be here in 2055 if we are, but 25 GB will be a small file for the purposes of this discussion.

/60 is actually pretty small; RFC 6177 basically says you should be getting /56 or bigger.

Though it's certainly better than the one /64 that far too many ISPs are doing (or the "no routed space whatsoever, on-link only" that way too many datacenters do...).

No one router has a "full table" of all the routes. The routing protocols and the engineers work to make sure the tables are as close to lean as possible.

Just about all ISPs and backbone carriers carry full tables and many large organisations do as well for multihoming purposes. Global BGP tables are currently around 513,191 routes and this is what facilitated the issues mentioned in the article. One ISP made a mistake and started advertising more specific prefixes for blocks that were already summarized and this pushed the number of global routes beyond the limits of some older hardware. I would suggest reading about the Default Free Zone.

Your offered solution isn't necessary.

LISP is not something that I invented, it's something the IETF is working on to solve a perceived problem.(RFC6830) Some IETF contributors came to the conclusion the Internet routing system was not scaling well with the "explosive growth of new sites" and multihoming that many organisations now do. Problem Statement From all indications, the growth of the Internet does not appear to be slowing down, but accelerating. It seems like a prudent choice to evaluate different ideas as possible solutions to the issue of Internet scalability.

Your bitcoinesque solution for IPv6 allocation would make things worse.

It seemed like a technical solution to avoid the politics of Internet governance. I admit it wasn't well thought out, however I am curious how it would make things worse by allowing a small block of IPv6 addresses to be allocated in a decentralized way and adding cryptographic integrity along the way.

Plus, networks transit other networks all the time, meaning one network can advertise a prefix they don't own, legitimately.

I should have been more specific; I was suggesting originating advertisements would be signed as opposed to transient advertisements.

Routers that speak BGP are on the ISP and backbone level,

Medium to large organisations also use BGP to advertise their address space to their ISP(s).

and are physically secured.

Originating BGP route advertisement signing is not intended to supplant physical security measures.

Your home router doesn't speak BGP, and if it did, your ISP's router would ignore it.

None of this would really be necessary for a home user as their ISP would be doing all of this on their behalf.

To announce rogue routes, one needs to hack into the ISP and backbone peering routers -- which happened recently, but is rare.

To announce rogue routes, one only needs an ISP that doesn't filter incoming BGP advertisements properly. It seems apparent as the Internet grows there will be more and more BGP peerings and as a consequence of that not all of them will be competent or aboveboard with their implementations.

The Resource Public Key Infrastructure (RPKI) is a step in the right direction, however seems to be mainly for preventing mis-configurations from causing outages. Someone with malicious intent need only use AS path prepending to bypass this protection.

No one router has a "full table" of all the routes. The routing protocols and the engineers work to make sure the tables are as close to lean as possible.

Just about all ISPs and backbone carriers carry full tables and many large organisations do as well for multihoming purposes. Global BGP tables are currently around 513,191 routes and this is what facilitated the issues mentioned in the article. One ISP made a mistake and started advertising more specific prefixes for blocks that were already summarized and this pushed the number of global routes beyond the limits of some older hardware. I would suggest reading about the Default Free Zone.

Your offered solution isn't necessary.

LISP is not something that I invented, it's something the IETF is working on to solve a perceived problem.(RFC6830) Some IETF contributors came to the conclusion the Internet routing system was not scaling well with the "explosive growth of new sites" and multihoming that many organisations now do. Problem Statement From all indications, the growth of the Internet does not appear to be slowing down, but accelerating. It seems like a prudent choice to evaluate different ideas as possible solutions to the issue of Internet scalability.

Your bitcoinesque solution for IPv6 allocation would make things worse.

It seemed like a technical solution to avoid the politics of Internet governance. I admit it wasn't well thought out, however I am curious how it would make things worse by allowing a small block of IPv6 addresses to be allocated in a decentralized way and adding cryptographic integrity along the way.

Plus, networks transit other networks all the time, meaning one network can advertise a prefix they don't own, legitimately.

I should have been more specific; I was suggesting originating advertisements would be signed as opposed to transient advertisements.

Routers that speak BGP are on the ISP and backbone level,

Medium to large organisations also use BGP to advertise their address space to their ISP(s).

and are physically secured.

Originating BGP route advertisement signing is not intended to supplant physical security measures.

Your home router doesn't speak BGP, and if it did, your ISP's router would ignore it.

None of this would really be necessary for a home user as their ISP would be doing all of this on their behalf.

To announce rogue routes, one needs to hack into the ISP and backbone peering routers -- which happened recently, but is rare.

To announce rogue routes, one only needs an ISP that doesn't filter incoming BGP advertisements properly. It seems apparent as the Internet grows there will be more and more BGP peerings and as a consequence of that not all of them will be competent or aboveboard with their implementations.

The Resource Public Key Infrastructure (RPKI) is a step in the right direction, however seems to be mainly for preventing mis-configurations from causing outages. Someone with malicious intent need only use AS path prepending to bypass this protection.

You get end to end encryption with just PGP.

Nope. SMTP envelope sender & recipient plus all the headers are still in the clear if you skip TLS. Metadata...

Network stacks don’t have anything to do with PGP

Sure network stacks don’t do PGP. Not sure what that has to do with SMTP which is an application level protocol common on TCP/IP networks and only a tiny part of the entire stack.

SMTP servers currently tell each other about encoding capabilities they may support. The receiving server may tell the sender for instance that it supports 8BITMIME. A sending server which sees that capability may react by not base 64 encoding the message if it contains UTF-8 characters. The sending server makes a decision immediately before transmitting content (after connecting to the remote and saying "EHLO") on what encoding it should apply.

Adding some indication of PGP to the SMTP capabilities might trigger similar behavior. The sending server could encrypt using the recipient’s public key transparently without requiring any user intervention or access to any private key material. That change could be implemented with an RFC similar to RFC-6152 which covered 8BITMIME. An admittedly more in depth change might enhance SMTP to allow the server to provide a recipient’s key ID if available in response to the "RCPT TO” command.

It's not stupid website. It's just stupid 4 char tld that shouldn't exist according to the standards.

Please show me in RFC 1035 where you see this 3 letter limitation.

By the way, the ".arpa" pseudo-domain has always existed.

There are myriad of validators out there that will reject it

No, most validators correctly implement the standard, only a handfew are incorrect.

they worked well for decades.

Something on the web that worked well for decades has necessarily been enhanced at some point...

I would imagine that there they implemented RFC6532, which involves a lot more than changing a regular expression

So we get sometimes unreadable mails because the encoding of the content is unknown. Then some mails will be rejected because of an encoding problem in the address itself. At least in the first case the mail was received and we had enough time to fix the problem.

Both UUCP and TCP/IP had email (although the ip side lagged badly, mail was really invented at Bell,

No, it wasn't.

IP made very crude versions of this ad took forever to do it)

Inter-host email came out the same year that UNIX first existed, and wasn't invented at Bell Labs. It ran over NCP, because TCP/IP didn't even exist yet.

SMTP, which ran over TCP and NCP, was first specified in 1982, slightly after TCP was first specified.

Both UUCP and TCP/IP had email (although the ip side lagged badly, mail was really invented at Bell,

No, it wasn't.

IP made very crude versions of this ad took forever to do it)

Inter-host email came out the same year that UNIX first existed, and wasn't invented at Bell Labs. It ran over NCP, because TCP/IP didn't even exist yet.

SMTP, which ran over TCP and NCP, was first specified in 1982, slightly after TCP was first specified.

Now that Google has implemented 2012 i18n technology, maybe vaunted technology site Slashdot can catch up to 1998 and implement UTF-8 properly?

Nah.

Download checksum are usually one or more of MD5SUM, SHA1SUM and SHA256SUM.

A simple transposition of bytes will not generate identical hashes.

From RFC793:

The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.

The extremely weak checksum of the TCP header (or even IP header) will not detect byte transposition.

And no amount of checksumming will stop drive-by-downloads from browsers that still don't understand basic security. (Really, Javascript permissions should have been introduced in Netscape 2.0.)

They're making it up, of course, unless they're including the '<' character in the addr-spec, http://tools.ietf.org/html/rfc...

The ABNF in that section is so broken, though, I have no idea how anyone could hope to provide a compliant implementation.

I would imagine that there they implemented RFC6532, which involves a lot more than changing a regular expression

Portland had "agora" in 1985. PDxs and Teleport joined in 1987.

With all three of them routing packets between a host on the other end of a dialup SLIP connection (not PPP, the first RFCs for that came out in 1989) and the Internet? If not, they weren't ISPs, they were providers of other dialup services.

I don't know who was first but I was on Wetware Diversions, a dial-up ISP in San Francisco connected to the Internet in as early as 1987 and it was up before then ...

DNS wasn't even in use at the time

RFC 882 and RFC 883 were published as early as 1983, so I really doubt that DNS wasn't at use at all in 1987.

I recall as e-mail addresses still needed to use bangs ("!") for routing

That's a UUCP convention, not used on the real Internet. Perhaps the service that you used required bang paths and didn't use DNS, but DNS was most definitely in use by people connected to the Internet (as opposed to people connected to a dialup service that gatewayed email onto the Internet).

I did a quick search for "Wetware Diversions" and came up with this long list of ISPs going back as far as 1988:

http://www.phrack.org/issues/29/4.html

That says

07/89 415-753-5265^ wet San Francisco CA 3/12/24 24
386 SYS V.3. Wetware Diversions. $15 registration, $0.01/minute.
Public Access UNIX System: uucp, PicoSpan bbs, full Usenet News,
multiple lines, shell access. Newusers get initial credit!
contact:{ucsfcca|claris|hoptoad}!wet!cc (Christopher Cilley)

I see nothing about "Internet" there. I see "uucp", "bbs", "Usenet", and "shell access", all of which can be provided as dialup services, and none of which necessarily imply that they support something such as SLIP or PPP over dialup lines and route packets between the host on the other end of the dialup line and the Internet, that being what being an Internet Service Provider indicates that you do.

UUCP (including UUCP mail and USENET), BBS access, and dialup shell access were certainly very useful services at the time, but they aren't sufficient to make you an ISP.

If you're going to quibble that Barry wasn't the first dialup ISP - not the first provider of dialup UUCP or the first provider of dialup BBS access or the first provider of dialup shell services - then talk about earlier ISPs, not earlier providers of dialup UUCP or dialup BBS access or dialup shell services.

I don't know who was first but I was on Wetware Diversions, a dial-up ISP in San Francisco connected to the Internet in as early as 1987 and it was up before then ...

DNS wasn't even in use at the time

RFC 882 and RFC 883 were published as early as 1983, so I really doubt that DNS wasn't at use at all in 1987.

I recall as e-mail addresses still needed to use bangs ("!") for routing

That's a UUCP convention, not used on the real Internet. Perhaps the service that you used required bang paths and didn't use DNS, but DNS was most definitely in use by people connected to the Internet (as opposed to people connected to a dialup service that gatewayed email onto the Internet).

I did a quick search for "Wetware Diversions" and came up with this long list of ISPs going back as far as 1988:

http://www.phrack.org/issues/29/4.html

That says

07/89 415-753-5265^ wet San Francisco CA 3/12/24 24
386 SYS V.3. Wetware Diversions. $15 registration, $0.01/minute.
Public Access UNIX System: uucp, PicoSpan bbs, full Usenet News,
multiple lines, shell access. Newusers get initial credit!
contact:{ucsfcca|claris|hoptoad}!wet!cc (Christopher Cilley)

I see nothing about "Internet" there. I see "uucp", "bbs", "Usenet", and "shell access", all of which can be provided as dialup services, and none of which necessarily imply that they support something such as SLIP or PPP over dialup lines and route packets between the host on the other end of the dialup line and the Internet, that being what being an Internet Service Provider indicates that you do.

UUCP (including UUCP mail and USENET), BBS access, and dialup shell access were certainly very useful services at the time, but they aren't sufficient to make you an ISP.

If you're going to quibble that Barry wasn't the first dialup ISP - not the first provider of dialup UUCP or the first provider of dialup BBS access or the first provider of dialup shell services - then talk about earlier ISPs, not earlier providers of dialup UUCP or dialup BBS access or dialup shell services.

Yeah, not the first. There were multiple public ISPs in Portland in 1989. PDxs, agora, Teleport...

One is still around, nearly 30 years later - Raindrop Laboratories http://www.rdrop.com/ still has its "vintage" mid '90s web page, too. (It has been around since 1985.)

If you follow the "Alan Batie" link from RainDrop's home page, and then follow his "agora" link from "I work at Peak Internet, a local ISP in Corvallis, Oregon. I also run a small ISP in Portland, Oregon, called RainDrop Laboratories. It started in 1985 as a public access system called Agora, while I was working at Intel.", it speaks of agora's RainNet Internet access starting in 1990 - "Now that our subject had SVR4, with TCP/IP and all, and there being several other hacker sorts around town who'd been eyeing the Internet with envy for sometime, it was time to see if something could be done locally. RAINet was thus born in the fall of 1990, and its first connection was a 2400 bps SLIP link between agora and parsely (another local public access system, owned by Tod Oace at the time)."

(Remember, unless you actually Provide a Service that lets you send IP packets onto the Internet, you're not an Internet Service Provider. Dialup BBSes don't count, UUCP doesn't count, only SLIP/PPP/bridged Ethernet/PPPoEoAoDSL/PPPoAoDSL/DOCSIS/etc. so that you can splat out one of these things - or one of these things - onto the Internet counts.)

Yeah, not the first. There were multiple public ISPs in Portland in 1989. PDxs, agora, Teleport...

One is still around, nearly 30 years later - Raindrop Laboratories http://www.rdrop.com/ still has its "vintage" mid '90s web page, too. (It has been around since 1985.)

If you follow the "Alan Batie" link from RainDrop's home page, and then follow his "agora" link from "I work at Peak Internet, a local ISP in Corvallis, Oregon. I also run a small ISP in Portland, Oregon, called RainDrop Laboratories. It started in 1985 as a public access system called Agora, while I was working at Intel.", it speaks of agora's RainNet Internet access starting in 1990 - "Now that our subject had SVR4, with TCP/IP and all, and there being several other hacker sorts around town who'd been eyeing the Internet with envy for sometime, it was time to see if something could be done locally. RAINet was thus born in the fall of 1990, and its first connection was a 2400 bps SLIP link between agora and parsely (another local public access system, owned by Tod Oace at the time)."

(Remember, unless you actually Provide a Service that lets you send IP packets onto the Internet, you're not an Internet Service Provider. Dialup BBSes don't count, UUCP doesn't count, only SLIP/PPP/bridged Ethernet/PPPoEoAoDSL/PPPoAoDSL/DOCSIS/etc. so that you can splat out one of these things - or one of these things - onto the Internet counts.)

I wasn't aware car manufacturers had even implemented RFC 2324...

Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were.

It's not like multi-homed protocols based on IP are new. SCTP has been around about a decade (half a decade as a real Internet standard).

Are you the author of RFC 3514 ?

Or is this an option?

RFC 3280 #4.2.1.11

The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names.

...

>

It is an option that was not forced on the root CAs. Essentially none of the public CAs are signing from intermediary CAs with name restrictions applied to their certificates.

Generally the restriction mechanism is only allowed to do something kind of "creepy"; where the root CA essentially "sells" this service to a smaller company for perhaps $50,000 or so and issues a restricted certificate --- that allows whoever bought this service to sign subcerts within certain constraints.

Quick, do you vote "yes" or "no" on the Jabberwocky?

This is the most lucid summary I've seen of the current "debate". Quoting:

The things that bug me most about the net neutrality debate are:

0) The whole slow lane/fast lane conception is just wrong. Internet traffic looks nothing like vehicle traffic. On roads, you have only a few lanes to put cars in. On the internet, it's more like you break up the cars and trucks into atoms (packets), mix them all together, pour them through various choke points and reassemble them at their destination no matter in what order they arrive.

Traffic management at these levels IS needed, and managed at a e2e level by a TCP-friendly protocol (generally), and at a router level by queue management schemes like "Drop Tail". Massive improvements to drop tail, fixing what is known as "bufferbloat" with better "active queue management" (AQM) and packet scheduling schemes (FQ) such as codel, fq_codel, RED, and PIE are being considered by the IETF to better manage congestion, and the net result of these techniques is vastly reduced latency across the chokepoints, vastly improved levels of service for latency sensitive services (such as voice, gaming, and videoconferencing), with only the fattest flows losing some packets and thus slowing down - regardless of who is sending them. Politics doesn't enter into it. Any individual can make their own links better, as can any isp, and vendor.

Some links:

http://tools.ietf.org/html/dra...
https://datatracker.ietf.org/d...
http://tools.ietf.org/html/dra...
http://tools.ietf.org/html/dra...

Furthermore individual packets can be marked by the endpoints to indicate their relative needs. This is called QoS, and the primary technique is "diffserv".

http://en.wikipedia.org/wiki/D...

There are plenty of problems with diffserv in general, but they are very different from thinking about "fast or slow" lanes, which are rather difficult to implement compared to any of the techniques noted above. You have to have a database of every ip address you wish to manipulate accessed in real time, on every packet, in order to implement the lanes.

IF ONLY I could see in the typical network neutrality debater a sane understanding and discussion of simple AQM, packet scheduling, and QoS techniques, I would be extremely comforted in the idea that sane legislation would emerge. But I've been waiting 10 years for that to happen.

We have tested, and have deployed these algorithms to dramatic reductions in latency and increased throughput on consumer grade hardware, various isps and manufacturers have standardized on various versions, (docsis 3.1 is pie, free.fr uses fq_codel, as does streamboost, as do nearly all the open source routing projects such as openwrt)

I really wish those debating net neutrality actually try - or at least be aware of - these technical solutions to the congestion problems they seek to solve with legislation. I wouldn't mind at all legal mandates to have aqm on, by default. :)

It makes a huge difference, on all technologies available today:

https://www.bufferbloat.net/pr...

See also the bufferbloat mailing lists.

1) if we want true neutrality, restrictive rules by the ISPs regarding their customers hosting services of their own have to go - and nobody's been making THAT point, which irks me significantly. In an age where you have, say, gbit fiber to your business, it makes quite a lot of sense from a security

Quick, do you vote "yes" or "no" on the Jabberwocky?

This is the most lucid summary I've seen of the current "debate". Quoting:

The things that bug me most about the net neutrality debate are:

0) The whole slow lane/fast lane conception is just wrong. Internet traffic looks nothing like vehicle traffic. On roads, you have only a few lanes to put cars in. On the internet, it's more like you break up the cars and trucks into atoms (packets), mix them all together, pour them through various choke points and reassemble them at their destination no matter in what order they arrive.

Traffic management at these levels IS needed, and managed at a e2e level by a TCP-friendly protocol (generally), and at a router level by queue management schemes like "Drop Tail". Massive improvements to drop tail, fixing what is known as "bufferbloat" with better "active queue management" (AQM) and packet scheduling schemes (FQ) such as codel, fq_codel, RED, and PIE are being considered by the IETF to better manage congestion, and the net result of these techniques is vastly reduced latency across the chokepoints, vastly improved levels of service for latency sensitive services (such as voice, gaming, and videoconferencing), with only the fattest flows losing some packets and thus slowing down - regardless of who is sending them. Politics doesn't enter into it. Any individual can make their own links better, as can any isp, and vendor.

Some links:

http://tools.ietf.org/html/dra...
https://datatracker.ietf.org/d...
http://tools.ietf.org/html/dra...
http://tools.ietf.org/html/dra...

Furthermore individual packets can be marked by the endpoints to indicate their relative needs. This is called QoS, and the primary technique is "diffserv".

http://en.wikipedia.org/wiki/D...

There are plenty of problems with diffserv in general, but they are very different from thinking about "fast or slow" lanes, which are rather difficult to implement compared to any of the techniques noted above. You have to have a database of every ip address you wish to manipulate accessed in real time, on every packet, in order to implement the lanes.

IF ONLY I could see in the typical network neutrality debater a sane understanding and discussion of simple AQM, packet scheduling, and QoS techniques, I would be extremely comforted in the idea that sane legislation would emerge. But I've been waiting 10 years for that to happen.

We have tested, and have deployed these algorithms to dramatic reductions in latency and increased throughput on consumer grade hardware, various isps and manufacturers have standardized on various versions, (docsis 3.1 is pie, free.fr uses fq_codel, as does streamboost, as do nearly all the open source routing projects such as openwrt)

I really wish those debating net neutrality actually try - or at least be aware of - these technical solutions to the congestion problems they seek to solve with legislation. I wouldn't mind at all legal mandates to have aqm on, by default. :)

It makes a huge difference, on all technologies available today:

https://www.bufferbloat.net/pr...

See also the bufferbloat mailing lists.

1) if we want true neutrality, restrictive rules by the ISPs regarding their customers hosting services of their own have to go - and nobody's been making THAT point, which irks me significantly. In an age where you have, say, gbit fiber to your business, it makes quite a lot of sense from a security

Quick, do you vote "yes" or "no" on the Jabberwocky?

This is the most lucid summary I've seen of the current "debate". Quoting:

The things that bug me most about the net neutrality debate are:

0) The whole slow lane/fast lane conception is just wrong. Internet traffic looks nothing like vehicle traffic. On roads, you have only a few lanes to put cars in. On the internet, it's more like you break up the cars and trucks into atoms (packets), mix them all together, pour them through various choke points and reassemble them at their destination no matter in what order they arrive.

Traffic management at these levels IS needed, and managed at a e2e level by a TCP-friendly protocol (generally), and at a router level by queue management schemes like "Drop Tail". Massive improvements to drop tail, fixing what is known as "bufferbloat" with better "active queue management" (AQM) and packet scheduling schemes (FQ) such as codel, fq_codel, RED, and PIE are being considered by the IETF to better manage congestion, and the net result of these techniques is vastly reduced latency across the chokepoints, vastly improved levels of service for latency sensitive services (such as voice, gaming, and videoconferencing), with only the fattest flows losing some packets and thus slowing down - regardless of who is sending them. Politics doesn't enter into it. Any individual can make their own links better, as can any isp, and vendor.

Some links:

http://tools.ietf.org/html/dra...
https://datatracker.ietf.org/d...
http://tools.ietf.org/html/dra...
http://tools.ietf.org/html/dra...

Furthermore individual packets can be marked by the endpoints to indicate their relative needs. This is called QoS, and the primary technique is "diffserv".

http://en.wikipedia.org/wiki/D...

There are plenty of problems with diffserv in general, but they are very different from thinking about "fast or slow" lanes, which are rather difficult to implement compared to any of the techniques noted above. You have to have a database of every ip address you wish to manipulate accessed in real time, on every packet, in order to implement the lanes.

IF ONLY I could see in the typical network neutrality debater a sane understanding and discussion of simple AQM, packet scheduling, and QoS techniques, I would be extremely comforted in the idea that sane legislation would emerge. But I've been waiting 10 years for that to happen.

We have tested, and have deployed these algorithms to dramatic reductions in latency and increased throughput on consumer grade hardware, various isps and manufacturers have standardized on various versions, (docsis 3.1 is pie, free.fr uses fq_codel, as does streamboost, as do nearly all the open source routing projects such as openwrt)

I really wish those debating net neutrality actually try - or at least be aware of - these technical solutions to the congestion problems they seek to solve with legislation. I wouldn't mind at all legal mandates to have aqm on, by default. :)

It makes a huge difference, on all technologies available today:

https://www.bufferbloat.net/pr...

See also the bufferbloat mailing lists.

1) if we want true neutrality, restrictive rules by the ISPs regarding their customers hosting services of their own have to go - and nobody's been making THAT point, which irks me significantly. In an age where you have, say, gbit fiber to your business, it makes quite a lot of sense from a security

Quick, do you vote "yes" or "no" on the Jabberwocky?

This is the most lucid summary I've seen of the current "debate". Quoting:

The things that bug me most about the net neutrality debate are:

0) The whole slow lane/fast lane conception is just wrong. Internet traffic looks nothing like vehicle traffic. On roads, you have only a few lanes to put cars in. On the internet, it's more like you break up the cars and trucks into atoms (packets), mix them all together, pour them through various choke points and reassemble them at their destination no matter in what order they arrive.

Traffic management at these levels IS needed, and managed at a e2e level by a TCP-friendly protocol (generally), and at a router level by queue management schemes like "Drop Tail". Massive improvements to drop tail, fixing what is known as "bufferbloat" with better "active queue management" (AQM) and packet scheduling schemes (FQ) such as codel, fq_codel, RED, and PIE are being considered by the IETF to better manage congestion, and the net result of these techniques is vastly reduced latency across the chokepoints, vastly improved levels of service for latency sensitive services (such as voice, gaming, and videoconferencing), with only the fattest flows losing some packets and thus slowing down - regardless of who is sending them. Politics doesn't enter into it. Any individual can make their own links better, as can any isp, and vendor.

Some links:

http://tools.ietf.org/html/dra...
https://datatracker.ietf.org/d...
http://tools.ietf.org/html/dra...
http://tools.ietf.org/html/dra...

Furthermore individual packets can be marked by the endpoints to indicate their relative needs. This is called QoS, and the primary technique is "diffserv".

http://en.wikipedia.org/wiki/D...

There are plenty of problems with diffserv in general, but they are very different from thinking about "fast or slow" lanes, which are rather difficult to implement compared to any of the techniques noted above. You have to have a database of every ip address you wish to manipulate accessed in real time, on every packet, in order to implement the lanes.

IF ONLY I could see in the typical network neutrality debater a sane understanding and discussion of simple AQM, packet scheduling, and QoS techniques, I would be extremely comforted in the idea that sane legislation would emerge. But I've been waiting 10 years for that to happen.

We have tested, and have deployed these algorithms to dramatic reductions in latency and increased throughput on consumer grade hardware, various isps and manufacturers have standardized on various versions, (docsis 3.1 is pie, free.fr uses fq_codel, as does streamboost, as do nearly all the open source routing projects such as openwrt)

I really wish those debating net neutrality actually try - or at least be aware of - these technical solutions to the congestion problems they seek to solve with legislation. I wouldn't mind at all legal mandates to have aqm on, by default. :)

It makes a huge difference, on all technologies available today:

https://www.bufferbloat.net/pr...

See also the bufferbloat mailing lists.

1) if we want true neutrality, restrictive rules by the ISPs regarding their customers hosting services of their own have to go - and nobody's been making THAT point, which irks me significantly. In an age where you have, say, gbit fiber to your business, it makes quite a lot of sense from a security

Get with the times! Switch to Y10K compliance already.

http://en.wikipedia.org/wiki/Y...

I don't like that type of short term thinking. When Y100,000 comes along you'll regret not doing it properly in the first place. Everyone should implement rfc2550.

It sounds like we need the ability to limit the scope of certificate authorities to signing for only certain domains.

http://tools.ietf.org/html/rfc...

I think intermediate CA certificates issued to certificate vendors, ISPs, governments, should all have name constraints so that they can be used to sign only certificates for an appropriate part of the namespace.

http://tools.ietf.org/html/rfc...

Yep, sounds like just another variation on the evil bit.

Being a government agency, with its well known tendency to mandate things, they might be inspired by this RFC and decide to mandate everyone to set the snark bit in all their postings.

Complicated totally unfamiliar representation of date and time for the "information age"? I think i'll take flawwed, but understood and good enough over that any time.

rfc 1925 2.11 is reaffirmed

(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

Right, we need password-authenticated key agreements to become more common place, which are based on a zero-knowledge password proof. There are even IEEE and RFC standards.

What is the hold up here? Implementation is harder than simple password comparison?

POP3 (port 110) does not have a "send" command. See the protocol definition:
http://www.ietf.org/rfc/rfc193...

You MUA uses POP3 on port 110 to retrieve messages. It sends via smtp on port 25 or port 587, often using a completely different server.

Not just that, but we even have an RFC to deal with keywords within RFCs. Its not just exclusion lists, but also required usage lists.

https://www.ietf.org/rfc/rfc21... http://tools.ietf.org/html/rfc...

People are simply getting bent out of shape because GM defines their language and set of standards for usage of said language. This is true of ALL large companies, and not just in these types of documents. In the tech world, we live or die by these requirements, so why is it a surprise that other industries use them too?

Not just that, but we even have an RFC to deal with keywords within RFCs. Its not just exclusion lists, but also required usage lists.

https://www.ietf.org/rfc/rfc21... http://tools.ietf.org/html/rfc...

People are simply getting bent out of shape because GM defines their language and set of standards for usage of said language. This is true of ALL large companies, and not just in these types of documents. In the tech world, we live or die by these requirements, so why is it a surprise that other industries use them too?

Espionage is not an attack.

The IETF would disagree with you

By now, SNMP v3 should be the only version implemented on *any* device, given that the standard was published in 1999.

According to TFA, most of the affected devices have been EOL'd, but are still in use and/or are for sale in secondary markets. Even so, I'd be surprised if any of these even existed before 2004, a full five years after the SNMP v3 spec was published. Sigh.

WEP was broken in 2001. My local DSL ISP provides wireless routers to their customers. They come from the ISP configured with WEP. In 2014.

Authentication data/encryption keys should never be exposed via the read-only (public) SNMP community. This is just crappy implementation. Surprise, surprise. By now, SNMP v3 should be the only version implemented on *any* device, given that the standard was published in 1999.

According to TFA, most of the affected devices have been EOL'd, but are still in use and/or are for sale in secondary markets. Even so, I'd be surprised if any of these even existed before 2004, a full five years after the SNMP v3 spec was published. Sigh.

Okay I know, a huge number of devices from almost every manufacturer default to SNMP v1 or v2c with no encryption whatsoever. But that doesn't make it right, nor does it excuse the inclusion of private data in the public MIB. I'm just glad I don't have any of those devices.

A third way is to control positions responsible for communicating with other groups, which gives them more opportunities to influence the discussion or misrepresent consensus.

See Trevor Perrin's request to remove NSA employee Kevin Igoe from the position as co-chair of the Crypto Forum Research Group:

Reasons for requesting Kevin's removal
----
1) Kevin has provided the *ONLY* positive feedback for Dragonfly that
can be found on the CFRG mailing list or meeting minutes. The
contrast between Kevin's enthusiasm and the group's skepticism is
striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based
on. There's no record of Kevin making any effort to understand
Dragonfly's unusual structure, compare it to alternatives, consider
possible use cases, or construct a formal security analysis.

2) Twice Kevin suggested a technique for deriving the Dragonfly
password-based element which would make the protocol easy to break
[IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid
timing attacks by adding extra iterations to one of the loops [IGOE_3,
IGOE_4]. These are surprising mistakes from an experienced
cryptographer.

3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG
consensus, which was skeptical of Dragonfly [CFRG_SUMMARY].

4) Kevin's NSA affiliation raises unpleasant but unavoidable
questions regarding these actions. It's entirely possible these are
just mistakes by a novice chair who lacks experience in a particular
sort of protocol and is being pressured by IETF participants to
endorse something. But it's hard to escape an impression of
carelessness and unseriousness in Kevin's work. One wonders whether
the NSA is happy to preside over this sort of sloppy crypto design.

While that's of course speculation, it remains baffling that an
experienced cryptographer would champion such a shoddy protocol. The
CFRG chairs have been silent for months, and haven't responded to
attempts to clarify this.

The request was reviewed and denied, so the crypto research group is still co-chaired by a NSA employee.

That RFC 3339 link didn't load. I googled, and got this one to work. I think it needed to be https...

If the IETF wants to make something like RFC 7168 (Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)), then its too late. In fact RFC 7258 is in violation of RFC 3339.

It was called DNSSEC Stapled Certificates. Was -- Chrome removed it.

See also RFC 6698.

Note you can already do this with SSH keys, where's the implementation for TLS for HTTP?

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.