Re: [Seamoby] Security Requirments for CAR Discovery

"Hemant Chaskar" <hchaskar@hotmail.com> Thu, 14 March 2002 16:25 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21470 for <seamoby-archive@odin.ietf.org>; Thu, 14 Mar 2002 11:25:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08783; Thu, 14 Mar 2002 11:08:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08758 for <seamoby@ns.ietf.org>; Thu, 14 Mar 2002 11:08:51 -0500 (EST)
Received: from hotmail.com (f8.law7.hotmail.com [216.33.237.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20738 for <seamoby@ietf.org>; Thu, 14 Mar 2002 11:08:48 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 08:08:20 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 16:08:19 GMT
X-Originating-IP: [63.78.179.5]
From: Hemant Chaskar <hchaskar@hotmail.com>
To: seamoby@ietf.org
Subject: Re: [Seamoby] Security Requirments for CAR Discovery
Date: Thu, 14 Mar 2002 16:08:19 -0000
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
Message-ID: <F8hMOgRGkQ6mBySsxVY000138e5@hotmail.com>
X-OriginalArrivalTime: 14 Mar 2002 16:08:20.0320 (UTC) FILETIME=[759FC600:01C1CB72]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

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" <kempf@docomolabs-usa.com>
>To: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
>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
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby