Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism?

Jean-Michel Combes wrote:
> Hi Alex,
> 
> 2007/12/12, Alexandru Petrescu <alexandru.petrescu@gmail.com>:
>> Jean-Michel Combes wrote:
>>> Hi,
>>> 
>>> 
>>> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5,
>>>  11.4.1
>>> 
>>> OLD TEXT: --
>>> 
>>> NEW TEXT: None
>>> 
>>> Motivations: - Two proposals have been specified and adopted by
>>> the MIP6 WG to allow a MN to get its HA (i.e. bootstrapping
>>> mechanisms for the split and the integrated scenario). - The
>>> present DHAAD mechanism is, more or less, a scanning tool
>>> allowing anyone to know what/where are the HAs owned by a
>>> Mobility Service Provider. - AFAIK, DHAAD has not a critical use
>>> in others MIPv6 based protocols
>>> 
>>> So, I wonder if it is still useful to keep the DHAAD mechanism in
>>> the MIPv6 specification.
>>> 
>>> Comments are welcome.
>> I support keeping DHAAD in the current spec.  If necessary, I can 
>> suggest new clarifying text saying that DHAAD used in conjunction
>> with MPD and a proper IPsec SA setting leads to effective HA
>> address and Home Address bootstrapping on MN while at home and
>> while away from home.
> 
> In your reply, there are 2 points:
> 
> o DHAAD is unsecured

I'm not sure how much insecure it is.  I agree that the semantics of a
anycast address seem less securable than a unicast address (with IPsec.)

> I strongly agree and this is one reason of this thread. There was a
> long discussion, IIRC, at Yokohama about this point but, again IIRC,
> at the moment, DHAAD was the only mechanism for a MN to discover its
> potential HAs. There were drafts about this security issue and
> potential solutions: at first to secure DHAAD
> (draft-dupont-mip6-dhaadharmful) and, later, the MIPv6 bootstrapping
> solution in the split scenario (draft-dupont-ikev2-haassign).

Any address discovery mechanism has an insecurity part in it.  DHCPv6 
has too.

It's not like there's a secure counterpart that we should use instead of 
the insecure DHAAD.

IKEv2 could securely assign the HA and maybe the HoA too, but maybe has 
too many message exchanges.

> o DHAAD as alternative MIPv6 bootstrapping solution That would mean
> to keep a third MIPv6 bootstrapping solution.

I'd call it a 0th :-)

> So, IHMO, I still don't see concrete/critical reasons to keep the 
> DHAAD mechanism in the RFC3775bis.

Ok, let's see.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext