Subject: RE: [mobile-ip] Routing headers: design team recommendation

From: "Jean-Michel COMBES" <[email-masked]>
Date: Wed, 30 Jan 2002 15:39:18 +0100

Hi,

Comments concerning #2 (ie. about firewall and RH).

IMO, there could be two FW policies :
1. Policy based on MIPv6-H@
This case, IMHO ,is the simplest policy  but the most complex to
administrate: the FW checks the last @ in the RH
2. Policy based on MIPv6-Co@
In this case, the FW checks the last address in the RH (ie. RH-@[Segments
Left]). If this is a MIPv6-H@ (ie. not topologically correct), then it
checks the RH-H@[SL-1] and then resolves the case regarding its policy.

Comments are welcome :-)

PS : I am not a FW vendor, so I think it would be better if some FW guys
could give their opinions.

Regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Erik Nordmark
> Envoye : mercredi 23 janvier 2002 21:35
> A : [email-masked]
> Objet : [mobile-ip] Routing headers: design team recommendation
>
>
> The MIPv6 security design team is trying to resolve the issues
> around routing headers as used by MIPv6.
>
> This note specifies the design teams' motivation and current position.
> In order to move forward in an efficient manner it would be beneficial if
> responses could make it clear whether it is
>  - a clarification (by putting CLARIFICATION: in the subject field),
>  - an issue with a particular point (by putting ISSUE: in the
> subject field),
>  - disagreement with the conclusion (by putting CONCLUSION: in
> the subject
>    field)
>
> INTRODUCTION
> ============
>
> There is background information on the security issues around
> MIPv6's use of the routing header in
> draft-savola-ipv6-rh-ha-security-01.txt.
> This note explores how to move forward on the routing header issue.
>
> Today in IPv4, firewalls block IPv4 source routes by default.
> The original motivation for this was that the TCP/IPv4
> implementations reverse
> the source route received in a SYN and use it for the connection.
> This means
> that if source routes are allowed and hosts do any form of access control
> based on the source IP address (such as UNIX r* commands) they could be
> trivially spoofed.
>
> In an IPv6 world the situation is different.
> IPv6 nodes MUST NOT reverse an unauthenticated (with IPsec)
> routing header.
> Thus routing headers can't be used to spoof IP address based
> access control.
> (Of course, this doesn't mean that IP address based
> access control is good security - it is still a bad and grossly
> insufficient
> form of security - but folks might end up doing it when porting
> applications
> from IPv4 to IPv6).
>
> When there is an IPv6 firewall in place and it wants to prevent
> inside node A
> from communication externally (for a subset or all protocols/port
> numbers)
> while allowing inside node B to communicate externally (for those
> protocols/ports) it needs to ensure that a routing header can't
> be used to
> reach node A via node B (where B might be a host or a router).
>
> ALTERNATIVES
> ============
>
> There seem to be three fundamentally different ways to approach this:
> 1. Make the inside nodes (hosts and routers) be "safe" enough in their
>    handling of routing headers that the firewall can avoid
> specific checks
>    on the presence of the routing header as well as the IP
> addresses contained
>    in the RH.
>
> 2. Make the firewall understand the routing headers and filter based on
>    their content.
>
> 3. Try to simplify things by not using Routing Headers for MIPv6
>
> Make RH "safe enough"
> ---------------------
>
> The implications of approach #1 seem to be draconian for other use of
> the routing header.
> Not only can hosts not process routing headers and send the
> packet out (the
> same or a different interface), but internal routers cannot
> process routing
> headers either.
> If a router processes the routing headers then the above A/B
> scenario can be
> used to bypass the firewall policy for host A by source routing
> packets via
> the router B to A.
>
> Thus the implications of #1 are likely to be that all hosts and
> routers must
> not process any routing headers and forward the packet. The only routing
> header  processing that would be allowed would be for a MN to
> process a RH
> where the packet doesn't leave the MN.
>
> Thus in effect routing headers would not be very useful for the initially
> intended purpose; they would only be useful for the MIPv6 usage.
>
>
> Make the firewall RH aware
> --------------------------
>
> When looking at #2 we need to understand what type of filtering a
> firewall would need to have to prevent the A/B bypass while still allowing
> MIPv6 to function.
>
> There are several things needed for MIPv6 to function.
> We need to be able to allow:
> A. CNs inside the firewall need to be able to use RH to send to
> MNs outside
>    the firewall.
> B. "visiting" MNs i.e. MNs who have a Home Address outside the firewall
>     and a CoA inside the firewall.
> C. "local" MNs i.e. MNs where both the HoA and CoA are inside the
> firewall.
>
> [Note that in general allowing A, B, and/or C might be subject to site's
> firewall policy in general. Hence the use of "need to be able to
> allow" above.]
>  A above doesn't cause any problems since allowing outbound RH through
> the firewall doesn't cause problems with the simple rules that A can't
> communicate externally.
> However, if the firewall rules are more complex as in A only being able
> to communicate with a specified external IP address then there are issues
> if that external node is a MN and A would use a routing header
> when sending
> to the MN.
>
> The case B looks like an external entity sending a packet with a
> destination
> being inside the firewall with the subsequent hop (in the RH)
> being outside
> of the firewall.
>
> Possible rules for a firewall to apply in approach #2 for packets
> inbound to the site would be:
> 1. If the destination address is not inside the firewall then
> 	the firewall would presumably drop it
> 2. If there is no RH or an RH with zero elements then
> 	follow non-MIPv6 firewall policy
> 3. If the RH has more then one element then
> 	treat it as a non-MIPv6 routing header (whatever policy
> that is subject
> 	to)
> 4. If one element RH with the address in the RH being external to the site
>    allow it (assuming "visiting" MNs are allowed)
> 5. If one element RH with the address in the RH being internal verify
>    that the address in the RH is allowed to communicate externally with
>    the protocol/port number. If so allow the packet with the RH.
>
> The above firewall rules are somewhat complex and they can't, by the
> very nature of the routing header, prevent source routing.
> For instance, rule #4 means that packets can be source routed through
> the site and back out again, and rule #5 allows some internal
> source routing.
> Thus this approach assumes that there isn't a perception that
> IPv6 firewalls
> need to block actual source routing while allowing the MIPv6 use
> of routing
> headers. There is also a concern that the existing IPv4 firewall behavior
> of blocking source routing might be carried forth into IPv6 firewalls.
> Should this happen there is a failure case where route optimization
> is established through a Binding Update but the data packets, with the RH,
> are dropped. If the CN somehow decides to discard the binding cache entry
> and send through the HA, it is likely that this would anew result in a
> Binding Update.
> Thus if this approach is taken it would seem prudent to make MIPv6 robust
> against packets with RH being discarded.
>
> Define a MIPv6 specific thing instead of using RH
> -------------------------------------------------
>
> An open question is to what extent approach #3 would make things
> significantly
> simpler. The non-RH packet format could be to e.g. define a new
> destination
> option, define a new extension header, define a new routing header type,
> or use IPv6_NO_SRC as specified in
> draft-deering-ipv6-encap-addr-deletion-00.txt.
> The following discussion doesn't assume any particular of the above
> encodings - it just assumes that it is a different encoding than the
> current routing header so that the firewall can have different policies
> for source routing and MIPv6.
>
> For all the encodings it is assumed that the rules are that
> 1) only a single address is contained in the encoding (just like a single
>    element routing header), and
> 2) the receiving node never forwards the packet after processing it.
>
> The encoding that is most consistent with the Home Address Option would
> be to define a destination option carrying the Home Address for the
> destination. This could be name the alternate (or "outer"?
> "upper layer"?) destination address option.
> If this approach is taken it might make sense to rename the Home
> Address Option to have a similar name e.g. the Alternate Source
> Address Option.
>  RECOMMENDATION
> ==============
>
> The design team is leaning towards #3 at the moment. One
> reason for this is that this would remove any suspicion that firewall
> administrators have for the use of the Routing Header and
> which might consequently lead to disabling MIPv6 because of these
> fears. Also, the firewall rules necessary to process the Routing
> Header are complex and accidental disabling of MIPv6 might also
> occur. The use of the Routing Header for other purposes would
> also not be affected. There are also drawbacks in alternative #3.
> One such issue is that existing MIPv6 implementations have to
> be changed. We feel that this drawback is offset by the expected
> wider usability of MIPv6 as a result. This change will also imply
> a substantial document modification for the MIPv6 I-D. This
> does not appear to be a structural change, however, and in
> general we feel that direct procedure is easier to describe than
> attempting to describe some additional rules to constrain the use
> of the Routing Header. Finally, alternative #3 might lead us to
> depend on the external work such as the new tunnel encapsulation
> work at IPNG. The design team feels that we should stay away
> from these non-MIPv6 solutions due schedule issues as well
> as in the interests of making a self-contained RFC.
>
> ---

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 09:47:31 +0100

=> two examples:
 - (theory) the selection of an intermediate ISP, i.e. to go from
   the West coast to the East coast you choose to go through Chicago,
   Saint-Louis, Memphis or New Orleans by a RH with the subnet anycast
   address of the selected ISP.
 - (practice) traceroute6 -g (there are two (not three :-) standard
   applications with IPv6 RH support: traceroute6 and telnet (in order
   to understand the syntax for telnet, you have to read (and sometimes
   to fix) the source.

Regards

[email-masked]

PS: the first usage is potentially critical (BTW is this kind of features
mandatory in the USA since ISPs are regulated as telecom operators?)