Subject: RE: [seamoby] Some proposed changes to the requirements draft.

From: "Shaheen, Kamel M." <[email-masked]>
Date: Wed, 14 Nov 2001 13:45:04 -0500

I would respectfully disagree.  I think it would be beneficial to this work
to understand and to take previous work into consideration (not necessarily
to duplicate) if we would like wider acceptance and more generalized
solution.  Specially given the current drive toward global more harmonized
kind of interworking.

Regards,

Kamel 

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Wed, November 14, 2001 1:34 PM
To: 'James Kempf'; Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel
M.; Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Thanks, 

I agree. Our requirements can't look like UMTS requirements.

The UMTS/ GPRS need for context transfer is definitely
 a topic of interest, BUT in a separate ID. I will look forward to reading
it.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 11:32 AM
To: Gary Kenward; 'Shahrier, Sharif M.'; Shaheen, Kamel M.; 'Nakhjiri
Madjid-MNAKHJI1'
Cc: [email-masked]
Subject: Re: [seamoby] Some proposed changes to the requirements draft.

Gary/Sharif,

I certainly agree that we should not be tayloring our requirements for
existing UMTS/GPRS networks. The requirements should define the
properties of a desirable solution for the Internet.

Regarding the specific requirement, about authentication, as Majhid
indicated, the thread is closed. CT happens between ARs or other
entities involved in routing in the wired network. The MN isn't
involved. If you look at the problem statement (the latest draft of
which is on my disk ready to go), that's how it is defined. So the
authentication involved is between ARs.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Shahrier, Sharif M.'" <[email-masked]>;
"Shaheen, Kamel M." <[email-masked]>; "'Nakhjiri
Madjid-MNAKHJI1'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2001 7:40 AM
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

> Sharif:
>
>    One thing that I am pretty sure Seamoby is not going to get into,
is
> exploring the world of
> internetwork authentication. CT needs it, yes, but will Seamoby be
defining
> the solution?
> As far as I know, it's not in our charter. Just as defining new
security
> protocols for CT was
> place out of scope very early on in the discussions.
>
>   You have valid points, many were discussed last spring. It doesn't
hurt to
> revisit issues, for
> we are constantly expanding our understanding of this problem domain
(or, at
> least I hope so).
> However, in my delusional view, we all need some real solution
proposals to
> chew on in order to
> really progress.
>
>   I realize that for you, the situation is very different. You have a
real
> system with real issues
> to resolve. It is only one of many networks however, and perhaps a
better
> way to get the wg up
> to speed on the specific requirements of UMTS (and other networks) is
to
> schedule some presentations
> at the next IETF on existing context transfer problems/solutions. What
say
> you Pat and James?
>
> Gary
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: November 14, 2001 09:52
> To: Shaheen, Kamel M.; 'Nakhjiri Madjid-MNAKHJI1'; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: [email-masked]'
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
>
>
> Majid,
>
>             To add to points Kamel had made, I would also like to add
> another point.
>
>             Given that there is a trust relationship between AR's in a
> specific domain, where there is no need for authorization. If the MN
then
> were to "roam" to a different administrative domain, where there may
be no
> trust relationship between the AR's in the previous domain and the new
> domain, how does the target AR in the new domain ensure that it is
using the
> right context to serve the right MN?
>
> -Sharif.
>
> -----Original Message-----
> From: Shaheen, Kamel M.
> Sent: Wednesday, November 14, 2001 9:36 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
> Cc: [email-masked]
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
>
> Madjid,
>
> I have some questions for clarifications.  First and before going into
the
> details, I would like to understand the focus of the work.  Is it only
> concentrated on the context transfer?  or It involves the hooks that
are
> necessary to ensure that right contexts are at the right ARs serving
the
> right MNs?
>
> I would agree with you that the authentication will take place between
the
> ARs before any CT takes place, may be as in wireless environment there
is a
> trust relationship between certain ARs where there is no need for
> authorization.
>
> However, if the MN is not involved in the CT.  How does the target AR
ensure
> that it is using the right context to serve the right MN?
>
> Regards,
>
> Kamel
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Tue, November 13, 2001 7:42 PM
> To: 'Shahrier, Sharif M.'; Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'
> Cc: [email-masked]
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
> Sherif,
>
> First I think the chairs closed this thread. Authentication has to
happen
> between ARs, since
> CT happens between ARs. If the MN was supposed to be involved in
context
> reestablishment,
> we wouldn't be here in the first place.
> Second, there are a lot of things that can go wrong with CT, and
failed
> authentication is one
> of them. Reliability for CT and the backup mechanisms for CT are still
open
> issues, but for sure
> a failed authentication at MN is not one of these issues and here is
why:
>
> after the two ARs have authenticated themselves to each other (maybe
once
> for all or maybe
> before a CT, I don't inject my opinion here), then they engage in CT.
The CT
> data can be
> authenticated if necessary. The receiving AR, will check the
authentication
> of context data.
>
> Architecture-wise, this is the only way to do it,  based on the fact
that
> only ARs do CT.
> And MN is not in this picture.
>
> Hope this clears things out.
> Madjid
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 3:17 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Shahrier, Sharif M.; 'Gary Kenward'
> Cc: [email-masked]
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
> Majid,
>
>             Consider the case where the context transfer occurs before
> handover. So, the context will arrive at the newAR before
>             The mobile node does. What if something goes wrong - the
context
> is not correctly received by the newAR.
>             When the MN arrives at the newAR, it needs to know this
fact.
> So, the MN should authenticate the received context, just
>             To make sure that its context was successfully received by
the
> newAR.
>
> -Sharif.
>
> Maybe you mean that the MN should authenticate the received context
data,
> but
> then why does the MN should do this. The context is going to the new
AR,
> anyway.
> If authentication of data is needed, new AR does it on behalf of MN.
>
> Why are we dragging MN into the authentication process.
>
> these issues are attacking the basic framework of CT, IMHO
>
> Madjid
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 10:44 AM
> To: 'Gary Kenward'; Shahrier, Sharif M.
> Cc: [email-masked]
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
> Gary,
>
>                 Understood. However, the requirements contains nothing
(?)
> about the mobile authenticating with its context, after the context
> Has been transferred.
>
> I think a requirement should be there for this, otherwise, without
> authentication, the MN can "get at" any context, or context feature
that its
> not authorized access to.
>
> How about:
>
>                 There MUST be mutual authentication between the MN and
its
> context, after the context transfer has occurred.
>
> -Sharif.
>
> -----Original Message-----
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 11:07 AM
> To: 'Shahrier, Sharif M.'
> Cc: [email-masked]'
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
>
> Sharif:
>
>   This requirement is for the ARs to authenticate each other so that a
ct
> exchange can
> be trusted. It has nothing to do with the MN and handoff per se.
>
> Gary
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: November 13, 2001 09:51
> To: Shahrier, Sharif M.
> Cc: [email-masked]'
> Subject: RE: [seamoby] Some proposed changes to the requirements
draft.
>
>
> I have some issues with the following requirement in the CT draft.
>
> 4.9 The entities transferring context MUST have completed a mutual
> authentication process prior to
>       initiating the transfer.
>
> I don't support this requirement.
>
> It appears to me this may not fit the case for "break-before-make"
handover
> .  For instance, the mobile may break connection with the old
> AP, and re-establish connection with the new AP.
>
> Assuming that the context is transferred prior to re-establishing the
new
> connection.
>
> The mobile will need to re-authenticate after it makes a new
connection at
> its new AP.
>
> I have seen several practical cases that supports this scanario, thus
I feel
> it is necessary for authentication after the transfer of context
> in "break-before-make".
>
> -Sharif.
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Nov 2001 10:58:11 -0800

Kamel,

This issue came up last spring. The IETF is specifically concerned with
standards for the Internet, it is the Standards Development Organization
(SDO) for the Internet. Working groups can consider the experience of
other standards development organizations when developing Internet
standards, that is simple common sense and good engineering practice. We
can also consider the needs of othe standards bodies for Internet
standards, just as we consider the needs of companies and individuals.
But any requirements or protocols we develop should be focused on the
Internet, not on standards developed by other standards bodies.

Hope that's clear.

            jak

----- Original Message -----
From: "Shaheen, Kamel M." <[email-masked]>
To: "'Nakhjiri Madjid-MNAKHJI1'" <[email-masked]>; "'James
Kempf'" <[email-masked]>; "Gary Kenward"
<[email-masked]>; "Shahrier, Sharif M."
<[email-masked]>; "Shaheen, Kamel M."
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2001 10:45 AM
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

draft.
draft.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 15 Nov 2001 21:36:22 -0800

> solution.  Specially given the current drive toward global more harmonized

Perhaps you've misunderstood. It is considered inappropriate to "present"
technologies at IETF meetings. There is no way that people can make a
real assessment in a 20 minute presentation. It is much better to
provide to submit an Internet-Draft and allow people to read it.

PatC