Subject: RE: [Seamoby] CARD Issues List

From: [email-masked]
Date: Fri, 14 Mar 2003 11:36:32 -0500

James,
Thanks for taking the time to putup a website. 
It will help us follow the discussion better.

Here are my comments.

Issue 1: You haven't mentioned the general WG opinion (including people from the DT)
that this issue is out of scope. We may be dealing with non-IP addressable devices here of
different technologies, and as pointed out by a slew of email,
and that there are existing methods to take care of this. 

So would this be a good statement for an alternative proposal for Issue 1?
Proposal 2: Problem is important, but is out-of-scope of CARD.  We
can use the following statement in the final spec. The operator/ISP MUST
provide an authorized list of AP beacons that can be attached to each AR. 

Issue 2:
Proposal 2: If you remove the server from the base draft, how is this base draft
going to address the AP-AR mapping. This is not clear to me. 
Maybe I'm missing something.

Issue 3: Though I'm not against putting explicit text in,
 I don't think explicit text is necessary. If the "cache protection"  scheme 
is designed well this kind of rate limiting will automatically happen. Rate limiting
may be difficult when used in the DT scheme, as MNs may report APs from other domains.

Issue 4:
Proposal 2: Apart from what is written, this should be added to the 
proposal. The scheme also uses a third party verified unique MN id and 
tags it with each cache entry. The number of cache entries created 
per MN is this limited. 

Proposal 3: I have illustrated the problems associated with Proposal 3. This is not
very secure against attacks by multiple malicious MNs, particularly when used
in conjunction with the DT approach. I haven't looked at the proposal's efficiency
when used with the cache population scheme described in dycard. I think
Proposal 2 works fine with dycard and we don't need proposal 3.

Issue 5:
Again, I think the points raised in the mailing list are missing here.
I think we shouldn't really do what is being proposed here. I think CARD is not
just for FMIPv6. 

Issues  6 - 9:
These issues may not exist when you have finished tackling prior issues.

Apart from these issues, here is an issue that was brought up in the mailing list:

Issue 12: Non-conformance with Requirement that deals with ARs with private
 and site-local addresses:
DT draft currently does not address this. 

Proposal: One possible approach is presented in dycard. 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 10:26:35 -0800

> and that there are existing methods to take care of this.

I haven't heard any general WG opinion. I've heard opinions from you and Dirk.

Anyone else want to give an opinon? I'd especially like to hear from someone not
on the Dyhard Dycard Team or the DT.

> So would this be a good statement for an alternative proposal for Issue 1?

OK, I will add it.

> provide an authorized list of AP beacons that can be attached to each AR.

I'll add that as another proposal.  Note: I suspect that whatever opinion the WG
has, it will ultimately be the opinion of the Security DAs that will prevail.
:-)

> Maybe I'm missing something.

Static configuration, PNE message exchange as in Dycard draft, or a server. Out
of scope for the AR to MN protocol. There only needs to be one feasible way, and
static configuration will always provide that.

> may be difficult when used in the DT scheme, as MNs may report APs from other
domains.

Govind, IETF protocols typically have this kind of rate limiting text in them.
Look at RFC 2461, pg. 47 for example, where rate limiting of RS in IPv6 Neighbor
Discovery is discussed. Or RFC 2608, pg. 41 for how SLP rate limits UDP for
reliable unicast transport.

If we don't put this in, the IESG is going to throw the draft back in our faces.

> tags it with each cache entry. The number of cache entries created

Done. I also added a reference to the Dycard draft and the DT draft for Proposal
1.

> Proposal 2 works fine with dycard and we don't need proposal 3.

I've done the same with Dycard. Let's let the WG decide.

> I think we shouldn't really do what is being proposed here. I think CARD is
not

That's your opinion. The opinion of the rest of the WG is also of interest, but,
ultimately, the ADs will have the final say since they're the managers.

> Proposal: One possible approach is presented in dycard.

Spell it out, please. It is not obvious to me that the DT draft doesn't deal
with site-locals, nor that the Dycard draft does.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 10:26:35 -0800

OK, I will add it.

            jak