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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 15:59:18 -0600

Hello Pat,
Thanks for expressing your thoughts.
Please find my few 
inline comments. 
Regards,
Ajoy 

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 2:24 PM
To: [email-masked]
Subject: [Seamoby] My thoughts on server approaches (and other fun
stuff)

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.

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. 

 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. 

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.   

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. 

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. 

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. 

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

AJOY-> Ok, but I suppose we are not discussing the inter-domain issues. 
Even in big access network, the security associations are not manually
configured though.  

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
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

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)

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

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

> hear from the security experts because I do not consider myself 

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. 

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

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

> 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

---

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,

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

NOT have any problem. 

PatC

---

From: [email-masked]
Date: Mon, 17 Mar 2003 09:25:29 -0500

>> being proposed in dycard. 

Do you have anything of substance here to say? Why on earth is a server-based
approach simpler than an approach that does not require said server? Statements
don't get right just because you post them. And rejecting our questions regarding the grounds
for what you claim with "I would like to hear opinions of others" doesn't make it better.
You post statements on the list with claims, and everybody, the silent WG members and the 
dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing 
more than a simple, unproven claim which can easily be rejected.

Thanks,

Dirk

---

From: [email-masked]
Date: Mon, 17 Mar 2003 13:17:16 -0500

My 2 cents at the end - Hemant

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

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

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

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. 

Hemant --> PSTNs were designed for 2% call blocking probability as a rule of thumb (recall Erlang blocking models). Then, another point about theory of statistics - addition of two very low probabilities does not degrade system performance. In other words addition of failure event of prob 10^(-6) to an event of prob 10^(-6) does not in practice (or even in theory) make any difference to overall system performance. I am not saying that we apply this straight to IP, but just because we were talking about probabilities ;-).

I know we can't 

PatC

---

From: [email-masked]
Date: Mon, 17 Mar 2003 13:17:16 -0500

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

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

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

I know we can't 

PatC

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:08:17 -0500

Hi Marco,

see comments inline

[snip]

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

The need for configuration here mainly refers to the static configuration
of neighborhood information in the server. The issue of how to tackle probable changes of 
such kind of neighborhood information (which was also one of the issues 
in the problem statement, and is also included in the requirements, i.e.,
the necessity to react upon changes in logical and physical topology) is
right now hidden somehow in the definition of the scope-id, which has to be set
somehow "properly" by the operator. Further, changes in topology are somehow
taken care by updating the backend server through any means. We outlined this
kind of static configuration solution already in the issues draft and called it
undesirable, in particular when we look at inter-domain cases.

Thanks,

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:08:17 -0500

Hi Marco,

see comments inline

[snip]

Thanks,

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:23:28 -0500

Hi Marco,

>From: ext Liebsch [mailto:[email-masked]]
>Sent: Tuesday, March 18, 2003 3:17 PM
>To: Trossen Dirk (NRC/Boston)
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: [Seamoby] My thoughts on server approaches (and other fun
>stu ff)
>
>
>Hi Dirk,
>
>I agree that it would be helpful to get some feedback from outside
>DT and dycard authors. Now, hope we can get some opinion during
>the Seamoby meeting.
>Now, as you know, there are some characteristics of a server-function
>approach that are not really convincing for reasons that are 
>actually valid for
>ALL server-based approaches. DT proposal tried to make the use 
>of the server
>function clear, keeping it restricted to very basic 
>functionality to avoid
>complexity. I wonder why statements like 'static config at the server'
>and 'server is used for initial population of caches only' appear, this
>is not what the server function is for, and DT doesn't 
>introduce a server
>function only to introduce additional complexity ;-), but to 
>avoid protocol
>complexity, ensure scalability and meet expectation on functional
>requirements.
>As referred to many times, if WG wants an alternative approach for
>cache maintenance, DT is open for modification. But tradeoff 
>coming with
>a currently available alternative approach, that's what I 
>tried to summarize
>in my last mails. Maybe we should take them over to slides for
>Thursday's meeting to not put bias on 'knocking on the server function
>approach'.
>
>marco

We're not trying to "knock out the server function". I agree that we have to 
put the different issues on the table, in particular separating the problem field
for this. 

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:23:28 -0500

Hi Marco,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 19 Mar 2003 11:50:18 -0600

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

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

Ajoy,

Instead of answer my fairly point blank questions, you appear to be
defending CARD against Dycar. 

AJOY-> I agree this was not a good strategy. 
Sorry about this. 

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. 

AJOY-> Ok. We will be glad to simplify the DT draft based upon the 
WG feedback, 

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.

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.

PatC