Subject: [Seamoby] My thoughts on server approaches (and other fun stuff)

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 12:24:01 -0800

Just caught up on the rather long e-mail thread, and wanted to
communicate my feelings about the discussions going on.

My initial reaction is that mandating a server is the wrong approach. I
am not claiming that discovery over the air, or some other approach, is
better, but *requiring* a server is problematic. I agree that service
providers will most likely not have much of an issue with requiring a
server for their network, but I doubt that enterprises that require
mobility, really want more infrastructure to manage.

One issue that I've heard in favor of a server approach is security.
I'll admit that I don't understand all of the issues, but there are
plenty of proof points where security can be provided without a backend
server. Whether it be peer-2-peer authentication via shared secrets,
certs, or what-have-you. In fact, maybe we should look at how OSPF
domains are created, and how routers communicate in a secure fashion? I
understand there are significant differences, but is there anything we
can learn from?

The next issue I have is what appears to be a requirement to build an
iron-clad protocol. I get very nervous when I hear that folks want to
create a protocol that cannot drop a single call (or packet!). Let's be
fair here folks, my cell phone drops calls all the time, regardless of
whether I'm doing a 911 call or not. That's just the nature of 1) really
complex systems, 2) unreliable code and 3) wireless is simply NOT
reliable. So in my opinion, we need to design a protocol that works
well, and can tolerate failures and recover from any problems.

I'm perfectly happy with a protocol that learns about it's neighbors.
It's all about trade-offs. Ethernet also has a cache, and has designed a
mechanism to re-validate the cache before it expires. Again, another
area that we should look into, and determine whether it can be applied
to this particular scenario.

The last one is rumblings about inter-domain. This subject has come up
before, and at that time the result was that it was out of scope (and it
still is).

Next is just a nit. When I hear "DT hat off", it provides the appearance
that DT members have more power than the rest of the WG, and I just
wanted to lay that one to rest... a DT serves the WG and does not have
more power (or say). We are all individual contributors working towards
a common goal.

Hope this help,

PatC

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

---

From: [email-masked]
Date: Wed, 19 Mar 2003 16:47:27 -0500

Hi:

CARD server is logical entity (a piece of software and IANA assigned UDP number) which can be put on any box. Security mechanism for AR-server exchange can be of operator's choice, e.g., if this box has IPSec stack and ARs have IPSec stack and they have configured credentials (passwords) it can use IPSec. 

In summary, I too am not convinced about tying CARD to AAA. I also don't get the argument that AAA servers make security readily available. If someone has an enterprise network that does not use AAA (Diameter server to be precise), but has Kerberos, for this person security is readily available in the form of Kerberos rather than Diameter.

Hemant 

-----Original Message-----
From: ext Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, March 19, 2003 12:56 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [Seamoby] My thoughts on server approaches (and other fun
stuff)

> Regarding the one question I can answer:
> AJOY-> I did not follow this. If CARD function is extension of 
> > AAA function then why we need SA between embedded device and 
> > AAA server. 
> 
> exactly, if it's an extension to an AAA protocol, every AAA protocol that I
> know requires some form of security relationship in order to communicate in 
> a secure fashion, either via shared secrets, or certs. So there's security
> configuration required regardless of the approach.
> 
> AJOY-> I do agree the AR will require some SA with AAA server. But such security
> should be readily available when AAA is  being used in access network.

ok... fair enough. So my question to the WG is whether it is a
reasonable assumption that everyone will deploy AAA servers for
mobility. If so, maybe it's a safe assumption, but I'm not convinced.

PatC