Subject: [Seamoby] Issue 2: CTAR Response Needed

From: "James Kempf" <[email-masked]>
Date: Thu, 26 Jun 2003 14:00:04 -0700

Issue 2 questions why there is no CTAR Response. I think this issue is
related to Section 4, Open Issues, in which the only open issue is failure
handling.

The current protocol has no way for the MN to know whether or not the
context transfer (and thus the handover) succeeded. In some cases, an
application, like AAA, on the MN might have to run the protocol from scratch
in order to re-establish the context. In other cases, like header
compression, the context would get reestablished automatically as packets
showed up at the router/MN with full IPv6 headers.

So, I think there is a need for a CTARR to tell the MN whether or not the
CT.

Comments?

                jak

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Jun 2003 14:24:48 -0700

Hello folks,

For the contexts that I have thought about in detail,
such a response doesn't seem clearly necessary.

- For header compression, I think the response is
  clearly unnecessary, because the mobile node
  might not be able to use the information in any
  useful way.

- For QoS, it could be that the CTAR response would
  not have the important information, and that the
  QoS protocol mechanism would be in charge of supplying
  the necessary error status.  I tend to think that
  the CTAR response should say whether or not the QoS
  context succeeded, but we don't know this yet from
  NSIS.  If anyone thinks the matter is clear, then
  maybe some discussion would help.

- For buffering, I think clearly no response is
  needed.

- For security, I think that the answer is still
  not clear, and it might depend on the reason why
  the security context could not be transferred.
  But I did not feel comfortable saying that we
  should automatically inform prospective security
  clients that their credentials are invalid.

Perhaps the right answer is that, once a context is
clearly identified as needed a CTAR response, at that
time we could create the protocol message.  Then, it
would be a matter for the feature profile to specify
whether the particular context type needed to allow
for CTAR response or not.

If that time arrives, then someone will have to make
the further determination about whether only negative
responses are needed, or whether responses are needed
even for positive results.

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Jun 2003 15:07:23 -0700

This could be useful during failures, depending on
the particular feature context. So, a place-holder for
now might be appropriate.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 Jun 2003 15:18:31 -0700

Hi Charlie,

Agree on header compression and buffering.

Security is a little murky:

    - If you mean IPsec SA context (like, for example, to secure the FMIP
signaling) then I agree, but I'll note that there are some security experts
that question the security of context transfer for this purpose in the first
place.

   - If you mean basic network access authentication as provided by AAA,
then I disagree. Suppose a transfer is attempted of basic authentication and
it fails. How would the MN know to redo network access authentication so it
could start getting routing service? One place where AAA transfer might fail
is at the boundary between two administrative domains, but it could also
fail for other reasons.

    - If you mean firewall properties (in the sense of Defcon), then I think
I disagree because the MN needs to know if it must re-establish the firewall
filters, otherwise it might stop receiving traffic and not know why. The
assumption here is that setting up the firewall filters is a co-operative
effort between the network and MN and that they are not simply installed by
the network (which a variation of the Defcon assumption).

For QoS, I'm not quite sure I follow your explanation. It seems like what
you are saying is that a CTAR response might not have access to whether the
QoS context establishment failed or not, right? But what connection does
that have with NSIS? My understanding (perhaps incorrect) is that NSIS is
simply a signaling mechanism. The success or failure of the QoS context
establishment should be independent of the signaling to establish it in the
first place. Or is the assumption that establishing the context after
transfer goes through the same steps as the signaling protocol would?

W.r.t. QoS, it seems like one would need to examine what context would be
established (and here I think we are talking about Intserv kinds of context,
or maybe a subset of the kind that would be involved in Intserv, like a
basic bandwidth and latency allocation, since I believe Diffserv is
stateless w.r.t. individual flows).

            jak

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 27 Jun 2003 01:27:26 +0200

Hi,

I suppose this might be one of the potential reasons why CTP came into
being. A CTP-friendly NSIS needs adding/readjusting a few features
(message format; refreshment; security), though.

Xiaoming

James Kempf wrote:
> 
> So it sounds like NSIS could benefit from knowing whether the CT succeeded
> or failed?
> 
>             jak
> 
> From: "Xiaoming Fu" <[email-masked]>
> Cc: "Charles E. Perkins" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 26, 2003 3:44 PM
> > Hi James,
> > In my understanding NSIS is trying to deliver different context (for
> > different signaling applications, such as QoS resource reservation) to
> > network nodes. If NSIS knows CT succeeds, it would not need to deliver
> > QoS context from the MN along the nAR, thus saving wireless bandwidth;
> > rather notifies (using shorter signaling message) the nAR to use that
> > from CTD.
> >
> > >
> > IMO QoS signaling for DiffServ could be also necessary, e.g., for
> > marking/metering purposes.
> >
> > Cheers,
> > Xiaoming
> >