Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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!
>>
>
> 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!

>
>> 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.

>
> 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.

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.

>
>> "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.

>
> 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.

> 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!

>
> 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)

> 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.)

I like Linux, but I don't hold Linux (or any Linux developer) in
veneration. I like Windows, but I don't hold Bill Gates, Balmer or any
Microsoft dev in veneration. I like Android, but I don't hold Google or
any Google employee in veneration. I dislike Macs, but I don't think of
Steve Jobs as evil.

> 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"?

If the latter, I'd agree; there are places you can use IPv6 where it
probably won't make a whole lot of sense (i.e. on an HDMI cable, unless
you have a particular need to provide network traffic to/from your TV).

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.

>
> 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.

The statements you've made that I regarded as trollish where were you
made emotional statements and arguments without anything explanatory to
back them up. In contrast, I've spent *hours* wading through the links
you've thrown at me (without you yourself reading, I suspect), making
point-by-point responses.