IPv6 Advertisements

[William_F_Maton_Sot1]

Should've clarified: this was in the context of IPv4...

To be honest, I'm not sure what the appropriate equivalent would be in IPv6 (/128 or /64? Arguments can be made for both I suppose).

There have been discussions of this sort made over the years. A good place to start would be the old (well, maybe not that old) 6Net site where there's a list of publications called 'Deliverables'. The info is buried in other, but amongst other things it contains deployment scenarios as well as cookbooks decumenting IPv6 deigns and roll-outs, and what they learned from it all. Lot's to read, but good info nonetheless:

   GÉANT

Rgds,
-drc

vixie had a fun discussion about anycast and dns... something about him
being sad/sorry about making everyone have to carry a /24 for f-root
everywhere.

Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.

I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.

However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.

Rgds,
-drc

wfms

[Paul_A_Vixie4]

drc@virtualized.org (David Conrad) writes:

I once suggested that due to the odd nature of the root name server
addresses in the DNS protocol (namely, that they must be hardwired
into every caching resolver out there and thus, are somewhat
difficult to change), the IETF/IAB should designate a bunch of /32s
as "root server addresses" as DNS protocol parameters. ISPs could
then explicitly permit those /32s.

However, the folks I mentioned this to (some root server operators)
felt this would be inappropriate.

as one of the people who told drc that this was a bad idea, i ought to
say that my reason is based on domain name universalism. if root name
service addresses were protocol parameters (fixed everywhere) they'd
be intercepted ("served locally") even more often by local ISP's and
governments for the purpose of overloading the namespace with political
or economic goals in mind. this would be great for local ISP's and
governments with political or economic goals in mind, but bad for the
end users, bad for the community, bad for the internet, and bad for the
world. right now, the people who intercept f-root traffic for fun or
profit could conceivably be in violation of law or treaty, could have
the pleasure of receiving letters from ISC's attorney, and so on. if
root name service addresses were unowned protocol parameters used only
by convention (like port numbers or AS112 server addresses or RFC1918
addresses), then we'd see a far less universal namespace than we do now,
and the coca cola company would probably see far fewer hits at COKE.COM
than they see now.

whether drc's idea is bad depends on what one thinks the internet is.

[Chris_L_Morrow]

what's interesting is some applications on the same platform reacting
differently Safari works 'fine' but mail.app is 'broken' for some
corner cases of v4/v6 naming/capabilities. Iljitsch pointed out mail.app,
I've filed atleast one bug with apple... I'm positive there are others as
well.

[Chris_L_Morrow]

However, you can *always* turn on IPsec with IPv6, which is not always true
for IPv4 (NATs, no end-to-end, etc.).

security is not JUST ipsec, and ipsec is not actually included in all
current ipv6 stacks (merike has some nice slides on this actually).
Security often is related to the applications using the stack, or the
stack itself.

While I agree that in principle ipv6 with ipsec is nice, I've yet to see
it work reliably in the field, and... it's never going to secure your
communications with yahoo.com (maybe not 'never' but not for a very long
time). So, having a sane discussion about 'security' and ipv6 ends up
being: "Hey, you have the same facilities and issues in ipv4, only the
stack is newer and slightly less baked, but if you have protections at
multiple layers you are on the right track."

Also, port scanning is not "so simple", and while in IPv6 a /24 can be
scanned in 5 minutes, a /64 takes 5.3 billion years, and of course, usually
you will have a /48.

This assumes a single machine scanning, not a botnet of 1000 or even the
1.5m the dutch gov't collected 2 yrs ago. Again, a sane discussion is in
order. Scanning isn't AS EASY, but it certainly is still feasible,
especially if you can enumerate the targets with other methods first to
cut down on the random other scanning efforts.

So at the time being, it can be considered a bit more difficult to do a
brute force DoS. Of course, attackers will try some other means, that's why

what?? I can make packets in v6 just as fast as v4... how is it harder
exactly? Given a host connected to gigabit ethernet on a direct native v6
pipe ... packets get made at line-rate... such hosts do exist.

[Don1]

This assumes a single machine scanning, not a botnet of 1000 or even the
1.5m the dutch gov't collected 2 yrs ago.
Again, a sane discussion is in order. Scanning isn't AS EASY, but it certainly is still feasible,

With 1.5 million hosts it will only take 3500 years... for a _single_ /64!

I'm not sure that's what I would call feasible.

-Don

[Dale_W_Carder]

There are "smarter" ways to scan v6 address space than this approach.
My favorite is "First, the attacker may rely on the administrator
conveniently numbering their hosts from [prefix]::1 upward. This
makes scanning trivial."

Take a look at:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-scanning-implications-03.txt

and

http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

Dale

[Don1]

There are "smarter" ways to scan v6 address space than this approach.
My favorite is "First, the attacker may rely on the administrator
conveniently numbering their hosts from [prefix]::1 upward. This
makes scanning trivial."

Most definitely- but not doing that should be considered best practices.

-Don

[Barry_Greene_bgreene]

> This assumes a single machine scanning, not a botnet of
1000 or even
> the 1.5m the dutch gov't collected 2 yrs ago.
> Again, a sane discussion is in order. Scanning isn't AS
EASY, but it
> certainly is still feasible,
With 1.5 million hosts it will only take 3500 years... for a
_single_ /64!

I'm not sure that's what I would call feasible.

I would call that not understanding today's security world. "Scanning"
is not the primary mode of looking for vulnerabilities today. There are
several more effective "come here and get infected" and "click on this
attachment and get infected" techniques.

What scanning that does go on today usually not the "lets scan the
Internet." No money in it. You target your scans to the address ranges
of the sites you are trying to mine (i.e. build BOTNETs) or go after.

[Don1]

I would call that not understanding today's security world. "Scanning"
is not the primary mode of looking for vulnerabilities today. There are
several more effective "come here and get infected" and "click on this
attachment and get infected" techniques.

I'm well aware of the modern security problems. All I said was:
"There is something to be said for not being able to blindly spew worm
traffic and still expect to get a sensible hit ratio as with IPv4."
and I stand behind that statement.

What scanning that does go on today usually not the "lets scan the
Internet." No money in it. You target your scans to the address ranges
of the sites you are trying to mine (i.e. build BOTNETs) or go after.

I'm not sure I understand what you are saying- if you number based on hardware addresses then I have no idea what you mean by "address ranges." The hosts you are trying to compromise could be anywhere in the subnet- that's the 3500 years I was referring to above. That's 3500 years to scan a single /64 subnet- not the entire Internet- not even a tiny little fraction of it.

The problem will be people putting all their ducks in a row, so to speak.

-Don

[Stephen_Sprunk3]

Thus spake "Donald Stahl" <don@calis.blacksun.org>

I'm not sure I understand what you are saying- if you number
based on hardware addresses then I have no idea what you
mean by "address ranges." The hosts you are trying to
compromise could be anywhere in the subnet- that's the 3500
years I was referring to above. That's 3500 years to scan a
single /64 subnet- not the entire Internet- not even a tiny little
fraction of it.

If people use stateless autoconfig, you know what 16 of the bits are, and you can guess 24 of them from a relatively small set. If you're writing a worm that targets residential Wintel users, just scan the OUIs from Dell, HP, etc. Throw in Lenovo if you want to go after business folks. Looking at it another way, you can toss out OUIs from vendors whose gear you know your worm _doesn't_ work on (e.g. Apple, embedded manufacturers, etc.) or only include OUIs for vendors you want to make look bad (e.g. Dell might write a worm that only probes HP machines).

(This is also mentioned in the draft Dale referenced, but I came up with it independently in a few seconds, so I think it falls in the "obvious" category for someone with the sk1llz needed to write a worm.)

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

[Stephen_Sprunk3]

Thus spake "Randy Bush" <randy@psg.com>

small site. so public servers provide multiple and diverse
services. if a hostname has a v6 address, then all services
must be v6 capable because clients do not retry the A record.

This seems to argue for having "service" hostnames, which has been standard practice at many sites for a long, long time. For instance, if you have a single box which does mail and news, and you have v6 mail but only v4 news, then mail.example.com should have both A and AAAA records but news.example.com should have A records only.

(Yes, this means you can't just CNAME the service hostname to the real hostname, but there are several other strategies.)

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov