Subject: [Seamoby] Security Requirments for CAR Discovery

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 11:52:19 -0800

The current requirements draft is a little thin on security. Here's a
proposal:

    The Seamoby CAR discovery solution MUST provide proper security.
    Security on CAR information and capabilities distribution MUST
conform
    and interoperate with existing IETF security policies and protocols
on
    the security of routing information distribution. Security on
communication
    of MN preferences to ARs MUST conform and interoperate with existing
    IETF security and AAA policies and protocols for host security,
where
    applicable.

Comments?

            jak

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 13 Mar 2002 20:41:05

Hi James:

Some comments inline.

>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>
>Subject: [Seamoby] Security Requirments for CAR Discovery
>Date: Wed, 13 Mar 2002 11:52:19 -0800
>

[HC] I agree with this part, though I think that the first sentence is 
superfluous. Also, do we have an official reference on such IETF security 
policies and protocols? If we do, we can quote it too. Furhter, will the 
currentness of that referece change over time?

>on
>     the security of routing information distribution.

I do not agree with this part. What is the relation between routing and CAR 
requirements? The first part of your requirement covers all the IETF 
security policies and protocols, and that should be enough in my opinion.

Security on
>     IETF security and AAA policies and protocols for host security,

I agree with this again.

>             jak

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 13 Mar 2002 22:09:36

Hi James:

Please see coments below marked as [HC]

--------------------------snip---------------------------------------
>CAR discovery involves sending information about the reachability and
>capabilities of one router to another, possibly via a host.

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

Routing
>information distribution involves sending information about the
>reachability and capabilities of one router to another, usually not via
>a host. The only thing the two don't have in common is that one could
>possibly use a host while the other doesn't.

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

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.

Thus, the
>security on the information distribution needs to be the same. Note that
>this is *not* to say that, a priori, CAR discovery and routing
>information distribution should be solved by the same protocol, just
>that they involve the same kind of security problem.
>
>For an example of the problems it might cause if security on CAR
>discovery were any less than that on routing information distribution,
>consider security on MIP binding updates. The newly decided upon
>protocol, return routability, depends critically upon the security of
>the routing fabric. If the security on CAR discovery causes the security
>of the routing fabric to be compromised, then MIP RR security on BU
>updates is compromised.
>
>             jak
>

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

Regards,
Hemant

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 13 Mar 2002 17:49:42 -0500

Hi James,
Just to add to Hemant's comments, reachability of GAARs according to CAR 
discovery is in the view of the current MN in question. Two GAARs may be
reachable for an MN but not for a different MN. In the IP sense, two GAARs 
are always reachable somehow through the Internet (of course I am not 
considering private addresses here. But even in that case it may be 
reachable indirectly through a border router). In summary,
I share Hemant's concern about why you are going linking routing and CAR 
discovery.  I don't know whether I am  missing something.

Regards,
Govind.

>Join the world?s largest e-mail service with MSN Hotmail.
>http://www.hotmail.com
>
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

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.

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

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Mar 2002 10:16:21 -0600

James,

I think your second sentence is putting most of its
emphasis on  protecting routing information.
I don't know what parameters the CAR discovery mechanism needs, and
what type of capabilities are communicated, but
whatever parameters those are, if they are sensitive, they must
be protected. So a stronger alternative would be:

The Seamoby CAR discovery solution MUST provide proper security and
protection for network's sensitive information. Furthermore,
security on CAR information and capabilities distribution MUST
conform and interoperate with existing IETF security policies 
and protocols on the security of network information distribution.

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 1:52 PM
To: [email-masked]
Subject: [Seamoby] Security Requirments for CAR Discovery

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Mar 2002 10:16:21 -0600

James,

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 1:52 PM
To: [email-masked]
Subject: [Seamoby] Security Requirments for CAR Discovery

Comments?

            jak

---

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

>Date: Thu, 14 Mar 2002 10:08:46 -0800
>
>Hemant,
>
>I think these are individual requirements, and should be separated out
>as such.
>
>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.
>
>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.
>
>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.
>
> >
>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
>