Re: [Seamoby] Security Requirments for CAR Discovery

"James Kempf" <kempf@docomolabs-usa.com> Thu, 14 March 2002 00:51 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 TAA26104 for <seamoby-archive@odin.ietf.org>; Wed, 13 Mar 2002 19:51:00 -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 TAA01611; Wed, 13 Mar 2002 19:45:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01580 for <seamoby@ns.ietf.org>; Wed, 13 Mar 2002 19:45:17 -0500 (EST)
Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26047 for <seamoby@ietf.org>; Wed, 13 Mar 2002 19:45:14 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0ijI12318; Wed, 13 Mar 2002 16:44:45 -0800 (PST)
Message-ID: <00db01c1caf1$35a09510$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Hemant Chaskar <hchaskar@hotmail.com>, seamoby@ietf.org
References: <F223wmcECTaJ82glKCU00017272@hotmail.com>
Subject: Re: [Seamoby] Security Requirments for CAR Discovery
Date: Wed, 13 Mar 2002 16:43:07 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

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.

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

> In either case, the routing
> >fabric has to be able to trust the information it gets.
>
> [HC] Why CAR discovery needs to inject any information in routing
fabric? As
> I have explained above, it is about peer to peer information exchange
> between GAARs.
>

Because the routing fabric is going to use information about reachable
GAARs in order to make decisions about what GAARs to offer the MN.
The GAARs are part of the routing fabric.

>
> [HC] I am not denying that the security problem may exist. But then,
we need
> to point it out more directly and precisely rather than saying that
the
> security problem is something like the one involved in routing. I
think the
> problem is that "why will the two GAARs involve in capability exchange
in
> the first place, unless they are assured about the validity of each
other".
> Now we do have to come up with a solution to that. But, it is
difficult to
> see how this problem alone can draw relation between CAR discovery and
> routing protocols.
>

What I have tried to say (perhaps unsuccessfully) is that a GAAR that
receives
CAR information has to have the same level of trust in that information
as
it has in path information received via OSPF. Whether or not the same
protocol is used is solution space, and therefore not part of the
current discussion.


            jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby