Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff)

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 17:38:06 -0600

I missed a NOT in my previous email so resending 
this with the correction. 
Regards,
Ajoy 

-----Original Message-----
From: Singh Ajoy-ASINGH1 
Sent: Sunday, March 16, 2003 5:31 PM
To: 'Pat Calhoun'; Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [Seamoby] My thoughts on server approaches (and other fun
stu ff)

Hello Pat,
Please find my inline reply. 
Regards,
Ajoy 

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 4:18 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [Seamoby] My thoughts on server approaches (and other fun
stu ff)

> 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.
> 
> AJOY-> I agree that requiring a new server introduces a single point 
> of failure. But if we piggyback CARD function over the existing 
> server such as AAA, it will not have this problem though. BTW, 
> if WG decides not to that then I am fine with that too. But so 
> far I have only heard from dycard co-authors.  BTW, the DT
> proposed server based approach to get the feedback from WG. 
> The DT will be happy change the approach if WG decides that. 
Right, and I'm providing my feedback... but I'm just one of many.

> 
>  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.
> 
> AJOY-> Servers are easier to manage. BTW, if the CARD function 
> can be integrated with existing server function e.g., AAA, then I do 
> not see why enterprise will need to manage extra infrastructure. 
embedded devices need to be configured, regardless of whether a server
is present or not.

AJOY-> Yup. How much cost it will add over the configuration of 
base AAA server?

 At a minimum, you'll want to create some form of
security relationship between the embedded device and the server... so
there's no way around it :(

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. 

> 
> 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?
> 
> AJOY-> I am not sure if comparing security requirements of intra-domain 
> routing protocol with that of CARD is fair. I will definitely like to 
> hear from the security experts because I do not consider myself 
> as a security expert.   

Well, maybe it's not a fair comparison, but I'd like to know why. If we
are focused on intra-domain, then I see no difference.

AJOY-> The dycard in initiated based upon trigger from a mobile node. 
The infrastructure does not have any control over what is provided by mobile
node. 
What happens when a mobile node provides IP address of malicious node as 
CAR and the somehow security of AR is compromised? In this case, current AR
will have to 
believe what is provided by the malicious CAR as valid 
information.  This type of scenario may not be possible in 
intra-domain routing. But as I said before if security experts 
believe that this is not an issue and we can design a protocol 
assuming that security of AR will never be comprised, then I do 
NOT have any problem. 

> 
> 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!). 
> 
> AJOY-> I think here simplicity is the key. If we can get simpler 
> protocol that can guarantee less or zero call drop, then what is
> wrong in using that. I would request you to read dycard as 
> well as DT draft to conclude which is more complicated protocol. 

There's nothing wrong with high availability, but there's a price to pay
for that. If you're telling me that it's free... then I get really
confused and am willing to be convinced :)

AJOY-> You did not answer my question about the simplicity of protocol. 
The DT proposal of CARD is lot simpler than what is 
being proposed in dycard. BTW, I am not sure how much extra 
cost we will incur if just enhance the AAA server to provide 
CARD function. It does not look very expensive to me. I 
will be more concerned about the cost of high availability 
when the server is involved in routing such as HA. 

> 
> 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.
> 
> AJOY-> I agree that cell phone can drop the call due to poor 
> radio conditions. The radio conditions change due to many 
> factors which we cannot control sometime. But, cellular networks are 
> not designed to drop the call though. 

Ah, but that's my point exactly. They are designed to NOT drop calls,
but they do. There's physics involved here, and there's nothing in the
IETF we can do about it. So let's just keep that in mind while we decide
how complex this needs to be.

AJOY-> But we do have alternative which will reduce the chances 
of poor handoff. In dycard we know that some percentage of calls 
will be be affected due to lack of cache. This is in additional to the 
calls that are being dropped due to poor radio conditions. I know we can't 
control the radio conditions, but at least we should try to 
eliminate the poor performance that is being caused 
due to something that can be fixed.  

> 
> 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.
> 
> AJOY-> I will be happy with such protocol if the protocol in questions
> is a simple protocol and  provides significant benefit over 
> other protocol in consideration. 
Simplicity, in itself, is a significant benefit.

AJOY-> That is what I am questioning about the dycard. Do we really 
need a complicated protocol to solve an easy problem? Please read 
the dycard draft and let me know if you still think dycard approach 
is simpler.  

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 19:02:02 -0800

Ajoy,

Pease see my inline comments.

> AJOY-> Yup. How much cost it will add over the configuration of
[eunsoo] The cost is not just the configuration effort of the server. The
cost of the central server is reliability, scalability, cache contamination,
inflexibility due to static configuration in addition to changing the AAA
server in my current view.
Also my understanding of Pat's comment in the above is that the presence of
the server does not remove the need to configure ARs and APs.

> assuming that security of AR will never be comprised, then I do

[eunsoo] Are you saying that the server approach will work fine even when
the security of AR is broken?
If you assume the security of AR is broken, what is safe among whatever the
AR is seriously involved in?
How is the intra-domain routing system safe when the security of the AR is
broken?
BTW I am not sure whether this kind of extreme scenario should be
considered.

> when the server is involved in routing such as HA.

[eunsoo] Again, please substantiate your claim that the DT proposal is a lot
simpler than Dycard.
How come you ignore the cost of reliability, scalability, cache
contamination and inflexibility on the CARD protocol caused by the server?

> due to something that can be fixed.

[eunsoo] What percentage of calls will be affected in Dycard? Can you
substantiate your claims?

> the dycard draft and let me know if you still think dycard approach

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 19:02:02 -0800

Ajoy,

Eunsoo

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 20:33:44 +0100

Hi,

just to clarify on the 'static and inconvenient configuration' issue.
Please see inline.

marco

> the server does not remove the need to configure ARs and APs.

[marco] Do folks really think there is really full plug and play with
future commercial systems? Miminal configuration is required and,
I think, also justifiable. Operators want security, reliabliity, etc...
Now, minimal configuration is reasonable, as passwords for initial
authentication. Establishment of SAs for stronger authentication is
then perfromed automatically. Since topological characteristics are
operator driven, why not just assigning an ID (e.g. the scope-ID)
to an AR? Situation won't be that one cell is supported by one AR ;-)
Rather one AR will support a very large area by means of couple of
APs. AP authentication at AR is another issue, which is to be solved
for BOTH approaches, the server-function based and the dynamic, handover
based one.

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 20:33:44 +0100

Hi,

marco