Subject: RE: [Seamoby] Comments on DT CARD draft

From: [email-masked]
Date: Wed, 5 Mar 2003 16:59:40 -0500

Jim,
First, I think the DT has a different view from you about the server not being a new element :).

Essentially what saying is that you are adding a new functionality on some other 
existing element in the network. 
There is an inherent assumption that this can be added to such servers. For example, this may
not be possible in AAA servers given the present charter of AAA WG. The DT members also 
seem to accept this may be the case.

The main point I was trying to make is
 having an extra server (or functionality) whereever it may  reside is not worth it at all. 

Could you elaborate more on the IPSec configuration that you mention. Just to
understand you better.
I look forward to your comments. 
-Govind.
-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 4:36 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]
Subject: Re: [Seamoby] Comments on DT CARD draft

Govind,

I don't agree that the server specified in the draft is a new element. The
specification is for a configuration server, AAA or LDAP or something like that.
This is a common way of configuring routers, I believe it is used for IPsec
configuration information.

I haven't finished reading the draft yet so I can't comment on the rest of your
points.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 05, 2003 10:58 AM
Subject: RE: [Seamoby] Comments on DT CARD draft

> Hi Ajoy,
> Comments inline. Thanks for your reply.
>
> -Govind.
>
>
>
> AJOY-> We are aware of this. What is the status of
> requirement draft? Is it approved by IESG yet. Probably
> we need to change this requirement in case WG likes
> to go with server based approach.
>
> [Govind] The requirements document has passed last WG last call. The IESG did
come back with one set of comments, but I don't think they had
> any problems with this particular requirement in those comments.
>
> [snip]
>
> AJOY-> This depends upon the cache timeout as well as handoff traffic.
> BTW, the server based approach is easier to manage as well
> it provides extra security. If we deploy scope-id with serve based approach,
then
> it is very much possible to reduce or even eliminate the problem of cache
contamination.
> This also minimizes the affect DoS attack.
>
> [Govind] The cache timeout can be handled quite easily. Regarding, the server
based approach being more secure, this is quite unclear from the document. I
don't think you can eleminate the cache contamination problem from any of the
schemes that you have described. I have explained in my email how using the
scope ID approach still allows you to keep "n" entries
> that are not CARs in the cache.  In fact, the DT draft acknowledges that the
> CARD server can still be subjected to a DoS attack. I don't really agree with
your premise that you alleviate the security problems just by having a
> CARD server.
>
> [snip]
>
> AJOY-> These entries may not be cached for ever. Smaller the cache timeout,
> the earlier you will be able to detect any change of capability
> or L2->L3 mapping information.
>
> [Govind] So we need to choose a timeout that is appropriate, why do we need a
server for this? I still don't understand that.
>
> [snip]
>
> AJOY-> I think this will be better than the case where cache entries are
solely
> propagated by the mobile node. I think in the later case, the first handoff
> will always be the slower. Moreover the later approach is very
> difficult to manage and is even less secure.
>
> [Govind] Yes, the first handover case. So are you saying the cost of the first
handover being not seamless is worth introducing a new element in the network?
>  Could you explain why the latter approach is less secure? Once you have a
cache at the AR that is populated with MN input, like what you are doing in the
DT draft and we do in dycard, the level of security of the protocols is pretty
comparable. Please note, any of the security checks that you have introduced
including scope ID, which I still think is not the best way to go, can be used
without the server being present at all.
>
> Also, you could you list out the security holes that you perceive in the
dycard draft. Also, could you look at the way we have handled it and see whether
we have presented solutions tackled the issues?
>
> Lastly, as I pointed out in my earlier mail, we have provided a method, in an
earlier version of the draft, that makes the first handover also seamless in a
probabilistic sense. I don't think DT draft can promise better than that too. We
omitted this, because we felt that it doesn't make much sense in the steady
state of the system. Basically a cost vs. benefit analysis.
>
> ----------*
> [snip]
>
> BTW-> The IP packets are not routed via CARD server so I am not sure if it a
big
> drawback.
> [Govind] You need the CARD server for any translation on a cache miss.
> So what is this that you bring about routing packets via CARD server? I'm
completely missing your point here.
> -----------------------*
> I will be more concerned about the single point of failure where IP packets
are
> routed through it. CARD server will provide a similar function as DNS server
> So, probably it is not a big drawback in my understanding.
>
> [Govind] Does this imply that the functionality of the CARD server is minimal?
We are talking about the "central" point of control here that determines the
cache entries. I think it a very important point to consider.
> ---------------------------*
>  On the other handoff,
> server based approach provides better manageability as well control.
>
> [Govind] What manageability are you talking about? You assume that each AR
knows what APs it has. Why should it be conveyed to the CARD server? Why can't
it be conveyed directly to its CARs? Also, what lack of manageability that you
perceive in dycard? Can we talk quantitatively rather qualitatively here?
>
> As I mentioned above,
> with clever use of scope-id, it is possible to reduce the affect of DoS attack
as
> well as cache contamination problem.
>
> [Govind] Could you define "clever" use of scope-id? Quoting from the draft
> "operators may set their ARs' scope id to a server. When a current AR requests
the L2-L3 mapping from the server, the server returns the mapping with the
scope-id".  From the above reasoning, there is an close correlation assumed with
the ARs and APs. That might not be true first. Second if the approximate
locations of APs and ARs are known and they are in the same domain, why not have
these scope-IDs directly stored at the ARs in the cache rather than pushing them
to the CARD server then getting them down to the ARs.
>
>
> [snip]
> AJOY-> Probably you are right. We do need to get consensus from AAA group for
doing this.
> BTW, If we use AAA server, then it is also possible to use AAA server for the
> purpose of key distribution. I would like to receive feedback from other
members of
> WG about the potential use of AAA server as CARD server.
> [Govind] I don't think we need to do this at all. Key distribution, that too
for ARs in the same domain, is not at all CARD problem at all. There are other
ways to do it, and I don't think we need to re-invent the wheel. Routers within
a domain are trusting each other right now too, is it not?
>
>
> [snip]
> AJOY-> I am not sure I agree with you here. Could you provide some additional
> detail why you think scope id is complicated?
>
> [Govind]I'll let you know if I come up with something more, than what I've
provided in my previous email.
>
> Also, when we talk about inter-domain handovers this may be quite difficult to
achieve. I know that we are not talking about inter-domain handovers at this
point, but coming up with a solution that does not work very well in the future
is not the correct way to go, IMHO.
>
> AJOY-> Let be focused now.
>
> [Govind] Focusing on a solution that doesn't work very well even now is not
the best way to go either. Instead, it will be more prudent to come up with
> a solution that works well now, and also has a good chance of being accepted
later.
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
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: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 14:42:57 -0800

> First, I think the DT has a different view from you about the server not being
a new element :).

Like I said, I haven't finished reading the draft yet. Too much email to read.
:-)

> seem to accept this may be the case.

It could be an LDAP server.

>  having an extra server (or functionality) whereever it may  reside is not
worth it at all.

Depends. There are other things in this draft (TAR calculation, for example)
that one could argue shouldn't be there.

> Could you elaborate more on the IPSec configuration that you mention. Just to

My understanding is VPN gateways and routers often store SPD entries in LDAP
servers. Having the configuration information centralized makes it easier for
sysadmins to maintain.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 14:42:57 -0800

jak