Subject: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST)

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 9 Feb 2004 15:35:40 +0100

SECOND REQUEST - To date, no response to this WG last call has been
received.  If enough responses are not received to support the
acceptance of this document, it *will not* be submitted to the IESG for
publication.  Please respond to this WG last call.  If you support
acceptance of the document without change, respond with a simple
acknowledgment, so that support for the document can be assessed.

--------

This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent
Assignment" <draft-ietf-mip4-dynamic-assignment-00.txt>.  The last call
will conclude at 24:00 UTC on Friday, 13th Feb 2004.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism
for dynamic home agent assignment and HA redirection. The goal is to
provide a mechanism to assign an optimal HA for a Mobile IP session
while allowing any suitable method for HA selection.  

This draft is available as
 <http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-00.txt>

	Regards,
		Henrik

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 12 Feb 2004 16:50:44 +0100

Sorry for being late with my comment,

I think the proposal is a good proposal. And so does a few of my 
customers who has asked for the functionality. To bad that they didn't 
flag their interest on the list.

However, there is one thing that I think is needed to be added to the 
draft to make the function usable. The extension carries to little 
information.

Normally a router or gateway with HA functionality have several 
interfaces. The natural setup is that the gateway is accessible to 
internet on one interface (or address) and have the HA advertising the 
home network on another network. In many cases the home network have a 
private address space.

The MN needs to know two things,
1) The address which I can reach my home agent from internet (the 
"external address").,
2) The address which my home agent is advertising on the home network 
(the "internal address").

In the case with dynamic home agent assignment, the MN is informed about 
the assigned "external address", but he is totally unaware of the 
"internal address". Subsequently the MN will never be able to recognise 
when he has entered his home network. Therefore this information needs 
to be relayed to him. Preferably in the Redirected HA address extension 
which then would look something like

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     |               Reserved        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Home Agent External Address                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Home Agent Internal Address                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Home Agent External Address The IP address that the home agent is 
externally
                              reachable. This might be a IP address on 
the Home
                              agent or a IP address of an external 
device that
                              will redirect or map the IP packets to the 
home agent.

  Home Agent Internal Address The IP address of the home agent. This 
might be the
                              same address as the Home Agent External 
Address or an
                              address on an internal network. This 
address MUST be
                              the same address that the Home agent uses 
for the
                              Mobility Agent Advertisements.

Best regards
/// Hasse

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Fri, 13 Feb 2004 02:16:57 +0900

Hello Hans,

 Your comment is interesting, but it isn't directly related to
 dynamic HA, but rather related to NAT traversal in case of
 an HA sitting behind NAT, I'm afraid.  So, we had better
 discuss about your issue as an improvement of the current
 NAT traversal RFC, or a separate draft.
 I think, if you can describe that your issue has more close
 relation to dynamic HA, rather than NAT traversal, it will
 help the authers to answer to you.

Cheers.
-Yoshi

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Feb 2004 21:22:14 +0100

Hello Yoshi,

    The case Hans describes is not the HA behind NAT case, it is just
one where the HA is accessible through more than one interface.  You
could have this setup:

     ..... Internet ....             ........ Home Link .........
                       .             .                          .
                       .           +----+            +-------+  .
                       .           |    |            | MN    |  .
                       .<=========>| HA |<---------->|3.4.5.9|  .
                       .   3.4.5.1 |    |3.4.5.254   +-------+  .
                       .           +----+                       .
                       .             .                          .
                                     ............................

In this case, there is no NAT, but you would still need to know both the
address of the HA on your home link, and the public address of the HA. I
know that not all HAs out there is designed to be positioned in this
manner, and I also believe that some support other ways of identifying
the HA's home link interface, rather than explicitly listing it (or
them).  But all HAs are definitely not so simple that they can be fully
described (assigned) through a single address.  

I don't know if 2 addresses are enough, or if we need to be able to
supply a list of addresses, or even a list of address/mask pairs,
though.

	Henrik

Friday 13 February 2004, Yoshiyuki Tsuda wrote:
> >  Home Agent External Address The IP address that the home agent is externally
> >                              reachable. This might be a IP address on the Home
> >                              agent or a IP address of an external device that
> >                              will redirect or map the IP packets to the home agent.
> >
> >  Home Agent Internal Address The IP address of the home agent. This might be the
> >                              same address as the Home Agent External Address or an
> >                              address on an internal network. This address MUST be
> >                              the same address that the Home agent uses for the

---

From: Alpesh <[email-masked]>
Date: Thu, 12 Feb 2004 12:49:03 -0800

Henrik -

Isn't this issue implementation specific? RFC3344 does not talk about HA 
with multiple interfaces too.

I was wondering if such an implementation can specify one or more 
private addresses using a VSE?
How does the MN currently come to know the private address?

-a

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 12 Feb 2004 22:23:18 +0100

Alpesh,

The problem  is not implementation specific. The reason 3344 doesn't
talk about these things is becasue it doesn't have to. 3344 doesn't at
all deal with how the clietn is configured, it's just a pre-requsite.
Note that this is specifically normal behaviour and 3344 is written to
support it (well, atleast it supports it).

The reason why this becomes an issue here is that this is the first time
ever (as far as I know) that a MN has been configured with a HA
information  in a Registration request extension. Thus, this have to
support both the case where the MN have a CoA (the external address) and
the case where the MN is in the home network (the internal).

The meere phrases internal and external address might however be new to
some people and at first sight be thought of as oimplementation
specific. But still, some mechanism is needed. Using the extension is one.

/// Hasse

Alpesh wrote:

> Henrik -
>
> Isn't this issue implementation specific? RFC3344 does not talk about 
> HA with multiple interfaces too.
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Feb 2004 23:49:44 +0100

Alpesh,

    In addition to Hans' comments, it bears mentioning that rfc3344 in
several places clearly discusses both FAs and HAs having multiple
interfaces.  Explicitly limiting the dynamic HA assgnment mechanism
to work with only the one-interface case seems wrong.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 13 Feb 2004 00:26:16 +0100

Alpesh,

    I've been thinking more about this, and I'm firmly convinced that
I'm still unclear about what would be the optimal solution ,:-)

My latest thoughts have been moving along like this (brainstorming
warning!):

Assuming that the general case is that a HA has one or more publicly
accessible interfaces, and one or more private interfaces, shouldn't we
provide for this?  That would mean that full information to the mobile
would consist of two lists: one giving N public interface addresses, the
other giving M private interfaces (address + mask).

Thoughts?

	Henrik

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Fri, 13 Feb 2004 10:34:19 +0900

Hello Henrik,

 Thank you for your explanation.  My understanding was getting
 better.  I have one more question:
 Do you think an MN needs to know both an external and an
 internal HA addresses at the first registration ?

 Here is another solution:
 - I think, while an MN is roaming in external subnets, the MN
   needs not know the internal HA address, but the external HA
   address.
 - When the MN moves to one of the internal subnets, the
   external HA may be able to redirect the registration request
   to the internal HA address by, say, Redirected HA address
   extension in the dynamic HA I-D.

 This kind of solutions can be extended to multiple interfaces.
 As an MN implementer, I hope MN configuration would not
 become too complicated...

Thanks.
-Yoshi

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 13 Feb 2004 02:48:17 +0100

Hello Yoshi,

>  internal HA addresses at the first registration ?

That depends if it's in its home network or not at the time.

If the HA does in fact have different addresses on its public
interface(s) and its home link interface(s), the MN will need to know
the internal address when it is at home, in order to know that it can
and should de-register.  

>    needs not know the internal HA address, but the external HA

True.

>    extension in the dynamic HA I-D.

Yes, but the MN needs to understand that this is it's home network,
too; otherwise it won't deregister and stop the HA from proxy
arping on its behalf.

>  become too complicated...

Right, I understand.

	Regards,
		Henrik

---

From: Kent Leung <[email-masked]>
Date: Thu, 12 Feb 2004 18:26:40 -0800

Hi Hans.

Doesn't this scheme assume a specific home/foreign domain network detection
mechanism?  This would allow the MN to use the HA IP addresses to find
out if it is on its home domain network or not.  So this is one possible 
solution
to a problem statement of "MN needs to be able to detect when it is at home
domain or foreign domain network", right?

Seems to me that this problem statement needs to be addressed and the
solution be agreed upon.  And at that point, also ensure that dynamic HA
assignment can still be achieved.

Other possible (and I do mean just possibilities) solutions to the home
domain detection issue could be DHCP Domain Name Option, FA
advertising domain name, HA logic to detect based on CoA address,
etc.  Since we haven't decided on a solution yet for that problem, it
doesn't seem to make sense to embed it into the Dynamic HA
Assignment function.

However, this does bring out the issue of HA address changing while the
HoA remains the same.  Since the HA box may have multiple interfaces,
it shouldn't matter which IP address is used for tunnel endpoint as long
as the HoA is reachable.

When MN is outside, it uses public HA.  And when MN is inside,
it can use private HA.  Dynamic HA assignment happens when MN first
registers.  And the draft's method of redirecting can be applied to
notify MN when it moves to the other side of the network.

Kent

At 04:50 PM 2/12/2004 +0100, Hans Sjöstrand wrote:
>I think the proposal is a good proposal. And so does a few of my customers 
>who has asked for the functionality. To bad that they didn't flag their 
>interest on the list.
>
>draft to make the function usable. The extension carries to little information.
>
>2) The address which my home agent is advertising on the home network (the 
>"internal address").
>
>when he has entered his home network. Therefore this information needs to 
>be relayed to him. Preferably in the Redirected HA address extension which 
>then would look something like
>
>   0                   1                   2                   3

---

From: Hans Sjöstrand <[email-masked]>
Date: Fri, 13 Feb 2004 16:36:47 +0100

Alpesh,

After thinking about your proposal I start to lean towards your proposal 
using a VSE for this purpose.

There are several advantages in not incorporating anything else than the 
redirected HA address in the extension exactly as you originally proposed.

Because what I really, really want is not an address, it's a way to 
identify my home agent. and when the NAI draft is published, I can do 
that a lot better with a NAI in the HA adverticement rather than a 
internal address. It woulds be bad in this case if we lock in the 
dynamic HA assignment in an old-school limited solution.

With a separate configuration extension we also get the freedom that the 
additional configuration very well might take place in the registration 
withe the assigned HA, not neccesarily in the first routndtrip with teh 
requested HA.

Also, there are more goodies that I would like to transfer to the MN, 
which indeed are implementation specific, so maybe I'll use a VSE anyway.

Thanks for the comments and sorry for stirring up dust.

A few smaller comments though

1. The extension is a little odd. In most other IETF protocools (atleast 
the ones I've been in) tries to maintain 4 byte alignment. It would be 
nice if the extension looked like this instead.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Redirected-HA-Address                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. I'm not terribly happy about the described behavior for the unicast address case. In the proposed scheme it's impossible for the HA (or HA cluster or whatever) to actually know if the MN will accept and/or support a redirect. This may very well result in that a client without support for dynamic HA assignments gets unneccassary rejects from the HA's even though it's perfectly ok to register. 

To solve this, one way would be to mandate the MN always to send the extension if the dynamic HA assignment is supported and configured. Another way is to remove the option to have a unicast address in the HA field. I didn't quite understand the advantage over just always use ALL-ZERO-ONE-ADDR.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 13 Feb 2004 19:35:09 +0100

On Friday, 13 Feb 2004, Hans Sjöstrand wrote:

> After thinking about your proposal I start to lean towards your
> proposal using a VSE for this purpose.
> 
> There are several advantages in not incorporating anything else than
> the redirected HA address in the extension exactly as you originally
> proposed.
> 
> With a separate configuration extension we also get the freedom that
> the additional configuration very well might take place in the
> registration withe the assigned HA, not neccesarily in the first
> routndtrip with teh requested HA.

This is a very good point.  Only the assigned HA should have to know
anything about it's detailed setup, all others should only have to
know about the addresses of alternative HAs.

> 1. The extension is a little odd. In most other IETF protocools
> (atleast the ones I've been in) tries to maintain 4 byte alignment. It
> would be nice if the extension looked like this instead.
> 
>   0                   1                   2                   3

Actually, there's also another consideration, which is that we probably
want to include a subtype here, to avoid unnecessary depletion of the
extension number space.  I think that possible future extensions to be
sent from the Assigned HA to give more details about itself might have
the same type, and different subtypes compared to this.  We then also
have the advantage of following the recommendation in 3344 section 1.9
:-)

> 2. I'm not terribly happy about the described behavior for the unicast
> address case. In the proposed scheme it's impossible for the HA (or HA
> cluster or whatever) to actually know if the MN will accept and/or
> support a redirect. This may very well result in that a client without
> support for dynamic HA assignments gets unneccassary rejects from the
> HA's even though it's perfectly ok to register. 

>From my reading of Section 4.2 of the draft, it seems that a redirect
when there is an unicast address in the HA field may only be done when
the unicast address doesn't match any of the HA's interfaces.  So a
properly formed request would never be in danger of rejection.  However,
see more below.

> To solve this, one way would be to mandate the MN always to send the
> extension if the dynamic HA assignment is supported and configured.
> Another way is to remove the option to have a unicast address in the
> HA field. I didn't quite understand the advantage over just always use
> ALL-ZERO-ONE-ADDR. 

It seems to me that there are two ways the HA may receive a request with
a unicast address which does not match its own address:

1) The MN places different HA addresses in the request HA field and in
the IP header destination address.  I don't see that this gives any
extra functionality over using the ALL-ZERO-ONE-ADDR.

2) The FA decides to forward the registration request to a different HA
than the one requested by the MN.  In this case, the draft suggests that
the discrepancy be observed by the HA, which may respond with a
REDIRECT-HA-REQ error value.  

Now, I don't have any great issue with the HA side of this, but I'm
quite doubtful as to permitting a FA to make the decision of forwarding
a registration to another HA than the one requested by the MN.  And what
is the the advantage here?

	Henrik

-- 
  If you lend someone $20 and never see that person again, it was
  probably worth it.

---

From: Pete McCann <[email-masked]>
Date: Mon, 16 Feb 2004 16:49:57 -0600

Hi,

 > know about the addresses of alternative HAs.

Even if the information comes from the assigned HA, I am a little bit
confused about the model here.  When up and running, a mobile node
knows the following:

1) its home address
2) its home subnet prefix (length)
3) its home agent address, and a security association with that home
   agent.

Now, we don't really need to know the home agent's address in order to
do home link detection; we just need to see a router advertisement
that says we have returned to the home prefix, right?

Are we saying there will be cases where the home agent address is not
on the home subnet prefix?  I suppose that is possible, and it
presents no big problem: the HA could still be reachable at its
"external" IP address even from within the "internal" subnet, modulo
firewall configuration, so the MN could send a de-registration from
anywhere.

Moreover, is it true that the data structures inside Mobile IP clients
can remember more than one IP address for a given mobility security
association?  Or would it be more proper to think of these as separate
security associations with separate entities, even though they might
have some keys/SPIs in common?

It seems to me that configuring information about alternative HA
addresses is isomorphic to the problem of configuring alternative HAs,
period, and it should stay that way.

 > extra functionality over using the ALL-ZERO-ONE-ADDR.

I agree.  Maybe we should adopt this convention as an indication of
support for the rejection code.

 > is the the advantage here?

I agree the FA should not be forwarding the request willy-nilly when
the MN did in fact specify a valid unicast HA address.  However, there
may be some sort of policy in place at the FA to only allow a certain
set of HAs.  So, maybe we should allow the FA to insert a rejection
code to inform the MN that it should try again with the
ALL-ZERO-ONE-ADDR, even though we have no indication that the MN
supports the extension, because the only other alternative might be to
silently deny service to the MN.  This would be a good use for
Charlie's new FA rejection code procedure.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 17 Feb 2004 01:51:37 +0100

Hi Pete,

> Henrik Levkowetz writes:
...
> that says we have returned to the home prefix, right?

Well...  in the basic 3344 scenario yes, but it isn't particularly good
if you go to private (rfc1918) address home networks.  (Too many of the
primate networks turn out to be 192.168.0.x and 192.168.1.x ...) Now,
knowing the exact address of the HA on the home network reduces the
error frequency (believing you're home when you're not) by in practice
maybe a factor on the order of 100 - but is really not particularly
good, either...

We really need a nai in the advertisements.  The general NAI extension
has been defined for advertisements too, so it's basically just a matter
of using it with a HA NAI in the advertisements.  That may need either
assignment of a subtype number for the generalized NAI, or declaring
that the currently defined HA identity NAI subtype may be used in
advertisements.  Mmh, I think I'll write a very short draft on this.

A remaining question then is - if we assign HA address dynamically,
should we also provide additional extension subtypes to carry additional
information about the assigned HA?  (For the NAI case this isn't needed
though, as it's covered by the NAI carrying extension.)

> firewall configuration, so the MN could send a de-registration from

No, this wasn't the scenario I was thinking of.

> have some keys/SPIs in common?

Mmm, the latter, I think.

...

> support for the rejection code.

Not sure I follow - could you elaborate? 

> Charlie's new FA rejection code procedure.

Sounds like a possibility. 

Alternatively, we could use an extension from the MN to indicate support.

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Tue, 17 Feb 2004 11:17:08 -0600

Hi,

 > maybe a factor on the order of 100 - but is really not particularly

Yes, this seems to be an unreliable heuristic.

 > advertisements.  Mmh, I think I'll write a very short draft on this.

I agree it would be highly useful to put NAIs in agent advertisements,
both foreign and home.

 > though, as it's covered by the NAI carrying extension.)

Quite possibly; although, it's not clear to me that "alternative IP
addresses" are really useful for movement detection.  There might be
other reasons to put them in, though.

A mobile node should de-register if and only if it is on its home
subnet, which means that the home IP address has become topologically
correct.  If it is not possible to determine that based on prefix
alone (such as in the private address case) then it's not clear to me
why adding additional HA IP addresses would help matters.

Usually, private IP addressed networks are set up in a way that makes
them look transparent to client nodes, i.e., the nodes don't actually
need to know the private address ranges or that there is anything
special about the address that they have obtained.  Putting all this
special-case code into Mobile IP clients makes me a bit uncomfortable,
but I suppose this is the whole point of the Mobile IP/VPN effort.

 > No, this wasn't the scenario I was thinking of.

Ok.

 > Not sure I follow - could you elaborate? 

I meant use the ALL-ZERO-ONE-ADDR in the HA field as an indication of
support for HA redirection.  I thought this was what you were
suggesting.  In that case maybe we wouldn't need a separate extension
to indicate support.  However, we'd lose the ability to redirect MNs
that put a unicast HA address in that field, in an attempt to register
with one round-trip.

 > Alternatively, we could use an extension from the MN to indicate support.

Yes, this might be best.

-Pete

---

From: Alpesh <[email-masked]>
Date: Tue, 17 Feb 2004 21:41:29 -0800

Henrik -

Clarifying on two issues, under ALPESH>>
<snip>

>have the advantage of following the recommendation in 3344 section 1.9

ALPESH >> I see your point regarding subtype field. I will discuss with 
the co-authors this issue.

>is the the advantage here?
ALPESH>> One possible scenario is where FA authentication happens and 
AAA server returns an
IP address to use. In that case FA forwards RRQ to the AAA suggested HA.

Alpesh

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Feb 2004 10:07:54 +0100

Tuesday 17 February 2004, Alpesh wrote:
[Henrik]
> the co-authors this issue.

Ok, good.

> IP address to use. In that case FA forwards RRQ to the AAA suggested HA.

Ok.  But I think that (at least in my mind) there is still a question
about dynamic assignment without the ALL-ZERO-ONE-ADDR.  I'd say that
the rule should rather be that if the Mobile permits dynamic HA
assignment in this case, it sends ALL-ZERO-ONE-ADDRESS and a MN-AAA
authentication-enabling extension and the FA sends the request on to the
AAA suggested HA, but if the MN sends a unicast address and MN-AAA auth.
ext., the FA may NOT direct the request to a different HA.

I think this should have been covered in the aaa-nai draft, but wasn't :-( 

Maybe this discussion shows some weaknesses with using the
ALL-ZERO-ONE-ADDRESS, which could more easily be resolved if we
requested a dynamically assigned address through the use of an extension
instead. In the unicast-addr/aaa-suggested-ha case discussed above, for
instance, the extension could carry a flag indicating whether or not it
would permit the FA to redirect the RRQ to a different initial HA.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Feb 2004 14:50:35 +0100

Ok.

> other reasons to put them in, though.

Yes.  What with the NAI having its own extension, I don't have any
example right now which I'd want to promote ... unless maybe the
home network prefix. That really belongs with dynamic home address
assignment rather than dynamic ha assignment, but it's part of the
same area of functionality; and we don't have a way today to inform
the MN of the appropriate netmask - or alternatively the private-side
HA interface address - or whatever other way of identifying the home
network people have implemented.

> correct.  

Yes.

> If it is not possible to determine that based on prefix

It's not really about prefix vs. prefix + extra addresses, but rather
that you need prefix _or_ some equivalent information - like HA address
in the home net, or NAI, or whatever you have designed your home network
identification heuristics around. 3344 is not really helpful on this
point.

> special about the address that they have obtained.  

Right.

> Putting all this

In the ipUnplugged case, we don't (as far as I know) have any special
case code based on the home network being private address or not - what
we have is the choice of preconfiguring with HA home address rather than
Home network prefix as home network detection characteristic; but that
has in itself nothing to do with private vs. publicly routable addresses.

With regards to the Mobile IP/VPN effort, that _does_ complicate the MN
code quite a bit :-(

> ... <snip> ...

Ah, OK.  Right.  I guess I'd prefer using an extension to signal the
capability, both for the greater flexibility and to have the whole
mechanism conform more to the basic model of using extensions to extend
MIP functionality ,:-)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Feb 2004 16:45:23 +0100

Hello Yoshi,

On Thursday, 19 Feb 2004, Yoshiyuki Tsuda wrote:
> at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote:
>  About the netmask, an MN can extract the home subnet prefix by
>  the following way:
>  - Mobility Agents are assumed to advertise correct subnet prefix
>    to their connected subnets.
>  - An MN with dynamic home address compares it with the current
>    subnet address and prefix.  If the home address is within the
>    current subnet, the MN can extract that the home prefix is the
>    current prefix.
>  - Before the MN encounters its home subnet, the MN should assume
>    its home prefix is 32.
> 
>  Our MN has the above function, and is working. :)

Yes, you're quite right, this is absolutely fine, and we don't need to
know the home subnet mask in advance.  Thanks for the correction :-)

	Henrik

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 19 Feb 2004 23:50:59 +0100

Yoshi-san,

I might be misunderstanding the subject here and not that it's anything 
impossible to solve. But the important thing must be to identify the 
home agent, not the home network. Don't you need to amend your algorithm 
a little bit.

The prime example is that you have two home agents on the same network 
segment. This could be for load sharing or for redundancy or for a bit 
of both. When you enter the network from internet, you hear a 
advertisement and notices that it's a home agent advertisement with the 
correct network mask. The MN deregister with that one and starts to grat 
arp. But if it infact was the other HA that you had a binding to, you 
have two devises arping for the same address until you deregister with 
the other HA aswell or the binding times out.

Regards
/// Hasse

Yoshiyuki Tsuda wrote:

>Hello Henrik,
>
> Here, I have just one comment:
>

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Fri, 20 Feb 2004 12:47:47 +0900

Hello Hans,

 My comments are inlined:

>home agent, not the home network. Don't you need to amend your algorithm 

 Ah, yes, I agree that home netmask info doesn't solve your original
 example.  I'm sorry that I went to a bit different example.

>the other HA aswell or the binding times out.

 In case of your original example, VSE or including NAI in
 advertisements might solve your example, as some other persons
 have proposed to you.
 According to your above configuration, if the MN can identify its
 private home network, the MN should send a deregistration request
 to the external(public) HA address, I think.  By this way, the MN
 succeeds in deregistration to the HA whihch really has a binding to
 the MN.  Here, I assume:
 - the MN has a configured private home address and prefix,
 - the MN gets an public(external) HA address by dynamic HA,
   before returning to private home network.
 Am I still missing anything about your concerning ?
 Have a nice weekend.

Thanks.
-Yoshi

---

From: Hans Sjöstrand <[email-masked]>
Date: Fri, 20 Feb 2004 10:47:59 +0100

Yoshi-san,

Comments inline

> Am I still missing anything about your concerning ?

Pretty clever.

But there are a security aspect about this. Deregistrations are a little 
bit sensitive since it makes the client sent the traffic untunneled and 
also in most cases turns off the IPsec client on the MN to get 
seamlessness. Therefore,  local deregistrations (Home address=CoA) are 
sent with TTL =1. In many cases the computer with the HA isn't the 
default gateway of the network. Since the deregistrations in your 
proposal is sent to a non-local address, this is delivered to the 
default gateway and dropped there because of TTL.

This is not mandated by some spec, just our assessment and implementation.

Regards
/// Hasse

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Fri, 20 Feb 2004 23:50:49 +0900

Hans,

 I see, there are some issues according to VPN configuration.
 About the TTL issue, I believe the current rfc doesn't mandate
 TTL=1 in case of unicast deregistaration.  But I can understand
 your security concern.
 We cannot set TTL=1 in deregistration packets from our MNs,
 because some vendor's HAs can be configured HA IP addresses
 apart from MNs' home subnets.  Thus, we need to set TTL
 more than one.  I'd like to try to find any other alternative way
 to this security issue.  Have a nice weekend!

Thanks.
-Yoshi

---

From: Pete McCann <[email-masked]>
Date: Fri, 20 Feb 2004 11:11:11 -0600

Also, isn't it always possible to deregister remotely, i.e., when you
are nicely shutting down a mobile node, even though you never returned
home?

Requiring TTL=1 in deregistrations doesn't seem proper.

-Pete

---

From: Hans Sjöstrand <[email-masked]>
Date: Sat, 21 Feb 2004 15:12:38 +0100

Pete,

You are quite correct, but note that I wrote

> > >sent with TTL =1.  

I have never commented on remote deregistrations. Also note  

> > >This is not mandated by some spec, just our assessment and implementation.

I have no intention to require anything. What I wanted to explain is that it's not entirely a good idea to deregister against the public(external) HA address obtained in the dynamic HA function. 

/// Hasse

---

From: Pete McCann <[email-masked]>
Date: Sun, 22 Feb 2004 10:17:58 -0600

Hi, Hans,

Hans Sjöstrand writes:
 > I have no intention to require anything. What I wanted to explain is
 > that it's not entirely a good idea to deregister against the
 > public(external) HA address obtained in the dynamic HA function.

I guess I don't understand why not.  This is a case where the HA
address happens not to be on the home subnet, but it should be no
different from any other remote de-registration.  Are you concerned
there will be no route to the external HA address from the home
subnet?

-Pete

---

From: Hans Sjöstrand <[email-masked]>
Date: Mon, 23 Feb 2004 10:09:10 +0100

Hi Pete,

>there will be no route to the external HA address from the home

As from previous e-mail, the concern I have is a security concern. The 
scenario described was that if a MN gets an adverticement that matches 
his home address, the MN could deregister against the public(external) 
HA address.

If thats the case he must use a TTL>1 since the route towards that 
address may involve router hops. The HA will reply with an 
acknowledgement to that deregistration and the mobile node will consider 
itself deregistered. Several commercial MN implementations, then turns 
off  the IPsec client to get seamslessness.

But this means that Eve, meerly by sending out a adverticement with 
appropriate address and mask can make a MN to deregister against it's HA 
and start communicate in clear. Therefore, I think that it's a better 
idea to deregister with the TTL=1 and directly to the internal (private) 
HA address. But in that case, this must be known. Another possibility 
might be to deregister against the "All Mobility Agents" multicast 
address. I think it's a good thing to keep the local deregistrations 
local, and having them separate from the remote deregistrations.

Regarding the reachability I have lesser of a concern. Although it might 
very well be so that the public(external) HA address isn't routable from 
the home network in the real world, it's a specific case. But if someone 
makes an implementation when this is one of the scenarious, then I hope 
that they also make a implementation to deal with it. For example to 
deregister against the local HA address. No need to discuss that further 
since it's implemntation specific.

And just to be extra clear. I have no issue with the dynamic HA draft 
regarding this. It does what it's suppose to do. This came up as a 
separate thread although the e-mail subject may be misleading.

Regards
/// Hasse