Subject: [Mip6] Bootstrapping from the home link

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Apr 2006 18:54:50 -0700

hello,

after some discussions offlist, we came up with
some text that could be added to
draft-ietf-mip6-bootstrapping-split-02.txt to
address bootstrapping from the home link. the
proposal is to have this in a new section before
the security considerations section.

9.  Bootstrapping from the home link

    The mechanisms described in this document also support a mobile node
    bootstrapping from the home link.  When the mobile node is on the
    home link it receives router advertisements from the home agent with
    the 'H' bit set and the 128 bit address of the home agent in the
    modified prefix information option [RFC3775].  When the mobile node
    bootstraps, the first operation it does is to perform a DNS lookup
    for the home agent.  If at least one of the home agent address
    received in the DNS reply matches the address the mobile node
    received in the router advertisement from the home agent, then the
    mobile node assumes it is attached to the home link.

    For configuring a home address, the mobile node can either auto-
    configure a home address, use DHCPv6 or run IKEv2 with its home agent
    as described in section 5.3.

    The mobile node MAY setup IPsec security associations to send and
    receive Mobile IPv6 signaling messages while still attached to the
    home link.  This would help avoid the latency involved in setting up
    the security associations during a handoff when the mobile node moves
    out of the home link.  The existence of an IPsec SA for protecting a
    Binding Update does not depend on the existence of a valid binding
    cache entry.  Therefore the mobile node is free to setup the required
    security associations at any time.

comments are welcome.

Vijay

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 12:17:10 +0200

Vijay Devarapalli wrote:
> hello,
> 
> after some discussions offlist, we came up with some text that could
> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address
> bootstrapping from the home link. the proposal is to have this in a
> new section before the security considerations section.
> 
> for the home agent.

Can MN do DNS lookup before having an Address?  I guess no.  So I doubt
the first operation it does is to perform a DNS loookup for the HA.  I
think the first operation it does is to auto-configure an address.

Also, in order to perform DNS lookup, would the MN need to have an SA 
developed with the DNS Server first?

> If at least one of the home agent address received in the DNS reply

Isn't that a "DNS Response" or "answer" but not "reply"?

> matches the address the mobile node received in the router
> advertisement from the home agent, then the mobile node assumes it is
> attached to the home link.
> 

Would MN auto-configure a Address first or decide first whether it
is at home or not (and do DNS)?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Apr 2006 09:23:14 -0700

> developed with the DNS Server first?

I don't think the way DNS is typically used today is to require an IPsec SA 
with the DNS server in order to do lookup.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 18:37:27 +0200

James Kempf wrote:
> I don't think the way DNS is typically used today is to require an IPsec 
> SA with the DNS server in order to do lookup.

Which renders HA discovery via DNS relatively insecure, no?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 10:50:22 -0700

Alexandru Petrescu wrote:
>> bootstrapping from the home link.  When the mobile node is on the home 
>> link it receives router advertisements from the home agent with the 
>> 'H' bit set and the 128 bit address of the home agent in the modified 
>> prefix information option [RFC3775].  When the mobile node bootstraps, 
>> the first operation it does is to perform a DNS lookup for the home 
>> agent.
> 

yes. I guess the current text is confusing. the fact
that the MN configures an address before doing a DNS
lookup was left implicit.

> Isn't that a "DNS Response" or "answer" but not "reply"?

will change it to "DNS Response".

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 21:43:39 +0200

> lookup was left implicit.

Ok, implicit.

And back to the multiple HA on the home link stuff...

If the MN doesn't know it auto-configures a HoA or a CoA before doing 
DNS, wouldn't it be more appropriate to actually do a reverse dns lookup 
(not straight resolution) and check the resulting name against the HA 
name it pre-configured?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 22:22:55 +0200

Vijay, should the MN do reverse DNS lookup to check the name (resolved 
from the IP address it receives with H bit in RA) against the 
pre-configured HA address?  It could help it decide whether it's at home 
or not.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 13:28:35 -0700

> pre-configured HA address?  It could help it decide whether it's at home 

that would work too.

but then in the general case where the MN is mostly
attached to visited link, we want the MN to always
do a lookup for the HA's IP address instead of a
reverse lookup. there could be local home agents on
the access link and the MN could receive router
advertisements with the 'H' bit set and the 128 bit
home agent address. the MN might be better off doing
a DNS lookup for the configured HA FQDN instead of
reverse lookup for the IP address it received in
the router advertisement.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 23:04:23 +0200

Vijay Devarapalli wrote:
>> Vijay, should the MN do reverse DNS lookup to check the name 
>> (resolved from the IP address it receives with H bit in RA) against
>>  the pre-configured HA address?  It could help it decide whether 
>> it's at home or not.
> 
> that would work too.
> 
> but then in the general case where the MN is mostly attached to 
> visited link, we want the MN to always do a lookup for the HA's IP 
> address instead of a reverse lookup. there could be local home agents
>  on the access link and the MN could receive router advertisements 
> with the 'H' bit set and the 128 bit home agent address. the MN might
>  be better off doing a DNS lookup for the configured HA FQDN instead 
> of reverse lookup for the IP address it received in the router 
> advertisement.

Sorry, I do not get it.  You do want the MN to do a IN AAAA resolution,
ok but this does not preclude do the reverse resolution as well - it
does not break anything.

Why wouldn't MN do both the straight resolution on the pre-configured
name _and_ the reverse resolution on the RA IP address?

If it does both, then it avoids the situation where it should check the 
AAAA address it got from the initial straight resolution against _all_ 
the addresses in all the received RAs on a certain link.  BTW, the 

> matches the address the mobile node received in the router
          ^
          any of the

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 14:10:39 -0700

Alexandru Petrescu wrote:
>>>  the pre-configured HA address?  It could help it decide whether it's 
>>> at home or not.
>>
>> that would work too.
>>

the MN can do the reverse lookup yes. but in
the most common case it might be the actual
DNS lookup that would be most useful.

> name _and_ the reverse resolution on the RA IP address?

at the same time? then its fine with me.

>> matches the address the mobile node received in the router

ok.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 23:28:23 +0200

Vijay Devarapalli wrote:
>>>> (resolved from the IP address it receives with H bit in RA)
>>>> against the pre-configured HA address?  It could help it decide
>>>> whether it's at home or not.
>>> 
>>> that would work too.
>>> 
>>> visited link, we want the MN to always do a lookup for the HA's
>>> IP address instead of a reverse lookup. there could be local home
>>> agents on the access link and the MN could receive router
>>> advertisements with the 'H' bit set and the 128 bit home agent
>>> address. the MN might be better off doing a DNS lookup for the
>>> configured HA FQDN instead of reverse lookup for the IP address
>>> it received in the router advertisement.
>> 
>> Sorry, I do not get it.  You do want the MN to do a IN AAAA
>> resolution, ok but this does not preclude do the reverse resolution
>> as well - it does not break anything.
> 
> the MN can do the reverse lookup yes. but in the most common case it
> might be the actual DNS lookup that would be most useful.

Most useful, yes, but maybe less secure too.  It's often safer to do
both straight and reverse resolution for some name and address (in 
addition to the checks you described) and thus double-check the validity 
(some SMTP servers do); since not all deployed DNS is secure, there's a 
risk that the foreign network's DNS is propagating a rogue HA address. 
If you think this risk can be mitigated, think about the latest famous 
DNS attacks.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 14:43:06 -0700

Alexandru Petrescu wrote:

> (some SMTP servers do); 

here I assume you are talking about the MN on
the visited link.

since not all deployed DNS is secure, there's a
> If you think this risk can be mitigated, think about the latest famous 

question is, is this specific to MIP6? or is it
a general concern with DNS? DNS lookup is used
quite widely for many services.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 00:26:58 +0200

Vijay Devarapalli wrote:
>>>> resolution, ok but this does not preclude do the reverse 
>>>> resolution as well - it does not break anything.
>>> 
>>> the MN can do the reverse lookup yes. but in the most common case
>>>  it might be the actual DNS lookup that would be most useful.
>> 
>> Most useful, yes, but maybe less secure too.  It's often safer to 
>> do both straight and reverse resolution for some name and address 
>> (in addition to the checks you described) and thus double-check the
>>  validity (some SMTP servers do);
> 
> here I assume you are talking about the MN on the visited link.

YEs, both on visited and on home link, double-check DNS information by
reverse resolving.

The additional reverse resolving works fine because coherent information
about names and IP addresses must be distributed from two different
points on the Internet, into DNS.  Just like MIP6 RR RO tests are
assumed to offer better security than without.

>> risk that the foreign network's DNS is propagating a rogue HA 
>> address. If you think this risk can be mitigated, think about the 
>> latest famous DNS attacks.
> 
> question is, is this specific to MIP6? or is it a general concern 
> with DNS? DNS lookup is used quite widely for many services.

Question is, is DNS specific to SMTP?  No, and that's why there's spam
and safety reverse lookups.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 15:29:43 -0700

Alexandru Petrescu wrote:
>>> addition to the checks you described) and thus double-check the
>> question is, is this specific to MIP6? or is it a general concern with 
>> DNS? DNS lookup is used quite widely for many services.
> 

so what happens when the reverse lookup fails?
support for the reverse tree is spotty in many
cases.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 00:42:56 +0200

Vijay Devarapalli wrote:
>>>>> the MN can do the reverse lookup yes. but in the most common 
>>>>> case it might be the actual DNS lookup that would be most 
>>>>> useful.
>>>> 
>>>> Most useful, yes, but maybe less secure too.  It's often safer 
>>>> to do both straight and reverse resolution for some name and 
>>>> address (in addition to the checks you described) and thus 
>>>> double-check the validity (some SMTP servers do);
>>> 
>> YEs, both on visited and on home link, double-check DNS information
>>  by reverse resolving.
>> 
>> The additional reverse resolving works fine because coherent 
>> information about names and IP addresses must be distributed from 
>> two different points on the Internet, into DNS.  Just like MIP6 RR 
>> RO tests are assumed to offer better security than without.
>> 
>>>> address. If you think this risk can be mitigated, think about 
>>>> the latest famous DNS attacks.
>>> 
>> Question is, is DNS specific to SMTP?  No, and that's why there's 
>> spam and safety reverse lookups.
> 
> so what happens when the reverse lookup fails? support for the 
> reverse tree is spotty in many cases.

It's spotty in some places because people don't deploy DNS correctly. 
With a correctly deployed DNS the reverse tree is right.  We should go 
with the assumption that DNS is deployed correctly.  IETF can't make 
assumptions on how certain protocols are deployed, can just suggest 
deployers how to do it.

If the reverse lookup fails simply don't use that foreign network, drop
all connections via it.

It's same reasoning as with certs: if you don't have a cert backed by a 
some CA don't connect to me.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 16:13:31 -0700

Alexandru Petrescu wrote:

>>> information about names and IP addresses must be distributed from two 
>>> different points on the Internet, into DNS.  Just like MIP6 RR RO 
>>> tests are assumed to offer better security than without.
>>>
>> so what happens when the reverse lookup fails? support for the reverse 
>> tree is spotty in many cases.
> 
> With a correctly deployed DNS the reverse tree is right.  

I can see this happening in say an Enterprise
network. but not between operators and ISPs who
have roaming agreements.

We should go
> If the reverse lookup fails simply don't use that foreign network, drop

this I dont agree with. I dont want MIP6
bootstrapping to fail if reverse lookup fails.

> some CA don't connect to me.

but in this case, you dont use certs until
you know you have the infrastructure in place.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 01:33:47 +0200

Vijay Devarapalli wrote:
>>>>>>>> Sorry, I do not get it.  You do want the MN to do a IN 
>>>>>>>> AAAA resolution, ok but this does not preclude do the 
>>>>>>>> reverse resolution as well - it does not break 
>>>>>>>> anything.
>>>>>>> 
>>>>>>> the MN can do the reverse lookup yes. but in the most 
>>>>>>> common case it might be the actual DNS lookup that would 
>>>>>>> be most useful.
>>>>>> 
>>>>>> Most useful, yes, but maybe less secure too.  It's often 
>>>>>> safer to do both straight and reverse resolution for some 
>>>>>> name and address (in addition to the checks you described) 
>>>>>> and thus double-check the validity (some SMTP servers do);
>>>>> 
>>>> YEs, both on visited and on home link, double-check DNS 
>>>> information by reverse resolving.
>>>> 
>>>> information about names and IP addresses must be distributed 
>>>> from two different points on the Internet, into DNS.  Just like
>>>>  MIP6 RR RO tests are assumed to offer better security than 
>>>> without.
>>>> 
>>>>>> risk that the foreign network's DNS is propagating a rogue 
>>>>>> HA address. If you think this risk can be mitigated, think 
>>>>>> about the latest famous DNS attacks.
>>>>> 
>>>>> question is, is this specific to MIP6? or is it a general 
>>>>> concern with DNS? DNS lookup is used quite widely for many 
>>>>> services.
>>>> 
>>>> Question is, is DNS specific to SMTP?  No, and that's why 
>>>> there's spam and safety reverse lookups.
>>> 
>> It's spotty in some places because people don't deploy DNS 
>> correctly. With a correctly deployed DNS the reverse tree is right.
>> 
>> 
> 
> I can see this happening in say an Enterprise network. but not 
> between operators and ISPs who have roaming agreements.

Not only Enterprise network.  Many cell operator networks and wired ISPs 
for individuals.  The reverse lookup working fine depends first and 
foremost on the owner of a certain domain setting up the reverse lookup 
for its assigned address space.  If it doesn't, no foreign network can 
reverse resolve it.

Some address space and domain owners would even ensure propagation of 
same DNS data from more than one place, for reliability.

Thus, if the domain administering the HA propagates its inverse
resolution then any foreign network should see it.  If while in the 
foreign network MN doesn't see its home reverse DNS it's either because 
the home DNS is not set up correctly or because the foreign operator 
wouldn't allow reverse resolution for fear of inside DNS attacks.  Many 
ISPs (wireless or wired) for individual customers forbid reverse 
resolution for security reasons.

>> We should go with the assumption that DNS is deployed correctly.
>> IETF can't make assumptions on how certain protocols are deployed,
>> can just suggest deployers how to do it.
>> 
>> If the reverse lookup fails simply don't use that foreign network, 
>> drop all connections via it.
> 
> this I dont agree with. I dont want MIP6 bootstrapping to fail if 
> reverse lookup fails.

I can assure you that in the case of SMTP spam, reverse lookups do get 
rid of a lot of spam.

How about this then: if the reverse lookup fails then fallback to DHAAD, 
and if DHAAD fails then stop connecting to foreign network - how about that?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 18:46:37 -0700

> and if DHAAD fails then stop connecting to foreign network - how about 

but then this requires configuring the MN
with the home prefix. this is not in the
minimal set of configuration on the MN as
described in the bootstrapping problem
statement draft.

I dont see a way out.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 11:48:32 +0200

Vijay Devarapalli wrote:
>> How about this then: if the reverse lookup fails then fallback to 
>> DHAAD, and if DHAAD fails then stop connecting to foreign network -
>>  how about that?
> 
> but then this requires configuring the MN with the home prefix. this
> is not in the minimal set of configuration on the MN as described in
> the bootstrapping problem statement draft.

I agree, the home prefix is not currently in the minimal set of 
configuration of MN as described in the bootstrapping PS draft.

> I dont see a way out.

I suggest to add the home prefix in the list of pre-config data.  This 
would help integrate DHAAD and MPD in the bootstrapping flow, with side 
effects of ensuring a higher level of security using DNS and facing 
renumbering events with MPD.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 08:41:11 -0700

> It's spotty in some places because people don't deploy DNS correctly. With 
> a correctly deployed DNS the reverse tree is right.  We should go with the 
> assumption that DNS is deployed correctly.  IETF can't make assumptions on 
> how certain protocols are deployed, can just suggest deployers how to do 
> it.
>

I don't think we are talking about failure of the reverse lookup. One can 
certainly argue convincingly that if the reverse lookup fails, the MN should 
drop the address. On the other hand, if the reverse tree is not deployed, 
there will just be no response. It is not clear to me that this is 
sufficient justification for the MN to drop the address. The MN can go ahead 
and try to set up an IKE transaction with the HA, and, if it succeeds, it's 
just an indication that the network sysadmins are not so diligent about how 
they deploy the DNS, not that there is an attacker spoofing a DNS server and 
HA.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 08:44:57 -0700

> and if DHAAD fails then stop connecting to foreign network - how about 

If the reverse lookup fails to return a response, the MN can try IKE anyway, 
so there is no need for DHAAD. If the response is negative, then of course 
the MN should drop the address. In any case, reverse lookup should be a MAY 
due to the patchy deployment status of reverse trees, which, as you note 
earlier in the message, is partly due to security concerns.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 09:02:38 -0700

Alex,

The whole point of boostrapping is to get rid of the need to preconfigure 
with topological data. This would obviate the entire design.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 25, 2006 2:48 AM
Subject: [Mip6] Re: Add home prefix to the minimal set of pre-config? (was: 
Should the MN do reverse DNS lookup to check if at home?)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 18:22:18 +0200

I understand you oppose running DHAAD in case reverse resolution fails 
or reverse resolution returns an address that doesn't match the 
pre-configured HA fqdn.

James Kempf wrote:
> I don't think we are talking about failure of the reverse lookup. One
>  can certainly argue convincingly that if the reverse lookup fails,
> the MN should drop the address. On the other hand, if the reverse
> tree is not deployed, there will just be no response. It is not clear
> to me that this is sufficient justification for the MN to drop the
> address. The MN can go ahead and try to set up an IKE transaction
> with the HA,

MN going ahead IKE to HA but not being sure about HA being the right one
may lead to HA telling it it is at home so don't use IKE.  Depending on
how the text about sequence of DNS resolving and IKE is written there
can be security holes.

> and, if it succeeds, it's just an indication that the network
> sysadmins are not so diligent about how they deploy the DNS, not that
> there is an attacker spoofing a DNS server and HA.

I agree.

The text could just say that MN checks whether the fqdn returned by a 
reverse resolution of the IP address obtained from resolving the 
pre-configured fqdn - is the same.  If not the same then it MUST run IKE 
to the HA even if it believes it is at home.  Becaue the HA may be 
rogue.  Or so.

If the reverse resolution returns NULL or fails to respond within 5 
minutes then also run IKE even if it believes it is at home.  Or so.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 18:34:45 +0200

James Kempf wrote:
> Alex,
> 
> The whole point of boostrapping is to get rid of the need to 
> preconfigure with topological data.

Ah!

Apparently sounds logical.

But MIP6 addresses exactly this problem, that the topology is stable and 
_can't_ change.  That's why Home Address-CoA bindings.

I was always thinking topological data must be there as is, at least 
about the home link, otherwise sessions get interrupted.  One can't 
bootstrap now a MN with a HoA and 2 hours later with a different 
prefixed HoA without loosing reachability at the permanent home address. 
  That's why this prefix must be stable, that's why should be 
pre-configured on MN, or that's why it should be returned in the SRV 
record too.

 > This would obviate the entire design.

Not my goal.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 10:09:18 -0700

James Kempf wrote:
> can certainly argue convincingly that if the reverse lookup fails, the 
> MN should drop the address. On the other hand, if the reverse tree is 
> not deployed, there will just be no response. It is not clear to me that 
> this is sufficient justification for the MN to drop the address. The MN 
> can go ahead and try to set up an IKE transaction with the HA, and, if 
> it succeeds, it's just an indication that the network sysadmins are not 
> so diligent about how they deploy the DNS, not that there is an attacker 
> spoofing a DNS server and HA.

I agree with this. there is an IKE authentication
that follows anyway.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 19:19:49 +0200

Vijay Devarapalli wrote:
>>> correctly. With a correctly deployed DNS the reverse tree is
>>> right.  We should go with the assumption that DNS is deployed
>>> correctly.  IETF can't make assumptions on how certain protocols
>>> are deployed, can just suggest deployers how to do it.
>>> 
>>> If the reverse lookup fails simply don't use that foreign
>>> network, drop all connections via it.
>>> 
>> 
>> I don't think we are talking about failure of the reverse lookup.
>> One can certainly argue convincingly that if the reverse lookup
>> fails, the MN should drop the address. On the other hand, if the
>> reverse tree is not deployed, there will just be no response. It is
>> not clear to me that this is sufficient justification for the MN to
>> drop the address. The MN can go ahead and try to set up an IKE
>> transaction with the HA, and, if it succeeds, it's just an
>> indication that the network sysadmins are not so diligent about how
>> they deploy the DNS, not that there is an attacker spoofing a DNS
>> server and HA.
> 
> I agree with this. there is an IKE authentication that follows
> anyway.

It follows _if_ MN still believes it is at home.

Sorry for insisting on this...

Many things were discussed and I'm not sure what you (Vijay) took or not 
into account.  I'll wait for your current text about DNS-based decision 
of being at home or not and I'll remark on it then.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 11:20:50 -0700

Hi Alex,

here is the latest text with the two changes
I agreed to make in the email below.

    The mechanisms described in this document also support a mobile node
    bootstrapping from the home link.  When the mobile node is on the
    home link it receives router advertisements from the home agent with
    the 'H' bit set and the 128 bit address of the home agent in the
    modified prefix information option [RFC3775].  When the mobile node
    bootstraps, the first operation it does is to perform a DNS lookup
    for the home agent.  It is assumed that the mobile node has an IPv6
    address, either auto-configured or acquired through DHCPv6 before
    sending a DNS request.  If at least one of the home agent address
    received in the DNS response matches any of the address the mobile
    node received in the router advertisement from the home agent, then
    the mobile node assumes it is attached to the home link.

the reverse DNS lookup for the HA's IP address
could have an impact on this section. but lets
agree on something before we add text. I would
assume the reverse DNS lookup belongs in the
security considerations section.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 21:12:19 +0200

Vijay, thanks for sending this so quickly!

Vijay Devarapalli wrote:
> Hi Alex,
> 
> here is the latest text with the two changes I agreed to make in the
>  email below.
> 
                  ^statelessly    ^or derived from EUI-64 (link-local),

(because DHCPv6 is auto-configuration too)

> For configuring a home address, the mobile node can either auto-
                                                             ^sl
> home link.

Ok, agreed.

> This would help avoid the latency involved in setting up the security
>  associations during a handoff when the mobile node moves out of the 
> home link.  The existence of an IPsec SA for protecting a Binding 
> Update does not depend on the existence of a valid binding cache 
> entry.  Therefore the mobile node is free to setup the required 

Ok, I agree.

> the reverse DNS lookup for the HA's IP address could have an impact 
> on this section.

YEs.

> but lets agree on something before we add text.

So the question is: should MN do both straight and reverse lookups for
the pre-configured HA fqdn?  Or only straight is sufficient?

I'd say both, for avoiding some risks.

> I would assume the reverse DNS lookup belongs in the security
> considerations section.

Ok that too, let's see.

Alex