RE: IPv6 Security Overview

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

Hi Francis,

Thanks for the reply. My comments are inline prefixed by a VM>, do let
me know where I am wrong.

-----Original Message-----
From: Francis.Dupont@point6.net [mailto:Francis.Dupont@point6.net] 
Sent: Wednesday, January 04, 2006 3:06 PM
To: Vishwas Manral
Cc: v6ops@ops.ietf.org
Subject: Re: IPv6 Security Overview 

 In your previous mail you wrote:

   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.

=> either we have not the same definition of a loop or the kind of loop
you talk about is not a security problem.

   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.

=> how, the packet is the same, only the addresses and the pointer to
the next address (and of course the TTL/HL) change.

   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.
   
=> 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.

   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.
   
=> it should look at both: this is the issue with headers/options which
introduce multiple source or destination addresses: the simple 2
addresses
ACL is not enough and policies can become complex.
VM> The best condition would be to be able to filter out based on any
field. However based on the current implementation we need to filter on
the final destination. The draft seemed to state that we currently do it
on the destination address in the IPv6 header.

   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.
   
=> there is no reason to go through the slow path for routing headers.
The whole idea of extension headers is to stop the stupid circle:
slow path so not used so no interest to support it in hardware...
VM> Ok.

   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.
   
=> 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
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.

   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.

=> either the tunnel is a link and a ND packet over it is for the tunnel
interface, or it is not a link and a ND packet is out of scope. I can't
see
a problem associated with ND here even I agree the 4 addresses of a
tunneled
packet should be checked (cf RFC 3964 for an example).
VM> I agree we need to put a check for IPv6 in IPv6 tunnels too, just as
we have for others. We however have missed that out.

   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.
   
=> the TEL is an intermediate destination option, the processing has to
be
done in the encapsulator.
VM> Agree, that is what I have been stating too.

   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.
=> we just lack a definition of what is a fragment...
VM> This could be used a simple evasion technique. We have ambiguities
in RFC's itself.
   
   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?

   11. Having fragments also can cause the packet to go to the slow path
   (software rather then hardware), which can cause CPU exhaustion
attacks.
=> 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.

Regards

Francis.Dupont@point6.net