Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 18 Oct 2001 11:20:49 -0500

Francis,

>    Do you believe there might ever be a need to send a 
> binding update in the
>    same packet as an RSVP or something similar message?
>    
> => I don't fully understand your question but:
>  - I really believe that piggybacking is a bad idea

GM] I'm not so sure. I will try to explain why below.

>  - if your example is RSVP because of the router alert option in
>    a hop-by-hop header, a BU as a (final) destination option should
>    be processed correctly (i.e. the whole extension skipped) by every
>    intermediate routers

GM] My example is RSVP because I think RSVP would have to know about the
binding in order to operate properly. If you get rid of piggybacking you
have pretty much nuked the non-vertical solution and will force solutions
that put address bindings in RSVP (i.e. vertical).

GM] Piggybacking seems to allow both the vertical model and horizontal
models. I.e. I can still do RSVP without mobility and I can still do
mobility without RSVP and with piggybacking I can do both in a synergistic
manner.

GM] I don't think that the RSVP processing would operate correctly if it we
not aware of the address binding. 

This brings up another point; namely, that it is highly likely that the
credentials used by an MN for the SAs of RSVP on the first hop would be
exactly the same as the credentials for MIP binding updates. I think it
would be pointless to include two sets of credentials and/or digests in the
same packet and perhaps even do integrity checks twice in some
implementations.

And this brings up my final point - perhaps MIP BU integrity checking and
mechanisms should be more like the trust model used with RSVP and active
networks. If RSVP bandwidth/DS signalling (not int-serv) integrity works and
scales then MIP integrity should work and scale. If MIP was changed to begin
using the router alert then the authentication objects of RSVP might be able
to be re-used as a new common h-b-h header that could be used by many tools
and network-layer service functions.

>  - the burden is not so high (when you put a hop-by-hop extension,
>    you definitely ask for the slow and hard path :-)

I think it is just a matter of time before someone starts saying let's use
RSVP signaling for route optimized macro mobility. I'd prefer to use both
pre-existing works as best we can to come up with a good horizontal
solution.

I'm just trying to get people to look ahead a bit in their proposed
solutions to realize the ramifications. I would like it all (layer 5, MIP,
RSVP) to work together and be a clean unencumbered design that function
synergisticly to acheive (personal mobility, network node mobility and
network resource signaling). Killing piggybacking seems to me to be in the
wrong direction for this goal.

Regards,

Glenn

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Oct 2001 11:42:08 -0500

Hi Glenn,
  I read your long email, talking about vertical and horizontal
solutions. I do not quite get what you are referring to (any drafts,
RFCs, books, papers, etc)?
  A simple question: you are saying that RSVP would not work with MIPv4,
aren't you?
  BTW, QoS issues to my knowledge will go to NSIS WG yet to be formed.
Regards,

Glenn Morrow wrote:

> GM] My example is RSVP because I think RSVP would have to know about
> the binding in order to operate properly. If you get rid of
> piggybacking you have pretty much nuked the non-vertical solution and
> will force solutions that put address bindings in RSVP (i.e.
> vertical).
>
> mobility without RSVP and with piggybacking I can do both in a
> synergistic manner.
>
> GM] I don't think that the RSVP processing would operate correctly if
> it we not aware of the address binding.
>
> This brings up another point; namely, that it is highly likely that
> the credentials used by an MN for the SAs of RSVP on the first hop
> would be exactly the same as the credentials for MIP binding updates.
> I think it would be pointless to include two sets of credentials
> and/or digests in the same packet and perhaps even do integrity checks
> twice in some implementations.
>
> And this brings up my final point - perhaps MIP BU integrity checking
> and mechanisms should be more like the trust model used with RSVP and
> active networks. If RSVP bandwidth/DS signalling (not int-serv)
> integrity works and scales then MIP integrity should work and scale.
> If MIP was changed to begin using the router alert then the
> authentication objects of RSVP might be able to be re-used as a new
> common h-b-h header that could be used by many tools and network-layer
> service functions.
>
>
> I think it is just a matter of time before someone starts saying let's
> use RSVP signaling for route optimized macro mobility. I'd prefer to
> use both pre-existing works as best we can to come up with a good
> horizontal solution.
>
> solutions to realize the ramifications. I would like it all (layer 5,
> MIP, RSVP) to work together and be a clean unencumbered design that
> function synergisticly to acheive (personal mobility, network node
> mobility and network resource signaling). Killing piggybacking seems
> to me to be in the wrong direction for this goal.
>
> Regards,
>
> Glenn

--
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S CTO2
1201 E. Campbell Rd.
Richardson, TX 75081-1936 USA
Email : [email-masked]
Phone : (972) 996-5075 Fax : (972) 996-5174