On 9/11/2011 7:24 PM, Andrew McMillan wrote:

A classic example I saw was a bunch of folk from some government department showing up at an IPv6 conference in Canberra a few years ago and being told the wireless was IPv6 enabled they hooked up and said "we don't need to worry about this, we just VPN back to the office and our security policy insists that all web browsing happens across the VPN" then they clicked on a link to an IPv6-only website and promptly discovered all of their security was being bypassed, if the website was available on IPv6. Whoops.

They promptly started paying a lot more attention to the conference, and thinking a lot harder about why they needed security policy around IPv6.

I wouldn't be surprised to discover this to be a reasonably common issue for medium-sizeor larger organisations who think "we can ignore IPv6 for now, because we don't need or use it".

Oh yes. This is particularly true in enterprises that are starting the "BYO device" model, where there is no longer a Standard Operating Environment, and IPv6 may be enabled on the device. Other than your anecdote - which I've observed myself, and it makes it easy to continue to use your home printer/other devices when on the corporate VPN - my favorite is split-horizon DNS breaking spectacularly, given that Windows 7 at least will prefer to use IPv6 DNS servers (e.g. "Internet") vs. IPv4 DNS servers ("VPN"), meaning that the VPN comes up but nothing appears to actually work. It's quite interesting how the gradual rollout is breaking things in slightly unanticipated ways, although it does tend to result in people [recommending to] clicking "disable ipv6" :-(.

On Sep 12, 2011, at 12:55 PM, Michael Newbery wrote:

* NAT does not exist. If your application requires NAT (e.g. load balancing) it's broken under IPv6. There is no workaround. This is a feature. NAT is gone. [I found this probably the biggest mind-blow for some people]

NAT <> load-balancing. I dislike both NAT and load-balancers for a lot of reasons, but load-balancing doesn't equate to NAT.

* ICMP is not optional. Blocking ICMPv4 indiscriminately was always a bad idea, now it's a terminal idea.

Concur 100%.

* DHCP is optional. If you think you need DHCP, then re-evaluate very, very carefully.

The current IPv6 DHCP brokenness will eventually be resolved, there's no choice in the matter.

* That best practice of providing reverse DNS entries for all possible addresses on your LAN? Not possible. Gone.

I don't know that this was ever a BCP. Reverse DNS for all *utilized* addresses on your LAN, sure, and it's still possible and recommended for IPv6.

* Reverse DNS as a way of encoding useful information is probably not very useful anymore. Find a better way.

Disagree (see above).

* Address scanning your own LAN to find things? Yeah, no.

Disagree to some degree with regards to hinted scanning (again, see reverse DNS above). Flow telemetry is better. ----------------------------------------------------------------------- Roland Dobbins // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde

On Tue, Sep 13, 2011 at 11:17 AM, Michael Newbery wrote:

The debate is ongoing in the IETF, but the point I'm making is again that security folk make assumptions about things, like DHCP existing, which may not be true in future. For instance, choosing RA rather than DHCPv6 could be a perfectly rational decision for a company to make, which could then be a bit of a shock to security if they are expecting DHCP to always be there.

Choosing RA+random identifiers sounds like a great move for a company who doesn't wish to get involved with NZs new copyright legislation. It effectively puts you in a situation where nobody has "assigned" an IP address to you -- you got the prefix from the ISP, but made up the rest of it yourself. You don't have an IPAP, and you aren't an IPAP yourself; I'm not sure that you're an Account Holder either. Sadly this argument wasn't my idea, but I do like it :-) -jim

On Wed, Sep 14, 2011 at 9:11 AM, Jonathon Exley wrote:

Surely the account holder would be considered to be the prefix owner. Is the legislation so tightly worded so that you have to be an IP address owner?

Well that's what lawyers are for, isn't it? :-) The difference between intention and actual wording ... An IPAP allocates IP addresses. A prefix is not an address. The address is computed from various features of my machine, and is not purposefully and audit-ably allocated by a human. http://www.legislation.govt.nz/act/public/1994/0143/latest/DLM345634.html#DL... is the Copyright Act that has been amended (this is the most useful version to browse, I think) In 122A we find :- “account holder, in relation to an IPAP, means a person who has an account with the IPAP" “IPAP, or Internet protocol address provider, means a person that operates a business that, other than as an incidental feature of its main business activities,— “(a) offers the transmission, routing, and providing of connections for digital online communications, between or among points specified by a user, of material of the user's choosing; and “(b) allocates IP addresses to its account holders; and “(c) charges its account holders for its services; and “(d) is not primarily operated to cater for transient users" So if my address has not been allocated to me by an IPAP, I don't have an IPAP, and I cannot be an account holder. -jim, with fingers crossed, but still on an IPv4 upstream.

The bit in question would then be “(b) allocates IP addresses to its account holders" which I think would be satisfied by allocating a prefix. If I sell you an Internet service and allocate you a /24 IPv4 address block, I am allocating you 256 addresses. If I allocate you a /48 IPv6 prefix, then I am allocating you 2^80 addresses. Jonathon -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Jim Cheetham Sent: Wednesday, 14 September 2011 3:07 p.m. To: NZNOG Subject: Re: [nznog] IPv6 firewall / security experiences On Wed, Sep 14, 2011 at 9:11 AM, Jonathon Exley wrote:

Surely the account holder would be considered to be the prefix owner. Is the legislation so tightly worded so that you have to be an IP address owner?

Well that's what lawyers are for, isn't it? :-) The difference between intention and actual wording ... An IPAP allocates IP addresses. A prefix is not an address. The address is computed from various features of my machine, and is not purposefully and audit-ably allocated by a human. http://www.legislation.govt.nz/act/public/1994/0143/latest/DLM345634.html#DL... is the Copyright Act that has been amended (this is the most useful version to browse, I think) In 122A we find :- “account holder, in relation to an IPAP, means a person who has an account with the IPAP" “IPAP, or Internet protocol address provider, means a person that operates a business that, other than as an incidental feature of its main business activities,— “(a) offers the transmission, routing, and providing of connections for digital online communications, between or among points specified by a user, of material of the user's choosing; and “(b) allocates IP addresses to its account holders; and “(c) charges its account holders for its services; and “(d) is not primarily operated to cater for transient users" So if my address has not been allocated to me by an IPAP, I don't have an IPAP, and I cannot be an account holder. -jim, with fingers crossed, but still on an IPv4 upstream. _______________________________________________ This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).

On 2011-09-12 17:55, Michael Newbery wrote:

On 12/9/11 1:41 PM, "Donald Clark" wrote:

...

All

In the piece of work I'm doing for the IPv6 TaskForce, a recurrent theme has been problems around firewalling / security in general with IPv6. This has raised its head in three variations:

1 - my kit doesn't support it / well 2 - I don't know what v6 policies to turn on, or off / how should I setup rules by range 3 - we don't have any v6 rules (but it may be turned on by default)

Does anyone have any examples of attacks, exposures, policy challenges around v6?

Cheers DC

Well, there is the NIST document, "Guidelines for the Secure Deployment of IPv6"

I have reservations about this document, but it is probably a useful starting point. At least it gets them on the way to understanding what they don't know.

Except that it basically says "block all tunnels unconditionally" which is one of the major operational problems for people whose corporate network doesn't support IPv6. That's a black mark against the NIST, and equivalent US DoD, documents. Brian

Another approach I think might be useful from conversations I've had is in pointing out a few headline adjustments they need to make in their thinking. (Note the statements are somewhat dogmatic, by design. Think of them as IPv6 Koans: mental tools to create a right world-view)

* NAT does not exist. If your application requires NAT (e.g. load balancing) it's broken under IPv6. There is no workaround. This is a feature. NAT is gone. [I found this probably the biggest mind-blow for some people]

* ICMP is not optional. Blocking ICMPv4 indiscriminately was always a bad idea, now it's a terminal idea.

* ARP is gone.

* Multicast is not optional

* An interface WILL have multiple IPv6 addresses

* DHCP is optional. If you think you need DHCP, then re-evaluate very, very carefully.

* That best practice of providing reverse DNS entries for all possible addresses on your LAN? Not possible. Gone.

* Reverse DNS as a way of encoding useful information is probably not very useful anymore. Find a better way.

* Address scanning your own LAN to find things? Yeah, no.