Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

From: [email-masked]
Date: Thu, 6 Mar 2003 12:09:43 -0500

Hi Jim,
Some comments embedded inline.

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 8:01 PM
To: [email-masked]
Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

[snip]

 dropping 2)
and making this signaling a collection of options on FMIP. In addition, I would
suggest that the CARD design team co-ordinate this with the current editor of
the FMIP draft. There is no point in having 2) if FMIP provides the
functionality.

[Govind] 
 I do agree that we can optimize CARD if we know FMIP (I think you mean v6)
 is going to be available in the subnet. However, CARD is needed to operate in domains
 that are not IPv6. I would think the better way to go is FMIP and other seamless
 mobility protocols were to use CARD messages for this purpose. I think this was
 pointed out in an email on the mobile-ip working group. 

3) I can't really see the point of introducing a new inter-router protocol of
this sort. I believe this would be better handled by defining some kind of
OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a
proposal, however. In any case, it needs investigation and should be moved into
a separate document if it proves to be of interest.

[Govind] Could you explain why you would think it should be an OSPF extension?
Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each
other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable
protocol functionality. Why is this any different? I think this is very important
 and helps provide a major functionality and it does belong in this document. Maybe 
I'm missing something.

4) I disagree with the contention of some that this protocol is introducing a
new network element. Any large scale enterprise or ISP network is going to have
configuration in it, and this protocol is essentially defining a way to do
configuration. For small, home networks, this might not be required, because it
might be done using a Web interface to the firewall/access point. The proposed
solution in this draft is fairly vague, but I can see a couple of possible
dispositions:
    a) Define a RADIUS extension like that used by IAPP.
    b) Define an LDAP schema for access point configuration information.
    c) Define an SNMP MIB that allows a router to obtain this information from
another router.
I believe 802.11 has its own MIB, but we are talking about something that is
more generic. I've got no opinion about which of these would be better, and
there could be other possibilities. We should decide fairly quickly which we
want to pursue.

[Govind] Do you think any of the methods that you suggest are
worth the effort for the purpose the CARD server is designated to do? Plus,
using a CARD server introduces the possibility of DoS on the CARD server itself.
I think this is one direction that we do not need to go, the cost heavily outweighs 
the benefit, IMO.  

Technical Comments
---------------------

Section 3.2: Highly dynamic capabilites should be out of scope. Also, in
paragraph 2, what are downlink channels? Not all wireless protocols will have
these.

[Govind] First, I don't know what you mean by highly dynamic capabilities. Can
you give some examples? I think the Issues draft does make the distinction between capabilities
as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new
level of distinction now? 
Second, regardless of the level of dyamicity  of the capabilities in question,
 the basic capability transfer remains the same. The state times out and it is refreshed.
 Third, the draft does not go into saying what 
capabilities are going to be put in. All it defines is the framework for capability transfer. 
So what are you trying to remove here? Are you saying that you want to remove the function of
the protocol that deals with dynamic capabilities? This I disagree with.

[snip]

Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is,
itself, subject to DOS attacks. The solutions presented in Section 6.3 for
handling these problems are much more streamlined and align with IP network
softstate approach:
    1) The protocol specifies a minimum interarrival time for sending requests.
    2) The protocol specifies a minimum reply time for routers replying. If too
many requests arrive, the router begins to selectively drop so hosts have to
retransmit.
    3) A default cache lifetime is defined. After this time, the router times
out the cache entry.
   4) An entry presented by the MN gets a preference level. The more times it is
reported by another MN, the less likely it is to time out. This needs to be
quantified and described as an algorthm.
These elements need to be added to the protocol draft for 1) in the meta-issues
section.

[Govind]
The scope-id solution has several questions regarding effectiveness and
I have pointed them out in my earlier email.  Having said that, none of the methodologies
 that you suggest above really help that much 
in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not?

One more thing that is missing in the DT draft is providing CARD services to ARs that
have private addresses, i.e. Requirement 3.3.  
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 09:56:57 -0800

>  pointed out in an email on the mobile-ip working group.

I would argue that events have overtaken us and CARD is no longer relevant for
IPv4 from a market perspective. Certainly, this is the case with other advanced
IP mobility technologies, like the fast handover technologies CARD was supposed
to support. I believe it makes more sense to have CARD be a well-integrated part
of the local link movement protocols for IPv6, where there is still some
interest in technology development on advanced IP mobility technologies.

>  and helps provide a major functionality and it does belong in this document.
Maybe

First off, I'm not convinced even an OSPF extension would be the right approach.
Like I said, we need to talk with the Routing Area Directors to see what they
say. However, what suggests that it is a better approach is that the information
being conveyed is not real time, that is, it is not connected to handover. It
will vary slowly as access points are introduced or brought down. Thus, it is in
the same category as standard routing reachability information distributed by
the IGPs, and not like CT or handover.

> I think this is one direction that we do not need to go, the cost heavily
outweighs

Servers are used all the time for PKI. There is an article in this month's ACM
Communications about how servers are used for PKI. They are used to configure
routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is
easy to foil: put a rule in the firewall that disallows any external traffic to
the server. Also, don't advertise the address of the server outside the access
router.

From an enterprise/ISP standpoint, tying CARD configuration to a server in a
standardized way might help to speed deployment. This component should not be a
required part of the router to host protocol, though, because the router to host
protocol could also be deployed in a small office or home environment with a Web
configuration. That's why I think it should be in a separate document.

> Technical Comments

I didn't make the distinction, it was in the draft. I think it should be
removed.

> in alleviating DoS attacks either. IP spoofing will counter all of the checks
is it not?

If the router starts dropping requests when they come in too quickly, then it
will look to clients like it is responding more slowly, but the attacker will
not succeed in completely disrupting service. That is what is meant by 2).

In addition to these measures, I think the draft should specify that standard ND
security including SEND is used on the protocol. This should completely
eliminate the possibility of IP spoofing.

> have private addresses, i.e. Requirement 3.3.

If the IPv4 requirement is dropped, I don't think this is necessary.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 09:56:57 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 17:08:47 -0800

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 06, 2003 9:56 AM
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

> >  dropping 2)
> > and making this signaling a collection of options on FMIP. In addition,
I
> would
> >  is going to be available in the subnet. However, CARD is needed to
operate in
> domains
> >  mobility protocols were to use CARD messages for this purpose. I think
this
> was

(eunsoo) Well, I have been seeing commercial products with Mobile IPv4. I
don't think we should forget about IPv4 yet.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 17:08:47 -0800

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 06, 2003 9:56 AM
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

I
operate in
this

Eunsoo