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

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2008 11:04:36 -0700

Hi,

A few comments.

Jean-Michel Combes wrote:

> NEW TEXT:
> 15.5.  Dynamic Home Agent Address Discovery
> 
>    The dynamic home agent address discovery function could be used to
>    learn the addresses of home agents in the home network.
> 
>    The ability to learn addresses of nodes may be useful to attackers
>    because brute-force scanning of the address space is not practical
>    with IPv6.  Thus, they could benefit from any means which make
>    mapping the networks easier.  For example, if a security threat
>    targeted at routers or even home agents is discovered, having a
>    simple ICMP mechanism to easily find out possible targets may prove
>    to be an additional (though minor) security risk.
> 
>    Furthermore, it is impossible to authenticate a DHAAD request: the
> HA doesn't know who is behind the CoA used as source address in the
> request and the destination address is an anycast type address,
> forbidding the use of IKE/IPsec.

Replace the above paragraph by

    Dynamic home agent address discovery messages are not authenticated.
    Therefore the home agent does not know the identify of the user which
    requested the list of home agents.

>    At last, it is important to remember that the DHAAD mechanism is
> ICMP based and that many ISPs are blocking such type of messages
> today.

Does this belong in the security considerations section? This is
more of a deployment issue, right?

>    Apart from discovering the address(es) of home agents, attackers will
>    not be able to learn much from this information, and mobile nodes
>    cannot be tricked into using wrong home agents, as all other
>    communication with the home agents is secure.
> 
>    Nevertheless, it is strongly recommended to use the mechanisms
> specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD
> mechanism.

Note that DNS lookup for the HA does not really let the network
to identify the user before providing with a list of home agents.
So it is not more secure.

Vijay

> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Section, sub-section and paragraph involved: 18.2
> 
> OLD TEXT:
> ....
> 
> NEW TEXT (to add):
> 
> [Boot-Integrated]
> Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated
> Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
> progress), July 2007.
> [Boot-Split]
> Giaretta et. al., "Mobile IPv6 bootstrapping in split scenario.", RFC
> 5026, October 2007.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Comments are welcome :)
> 
> Best regards.
> 
> JMC.
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Mar 2008 19:28:12 +0100

Vijay Devarapalli wrote:
>> NEW TEXT: 15.5.  Dynamic Home Agent Address Discovery
>> 
>>  HA doesn't know who is behind the CoA used as source address in
>> the request and the destination address is an anycast type address,
>  Therefore the home agent does not know the identify of the user
> which requested the list of home agents.
> 
> Does this belong in the security considerations section? This is more
>  of a deployment issue, right?
> 
>> Apart from discovering the address(es) of home agents, attackers 
>> will not be able to learn much from this information, and mobile 
>> nodes cannot be tricked into using wrong home agents, as all other
>> specified in [Boot-Integrated] and [Boot-Split] instead of the 
>> DHAAD mechanism.
> 
> Note that DNS lookup for the HA does not really let the network to 
> identify the user before providing with a list of home agents. So it 
> is not more secure.

I agree.  I also wanted to say that the security risk which is imposed
on DHAAD because of using anycast address in Request is same risk
present in the DHCP steps prior to being able to query the DNS (also
present in the SLAAC).

I wanted to avoid a loop like this: discard DHAAD because insecure, then
design a new bootstrapping tool just as insecure.

Alex

>> OLD TEXT: ....
>> [Boot-Integrated] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping 
>> for the Integrated Scenario", 
>> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress),
>>  July 2007. [Boot-Split] Giaretta et. al., "Mobile IPv6 
>> bootstrapping in split scenario.", RFC 5026, October 2007.
>> 
>> _______________________________________________ MEXT mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mext
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.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 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 13 Mar 2008 20:44:45 +0100

Hi Vijay,

>     requested the list of home agents.

OK but, IMHO, it would be better to replace "are not authenticated" by
"cannot be authenticated".

> Does this belong in the security considerations section?

Yes.

> This is

Maybe, but I think this is important to recall this.

>  So it is not more secure.

I agree. That was why I was supporting, during the MIPv6 bootstrapping
mechanisms specification, solutions like the draft
<draft-dupont-ikev2-haassign> allowing to increase the security of
the HA discovery (i.e. HA assignment) .. but this is out of scope this
thread :)

Best regards.

JMC.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Mar 2008 12:55:42 -0700

Hello,

One very short comment:

> "cannot be authenticated".
But this isn't true -- of course they can be authenticated.  For instance,
there could be a shared group key or any one of a dozen other schemes
not defined within RFC 3775.

I guess you would have to just say that RFC 3775 does not specify
any authentication mechanisms.
Regards,
Charlie P.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 13 Mar 2008 20:58:44 +0100

Hi Alexandru,

>  design a new bootstrapping tool just as insecure.

But these tools already exist and have been specified because DHAAD
was not the right mechanism to bootstrap MIPv6.

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 13 Mar 2008 21:01:46 +0100

Hi Charlie,

Yes, you are right.

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Mar 2008 23:52:13 +0100

Hi Jean-Michel,

> was not the right mechanism to bootstrap MIPv6.

Are they more secure than DHAAD?

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 00:03:14 +0100

Anything is more secure than DHAAD because there is no way to secure
a mechanism based on anycasts. About DNS it is possible using DNSSEC
to sign the announce part so a MN could not go to a fake HA. But
by definition the DNS accepts any MN from anywhere almost the same way,
so it is not a good solution in all cases (for instance it is not
when the MN tries to find HAs on the link/network).

Thanks

[email-masked]

PS: DHAAD should be obsoleted ASAP only for this terrible name!
PPS: what happens to the assignment by IKEv2 proposal?
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 14 Mar 2008 00:11:34 +0100

Hi Alexandru,

>  >>  > Jean-Michel Combes wrote:

[snip]

> Are they more secure than DHAAD?

Today, I think:
o Split solution
- Only one HA address is recorded in the DNS
- Use after the RFC 5142 to do load balancing
o Integrated
- Security based on AAA

Tomorrow, I hope:
o Split solution
- The address in the DNS is an anycast one
- The possibility to use anycast with IPsec

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2008 00:17:56 +0100

Francis Dupont wrote:
> to sign the announce part so a MN could not go to a fake HA.

How does MN securely get the address of the DNS server?

> But by definition the DNS accepts any MN from anywhere almost the 
> same way, so it is not a good solution in all cases (for instance it
>  is not when the MN tries to find HAs on the link/network).

Right, attacks are possible both ways.

> PS: DHAAD should be obsoleted ASAP only for this terrible name!

Call it ODAD (for "Obsoleted DhAaD") :-)

> PPS: what happens to the assignment by IKEv2 proposal?

I don't know :-)

Would one embark on that endeavour only to find out a few years later
that IKEv2 is probably too many message exchanges and needs to be 
obsoleted use something lighter, like for example DHAAD?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2008 00:20:31 +0100

> - Only one HA address is recorded in the DNS

How does the MN securely get the address of the DNS server?

> - Use after the RFC 5142 to do load balancing

How does the MN securely get the address of the AAA server?

> - The possibility to use anycast with IPsec

How will the MN securely obtain the DNS Server's address tomorrow?

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 00:25:23 +0100

In your previous mail you wrote:

=> it does not matter: with DNSSEC a fake DNS server can only do
a basic denial of service. And nothing prevents the MN to use
its preferred well known DNS server.

   
=> I don't understand your comment: DNSSEC (and many other mechanisms)
provides some security on the server side.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 00:30:59 +0100

Tomorrow, I hope:
   o Split solution
   
=> IMHO it is impossible as anycast is one in a group so you don't know
which member of the group will receive the next packet. And something
shared between more than two is no more a secret.

Thanks

PS: and don't forget RFC 2782 for HA selection via DNS.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2008 00:42:04 +0100

Francis Dupont wrote:
> => it does not matter: with DNSSEC a fake DNS server can only do a
> basic denial of service. And nothing prevents the MN to use its
> preferred well known DNS server.

'Preferred'?  Like having been pre-configured on the MN together with
the necessary keys?

>> same way, so it is not a good solution in all cases (for instance
>> it is not when the MN tries to find HAs on the link/network).
> 
> => I don't understand your comment: DNSSEC (and many other
> mechanisms) provides some security on the server side.

MN must have the address of the DNS Server in order to make resolutions.
  If it doesn't have it then it has to discover it.  Securely.  Until it
is secure attacks between MNs and DNS Servers are possible both ways.

I think DNSSEC you may be mentioning does not address this.  I'm
thinking of DNSSEC as something to do with the way DNS Servers securely
talk to each other.  But you add 'many other mechanisms', so not sure
we're seeing same aspects.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 03:12:11 +0100

In your previous mail you wrote:

   > And nothing prevents the MN to use its
   
   'Preferred'?

=> yes, in the sense the server you prefer to use.

   Like having been pre-configured on the MN together with
   the necessary keys?
   
=> what keys???

=> I believe you have no idea about how the DNS works. You just need
the address of a server, if you know nothing there is nowhere to send
something. And this has nothing to do with mobility.

=> yes, the only place where attacks are perhaps impossible is the
node itself. You should power it down to be sure...

   talk to each other.

=> you are simply fully wrong.

   But you add 'many other mechanisms', so not sure we're seeing same aspects.
   
=> there are many other mechanisms and nearly all are far more secure
than DHAAD. For instance AAA can do the job and provides some uniq
security properties (authentication/authorization of the CoA for instance).
   
Thanks

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2008 04:16:39 +0100

Francis, I'll try to cool down a bit, I'm not trying to prove anything
with this discussion.  It's just a technical perspective I'm pondering over.

I perfectly understand that there are many important scenarios valid for
the existing bootstrapping work - RFC5026.

I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is
  not offering a method that is more secure than DHAAD.  It just
relegates the security question to DNS, away from the IPsec-anycast
question; and does not address how is the DNS Server's address learned
securely, it's simply silent about it.

For clarity: I don't mean I want that clarified.  I just say how things
are.  If the RFC5026's customers are satisfied with the way it is then
nothing have I to say.

Francis Dupont wrote:
>> And nothing prevents the MN to use its preferred well known DNS 
>> server.
> 
> 'Preferred'?
> 

If a MN can have a preferred DNS server then why not having a preferred
HA as well.  No need to discover it then.

> Like having been pre-configured on the MN together with the necessary
>  keys?
> 
> => what keys???

Like MH-HA keys, not needing to discover HA address.

>  the address of a server, if you know nothing there is nowhere to
> send something. And this has nothing to do with mobility.

I thought a MN not knowing DNS Server's address would want to discover
it.  A discovery mechanism would be prone to same risks as DHAAD is.

> If it doesn't have it then it has to discover it.  Securely.  Until 
> it is secure attacks between MNs and DNS Servers are possible both 
> ways.
> 
> thinking of DNSSEC as something to do with the way DNS Servers 
> securely talk to each other.
> 

er?

> security properties (authentication/authorization of the CoA for 

I think relying MIP6 on AAA reduces MIP6's proven capability to run
inter-domain to running intra-domain.

So that said, please don't take me wrong, and you're right :-)

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 14 Mar 2008 04:22:57 +0100

> How will the MN securely obtain the DNS Server's address tomorrow?

I think you missed my point.I agree it is important to secure the
information provided to the MN but, AFAIK, this is already done in the
specification of the MIPv6 bootstrapping mechanisms. My concern is
about here the security of the MSP and DHAAD is not adapted for such a
security (cf. the reasons I cited before).

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 14 Mar 2008 04:37:52 +0100

Hi Alex,

2008/3/14, Alexandru Petrescu <[email-masked]>:
>  HA as well.

Because:
- DNS is (generally) a public resource
- HA is owned by the MSP and this one should have the last word
regarding which HA it wants to provide to a MN.

Best regards.

JMC.

>  No need to discover it then.
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 14:37:05 +0100

It's just a technical perspective I'm pondering over.
   
=> so can I expect something technically sound from you?

   I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is
   not offering a method that is more secure than DHAAD.

=> I disagree: this offers methods which are or can be made more secure
than DHAAD and BTW offers new capabilities like HA assignment too.

   It just relegates the security question to DNS, away from the IPsec-anycast
   question; and does not address how is the DNS Server's address learned
   securely, it's simply silent about it.
   
=> it is simply silent because you question does not make sense, nor
your "*the* DNS Server" term.

   are.

=> but as they are not how you say I still disagree.

   
=> a node can have a preferred DNS server because some people don't like
to rely on a local DNS server. This is only a fact, and this has nothing
to do with mobility (and BTW I can see this more frequently with ADSL/Cable
ISPs and fixed nodes :-).

=> what are these MH-HA keys? You refer to statically configured IPsec??

=> this is not true because all service discovery used in this case
are local so can't be attacked from outside (BTW in IPv4 the standard
is DHCPv4, for IPv6 you have LLMNR & co, stateless DHCPv6, etc).

   er?
   
=> well, please read anything about DNSSEC...

=> I don't think so as AAA has an architecture but I agree to rely
on AAA obviously narrows available environments (I don't think so
we can get more security for free :-).

Regards

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 14 Mar 2008 09:40:15 -0400

Could you please stop assuming that the HA is deployed by an MSP? HAs
can also be deployed in corporates and home networks. IMO, DHAAD is
usable in such cases while the DNS based solution is more appropriate
in the maybe more common MSP scenario.

In any case the task at hand is to figure out what to do with DHAAD in
RFC3775bis.

I think during the meeting it was clear that the feature has been
implemented and it is supported by HAs. I think it was also agreed
that some tightening of the applicability of this mechanism would be
useful in RFC3775bis, but removal of the feature does not seem to be
warranted.

Do people agree that DHAAD is at least useful in some scenarios and it
is to leave it in the RFC if we clarify its applicability?

Regards
George

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 14 Mar 2008 15:10:06 +0100

Hi George,

>  useful in RFC3775bis, but removal of the feature does not seem to be

I agree and my intention was to provide text about the recommendation
to use Split and Integrated MIPv6 boostrapping mechanisms rather than
DHAAD.

>  is to leave it in the RFC if we clarify its applicability?

DHAAD has to be kept in the RFC because, as far as I understood,
3775bis stays to PS status and so no features can be removed from the
specification.

Best regards.

JMC.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 16 Mar 2008 09:26:50 -0700

> is to leave it in the RFC if we clarify its applicability?

Yes. As I said at the MIC, we have this feature in our release and
we cannot just take this out. We can add few lines on the security
issues around this mechanism and add an applicabilty note. Beyond that,
I do not agree taking this feature out.

Thanks
Sri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 13:55:39 +0100

Folks,

We need to wrap up this thread. As of now it seems we have consensus on 
modifying the security considerations section as below. Please let us 
know if you think this is a wrong interpretation of the discussion that 
happened so far.

-- julien & marcelo, MEXT chairs

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

OLD TEXT:

NEW TEXT:

*  This document does not define any authentication mechanism for 
*  dynamic home agent address discovery messages. Therefore the home
*  agent does not know the identify of the user that requested the list
*  of home agents.

*  Finally, it is important to remember that the DHAAD mechanism is 
*  based on ICMP and that many ISPs are blocking such type of messages
*  today.

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

On Thursday 13 March 2008, Jean-Michel Combes wrote:
> >  > OK but, IMHO, it would be better to replace "are not
> >  > authenticated" by "cannot be authenticated".
> >
> > But this isn't true -- of course they can be authenticated.  For
> > instance, there could be a shared group key or any one of a dozen
> > other schemes not defined within RFC 3775.
> >

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 18 Mar 2008 10:38:59 -0400

Hi Julien,

May I propose a slightly modified wording for the last addition?

 *  Finally, it should be noted that the DHAAD mechanism is
 *  based on ICMP and as such, it will not work in networks that are
configured to block ICMP messages.

George

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Mar 2008 16:24:47 +0100

Hi,

I think a part of the text at the end is missing;
  "Nevertheless, it is strongly recommended to use the mechanisms
specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD
mechanism."

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Mar 2008 16:27:50 +0100

Hi,

OK for me.

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 16:31:43 +0100

> -- julien & marcelo, MEXT chairs

By rfc4877 "ESP encapsulation of the ICMPv6 messages related to mobile
prefix discovery MUST be supported and SHOULD be used."

DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user requesting
the list of the home agents, provided MN and HA hold shared keys.

For IPsec and anycast problems there's a good old reading 2001
draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt saying "Even with manual
keying, IPsec trust model with anycast address is confusing.  As IPsec
uses IPv6 destination address to identify which IPsec key to be used, we
need to use the same IPsec key for all of the anycast destinations that
share an anycast address." which lays the problem and proposes the
solution at the same time.

Since this reference is outdated: (1) there may be other document
discussing IPsec and anycast?  Anbybody knows? and (2) is there any
other issue with IPsec and anycast I'm not aware of?  and (3) should we 
add a reference to that draft?

> *  based on ICMP and that many ISPs are blocking such type of messages

I agree with George implying DHAAD doesn't work on networks not 
supporting ICMPv6.  MIP6 doesn't work on networks not supporting MIP6. 
RFC5026 doesn't work on networks not supporting RFC5026 and so on.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 17:12:12 +0100

> specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD

Jean-Michel,

I interpreted the quoted discussion between you and Vijay below

> > >    Nevertheless, it is strongly recommended to use the
> > > mechanisms specified in [Boot-Integrated] and [Boot-Split]
> > > instead of the DHAAD > mechanism.
> >
> >
> I agree. That was why I was supporting, during the MIPv6
> bootstrapping mechanisms specification, solutions like the draft
> the HA discovery (i.e. HA assignment) .. but this is out of scope
> this thread :)

as you agreeing that a DNS lookup "as is", as specified by bootstrapping 
procedures isn't more secure than DHAAD, and therefore I removed the 
offending paragraph. Isn't that okay with you?

--julien

> >  We need to wrap up this thread. As of now it seems we have
> > consensus on modifying the security considerations section as
> > below. Please let us know if you think this is a wrong
> > interpretation of the discussion that happened so far.
> >
> >     The dynamic home agent address discovery function could be used
> > to learn the addresses of home agents in the home network.
> >
> >     The ability to learn addresses of nodes may be useful to
> > attackers because brute-force scanning of the address space is not
> > practical with IPv6.  Thus, they could benefit from any means which
> > make mapping the networks easier.  For example, if a security
> > threat targeted at routers or even home agents is discovered,
> > having a simple ICMP mechanism to easily find out possible targets
> > may prove to be an additional (though minor) security risk.
> >
> >     Apart from discovering the address(es) of home agents,
> > attackers will not be able to learn much from this information, and
> > mobile nodes cannot be tricked into using wrong home agents, as all
> > other communication with the home agents is secure.
> >
> >  NEW TEXT:
> >
> >     The dynamic home agent address discovery function could be used
> > to learn the addresses of home agents in the home network.
> >
> >     The ability to learn addresses of nodes may be useful to
> > attackers because brute-force scanning of the address space is not
> > practical with IPv6.  Thus, they could benefit from any means which
> > make mapping the networks easier.  For example, if a security
> > threat targeted at routers or even home agents is discovered,
> > having a simple ICMP mechanism to easily find out possible targets
> > may prove to be an additional (though minor) security risk.
> >
> >  *  dynamic home agent address discovery messages. Therefore the
> > home *  agent does not know the identify of the user that requested
> > the list *  of home agents.
> >
> >     Apart from discovering the address(es) of home agents,
> > attackers will not be able to learn much from this information, and
> > mobile nodes cannot be tricked into using wrong home agents, as all
> > other communication with the home agents is secure.
> >
> >  *  Finally, it is important to remember that the DHAAD mechanism
> > is *  based on ICMP and that many ISPs are blocking such type of
> > messages *  today.
> >
> > 
> >  > > But this isn't true -- of course they can be authenticated. 
> >  > > For instance, there could be a shared group key or any one of
> >  > > a dozen other schemes not defined within RFC 3775.
> >  > >
> >  > >  I guess you would have to just say that RFC 3775 does not
> >  > > specify any authentication mechanisms.
> >  > >  Regards,
> >  > >  Charlie P.
> >  >

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 17:27:24 +0100

Alex,

On Tuesday 18 March 2008, Alexandru Petrescu wrote:
> > *  home agent does not know the identify of the user that requested
> > *  the list of home agents.
>
> By rfc4877 "ESP encapsulation of the ICMPv6 messages related to
> mobile prefix discovery MUST be supported and SHOULD be used."
>
> DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user
> requesting the list of the home agents, provided MN and HA hold
> shared keys.

The proposed text states that "the document does not define any 
authentication mechanism for dynamic home agent address discovery 
messages" which is true. In then goes on by concluding "Therefore the 
home agent does not know the identity of the user that requested the 
list of home agents" which is also true since you cannot know the 
identity without authentication.

Therefore, I don't understand what you disagree with. Or maybe you don't 
disagree...

And yes, MPD and DHAAD are too different things, thus I don't understand 
why you refer to MPD in the first place.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 17:28:25 +0100

Jean-Michel Combes wrote:
> Hi,
> 
> I think a part of the text at the end is missing; "Nevertheless, it 
> is strongly recommended to use the mechanisms specified in 
> [Boot-Integrated] and [Boot-Split] instead of the DHAAD mechanism."

I'm not sure we can strongly recommend using RFC5206 (split
bootstrapping) instead of DHAAD.  I don't find any reasonable basis
for this.

I understand DHAAD is considered insecure because of the anycast
addressing (DHAAD Request dst field contains an anycast address).

RFC5026 is insecure in the DNS discovery phase.  RFC5026 says  "The
Mobile Node needs to obtain the IP address of a DNS server before it can
send a DNS request.  This can be configured on the Mobile Node or
obtained through DHCPv6 from the visited link [14] [DNS Configuration
options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC
3646]".

Initial DHCPv6 phases (DHCPv6 Solicit) is as much insecure as DHAAD
Request.  DHCPv6 Solicit is sent to a multicast address, and it has same
IPsec issues as DHAAD Request.

Pre-configuring the address of the DNS Server on the MN has the same
load-balancing problems as pre-configuring the HA address on the MN:
namely an operator can't load balance the MN among several DNS Servers.

Pre-configuring the address of the DNS Server on the MN has the same
security needs as pre-configuring the address of HA: need to pre-share
keys on MN and on HA.

That's why I'm not sure we can recommend strongly rfc5026 instead of dhaad.

But I think we can say that some deployments prefer rfc5026 bootstrapping.

Alex

>> *  This document does not define any authentication mechanism for *
>>  dynamic home agent address discovery messages. Therefore the home
>> * agent does not know the identify of the user that requested the 
>> list *  of home agents.
>> 
>>  *  based on ICMP and that many ISPs are blocking such type of 
>> messages *  today.
>> 
>>>> instance, there could be a shared group key or any one of a 
>>>> dozen other schemes not defined within RFC 3775.
>>>> 
>>>> specify any authentication mechanisms. Regards, Charlie P.
>>>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 17:30:31 +0100

On Tuesday 18 March 2008, George Tsirtsis wrote:
>  *  configured to block ICMP messages.

Hi George, your text reads better and it makes sense to use it. The 
update should look as below:

OLD TEXT:

NEW TEXT:

*  This document does not define any authentication mechanism for 
*  dynamic home agent address discovery messages. Therefore the home
*  agent does not know the identity of the user that requested the list
*  of home agents.

*  Finally, it should be noted that the DHAAD mechanism is
*  based on ICMP and as such, it will not work in networks that are
*  configured to block ICMP messages.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 17:46:13 +0100

Julien Laganier wrote:
>>> *  home agent does not know the identify of the user that 
>>> requested *  the list of home agents.
> messages" which is true.

I agree.

> In then goes on by concluding "Therefore the home agent does not know
>  the identity of the user that requested the list of home agents" 
> which is also true since you cannot know the identity without 
> authentication.

But, generally, HA does know the identity of the MNs, at least by RO
tests and moreover by IPsec shared keys.  Using IPsec shared keys there
still may be a problem, but because the MN wouldn't know the identity of
the HA (the HA address is anycast, whereas the MN address is unicast),
and not because HA does not know the id of the user.

Besides why talking users here, we should be talking MNs.  USers makes
think of NAI and AAA and we don't treat that here.

I'm also suggesting referring to a existing IPsec anycast draft or rfc
or similar discussion.

Because, for example, RFC4301 "Security Architecture for IP" does not
prohibit Security Associations to hold multicast addresses, and gives
guidance about how it should be implemented.

> Therefore, I don't understand what you disagree with. Or maybe you 
> don't disagree...

I disagree to one saying HA doesn't know the identity of the user.  I
think you meant MN not user.  And thus I think HA does know the identity
of the MN.

> And yes, MPD and DHAAD are too different things, thus I don't 
> understand why you refer to MPD in the first place.

I referred to MPD to bring in the IPsec shared keys that may exist
between MN and HA.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 17:51:15 +0100

Would you be satisfied with s/user/MN ? i.e.:

*  This document does not define any authentication mechanism for
*  dynamic home agent address discovery messages. Therefore the 
*  home agent does not know the identity of the MN that requested 
*  the list of home agents.

--julien

> > In then goes on by concluding "Therefore the home agent does not
> > know the identity of the user that requested the list of home
> > agents" which is also true since you cannot know the identity
> > without authentication.
>
> tests and moreover by IPsec shared keys.  Using IPsec shared keys
> there still may be a problem, but because the MN wouldn't know the
> identity of the HA (the HA address is anycast, whereas the MN address
> is unicast), and not because HA does not know the id of the user.
>
> Besides why talking users here, we should be talking MNs.  USers
> makes think of NAI and AAA and we don't treat that here.
>
> I'm also suggesting referring to a existing IPsec anycast draft or
> rfc or similar discussion.
>
> think you meant MN not user.  And thus I think HA does know the
> identity of the MN.
>
> _____________________________________________________________________
>_ This email has been scanned by the MessageLabs Email Security
> System. For more information please visit
> http://www.messagelabs.com/email

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Mar 2008 18:16:55 +0100

Hi Julien,

>  offending paragraph. Isn't that okay with you?

The agreement was about the identification of the user and not the
overall security :)

Now, as I explained in a previous email, it is always possible to only
put one HA address in the DNS and to use HA switch [RFC5142]: that
will allow to keep a sort of privacy for a pool of HAs managed by a
same administrator.

On the other side (i.e. the MN side), as explained in the "Security
Considerations" section of the split bootstrapping mechanism
[RFC5026], to ensure the MN will receive "correct" information (i.e.
integrity of the information), when the HA address discovery is DNS
based, DNSSEC may be used , and when the HA address discovery is DHCP
based, usual security with DHCP may be used (e.g. Authentication for
DHCP Messages [RFC3118]).

Finally, as said in RFC 3775, in section 5.3, "No security is required
for dynamic home agent address discovery." and so there is no
"official"/standardized mechanism today to provide security if this
one is needed.

That's why, _today_, IMHO, DHAAD is less secure than the Split and the
Integrated mechanisms and the RFC3775 should recommend to use these
latest rather than DHAAD.

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 18:19:23 +0100

> *  the list of home agents.

You mean HA doesn't know the CoA of the MN?  I agree.

But I don't see any problem with that, exactly as http servers don't 
know the address of the requesters yet they deliver the pages.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 18:26:32 +0100

Just fyi rfc3775 already says:
> The Source Address of the Home Agent Address Discovery Request 
> message packet is typically one of the mobile node's current care-of 
> addresses.  At the time of performing this dynamic home agent address
>  discovery procedure, it is likely that the mobile node is not 
> registered with any home agent.  Therefore, neither the nature of the
>  address nor the identity of the mobile node can be established at 
> this time.  The home agent MUST then return the Home Agent Address 
> Discovery Reply message directly to the Source Address chosen by the 
> mobile node.

Just fyi,

Alex

Alexandru Petrescu wrote:
>> dynamic home agent address discovery messages. Therefore the * home
>> agent does not know the identity of the MN that requested *  the 
>> list of home agents.
> 
>  This email has been scanned by the MessageLabs Email Security

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 19:54:43 +0100

Julien I mainly agree with the intent of clarifying about DHAAD.  To
that end, how about this:

> communication with the home agents is secure.

Add below:

This is a threat perceived when considering Home Agents are legitimate
(the Home Agents on a home link may not want to reveal their addresses
to arbitrary remote nodes, never present on the home link).  The
protection against these attacks, if deemed necessary, is to use IPsec
[xx].  The way IPsec is used with DHAAD is outside the scope of this
document.

How about this?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 21:21:18 +0100

Hi Jean-Michel, Julien, please allow some remarks in this thread.

Jean-Michel Combes wrote:
>>> I think a part of the text at the end is missing; "Nevertheless,
>>> it is strongly recommended to use the mechanisms specified in
>>>>  to identify the user before providing with a list of home
>>>> agents. So it is not more secure.
>>> 
>>> <draft-dupont-ikev2-haassign> allowing to increase the security
>>> of the HA discovery (i.e. HA assignment) .. but this is out of
>>> scope this thread :)
>> 
>> as you agreeing that a DNS lookup "as is", as specified by
>> bootstrapping procedures isn't more secure than DHAAD, and
>> therefore I removed the offending paragraph. Isn't that okay with
>> you?
> 
> Now, as I explained in a previous email, it is always possible to
> only put one HA address in the DNS and to use HA switch [RFC5142]:
> that will allow to keep a sort of privacy for a pool of HAs managed
> by a same administrator.
> 

I haven't seen implementations of RFC3118 "Authentication for DHCP
Messages".  But from reading the RFC it seems the recommended way to
share keys between DHCP Client and Server is to have a common secret
Master Key.  I think this can't work inter-domain (DHCP Server in a 
visited domain to have Master Keys known by an arbitrary MN visiting 
that domain).

It can work in a closed domain - yes, but not across domains.

Another question on RFC3118: I haven't seen it implemented, and not for
DHCPv6.  Has one seen an implementation of RFC3118 for DHCPv6?  I'd like
to have a look at it.

Please feel free to correct me where I'm wrong, I often doubt things.

> Finally, as said in RFC 3775, in section 5.3, "No security is
> required for dynamic home agent address discovery." and so there is
> no "official"/standardized mechanism today to provide security if
> this one is needed.

I think there's no DHAAD implementation assuring against all risks
involved during bootstrapping inter-domain.

I think RFC5026 (DHCP-DNS-based split-bootstrapping) may ensure more
security during bootstrapping, but it is not inter-domain.

Thus I'm not sure we can recommend DHCP-DNS-based split bootstrapping 
for MIP6 which is inter-domain.

> That's why, _today_, IMHO, DHAAD is less secure than the Split and
> the Integrated mechanisms and the RFC3775 should recommend to use
> these latest rather than DHAAD.

IMHO DHAAD is as secure as split-bootstrapping DHCPv6 learning of the
DNS Server's address (RFC5026).

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 17:48:16 -0700

> configured to block ICMP messages.

I wonder if this sentence belongs in the security considertions
section. Anyway, isn't the above sentence stating the obvious?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 17:52:11 -0700

> [xx].  The way IPsec is used with DHAAD is outside the scope of this

Using IPsec with anycast addresses is not straight forward. And
I don't expect someone to use IPsec with DHAAD messages either.
So I think we should not add the above paragraph.

Vijay

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 19 Mar 2008 10:27:57 +0800

Hi,

Permit me to make a small comment. 

=8==8<=8==
> attackers will
[Ben] Since you mention that DHAAD will not work in some networks, I think
it might be better to suggest the use of other mechnisams to find
address(es) of home agents in such networks. Hence, I propose the following
to be added.

"In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to
discover the address(es) of the home agents"

Regards,
Benjamin Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Mar 2008 11:09:01 +0100

Vijay Devarapalli wrote:
>>> attackers because brute-force scanning of the address space is 
>>> not practical with IPv6.  Thus, they could benefit from any means
>>>  which make mapping the networks easier.  For example, if a 
>>> security threat targeted at routers or even home agents is 
>>> discovered, having a simple ICMP mechanism to easily find out 
>>> possible targets may prove to be an additional (though minor) 
>>> security risk.
>>> 
>>> nodes cannot be tricked into using wrong home agents, as all 
>> This is a threat perceived when considering Home Agents are 
>> legitimate (the Home Agents on a home link may not want to reveal 
>> their addresses to arbitrary remote nodes, never present on the 
>> home link).  The protection against these attacks, if deemed 
>> necessary, is to use IPsec [xx].  The way IPsec is used with DHAAD 
>> is outside the scope of this document.
> 
> Using IPsec with anycast addresses is not straight forward.

Well I think it is straightforward.  Nothing in IPsec prevents the use
of anycast.  Besides, the IP Security Architecture RFC gives specific
advice on the use of IPsec with multicast, which semantically is very close.

What one may find difficult is the use use of IPsec for bootstrapping,
and I agree it is not straightforward to use IPsec when the address of
the destination is about to be discovered.

But this is true for _any_ bootstrapping mechanism, RFC5026 included.
And it is also true DHAAD is not used exclusively for bootstrapping.

Also, when DHAAD is _not_ used for bootstrapping DHAAD Request _could_
be improved to include the DO HoA and thus easily secured by IPsec.  If
DHAAD  _is_ used for bootstrapping then that DO HoA could contain a
constant reserved address and the AH containing a MAC hashed from it and
from a shared key (MN1 and HA share key1, MN2 and HA share key2, etc.)
This is nothing extraordinary.  But it is indeed a work not done in RFC3775.

What do you think?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2008 08:21:36 -0700

> discover the address(es) of the home agents"

I think we need to make changes in 3775 to point to the bootstrapping
work thats been done. 3775 assumes the mobile node is configured with
the home prefix. We probably have to add text there. I don't think we
should add this text in the security considerations section for DHAAD. :)

I will open an separate issue for that.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2008 08:28:58 -0700

> This is nothing extraordinary.  But it is indeed a work not done in 

I don't think we would be making changes or enhancements to DHAAD
in 3775bis. So it is better to leave it at recognizing that DHAAD
messages are not authenticated, and the home agent does not know
the identity of the user/MN before sending the list of home agents.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Mar 2008 16:43:41 +0100

Vijay Devarapalli wrote:
>> Well I think it is straightforward.  Nothing in IPsec prevents the
>> use of anycast.  Besides, the IP Security Architecture RFC gives
>> specific advice on the use of IPsec with multicast, which
>> semantically is very close.
>> 
>> What one may find difficult is the use use of IPsec for
>> bootstrapping, and I agree it is not straightforward to use IPsec
>> when the address of the destination is about to be discovered.
>> 
>> But this is true for _any_ bootstrapping mechanism, RFC5026
>> included. And it is also true DHAAD is not used exclusively for
>> bootstrapping.
>> 
>> Also, when DHAAD is _not_ used for bootstrapping DHAAD Request
>> _could_ be improved to include the DO HoA and thus easily secured
>> by IPsec.  If DHAAD  _is_ used for bootstrapping then that DO HoA
>> could contain a constant reserved address and the AH containing a
>> MAC hashed from it and from a shared key (MN1 and HA share key1,
>> MN2 and HA share key2, etc.) This is nothing extraordinary.  But it
>> is indeed a work not done in RFC3775.
>> 
>> What do you think?
> 
> I don't think we would be making changes or enhancements to DHAAD in
> 3775bis. So it is better to leave it at recognizing that DHAAD 
> messages are not authenticated, and the home agent does not know the
> identity of the user/MN before sending the list of home agents.

I agree for 3775bis, leave it there, and don't go any further
recommending anything else to address that aspect.

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 19 Mar 2008 18:49:11 +0100

Hi Alex,

>  >> is outside the scope of this document.

This text looks like Neighbor Discovery security text in the RFC 2461
sometime ago but there were more details how to use IPsec with ND :)

>  of anycast.

No clear specification today about this and this is the problem, IMHO.
Now, DHAAD may use a specification which exists today: RFC 3514,
section 5 for IPv6 use :p

> Besides, the IP Security Architecture RFC gives specific

A bull is very close to an ox, you know. But personally, I will not
attempt to walk in a field if I cannot recognize whether there are
bulls or oxes :)

More seriously, if for you it seems it is possible to use, in an easy
way, IPsec with anycast address, I will be very interested to see (and
to work on) a document about this.

>  And it is also true DHAAD is not used exclusively for bootstrapping.

What are the others uses with DHAAD?

>  be improved to include the DO HoA and thus easily secured by IPsec.

DO == Destination Option?

Best regards.

JMC.

>  If

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Mar 2008 19:23:21 +0100

Hi Jean-Michel,

Jean-Michel Combes wrote:
>>>> Julien I mainly agree with the intent of clarifying about 
>>>> DHAAD. To that end, how about this:
>>>> 
>>>> OLD:
>>>>> The dynamic home agent address discovery function could be 
>>>>> used to learn the addresses of home agents in the home 
>>>>> network.
>>>>> 
>>>>> attackers because brute-force scanning of the address space 
>>>>> is not practical with IPv6.  Thus, they could benefit from 
>>>>> any means which make mapping the networks easier.  For 
>>>>> example, if a security threat targeted at routers or even 
>>>>> home agents is discovered, having a simple ICMP mechanism to 
>>>>> easily find out possible targets may prove to be an 
>>>>> additional (though minor) security risk.
>>>>> 
>>>>> attackers will not be able to learn much from this 
>>>>> information, and mobile nodes cannot be tricked into using 
>>>>> wrong home agents, as all other communication with the home 
>>>>> agents is secure.
>>>> 
>>>> Add below:
>>>> 
>>>> legitimate (the Home Agents on a home link may not want to 
>>>> reveal their addresses to arbitrary remote nodes, never present
>>>>  on the home link).  The protection against these attacks, if 
>>>> deemed necessary, is to use IPsec [xx].  The way IPsec is used 
>>>> with DHAAD is outside the scope of this document.
> 
Sounds so to many I believe, I like its sound :-)

>> use of anycast.
> No clear specification today about this and this is the problem, 
> IMHO. Now, DHAAD may use a specification which exists today: RFC 
> 3514, section 5 for IPv6 use :p

RFC3514 April's Fool "The Security Flag in the IPv4 HEader" haha :-)

>> Besides, the IP Security Architecture RFC gives specific advice on 
>> the use of IPsec with multicast, which semantically is very close.
> 

Haha :-) At least make sure you don't wear something Red :-)

>  way, IPsec with anycast address, I will be very interested to see 
> (and to work on) a document about this.

You could work it out and I review it :-)

> What are the others uses with DHAAD?

For example, just to discover the current address of the HA, among
several addresses of HAs on the home link.  Or discover which of the HAs
on the home link supports Mobile Routers.

>> by IPsec.

YEs, sorry, Destination Option Extension Header after the IPv6 Base
Header and before the ICMPv6 header, something like this:

Base-AH-DO-ICMPv6

The SA on MN would hold (HoA - anycastHA - key) triplets and the SA on
HA would also hold (HoA - anycastHA - key) triplets.  All HAs on the
home link would hold same SAdb Security Association database.  The IPsec 
code on HA would replace the anycastHA src address in the DHAAD Reply 
with its own unicastHA address after the SAdb check and right before 
sending the packet to driver. (widely available MIP6 linux code already 
substitutes the HoA from DO to the dst address, so it could also 
substitute these unicast for anycast addresses in the HA).

If the MN doesn't yet know its own HoA then IANA-define a constant
address 'JMC' and it will still work, because the HA and MN trust each
other because of these pre-shared keys in the SAdbs, when checking the 
hashes out of the AH headers (for dynamically generated keys see Francis :-)

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 19 Mar 2008 19:40:41 +0100

Hi Vijay,

2008/3/19, Vijay Devarapalli <[email-masked]>:
>  work thats been done.

Agree. That was one of my concern in the text I provided initially.
But, my main reason to integrate such referencies in the security
considerations section was when you want to secure exchanges: there is
no specified solution today with DHAAD which is not the case with the
RFC 5026.

*********************************************************************************************************
OLD proposed TEXT:
Nevertheless, it is strongly recommended to use the mechanisms
specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD
mechanism.

NEW proposed TEXT:
In cases where security is needed, it is advisable to consider the use
of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in conjunction
with security mechanisms suggested in these specifications, instead of
the DHAAD mechanism.
*********************************************************************************************************

Comments?

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2008 12:27:05 -0700

> no specified solution today with DHAAD which is not the case with the

The security considerations is not the right place to introduce this.
Lets leave the DHAAD section alone. Just point the issue with sending
a list of home agents without authenticating the user and stop there.

Vijay

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 20 Mar 2008 08:52:25 +0000

I like the new proposed text better. JMC can you put together the
complete new proposed text so we can take a look at it...I think I
have lost track of some of the changes.

Thanks
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 11:40:31 +0100

George Tsirtsis wrote:
> Thanks George
>>>> [Ben] Since you mention that DHAAD will not work in some
>>>> networks, I think it might be better to suggest the use of
>>>> other mechnisams to find address(es) of home agents in such
>>>> networks. Hence, I propose the following to be added.
>>>> 
>>>> "In such networks, the MN SHOULD employ other mechanisms (e.g.
>>>> DNS query) to discover the address(es) of the home agents"
>>> 
>>> 
>>> I think we need to make changes in 3775 to point to the
>>> bootstrapping work thats been done.
>> 
>> considerations section was when you want to secure exchanges: there
>> is no specified solution today with DHAAD which is not the case
>> with the RFC 5026.
>> 
>> NEW proposed TEXT: In cases where security is needed, it is
>> advisable to consider the use of MIPv6 bootstrapping
>> [Boot-Integrated] [Boot-Split], in conjunction with security
>> mechanisms suggested in these specifications, instead of the DHAAD
>> mechanism.

Additionally, would one acknowledge in the NEW propsed TEXT the security
weaknesses of [Boot-Split], as discussed here on the MIP6 mailing list,
namely the lack of security during the discovery phase of the address of
the DNS Server (DHCPv6).

Alex

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 20 Mar 2008 10:42:46 +0000

Passing judgment on another RFC sounds like a bad idea to me. The
split scenario RFC already includes a security considerations section.

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 14:08:21 +0100

> split scenario RFC already includes a security considerations 

This is what people do when discarding DHAAD: passing judgment on
rfc3775 - it's claimed rfc3775's dhaad is insecure whereas rfc5026 is no
more secure than dhaad.

I'm writing so many emails on dhaad topic because this is only one
particular topic where recently it seems more and more suggestions are
made to change more and more rfc3775:

-home link detection
-bootstrapping
-pointotopoint links

All these features are answered and tested in a certain way by rfc3775
implementations.  However people either ignore these or prefer to do it
otherwise for some deloyments.  All these oppinions of doing alternative
rfc3775 should be considered as such: alternatives and maybe competitors
to rfc3775, and not improvements over rfc3775.

That's why I don't find any reason to improve rfc3775 by replacing its
dhaad by rfc5026, or by replacing its home link detection by a new rfc.

I find it much more reasonable for people wanting to do dhaad
bootstrapping replacements or home link detection and ptp links
replacements to design completely new systems rather than trying to fix
rfc3775.

Alex

>>>  complete new proposed text so we can take a look at it...I think
>>>  I have lost track of some of the changes.
>>> 
>>> Thanks George
>>> 
>>>>>>  other mechnisams to find address(es) of home agents in
>>>>>> such networks. Hence, I propose the following to be added.
>>>>>> 
>>>>>> "In such networks, the MN SHOULD employ other mechanisms 
>>>>>> (e.g. DNS query) to discover the address(es) of the home 
>>>>>> agents"
>>>>> 
>>>>> 
>>>> Agree. That was one of my concern in the text I provided 
>>>> initially. But, my main reason to integrate such referencies in
>>>>  the security considerations section was when you want to
>>>> secure exchanges: there is no specified solution today with
>>>> DHAAD which is not the case with the RFC 5026.
>>>> 
>>>> mechanisms suggested in these specifications, instead of the 
>>>> DHAAD mechanism.
>> 
>> Additionally, would one acknowledge in the NEW propsed TEXT the 
>> security weaknesses of [Boot-Split], as discussed here on the MIP6 
>> mailing list, namely the lack of security during the discovery 
>> phase of the address of the DNS Server (DHCPv6).
>> 
>> 
>> 
>> Alex
>>

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 20 Mar 2008 13:28:50 +0000

Alex, we have past the point of trying to remove dhaad. We have
already agreed NOT to remove it.
We are simply trying to clarify the text and as part of that point to
other alternatives.

Do you agree?

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 14:43:35 +0100

> We are simply trying to clarify the text and as part of that point to

Let's see text then I can agree on text or not.

I agree 3775bis referring to work that's been done (5026) but by no 
means make it sound as the exclusive bootstrapping, or sound as if 
dhaad lacks security compared to 5026.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Mar 2008 15:14:52 +0100

Hello George, all,

> have lost track of some of the changes.

Here comes the new text taking in account the wrap-up discussion that 
happened so far:

------------------------------------------------------------------------
OLD:

NEW:

*  This document does not define any authentication mechanism for 
*  dynamic home agent address discovery messages. Therefore the home
*  agent does not know the identity of the mobile node that requested
*  the list of home agents.

*  In cases where security is needed, it is advisable to consider the
*  use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in
*  conjunction with security mechanisms suggested in these
*  specifications, instead of the DHAAD mechanism.
*
*  Finally, it should be noted that the DHAAD mechanism is based on
*  ICMP and as such, it will not work in networks that are configured
*  to block ICMP messages.
------------------------------------------------------------------------
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 20 Mar 2008 15:25:53 +0000

Thanks Julien,

The proposed text is fine with me.

George

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 17:27:28 +0100

Hi Julien, I don't agree.

Here's why, interspersed in the text below.

> Here comes the new text taking in account the wrap-up discussion that 

It does not know the address.  I'm not sure what 'identity' is (I hear 
'identity' as something that can be an address, or a fqdn name, at 
least.  And the MN can very well have a fqdn name in DNS for its CoA, 
known by HA).

> *  use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in

1. What is [Boot-Integrated]?  Is there an RFC for integrated
    bootstrapping scenario (expired
    draft-ietf-mip6-bootstrapping-integrated-05.txt)?  Or is this a
    forward reference?  Can 3775bis go forward this way?

2. Do you mean that when security is needed it is advisable to consider
    Boot-Split RFC5026 as a secure method to bootstrap?  I don't agree
    with this advice.  RFC5026 is _insecure_.  It is silent about the
    security of the way the address of the DNS Server is obtained at the
    MN.

> *  specifications, instead of the DHAAD mechanism.

I can't agree with a recommendation of a unsecure mechanism (rfc5026) 
just for the sake of discarding DHAAD.

> *  to block ICMP messages.

If it said the below then I'd agree with it:

"Finally, it should be noted that in networks where ICMPv6 is blocked
  DHAAD will not work, and in networks where rfc5026 (DHCPv6, DNS) is
  blocked rfc5026 will not work."

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 09:32:18 -0700

Hi Julien,

I think we should just go with

NEW:

> *  specifications, instead of the DHAAD mechanism.

This paragraph doesn't make sense without explaining how the split
or integrated bootstrapping mechanisms make it more secure to obtain
a list of home agents.

> *  to block ICMP messages.

This does not belong in the security considerations section.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Mar 2008 19:32:01 +0100

Hi Julien,

>  Here comes the new text taking in account the wrap-up discussion that

Thanks for the text and I agree it.

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Mar 2008 19:49:38 +0100

Hi Vijay,

[snip]

>  or integrated bootstrapping mechanisms make it more secure to obtain

There are the information in the "Security Considerations" section of
these documents. Why do we need to explain them again?

> This does not belong in the security considerations section.

Why?
This is linked to security or did I miss something? :)

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 12:30:07 -0700

> these documents. Why do we need to explain them again?

Since you can't claim something is more secure and then not explain
why it is more secure.

> This is linked to security or did I miss something? :)

It is more of a deployment issue. DHAAD is clearly identified by
a specific ICMPv6 type. Firewalls can be configured to allow the
DHAAD ICMPv6 message through, while blocking other ICMPv6 messages
deeemed harmful.

Vijay