[asterisk-dev] [Code Review] Make ACLs IPv6-capable

[Simon Perreault]

On 2010-07-15 09:55, Mark Michelson wrote:
> There were two driving forces behind the way I implemented this. First, 
> my tendency is to lean towards having an ACL err towards denying traffic 
> rather than allowing it. To give an example of what I mean, a common ACL 
> scheme in IPv4-only Asterisk versions is something like:
> 
> deny = 0.0.0.0/0
> *bunch of permit lines for specific IP addresses*
> 
> The idea here is to deny all traffic except for whitelisted addresses. 
> My thought is that on an upgrade, the principle of least surprise would 
> dictate that the whitelisted addresses are still the only ones allowed 
> access even though there is no specific ACL to deny IPv6 addresses. The 
> gist of this is that I decided that, in general, IPv4-specific ACLs 
> should also apply to IPv6 addresses.

This is a good idea, but I think it is not needed. The default bindaddr
is still 0.0.0.0, therefore you need to consciously enable IPv6 when you
want it (e.g. using bindaddr=::). We can expect such a person who
consciously enables IPv6 to also take care of IPv6-enabling its ACLs.

> Now, the second thing that influenced me is IPv4-mapped IPv6 addresses. 
> Consider a simple ACL like:
> 
> deny = 10.0.0.0/8
> 
> Obviously, this should deny all IPv4 traffic from the 10.0.0.0 network. 
> But what happens if you are told the source of a SIP request is 
> ::ffff:10.17.34.211? This is an IPv6 address, so should the above ACL be 
> applied? I would think so, but maybe this isn't what is expected. What 
> do you think?

Yes, it should definitely apply. Any IPv4-mapped IPv6 address that the
ACL code receives as input needs to be converted to an IPv4 address (we
have a function for doing that in netsock2 I think) and treated as such.

> Consider Simon's example ACL of:
> 
> deny=::/0
> 
> First off, my tendency to err on the side of denying traffic leads me to 
> believe everything should be blocked, even IPv4 traffic. But let's go 
> the other way and say that this will only apply to IPv6 addresses. 
> Again, we are told the source of a SIP request is ::ffff:10.17.34.211. 
> This is an IPv6 address, so the ACL should apply, right? But then again, 
> it's an IPv4-mapped address, so maybe it should only be run through IPv4 
> ACLs? Should a user expect the address to be denied or not?

No, the ACL should not apply. An IPv4-mapped IPv6 address is just a
agreed-upon trick between you and the kernel to let you listen on both
IPv4 and IPv6 using a single socket. It has no meaning to the user and
is irrelevant to what's on the wire. You convert the IPv4-mapped IPv6
address to IPv4 and treat it as such.

> Of course, this can apply the opposite way as well. If someone in a very 
> IPv6-centric installation puts an ACL like:
> 
> deny=::ffff:0:0/96
> 
> will this block only IPv4-mapped addresses or will it block IPv4 
> addresses, too?

It will have no effect. From the point of view of the user editing
sip.conf, IPv4-mapped addresses *do not exist*. ACLs only apply to
what's on the wire. And since IPv4-mapped IPv6 addresses cannot exist on
the wire, this ACL will never match anything.

Of course Asterisk could gently output a warning when parsing sip.conf
if it encounters an ACL starting with ::ffff:... and with a netmask >= 96.

> I think Olle may be on the right track in that we can add specifiers to 
> ACLs so that there is no chance of surprise, since it appears that 
> instincts on what traffic will be permitted and denied varies from 
> person to person.

I think this would be very wrong.

ACLs apply to what's on the wire. IPv4-mapped IPv6 addresses are an
implementation detail.

The suggested warning above should address any possible confusion.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org