Subject: IPv6 Security Overview

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 4 Jan 2006 00:59:59 -0800

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 5 Jan 2006 21:19:45 -0800

Hi Francis,

=> I am sorry to have to say that but I don't believe we should change
protocols to make the life of middleboxes better, i.e., middleboxes
have to adapt, not the opposite. And here I say middleboxes because
fragments are transparent for routers (i.e., a lot of fragments or
a lot of packets are the same thing for a router).

Routers also do basic load balancing (ECMP) based on deeper packet
inspection, this is where things can be affected (ACL's etc). I agree to
what you say above. However I think we are doing a security analysis of
the protocol and hence noting down the possible places where we can have
issues.

The draft also talks about issues with overusing "Router Alert option"
or having excessive "hop-by-hop" options; it does not however mean we
are removing the options totally or putting a limit on it (Seemed to me
that way from the spirit of the draft, the authors could probably
clarify).

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 06, 2006 4:02 AM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: IPv6 Security Overview 

    In your previous mail you wrote:
   
   => I don't think it matters.
   VM> I agree the TTL/ Hop Limit changes etc. However by keeping
address
   alternating i.e. Address [2x] = A, Address [2x+1] = B for x = 1 to n,
we
   make a packet transit the same router n times, thus increasing the
load
   on a router. It is a simple amplification attack.
   
=> it is a low order attack against an intermediate slow link when
the real issue is bad security policies (bad = not prepared to see
packets following strange routes).

   => as AH is no more used this is an academic discussion. I do not
think
   so.
   VM> I agree AH has been downgraded to a MAY in RFC4301. However one
   point I can think of is that AH is more amenable to middleboxes than
ESP
   authentication only service. I am not sure if we can say AH is no
more

=> just ask IPsec people.

   used, we just had an RFC4302 for the same. I also think that AH
should
   take care that Flow Label, however that is an IPsec(and backward
   compatibility) discussion.
   
=> it was an IPsec discussion and backward compatibility won.

      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.
   => this is not so clear: PadN can be a nice hidden channel.
   VM> We should not allow multiple Pad1 or PadN options. Is there
   something I am missing?
   
=> yes, people want to be free to use Pad1 and PadN as they believe it
is the best. BTW adding a constraint here shall kill compatibility.

   => do you mean we should forbid fragments for any transport which has
   its own segmentation (i.e., not UDP)?
   VM> We are talking about security issues. I am just listing that
having
   too many fragments can cause state exhaustion in middleboxes as well
as
   other routers which send fragments to slow path along the way. We are
   not giving a solution here in my view.
   
=> I am sorry to have to say that but I don't believe we should change
protocols to make the life of middleboxes better, i.e., middleboxes
have to adapt, not the opposite. And here I say middleboxes because
fragments are transparent for routers (i.e., a lot of fragments or
a lot of packets are the same thing for a router).

Regards
   
[email-masked]