Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt

From: Gabor Fodor <[email-masked]>
Date: Mon, 1 Jul 2002 19:31:41 +0200 (MET DST)

Hi Cedric, 

Thnaks for your answers, I would like to discuss
one of your points here, which I believe
is important:

[...]

> 
> [GF]
> 4
> I am not sure that it is meaningful at this point to start
> discussing specific solution approaches. You seem to propose
> to use ICMP as a design base for both edge signaling and for
> context transfer (AR to AR). At least for the edge signaling,
> we need to consider the edge specific requirements before
> we start discussing what existing or new protocol can be the
> design base for that.
> [GF]

> Let me explain a bit here: the design base for edge signaling and
> context transfer is
> really 'A context transfer protocol for seamless mobility',
> draft-koodli-seamoby-ctv6-03.txt.
> Earlier version of draft-koodli-seamoby-ctv6 were ICMP based. However,
> it is more general in this latest version, and not necessarily ICMP. As
> a consequence, we mention ICMP
> as a possible illustration. The main point is that QoS signaling is
> redundant with context transfer, one object being transferred being QoS
> context, and that CT signaling will do the job for the MN to AR QoS
> signaling. 
> We will clarify this point.

[GF]
We need to understand and analyze better the requirements on the edge
and the CT signaling protocols. You make a good point : the QoS signaling
is to a great extent redundant with context transfer 
(which makes the re-use of the same design attractive), but there
may as well be important differences that are connected to the
wireless interface itself. I believe that there are scenarios where
transferring the context from AR1 to AR2 is not sufficient to exercise
admission control at and make the mecessary configurations of the new
wireless link. I think we need to list the requirements for the edge
protocol and go check how those are fulfilled 
with differenet alternatives.
[GF]

/Gabor

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Xiaoming Fu" <[email-masked]>
Date: Mon, 1 Jul 2002 22:50:12 +0200

Hi Hemant and Cedric,

Some comments inline:

> [Hemant] In this draft, we have considered following requirements as prime ones: air
interface bandwidth saving, fast QoS establishment after handoff,   authentication of
handoff-induced signaling (to avoid spoofing attacks) and minimizing the impact of signaling
on the segment of packet path that remains unchanged after handoff.

[XF] What you presented in this draft is quite interesting. Suggested ways of locating of
crossover router and crossover router-related authentication are tricky, eg.,
       - borrows a  "Previous hop" way in RSVP to record the backward route
       - using TEAR DOWN to release unauthenticated request, and
You also consider the integration of context transfer procedure at first place.

[XF] While you heavily consider depreciation of over-using wireless bandwidth, I think there
is a concern that resources in access networks are limited as well. It then makes sense to
release the unnecessary resources as quick as one can. This implies your TEAR DOWN is helpful,
even if you deploy a soft-state way. If we take the default value of time-out in RSVP (30s), 5
times larger than the default refreshment timer, as an example, it may take long to timeout
the reserved resources even a mobile user moves to another point of attachment or his request
being rejected by the crossover router. Therefore, while soft-state is the realistic option (I
think due to best-effort feature of Internet transmission and dynamic routing, any state
potentially kept in the routers would be dangerous!), releasing message is still needed.

[XF] I'm not of a security expert, but it seems to me the entity performing authentication for
a QoS request is the crossover router. Is it sufficient enough? Again the resources in access
networks are limited, what if a misbehaved router (between MN and crossover router) modifies a
QoS request? Then rest of routers would better be untouched, instead of reserving resources
on! And what if an MN doesn't really want to consume QoS he requested? I think we should
protect this DoS at the very edge (e.g., AR)!

[XF] It looks like IPv6 signaling is your main focus (e.g.,<IPv6 flow label, MN new CoA, CN
CoA) as flow classification param.). I think this can be extended for IPv4 as well without
much problem.

> 3
> The draft talks about the negotiation procedures (in 4.2).
> In my opinion the draft should identify the requirement more
> clearly, preferably with a reference to either the NSIS or
> the mobile IP requirement draft. Is there a difference between
> negotiation (which takes place upon QoS initiation time) and
> QoS adaptation signaling which may take place upon hand-over ?
>
> [Hemant] We have advocated one pass reservation approach in the interest of speed of QoS
establishment (in other words, minimize the number of packets that may get default forwarding
treatment after handoff, just because QoS signaling has not yet completed). In most of the
handoff cases, the request will be granted. But, there could be cases when requested QoS <
offered QoS, and then, MN may choose to have control over decision as to whether to continue
or terminate the session. For this case, we have provided fallback mechanism in the form of
negotiation procedure. If the MN knows at handoff time (e.g. handoff from 2.5G to WLAN or vice
versa) as to whether it needs to adapt QoS after handover to the characteristics of new
access, it will put the adapted QoS parameters in the QoS signaling packet in the first place.
Even after that, if some router cannot offer the requested QoS, we have negotiation procedure
as fallback.

[XF] In this way, you may implicate somewhat complicated application interface(s). How about
push some complexity into the networks (though some violating Internet design principles, but
maybe beneficial in wireless/mobile environments), say, put adaption QoS data in the AR (and
let AR to decide whether to depreciate or increase a session's QoS - in fact ARs could know
this e.g., by checking the AP interfaces)? An AR can gracefully forward on those info to new
ARs given a first one by the MN.

> 6
> You identify QoS release as a necessary functionality.
> Here there is a need to identify if the protocol should
> support soft state (in which case this explicit QoS release
> may not be necessary) or not.
>
> [Hemant] In soft state approach, explicit TEAR DOWN may not be required. Of course, if
inter-REFRESH period is chosen long enough to save REFRESH signaling overhead, TEAR DOWN can
still help. Finally, if we go for soft state & no tear down approach, the TEAR DOWN part of
the protocol can be gracefully omitted.
[XF] See above.

Regards,
Xiaoming

---

From: [email-masked]
Date: Tue, 2 Jul 2002 18:16:55 -0400

Hi Xiaoming:

Please see inline:

------------------------------------snip---------------------------------------
on! 

[Hemant2] I think from security perspective (not DoS perspective though), it may suffice to do authentication in crossover router. This is because, crossover router happens to be on existing data path and it is reasonable to trust entities on the existing data path. 

[Hemant2] The kind of DoS attack that you mention is still possible. It is even possible from malicious "hosts" spoofing the QoS request. The malicious host may send many spoofed QoS requests, only to be later rejected by crossover router. With forward reservation approach, in addition to causing processing overhead of creating resource reservation and authentication, the host can even get a small burst of packets transmitted with QoS until authentication failure is detected. One can defer resource comittment until authentication succeeds (this can be implemented by CONFIRM message in the current solution). This prevents free QoS use for the small burst I mentioned above, but still causes processing overhead. But, if you do not use forward reservation approach, you loose on speed of QoS establishment front for genuine QoS requests. There is a tradeoff here. 

[Hemant2] However, we think that the current mechanism of authenticating QoS signaling does prevent a situation where malicious node disrupts the ongoing QoS of mobile node, either by sending QoS request to make it appear as if handoff has occured or by reducing the QoS requested. 

And what if an MN doesn't really want to consume QoS he requested? I think we should
protect this DoS at the very edge (e.g., AR)!

[Hemant2] What is the problem if MN does not consume the requested QoS, as long as it is paying for it? Nonetheless, it will be good if we can detect the DoS attacks of the kind mentioned above at AR itself.

[Hemant2] Yes, I think it is only matter of using right packet classification parameters.

[Hemant2] Yes, ARs acting on behalf of MN is definitely possible and is within the scope of current solution framework. When we say, MN decides, it is perfectly OK that AR can decide on MN's behalf if AR knows MN's preferences.

[XF] See above.

Regards,
Xiaoming