[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPv6 Security Overview
Thanks for the reply. My comments are inline prefixed by a VM>, do let
me know where I am wrong.
From: Francis.Dupont@point6.net [mailto:Francis.Dupont@point6.net]
Sent: Wednesday, January 04, 2006 3:06 PM
To: Vishwas Manral
Subject: Re: IPv6 Security Overview
In your previous mail you wrote:
1. Section 2.1.1 - "Routing headers can be used to evade access
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
destination A and B. Thus 1 packet sent by a malicious router is
=> 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
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
to evade access controls based on destination addresses."
I think the access control should look at the Final Destination and
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
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
header (type 0) in the fast path (hardware) and the packet would
generally be sent for slow-path processing (software) thus
=> 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...
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
affect traffic. Also because AH does not protect the field it is easy
It would have helped if the flow label field was not mutable(and
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
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
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
to be sent tunneled from multiple hops away, thus making the "Hop
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
a problem associated with ND here even I agree the 4 addresses of a
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
"Tunnel Encapsulation Limit" option, which is analyzed even along the
way when tunneling, is to be done. We do process the Destination
in the intermediate nodes in some cases.
=> the TEL is an intermediate destination option, the processing has to
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
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
packet is a fragment if the fragment header is present. However the
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
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
=> 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.