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

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 11 Dec 2007 14:21:36 +0100

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.

Best regards.

JMC.

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Dec 2007 16:03:43 +0100

Jean-Michel Combes wrote:
> 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
> 

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.

Alex

> 
> Best regards.
> 
> JMC.
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mext
> 

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

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 17 Dec 2007 14:35:28 +0000

I agree with Alex on this. I am not sure we have good justification
for removing DHAAD. The feature is not broken and arguably the
additional bootstraping mechanisms being defined, do not overlap with
it since they are dealing with the case when the HNP is not known to
the MN.

Regards
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 11:09:36 -0800

Hi Jean-Michel,

I don't think we should remove the DHAAD mechanism from 3775bis.
The intention behind revising 3775 is to add clarifications
where ever required and fix bugs. Not to make major changes like
removing or adding features.

The use of DHAAD in RFC 3775 is optional anyway

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 17 Dec 2007 15:51:27 -0600

3775bis should only be fixing any bugs found and not deprecating or adding
new features.

-Raj

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Dec 2007 00:25:08 +0100

Hi George,

2007/12/17, George Tsirtsis <[email-masked]>:
> for removing DHAAD. The feature is not broken

Not broken but:
- unsecured
- a nice tool to scan HAs owned by a Mobility Service Provider (which
are the points of failure of a MIPv6 based service)

> and arguably the

So, if these solutions are better, why to keep DHAAD?

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Dec 2007 00:24:55 +0100

Hi Alex,

> Address bootstrapping on MN while at home and while away from home.

In your reply, there are 2 points:

o DHAAD is unsecured
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).

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

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

Best regards.

JMC.

PS: BTW, I agree that a solution to secure anycast based exchanges is
needed too :)

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Dec 2007 00:25:40 +0100

Hi Vijay and Raj,

DHAAD seems not to be critical for MIPv6 (and the protocols based on
MIPv6 but it would be good to check this), and Vijay confirmed this
point in saying that DHAAD is optional in MIPv6.

Maybe, if the RFC3775bis is a new step in the Standard Track for the
MIPv6 standardization, this would be the right moment to do such
modifications.

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 15:37:02 -0800

> point in saying that DHAAD is optional in MIPv6.

I said optional to use. Most implementations I know of have
implemented DHAAD.

> MIPv6 standardization, this would be the right moment to do such

Dropping features that are not used/implemented is typically done
when a protocol progresses from Proposed Standard to Draft Standard.
We shouldn't do it now.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Dec 2007 01:02:43 +0100

Hi Vijay,

2007/12/18, Vijay Devarapalli <[email-masked]>:
> I said optional to use.

Sorry, yes: s/DHAAD is optional in MIPv6/DHAAD use is optional in MIPv6.

> Most implementations I know of have
> implemented DHAAD.

RH0 is implemented in most IPv6 implementations too but the code
has/will be commented/removed.
My concern is regarding future implementations.

> when a protocol progresses from Proposed Standard to Draft Standard.

I've read again the MEXT charter and I've just seen that RFC3775bis
will be submitted as PS. I must admit, I've missed this _important_
point.

Best regards.

JMC.

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 18 Dec 2007 08:19:12 +0000

Another thing to do maybe would be to add text to the security section
indicating what the security issues with DHAAD might be. I see what
you are saying wrt HA scanning but that may not always be a problem
e.g., for private HAs behind firewalls.

Again my understanding of the guidelines for the revision is that "if
it is not broken, do not fix it" :-)

Regards
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Dec 2007 10:00:43 +0100

Jean-Michel Combes wrote:
>>> 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.
>> 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.
> 

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 :-)

> DHAAD mechanism in the RFC3775bis.

Ok, let's see.

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 28 Dec 2007 16:47:18 +0100

Hi George,

2007/12/18, George Tsirtsis <[email-masked]>:
> indicating what the security issues with DHAAD might be.

Good idea :)
I will submit some text when I will come back from vacations.

> I see what

Do you mean you filter and you allow only DHAAD requests from some MNs
and you block all the others requests?
But in this case, how will you set up the firewalls policy (i.e. based
on which IP address?)?

Best regards and happy new year.

JMC.