Subject: [nemo] about draft-wakikawa-nemo-basic-00.txt

From: marcelo bagnulo <[email-masked]>
Date: 09 Mar 2003 23:22:04 +0100

Hi,

I have found the draft to be a really interesting reading and I would
like to make some comments about it.

My first comment is about the new prefix sub-option. If i understood it
correctly, this new sub-option replaces the original PSBU. The benefits
are clear, less overhead since the prefix is not included. However,IMO
this optimization also presents some drawbacks that should be considered
in order to evaluate the trade-off that its adoption implies.IMO, Since
the prefix is implicit in the MR-A carried in the BU message, the prefix
sub-option is less flexible than the original PSBU. In the case that the
mobile network is composed by a single subnet with only one prefix, both
options are equivalent. However, when the mobile network is composed by
multiple subnetworks, the usage of the prefix sub-option imposes
additional conditions on the address range assigned to the subnets that
compose the mobile network, since they must all obtain their address
range from an aggregate that have to be susceptible to be expressed as a
prefix of the MR-A. This imposes multiple constraints. First of all, it
constraints the way addresses are assigned, i.e. the address
administration within the home network. This, at least is an additional
burden to address administrators. Additionally, this constraint may
impose address lost. For example, suppose that the mobile network is
composed by three subnetworks: Pref:0::/48, Pref:1::/48 and Pref:2::/48.
In this case, if i understand this correctly, the prefix sub-option
would indicate a 47 bits long prefix, imposing the waste of the
Pref:3::/48. 
Additionally, its impact in the case of nested networks should be also
considered, since it imposes similar constraints to address
administration. My concern is whether the reduction of 64 bits in the BU
messages is worth these additional costs.

Moreover, it assumed that the HA is aware of the prefix that this
particular MR is authorized to announce, because of security reasons.
So, why is not enough with the N bit only? I mean, the MR sends a BU
with the N bit set, and the HA already knows which prefix of the mobile
network (implicit signaling). If i understand the rationale correctly, 
when PSBU are used, it is useful since the mobile network can have
multiple prefixes, and the BU can refer to only some of them. If the
prefix sub-option is used, this feature is more restricted since only
aggregates containing the MR-A can be announced. I do not know if i am
missing something, but IMO much flexibility is lost when replacing PSBU
by prefix suboption.

My second comment is about the location of the HA. I think that it is
assumed that the HA is co-located with the only router present in the
home-link. I could not find this assumption in the draft, but it is
illustrated in the figure. This assumption is reflected in the behavior
described in section 6.2.2 where it is assumed that all incoming packets
pass through the HA. Is there any reason for this restriction? I think
that the case where multiple routers are present in the home link is a
reasonable case, and it can be easily supported, for instance by means
of redirect from the HA pointing to the alternative router.
Additionally, i think that, as i think it is suggested in
draft-petrescu-nemo-mrha-02, the solution should support that the HA is
a single interface node. I think that the solution can be extended to
support this configurations.

Additional comments:

IPSec processing is included in section 5.2.2 and 6.1.1 but it is not
described in section 5.2.1. Perhaps it would be clarifying to include
it. 

I think that section 6.3 should include the location of the MR (home
link or not) among the rules to decide whether HA has to tunnel or not
packets to the MR.

The fact that the authorization of which prefixes can be announced by a
MR is performed by configuring them in the HA is somehow included in
different sections in the draft but perhaps it would be relevant to
explicitly mention it in the security consideration section.

Regards, marcelo
-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 10 Mar 2003 09:40:30 +0900

# Some Requests to ML administrators
# The SMTP server of NEMO WG has the AAAA record, but SMTP server do not
# speak IPv6. Therefore, my SMTP server (IPv6 capable) fails to send email
# to NEMO ML. If the SMTP server finds AAAA record, it tries to connect to the IPv6
# address first. and I got connection refused error. Is it possible to
# remove AAAA record or to update SMTP server to support IPv6?
# Thanks in advance.

Hello Marcelo

> like to make some comments about it.

Thanks!

> would indicate a 47 bits long prefix, imposing the waste of the

The first motivation of this prefix-suboption is optimization as you've
notice already:)
But, there are other reasons for this now.

When a MR has multiple prefixes, the MR acquires multiple MR-A at the
ingress interface. The MR have to send BU individually for each mobile
prefix. This is because current MIP6 does not allow to update multiple
binding caches by sending "single" BU (i.e. no optimization for this).
Since the assignment of multiple  mobile network prefixes is equal to
the assignment of multiple home addresses on Mobile IPv6. I am not sure
if it is possible to allow this optimization only for NEMO. There will
be another issues if NEMO allows this optimization.

PSBU allows to carry prefix and its length in BU, but the prefix stored
in the suboption of BU is not secured and authorized. MIP6 security
scheme only verify MR's home address, but not prefix itself. 
Our approach provides these verification by using IPsec encryption. SA
is established between MR and HA by using MR-A (MR-A is used as the key
of encryption), mobile network prefix is verified. I think this approach
is well compliant with current MIP6 spec. Instead, PSBU store all the
prefix information in the BU. PSBU needs another way to verify this
prefix and also way to notify mapping of home address and mobile network
prefixes.

Your last scenario is a  kinds of administrative issue. MR may sends BU
w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length.
In fact, I did not mention the situation when MR has multiple mobile
network prefixes in the draft. I will add some texts at the next version.
Thanks for pointing this out.

> messages is worth these additional costs.

Optimization is important, but I tried to keep compliance with current
MIPv6 spec including security idea, because MIPv6 is fully discussed at the IETF and is very
"sensitive" protocol indeed. If I added a lot of optimizations for NEMO, many new
issues come up. Furthermore, NEMO has many kinds of configuration
compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to
provide a certain level of optimization by means of "network operation".
(e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix
length) 

> missing something, but IMO much flexibility is lost when replacing PSBU

For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64
at the beginning. Then the MR sends BU w/ 64 prefix length instead of 48.
Of course, this prefix is belong to the MR, HA can accept BU and
intercepts and tunnels packets only for the prefix/64. For these
operation, the prefix-suboption is needed.
> support this configurations.

Good point, I did not mention this case enough. Delegated prefix is
assigned to MR, and HA only advertises the prefix by routing protocol.
"Routing protocol" means both IGP and BGP. If there are multiple routers
at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in
the home link. HA do not send RA of the delegated prefix at the home
link, so that it becomes next hop router of the delegated prefix. (Other
routers are not on-link of the mobile network prefix).

Multiple HAs for single mobile network prefix is not considered yet in
the draft. 
Although current MIP6 does not allow to register same binding to
multiple HAs, I have rough solution for this.
But I have to consider more before putting texts in the draft, because
there are many issues for multiple HAs, how MR selects HA, how HAs
manage same mobile network prefix at the home link, how to avoid inconsistency
of binding for same prefix among HAs due to some accidents of MR for
example.

> described in section 5.2.1. Perhaps it would be clarifying to include

Thanks, I will fix this.

> link or not) among the rules to decide whether HA has to tunnel or not

Right. I did not notice this. I will fix this, too.

> explicitly mention it in the security consideration section.

We give the assumption for the prefix assignment and configuration at
this moment. I am just wondering whether I should use DHCP prefix
delegation for this protocol or not, now. I will think about this more.

Thank you for your comments!

regards,
ryuji

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 10 Mar 2003 11:08:40 +0100

Ryuji Wakikawa wrote:
> # Some Requests to ML administrators # The SMTP server of NEMO WG
> has the AAAA record, but SMTP server do not # speak IPv6.
> Therefore, my SMTP server (IPv6 capable) fails to send email # to
> NEMO ML. If the SMTP server finds AAAA record, it tries to connect
> to the IPv6 # address first. and I got connection refused error. Is
> it possible to # remove AAAA record or to update SMTP server to
> support IPv6? # Thanks in advance.

Hi, I understand that.

My problem is how to make sendmail speak v6.  Do you know about how to
do it?  I've configured sendmail.cf to have this line:
O DaemonPortOptions=Family=inet6, Addr=2002:c3d4:6ffd:1:201:2ff:fe6c:eff8

Do you think that is enough?

I can not turn the AAAA entry off at this point because I want
jessica's http server to be reachable in IPv6 now...

-- 
Message Classification: GBU

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 10 Mar 2003 11:18:51 +0100

Alexandru Petrescu wrote:
> sendmail

Ah, sorry for cc'ing the list.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 10 Mar 2003 09:30:19 +0900

Hello Marcelo

Thanks!

Optimization is important, but I tried to keep compliance with current
MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive"
protocol indeed. If I added a lot of optimizations for NEMO, many new
issues come up. Furthermore, NEMO has many kinds of configuration
compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to
provide a certain level of optimization by means of "network operation".
(e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix
length) 

Thanks, I will fix this.

regards,
ryuji

---

From: marcelo bagnulo <[email-masked]>
Date: 10 Mar 2003 17:24:26 +0100

Hello Ryuji,

> binding caches by sending "single" BU (i.e. no optimization for this).

Ok. But what happens if the router's interface is not connected to the
network that contains the assigned prefix? I mean, more than one segment
may exist within a mobile network and the MR do not have to have an
interface in each of them.

For example, the below configuration:

                             +--+
                             |MR|
                             +--+
                              |  Pref1::/48        
                    ----------------
                         |
                       +--+
                       |R |
                       +--+
                        |      Pref2::/48
                  -----------------

If i understand correctly, you are proposing that MR ingress interface
has two addresses configured i.e. Pref1:Router and Pref2:Router

Now when the MR wants to send a packet addressed to Pref2, it will
assume it is directly connected if no additional configuration is made,
the same goes for R when trying to reach MR through the Pref2:Router
address. How do deal with this? 

> in the suboption of BU is not secured 

Isn't it possible to secure it with IPSec?

> and authorized.

If i understand correctly, in both cases authorization is achieved
through proper configuration of the HA. I mean, the HA knows which
prefixes are assigned to each MR and the HA can securely communicate
with the MR using preconfigured IPSec. This applies both to PSBU and the
prefix sub-option, or there is a difference respecting to this in both
approaches?

>  MIP6 security
> of encryption), mobile network prefix is verified.

Again, why this can not be used with PSBU messages?

>  I think this approach

I do not understand why this is so, could you explain it to me?

> w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length.

I see, however, the problem illustrated in the figure above remains.

> at the beginning.

I don't quite follow you. What do you mean by the beginning? Why this
information cannot be preconfigured in the HA? Do you have in mind a
possible scenario where the dynamic of configuring the HA with the
prefix assigned to the mobile network is insufficient?

>  Then the MR sends BU w/ 64 prefix length instead of 48.

Ok. however, how this works if the HA is not a router? i mean it only
has one interface? The communication between the AR and the MR should
not pass through the HA in this case. That is why my guess is that
redirects should do the trick.

The other similar case is when multiple routers exist. In this case,
again, the communication between the other routers and the HA should not
pass through the HA. Again, i think the redirects can solve this.

Regards, marcelo

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 14 Mar 2003 01:53:01 +0900

Hello Marcelo.

Sorry for replying late.

> For example, the below configuration:

For this situation, we recommends that "R" becomes another MR which
manage Pref2::/48. I treat this example as nested mobility.

If R doesn't exist and a MR manages multiple prefixes with an ingress
interface, MR assigns multiple MR-A to the ingress interface.

> Isn't it possible to secure it with IPSec?

How HA verrify that the prefix in suboption belong to the MR?

> Again, why this can not be used with PSBU messages?

There is slight difference.
SA is established between HA and MR-A in our id.
SA is established between HA and MR HoA in PSBU.
As you say, if HA has mapping of HoA and prefix, same security can be
provided to PSBU between HA and MR.

We design protocol to support RO in the future, and our scheme is
well-applied to Return Routability, too. For return routability, this
difference becomes large, because PSBU cannot use RR scheme to protect
BU including prefix. PSBU can not verify the prefix by using HoTI and
HoT. But this RO discussion is currently out of scope at WG.

> I do not understand why this is so, could you explain it to me?

I mean HA should know which MR carry which prefix.

> prefix assigned to the mobile network is insufficient?

"beginning" is just example. MR can change the prefix length in active
use anytime. 

HA delegates prefix with certain length, but HA does not care which
prefix length MR currently use (of course within delegated length).

We also consider dynamic configuration. If MR needs larger prefix, MR tries
prefix delegation operation, then generates MR-A from the
appropriate prefix and assigns it to the ingress interface.
MR have to establish SA somehow between HA, too.

> pass through the HA. Again, i think the redirects can solve this.

Currently, HA is the router. HA is configured as the default router of
the mobile network prefix. Even if the HA has a single interface, HA
could receives packets.

Am I missing something here?

regards,
ryuji

---

From: marcelo bagnulo <[email-masked]>
Date: 13 Mar 2003 18:55:57 +0100

Hi Ryuji,

> manage Pref2::/48. I treat this example as nested mobility.

Ok, i guess this would work...
However, wouldn't this introduce additional overhead?
I mean all packets addressed to Pref2 subnet will have 2 tunnels, right?
This seems to be conflicting with the main goal of the modification of
PSBU which was diminishing overhead. 

Perhaps you could consider an alternative option, such as configuring
something like a router loopback address  with Pref2 in MR. I mean, what
if you configure in MR the address Pref2::routeriid with a 128 bit long
prefix? would this break something?
If you can do this, MR can send the BU using this address, and receive
packets addressed to him, but all other addresses of Pref2 subnetwork
could be forwarded to R.
I am probably missing something here (besides that this seems a nasty
hack) but this would reduce the overhead... 

> How HA verrify that the prefix in suboption belong to the MR?

I think that there was a misunderstanding here..
using IPSec the HA knows for sure that the prefix contained in the
packet it had received it is the same that the one the MR has included
when creating the packet (this is what i called the BU sub option is
secured)
What IPSec does not provide to HA are tools to determine if this MR is
allowed to announce this prefix (that is what i called authorization)
I guess we agree then.

> HoT. But this RO discussion is currently out of scope at WG.

Ok, however it seems now that a main benefit of the new sub option is
its extensibility to the RO case, right?

> MR have to establish SA somehow between HA, too.

Do you have some specific application scenario in mind for this feature?
> Am I missing something here?
No, i just meant that if the mobile network is in its home link, and the
HA has a single interface, then HA shouldn't be involved in routing
packets to the mobile network. In this case, other routers in the home
link should send packets directly to the MR (which is on the home link)
and the HA only have to stop intercepting packets. 

Regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 14 Mar 2003 03:58:14 +0900

Hello Marcelo

> PSBU which was diminishing overhead. 

Actually, I did not expect this case. 
We can provide same kinds of network with other configuration (ex. MR
provides Pref1 and Pref2 with multiple ingress interfaces.)

> could be  to R.
> I am probably misforwardedsing something here (besides that this seems a nasty

Wowoo, this could be additional solution for this case. 
I did not consider this yet, but this is interesting.

I will consider this operation carefully and may put this into draft.

> allowed to announce this prefix (that is what i called authorization)

OK, sorry for confusing you.

> its extensibility to the RO case, right?

and packet size becomes less than PSBU

> Do you have some specific application scenario in mind for this feature?

I do not have good example, but...

For example, automobile has pre-assigned Pref::/48.
Each automobile has a mobile newtork (Pref:1::/64) for control system of
engine, car condition monitor. MR basically register the binding w/64 for Pref:1::/64.
This network is managed by automobile company. 
Thus, automobile company may not want to run third-vendor applications
on the network (Pref:1::/64).

When a driver buy some entertainment box, the driver
configures a new prefix for applications to MR. Then MR starts to
register the binding with 63 prefix length. 

> and the HA only have to stop intercepting packets. 

MR do not advertise route information of its mobile network prefix.
HA still receives packets destined to the prefix. 
HA intercepts packets and forward them to the next-hop MR.
In this case, redirect maybe happened. But I think HA should not issue
ICMP redirect for mobile network prefix. 

Regards,
ryuji

regards,
ryuji

---

From: marcelo bagnulo <[email-masked]>
Date: 15 Mar 2003 21:04:39 +0100

> HA intercepts packets and forward them to the next-hop MR

Why is this?
I would have thought that when the MR returns home, it announces so to
the HA and starts advertising the mobile network prefix so that packets
are directly coursed to the MR. This would provide a more efficient
path. Am i missing something?
> ICMP redirect for mobile network prefix.

Why is that?

Regards, m