Re: Update to BCP-38?
Any additional effort put in by an attacker will increase the chance of an attack being detected before it is successful. COnsider the following two scenerios. Scenerio 1 is a webserver that makes no effort to obfuscate: 1. Attacker does HEAD request on /, which is a legitmate request, and sees the webserver vendor name 2. Attacker does a quick search, and finds there is a vulnerabilty in webserver 3. Attacker exploits vulnerability Now, consider scenerio 2, where the server is configured to hide the webserver vendor and has an IDS/IPS system in place 1. Attacker does HEAD request on /, which is a legitmate request, but there is no usable information in the respone. 2. Attacker does a probe on the webserver to try a number of attacks, which generate a number of 403, 404, 500 etc errors in the webserver logs 3. IDS/IPS sees the sudden spike in errors from a single IP address and blocks the source IP The act of obfuscation made it possible for the IDS/IPS to detect the probe, preventing the attack. WIll this block every attack? Probably not, but it increases the effectiveness of the security by forcing the attacker to take additional (detectable) actions when trying to break in. The lock on your front door can be picked by anyone with a $10 lockpick set in under 5 minutes, does that mean you shouldn't bother locking your doors? Mark From: NANOG on behalf of Keith Medcalf Sent: 08 October 2019 18:53 To: nanog@nanog.org Subject: RE: Update to BCP-38? On Tuesday, 8 October, 2019 11:03, William Herrin wrote: >Limiting the server banner so it doesn't tell an adversary the exact OS- >specific binary you're using has a near-zero cost and forces an adversary >to expend more effort searching for a vulnerability. It doesn't magically >protect you from hacking on its own. As you say, your security must not >be breached just because the adversary figures out what version you're >running. But viewed as one layer in an overall plan, limiting that >information enhances your security at negligible cost. That's security >smart. I think your analysis is incorrect. There are two cases which are relevant: (1) The attack is non-targetted (that is, it is opportunistic) (2) The attack is targetted at you specifically. In the former (1) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. The script either works or it does not. Even if the "banner" says "Beyond this point there be monsters" will make absolutely not one whit of difference. In the latter (2) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. You have been targetted. All possible exploits will be attempted until success is achieved or the vat of exploits to try runs dry. So while the cost of doing the thing may be near-zero, it is not zero. All those near-zero cost things you do that have no actual advantage can add up to quite a huge total and it will be more advantageous to spend that somewhere where it will, in fact, make a difference. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. This Email from Marie Stopes International and any attachments may contain information which is privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient(s) of this Email or any part of it please notify the sender immediately on receipt and delete it from your system. Any opinion or other information in this email or its attachments that does not relate to the business of Marie Stopes International is personal to the sender and is not given or endorsed by Marie Stopes International.
Re: Update to BCP-38?
On Tue, 8 Oct 2019 13:59:58 +, Mark Collins may have written: > Not everyone attacking your systems is going to have the skills or > knowledge to get in though - simple tricks (like hiding what web server > you use) can prevent casual attacks from script kiddies and others who > aren't committed to targeting you, freeing your security teams to focus > on the serious threats. Er ... no. Not according to real world data (my firewall logs). Most attacks are fully automated and they don't (always) bother with complex logic to determine which attacks to try. For instance I constantly see Apache struts attacks against servers that a) may or may not be running Apache (the headers are removed) b) definitely aren't running Struts. In fact many attacks are sufficiently automated that the human behind the scenes won't even know a system has been compromised if it doesn't successfully pick up the second stage of the payload and 'phone home'. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! pgpuN30Tt6VQC.pgp Description: OpenPGP digital signature
Re: Update to BCP-38?
On Tue, Oct 08, 2019 at 10:03:16AM -0700, William Herrin wrote: > Limiting the server banner so it doesn't tell an adversary the exact > OS-specific binary you're using has a near-zero cost and forces an > adversary to expend more effort searching for a vulnerability. Why would they bother performing that search? Why not use their botnets to throw every exploit they have at a service and see if anything works? That's easier and cheaper and faster than being selective. It also -- if they have happen to have a working exploit -- blows right past (announced) versions, whether real, fake, or elided. Brute force is cheap, analysis is expensive. Case in point: every mail server I have eyeballs on was probed by attackers trying to exploit the recent exim vulnerability -- no matter what MTA they're running, no matter that they all announce the MTA and version, no matter anything. I doubt I'm alone in observing this. Even a diligent, capable attacker -- someone who is willing to invest the time and effort to ascertain what's running which service, down to the version -- could save themselves some homework by launching an attack like the one in the first paragraph above, examining the results, and using those to greatly reduce their search space. It's easy, it's cheap, it's fast, it's automated, and it yields no clues as to where the followup (version-specific) attack is going to come from. ---rsk
RE: Update to BCP-38?
You would still be better served by forgetting about hiding the webserver vendor name and using that money to buy an IDS/IPS that works properly by detecting the actual exploit attempt rather than looking for "a spike of errors in the log" in order to block the originating address, especially since a "spike of errors in the log" can have quite a few causes other than exploit attempts -- in fact such a "spike in errors" is more likely to occur for reasons other than attempts to find a vulnerability. Furthermore, it is quite possible for the first exploit attempt to be successful despite having hidden the banner, in which case the entire thing was merely nothing more than security theatre. This is especially true when you consider "many" systems using this method of protection and millions of attempted exploits per second. Furthermore, why on earth would an opportunistic attacker use two requests when one would suffice? There is nothing to be gained by probing only to discover "Oh, I am getting all wet cuz this is a juicy target" when one would merely send the exploit and see what happens -- it either works or it does not -- and probing first adds no value -- in just makes each attempt expend more resources. In the time you have probed a server and gotten a response, you could have simply sent the exploit to a dozen servers. So clearly probing for a "good target" is just a waste of time. This is why most dirty e-mail spammers just "blast" out their spam without waiting for the appropriate responses from the SMTP server, and why having the SMTP server insist on strict RFC compliance (and test that the connected MTA is RFC compliant) works so well at getting rid of 95% of spam. So given a choice between: (1) Spending money hiding the headers and using software to reconfigure the firewall based on errors in the log; or, (2) Spending money on an IDS/IPS that can detect and drop an exploit dynamically you are probably better served by (2) than by (1). The software that monitors the log is most useful to send a notification that there is an excessive error rate (since that is what it is detecting). Of the millions of ransomware attacks per second, the 617 victims so far this year probably relied on method (1) and in hindsight wished they had been a little smarter and used method (2) instead. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: Mark Collins >Sent: Tuesday, 8 October, 2019 12:17 >To: Keith Medcalf ; nanog@nanog.org >Subject: Re: Update to BCP-38? > >Any additional effort put in by an attacker will increase the chance of >an attack being detected before it is successful. COnsider the following >two scenerios. > >Scenerio 1 is a webserver that makes no effort to obfuscate: > > >1. Attacker does HEAD request on /, which is a legitmate request, and >sees the webserver vendor name > >2. Attacker does a quick search, and finds there is a vulnerabilty in >webserver >3. Attacker exploits vulnerability > > >Now, consider scenerio 2, where the server is configured to hide the >webserver vendor and has an IDS/IPS system in place > > >1. Attacker does HEAD request on /, which is a legitmate request, but >there is no usable information in the respone. >2. Attacker does a probe on the webserver to try a number of attacks, >which generate a number of 403, 404, 500 etc errors in the webserver logs >3. IDS/IPS sees the sudden spike in errors from a single IP address and >blocks the source IP > >The act of obfuscation made it possible for the IDS/IPS to detect the >probe, preventing the attack. WIll this block every attack? Probably not, >but it increases the effectiveness of the security by forcing the >attacker to take additional (detectable) actions when trying to break in. > >The lock on your front door can be picked by anyone with a $10 lockpick >set in under 5 minutes, does that mean you shouldn't bother locking your >doors? > >Mark > > > >From: NANOG on >behalf of Keith Medcalf >Sent: 08 October 2019 18:53 >To: nanog@nanog.org >Subject: RE: Update to BCP-38? > > >On Tuesday, 8 October, 2019 11:03, William Herrin wrote: > >>Limiting the server banner so it doesn't tell an adversary the exact OS- >>specific binary you're using has a near-zero cost and forces an >adversary >>to expend more effort searching for a vulnerability. It doesn't >magically >>protect you from hacking on its own. As you say, your security must not >>be breached just because the adversary figures out what version you're >>running. But viewed as one layer in an overall plan, limiting that &g
Re: Update to BCP-38?
On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said: > So while the cost of doing the thing may be near-zero, it is not zero. And in fact, there's more than just the costs of doing it. There's also the costs of having done it. Obfuscating your OpenSSH versions is a *really* good way to make your security scanners that flag backleveled systems fail to flag the systems. Which can cause a really uncomfortable conversation with the CIO about why the local newspaper's front page is running a story about how your organization got totally pwned via a backleveled OpenSSH on one cluster of 5 servers. pgpES4WWnZrxq.pgp Description: PGP signature
RE: Update to BCP-38?
On Tuesday, 8 October, 2019 11:03, William Herrin wrote: >Limiting the server banner so it doesn't tell an adversary the exact OS- >specific binary you're using has a near-zero cost and forces an adversary >to expend more effort searching for a vulnerability. It doesn't magically >protect you from hacking on its own. As you say, your security must not >be breached just because the adversary figures out what version you're >running. But viewed as one layer in an overall plan, limiting that >information enhances your security at negligible cost. That's security >smart. I think your analysis is incorrect. There are two cases which are relevant: (1) The attack is non-targetted (that is, it is opportunistic) (2) The attack is targetted at you specifically. In the former (1) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. The script either works or it does not. Even if the "banner" says "Beyond this point there be monsters" will make absolutely not one whit of difference. In the latter (2) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. You have been targetted. All possible exploits will be attempted until success is achieved or the vat of exploits to try runs dry. So while the cost of doing the thing may be near-zero, it is not zero. All those near-zero cost things you do that have no actual advantage can add up to quite a huge total and it will be more advantageous to spend that somewhere where it will, in fact, make a difference. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: Update to BCP-38?
On Tue, Oct 8, 2019 at 6:51 AM Rich Kulawiec wrote: > On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > > You've ignored step 1 - identifying critical information that needs > > protecting. It makes sense to protect information that needs protecting and > > don't lose sleep over information that doesn't need protecting. Not many of > > us are planning an invasion of a Nazi-infected Europe any time soon. > > We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, > the latter of which can be paraphrased as "design systems assuming that > your adversary will know as much about them as you do". They aren't mutually exclusive concepts. A strong security architecture has multiple layers an adversary must penetrate. No layer has to be sufficient on its own, it just has to reduce vulnerability more than it increases cost. Limiting the server banner so it doesn't tell an adversary the exact OS-specific binary you're using has a near-zero cost and forces an adversary to expend more effort searching for a vulnerability. It doesn't magically protect you from hacking on its own. As you say, your security must not be breached just because the adversary figures out what version you're running. But viewed as one layer in an overall plan, limiting that information enhances your security at negligible cost. That's security smart. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
RE: Update to BCP-38?
>Not everyone attacking your systems is going to have the skills or >knowledge to get in though - simple tricks (like hiding what web server >you use) can prevent casual attacks from script kiddies and others who >aren't committed to targeting you, freeing your security teams to focus >on the serious threats. And this is based on what evidence? It also defies logic. By definition script-kiddies run scripts. If you remove the identification those scripts can no longer identify what is running, and therefore will continue to attack it. What would be useful is to replace that with alternative "disinformation" headers so that the script-kiddies scripts will get a positive result, but that result will not be what they are looking for, so they will go away. Until having disinformation headers gets the same "old wives tale" status as "remove the identifying headers". At which point either course of either action is a waste of effort and $$$ because the script-kiddies will just ignore it as it will be just as cost effective to run the exploit and see what happens. In other words, simple tricks are exactly that. They usually do exactly the opposite of what the "simple tricker" thought they were doing, or do nothing useful at all. Which means that effort and $$$ have been expended at best on a useless endeavour, and at worst one which increased the very activity it was designed to thwart. One would have been far better off putting the $$$ in the slush-fund and using it when some particularly persistent script-kiddie showed up so you could afford to add a filter to the firewall. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
RE: Update to BCP-38?
Not everyone attacking your systems is going to have the skills or knowledge to get in though - simple tricks (like hiding what web server you use) can prevent casual attacks from script kiddies and others who aren't committed to targeting you, freeing your security teams to focus on the serious threats. Mark -Original Message- From: NANOG On Behalf Of Rich Kulawiec Sent: 08 October 2019 14:51 To: nanog@nanog.org Subject: Re: Update to BCP-38? On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > You've ignored step 1 - identifying critical information that needs > protecting. It makes sense to protect information that needs > protecting and don't lose sleep over information that doesn't need > protecting. Not many of us are planning an invasion of a Nazi-infected Europe > any time soon. We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, the latter of which can be paraphrased as "design systems assuming that your adversary will know as much about them as you do". Not that I'm advocating publishing all internal design documents, but systems whose security is predicated on the secrecy of those are brittle and likely to be badly compromised. Better to assume that enemies know or can find out everything and design/build accordingly. ---rsk This Email from Marie Stopes International and any attachments may contain information which is privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient(s) of this Email or any part of it please notify the sender immediately on receipt and delete it from your system. Any opinion or other information in this email or its attachments that does not relate to the business of Marie Stopes International is personal to the sender and is not given or endorsed by Marie Stopes International.
Re: Update to BCP-38?
On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > You've ignored step 1 - identifying critical information that needs > protecting. It makes sense to protect information that needs protecting and > don't lose sleep over information that doesn't need protecting. Not many of > us are planning an invasion of a Nazi-infected Europe any time soon. We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, the latter of which can be paraphrased as "design systems assuming that your adversary will know as much about them as you do". Not that I'm advocating publishing all internal design documents, but systems whose security is predicated on the secrecy of those are brittle and likely to be badly compromised. Better to assume that enemies know or can find out everything and design/build accordingly. ---rsk
Re: Update to BCP-38?
As an Evil Firewall Administrator™, I have an interest in this area ... On Fri, 4 Oct 2019 15:05:29 -0700, William Herrin may have written: > On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote > > Anyone who says something like that is not a "security geek". They are > > a "security poser", interested primarily in "security by obscurity" and > > "security theatre", and have no clue what they are talking about. Hmm ... 'primarily in "security by obscurity"' ... that does tend to indicate a severe case of cluelessness (and that's coming from someone who doesn't let his right hand know what his left hand is up to without justification that has been signed off in triplicate). To give a real world example, removing headers from an Apache web server doesn't do much to increase security (it's mostly to keep auditors happy) because automated attacks will hit your exposed Apache servers anyway, and a sophisticated attacker will note the removal and adopt the strategy of an automated attack. > more important information you'd like to deny to him. There's a 5-step > process used by the U.S. Military but the TL;DR version is: if you don't > have to reveal something, don't. You've ignored step 1 - identifying critical information that needs protecting. It makes sense to protect information that needs protecting and don't lose sleep over information that doesn't need protecting. Not many of us are planning an invasion of a Nazi-infected Europe any time soon. -- Mike Meredith, University of Portsmouth Hostmaster, Security, and Chief Systems Engineer pgpmEWhW6kP_b.pgp Description: OpenPGP digital signature
Re: Update to BCP-38?
- Original Message - > From: "Stephen Satchell" > On 10/3/19 10:13 PM, Fred Baker wrote: >> There is one thing in 1122/1123 and 1812 that is not in those kinds >> of documents that I miss; that is essentially "why". Going through >> 1122/1123 and 1812, you'll ind several sections that say "we require >> X", and follow that with a "discussion" section that says "we thought >> about X, Y, and Z, there were proponents of each, the arguments were >> X', Y', and Z', and we chose X for this reason". I would presume that >> what you're really looking for in a 1812-for-IPv6 is not "we require >> X" as much as "for this reason". Correct me if I'm wrong. > > Ah. What I'm looking for is a list of check-boxes to include in an > implementation specification for an edge router. It can be references > to a whole bunch of RFCs and "packaged" as a BCP. The discussions you > describe are better in the individual papers. Is that a good time for me to point to the URL in my sig? 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
RE: Update to BCP-38?
On Friday, 4 October, 2019 16:05, William Herrin wrote: >On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote: >> On Thursday, 3 October, 2019 11:50, Fred Baker >> wrote: >>> A security geek would be all over me - "too many clues!". >> Anyone who says something like that is not a "security geek". They >> are a "security poser", interested primarily in "security by obscurity" >> and "security theatre", and have no clue what they are talking about. > It's called "operations security" or "OPSEC." The idea is that from lots > of pieces of insignificant information, an adversary can derive or infer > more important information you'd like to deny to him. There's a 5-step > process used by the U.S. Military but the TL;DR version is: if you don't > have to reveal something, don't. You and I have completely different opinions of how security works. In my world, security must continue to be effective even in the face of an adversary that knows everything there is to know about what is being attacked (except for some authentication secrets, which of course need to be kept secret). If the attacker does not already have that information, then obtaining it is usually a rather trivial reconnaissance operation. The job of "securing" something means to make it impervious to outside influence -- it is the other side of the "safety" coin -- and Safety and Security go hand in hand. Security based on keeping something which is trivial to discover secret is trivial security and can still be trivially bypassed. It is telling that of the thousands of "ransomware attacks" that occur each second, only 617 have been successful so far this year. Those victims probably relied on keeping something secret that did not matter. In other words, they expended effort on the wrong things -- their analysis of risk was inherently flawed. Can you provide a scenario in which knowledge of the VLAN number is a vulnerability that can be exploited? And if you can find one, is there a more effective way to prevent that exploit that will work even if the attacker knows the VLAN number? Would it not be more effective to implement that measure than simply using trivial means (that are trivial to defeat) to hide the VLAN number? This does not mean that you need to publish the VLAN numbers on Facebook for all to see, merely that knowledge of that fact is now irrelevant, and that even if the someone posted the VLAN numbers on Facebook for all to see, then that would not be helpful to the adversary. >IMO, anyone who thinks the folks who developed OPSEC don't have a clue is >the one I find wanting. Opinions vary. That is the nature of opinion. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: Update to BCP-38?
On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said: > One of a stupidity, among many, of IPv6 is that it assumes > links have millions or billions of mostly immobile hosts Can somebody hand me a match? There's a straw man argument that needs to be set afire here. pgp1MMtG4U3Ba.pgp Description: PGP signature
Re: Update to BCP-38?
On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > A security geek would be all over me - "too many clues!". > > Anyone who says something like that is not a "security geek". They are a > "security poser", interested primarily in "security by obscurity" and > "security theatre", and have no clue what they are talking about. Keith, It's called "operations security" or "OPSEC." The idea is that from lots of pieces of insignificant information, an adversary can derive or infer more important information you'd like to deny to him. There's a 5-step process used by the U.S. Military but the TL;DR version is: if you don't have to reveal something, don't. IMO, anyone who thinks the folks who developed OPSEC don't have a clue is the one I find wanting. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Update to BCP-38?
Mark Andrews wrote: Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. One of a stupidity, among many, of IPv6 is that it assumes links have millions or billions of mostly immobile hosts and define very large (but not large enough for billions or even millions) minimum interval between ND messages, which is applicable to links with much smaller number of hosts. So, though rfc7084 says; it MUST explicitly invalidate itself as an IPv6 default router on each of its advertising interfaces by immediately transmitting one or more Router Advertisement messages with the "Router Lifetime" field set to zero [RFC4861]. rfc4861 forbids two RAs sent with minimum interval less than 16 seconds. Is it "immediately transmitting one or more Router Advertisement messages"? Masataka Ohta
Re: Update to BCP-38?
Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. Also RFC 8585, Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service Mark > On 5 Oct 2019, at 12:00 am, Stephen Satchell wrote: > > On 10/3/19 10:13 PM, Fred Baker wrote: >> There is one thing in 1122/1123 and 1812 that is not in those kinds >> of documents that I miss; that is essentially "why". Going through >> 1122/1123 and 1812, you'll ind several sections that say "we require >> X", and follow that with a "discussion" section that says "we thought >> about X, Y, and Z, there were proponents of each, the arguments were >> X', Y', and Z', and we chose X for this reason". I would presume that >> what you're really looking for in a 1812-for-IPv6 is not "we require >> X" as much as "for this reason". Correct me if I'm wrong. > > Ah. What I'm looking for is a list of check-boxes to include in an > implementation specification for an edge router. It can be references > to a whole bunch of RFCs and "packaged" as a BCP. The discussions you > describe are better in the individual papers. > > Side note: I'm used to rationales being included in Standards, and > welcome them, as long as they are normative and clearly marked so. > >> I can kick the idea around in the IETF if its important to you. I'll >> be looking for a LOT of operational input. > > It could well me that the data is there, we just need a document to > index it all. That's what I thought a BPC was supposed to be. It would > be like an article in ACM Computing Surveys, which references the > existing literature, as opposed to being created from whole cloth. > > I think I steered everyone wrong when I was talking about some of the > exposition in the text, specifically the examples. That kind of > material really belongs in an RFC. My apologies. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Update to BCP-38?
On 10/3/19 10:13 PM, Fred Baker wrote: > There is one thing in 1122/1123 and 1812 that is not in those kinds > of documents that I miss; that is essentially "why". Going through > 1122/1123 and 1812, you'll ind several sections that say "we require > X", and follow that with a "discussion" section that says "we thought > about X, Y, and Z, there were proponents of each, the arguments were > X', Y', and Z', and we chose X for this reason". I would presume that > what you're really looking for in a 1812-for-IPv6 is not "we require > X" as much as "for this reason". Correct me if I'm wrong. Ah. What I'm looking for is a list of check-boxes to include in an implementation specification for an edge router. It can be references to a whole bunch of RFCs and "packaged" as a BCP. The discussions you describe are better in the individual papers. Side note: I'm used to rationales being included in Standards, and welcome them, as long as they are normative and clearly marked so. > I can kick the idea around in the IETF if its important to you. I'll > be looking for a LOT of operational input. It could well me that the data is there, we just need a document to index it all. That's what I thought a BPC was supposed to be. It would be like an article in ACM Computing Surveys, which references the existing literature, as opposed to being created from whole cloth. I think I steered everyone wrong when I was talking about some of the exposition in the text, specifically the examples. That kind of material really belongs in an RFC. My apologies.
Re: Update to BCP-38?
On Oct 3, 2019, at 3:15 PM, Stephen Satchell wrote: > You still need a IPv6 version of RFC 1812. If we were to start with the current draft, I would probably want to start over, and have people involved from multiple operators. That said, let me give you some background on RFC 1812. The development started a little after a largish group of people started on what eventually became RFCs 1122 and 1123. The point was that there were a number of RFCs that needed to be updated with hard-earned wisdom - how ARP should work and so on. The group decided that instead of reissuing each individual RFC, they should do one omnibus effort. 1812 similarly covered a lot of "we discovered that this was true or needed to become true". The first editors was Philip Almquist, and it passed through several subsequent pairs of hands. It then sat on a shelf for several years, with people saying "we really should publish that" and not doing so. In 1994, the CIDR change was in full swing, and I was changing employers. Marshall Rose contacted me asking me to take it over, edit CIDR into it and "do whatever else was needed", and publish the thing. My new boss agreed to lt me do so, and I did. I was given the text in RFC 1716 as input, which was then published as "historic", and RFC 1812 was the end product. RFC 1812 is kind of long in the tooth, BTW. Since then, the way the IETF updates documents with hard-earned wisdom has changed. We don't do omnibus documents like RFC 1122/1123 and 1812; we write a document - or 20 of them - that "update" the document in question. You can find that information in the rfc-index.txt file, and in the datatracker. So if there were updates to include corresponding to those RFCs and on IPv6, I think the IETF would tell you to look at RFC 8200. There is one thing in 1122/1123 and 1812 that is not in those kinds of documents that I miss; that is essentially "why". Going through 1122/1123 and 1812, you'll ind several sections that say "we require X", and follow that with a "discussion" section that says "we thought about X, Y, and Z, there were proponents of each, the arguments were X', Y', and Z', and we chose X for this reason". I would presume that what you're really looking for in a 1812-for-IPv6 is not "we require X" as much as "for this reason". Correct me if I'm wrong. I can kick the idea around in the IETF if its important to you. I'll be looking for a LOT of operational input.
Re: Update to BCP-38?
Valdis Kletnieks wrote: I suppose you never considered that in the 11 years intervening, we decided that maybe things should be done differently. I never considered? I even know that it is called second system syndrome. Do you? Masataka Ohta
Re: Update to BCP-38?
On Fri, 04 Oct 2019 08:20:22 +0900, Masataka Ohta said: > As for requirements for IPv6 routers, how do you think about the > following requirement by rfc4443? 3 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443) > rfc1812 says: 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) I suppose you never considered that in the 11 years intervening, we decided that maybe things should be done differently. > IPv6 specification is fatally broken in various ways. Oddly enough, it doesn't seem to be fatally broken from where I am, or from where Google is, or from where Facebook is, or from where most of the cellphone companies are. You must have a different definition of "fatally broken" than the rest of us. pgpBf75WZkmZ4.pgp Description: PGP signature
Re: Update to BCP-38?
Stephen Satchell wrote: You still need a IPv6 version of RFC 1812. Make it as clean as possible. Use an ax instead of a XACTO knife on the current draft. What is the minimum necessary things that a generic IPv6 router MUST do? As for requirements for IPv6 routers, how do you think about the following requirement by rfc4443? Originating a Packet Too Big Message makes an exception to one of the rules as to when to originate an ICMPv6 error message. Unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or with a link-layer multicast or link-layer broadcast address. rfc1812 says: 4.3.2.7 When Not to Send ICMP Errors An ICMP error message MUST NOT be sent as the result of receiving: o A packet destined to an IP broadcast or IP multicast address, or o A packet sent as a Link Layer broadcast or multicast, or with reasons. IPv6 specification is fatally broken in various ways. Masataka Ohta
Re: Update to BCP-38?
On 10/3/19 2:07 PM, Mark Andrews wrote: > Now IPv6 examples are nice but getting several 1000’s people to read draft > that > just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, > 12.0.0.0/8 > and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly > is a waste of time. Long ago, I was working on Network Graphics Protocol and the draft RFC for it. My boss said that I needed to write a couple of paragraphs about fixed-point binary fractions, which the protocol used, "because that's not a common thing in the world". How bad was this? The person who was writing the generator of the NGP stream used *floating point* because that person didn't understand that 7FFF was interpreted as a bitty-point less than 1.0, and 8001 was a bitty-point less that -1.0 -- and that trying to shoehorn this into IEEE floating-point format almost worked. What my poor boss didn't realize is that exactly 1.0 and -1.0 were not defined. The specification didn't make that clear. When I'm doing technical writing, I find all sorts of corner cases that were missed by the designers and the QA people. It makes me very unpopular. But it also makes for a better product, in the end. So making everything crystal clear and obvious is definitely not "a waste of time." You have no idea what undiscovered bugs may become obvious when you go through the exercise and show all your work. You still need a IPv6 version of RFC 1812. Make it as clean as possible. Use an ax instead of a XACTO knife on the current draft. What is the minimum necessary things that a generic IPv6 router MUST do?
Re: Update to BCP-38?
On Thu, 03 Oct 2019 15:28:30 -0600, "Keith Medcalf" said: > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > A security geek would be all over me - "too many clues!". > Anyone who says something like that is not a "security geek". They are a > "security poser", interested primarily in "security by obscurity" and > "security > theatre", and have no clue what they are talking about. Amen to that. If you've been pwned hard enough that vlan numbers are useful to the attacker, the fact the attacker knows your vlan numbers is the *least* of your problems pgpKSVtMGgvCY.pgp Description: PGP signature
RE: Update to BCP-38?
On Thursday, 3 October, 2019 11:50, Fred Baker wrote: > A security geek would be all over me - "too many clues!". Anyone who says something like that is not a "security geek". They are a "security poser", interested primarily in "security by obscurity" and "security theatre", and have no clue what they are talking about. Send them back to the burger assembly line at McDonalds -- they are not even qualified to be flipping the burgers -- only to assemble the final burger from the pre-flipped burgers in the burger drawers. And keep them away from the deep fryer, cash, and the microwave oven. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: Update to BCP-38?
> On 4 Oct 2019, at 12:10 am, Marco Davids (Private) via NANOG > wrote: > > > On 03/10/2019 15:51, Stephen Satchell wrote: > >> For a start, *add* IPv6 examples in parallel with the IPv4 examples. > > 1000 times +1 > > We need (much) more IPv6 examples! Have you read BCP-38? Is there anything in there that really needs IPv6 examples to make it clear? BCP-38 is “if the source address of the packet coming from the site isn’t a address allocated to the site, drop the packet”. I’m sure you can all figure out how to do that with IPv6 as easily as with IPv4. Now IPv6 examples are nice but getting several 1000’s people to read draft that just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, 12.0.0.0/8 and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly is a waste of time. Do you really need examples of a TCP SYN Flood attack using IPv6 addresses instead of IPv4 addresses? Or the network diagram to be changed? 11.0.0.0/8 / router 1 / / / 204.69.207.0/24 ISP <- ISP < ISP <--- ISP <-- router <-- attacker A B CD 2 / / / router 3 / 12.0.0.0/8 In other words, the ingress filter on "router 2" above would check: IFpacket's source address from within 204.69.207.0/24 THEN forward as appropriate IFpacket's source address is anything else THEN deny packet Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity. 2001:DB8:11:/48 / router 1 / / / 2001:DB8:204:/48 ISP <- ISP < ISP <--- ISP <-- router <-- attacker A B CD 2 / / / router 3 / 2001:DB8:12:/48 In other words, the ingress filter on "router 2" above would check: IFpacket's source address from within 2001:DB8:204:/48 THEN forward as appropriate IFpacket's source address is anything else THEN deny packet Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity. Mark > -- > Marco > (pushing for IPv6 examples since 2007 or so > like in: https://youtu.be/OLEizGPoB5w?t=30) > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Update to BCP-38?
On Oct 3, 2019, at 12:30 PM, Stephen Satchell wrote: > > On 10/3/19 8:22 AM, Fred Baker wrote: >> And on lists like this, I am told that there is no deployment - that >> nobody wants it, and anyone that disagrees with that assessment has >> lost his or her mind. That all leaves me wondering which of us >> doesn't quite have their eye on the ball. > For the reasons you provided in your original message, the learning > curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" -- > is steep and uncertain. > > And I think you may be misunderstanding the problem. It's not that > people don't want it. They lack the zen of it, they don't see the four > corners of the thing, something that people took years to learn in IPv4. > (I had a leg up, being involved in the original ARPAnet, so I got to > watch it grow. Still have the 1984 DDN handbooks, too.) Funny thing. I was quoting the email in this thread just prior to yours. I won’t say there are no issues in IPv6 deployment; there are. However, having done some myself, if you have IPv4-zen, IPv6-zen is pretty easy to come by with a cheat sheet. For example, does your configuration have statements like IP address 192.0.2.1 255.255.255.0 ? Everywhere you find that, you add a statement like ipv6 address 2001:db8:AABB:1234::/64 eui-64 What I did for the IID (IPv4-speak: “host part”) in a recent project was use the IPv4 address of the interface: IP address 192.0.2.1 255.255.255.0 IPv6 address 2001:db8:aabb:1234:192:0:2:1::/128 The idea was to give the operator a clue. I also put the VLAN number in as the subnet number. A security geek would be all over me - “too many clues!”. That said, I found that by typing “IPv6 address command” into google; the first hit was https://study-ccna.com/how-to-configure-ipv6/. Then, noting that Cisco has a bad habit of pulling things out of there air even though there is a defined way to accomplish it, I corrected the prefix to use the defined documentation prefix. It gets a little interesting when you step away from the switch or router to the firewall; they have their own commands. The ASA, for example, really believes in what Cisco calls “zone-based access control” or “context-based access control”. The good news is that if that’s what you’re trying to achieve (it’s common), configuring that for IPv6 is pretty simple. And similarly, BGP and access lists look a lot like their IPv4 counterparts. What’s a little more of a pain is that if you are using other appliance in your network, they may or may not have IPv6 configurability, and there may or may not be a drop-in replacement. That becomes a conversation with your vendors of choice.
Re: Update to BCP-38?
Sent from my iPad > On Oct 3, 2019, at 12:14 PM, Stephen Satchell wrote: > > On 10/3/19 8:42 AM, Fred Baker wrote: >> >> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: >>> >>> Someone else mentioned that "IPv6 has been around for 25 years, and why >>> is it taking so long for everyone to adopt it?" I present as evidence >>> the lack of a formally-released requirements RFC for IPv6. It suggests >>> that the "science" of IPv6 is not "settled" yet. That puts the >>> deployment of IPv6 in the category of "experiment" and not "production". >> >> And, of course, we now have companies like T-Mobile and others >> turning IPv4 off. If that's an experiment, wow. > The cellular data industry appears to have embraced IPv6 in one form or > another. I would expect that the network engineers have done some work > to keep IPv4 off their *internal* networks, but provide IPv4 access at > the edge. (Isn't a netblock within IPv6 intended to enable bridging to > IPv4?) The applications on the phon could be configured to search DNS > for addresses first. T-Mobile documented what they are doing at https://tools.ietf.org/html/rfc6877. > My AT cell phone has both IPv4 and IPv6 addresses. The IPv4 address > is from my access point; the IPv6 address appears to be a public address. So does my T-Mobile phone. It got the IPv4 address from my friendly neighborhood WiFi. > I would like to move to IPv6. I just don't want to shoot myself in the > foot, or cause trouble for other people, by being sure my edge router > "follows all the rules."
Re: Update to BCP-38?
On 10/3/19 8:22 AM, Fred Baker wrote: > Speaking as v6ops chair and the editor of record for 1812. > draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be > an 1812-like document and adopted as such, but many of the > "requirements" that came out of it were specific to the author's > operation and not common to other operators. So it ultimately didn't happen. Sympathies. I've been involved in Standards-setting committees, so I know how that works. Is there any further work being done? And just how much of the current draft can be generalized? > There is no demand until further IPv4 deployment no longer suffices. > I would say that there was no real market demand until after January > 2011, and probably 2012 or 2013.> > At this point, there is fairly wide deployment among the ISP and CDN > operators, and vendor implementations are fairly complete. Google, > APNIC, and Akamai report on traffic levels; Google says that they see > at least 5% of the requests they receive from 61 countries use IPv6, > and from one country a tad more that half of the requests they > receive use IPv6.> > So we see IPv6 in broadband, in ISPs, and in telephone networks. To > give you an anecdote, my kids have teased me about IPv6 for years, > and each now have IPv6 service from their various ISPs and telephone > networks despite themselves - and use it for the majority of their > accesses.> > What is visibly lacking is enterprise deployment. Interesting you should mention that. One reason I wanted to do an IPv6-aware BGP-38 module for firewalld was to help break that logjam. Enterprises are risk-adverse, which is why adoption meets such strong resistance. > And on lists like this, I am told that there is no deployment - that > nobody wants it, and anyone that disagrees with that assessment has > lost his or her mind. That all leaves me wondering which of us > doesn't quite have their eye on the ball. For the reasons you provided in your original message, the learning curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" -- is steep and uncertain. And I think you may be misunderstanding the problem. It's not that people don't want it. They lack the zen of it, they don't see the four corners of the thing, something that people took years to learn in IPv4. (I had a leg up, being involved in the original ARPAnet, so I got to watch it grow. Still have the 1984 DDN handbooks, too.)
Re: Update to BCP-38?
On 10/3/19 8:42 AM, Fred Baker wrote: > > >> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: >> >> Someone else mentioned that "IPv6 has been around for 25 years, and why >> is it taking so long for everyone to adopt it?" I present as evidence >> the lack of a formally-released requirements RFC for IPv6. It suggests >> that the "science" of IPv6 is not "settled" yet. That puts the >> deployment of IPv6 in the category of "experiment" and not "production". > > And, of course, we now have companies like T-Mobile and others > turning IPv4 off. If that's an experiment, wow. The cellular data industry appears to have embraced IPv6 in one form or another. I would expect that the network engineers have done some work to keep IPv4 off their *internal* networks, but provide IPv4 access at the edge. (Isn't a netblock within IPv6 intended to enable bridging to IPv4?) The applications on the phon could be configured to search DNS for addresses first. My AT cell phone has both IPv4 and IPv6 addresses. The IPv4 address is from my access point; the IPv6 address appears to be a public address. I would like to move to IPv6. I just don't want to shoot myself in the foot, or cause trouble for other people, by being sure my edge router "follows all the rules."
Re: Update to BCP-38?
> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: > > Someone else mentioned that "IPv6 has been around for 25 years, and why > is it taking so long for everyone to adopt it?" I present as evidence > the lack of a formally-released requirements RFC for IPv6. It suggests > that the "science" of IPv6 is not "settled" yet. That puts the > deployment of IPv6 in the category of "experiment" and not "production". And, of course, we now have companies like T-Mobile and others turning IPv4 off. If that's an experiment, wow.
Re: Update to BCP-38?
On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: > It appears that the only parallel paper for IPv6 is > draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which > currently carries a copyright of 2018. It's a shame that this document > is still in limbo; witness this quote: "It is inappropriate to use > Internet-Drafts as reference material or to cite them other than as > 'work in progress.' Speaking as v6ops chair and the editor of record for 1812. draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be an 1812-like document and adopted as such, but many of the "requirements" that came out of it were specific to the author's operation and not common to other operators. So it ultimately didn't happen. > Someone else mentioned that "IPv6 has been around for 25 years, and why > is it taking so long for everyone to adopt it?" I present as evidence > the lack of a formally-released requirements RFC for IPv6. It suggests > that the "science" of IPv6 is not "settled" yet. That puts the > deployment of IPv6 in the category of "experiment" and not "production". > > Is that really true? That's a long story. The IETF realized it needed a next generation protocol in 1990; that's where NATs came from, the successive efforts to recover unused IPv4 space, and research into possible next generation protocols. IPv6 was proposed in 1993-1994, originally published in 1996 as RFC 1883, and republished in 1998 as RFC 2460. It was recently re-re-published as RFC 8200. Supporting work was required in DHCP, DNS, and several routing protocols; that happened over time. ICANN didn't adopt a policy for the allocation of IPv6 address space to RIRs until 2006, and in 2007 there were a number of allocations from IANA to the RIRs and from some of the RIRs to operators in various parts of the world. Testing was also important - primarily done by the NRENs. That wound up with comments going back to various vendors. I was employed by one of them, but will refrain from giving "insider" comments. Suffice it to say that there were multiple vendor implementations, mostly incomplete in one way or another. IANA allocated the last five IPv4 /8s to the RIRs in 2011, and since then the IPv4 address market has been mopping up the slop. Per https://ipv4marketgroup.com/ipv4-pricing/ (if addresses were real estate, ipv4marketgroup would be a real estate agent), the price of an address was stable at or near $10/address from several years, and in 2016-2018 shot to about $18/address. They expect the price to start to fall in the next year or so, as CIOs figure out that its a waste of money. There is no demand until further IPv4 deployment no longer suffices. I would say that there was no real market demand until after January 2011, and probably 2012 or 2013. At this point, there is fairly wide deployment among the ISP and CDN operators, and vendor implementations are fairly complete. Google, APNIC, and Akamai report on traffic levels; Google says that they see at least 5% of the requests they receive from 61 countries use IPv6, and from one country a tad more that half of the requests they receive use IPv6. https://www.vyncke.org/ipv6status/compare.php?metric=p=be,yt,de,gr,my,vn,in,gf,us,uy,fr,tw,jp,lu,ch,mx,br,pt,fi,mq,ax,th,ee,re,hu,gb,ca,gp,tt,ie,lk,nz,au,pe,ec,nl,ae,ro,ga,bo,sa,sx,cz,no,si,sg,pl,gt,at,mo,ar,mm,kr,fo,om,lv,zw,pr,ke,tg,ba. And interesting point in those reports is that Google and Akamai are CDNs, which means that (for the most part) a request goes almost directly from a user's broadband interface to the service in question. APNIC is different in that it operates no CDN; requests they receive cross the backbone, and therefore also measure backbone deployment. To that matter, let me list the APNIC charts of the top ten: https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=BE https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=YT https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=DE https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=GR https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=MY https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=VN https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=IN https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=GF https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=US https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=UY In each of those, APNIC measures and reports a distinction between a requestor being "IPv6 Capable" and "Preferring IPv6". This is done using a google ad that includes three one-pixel links; one of the names has only an A record, one has only a record, and one bas both. If the requestor uses the first two links and APNIC receives the SYN, then the end system and every AS en route used and provided an IPv4 or IPv6 capability respectively. In the third case, the end system presumably gets both an IPv4 and an IPv6 address, and makes a choice. If it chooses IPv6, it is reported as preferring IPv6. If you select the links
Re: Update to BCP-38?
On 03/10/2019 15:51, Stephen Satchell wrote: > For a start, *add* IPv6 examples in parallel with the IPv4 examples. 1000 times +1 We need (much) more IPv6 examples! -- Marco (pushing for IPv6 examples since 2007 or so like in: https://youtu.be/OLEizGPoB5w?t=30)
Re: Update to BCP-38?
On 10/2/19 9:51 PM, Mark Andrews wrote: > What part of BCP-38 do you think needs to be updated to support IPv6? > > Changing the examples to use IPv6 documentation prefixes instead of IPv4 > documentation prefixes? For a start, *add* IPv6 examples in parallel with the IPv4 examples. As RFCs are peer reviewed, if the examples expose a hole or problem then the hole can be filled or the problem resolved. BCP-38 should be reviewed in whole for "IPv6" completeness, and the preamble of BCP-38 add that the Best Practices include complete recommendations for both IPv4 and IPv6. One specific example: BCP-38 currently references RFC1812, _Requirements for IP Version 4 Routers_. It appears that the only parallel paper for IPv6 is draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which currently carries a copyright of 2018. It's a shame that this document is still in limbo; witness this quote: "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' Someone else mentioned that "IPv6 has been around for 25 years, and why is it taking so long for everyone to adopt it?" I present as evidence the lack of a formally-released requirements RFC for IPv6. It suggests that the "science" of IPv6 is not "settled" yet. That puts the deployment of IPv6 in the category of "experiment" and not "production". Is that really true? There may be more issues. And, yes, I understand that a new BCP paper may result -- I don't care how it's labeled, as long as it's done. Or has such a BCP document already been released? If so, why do I not see any references to it here on NANOG, or anywhere else? Why do I care, you ask. I'm working on a BCP-38 module proposal for firewalld, one that can be peer-reviewed for accuracy and completeness. Servers running that firewall package can then be easily configured to conform to the requirements of BCP-38 and can easily become good net-citizens in their own right. So I call for draft-ietf-v6ops-ipv6rtr-reqs-04 to be finished and released as a formal RFC, and that BCP-38 be updated to refer to that finished RFC. Until that is done, my BCP-38 module will have to carry a "work in progress" disclaimer.
Re: Update to BCP-38?
What part of BCP-38 do you think needs to be updated to support IPv6? Changing the examples to use IPv6 documentation prefixes instead of IPv4 documentation prefixes? Mark > On 3 Oct 2019, at 1:20 pm, Stephen Satchell wrote: > > Is anyone working on an update to include IPv6? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
