Subject: RE: [Mip6] Bootstrapping on the home link

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 11 Apr 2006 18:04:22 -0700

> 
> MN powers up on the home link. It has no means of knowing it is on the
> home link. Hence, it configures an IP address that it thinks is a CoA
> (say, statelessly). It then goes about doing IKEv2 and trying to get a
> home address, at which point, it realizes that the home prefix is the
> same as the prefix on which it just got an IP address. 

before that the MN should get a router advertisement 
from the HA with the H bit set and the 128 bit address
of the HA in the prefix information option. if this
address matches the HA's IP address the MN gets by DNS 
lookup, then the MN realizes it is at home.

Vijay

MN and HA
> behavior in this scenario needs to be addressed. 
> 
> There are multiple ways in which this could work. I walked 
> through a few
> different options and here is one that I think would probably 
> work best:
> 
> 
> 1. MN configures CoA
> 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home
> 3. If the CoA is acceptable as HoA, HA returns the same address in the
> CFG_REPLY. 
> 4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of
> the CFG_REPLY. 
> 5. Either way, MN realizes it is home, based on prefix matching
> 6. If the CoA was accepted as the HoA, MN uses that. If not, 
> it gives up
> the CoA and uses the HA proposed address as the HoA. 
> 7. MN may send BU to de-register (so that other things like 
> DNS updates,
> etc. can happen and doesn't need to wait till handoff time). 
> 
> If this behavior is already discussed somewhere, please point 
> me to it -
> apologies in advance for not doing my homework in that case :)
> 
> If it is not described anywhere, thoughts on this? 
> 
> Regards,
> Vidya
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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

---

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

> lookup, then the MN realizes it is at home.

I do not agree to involve DNS querying in the decision of being at home 
or not.  "Home" link is the realm of proxy ND and MIP, not DNS.

For this reason, the straightforward way to have a decision capability 
about being at home is to pre-configure the home prefix on the mobile, 
and compare it to the one in the received RA.

Alex

---

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

Alex,

Can you say why?

            jak

---

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

> Can you say why?

For one thing, SRV DNS interrogating wouldn't work here because the
interrogating key _mip6._ipv6 is not enough to solve all the HAs that
can exist in that domain's subnets.  It can only solve one.

For the DNS resolving method (not SRV), the MN issues normally a query
for a ha fqdn.  But there can be several HAs on the link, each with a
different address, so MN sees several HAs in the RAs.  Should it query
the DNS for all HAs?  If it queries only one and it compares with the
wrong RA the home "test" wrongly yields "not at home".

If we decide to pre-configure and query all the names of all HAs (and
compare to all RAs) then MN could do so only when it is at home, but it
doesn't know at this point it's at home or not.

Makes sense?

Alex

---

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

> and compare it to the one in the received RA.

sure thats possible. but the assumption here is
that the MN has minimal configuration. this does
not include configuring home prefix information
on the MN. infact, many folks did not want to
tie the mobile node to a specific home prefix.

Vijay

---

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

Vijay Devarapalli wrote:
>> For this reason, the straightforward way to have a decision
>> capability about being at home is to pre-configure the home prefix
>> on the mobile, and compare it to the one in the received RA.
> 
> sure thats possible. but the assumption here is that the MN has
> minimal configuration. this does not include configuring home prefix
> information on the MN.

Vijay what's "minimal"?

Memory space?  Binary representation of a 64 bit prefix (the longest
possible) is sure shorter than here-goes-my-domain.com.  ASCII too.

Do you mean "more human-friendly" and not "minimal"?  Even in that case,
entering a hexa address on a PDA screen may be easier than a domain
name, depending on software and user skill.

Besides, I think this kind of pre-configured information is to be
written in the MN by some configuration software (SNMP, SMS, you name
it), so I don't buy the argument configuring a DNS address is more
minimal than a home prefix.

> infact, many folks did not want to tie the mobile node to a specific
> home prefix.

That's another thing.  Ask whether they want a permanent Home IP Address 
or not, also do they want session continuity.

Because, one can not imagine to magically use bootstrapping and each 
time obtain a different Home Address and still have session continuity 
at the previous Home Address.

Also, one can not imagine that same traffic from CN to same Home Address 
will be duplicated in two parts of the network (different home prefixes).

 > infact, many folks did not want to tie the mobile node to a specific
 > home prefix.

Do you think they agree to tie the MN to one specific home domain name? 
  I don't think so.

Alex

---

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

>> minimal configuration. this does not include configuring home prefix

see section 8 of
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-04.txt
this draft is with the IESG right now.

> or not, also do they want session continuity.

no permanent home address but session continuity.

> at the previous Home Address.

as long as the new home address is updated in the
DNS entry, the new home address is _the_ home
address of the mobile node.

Alex, all this has nothing to do with the current
text that is being proposed. looks like you have
issues with the basic assumptions in
draft-ietf-mip6-bootstrap-ps-04.txt and
draft-ietf-mip6-bootstrapping-split-02.txt.

> will be duplicated in two parts of the network (different home prefixes).

I didn't get this. the traffic from the CN to a
home address shouldnt get duplicated.

Vijay

---

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

Vijay Devarapalli wrote:
>>>> capability about being at home is to pre-configure the home
>>>> prefix on the mobile, and compare it to the one in the received
>>>> RA.
>>> 
>>> minimal configuration. this does not include configuring home
>>> prefix information on the MN.
>> 
>> Vijay what's "minimal"?
> 
> see section 8 of 

Not to look dumb: I _am_ aware of the draft and of the section.  It says
the bootstrapping for split scenario should use the domain name and IKE
credentials.  That's a biased and unfounded statement.  A problem
statement draft should consider all possible pre-config (seed)
information.  A possible pre-config information is the home prefix. 
That's been implemented in at least two implementations.  I have said 
this on the mailing list and on the microphone.

Skimming today through it anew, I find many statements about discarding
DHAAD security issues as being problems, and to which proposed solution
is no better, security-wise.

Re the draft is in IESG queue - I can't and don't intend do anything
about it.  The document has other value in it anyways.  The only point
where it hasn't is that it leaves the reader with the taste that DHAAD
is insecure, and can't be made secure, so one would expect a real secure
discovery technique only to be disapointed by the relegation to "it's a
generic problem" and "people deploy wrongly".

Re "minimal" - nowhere does the PS draft (nor the split solution) say
what's minimal pre-config.

Calling "minimal" pre-config the list of domain name and IKE keys/certs
is not adequate because home prefix + same certs is shorter in terms of
memory space.

>>> infact, many folks did not want to tie the mobile node to a
>>> specific home prefix.
>> 
>> That's another thing.  Ask whether they want a permanent Home IP 
>> Address or not, also do they want session continuity.
> 

That can't be... but separate topic.

>> Because, one can not imagine to magically use bootstrapping and
>> each time obtain a different Home Address and still have session
>> continuity at the previous Home Address.
> 
> as long as the new home address is updated in the DNS entry, the new
> home address is _the_ home address of the mobile node.
> 
> Alex, all this has nothing to do with the current text that is being
> proposed. looks like you have issues with the basic assumptions in 

I know.  And it's too late.  Fine.  What I say now I was saying during
the LC for PS too.  There's still reply, the meaning of which is up to 
anyone's interpretation.

>> Also, one can not imagine that same traffic from CN to same Home 
>> Address will be duplicated in two parts of the network (different
>> home prefixes).
> 
> I didn't get this. the traffic from the CN to a home address shouldnt
> get duplicated.

Yes, I can explain separately.

Alex