Subject: [Seamoby] CAR Discovery Requirements ... Call for Comments

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 20 Feb 2002 12:38:50 -0500

Hello all,
I hope that you have had a chance to read the CAR Discovery Requirements 
draft. I request you to post any comments that you may have on the document 
soon, so that I would have the time to incorporate them in the document if 
we have WG consensus.

Regards,
Govind.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 22 Feb 2002 16:42:13 -0600

Govind, 

not sure if I making the deadline or not. Sorry if I bring up
things that have been discussed on the list, I only go based
on what I see in the draft:

Don't know if inter-domain is included in the discussion,
but I am guessing since you mentioned multiple access technologies
and multiple mobility management mechanism, I am guessing that
multi-admin domain is in scope: in that case, you would have several 
issues

1-I didn't see any security requirements, it depends on how
much of the policy and capability information can be shared
with the MN, one example is the location and info of all the 
network management units behind the ARs, another is the network
topology information.

2-since CAR is carrying capability information (I am guessing
this would also mean availibility of resources) then signaling
of network policies might be an issue. I did not see any info
on policy.

Regards,

Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 11:39 AM
To: [email-masked]
Subject: [Seamoby] CAR Discovery Requirements ... Call for Comments

Hello all,

Regards,
Govind.

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Fri, 22 Feb 2002 23:03:34 -0500

Madjid,
Thanks for your comments. My responses are embedded.
Regards,
-Govind.

>multi-admin domain is in scope: in that case, you would have several

------> Yes, we do include inter-domain in the requirements.
Requirement 3.6, talks about this. As for  now support for
inter-domain CAR discovery is a SHOULD and not a MUST.
Do you feel that support for inter-technology as a MUST might imply
this requirement to be a MUST too?

>network management units behind the ARs, another is the network

-----> Requirement 3.4 states that capabilities MUST be transferred in a
secure fashion. If I understood you right, are there  special security 
requirements for CAR discovery w.r.t to different domains except the ones we 
have to deal with establishing an SA between two ARs in different domains. 
If you feel any particular security requirements text needs to be added, 
please post it.

>of network policies might be an issue. I did not see any info

-----> You are right that policy information may be a capability that needs 
to be transferred. The requirements draft does not define the capabilities
or their formats (yet). It has been left as TBD. But there hasn't much 
discussion done on this topic. Do you feel that you would need special 
signalling for network policies as capabilities? Or for that matter
any other capability?

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: [email-masked]
Date: Mon, 25 Feb 2002 08:36:45 -0500

Hi Madjid,

Thanks for your comments, see my comments inline.

> network management units behind the ARs, another is the network

I don't quite understand what you're exactly after. The cap. information 
as such is to be tranfered in a secure manner which is included in the 
requirements. The question whether it makes sense to share said information 
with an MN is a different discussion. It is up to the AR (as a member
of a particular domain) to share information. If the AR is revealing 
such sensitive information, it is not the problem of CAR discovery,
apart from the mere transfer aspect.

> of network policies might be an issue. I did not see any info

CAR discovery is supposed to cover capability information exchange.
However, it is not within the scope of CAR WHICH information eventually
will be transfered. But in the problem statement, exchange of policy
information is mentioned as an example what could be exchanged in such
capability transfer. I don't think that we have to put this again in
the requirements draft.

Best Regards,

Dirk

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Feb 2002 18:14:37 -0600

Govind,
Thank you for my email. I guess I was a bit sloppy in my reading. 
I guess I wanted to leave early that Friday (blame it on the Olympics :) )
 I appologize for that, comments below,

BR,
Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:[email-masked]]
Sent: Friday, February 22, 2002 10:04 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments

Madjid,

MN>> Thank you for pointing it out. I missed that sentence. 
The implication of intertechnology on inter-domain is scenario
independent. I have a feeling, you would have a variety of cases,
both when various access radios are owned by same operator/admin
authority, and when they are not. So that is tough call, but
a SHOULD is a good interim goal to keep everybody happy:)

MN>> Boy, I missed that last sentence too :( 
However, in your dynamic CAR case (If I remember correctly)
 MN is handling the selection process. This means it is getting
information from ARs that it might not already have SAs with, correct?
If that is correct, especially if this information is more than
just signal strength and include sensitive network management information,
then there is a security issue, since the MN is not a trusted node
for those networks, and the MN can't have SAs with all the ARs that it
might come across? am I missing some point?

MN>> Yes, I would think policy info is important type of 
"capability information" for QoS management, admission control
 are related, right? and admission control is an important part
of a successful handover, so possibility of a need for policy
signaling exist. We might not have to do design the signaling
here, but CAR signaling can be used as a vehicle.
UNLESS, capability is transferred by context transfer, we did have
that discussion at some point, so this might be a scope issue.

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Feb 2002 18:23:19 -0600

Dirk,

Thanks for your email, see below.

BR,
Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 7:37 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments

Hi Madjid,

Madjid>> I responded to Govind on this issue. However, to respond
to the above, my issue is, say the MN needs some information before
the handover, that the AR thinks it is too sensitive to be shared, then
the whole thing would fall apart in an inter-domain scenario??

Madjid>> Sounds fair. However, If you need an AR-AR signaling,
you can extend Context transfer to handle capability (this
was discussed a lot last year). if you need
AR-MN signaling  you would still have the issue of AR-MN trust.  

Just a thought,

BR,

Madjid

Best Regards,

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Feb 2002 23:55:28 -0500

Madjid,
My comments inline. Thanks for your comments again.
Regards,
Govind.

>a SHOULD is a good interim goal to keep everybody happy:)

------> It is a SHOULD right now.. so that settles this issue then.

>might come across? am I missing some point?

-----> There was some confusion about what dynamic discovery means.
It was later  (in version 02.txt) defined as being done on the fly during 
the handover process(any network node/MN can do it) and anticipated implies 
that the discovery is done prior to the handover (again any network node/MN 
can do it). So I guess thatIf the MN has a security association with the 
current AR and the current AR has a
SA with the new AR then we are through, is it not? Do you see any other
problem?

>that discussion at some point, so this might be a scope issue.

-----> CAR discovery, I believe, occurs prior to context transfer. So it 
cannot be associated with that.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 26 Feb 2002 10:23:16 -0600

Govind,

Please see my comments below.

BR,

Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:[email-masked]]
Sent: Monday, February 25, 2002 10:55 PM
To: [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments

Madjid,

Madjid>OK. However, remember that the original attraction of
CAR as a protocol will be greatly diminished (IMHO) if it can't 
handle inter-domain.

Madjid>> Well, not quite, there are two issues, first
The AR-AR SA is a big IF, in case of inter-domain (I am guessing
you are dealing with more than just one new AR, right). Now, since
inter-domain is a should, I give up on this, lets move to the second
issue, you seem to be assuming that from oldAR-MN and oldAR-NewAR
SA you can deduce newAR-MN SA? How, you said that CAR comes before
Context transfer. 

Madjid>> Good point on capability issue,
 but see my previous comment on security. BTW, did you agree on
the policy issue, that I mentioned in previous email (above)?

Regards,
Madjid

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Feb 2002 18:05:54 -0500

Madjis,
My comments are inline.
Regards,
Govind.

>CAR as a protocol will be greatly diminished (IMHO) if it can't

----> Thats why we  have to decide whether it is a SHOULD or a MUST.

[snip]
>SA you can deduce newAR-MN SA? How, you said that CAR comes before

------> Agreed that old AR - new AR SA maybe a toughie, maybe SIKED can help 
us with this :)

But once that is established we can have two tunnels is it not? One tunnel 
to the old AR from the MN and then another tunnel to the new AR. Ofcourse, 
this is a trivial solution and may not be the optimal way to go, but wont 
this work?

[snip]
>the policy issue, that I mentioned in previous email (above)?

-----> I agree that policy information may be important to transfer.
I also agree that nothing special signalling is required for policy as you 
seem to point out.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: [email-masked]
Date: Tue, 26 Feb 2002 18:08:27 -0500

Hi Madjid,

thanks for your response, see comments below.

> From: ext Nakhjiri Madjid-MNAKHJI1 
> [mailto:[email-masked]]
> Sent: Monday,February 25,2002 7:23 PM
> To: Trossen Dirk (NRC/Boston); Nakhjiri Madjid-MNAKHJI1
> Cc: [email-masked]

In an MN-based decision approach, the selection of a TAR is still possible
in general since it is always under the constraint of the revealed
information. It is certainly true that this constraint is more stringent
in the N case. But that's a drawback which lies in the fact to put the 
decision in the MN. You could do this also in the AR. 

> AR-MN signaling  you would still have the issue of AR-MN trust.  

I don't want to go too much into using context transfer for
AR capability transfer since it is certainly not the scope of
CT to do this. Though I'm not saying that the pure transfer of 
the capabilities is much different from the transport of context.
But with this thinking, you probably have to redefine lots of CT
requirements (I'm not that much in this to explicitly point out which
ones) to cover AR-related information exchange in general.

Right now, the requirements cover the capability exchange which is
meant to happen between ARs. As for a capability transfer from the
AR to an MN for performing a TAR selection in the MN, we could 
incorporate this by extending requirement 3.4 in the way that
each transfer of capability information within CAR has to happen
in a secure manner. We should probably then also rename the heading
of 3.4 in 'capability transfer'. You should also keep in mind that
that the MN gets the information from the old AR, so it is enough
to an SA between MN and old AR. The old AR (hopefully) has information
regarding the potential new ARs (AKA CARs) which are then transferred
to the MN. I have to admit that I didn't get your comment in a mail
to Govind that you need an MN-newAR SA? For what is this in the 
context of CAR. CAR discovery is meant to determine the new AR, so
why should I have an SA to this entity in the process of CAR??

Regarding the inter-domain SHOULD issue, I agree that CAR without
inter-domain reduces the relevance of CAR a lot. That's why I think
that MUST is better.

Regards,

Dirk