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

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

Hi James:

I think that the genesis of this discussion thread is your concern that the 
current document does not bring out security aspects in detail. Sharing 
that, I would like this concern being addressed in a direct and precise 
manner. From that perspective, may I propose the following text for the 
security requirements part:

"A CAR discovery protocol MUST address the security concerns involved in the 
various aspects of protocol operation, namely GAAR discovery, capability 
exchange and CAR selection. In particular,

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.

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

If you like these, you need not read the rest of the comments below included 
as <HC> for friendly understanding purposes.

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Security Requirments for CAR Discovery
>Date: Wed, 13 Mar 2002 16:43:07 -0800
>
>Hemant,
>
> > [HC] CAR discovery is not about spreading reachability information of
>one
> > router to another. That is the job of routing protocols. It is about
> > capability exchange between GAARs.
> >
>
>I think we have a fundamental disconnect here. Please go back
>and review draft-ietf-seamoby-cardiscovery-issues-02.txt.
>
>One of the primary drivers behind the CAR discovery work is spreading
>reachabilty information for fast handover purposes. The access routers
>need to know what other routers a mobile node can get to in order
>to be able to perform fast handover. This is, fundamentally, spreading
>routing
>reachability information.

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

>
>BTW, I am not aruging this from a purely theoretical perspective.
>We are in the process of implementing fast handover, and
>we have implemented one of the CAR discovery algorithms
>for exactly this purpose.

<HC> Same here. We are using CAR discovery for fast and seamless handovers 
and some other interesting applications too.

>
> > [HC] I think there is little commanality between routing protocols and
>CAR
> > discovery. Let me explain. There are two main parts of CAR discovery:
>GAAR
> > discovery and capability exchange. I will come to GAAR discovery
>later. As
> > far as the capability exchange between the GAARs is considered, once
>the two
> > GAARs have decided to exchange capabilities they can do so by opening
>simply
> > a peer-to-peer connection such as TCP between them or use open loop
> > messaging like UDP and ICMP. I see no involvment of routing protocols
>here
> > (beyond the point that they will help route the packets containing
>these
> > messages). To give an analogy, if two routers need to do FTP between
>them
> > they simply do it using TCP. FTP is however not deemed to be related
>to
> > routing. If capabilities are exchanged via MN instead, the same logic
>still
> > applies. Only, there is extra node between them.
> >
> > Now coming to GAAR discovery part, I struggle to see how a routing
>protocol
> > are related to GAAR discovery. The problem statement clearly points
>hout how
> > GAAR discovery (Geospace) is different from logical neighborhood
>discovery
> > (Cyberspace) on which routing protocols are built.
> >
>
>Both OSPF and BGP have the ability to send capability information, in
>the form
>of attributes. While I am not advocating that CAR discovery use OSPF or
>BGP, I am trying to point out that the problem is not all that
>different.

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

Regards,

Hemant

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

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 10:08:46 -0800

Hemant,

I think these are individual requirements, and should be separated out
as such.

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

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

> it routing reachability which has completely different connotations in
IP

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.

> 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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 10:08:46 -0800

Hemant,

These are also OK.

            jak