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:31:27 -0600

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 
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: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 16:23:46 -0800

Ajoy,

Instead of answer my fairly point blank questions, you appear to be
defending CARD against Dycar. Let's put aside dycar for a moment as my
point is not to start a comparison war. Instead I want to look at the
current CARD proposal and see if it can be simplified. I don't have the
answers, all I have are questions.

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 

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.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 16:23:46 -0800

Ajoy,

PatC

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 19:55:53 +0100

Pat,

since DT proposed the server function for reverse address translation and
optionally for static caps distribution, intention of DT was to discuss with
the WG whether or not it's beneficial to put this function to a node that
is integrated with an infrastructure already. Now, requirement of established
SAs between protocol peers is not only for AAA protocols, as you referred to.
But (and that's actually the reson why DT addressed this issue) we could
integrate the CARD server function with an entity that has an established SA
with ARs already. This avoids additional establishemnt of SAs. We took this
proposal over
as 'to be discussed'

Alternatively, if the server function is somewhere else, we took also this
into consideration and propose to have administratively configured keys/
passwords on ARs for initial weak authentication. After AR's activation,
strong authentication is to be established dynamically (IKE, or alternatives).
Means to establishthese SAs is not a CARD specific issue, I think, since it
addresses all other areas as well (FastMIP, CT, ...) so, there should be
a common mechanism to establish SAs between protocol peers.

marco

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 19:55:53 +0100

Pat,

marco