Subject: [nemo] Section 8 comment in IESG review

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Apr 2004 18:01:39 +0200

[repost, included reviewer in CC]

Steve Bellovin wrote about section 8 draft-nemo-02 in IESG review:
| Do you mean "be careful to include the same information in both
| places" -- redunancy is sometimes good.  Or do you mean "be careful
| to avoid doing this"?  Personally, I think the former is more
| appropriate, because it allows a check on the validity of the routing
|  information.

I also think the text should be along the lines of "careful with that
prefix, include same information in both places", and not "careful to
avoid doing this".

| Note that the prefixes announced via binding updates are checked for
|  authorization; routing data generally is not.  I would thus suggest
|  that routing advertisements MUST NOT contain any prefixes not known
|  to the home agent by either implicit mode configuration or explicit
|  mode announcement.

Basically, I agree with this; this is a useful check.

My preferred way to solve this potential conflicting information between
the prefixes advertised by NEMO and the ones advertised by rt protocol
is to have NEMO _not_ have prefixes in the BU, that is: implicit mode.
Let only the rt protocol make do about prefixes.

Moreover, there are at least three ways by which a host learns routes
(rt protocol, icmp redirects, static config). Adding NEMO as a fourth
means only complicates the picture: one wants all four means to
distribute the same routing information; why not let NEMO just do the
Home-Address - Care-of-Address binding.

Alex

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 1 Apr 2004 08:54:13 -0500

> > => Agreed. I was just thinking of a general HA
 > > that might end up supporting both types of MRs
 > > (i.e. trusted and not trusted). So unless further
 > > configuration is done to distinguish between
 > > the two cases the HA won't know the difference.
 > 
 > Yeah, you wouldn't want to mix the two cases.
 > 
 > Thinking a bit more on this; maybe what we originally 
 > intended was to 
 > allow different kinds of network configurations.
 > 
 > In my example 1) above, the administrator would possibly want to use 
 > routing protocols _as the only mechanism_ to pass prefixes 
 > and routing 
 > information from MR to HA (and not include them in BUs). It 
 > is then up 
 > to the IGP daemon to authorize the MR and the prefixes, if need be.
 > 
 > In 2), the administrator would possibly want to use BUs _as the only 
 > mechanism_ to pass prefixes from the MR to HA. In this case 
 > it is up to 
 > the HA function to autorize the MR and the prefixes.
 > 
 > Now I'm not sure whether we still want to keep the specs 
 > open for such 
 > configurations. It is ultimately up to the administrator of 
 > the HA to 
 > make sure routing information is correct and that no MR 
 > steals another 
 > MR's traffic.

=> Sure, but the admin is only limited by the tools
provided by the vendor. We need to make these tradeoffs clear
in the spec to allow vendors/admins to make that choice. 
But I get the feeling that there are too many options
here. Given that there are different ways of implementing
the MR, and that we don't know what vendors will
support, what can we do? Either always make sure that 
the information is checked in both the routing side
and the MIP side, or somehow allow for "protocol
support discovery ;)" between the MR and the HA.
The latter seems like an overkill.

For instance suppose that company X decided not
to use IGPs in their MR and company Y decided to
use the IGP. Say that one method is more IPR friendly :).
Now, what does the HA do? Does the admin say:
"We'll support your MR if it's from a certain
vendor?" 

 > 
 > I think my original intention was to try to keep IGP and NEMO 
 > independent. That would mean that their respective 
 > authorization would 
 > also be kept independent. Now, is that a good idea?

=> I don't know if it can be done if we allow the use
of an IGP. There is basically two mechanisms that are 
used for routing: The BU and routing protocol. 
So it seems like some kind of correlation of the information
is needed.

 > > => It depends on the platform of course, but it also
 > > depends on whether a copy of the prefix table/BCE
 > > is available to user space processes (e.g. in a file).
 > 
 > And all IGP protocols (or at least their implementations on 
 > NEMO-enabled 
 > routers) must be updated to be able to handle this?

=> Looks like it, unless there is another way of handling
this. But this is not unusual. I mean, look at MIPv6 and 
how many additions it made to ND. Note that the spec also
requires the BU to trigger the IGP to inject routes in 
the case where the MR's prefix is not aggregated under 
the HA prefix. But hopefully this is a rare event with
proper configuration. The problem here is that the MR
is not always part of the same admin domain. Thus, some
kind of authorisation is needed for the routing messages. 
Relying on the MIP authorisation seems like a good way to
leverage existing security and minimise the amount of 
changes required in the IGP. 

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================