On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco@ns.sol.net> wrote:
However, that's not the only potential use! A client that initiates each new outbound connection from a different IP address is doing something Really Good.
No, Joe, it is not doing anything Good. This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. Every additional person who is expressing concern to their vendors brings us closer to a solution. In addition, if the machine can choose another random IPv6 address in the /64 for each new outgoing connection, it could just as easily source all its outgoing connections from ... a single IPv6 address that does not accept any incoming connections. I will grant that this does not prevent "magic packet" attacks against bugs in the machine in kernel space, and that the machine could be the recipient of a DoS attack; but your proposed solution has no advantage in the case of, say, SQL Slammer 6, or other attacks exploiting vulnerabilities in user-space. On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong <owen@delong.com> wrote:
Is there any reason we really need to care what size other people use for their Point to Point links?
Personally, I think /64 works just fine.
I won't criticize anyone for using it. It's what I choose to use.
You should care what size you choose, Owen. I would if I was your customer. There are several reasons why. If you configure a /64 on a point-to-point interface e.g. SONET, some current platforms will bounce any "scan" packets back and forth between the two hosts until the TTL expires, which means an attacker can saturate the point-to-point link with two orders of magnitude less attack traffic than the link capacity. This is very bad. Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem. This may be a per-interface issue on your box, or it may be a global one. In the per-interface case, most likely, the failure mode will be okay; but some vendors (including Juniper?) will eventually expire the ARP/NDP entry even though there is active traffic, and may be unable to re-learn it when needed due to the attack, which would break the link between routers. On the other hand, if it's a global issue, it will break NDP on the entire router, affecting all interfaces by whatever the platform's failure mode is. Obviously, that is worse. This is why "RFC compliant" is wrong, Owen. That a learned, experienced person such as yourself has no clue what the underlying problem is exemplifies my point: much, much more noise needs to be made about this issue. A lot of smart people have known about it for years but nothing is being done. Anyone can choose not to use /64 on their point-to-point links with no consequence to their business. Customers aren't going to choose another vendor because they are likely never even aware of it. The operational problem is that customers will want it on the PE/CE LANs, hosting center LANs, and so on; and right now, if you tell them "we can't do that," they have trouble believing you because the standard says otherwise, and a lot of other networks are currently doing it (because they think they don't have a choice other than to lose potential customers.) However, if you are running /64 instead of something like /124 on your VLANs or SONET circuits between routers, you should change this practice as soon as practical. Not doing so once you have been educated about this problem because it is "the standard" is very stupid. Pretty much every major transit network has figured this out and are doing it on their interfaces to BGP customers, too, either optionally, by default, or as the only choice. The industry standard must change to be non-hostile toward choosing a smaller subnet size than /64 to give coverage to those of us who do understand what we are doing as we roll out IPv6 to customers. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco@ns.sol.net> wrote:
However, that's not the only potential use! =A0A client that initiates each new outbound connection from a different IP address is doing something Really Good.
No, Joe, it is not doing anything Good. =A0This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. =A0I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. =A0Every additional person who is expressing concern to their vendors brings us closer to a solution.
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years. A bunch of clever people have worked on things like 4941, people at places like IBM and Microsoft, people who created actual working implementations of these things. A bunch of experienced people have discussed the operational ins and outs. Including myself. We realize that there are both good and bad aspects to pretty much any issue. I certainly said so about this one. I view IPv6 as a mostly-done deal; no major changes are likely to happen. Too many parties have too much invested in all of this. I'm sorry that you missed out on all of that. But. Calling it "my" idiocy? "Facepalm" graphic? Brilliant discussion technique. If you can't discuss this on the merits and concede that there are other valid points of view, please hang up and go bother someone else. I hear Jim Fleming's available. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
Very smart people can and do come up with bad ideas, and IPv6 is a textbook example of this phenomenon, heh. I certainly bear my share of the responsibility for this state of affairs by not getting involved, and leaving the heavy lifting to others.
Calling it "my" idiocy? "Facepalm" graphic?
Concur 100% - I respectfully disagree with you on substantial aspects of the IPv6 situation, and am in substantive agreement with Jeff on most aspects which have been discussed on this thread - but you're *far* from an idiot, heh. You're also entirely correct that we need to ensure that our passions and mutual frustrations don't lead us into ad hominem attacks; security is an area which attracts people of a passionate bent, and it's important that we don't end up in a pointless flame-war. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 5, 2011 at 10:36 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
Very smart people can and do come up with bad ideas, and IPv6 is a textbook example of this phenomenon, heh. I certainly bear my share of the responsibility for this state of affairs by not getting involved, and leaving the heavy lifting to others.
As someone who has been immersed in security for many years now, and having previously been very intimately involved in the network ops community for equally many years, I have to agree with Roland here. Just because a lot of smart people have worked on IPv6 for many years does not mean that the security issues have been equally well thought out. I see this as very similar to all IP technology evolution issues -- none of which ever really focused on the dedicated attacker/criminal using the same technology to attack/defraud/hijack/etc. This is not meant as a slight to anyone -- just a realization of looking at security from a real-world perspective. It seems to always have to get "bolted on" as an afterthought, instead of baked-in from the beginning. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNJWVcq1pz9mNUZTMRAtimAJ4xWmqbP4Or5KFnonDW8XtOMMvMjgCcCswk 9JDJXNyDgUV4RnZlfDcBges= =KKZ+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On 1/6/11 1:47 AM, Paul Ferguson wrote:
As someone who has been immersed in security for many years now, and having previously been very intimately involved in the network ops community for equally many years, I have to agree with Roland here. Just because a lot of smart people have worked on IPv6 for many years does not mean that the security issues have been equally well thought out.
...
This is not meant as a slight to anyone -- just a realization of looking at security from a real-world perspective. It seems to always have to get "bolted on" as an afterthought, instead of baked-in from the beginning.
I've not read everything in this thread yet. So, this may have already been mentioned. But Security *was* baked-in from the beginning of IPv6. IT WAS TAKEN OUT! I was one of the original IPng PIPE->SIP->SIPP->IPv6 designers. We knew about *all* of these problems mentioned thus far in this thread. IPsec was originally designed for SIP->SIPP->IPv6, and I back-ported it to IPv4 after IPv6 was hijacked by committee. As to Neighbor Discovery, the original specifications eliminated ARP, DHCP, and OSPF, *and* routers knew all hosts on the local net, *and* both hosts and routers automatically renumbered. Everything that folks have asked for thus far. Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. I've not found my -04, -05, or -06 on-line, so I've occasionally been looking through old backups lately as time allows. Sadly, those systems are long dead, and finding actual systems to read my old data makes the recovery process rather slow. Anyway, don't blame the original designers. We knew what we were doing! Blame the vendors (and their lackeys) that had vested interests in making IPv6 into IPv4 with bigger addresses, and *removing* security.
On 1/6/2011 2:47 PM, William Allen Simpson wrote:
Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. I've not found my -04, -05, or -06 on-line, so I've occasionally been looking through old backups lately as time allows. Sadly, those systems are long dead, and finding actual systems to read my old data makes the recovery process rather slow.
" When a host or router needs the location of a target host on the local media, it sends a media multicast solicitation for the location of the host, followed by a media multicast of the original data packet. The target node issues an advertisement which indicates its current reachability. " Umm, so it sends a data packet to everyone instead of waiting and sending a unicast packet? Seems rather insecure if that packet wasn't encrypted, not to mention noisy. In addition, I'd hate to see what happens when more than one packet arrives prior to the target node's advertisement being received. Contrary to my last email (where I didn't consider mobile devices and similar which do have memory restrictions), I agree with the as-needed basis, except for routers. A router should have all necessary information and not just as-needed. One could argue that routers can't process that much data, but given the trends I've seen in IOS and other vendors of refreshing arp every 10s or less, I'm pretty sure they can handle it. To streamline the process and since we are using multicast, hosts can just tell the router multicast address who they are to quickly update all local router ND caches, and could just as easily expire an address from the cache. The usual options we use for securing ARP could still apply in this scenario. Jack
On 1/5/11 10:36 PM, Dobbins, Roland wrote:
On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
Very smart people can and do come up with bad ideas, and IPv6 is a textbook example of this phenomenon, heh. I certainly bear my share of the responsibility for this state of affairs by not getting involved, and leaving the heavy lifting to others.
The reason for standing on the shoulders of giants should not be to piss on them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 5, 2011 at 11:46 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 1/5/11 10:36 PM, Dobbins, Roland wrote:
On Jan 6, 2011, at 1:26 PM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
Very smart people can and do come up with bad ideas, and IPv6 is a textbook example of this phenomenon, heh. I certainly bear my share of the responsibility for this state of affairs by not getting involved, and leaving the heavy lifting to others.
The reason for standing on the shoulders of giants should not be to piss on them.
I sense an unnecessary level of acrimony here. No one is pissing on the work done by the many folks who have spent many years hashing out v6 work. But I think you are missing a larger point -- much of the security community has been summarily dismissed in its concerns along the way. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNJXTUq1pz9mNUZTMRAs9BAKDh1N+BJFgmbROPSIOf+rM5v+Ol1ACbBfcr qXiMOvfkjLtTaQX55I+Sc2U= =aFv3 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On 1/6/2011 12:26 AM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
NDP should have been better designed. It still has the same problems we had with ARP except the address pool has magnified it. Routers should have 1) better methods for keeping ND tables low (and maintaining only valid entries) or 2) better methods for learning valid entries than unsolicited NDP requests. This isn't to say the protocol itself is a waste, but it should have taken in the concerns and developed the mitigation controls necessary as recommendations to the implementers. Jack
Perhaps we're reaching the point where we can say "We don't need an ND table for a /64 network". If the ethernet MAC is embedded in the IPv6 address, we don't need to discover it because we already know it. If the IPv6 address has been manually configured on a host, perhaps that host should now accept traffic directed to the MAC that the lower 64 bits of the IPv6 address would translate to. Perhaps this idea has been discussed somewhere and discarded for its flaws, but if not, perhaps it should be :-). Marcel (First post by the way, go easy on me :-) On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates <jbates@brightok.net> wrote:
On 1/6/2011 12:26 AM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
NDP should have been better designed. It still has the same problems we had with ARP except the address pool has magnified it.
Routers should have 1) better methods for keeping ND tables low (and maintaining only valid entries) or 2) better methods for learning valid entries than unsolicited NDP requests.
This isn't to say the protocol itself is a waste, but it should have taken in the concerns and developed the mitigation controls necessary as recommendations to the implementers.
Jack
On 1/6/2011 9:37 AM, Marcel Plug wrote:
Perhaps we're reaching the point where we can say "We don't need an ND table for a /64 network". If the ethernet MAC is embedded in the IPv6 address, we don't need to discover it because we already know it. If the IPv6 address has been manually configured on a host, perhaps that host should now accept traffic directed to the MAC that the lower 64 bits of the IPv6 address would translate to.
Perhaps this idea has been discussed somewhere and discarded for its flaws, but if not, perhaps it should be :-).
The table itself is fine. I fully support it. The method for generating such a table within a router (separate from standard hosts who only generate tables for who they need to talk to, and unless you allowed forged packets in from remote, shouldn't have an issue) is what is in questions. See my other posts. There have been many implementations, mostly for security reasons, but also helping with this problem by implementing a "router MUST NOT send unsolicited arp requests". It's important that routers learn their table in another fashion. Jack
On Thursday, January 06, 2011 10:51:27 am Jack Bates wrote:
There have been many implementations, mostly for security reasons, but also helping with this problem by implementing a "router MUST NOT send unsolicited arp requests". It's important that routers learn their table in another fashion.
Yeah, that's more succinct than what I said, but I think you're saying the same thing.
This would break dead-neighbor detection, but, I'm not sure that's necessarily a problem for end hosts at the local router level. It is touted as one of the IPv6 features, but, I'm not sure how valuable it is as a feature. Owen On Jan 6, 2011, at 7:37 AM, Marcel Plug wrote:
Perhaps we're reaching the point where we can say "We don't need an ND table for a /64 network". If the ethernet MAC is embedded in the IPv6 address, we don't need to discover it because we already know it. If the IPv6 address has been manually configured on a host, perhaps that host should now accept traffic directed to the MAC that the lower 64 bits of the IPv6 address would translate to.
Perhaps this idea has been discussed somewhere and discarded for its flaws, but if not, perhaps it should be :-).
Marcel
(First post by the way, go easy on me :-)
On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates <jbates@brightok.net> wrote:
On 1/6/2011 12:26 AM, Joe Greco wrote:
A bunch of very smart people have worked on IPv6 for a very long time, and justification for /64's was hashed out at extended length over the period of years.
NDP should have been better designed. It still has the same problems we had with ARP except the address pool has magnified it.
Routers should have 1) better methods for keeping ND tables low (and maintaining only valid entries) or 2) better methods for learning valid entries than unsolicited NDP requests.
This isn't to say the protocol itself is a waste, but it should have taken in the concerns and developed the mitigation controls necessary as recommendations to the implementers.
Jack
participants (10)
-
Dobbins, Roland -
Jack Bates -
Jeff Wheeler -
Joe Greco -
Joel Jaeggli -
Lamar Owen -
Marcel Plug -
Owen DeLong -
Paul Ferguson -
William Allen Simpson