Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01

From: "Ebalard, Arnaud" <[email-masked]>
Date: Thu, 14 Jun 2007 09:45:10 +0200

Hi,

Le 13 juin 07 à 19:53, Rémi Denis-Courmont a écrit :

> Le mercredi 13 juin 2007, Thomas Narten a écrit :
>> To be clear, if even a small fraction of firewalls get deployed that
>> just block all traffic with a RH, MIPv6 breaks and becomes
>> undeployable in practice. For EVERYONE!
>
> The answer to the upcoming question must be obvious to many people  
> here,
> but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your
> network, or does it break both Mobile Nodes *AND* Correspondant Nodes?

When acting as a Correspondent Node, you are aware of the CoA and HoA  
of your peer (MN). Traffic from the CN to the MN is sent to the CoA  
of your peer (as the destination address in the IPv6 header) and  
includes a RH2 carrying the HoA (for the last next hop on the MN).

=> Blocking RH2 breaks CN function.

When acting as a Mobile Node, your HA will send its Binding  
Acknowledgements packets to the CoA (Destination field of the IPv6  
header) and include a RH2 (carrying the HoA of the MN).

=> Blocking RH2 breaks MN function (registration of a new CoA from a  
foreign network).

> In the poor real world of IT, there are some network administrator  
> that
> are responsible for the security of their perimeter. There are seldom
> responsible for new technology not working out of the box. It's a
> truth, we'd rather adapt to, if we can.

At the minimum, when implementing a guest IPv6-enabled network,  
network administrators should have the ability to filter RH2 (and  
Destination Option headers) selectively (i.e. let them flow) and not  
passively undergo blind RH killing by their filtering devices.

I'm wondering if it is possible to do that in Cisco (PIX) or Juniper  
(ScreenOS) based environments ? To what extent ? I'll be interested  
in some feedback, if someone has (*). This could be a starting point  
to defined Best Practices and other SHOULD/MUST rules.

Regards,

a+

(*) off-list / somewhere else if you think it's not the right place  
to discuss that

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------