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

[Mark Michelson]

On 07/15/2010 06:35 AM, Simon Perreault wrote:
> On 2010-07-15 04:00, Olle E. Johansson wrote:
>    
>> While this may be clever, it will be much harder separating IPv4 and IPv6 addresses. If I want to deny all IPv4 but not IPv6 the syntax will be hard to find out, even though it's possible for IPv4. I can't figure out how you deny all IPv6 addresses this way. We might want to explore adding prefixes just to make the configuration easier to handle and read.
>>
>> deny=ipv4,0.0.0.0
>> deny=ipv6,0::0    ; Just deny all IPv6, but allow IPv4
>>      
> You shouldn't have to specify "ipv4" or "ipv6" in the config file. It's
> easy to distinguish between the two types based on just the address itself.
>
> That said, you may be onto something here. What happens if I say
>
> deny=::/0
>
> Will that also block IPv4 completely?
>
> I don't think it should.
>
> Simon
>    
Thanks for the feedback, guys. You bring up some good points that have 
shown that my instincts do not align with yours.

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.

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?

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?

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?

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 would offer a slight change to the proposed syntax 
though just to ease coding and upgrading. I suggest that after a 
netmask, a user may specify "ipv4" or "ipv6" to indicate that the ACL 
should only be applied to addresses of a specific scheme. Here are some 
examples:

1. deny = 0.0.0.0/0      ;Applies to IPv4 and IPv6 addresses since no 
specifier was added
2. deny = 0.0.0.0/0/ipv4 ;Applies to IPv4 addresses (and perhaps 
IPv4-mapped IPv6 addresses?)
3. deny = 0.0.0.0/0/ipv6 ;Applies only to IPv4-mapped IPv6 addresses. 
Not terribly useful.
4. deny = ::/0           ;Applies to IPv4 and IPv6 addresses since no 
specifier was added
5. deny = ::/0/ipv6      ;Applies only to IPv6 addresses (includes 
IPv4-mapped IPv6 addresses)
6. deny = ::/0/ipv4      ;Applies to IPv4 and IPv4-mapped IPv6 addresses

Let me know what you think about all this, and again, thanks for the 
quick feedback on this.

Mark Michelson