Subject: [Seamoby] Issue 15: CTAR Relay

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

The last paragraph of Section 5.4, it says that CTAR Relay routes to PAR,
but the routing details are given later.

Is CTAR Relay really necessary? Isn't it sufficient to either a) send CTAR
to NAR (as currently) or b) send CTAR to PAR?

Note: FMIP has chosen to do b), why does CTP do a) instead?

I'm especially curious because the CTP and FMIP drafts share an author and
one of the authors on the CTP draft was on the original FMIP design team,
which would have suggested to me more consistency in the basic architecture
between the two protocols.

            jak

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Jun 2003 11:21:05 -0700

> but the routing details are given later.

So in the interest of simplifying the draft, I'd like to propose removing
CTAR Relay from the draft for now. There are some security issues with it,
and it is currently not well enough specified in the draft that it could be
implemented. It could take quite some time to work these out, and we need to
finish the draft. Since the draft is experimental, people could experiment
with it, and we could revisit the issue, with some actual data, when and if
the specification is put on the standards track.

The editoral changes would be:

Section 2.4: First sentence, remove terminating phrase ("it should be...")

Section 5.4: Remove CTAR Relay from diagram and text following the diagram.

Comments?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Jun 2003 16:07:51 -0700

> to NAR (as currently) or b) send CTAR to PAR?

I think CTAR alone should be sufficient.

> Note: FMIP has chosen to do b), why does CTP do a) instead?

Actually, if possible MN sends CTAR to PAR before leaving the
link. Since it does not wait for a confirmation from PAR regarding
success of CT, it always send CTAR to NAR. This way, if CT
succeded, NAR would verify authorization and make contexts
available right away. If it did not, OR if the MN was unable to send
CTAR on the old link, the CTAR to NAR triggers CTD Request
and CTD messages. Notice that in both the cases token verification
takes place at the router possessing the contexts.

This is like transmitting FBU when FBack has not been received.

Regards,

-Rajeev