> On 03/09/2013 07:53 AM, Kevin Chadwick wrote: > >> "There is no reason to believe that IPv6 will result in an > >> increased use of IPsec." > >> > >> Bull. The biggest barrier to IPsec use has been NAT! If an > >> intermediate router has to rewrite the packet to change the > >> apparent source and/or destination addresses, then the > >> cryptographic signature will show it, and the packet will be > >> correctly identified as having been tampered with! > >>
http://marc.info/?l=openbsd-misc&m=135325641430178&w=2 > > > > It's hardly difficult to get around that now is it. > > Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was > designed from the beginning to allow you to do things like sign your IP > header and encrypt everything else (meaning your UDP, TCP, SCTP or what > have you). > > Setting up a tunnel just so your IP header can be signed wastes another > 40 bytes for every non-fragmented packet. Ask someone trying to use data > in a cellular context how valuable that 40 bytes can be. > > > You are wrong the biggest barrier is that it is not desirable to do > > this as there are many reasons for firewalls to inspect incoming > > packets. I don't agree with things like central virus scanning > > especially by damn ISPs using crappy Huawei hardware, deep inspection > > traffic shaping rather than pure bandwidth usage tracking or active > > IDS myself but I do agree with scrubbing packets. > > It's not the transit network's job to scrub packets. Do your scrubbing > at the VPN endpoint, where the IPSec packets are unwrapped. > > Trusting the transit network to scrub packets is antithetical to the > idea of using security measures to avoid MITM and traffic sniffing > attacks in the first place! > I never said it was. I was more thinking of IPSEC relaying which would be analogous to a VPN end point but without losing the end-end, neither are desirable, NAT has little to do with the lack of IPSEC deployment. What do you gain considering the increased resources, pointlessly increasing chances of cryptanalysis and pointlessly increasing the chances of exploitation due to the fact that the more complex IPSEC itself can have bugs like Openssl does, not to mention amplifying DDOS without the attacker doing anything, which is the biggest and more of a threat than ever, or are you going to stop using the internet. When ipv4 can utilise encryption without limitations including IPSEC but more appropriately like ssh just fine when needed you see it is simply not desirable and a panacea that will not happen. You are simply in a bubble as the IETF were. > > > >> With IPsec, NAT is unnecessary. (You can still use it if you need > >> it...but please try to avoid it!) > >> > > > > Actually it is no problem at all and is far better than some of the > > rubbish ipv6 encourages client apps to do. (See the links I sent in > > the other mail) > > Please read the links before you send them, and make specific references > to the content you want people to look at. I've read and responded to > the links you've offered (which were links to archived messages on > mailing lists, and the messages were opinion pieces with little (if any) > technical material.) > > > > >> Re "DNS support for IPv6" > >> > >> "Increased size of DNS responses due to larger addresses might be > >> exploited for DDos attacks" > >> > >> That's not even significant. Have you looked at the size of DNS > >> responses? The increased size of the address pales in comparison to > >> the amount of other data already stuffed into the packet. > > > > It's been ages since I looked at that link and longer addresses > > would certainly be needed anyway but certainly with DNSSEC again > > concocted by costly unthoughtful and unengaging groups who chose to > > ignore DJB and enable amplification attacks. > > What from DJB did they ignore? I honestly don't know what you're talking > about. > They completely ignored dnscurve.org or that RSA768 was not strong enough to be a good choice and ECDSA should be looked at and most importantly the DOS amplification (we are talking years ago). I even had a discussion with a dns caching tools (that I do like a lot) author who completely dismissed the potential of RSA being broken for years and years. Guess what's come to light since. > > > > His latest on the "DNS security mess" > > > > http://cr.yp.to/talks/2013.02.07/slides.pdf > > I've never before in my life seen someone animate slideshow transitions > and save off intermediate frames as individual PDF pages. That was painful. > Yeah, xpdf worked well though. I actually couldn't find the link and looked it up and thought it was just an update of 2012 as it had the same title and only got around to reading it about an hour later. > So, I read what was discussed there. First, he describes failings of > HTTPSEC. I don't have any problem with what he's talking about there, > honestly; it makes a reasonable amount of sense, considering > intermediate caching servers aren't very common for HTTP traffic, and > HTTPS traffic makes intermediate caching impossible. (unless you've > already got serious security problems by way of a MITM opening.) > > Then he turns around and dedicates two slides showing a DNS delegation > sequence...and then states in a single slide that DNSSEC has all the > same problems as HTTPSEC. > > DNSSEC doesn't have the same problems as HTTPSEC, because almost *every* > recursive resolving DNS server (which is most of the DNS servers on the > Internet) employs caching. > I suggest you read the 2012 slides. > > > >> "An attacker can connect to an IPv4-only network, and forge IPv6 > >> Router Advertisement messages. (*)" > > > >> Again, this depends on them being on the same layer 2 network > >> segment. > > > >> The same class of attacks would be possible for any IPv4 successor > >> that implemented either RAs or DHCP. > > > > Neither of which I use. > > You're telling me you don't use DHCP? Seriously, that you statically > configure the IPv4 addresses of all the hosts on your network? > > With one exception, I haven't personally seen a network configured in > that way since 1998! Certainly, every network has some hosts configured > statically, but virtually no network I've observed (and I've seen > private networks between 2 and 50 hosts, and commercial networks between > 5 and 30k hosts) managed completely statically. > None of my networks for way over a decade have ever employed DHCP and boy am I glad in avoiding many security issues. That was one of the first decisions in network design I made as a teenager. In fact the only networks that do use DHCP by definition are not well cared for such as roaming or tethering a laptop I trust little to my phone which I also trust little and for many good, sorry very bad mobile network reasons. > > > > As I said we would be here all day and that link wasn't as good as > > the one I was actually looking for. > > > > local NAT done right is no problem and actually a good thing and I > > have no issues playing games, running servers or anything else behind > > NAT. > > See others' responses about port standardization, and about how it > enforces a distinction between 'clients' and 'servers' that's > unnecessary (and even harmful) for a variety of applications. > Boy should there be a distinction between clients and servers, without it we would be in a world of pain. However I still atest that there is no problem and far less than what ipv6 advocates. > > Global NAT works well enough > > With global NAT, anything you do that depends on port forwarding is broken. > > > but isn't a good thing and wouldn't exist if they had simply added > > more addresses quickly. The hardware uptake would have been no issue > > rather than a decade of pleads. > > There's almost nothing you've pointed at so far that would have > prevented backbones from IPv6 uptake...and the backbones dragged their > heels long enough. IPv4 with expanded address bits would have been > worse; IPv6 explicitly includes features intended to ease the strain on > the size of a global routing view! > And much more which is the problem and yet still including the bad parts of ipv4 apparently. > > > > We haven't even touched on the code yet and so all the vulnerable > > especially home hardware which yes often has vulnerable sps anyway > > but by no way just home hardware. > > > > The ipvshit links give an insight into the code complexity. > > You call that code complex? (and I still don't know what 'ipvshit' is, > except possibly one guy's pejorative description of IPv6) Think about what it is doing from the comment not the actual code. > > > Note OpenBSDs kernel which is very secure (unlike Linux whose > > primary goal is function) > > I have no complaints about OpenBSD. > > > and has had just a few remote holes in well over a decade, one of > > which was in ipv6 > > So OpenBSD, who you venerate, had a bug in its IPv6 implementation, and > for that you view IPv6 as an abomination? Is that it? (Or is it because > the guy who wrote the buggy code thinks so, and you venerate him? > Because that seems plausible, too.) > You seem to underestimate the gravity or such a bug making it into the OpenBSD kernel. However, not just that, try searching osvdb.org for ipv4 = < 1 page ipv6 = > 3 pages > > and which I had avoided without down time because I won't and what's > > more shouldn't use ipv6 wherever possible > > Do you mean that as "I'll avoid IPv6 as much as possible" or do you mean > that as "I won't use IPv6 in all places where it's possible to use IPv6"? > Former > If the former, I'm afraid I still haven't seen a solid technical case > against it. > > > and had actually removed it from the kernel all together. > > That's sensible; if you're not going to use code, remove it. > You would be surprised, many security books used to say it was a waste of time. I ignored them. > > > > If I am Trolling rather than simply trying to make people aware then > > stating ipv6 is wonderful is Trolling just as much or more. > > IPv6 fixes things about the Internet that are currently broken by IPv4 > address exhaustion. I try to point out where IPv6 fixes things, I try to > clear up popular misconceptions about IPv6, and I try to help people > understand a thing rather than simply fear it. > > If you take a highly competent IPv4 network administrator and drop him > into IPv6 territory without ensuring that he has knowledge of IPv6 best > practices and practical concerns, you're likely to get a broken network > out of it. I try to help keep that from happening. It is more than that. Though I am glad you are reducing the problems out there. IPV6 unarguably is worse than IPV4. You can argue it is also better but where if it is it serves no useful purpose for me that would make me even consider using it unless it is redesigned. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
