Re: [Seamoby] Moving forward with paging

[Marco Liebsch <[e-mail]>]

Pat and all,

proposing a protocol as starting point, I think the decision process
described in the assessment-01.txt addresses the right things and the
independence and flexibility of the draft-renker concept has been
understood. Therefore, I support the opinion of many others to keep
draft-renker as a starting point.

With respect to technical feedback on the assessment draft, I would like
to refer to my mail from Dec., 4th, 2001, where I covered feedback on
most of the issues addressed for draft-renker-paging-ipv6-01.txt.
If desired, I can send the mail again to the list.

In addition I would like to add some comments now:
wrt requirement 4.6:
As the assessment-01.txt indicates, multiple dormant modes should
address MTs, that have no explicit L2 paging support. The architecture
and protocol in draft-renker allows to keep access technologies
specifics transparent to the IP paging protocol up to Access Routers,
but allows mapping to any specifics at the Access Routers. This can be a
mapping to L2 wake-up/paging mechanisms, but might be a mapping to
link-local L3 paging (for example a solicited node multicast). This
concept allows easy integration of time-slotted paging from ARs in order
to improve efficiency of dormancy.

wrt requirement 4.19:
I don't think that this issue has been addressed correctly, since we
decribe how to authenticate paging related signaling by IPSec AH, like
other proposals do. Some security issues are addressed in the Security
Consideration section, but not describing threads addressed in RFC 3154
already. We described how our concept integrates into an IPSec
framework, but does not discuss establishment of SAs (as none of the
other drafts does). The deployment of the AAA framework as key
distribution center is described roughly.
In general, as addressed on the list already, the security issue is
obviously one of the issues requiring a lot more study and discussion.

wrt 4.20:
Same as 4.19, the assessment criticizes that the protocol relies on BUs,
which is not correct. It's only the case for MIPv6 optimization, as
described. For the generic (explicit signaling) case, which is the one
to be considered within the Seamoby WG protocol specification, IPSec AH
is deployed for signaling message authentication. The advantage of an
IPSec approach is also to support authentication of signaling messages
independent of UDP or IPv6 Destination Option transport.

wrt 4.21:
true, but advertising PA info from the attendant function located on
each Acces Router allows to authenticate and to keep this info broadcast
away from RtAdv specifics.


Regards,

Marco




"Pat R. Calhoun" wrote:

>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks for the feedback. However, what would be much more useful is
> to provide comments on the assessment draft. If you believe that the
> technical assessment of a particular draft is incorrect, please make
> that statement. Perhaps the new text could justify the selection of
> another draft as the starting point.
>
> PatC
>
> - -----Original Message-----
> From: Behcet Sarikaya [mailto:[e-mail]]
> Sent: Wednesday, February 06, 2002 1:39 PM
> To: Pat R. Calhoun
> Cc: [e-mail]
> Subject: Re: [Seamoby] Moving forward with paging
>
>
>


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