IPv6 Security Overview

["Vishwas Manral" <Vishwas@sinett.com>]

Hi,

I went through the "IPv6 security overview" draft. It looked good. I had
the following minor comments on section 2 of the draft: -

1. Section 2.1.1 - "Routing headers can be used to evade access controls
based on destination addresses."

One more problem with Routing Header is it can cause packets to loop.
Assume a case where we have a loop of addresses in the Routing header,
destination A and B. Thus 1 packet sent by a malicious router is
amplified. I think a simple check at a firewall could be to see that the
routing header does not contain the same address more then once, just as
we have a check for the multicast address.

2. Also regarding the point you have made "Routing headers can be used
to evade access controls based on destination addresses."
I think the access control should look at the Final Destination and not
the destination address when a routing header is present.

3. Another thing about routing header is we may not want to process the
header (type 0) in the fast path (hardware) and the packet would
generally be sent for slow-path processing (software) thus overwhelming
the software.

3. Manipulation of "Traffic class" or "Flow Label" field by an
intermediate device by changing the values so that a packet can get
better service can cause legitimate flows not traversing the
intermediate device to be effected(of course if a malicious router is
on-path it can affect the traffic). This means that off-path routers can
affect traffic. Also because AH does not protect the field it is easy to
manipulate (mutable). 

It would have helped if the flow label field was not mutable(and hence
protected by AH) as it is anyway dependent on the source address.

4. Section 2.1.4 - RFC2473 does not specify that we need to check the
tunnel source address is legitimate or not. This can cause any ND packet
to be sent tunneled from multiple hops away, thus making the "Hop Limit"
check not so useful. Below I am attaching a part of the private
discussion I had with Pekka and a few others.
"
> I agree RFC4213 states that, but does it not imply only for 
> IPv6-in-IPv4 and not for IPv6-in-IPv6. Is there a more general check 
> for the same I am missing?

Correct, RFC2473 which specifies v6-in-v6 tunnels did not specify this
(yet) as a requirement.

Hosts aren't vulnerable until they have at least one v6-in-v6 tunnel set
up though." Using SEND resolves the issue anyway.

5. I went through the draft draft-krishnan-ipv6-hopbyhop-00.txt. I think
the attack would be more effective if the router used a multicast
address and we knew that some routers on-path support the option while
others don't. Instead of sending random options which would be dropped
in the first-hop itself and not be amplified.

6. I think when talking about destination options we need to talk about
the 
"Tunnel Encapsulation Limit" option, which is analyzed even along the
way when tunneling, is to be done. We do process the Destination Options
in the intermediate nodes in some cases.

7. It seems the IPv6 spec is unclear about whether if a Fragment header
means the packet is a fragment or if only when the More or fragment
offset field is set is the packet a fragment. ESP/ AH RFC's state that a
packet is a fragment if the fragment header is present. However the SIIT
document states the opposite.


8. Another thing that can be done is basic evasion against firewall. A
simple evasion attack is the IPv6 spec could be that some
implementations for duplicate fragments assume the fragment received
first is kept while some other may assume the one received later is
kept. This can cause basic evasion in case a device is passively
monitoring for attacks.

9. I agree middleboxes including policy boxes rely on fields inside the
header to identify a flow. Even when they are not the end systems. 

However if a middlebox is acting on behalf of a device it needs to look
deeper into the packet.  

10. One more thing about Padding option is that we should have only one
padding option, either 1 instance of PadN or one of Pad1.

11. Having fragments also can cause the packet to go to the slow path
(software rather then hardware), which can cause CPU exhaustion attacks.

Thanks,
Vishwas