Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 5 Feb 2002 15:21:35 -0600

Jari,

Thanks for doing this analysis.

Below are my comments on the zero-overhead variants.

> 3. ZOD/MR.ZOD Tunneling
> 
> This is an entity with unselected semantics, both endpoint and
> routing semantics are described, but no restriction has been made.

The reason there are unselected semantics is because there are options that
I felt the Internet community as a whole may wish to consider. The main
thing that the draft is trying get accross is that:

"We don't need no stinking overhead. Here are some ways it works. Which way,
with its accompanying restrictions do you think is appropriate? Pick one,
but please get rid of the overhead - we don't need it now that we have to
protect against the reflector spoofing. It is a waste."

> That is, by reception, the Shim either switches endpoint
> addresses from authorized state for internal delivery to
> upper layer or in case of generalization, packet is
> forwarded based on state. Non-generalized mode (NGM) fulfills
> the generic requirement of not forwarding out of the node.

I think it is quite evident that we would be doing NGM if one of the options
is applied to MIPv6. The intent of the document was to convey the general
concepts and requirements for signaling. The application of the concept to
MIPv6 is pretty straight forward given the examples and it would use the NGM
- E2E approach if you wish to call it that.

> Alternatively this could have been treated as the applicable
> component of the proposal but since this is a whole draft,
> NGM cannot realistically be just extracted to MIPv6 draft?
> 

We already have a MIPv6 draft. I don't want to come up with a new MIPv6
draft. The ZOD draft's purpose was to convey the idea in sufficient detail
such that the rightful authors of the draft can understand the changes and
the developers could understand what the reasoning behind the changes were.
The mail list and the draft should be sufficient to work out choices. The
generalized detail was given in order to let people understand what other
uses MIP signaling could be used for to achieve functions other than just
node mobility. I think it is very realistic to incorporate the change into
MIPv6 in a timely fashion once a choice is made between the alternatives.

> Known properties:
> - Header Type: Nothing needed (except a flag both ways)
> 
> Derivable properties
> - Position of the flag, this was not specified for all cases, but
>   rough alternatives were given.
> 
> Unknown properties:
> - Problems resulting from use for other purposes: Not known,
>   since this proposal does not restrict itself to host mobility.

As for the other purposes argument, the problems with the other
overhead-based proposals is due to the fact that the overhead exists and a
firewall might be inspecting and blocking these other purposes. With ZOD the
firewalls have nothing to block; therefore, the issue with "other purposes"
is mute.

Again, the idea is to convey the options, bearer semantics and associated
requirements for the signaling. The signaling of MIP can be used, as is,
with the restrictions detailed in the draft related to host mobility.  The
same restrictions  have pretty much already been agreed to on the mail list.
This is hardly the same issue in terms of unknowns as exists with the RH or
other overhead-based solutions. With this "other purposes" reasoning I guess
we shouldn't use overhead based tunneling mechanisms at all because all of
the uses of it are unknown as well. I guess we should throw the routing
header into this bucket, as well, with this reasoning. I don't just mean
throw them out for MIP only, either. I think this was Charlie's earlier
point on the RH.

If you want to limit MIPv6 signaling to only be used for mobility - go for
it. I don't think this would stop people from using it for other purposes,
though. The choice of overhead vs no overhead is orthogonal to this
argument.

With these points in mind, I see the ability of ZOD and MIPv6 signaling to
be used for other functions than just mobility as a positive - not an issue
or problem.

>   The choice for delivery vs. forwarding was not made nor strict
>   restriction to use with host mobility in delivery, nor the use
>   of RO signaling as establishing the state were mandated. This
>   many open options leave room for too many unknowns given the
>   level of security required for the choice at hand.

The example of ZOD applied to MIPv6 was given that did detail delivery and
forwarding. The draft also gives restrictions and requirements on the
signaling related to security in a way that is irrespective of the signaling
employed. It just so happens that MIPv6 RO signaling meets these
restrictions and requirements. It would be the job of the MIPv6 draft to do
the mandating with its specific signaling. What unknowns are you refering to
- one will do?

> - Interaction/security with other protocols (given the amount of
>   security and other analysis in MIPv6, any generic new method
>   deserves this note)

The draft shows that the security requirements and state necessary to
implement route optimized MIPv6, without the reflector spoofing hole, are
the same as that which would be needed to remove the extra overhead. In
short, if the security for MIPv6 with overhead based tunneling has no
issues; neither does ZOD/MR. ZOD. If you could give me an example of where
it might be different I can respond to the concerns?

> - All possible signaling methods for setting up the
>   authorized state (a downside of the proposal is its reliance
>   on state, which gets the critique all non-routing-state-based
>   forwarding usually does, esp. in its generalized format)

I'd really like to see someone attempt an efficient implementation of secure
route optimized mobile IPv6 (i.e. without the reflector spoofing hole) that
doesn't keep the same state. If you see a problem with this state end to
end, then you must see the same problem with all of the overhead-based
methods that also require this state. This was the entire message of the
draft: "Because you have to keep this state to do RO in a secure manner, you
don't need the overhead". I guess MIPv6 with any of the overhead based
methods has the same downside to it.

> - Final stabilized properties, since there may be changes due to
>   problems found with other uses.

Again, the "other uses/other purposes" duplicate argument doesn't hold water
because as there is nothing in the packet for the firewalls to block or
worry about. The issue with "others" is not there. ZOD is transparent to
firewalls.

> - Interaction with IPsec

I did, indeed, detail the interactions and processing rules in relation to
IPSEC. This detail includes the of order of operations of each component. If
you see an specific issue, please detail it?

> Requirement for change
> - Entry and processing of the bits (Shims)
> - Possible robustness features (several, some due to statefulness)
>

Again RO'd MIPv6 will have to be just as stateful unless you want to keep
the reflector hole. If we keep the hole, it will eventually end up being
blocked by firewalls anyway. I.e. a few days after a worm starts to take
advantage of it. Actually it may be blocked from day one if the hole exists.

> Summary: if it had restricted itself to host IPv6 mobility only,
>   it would have been a stronger candidate. Then, I do not give
>   the proper credit to this otherwise well thought draft, it
>   should be a contender with the Deering-Zill tunneling, though
>   the requirement for state in forwarding is a liability.
> 

Again all of the alternatives (D/Z, RH, HAO, ZOT, MR. ZOT) will all have to
keep the same state in order to protect against the reflector spoofing. The
fact that the draft introduced other modes of operation should not have a
bearing on MIPv6's application of a specific mode. This thinking is a
logical fallacy. 

The overhead of the extra address on the paths between the MN and CN is a
waste for MIPv6.

Thanks again for capturing your thoughts on each of the proposals. 

Glenn

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 05 Feb 2002 16:32:11 -0800

Glenn,

> The reason there are unselected semantics is because there are options that I felt the Internet community as a whole may wish to consider. The main thing that the draft is trying get accross is that:
> 
> "We don't need no stinking overhead. Here are some ways it works. Which way, with its accompanying restrictions do you think is appropriate? Pick one, but please get rid of the overhead - we don't need it now that we have to protect against the reflector spoofing. It is a waste."

I agree with you this is a very valuable point in your draft
and feel it makes injustice to this point to evaluate it as a whole
for the very special case of MIPv6 in mind, if known solutions are
sought. I'd be happy to see this kind of an idea to be employed with
RO but not necessarily from the document you have in its current form.
The possible controversies of overlay routing that may occur if the
other parts of the document are proposed as standard did give
a factor in the known-unknown axis (we do not yet know how people
feel about these).

> I think it is quite evident that we would be doing NGM if one of the options is applied to MIPv6. The intent of the document was to convey the general concepts and requirements for signaling. The application of the concept to MIPv6 is pretty straight forward given the examples and it would use the NGM - E2E approach if you wish to call it that.

Agree with that.

> We already have a MIPv6 draft. I don't want to come up with a new MIPv6 draft. The ZOD draft's purpose was to convey the idea in sufficient detail such that the rightful authors of the draft can understand the changes and the developers could understand what the reasoning behind the changes were. The mail list and the draft should be sufficient to work out choices. The generalized detail was given in order to let people understand what other uses MIP signaling could be used for to achieve functions other than just node mobility. I think it is very realistic to incorporate the change into MIPv6 in a timely fashion once a choice is made between the alternatives.

Good to know. Now there is less unknown about this..

> As for the other purposes argument, the problems with the other overhead-based proposals is due to the fact that the overhead exists and a firewall might be inspecting and blocking these other purposes. With ZOD the firewalls have nothing to block; therefore, the issue with "other purposes" is mute.

This was not about firewalls, it was about having so far zero feedback
on its applicability as a general-purpose proposal, not as "donesn't work"
but as in "don't yet know what will the response be" (an unknown).

> Again, the idea is to convey the options, bearer semantics and associated requirements for the signaling. The signaling of MIP can be used, as is, with the restrictions detailed in the draft related to host mobility.  The same restrictions  have pretty much already been agreed to on the mail list.  This is hardly the same issue in terms of unknowns as exists with the RH or other overhead-based solutions. With this "other purposes" reasoning I guess we shouldn't use overhead based tunneling mechanisms at all because all of the uses of it are unknown as well. I guess we should throw the routing header into this bucket, as well, with this reasoning. I don't just mean throw them out for MIP only, either. I think this was Charlie's earlier point on the RH.

I understand your reservations, since I looked at the whole proposal,
not at the applicable part as a separate issue.

> If you want to limit MIPv6 signaling to only be used for mobility - go for it. I don't think this would stop people from using it for other purposes, though. The choice of overhead vs no overhead is orthogonal to this argument.

True.

> With these points in mind, I see the ability of ZOD and MIPv6 signaling to be used for other functions than just mobility as a positive - not an issue or problem.

It was an issue in the known-unknown scale rather than does work - doesn't
-scale, not communicated well in the text. This did not imply it wouldn't
work, rather of the possibility it is not yet analyzed how well does it
match peoples' ideas on end-to-end tunneling or forwarding.
Given this, the genericity of the proposal in its current form
is a factor in the known-unknown axis.

> The example of ZOD applied to MIPv6 was given that did detail delivery and forwarding. The draft also gives restrictions and requirements on the signaling related to security in a way that is irrespective of the signaling employed. It just so happens that MIPv6 RO signaling meets these restrictions and requirements. It would be the job of the MIPv6 draft to do the mandating with its specific signaling. What unknowns are you refering to - one will do?

Ok. If the signaling is a totally open choice, there are different levels of
strength authorization a possible signaling (out of many) would take. Given a
signaling has weak authorization and the state created is used for IPsec based
communication, it is not specified how this weakness be communicated to IPsec.
I do not claim it not to work, just to be an unknown. Rather than saying any
signaling, it would be more "known" to specify a particular signaling.

> The draft shows that the security requirements and state necessary to implement route optimized MIPv6, without the reflector spoofing hole, are the same as that which would be needed to remove the extra overhead. In short, if the security for MIPv6 with overhead based tunneling has no issues; neither does ZOD/MR. ZOD. If you could give me an example of where it might be different I can respond to the concerns?

Again, this is about the genericity.

> I'd really like to see someone attempt an efficient implementation of secure route optimized mobile IPv6 (i.e. without the reflector spoofing hole) that doesn't keep the same state. If you see a problem with this state end to end, then you must see the same problem with all of the overhead-based methods that also require this state. This was the entire message of the draft: "Because you have to keep this state to do RO in a secure manner, you don't need the overhead". I guess MIPv6 with any of the overhead based methods has the same downside to it.

The state issue is not about its specific use in MIPv6 but about generic
use of state in ZOD-based forwarding. I withhold this argument if people
see no problems with it, it is just a guess generic stateful forwarding
may get some reservation due to robustness, it not using normal routing etc.
Anybody reading this has the opportunity to prove me wrong on this.

> Again, the "other uses/other purposes" duplicate argument doesn't hold water because as there is nothing in the packet for the firewalls to block or worry about. The issue with "others" is not there. ZOD is transparent to firewalls.

Firewalls is not the only other use, the issue was more of recognizing
there is not yet understanding whether the generic part has the concensus
to be standardized.

> > - Interaction with IPsec
> >
> 
> I did, indeed, detail the interactions and processing rules in relation to IPSEC. This detail includes the of order of operations of each component. If you see an specific issue, please detail it?

Re. above one example.

> Again RO'd MIPv6 will have to be just as stateful unless you want to keep the reflector hole. If we keep the hole, it will eventually end up being blocked by firewalls anyway. I.e. a few days after a worm starts to take advantage of it. Actually it may be blocked from day one if the hole exists.

Agree with that. If current HAO is not checked against BCE, the hole exists.
State needs to be there for RO and HAO checked against authorized BCE.

> Again all of the alternatives (D/Z, RH, HAO, ZOT, MR. ZOT) will all have to keep the same state in order to protect against the reflector spoofing. The fact that the draft introduced other modes of operation should not have a bearing on MIPv6's application of a specific mode. This thinking is a logical fallacy.

Comments above should apply to this.

> The overhead of the extra address on the paths between the MN and CN is a waste for MIPv6.

Agree on that

> Glenn

BR,

-Jari