Subject: RE: [Seamoby] CAR Discovery Requirements

From: [email-masked]
Date: Wed, 13 Mar 2002 10:54:03 -0500

Hi James,

comments inline...

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 5:43 PM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CAR Discovery Requirements

Dirk,

Well, here we have a basic disagreement about what is involved in
TAR selection.

IMHO, TAR selection includes everything including communication
of MN requirements. The reason I believe this is because communication
of the requirements may require functions such as:

    - verifying that the MN is, in fact, authorized to get what it is
asking.

    - arranging for accounting information so that the owner of the MN
    can be billed appropriately for what it is asking.

    - authenticating the exchange with the MN so that the AR (or
whatever
    other network entity is involved in doing TAR selection) knows that
    they come from an authorized MN and not from a freeloader.

    - securing the exchange between the MN and the AR or other
    entity implementing the MN's selection.

These functions are separate from communicating routing reachability
and router capability information, even if the MN is involved in
propagating the reachability and capability information (as, I believe,
it may be in CAR discovery). The AAA functions are
completely orthogonal, as are the security functions.

[DOT] By all due respect, I'm kind of surprised to see these interpretations
at this stage of discussion. What I quoted in my previous email is the 
definition of CARs and the fundamental sentence in the problem statement.
In addition, here the definition of TAR selection:
"TAR Selection Algorithm

  The algorithm that determines a unique TAR for MN's handoff from
  the set of CARs. The exact nature and definition of this algorithm
  is outside the scope of this document.
" 
With all this information, available in the issues draft for quite a while,
I draw the following line
- discover GAARs and their capabilities
- determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements)
- select a unique TAR from this set (i.e., TAR selection)
I don't see that much room for interpretation of the terms, at least this
interpretation should have been done at appropriate time of the discussion.

[DOT] Further, the requirement to provide means to express MN's requirements
to be used for the determination of the set of CARs (as I stated in my requirement)
does not imply that we have to invent a new protocol for this part of CAR discovery. 
If I want to solve the CAR discovery problem (which according to the issues draft
include the determination of CARs), I have to have means to express MN's
requirements. These 'means' might certainly be existing protocols. 

[DOT] More philosophically, the requirements are meant to define a protocol
that solves the CAR discovery problem. The design of such protocol should always
be done under the constraint to re-use as much existing functionality as possible.
However, the first and strongest requirement is to solve the problem. To do, I do
think that this requirement is needed.

> and look at the fundamental task of CAR discovery, namely to determine
a set of
> CARs, it means logically for me that I also require means to express
> these requirements and feed them into CAR discovery. This does not
> mean that I need a new protocol for expressing these requirements.
> If I look at CAR discovery as a black box, and I want to define the
> requirements of this black box, to fulfill the implicit fundamental
> task that we put in the issues draft, namely
> "What is required is a protocol that would allow an AR or an MN to
discover
> the neighboring ARs whose capabilities meet the requirements of
> a MN, thus becoming potential target ARs for handoff." (copied from
> introduction of issues draft),
> I came up with this requirement. It merely says, that CAR discovery
has
> to provide this set of CARs that would meet MN's requirement. For
that,
> I need means to express MN's requirements. It does not imply that we
> have to invent the wheel again for this part, it merely has to be part
> of this black box to fulfill its task.
>

Perhaps what we need is "requirements for TAR selection." One
requirement
is that the MN communicate its requirements. 

[DOT] Since TAR selection is out of scope, I don't see the necessity
and sense of such requirements. As I pointed out above, the need to
communicate MN's requirements is already required for the CAR
determination. 

There is no need to for the AR to know the MN's requirements just to select GAARs.

[DOT] On what basis do you want to select GAARs? If you plainly determine
a subset of GAARs that are reachable by the MN at time of handoff (is it 
that what you mean?), then you are not determining CARs according to the
definition of CARs. You are plainly selecting reachable GAARs.

Regards,

Dirk

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 10:21:01 -0800

Dirk,

> interpretation should have been done at appropriate time of the
discussion.

Perhaps I did not state clearly enough what I was trying to say.

The point that I was trying to make is similar to the one the Scott
Bradner brought up at the last Seamoby meeting in SLC. The security/AAA
requirements on a protocol for distributing routing reachability
information are likely to be very different from those involving a MN
expressing its preferences for capabilities. For example, I believe
there is a separate IPsec policy for routing security as opposed to host
security. If the CAR discovery information is coming from a host and the
routing infrastructure is using this policy, then I would presume that
the host must, in some way ensure that the security requirements of the
routing infrastructure, and not for hosts, is followed. Similarly, for
communicating MN capabilities preferences, a host security/AAA policy
needs to be used and not a routing security policy.

Conflating these two is likely to result in problems, IMHO. So I believe
they should be kept separate.

And, in fact, this brings up another issue. The current requirements are
completely lacking *any* mention of security. But I will address that in
another note so as not to confuse the threads.

> requirements. These 'means' might certainly be existing protocols.

Agreed.

> think that this requirement is needed.

Agreed.

> definition of CARs. You are plainly selecting reachable GAARs.

I have no objection to including this requirement as long as:

    - The language makes clear that the requirement is not to force the
same protocol to perform CAR discovery and to communicate MN
preferences.

    - The distinction between routing security/AAA requirements for CAR
discovery and MN security/AAA requirements for MN preferences is
maintained.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 10:21:01 -0800

Dirk,

Agreed.

Agreed.

            jak

---

From: "Trossen Dirk \(NRC/Boston\)" <[email-masked]>
Date: Wed, 13 Mar 2002 14:13:56 -0500

Hi James,

> another note so as not to confuse the threads.

They at least mention the secure transfer of capability information.
However,
I'm looking forward to seeing requirements or additions to requirements,
folding in security aspects.

> same protocol to perform CAR discovery and to communicate MN

Agree, sorry for any inappropriate wording that didn't make this clear
enough.
From my perpective, CAR discovery has been seen as a problem that needs
certain
aspects to be addressed. Expressing MN's requirements is one of them to
determine the CARs. A solution for the CAR discovery problem is comprised
of different parts that fulfil as a whole the requirements we're currently
talking about. Parts of
the solution could be defined as a new protocol, for other parts we could
and should
use existing infrastructure. This was implicitly in my mind for ALL
requirements,
e.g., for the transfer of capability information. That's why I didn't put it
specifically
in the one we're currently discussing.
To expedite the process, what would an appropriate wording to make this
clear?
Or would it be more useful to have a general statement in the introduction
of the
requirements, that this is the case for ALL requirements, following the line
of
argumentation I tried to outline in the previous paragraph?

> discovery and MN security/AAA requirements for MN preferences is

I see this more as security aspects in general. Could you provide
requirement(s)
for this aspect (actually your above sentence is pretty much one, isn't it)?

Regards,

Dirk

---

From: "Trossen Dirk \(NRC/Boston\)" <[email-masked]>
Date: Wed, 13 Mar 2002 14:13:56 -0500

Hi James,

Regards,

Dirk

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 11:49:06 -0800

This requirement is meant for a solution to expressing MN preferences
without conflating that and routing and capability information
distribution, requested by Dirk.

    The Seamoby CAR discovery solution MUST provide a means for
    the MN to transmit its preferences for CARs based on CAR
    capabilities  to the AR. The MN preference solution SHOULD
    be logically separate from the CAR information distribution
    solution in order to maintain separation of security requirements,
    i.e. it need not be part of the same protocol as that involved
    in CAR information distribution. Existing protocols, such as AAA,
    MUST be examined as part the design process.

Comments?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 11:49:06 -0800

Comments?

            jak

---

From: "Trossen Dirk \(NRC/Boston\)" <[email-masked]>
Date: Wed, 13 Mar 2002 15:12:28 -0500

Hi James,

two comments:
1) I'd like to have the term CAR changed in GAAR or GAAR/CAR since
a solution  might exchange data of GAARs only while the CARs are determined
locally without distributing any information. In general though, I
appreciate to state the
separation.

2) For the last sentence, the same comment is valid as for the re-use
requirement earlier.
What you state here is a procedure requirement rather than a solution
requirement.
We should keep process and solution requirements separate. Either we put ONE
procedure requirement in the document, outlining exactly this implicit
requirement
explicitly, i.e., to re-use existing protocols wherever possible. That's
what you proposed
earlier (though removing the second sentence in this requirement).
Or we put a description of the solution assessment procedure in the
introduction
as prosa text, stating that solutions will be assessed against the re-use of
functionality and
that the design process has to include an assessment/gap analysis of
existing protocols.
Personally, I'd prefer the second option.

Regards,

Dirk

----- Original Message -----
From: "ext James Kempf" <[email-masked]>
To: "Trossen Dirk (NRC/Boston)" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 13, 2002 2:49 PM
Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery
Requirements)

---

From: "Trossen Dirk \(NRC/Boston\)" <[email-masked]>
Date: Wed, 13 Mar 2002 15:12:28 -0500

Hi James,

two comments:

Regards,

Dirk

----- Original Message -----
From: "ext James Kempf" <[email-masked]>
To: "Trossen Dirk (NRC/Boston)" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 13, 2002 2:49 PM
Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery
Requirements)

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 13:04:19 -0800

> locally without distributing any information. In general though, I

OK.

> Personally, I'd prefer the second option.

Let's put one procedure requirement in. Perhaps we can state this
as a goal in the introductory section (but with MUST/SHOULD
language) rather than as an explict requirement because, as
you say, it does not constrain the solution but just the
process.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 13:04:19 -0800

OK.

            jak