Subject: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes <[email-masked]>]

From: "mext" <[email-masked]>
Date: Mon, 17 Dec 2007 13:59:52 -0000

#2: Removing DHAAD mechanism [Jean-Michel Combes <[email-masked]>]
-------------------------------------+--------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                   |      Status:  new                    
 Priority:  major                    |   Milestone:                         
Component:  RFC3775 changes          |     Version:                         
 Keywords:                           |  
-------------------------------------+--------------------------------------
 {{{
 OLD TEXT:
 =========

 N/A

 NEW TEXT:
 =========

 N/A

 Motivation:
 ===========

 - 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.
 }}}

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/2>
mext <http://tools.ietf.org/wg/mext/trac/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "mext" <[email-masked]>
Date: Tue, 18 Dec 2007 13:14:19 -0000

#2: Removing DHAAD mechanism [Jean-Michel Combes <[email-masked]>]
--------------------------------------+-------------------------------------
  Reporter:  [email-masked]  |       Owner:  [email-masked]
      Type:  defect                   |      Status:  new                    
  Priority:  major                    |   Milestone:                         
 Component:  RFC3775 changes          |     Version:                         
Resolution:                           |    Keywords:                         
--------------------------------------+-------------------------------------
Comment (by [email-masked]):

 Alexandru Petrescu <[email-masked]> wrote:

 > 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.

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:1>
mext <http://tools.ietf.org/wg/mext/trac/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "mext" <[email-masked]>
Date: Tue, 18 Dec 2007 13:36:06 -0000

---------------------
 George Tsirtsis wrote:
 > 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.
 ---------------------
 Vijay Devarapalli wrote:
 > 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
 ---------------------
 Basavaraj Patil wrote:
 > 3775bis should only be fixing any bugs found and not deprecating or
 > adding new features.
 ---------------------
 Jean-Michel Combes wrote:
 > George Tsirtsis wrote:
 > > I agree with Alex on this. I am not sure we have good justification
 > > 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
 > > 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.
 >
 > So, if these solutions are better, why to keep DHAAD?
 ---------------------

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

 Jean-Michel Combes wrote:
 > Basavaraj Patil wrote:
 > > 3775bis should only be fixing any bugs found and not deprecating or
 > > adding new features.
 > 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.
 ---------------------

 Vijay Devarapalli wrote:
 > Jean-Michel Combes wrote:
 > > 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.
 >
 > I said optional to use. Most implementations I know of have
 > implemented DHAAD.
 >
 > > 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.
 >
 > 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.
 ---------------------

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

 George Tsirtsis wrote:
 > Jean-Michel Combes wrote:
 > > George Tsirtsis wrote:
 > > > I agree with Alex on this. I am not sure we have good
 > > > justification 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)
 > 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" :-)

 ---------------------

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

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:2>
mext <http://tools.ietf.org/wg/mext/trac/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "mext" <[email-masked]>
Date: Tue, 18 Dec 2007 13:14:19 -0000

---

From: "mext" <[email-masked]>
Date: Tue, 18 Dec 2007 13:36:06 -0000

---------------------
 ---------------------
 ---------------------
 ---------------------
 ---------------------

 ---------------------

 ---------------------

 ---------------------

 ---------------------

 ---------------------