Subject: Re: [Seamoby] Security Requirments for CAR Discovery

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 14 Mar 2002 20:16:37

Hi James:

I am happy that we have made progress towards stating the security concerns 
in our protocol more clearly. Your suggestions about replacing "A protocol" 
by other alternatives is well taken.

(Also, not that it matters to the business at hand, but how do you like the 
terminology "handoff reachability" defined as the reachability of an AR from 
another AR for "MN handoffs". "Routing reachability" means reachability of 
one router from another router for "IP packet routing". Since the concepts 
are clearly different, different terminology may help to avoid confusion. 
Again, it does not matter as to what terminology both of us like, as long as 
we are in sync on the issues).

Cheers,
Hemant

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Security Requirments for CAR Discovery
>Date: Thu, 14 Mar 2002 10:08:46 -0800
>
>Hemant,
>
>I think these are individual requirements, and should be separated out
>as such.
>
> > a) A CAR Discovery protocol MUST provide means for an AR to to verify
>that
> > another AR claiming to be its GAAR is genuine. In other words, the
>other AR
> > is indeed a GAAR and it is an authentic router. The authenticity of a
>router
> > MAY mean that it is authorized to act as an access router by the
> > jurisdiction of the environment (operator network, organizatoinal LAN,
>home
> > network etc.) that the router resides in.
> >
>
>OK, this is what I was saying about hooking into the security provided
>by the
>routing infrastructure, but you have spelled it out in more detail here.
>Good.
>
> > b)A CAR discovery protocol MUST provide means for secure capability
>exchange
> > between an AR and its GAAR.
> >
> > c)A CAR discovery protocol MUST provide secure means for the
>expression of
> > MN requirements to CAR discovery protocol."
> >
>
>These are also OK.
>
>However, I disagree with "A CAR discovery protocol". The implication
>here is that there is
>one protocol that does both. It is not clear to me at this point that
>this is so.
>I would prefer "A solution to the CAR discovery problem" or "Protocols
>involved in CAR discovery", something like that.
>
>Other than that, I think these are fine.
>
> > <HC> I do not have any disconnet here. I exactly know what CAR
>discovery is
> > about and agree with your detailed description above. However, I do
>not call
> > it routing reachability which has completely different connotations in
>IP
> > community.
> >
>
>One of the issues I have with this whole discussion is an assumption,
>which I think
>I'm seeing, that the problems Seamoby is addressing are somehow so
>radically different from those of the rest of the Internet that new
>terms must
>be invented to describe them. It reminds me of the early days of object
>oriented programming where people felt they had to invent all kinds of
>new
>terminology to describe what was essentially a function call with a
>default
>first argument. Extraordinary claims require extraordinary proof. I've
>not found any such proof so far that convinces me that radically new
>terminology is needed for what's been around in the Internet for 30
>years.
>If you can provide it for me, I'll be happy to accept some new
>terminology.
>
> >
> > <HC> I think that there are some fundamental differences between
>capability
> > attributes of OSPF, BGP and what is required for CAR. Some of them
>that come
> > to mind are as follows:
> >
> > - Subjects of OSPF and BGP are all routers in a domain and all ASs in
>the
> > Internet, respectively. While, CAR discovery affects only a small
>percentage
> > of routers, namely the access routers.
> >
> > - Routing protocols employ generous aggregation techniques at the
>inerdomain
> > boundaries. This is not in the interest of CAR, as every router in a
>given
> > domain may actually have different capabilities (best examples are
>load and
> > lower layer IDs).
> >
> > - Attributes exchanged by inter-domain routing protocls are typically
> > relevant for domains as a whole (e.g. AS policy in BGP). It does not
>seem
> > that these will suffice for CAR as here we have to exchange very fine
> > grained and possibly fast changing attributes of different ARs.
> >
> > - Either the AR or GAAR may actually not be a part of routing
>information
> > exchange. For example, a router in my home can be statically
>configured to
> > forward IP packets to some router in the Internet. However, I still
>may want
> > it to exchange capabilities with another AR.
> >
>
>I'm not arguing that the *content* of the attributes currently exchanged
>by
>these routing protocols is different. What I am arguing is that the
>*concept*
>of exchanging attributes is essentially the same as capability exchange.
>
>
>             jak
>

_________________________________________________________________
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: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 12:59:54 -0800

> Also, not that it matters to the business at hand, but how do you like
the
> we are in sync on the issues.
>

Hmm, off the top of my head, it sounds better. Or maybe "access router
reachability."

I think I see now where you are coming from on this. There is an aspect
here that is not involved in wired, but I don't believe it is as
different
as, for example, handoff itself. Essentially, what the current AR offers
as CARs is not much different than what is offered on a wired network
as choices for a default router, at least from a security standpoint.

The real difference is how the AR gets those choices. For CAR discovery,
they may only be available through the host because only the host may
have radio connection to the access points. On the wired network, the
choices are offered directly by the routers themselves via RAs or
are solicited by the host. So there is no need to consolidate them at
one router.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 12:59:54 -0800

the

            jak