Re: [Seamoby] CAR Discovery Requirements

["James Kempf" <[e-mail]>]

Dirk,

> 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.
>

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.


> [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.
>

Agreed.

> [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.
>

Agreed.

> 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.
>
>

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


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