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

From: [email-masked]
Date: Thu, 6 Mar 2003 13:18:26 -0500

Jim,

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.

[Govind] GPRS, for example is still a technology for the near future.
I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable
but neglecting IPv4 is not correct. I disagree.

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

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.

[Govind] First, I don't think this a real time. Information transferred between does not
comprise only of the example that you talk about network topology change. Hence
I don't think we can tie everything to routing reachability information like you 
say above. 

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

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.

[Govind]Even though is also manual configuration possible for PKI, I don't disagree
with PKI using servers (LDAP is just one way of doing it). 
What I disagree is with your notion that just because PKI uses it,
 CARD should use it too.  There is no need to do this. 

[Govind] DoS attack is possible because, the traffic is not coming from the external source,
it is coming from an authenticated access router because it is not able to
translate a particular AP to an AR. 

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.

[Govind] This is not true. The server approach needs a cache at ARs anyways. So what
ease are you talking about. By removing the server how does the protocol become
easier to deploy? This seems counter intutive to me. Are you saying that ISPs will
allow caches to be present at ARs only they have a server too?

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

I didn't make the distinction, it was in the draft. I think it should be
removed.
[Govind] ok.
> 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?

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

[Govind] I feel that there are better, possibly not difficult, ways to make any 
DoS attack really hard to materialize. 

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.

[Govind] I have to read up on this before I can respond to you.

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

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

[Govind] First, I don't think the IPv4 should be dropped. Secondly, I think
site-local addresses in IPv6 is also covered by this requirement. 
Third, I think non global routeability may not be just for the sake of lack
of addresses, it may be for other reasons too, like security, as you probably know.

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 11:02:15 -0800

> but neglecting IPv4 is not correct. I disagree.

I don't see what GPRS has to do with CARD.

I think I would have to see a higher level of implementation and deployment
interest before I would be willing to change my opinion, but the trend in Mobile
IP is towards stopping any technology development in MIPv4 unless it is directly
related to deployment concerns. As a way to focus the design and reduce people's
work load, I think that would be a prudent course for Seamoby to follow as well.

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

(for the second and last time) Like I said, I did not say it should be an OSPF
extension. I said that we need to talk with the Routing Area Directors about
whether it is an appropriate kind of information to distribute using the IGP. It
is different from CT in that it is not tied to handover. There are no timing
constraints on whether this information gets between routers within a particular
time window. The information is not tied to a specific mobile node. It is
orthogonal to the router to host protocol for CARD. The information is tied to a
topology change, an AP going up or down, which is like a router going up or
down, suggesting an IGP extension. Therefore I believe it should be in a
separate document. Whether or not an IGP extension is the right approach is TBD.

>  CARD should use it too.  There is no need to do this.

Govind, if I am a sysadmin, I don't want 50 different ways to configure my
network, I want one. Its as simple as that. Ask the sysadmin in your office if
he likes having multiple ways of doing things if you don't believe me.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 11:02:15 -0800

jak